AZ-400 Practice Exam 2 — 20 Questions

Question 1

Your team uses a Git flow branching strategy with develop and release branches. You want to enforce that only release branches can be merged into main, and all merges into main require a successful deployment to a production-like environment. How should you implement this in Azure Pipelines?

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

Accepted Answer

YAML pipeline with environment approvals and branch filters on trigger. A YAML pipeline with environment approvals can require manual approval for deployment to a production-like environment, ensuring only successful deployments from a production-like environment allow merges. Branch filters on triggers can restrict pipeline execution to only release branches, preventing other branches from triggering the pipeline that leads to main. Option A is wrong because branch policies with required reviewers only enforce PR review requirements, not deployment or branch source restrictions. Option B is wrong because the 'Check for linked work items' status check ensures work items are linked but does not enforce branch restrictions or deployment validation. Option D is wrong because build validation runs on PR creation but does not enforce environment approvals or restrict the source branch to release branches only.

Answer

Branch policy with required reviewers for main

Answer

Required status check for 'Check for linked work items'

Answer

Build validation policy on main

Question 2

Your team uses GitHub Actions to build and deploy a Node.js application to Azure Functions. You need to implement a CI/CD pipeline that automatically deploys to a staging environment on every push to the main branch, and then promotes to production after a manual approval via GitHub Environments. The pipeline must also run unit tests and linting. You want to use the official Azure actions. What should you do?

Accepted Answer

Create a single GitHub Actions workflow with multiple jobs. Use a job for build and test, then a job for deploy to staging, and a job for deploy to production with an environment that requires approval.. Correct answer is C. A single GitHub Actions workflow can have multiple jobs: build and test, deploy to staging, and deploy to production. The production deployment job should use a GitHub Environment configured with required reviewers, enabling manual approval. Option A is incorrect because two separate workflows make it harder to share build artifacts and do not inherently use environment-based approvals for staging vs production. Option B is incorrect because GitHub Issues are not used for manual approvals; approvals are configured via GitHub Environments. Option D is incorrect because it uses Azure Pipelines, not GitHub Actions, which violates the requirement to use official Azure actions in GitHub Actions.

Answer

Create two separate workflows: one for CI (build, test, deploy staging) and one for CD (deploy production) that triggers manually.

Answer

Use a single workflow with a step that deploys to staging and then to production, using a condition to require manual approval via GitHub Issues.

Answer

Use Azure Pipelines with a multi-stage YAML pipeline that includes a stage for staging and a stage for production with pre-deployment approvals.

Question 3

You are designing a release pipeline for a multi-tenant SaaS application that is deployed to Azure App Service. Each tenant has its own App Service instance. The pipeline must deploy a new version of the application to a staging slot for each tenant, run smoke tests, and then swap the staging slot to production. You need to ensure that if the smoke tests fail for any tenant, the swap is not performed for that tenant, while other tenants continue. Which release pipeline configuration should you use?

Accepted Answer

Create a release with multiple jobs (one per tenant) in the same stage, each deploying to a tenant's staging slot, running tests, and conditionally swapping. Set the 'Run this job' condition to 'Only when all previous jobs have succeeded' or use custom conditions to skip swap on failure.. It uses separate jobs per tenant within a single stage, each with its own deployment, smoke test, and conditional swap. By setting the 'Run this job' condition to 'Only when all previous jobs have succeeded' or a custom condition, you ensure that a failed smoke test for one tenant blocks only that tenant's swap, while other tenants' jobs proceed independently. This design aligns with Azure Pipelines' job-level isolation, where each job runs on its own agent and can have independent success/failure conditions.

Answer

Create a single stage with a 'foreach' loop over tenants, and if smoke tests fail, skip the swap using a condition.

Answer

Create a single job with parallel tasks for each tenant, and configure failure conditions to skip the swap.

Answer

Create a single stage with multiple deployment tasks, one per tenant, and use a 'continue on error' option on each task.

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

Which THREE components are required to set up a self-hosted agent pool in Azure Pipelines?

Accepted Answer

The agent software installed on the target machine. The self-hosted agent requires the Azure Pipelines agent software to be installed on the target machine. This software, which includes the agent listener and worker processes, is what registers the machine with the agent pool and executes pipeline jobs. Without the agent software, the machine cannot communicate with Azure Pipelines or run any tasks.

Answer

A deployment group target

Answer

Azure VM extension for Azure Pipelines Agent

Question 7

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 8

Your release pipeline deploys a web app to Azure App Service. You need to implement safe deployment practices that minimize downtime and enable quick rollback. Which THREE strategies should you recommend?

Accepted Answer

Deploy to a staging slot first, validate, then swap.. Deploying to a staging slot first allows you to validate the application in a production-like environment without affecting live traffic. Once validated, swapping the staging and production slots ensures zero-downtime deployment by instantly routing all traffic to the validated version. This is a core safe deployment practice for Azure App Service.

Answer

Use rolling deployment with manual step to approve each instance.

Answer

Deploy directly to the production slot.

Question 9

Which TWO approaches can you use to enforce consistent commit message conventions across your GitHub repositories?

Accepted Answer

Use a GitHub Action to validate commit messages on push. GitHub Actions can be configured with a workflow that triggers on `push` events to validate commit messages against a regex pattern, rejecting non-conforming commits. Option D is correct because repository rulesets (or branch protection rules) allow you to define required commit message patterns that must match before a push is accepted, enforced server-side. Both approaches enforce conventions consistently across all contributors.

Answer

Add a .gitattributes file

Answer

Set the default branch to main

Answer

Set up an issue template

Question 10

You need to implement a build retention policy that automatically deletes old builds after 30 days, but keeps the latest 5 builds regardless of age. Which configuration should you use?

Accepted Answer

Set 'Days to keep builds' to 30 and 'Minimum number of builds to keep' to 5. In Azure Pipelines, the 'Days to keep builds' and 'Minimum number of builds to keep' settings work together to enforce a retention policy that deletes builds older than 30 days while ensuring that at least the latest 5 builds are retained, even if they exceed the age limit. This configuration directly matches the requirement to delete old builds after 30 days but keep the latest 5 builds regardless of age.

Answer

Set 'Number of days to keep runs' to 30 and 'Number of runs to keep' to 5

Answer

Set 'Maximum retention policy' to 30 days and 'Number of builds to retain' to 5

Answer

Set 'Number of days to keep artifacts' to 30 and 'Number of artifacts to keep' to 5

Question 11

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 12

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 13

You are designing a release pipeline for a mission-critical application that must achieve zero-downtime deployments to Azure App Service (Web App for Containers). The application uses Azure SQL Database with schema migrations. The current deployment slot strategy uses staging and production slots. You need to ensure that during a swap, the staging slot is warmed up and the database schema is rolled back if the swap fails. Which combination of deployment slots and pre/post-swap actions should you implement?

Accepted Answer

Use three slots: production, staging, and a new slot for the new version. Apply schema changes in the new slot, then swap new to staging, warm up staging, then swap staging to production. On failure, swap staging back to production.. It uses three slots to isolate schema changes in a new slot, then swaps to staging for warm-up, and finally swaps to production. If the swap fails, rolling back staging to production reverses the schema changes, ensuring zero-downtime. This approach aligns with Azure App Service slot-swap best practices for mission-critical applications requiring database rollback capability.

Answer

Use two slots (staging and production) with auto-swap enabled. The auto-swap handles warm-up automatically. If the swap fails, Azure automatically rolls back.

Answer

Use three slots: production, staging, and a new slot for the new version. Apply schema changes in the new slot, then swap new slot to staging, then staging to production. On failure, swap staging back to production.

Answer

Use two slots (staging and production). Apply schema changes in staging before swap. If swap fails, manually redeploy the old version to production.

Question 14

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 15

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 16

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 17

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 18

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 19

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 20

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