AZ-400 Practice Exam 55 — 20 Questions

Question 1

You are designing a build pipeline that uses Microsoft-hosted agents. The pipeline must build a .NET Framework 4.8 application and run on a Windows agent. Due to compliance, the build must use a specific version of Visual Studio that is not pre-installed on the Microsoft-hosted agents. What should you do?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Use a self-hosted agent that has the required version of Visual Studio installed.. To use a specific version of Visual Studio not pre-installed on Microsoft-hosted agents, you can either use a self-hosted agent with that version installed, or run the build in a Docker container that includes the required Visual Studio/Build Tools version. Microsoft-hosted agents have Docker installed and can run Windows containers, so option B is viable. Options C and D do not install a full Visual Studio version.

Answer

Specify the 'vsVersion' parameter in the MSBuild task to target the required version.

Answer

Use the 'Visual Studio Test Platform Installer' task to install the required version at build time.

Question 2

Which TWO conditions must be met to use multi-stage YAML pipelines with approvals?

Accepted Answer

An environment must be created and approval checks configured on it.. Multi-stage YAML pipelines in Azure DevOps require that an environment be created and approval checks configured on it to enable manual approvals. Additionally, the deployment job within the pipeline must reference a specific environment, as the approval check is associated with that environment resource. Without these two conditions, the pipeline cannot enforce approval gates before deployment.

Answer

The pipeline must be triggered by a pull request.

Answer

The pipeline must have at least one stage defined in a separate release pipeline.

Answer

The pipeline must be created using the classic release editor.

Question 3

You are designing a release pipeline for a critical application. The pipeline must automatically roll back to the previous version if the deployment to staging fails health checks. Which deployment strategy should you implement?

Accepted Answer

Rolling update with health checks and automatic rollback.. A rolling update with health checks and automatic rollback is the only strategy that fully automates the deployment, validates health after each batch of pods is updated, and automatically reverts to the previous version if health checks fail. This meets the requirement for an automated rollback on staging health check failure without manual intervention.

Answer

Canary deployment with manual promotion.

Answer

Blue-green deployment with manual swap.

Answer

Recreate deployment by redeploying the same version.

Question 4

Your team uses Azure Pipelines to deploy a microservices application to Azure Kubernetes Service (AKS). Each microservice has its own pipeline that builds a Docker image and deploys it to a shared AKS cluster. The deployment must support rolling updates with zero downtime. You need to ensure that if a deployment fails (e.g., health check fails), the pipeline automatically rolls back to the previous version. Which deployment strategy should you implement in the pipeline?

Accepted Answer

Use a rolling update strategy with the 'kubectl apply' command, and include a post-deployment step that checks the rollout status. If the rollout fails, run 'kubectl rollout undo' to roll back.. It directly implements the required behavior: using `kubectl apply` for a rolling update (which inherently supports zero-downtime by gradually replacing pods), followed by a post-deployment step that checks the rollout status. If the rollout fails (e.g., due to health check failures), the pipeline runs `kubectl rollout undo` to automatically revert to the previous version, ensuring rollback on failure.

Answer

Use a canary deployment strategy with a pipeline task that gradually shifts traffic to the new version and monitors error rates. If errors exceed a threshold, the task stops the canary.

Answer

Use the 'KubernetesManifest' task with the 'rollout status' option, which automatically rolls back if the rollout status indicates failure.

Answer

Use a blue-green deployment strategy with two separate AKS clusters. Deploy the new version to the green cluster, run health checks, and then update the load balancer to point to green. If health checks fail, keep pointing to blue.

Question 5

Your release pipeline deploys a .NET Core web app to Azure App Service using a slot swap strategy. The pipeline runs acceptance tests on the staging slot before swapping. After a recent change, the acceptance tests pass but the production site becomes unresponsive after the swap. What is the most likely cause?

Accepted Answer

The staging slot had different app settings that were swapped into production, causing the site to fail.. The most likely cause is that the staging slot had different app settings (e.g., connection strings, environment variables, or feature flags) that were swapped into production. During a slot swap, Azure App Service automatically moves all slot-specific configuration (app settings, connection strings, and other deployment slot settings) to the target slot. If the staging slot was configured with settings intended only for testing (like a staging database or debug mode), those settings would overwrite the production settings, causing the production site to become unresponsive. This is a common pitfall because acceptance tests may pass against the staging environment but fail when the same code runs with production configuration.

Answer

The acceptance tests are not comprehensive enough and missed a regression.

Answer

The acceptance tests should have been run after the swap.

Answer

The slot swap was not 'warm-up' and caused downtime.

Question 6

Refer to the exhibit. You are creating an ARM template to deploy an App Service and its Application Insights configuration. The template fails to deploy with error: 'The resource 'Microsoft.Insights/components/...' is not defined in the template.' What is the most likely cause?

Accepted Answer

The Application Insights component is not defined as a resource in the template.. The error 'The resource 'Microsoft.Insights/components/...' is not defined in the template' indicates that the ARM template references an Application Insights component (e.g., via the `reference()` function or a `dependsOn` property) that is not declared as a resource within the template's `resources` array. In ARM templates, every resource you reference must be explicitly defined; otherwise, the deployment engine cannot resolve it, causing this validation error.

Answer

The reference function cannot be used in a properties object.

Answer

The reference function syntax is incorrect.

Answer

The apiVersion for the config resource is outdated.

Question 7

Refer to the exhibit. You have this Azure Pipeline YAML. When you run the pipeline, it fails because the resource group name is not correctly resolved. What is the likely cause?

Accepted Answer

The variable 'resourceGroupName' uses $(environment) which cannot reference a parameter.. In Azure DevOps YAML pipelines, the `$()` syntax is used to reference runtime variables, not parameters. Parameters are defined using `parameters:` and are referenced with `${{ parameters.parameterName }}`. Using `$(environment)` attempts to resolve a variable named 'environment', but since 'environment' is defined as a parameter, it is not available as a variable at runtime, causing the resource group name to remain unresolved and the pipeline to fail.

Answer

The script type 'pscore' is not supported on Ubuntu.

Answer

Parameters cannot be used in YAML pipelines; they must be defined in a template.

Answer

The 'trigger: none' prevents the pipeline from running.

Question 8

Your development team uses GitHub Actions for CI/CD. You need to ensure that secrets stored in GitHub repository secrets are not exposed in build logs. What is the best practice?

Accepted Answer

Store secrets in GitHub repository secrets and reference them in workflows using ${{ secrets.SECRET_NAME }}. GitHub automatically masks secrets in logs.. GitHub automatically masks secrets referenced via the ${{ secrets.SECRET_NAME }} syntax in workflow logs. When a secret is used in a workflow, GitHub Actions scans the log output and replaces any occurrence of the secret value with '***', preventing exposure. This built-in mechanism is the recommended best practice as it requires no additional configuration and works across all steps and actions.

Answer

Use a custom action to manually mask secrets in the logs.

Answer

Define secrets as environment variables directly in the workflow YAML.

Answer

After the workflow runs, delete the logs from GitHub.

Question 9

Your organization uses Azure Pipelines and wants to enforce that all builds must pass a security scan before being deployed to production. The security scan is performed by a third-party tool that is not available as a built-in task. You have installed the tool on a self-hosted agent. What is the best way to integrate the security scan into the pipeline?

Accepted Answer

Use a command-line task (e.g., Bash, PowerShell) to execute the security scan tool.. The security scan tool is installed on a self-hosted agent but not available as a built-in task or marketplace extension. Using a command-line task (Bash or PowerShell) allows you to directly invoke the tool's executable from the agent's file system, passing necessary parameters and capturing exit codes to determine success or failure. This approach integrates seamlessly with Azure Pipelines' standard task execution model without requiring custom extensions or external service hooks.

Answer

Add the tool as a capability of the agent pool and use the 'Install Tool' task.

Answer

Add the 'Run Security Scan' task from the Azure DevOps marketplace.

Answer

Create a custom service hook to trigger the scan externally and wait for results.

Question 10

You are designing a release pipeline for a critical production application. The pipeline must ensure that changes are deployed to a staging environment first, and if integration tests pass, they are automatically deployed to production. However, if the tests fail, the deployment to production must be blocked. What is the best approach?

Accepted Answer

Create a multi-stage YAML pipeline with a gate on the production stage that evaluates test results from the staging stage.. A multi-stage YAML pipeline with a gate on the production stage allows you to evaluate the results of integration tests run in the staging stage before proceeding to production. The gate can be configured to check for test pass/fail status from the staging stage, blocking the production deployment if tests fail. This approach provides a clear, automated approval flow within a single pipeline definition, aligning with the requirement for conditional promotion based on test results.

Answer

Create a single stage in the pipeline with conditional tasks to deploy to staging and then to production based on test results.

Answer

Create two separate pipelines: one for staging and one for production. Use a pipeline trigger to run the production pipeline after staging completes.

Answer

Use a classic release pipeline with pre-deployment approvals on the production stage.

Question 11

Which TWO are benefits of using deployment groups in Azure Pipelines compared to using individual virtual machines?

Accepted Answer

Simplified targeting of multiple machines with a single pipeline run.. Deployment groups in Azure Pipelines allow you to target multiple machines with a single pipeline run by logically grouping them, enabling parallel or rolling deployments across all machines in the group. This simplifies management compared to configuring each individual VM separately in the pipeline, as you can define the group once and reuse it across releases.

Answer

Built-in secrets management for connection strings.

Answer

Reduced cost because VMs are shut down when not in use.

Answer

Automatic scaling of virtual machines based on load.

Question 12

You have a pipeline that builds a Docker image and pushes it to Azure Container Registry. You need to ensure that only the latest successful build image is tagged as 'latest'. Which tagging strategy should you use?

Accepted Answer

Use a conditional step that runs only when the build succeeds to tag the image as 'latest'. It ensures the 'latest' tag is applied only after a successful build, preventing broken or incomplete images from being tagged as 'latest'. In Azure Pipelines, you can use a condition like `condition: succeeded()` on a script or Docker task that runs `docker tag` and `docker push` to update the 'latest' tag only when the preceding build steps succeed. This maintains a reliable 'latest' pointer to the most recent stable image.

Answer

Use the build ID as the tag and manually update 'latest'

Answer

Use the Git commit hash as the tag and push 'latest' separately

Answer

Always tag the image as 'latest' regardless of build status

Question 13

Your team uses Microsoft Defender for Cloud to monitor Azure resources. You need to ensure that all Azure DevOps pipelines are scanned for security misconfigurations before deployment. Which integration should you enable?

Accepted Answer

Enable the 'Defender for DevOps' integration in Microsoft Defender for Cloud.. Microsoft Defender for Cloud includes a 'Defender for DevOps' integration that allows you to connect Azure DevOps environments and scan pipelines for security misconfigurations, such as Infrastructure as Code (IaC) template issues or exposed secrets, before deployment. This integration provides built-in security posture assessments and actionable recommendations directly within the Defender for Cloud dashboard, enabling shift-left security practices.

Answer

Connect Azure DevOps to Microsoft Sentinel.

Answer

Deploy Microsoft Intune policies to Azure DevOps agents.

Answer

Configure Microsoft Purview to scan Azure DevOps repositories.

Question 14

Your team is using GitHub Enterprise and wants to ensure that every pull request includes a link to a work item in Azure Boards. Which GitHub Apps or Azure DevOps Services integration should you configure?

Accepted Answer

GitHub-Azure Boards integration. The GitHub-Azure Boards integration is the correct choice because it connects GitHub repositories to Azure Boards, automatically linking commits and pull requests to work items when they mention an Azure Boards ID (e.g., 'AB#1234'). However, it does not enforce that every PR must include such a link. To enforce this, you would need an additional validation tool or branch protection rule, but among the given options, this is the only integration that provides the linking capability.

Answer

Azure Repos branch policy

Answer

Azure DevOps OAuth app

Answer

Azure Pipelines GitHub App

Question 15

You receive a webhook notification from Azure Pipelines with the above payload. The build for the 'feature/logging' branch failed. You want to automatically create a work item to track the fix. What should you configure in Azure DevOps?

Accepted Answer

Enable the 'Create work item on failure' option in the pipeline settings.. Azure Pipelines provides a built-in setting called 'Create work item on failure' that automatically generates a work item (e.g., a bug or task) in Azure Boards whenever a pipeline run fails. This directly meets the requirement to track the fix for the failed build on the 'feature/logging' branch without requiring external integrations or manual steps.

Answer

Add a branch policy on 'feature/logging' to require a successful build before merging.

Answer

Use a GitHub Actions workflow to create an issue on failure.

Answer

Create a service hook subscription to listen for build failures and call Azure Boards API.

Question 16

Your release pipeline deploys to multiple environments sequentially. The deployment to production fails intermittently due to a database schema migration issue. You need to implement a strategy that automatically rolls back the deployment if the migration fails. What should you do?

Accepted Answer

Add a post-deployment script that runs a rollback script on failure.. It directly addresses the requirement to automatically roll back the deployment when a database schema migration fails. By adding a post-deployment script that runs a rollback script on failure, you can execute custom logic (e.g., reverting schema changes using SQL scripts or tools like Entity Framework migrations) immediately after the deployment step detects an error. This approach provides fine-grained control over the rollback process, which is essential for database migrations that cannot be handled by Azure Pipelines' built-in auto-rollback feature, which only reverts the application deployment (e.g., swapping slots or restoring files) and does not execute custom rollback scripts.

Answer

Enable 'Auto-rollback' in the release pipeline settings.

Answer

Use a multi-stage YAML pipeline with manual intervention.

Answer

Configure pre-deployment approval gates.

Question 17

You are a DevOps engineer for a large enterprise that uses GitHub Enterprise Cloud. The development team follows a GitFlow branching strategy with develop, feature, release, and main branches. The release branch is created from develop when a release is ready. After testing, the release branch is merged into main and then tagged. However, the team frequently forgets to merge release branches back into develop, causing hotfixes applied to main to not be in develop. You need to implement an automated process to ensure that after a release branch is merged into main, the changes are also merged back into develop. The solution must not require manual intervention and must handle merge conflicts gracefully by opening a pull request for conflict resolution. Which approach should you use?

Accepted Answer

Create a GitHub Actions workflow that triggers on push to main, attempts to merge main into develop, and if conflicts occur, opens a pull request for manual resolution.. It uses a GitHub Actions workflow triggered on pushes to main to automatically merge main into develop. If conflicts arise, the workflow opens a pull request for manual resolution, ensuring no changes are lost and the process remains automated without manual intervention.

Answer

Configure a branch protection rule on main that requires a pull request to merge into develop.

Answer

Create a scheduled workflow that runs daily and merges main into develop if there are no conflicts.

Answer

Set up a webhook in GitHub that calls an Azure Function to merge main into develop.

Question 18

An organization uses an on-premises Jenkins server to build Docker images and push them to Azure Container Registry (ACR). The security team requires that all images be scanned for vulnerabilities before deployment. The DevOps team needs to automate this scanning after each push. What is the most efficient way to meet this requirement?

Accepted Answer

Create an ACR task that runs a vulnerability scanner triggered by image push events.. ACR Tasks natively support automated vulnerability scanning via integration with Azure Security Center or third-party scanners like Trivy. By creating an ACR task that triggers on image push events, the organization can scan images immediately after they are pushed without additional infrastructure or manual intervention. This approach is event-driven, serverless, and aligns with the requirement to automate scanning after each push.

Answer

Use Azure Policy to enforce vulnerability scanning.

Answer

Configure a Jenkins job to scan images before pushing to ACR.

Answer

Configure a webhook in ACR to notify Jenkins to scan the image.

Question 19

You have deployed an Azure Resource Manager (ARM) template for a scheduled query rule as shown. The rule is enabled and targets an Application Insights resource. However, no alerts are firing despite HTTP 500 errors occurring. What is the most likely cause?

Accepted Answer

The threshold of 100 is too high; the rule should use a percentage-based condition on error rate.. The threshold of 100 is an absolute count, not a percentage. HTTP 500 errors may occur sporadically, but unless they reach 100 within the evaluation window, the alert will not fire. For error-rate monitoring, a percentage-based condition (e.g., >5% of total requests) is more appropriate to detect anomalies even with lower traffic volumes.

Answer

The severity is set to 2, which suppresses the alert.

Answer

The metric name 'requests/count' is misspelled; it should be 'requests/count' (correct).

Answer

The dimension filter for 'request/resultCode' includes '500' but should also include '5xx' wildcard.

Question 20

Your team uses GitHub and wants to automatically label pull requests based on the content of the changes (e.g., 'frontend' for changes in /frontend folder, 'backend' for /backend). Which approach should you use?

Accepted Answer

Create a GitHub Actions workflow that runs on pull_request events and uses an action like 'actions/labeler' to add labels based on path patterns.. GitHub Actions provides a native, event-driven way to automate labeling based on pull request changes. The 'actions/labeler' action specifically inspects file paths in the diff and applies labels defined in a configuration file, making it the simplest and most maintainable solution for path-based labeling.

Answer

Use branch protection rules to require specific labels based on branch name patterns.

Answer

Set up a webhook that triggers an Azure Function to parse the pull request diff and add labels.

Answer

Use a CODEOWNERS file to assign labels based on file paths.