AZ-400 Practice Exam 2 — 20 Questions

Question 1

A team uses a monorepo in Azure Repos. They want to implement a build validation policy that only triggers builds for code changes in specific folders to reduce build times. Which approach should they use?

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

Accepted Answer

Configure the build policy in Azure Repos with a path filter to limit which folders trigger the policy.. Azure Repos build validation policies allow you to specify path filters when configuring the policy. These path filters restrict when the policy requires a build, based on the files changed in the pull request. By setting the path filter to the specific folders of interest, the build validation only triggers for changes in those folders, directly reducing build times for unrelated changes. Pipeline trigger path filters (Option D) control CI builds on push, not the build validation policy for pull requests.

Answer

Use a manual trigger and have developers specify which folder to build.

Answer

Create separate YAML pipelines for each folder and configure branch policies to require all pipelines.

Answer

Configure path filters in the pipeline trigger to include only the changed folder.

Question 2

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 3

Your organization uses GitHub for source control and GitHub Actions for CI/CD. You need to implement a branching strategy where every commit to the main branch triggers a build and deployment to a staging environment, but only after a successful pull request review. Which GitHub Actions trigger should you use?

Accepted Answer

push with branches: [main]. The `push` trigger with `branches: [main]` runs on every commit pushed to main. When branch protection requires pull request reviews, commits only reach main through a reviewed and merged PR, so this satisfies the 'only after successful pull request review' condition. In contrast, `pull_request_target` with `types: [closed]` triggers for any closed PR, including those not merged, and does not map one-to-one to commits on main. To use a PR event, you would need an additional condition like `if: github.event.pull_request.merged == true`, which is not mentioned.

Answer

pull_request_target with branches: [main] and types: [closed]

Answer

pull_request with branches: [main]

Answer

workflow_dispatch

Question 4

Which THREE conditions must be met for you to use the 'Approvals' feature in Azure Pipelines to control deployments to a production environment? (Choose three.)

Accepted Answer

The approver must have the 'Approve pipeline permissions' permission for the environment.. The 'Approvals' feature in Azure Pipelines requires an environment to be defined in the pipeline. You must add an approval check to that environment, which can be done in either a classic release pipeline or a YAML pipeline that references the environment as a resource. Additionally, the approver(s) - whether individual users or groups - must have the 'Approve pipeline permissions' permission on that environment. Without an environment resource, the approval check cannot be configured; without the permission, approval requests cannot be validated.

Answer

The approver must be an individual user, not a group.

Answer

The approval must be configured in the release pipeline's pre-deployment conditions.

Question 5

Your organization uses GitHub and wants to implement a monorepo strategy for multiple related projects. Which approach best optimizes CI/CD pipeline performance by only building projects that have changed?

Accepted Answer

Use path filters in GitHub Actions workflows. GitHub Actions path filters (using `on.push.paths` or `on.pull_request.paths`) allow you to trigger workflows only when changes are made to specific directories or files. In a monorepo, this ensures that CI/CD pipelines run exclusively for the projects that have been modified, avoiding unnecessary builds and significantly improving performance.

Answer

Use a single workflow that builds all projects on every push

Answer

Use submodules to separate projects

Answer

Use workflow templates and composite actions

Question 6

Your team uses Azure Repos for source control. You need to enforce that all builds must pass unit tests before code can be merged into the main branch. Which branch policy should you configure?

Accepted Answer

Add a build validation policy that triggers the CI pipeline and requires it to succeed.. Azure Repos branch policies allow you to add a build validation policy that triggers a CI pipeline (e.g., a YAML or classic build pipeline) and requires it to succeed before a pull request can be completed. This ensures that all code merged into the main branch has passed unit tests, enforcing quality gates directly in the PR workflow.

Answer

Require a linked work item.

Answer

Require a minimum number of reviewers.

Answer

Require comment resolution.

Question 7

Drag and drop the steps to perform a blue-green deployment in Azure using App Service slots into the correct order.

Accepted Answer

1. Create a staging slot, 2. Deploy the application to the staging slot, 3. Validate the staging slot, 4. Swap the staging slot to production, 5. Monitor the production slot. Blue-green deployment involves creating a slot, deploying to it, validating, swapping, and monitoring.

Answer

1. Deploy the application to the staging slot, 2. Create a staging slot, 3. Validate the staging slot, 4. Swap the staging slot to production, 5. Monitor the production slot

Answer

1. Create a staging slot, 2. Deploy the application to the staging slot, 3. Swap the staging slot to production, 4. Validate the staging slot, 5. Monitor the production slot

Answer

1. Create a staging slot, 2. Deploy the application to the staging slot, 3. Validate the staging slot, 4. Monitor the production slot, 5. Swap the staging slot to production

Question 8

Refer to the exhibit. A build pipeline uses this trigger configuration. A developer pushes a commit to the 'main' branch that modifies files in '/src/app/' and '/src/tests/'. How many builds will be triggered?

Accepted Answer

1 build, because batchChanges is true.. The trigger configuration has `batchChanges` set to `true`. When `batchChanges` is enabled, Azure Pipelines groups all commits that arrive while a build is in progress into a single build, rather than triggering a separate build for each commit. In this scenario, the developer pushes a single commit that modifies files in both `/src/app/` and `/src/tests/`. Since `batchChanges` is true, only one build is triggered for that commit, regardless of the number of modified folders.

Answer

0 builds, because the excluded path takes precedence.

Answer

3 builds, because maxConcurrentBuildsPerBranch is 1 but batchChanges overrides.

Answer

2 builds, one for each modified folder.

Question 9

A company uses Azure Pipelines to build a .NET Core application. The build takes 45 minutes due to dependency restoration. They want to reduce build time. What is the most effective strategy?

Accepted Answer

Cache the NuGet packages and enable caching in the pipeline. Caching NuGet packages in Azure Pipelines is the most effective strategy because dependency restoration is the primary bottleneck, often downloading hundreds of packages from nuget.org. By caching the ~/.nuget/packages folder, subsequent builds skip the network download entirely, reducing the 45-minute build time to minutes. This directly addresses the root cause—repetitive package restoration—without requiring additional infrastructure or parallelism.

Answer

Use parallel jobs in the pipeline

Answer

Use a self-hosted agent with more CPU

Answer

Enable incremental builds

Question 10

Your organization uses Azure DevOps to manage CI/CD pipelines. The security team requires that all pipeline runs use a specific service connection that references a managed identity in Microsoft Entra ID. However, some developers have been using personal access tokens (PATs) in their pipelines, bypassing the managed identity. What should you implement to enforce the use of the managed identity service connection?

Accepted Answer

Use a pipeline decorator to validate the service connection and fail the pipeline if an unauthorized connection is used.. Pipeline decorators allow you to inject custom validation steps into every pipeline run at the organization or project level. By using a decorator that checks the service connection ID used in each job and fails the run if it does not match the approved managed identity connection, you can enforce compliance without relying on developer cooperation or manual policy configuration.

Answer

Configure a branch policy on the main branch to require a specific service connection.

Answer

Restrict the use of PATs by setting an agent pool-level permission.

Answer

Store the service connection ID in a variable group and reference it in each pipeline.

Question 11

Your Azure DevOps pipeline uses a YAML template to avoid duplication. The template defines common build steps. You need to override one of the steps in a specific pipeline without modifying the template. Which approach should you use?

Accepted Answer

Use template parameters with a 'steps' object that can be injected to override the step.. Azure DevOps YAML templates support parameterized steps objects. By defining a template parameter of type 'steps' with a default value, the calling pipeline can pass a custom steps object as an argument to that parameter, effectively overriding the default steps without modifying the template. No 'replace' keyword is used; the override is achieved by directly injecting the steps object via the parameter.

Answer

Use the 'overrides' keyword in the pipeline YAML to specify which steps to replace.

Answer

Create a copy of the template and modify the step directly.

Answer

Use a conditional 'if' statement in the template to skip steps based on a parameter.

Question 12

Refer to the exhibit. A release is created with the above command. The Dev environment starts deploying, but the Prod environment does not. Which is the most likely reason?

Accepted Answer

The Prod environment has a pre-deployment condition that waits for the Dev environment to succeed.. The exhibit shows a release pipeline with a sequential deployment strategy where the Prod environment has a pre-deployment condition configured to wait for the Dev environment to succeed. In Azure DevOps, pre-deployment conditions can be set to trigger only after a specific environment (like Dev) completes successfully. Since the Dev environment is still deploying, the Prod environment remains in a waiting state and does not start.

Answer

The Prod environment requires manual approval before deployment.

Answer

The release definition ID 5 is incorrect.

Answer

The build artifact with ID 123 is not accessible.

Question 13

The pipeline fails because the artifact is empty. What is the most likely cause?

Accepted Answer

The build output is not copied to the staging directory. The most common reason for an empty artifact in Azure Pipelines is that the build output files were not copied to the staging directory (typically $(Build.ArtifactStagingDirectory)) before the PublishBuildArtifacts task runs. The PublishBuildArtifacts task publishes whatever is in the staging directory; if no files are copied there, the artifact will be empty. This is a standard pattern where a Copy Files task or similar step must explicitly place the build outputs into the staging directory.

Answer

The projects pattern '**/*.csproj' does not match any files

Answer

The task 'PublishBuildArtifacts@1' is misspelled

Answer

The artifact name 'drop' is invalid

Question 14

Your company is a startup developing a mobile application with a small team of 5 developers. You use GitHub Free and want to implement a simple but effective branching strategy that supports continuous delivery. The team wants to release new features every week and be able to hotfix critical bugs quickly. They currently have a main branch and feature branches, but sometimes features are merged to main before they are fully tested, causing issues. You need to recommend a strategy that minimizes risk while keeping the process lightweight. The team does not want to use long-lived branches. What should you recommend?

Accepted Answer

Use GitHub Flow: developers create feature branches from main, open pull requests with required CI and at least one review, then merge to main. Hotfixes follow the same process.. GitHub Flow is the simplest and most effective strategy for a small team using GitHub Free that wants continuous delivery without long-lived branches. By requiring feature branches, pull requests with CI checks, and at least one review before merging to main, it ensures that all code is tested and reviewed before integration, preventing untested features from breaking main. Hotfixes follow the same lightweight process, allowing quick, safe patches without additional branch overhead.

Answer

Use a single main branch and create release branches for each weekly release; features are merged to release branches, then release branches are merged to main after testing.

Answer

Allow developers to commit directly to main but require all commits to pass CI and be reviewed by at least one other developer after the fact.

Answer

Adopt GitFlow with develop and release branches.

Question 15

You are the DevOps lead for a financial services company. The company uses Azure DevOps Services with a single project containing multiple teams. The compliance team requires that all production deployments be approved by a change advisory board (CAB) member. Additionally, any deployment that changes a configuration value stored in Azure App Configuration must be audited. You have set up a release pipeline with a manual approval gate and a pre-deployment condition that runs a PowerShell script to validate configuration changes. However, the compliance team reports that some deployments bypassed the approval gate. Upon investigation, you find that developers with 'Edit release pipeline' permissions can modify the pipeline and remove the approval gate. You need to ensure that the approval gate cannot be bypassed by developers. You also need to ensure that any change to a configuration key is logged to Azure Monitor. What should you do?

Accepted Answer

Create a protected variable group that stores the approval gate configuration and set the pipeline to use it. Restrict edit permissions on the release pipeline to a security group that does not include developers. For configuration changes, use an Azure Resource Manager template with a deployment script that sends logs to Azure Monitor.. It addresses both requirements: restricting pipeline edit permissions to a security group that excludes developers prevents them from removing the approval gate, and using an ARM template with a deployment script that sends logs to Azure Monitor ensures configuration changes are audited. Protected variable groups secure sensitive configuration, but the key is permission separation and audit logging via ARM deployment scripts.

Answer

Create a new service connection with limited permissions and require that all pipeline runs use it. Use an Azure Policy to audit configuration changes.

Answer

Configure environment-level approvals in the release pipeline and use Azure Policy to enforce that all deployments go through the environment. Use diagnostic settings on App Configuration to stream logs to Azure Monitor.

Answer

Implement a branch policy on the release pipeline's YAML file in the repository to require approval for changes. Use a webhook to send configuration change events to Azure Monitor.

Question 16

Refer to the exhibit. The workflow runs successfully but the deployment fails because the Azure CLI is not authenticated. What should you add to the workflow to authenticate?

Accepted Answer

Add the 'azure/login' action with Azure credentials. The Azure CLI in the workflow requires authentication to interact with Azure resources. Adding the 'azure/login' action with valid Azure credentials (e.g., service principal secrets or OpenID Connect) establishes the necessary authentication context before any Azure CLI commands are executed, resolving the 'not authenticated' error.

Answer

Add the 'actions/setup-node' action

Answer

Add the 'azure/webapps-deploy' action

Answer

Add the 'actions/github-script' action to use the GitHub token

Question 17

You are designing a communication strategy for your DevOps team. They use Microsoft Teams for collaboration. You need to automatically notify the team when a release to production fails. Which Azure DevOps integration should you use?

Accepted Answer

Configure a notification subscription in Azure DevOps to send a Teams webhook. Azure DevOps notification subscriptions can be configured to send alerts to a Teams channel via an incoming webhook. This allows automatic, real-time notifications to the DevOps team when a release to production fails, directly within their collaboration platform.

Answer

Set up an email subscription to the DevOps team

Answer

Create a service hook to call a custom API

Answer

Publish a Wiki page with deployment status

Question 18

Your team uses Git for source control. A developer accidentally committed a large binary file (500 MB) to the main branch. The push succeeded but other team members are now complaining about slow fetch times. What is the most efficient way to remove the file from the repository history?

Accepted Answer

Use 'git filter-repo' to remove the file from history. 'git filter-repo' is the recommended modern tool for permanently removing large files from Git history. It rewrites the repository's commit graph, eliminating the file from all commits, which reduces repository size and resolves slow fetch times for team members. Unlike BFG Repo-Cleaner, 'git filter-repo' is actively maintained and integrates natively with Git, making it the most efficient and reliable choice for this task.

Answer

Add the file to .gitignore and push again

Answer

Use 'git revert' to undo the commit

Answer

Use BFG Repo-Cleaner

Question 19

You have a YAML pipeline that builds a Docker image and pushes it to Azure Container Registry (ACR). You need to dynamically set the image tag based on the build number. Which predefined variable should you use?

Accepted Answer

$(Build.BuildNumber). The `$(Build.BuildNumber)` variable represents the build number, which is the name of the completed build. It's often customized to include versioning information, and it's the appropriate variable to use when tagging Docker images based on the build number. `$(Build.BuildId)` is a unique numeric ID for the build record, but it is not the build number.

Answer

$(System.JobId)

Answer

$(System.TeamProject)

Answer

$(Build.BuildId)

Question 20

Your organization uses GitHub Actions and needs to enforce that all workflows pass required checks before a pull request can be merged. Which GitHub feature should you configure?

Accepted Answer

Branch protection rules with required status checks. Branch protection rules with required status checks enforce that all configured GitHub Actions workflows must pass before a pull request can be merged. This ensures that any workflow defined in the repository (e.g., CI, linting, security scans) produces a successful check run, and the merge is blocked if any required check fails or is pending.

Answer

Workflow triggers

Answer

Required reviewers

Answer

Environment protection rules