Intermediate Azure test (Intermediate)
30 questions · 35 minutes · Free
Networking, App Service, AKS and Azure DevOps.
Take the Intermediate Azure test
What it covers
- VNets and NSGs
- App Service
- AKS
- Azure DevOps
- Monitor and Log Analytics
Interview format
- Questions: 30 questions — 18 multiple choice, 12 multi-answer
- Time: 35 minutes, timed from the first question
- Difficulty: Intermediate
- Skill area: DevOps & cloud
- Price: Free
Earn a certificate
The Intermediate Azure test is one of the 7 tests of the Cloud Engineer: Intermediate learning path. Pass it and the other 6 tests at 70% or more and readyforhires issues you a verifiable certificate in your name, with its own code and verify link to share or add to LinkedIn.
Sample questions
5 sample questions from the Intermediate Azure test, with the answers. Samples are taken out of the live test, so you will not meet these when you sit it.
When implementing network policies in an AKS cluster, which of the following statements accurately describes how network policies are enforced?
- Network policies are enforced at the node level, not the pod level.
- Network policies are not supported in AKS and must be implemented using Azure Firewall.
- Network policies are enforced at the pod level, not the node level.
- Network policies are enforced at the cluster level, not the pod or node level.
Answer: C. Network policies are enforced at the pod level, not the node level.
In AKS, network policies are implemented using the Azure CNI (Container Networking Interface) or the kubenet model. When using Azure CNI, network policies are enforced at the pod level, meaning that traffic between pods is filtered based on the policies defined in the network policy manifest. This is different from some other Kubernetes distributions where policies may be applied at the node level. A common mistake is assuming that network policies are enforced at the node level, which can lead to incorrect configurations and unexpected behavior in the cluster.
What will happen when the AKS pod autoscaler is configured to scale based on CPU utilization metrics?
- The autoscaler will scale out the pod count based on CPU utilization metrics.
- The autoscaler will scale based on memory utilization metrics by default.
- The autoscaler will automatically adjust the number of nodes in the cluster.
- The autoscaler will use custom metrics for scaling without any configuration.
Answer: A. The autoscaler will scale out the pod count based on CPU utilization metrics.
The AKS pod autoscaler uses metrics such as CPU utilization to determine when to scale out or scale in the number of pods in a deployment. It is designed to maintain the desired level of performance and resource utilization based on the configured metrics. The autoscaler does not scale based on memory metrics by default, does not automatically adjust the number of nodes, and does not use custom metrics unless explicitly configured.
Which statement correctly describes the relationship and functionality between Azure Monitor and Log Analytics?
- Azure Monitor provides a broader set of monitoring capabilities, including metrics, logs, and application performance management, while Log Analytics focuses primarily on log data analysis.
- Log Analytics provides a broader set of monitoring capabilities, including metrics, logs, and application performance management, while Azure Monitor focuses primarily on log data analysis.
- Azure Monitor and Log Analytics are identical in functionality and purpose.
- Log Analytics is a component of Azure Monitor, but they serve entirely different purposes.
Answer: A. Azure Monitor provides a broader set of monitoring capabilities, including metrics, logs, and application performance management, while Log Analytics focuses primarily on log data analysis.
Azure Monitor is a comprehensive monitoring service that includes Log Analytics as one of its components. Log Analytics is specifically designed for querying and analyzing log data, whereas Azure Monitor covers a wider range of monitoring needs, such as metrics, logs, and application insights.
When integrating an Azure App Service with an Azure Application Gateway, what is a common mistake or tricky edge case that developers often overlook?
- The Application Gateway must be configured with a dedicated frontend IP and bound to the App Service's custom domain.
- The App Service can use the Application Gateway's default frontend IP without any changes.
- The Application Gateway can be integrated without configuring a custom domain.
- The App Service automatically detects and routes traffic through the Application Gateway without configuration.
Answer: A. The Application Gateway must be configured with a dedicated frontend IP and bound to the App Service's custom domain.
A common mistake when integrating an App Service with an Application Gateway is assuming that the gateway can automatically route traffic without proper configuration. The Application Gateway must have a dedicated frontend IP address and be properly bound to the App Service's custom domain to ensure correct traffic routing. Other options describe incorrect or incomplete configurations that would not resolve the integration issue.
In Azure DevOps, how are release gates typically configured to ensure quality checks or approvals before deployment?
- Release gates are configured in the pipeline using conditions based on approvals or automated tests.
- Release gates are part of the artifact feed's configuration and are not pipeline-specific.
- Release gates are defined in the deployment target's configuration settings.
- Release gates are automatically triggered by the deployment success status.
Answer: A. Release gates are configured in the pipeline using conditions based on approvals or automated tests.
Release gates in Azure DevOps are used to enforce quality checks or approvals before a deployment proceeds. They are configured as conditions within the pipeline, such as requiring approvals or passing automated tests. Other options refer to unrelated concepts or incorrect implementations.
Frequently asked questions
- How many questions are in the Intermediate Azure test?
- 30 questions (18 multiple choice, 12 multi-answer), with 35 minutes to answer them.
- What does the Intermediate Azure test cover?
- VNets and NSGs, App Service, AKS, Azure DevOps, Monitor and Log Analytics.
- Is the Intermediate Azure test free?
- Yes. It is free to take with a readyforhires account.
- What level is the Intermediate Azure test?
- Intermediate, in DevOps & cloud.