Microsoft Azure DevOps Engineer Expert AZ-400 AZ-400 Questions 151–225 | Page 3/10

151

MCQeasy

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?

A.Use a conditional step that runs only when the build succeeds to tag the image as 'latest'

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

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

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

AnswerA

This approach guarantees that the 'latest' tag is only moved after a fully successful build, using a condition such as `condition: succeeded()` to run a docker tag/push step. It ensures the image referenced by 'latest' is always a known-good artifact, avoiding the risk of tagging broken builds.

Why this answer

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.

Exam trap

The trap here is that candidates may assume any tagging strategy that includes 'latest' is sufficient, overlooking the critical requirement that the tag must only be applied to successful builds, which is enforced by a conditional step.

How to eliminate wrong answers

Option B is wrong because manually updating the 'latest' tag introduces human error and operational overhead, and it does not automate the process to ensure only successful builds are tagged. Option C is wrong because using the Git commit hash as the tag is a valid strategy for traceability, but pushing 'latest' separately without a conditional check on build success could result in tagging a failed build as 'latest'. Option D is wrong because always tagging the image as 'latest' regardless of build status would overwrite the 'latest' tag with a broken or incomplete image, breaking downstream consumers that rely on 'latest' being a stable reference.

Full explanation →

152

Multi-Selecthard

A company uses Azure Monitor and Application Insights to monitor a microservices application deployed on Azure Kubernetes Service (AKS). The development team wants to implement distributed tracing to correlate requests across services. They currently have Application Insights SDKs instrumented in each service. Which TWO configurations are required to enable end-to-end distributed tracing?

Select 2 answers

A.Enable the Live Metrics Stream feature in Application Insights.

B.Ensure all services use the same Application Insights instrumentation key or connection string.

C.Configure adaptive sampling in the Application Insights SDK.

D.Ensure the SDKs are configured to propagate correlation headers (e.g., W3C Trace-Context).

E.Enable Application Map in the Azure portal for each service.

AnswersB, D

For distributed tracing, all services must send telemetry to the same Application Insights resource by using the same instrumentation key or connection string. This ensures that the operation IDs and parent IDs emitted by each service are stored in one logical table, allowing the trace to be stitched together across service boundaries. Using different keys on different services scatters telemetry into separate resources, making it impossible to correlate a request end-to-end even if trace-context headers are present. This is a necessary prerequisite, though not sufficient on its own.

Why this answer

All services must share the same Application Insights instrumentation key or connection string to ensure that telemetry from different microservices is correlated into a single application map and trace. Without a common instrumentation key, the distributed trace data would be siloed across separate Application Insights resources, preventing end-to-end correlation.

Exam trap

The trap here is that candidates often confuse enabling Application Map (a visualization) with the actual configuration needed for correlation, or they think adaptive sampling is required for tracing, when in fact the key requirements are a shared instrumentation key and header propagation.

Full explanation →

153

MCQhard

You are configuring a multi-stage YAML pipeline in Azure Pipelines. The pipeline has stages for Build, Test, and Deploy. You need to ensure that the Deploy stage runs only if the Build and Test stages succeed, and that it uses a specific environment named 'Production' with an approval check. What should you do?

A.Add a dependsOn condition to the Deploy stage for Build and Test, and configure the environment 'Production' with an approval check.

B.Add a dependsOn condition to the Deploy stage for Build and Test, and use a manual approval task in the stage.

C.Use a condition on the Deploy stage to check the status of previous stages, and add an approval gate in the release pipeline.

D.Set the Deploy stage to run always, and use a manual intervention task before deployment.

AnswerA

Using dependsOn on the Deploy stage ensures it runs only after Build and Test succeed. Configuring the 'Production' environment with an approval check enforces manual approval before deployment. This combination meets both requirements: conditional execution and approval.

Why this answer

In YAML pipelines, stage dependencies are defined with dependsOn, and approvals are configured on environments. The Deploy stage should depend on Build and Test, and the Production environment should have an approval check. This ensures the stage runs only after successful prior stages and requires approval.

Exam trap

The trap here is confusing YAML pipeline approvals with classic release pipeline approval gates, or thinking that a manual intervention task can be used in YAML for approvals.

Full explanation →

154

Multi-Selectmedium

Which TWO actions should you take to protect sensitive information (e.g., API keys, passwords) in Azure Pipelines? (Choose two.)

Select 2 answers

A.Store secrets in environment variables on the agent machine.

B.Define secrets as pipeline secret variables and reference them as $(secretName).

C.Store secrets in a YAML file and include the file in the repository.

D.Use plain text variables in the pipeline and mask them using the 'Logging Command' feature.

E.Use Azure Key Vault to store secrets and reference them via variable groups linked to Key Vault.

AnswersB, E

Pipeline secret variables are encrypted at rest by Azure DevOps and are masked in pipeline logs when referenced as $(secretName). Only tasks that explicitly reference the variable receive its value, and it is never exposed in the pipeline definition or logs, making this a secure method.

Why this answer

Azure Pipelines allows you to define secret variables in the pipeline UI or YAML, which are encrypted at rest and never exposed in logs. Referencing them as $(secretName) ensures they are securely injected at runtime without being stored in plaintext. Option E is correct because Azure Key Vault provides a centralized, audited, and encrypted store for secrets, and variable groups linked to Key Vault allow pipelines to fetch secrets dynamically without embedding them in pipeline definitions.

Exam trap

The trap here is that candidates may think masking secrets in logs (Option D) is sufficient, but masking does not protect the secret from being stored in plaintext in the pipeline definition or from being exposed in other output channels.

Full explanation →

155

Multi-Selecteasy

Which THREE are valid ways to trigger a pipeline in Azure Pipelines? (Choose three.)

Select 3 answers

A.Schedule trigger

B.Pull request (PR) trigger

C.Continuous integration (CI) trigger

D.'on: push' trigger in YAML

E.Commit trigger

AnswersA, B, C

A schedule trigger runs the pipeline automatically at defined cron times, satisfying the requirement for a valid pipeline trigger. It is configured via the trigger's schedules block in YAML, distinct from CI, PR, or pipeline-completion triggers.

Why this answer

A is correct because Azure Pipelines supports scheduled triggers via the `schedules` block in YAML (or the Triggers UI), which runs the pipeline on a cron-based timetable. B is correct because PR triggers (`pr:` in YAML) cause the pipeline to run when a pull request is opened or updated against specified branches, typically for validation builds. C is correct because CI triggers (`trigger:` in YAML) run the pipeline automatically whenever code is pushed to the included branches, which is the standard continuous integration mechanism.

D is not a valid Azure Pipelines trigger; `on: push` is GitHub Actions syntax, not Azure Pipelines YAML. E is not a valid trigger type in Azure Pipelines; commits are picked up through CI triggers, not a separate 'commit trigger' construct.

Exam trap

Do not confuse Azure Pipelines trigger syntax with other CI systems. Azure Pipelines supports CI triggers, PR triggers, and scheduled triggers as first-class trigger types.

Full explanation →

156

MCQhard

Your pipeline builds a .NET application and runs unit tests. You notice that the pipeline takes too long because it restores NuGet packages on every run. You want to cache the NuGet packages to speed up subsequent builds. Which task should you use?

A.NuGetCommand@2 with the restore command

B.CopyFiles@2

C.PowerShell@2 to manually download and cache

D.Cache@2 (CacheBeta)

AnswerD

The Cache@2 task (formerly CacheBeta) is Azure DevOps' built-in caching solution; it restores a folder from a cache key, and if there is a miss, it saves the folder after the job completes. For a .NET application, you can cache the ~/.nuget/packages directory (NuGet package cache) to speed up subsequent restores, so it is the correct answer.

Why this answer

The Cache@2 (CacheBeta) task is specifically designed to cache folders or files between pipeline runs, such as NuGet packages, to reduce restore time. By caching the NuGet packages folder (e.g., $(UserProfile)/.nuget/packages), subsequent builds can skip the full restore and reuse previously downloaded packages, significantly speeding up the pipeline.

Exam trap

The trap here is that candidates often choose NuGetCommand@2 (Option A) thinking it inherently caches packages, but it only restores from remote sources each time unless combined with a separate caching task.

How to eliminate wrong answers

Option A is wrong because NuGetCommand@2 with the restore command only restores packages from sources; it does not cache them across pipeline runs. Option B is wrong because CopyFiles@2 is used to copy files from source to destination, not to manage caching of NuGet packages. Option C is wrong because PowerShell@2 can manually download and cache packages, but it requires custom scripting and lacks the built-in cache key, restore keys, and automatic hit/miss handling that Cache@2 provides, making it error-prone and less efficient.

Full explanation →

157

MCQmedium

Your release pipeline deploys to multiple Azure regions. You need to ensure that if a deployment to one region fails, the pipeline continues deploying to other regions. Which deployment strategy should you use?

A.Immutable deployment

B.Rolling deployment

C.Blue-green deployment

D.Canary deployment

AnswerB

Rolling deployment replaces instances incrementally across regions, keeping the previous version running in unaffected instances; if a region's batch fails health checks, Azure DevOps can stop that batch while other regions continue receiving updates, thereby tolerating regional failures and meeting the requirement to keep deploying.

Why this answer

Rolling deployment updates instances gradually across regions. If a deployment to one region fails, the pipeline can continue deploying to other regions because each region is updated independently. Option A (immutable deployment) replaces all instances at once, so a failure would halt the entire deployment.

Option C (blue-green) switches all traffic to a new environment; if that environment fails, the whole deployment fails. Option D (canary) routes a small percentage of traffic to a new version and rolls back if issues occur, but it does not ensure continued deployment to other regions upon failure.

Full explanation →

158

MCQeasy

Your organization uses GitHub Actions for CI/CD. You need to ensure that secrets are securely passed to workflows without being exposed in logs. What should you use?

A.GitHub Secrets

B.Environment variables in the workflow YAML

C.Hardcode the secrets in the workflow file

D.Azure Key Vault with Azure DevOps encrypted variables

AnswerA

GitHub Secrets are repository-level encrypted values that are never stored in the workflow file; GitHub encrypts each secret with a public key using the libsodium sealed box algorithm before storing it and exposes it to workflow runs only as the secrets context. During a run, GitHub injects the secret into the runner environment and automatically redacts its value from logs, and secrets are not available to pull requests from forks unless explicitly configured. This provides a secure, native mechanism for storing sensitive data like API tokens with per-environment scoping and rotation through the GitHub UI or API.

Why this answer

GitHub Secrets (Option A) is the correct choice because GitHub Actions provides a built-in secrets management system that encrypts sensitive values at rest and masks them in all workflow logs. When you reference a secret using ${{ secrets.MY_SECRET }}, GitHub automatically redacts the value from any log output, ensuring it is never exposed during execution.

Exam trap

The trap here is that candidates confuse Azure DevOps encrypted variables with GitHub Secrets, assuming Azure Key Vault integration works identically in GitHub Actions, when in fact GitHub Actions requires a separate action or manual API calls to fetch secrets from Azure Key Vault.

How to eliminate wrong answers

Option B is wrong because environment variables defined directly in the workflow YAML file are stored in plain text and can be printed or leaked in logs, offering no security for sensitive data. Option C is wrong because hardcoding secrets in the workflow file commits them to the repository history, making them visible to anyone with repository access and violating security best practices. Option D is wrong because Azure Key Vault with Azure DevOps encrypted variables is a valid approach for Azure Pipelines, but the question specifically asks about GitHub Actions, where Azure Key Vault integration is not natively supported without additional custom steps or third-party actions.

Full explanation →

159

MCQmedium

Refer to the exhibit. A developer creates a pipeline with this YAML. When a commit is pushed to the 'main' branch of the repository 'MyProject/MyRepo', the pipeline does NOT trigger. Which is the most likely cause?

A.The 'checkout: internal' step should use a different syntax.

B.The 'ref' property should be set to a commit SHA, not a branch name.

C.The branch specification 'main' is case-sensitive and should be 'Main'.

D.The 'internal' repository trigger requires a pipeline trigger to be enabled in the UI.

AnswerD

For a repository resource trigger to fire, the pipeline's overall Continuous Integration trigger must be enabled in the Azure DevOps UI, not just the YAML trigger under 'resources'. When the CI trigger is turned off, Azure Pipelines ignores both the pipeline-section branch filters and the repository resource trigger configurations. Because the pipeline trigger may be disabled in the UI, this statement identifies the actual root cause and is therefore correct.

Why this answer

When using the 'internal' repository type in Azure Pipelines YAML, the pipeline must have a 'Pipeline trigger' explicitly enabled in the UI settings. The YAML 'trigger' branch specification alone is insufficient for 'internal' repositories; the UI trigger acts as a required gate. Without this UI setting, commits to 'main' will not initiate the pipeline.

Exam trap

The trap here is that candidates assume the YAML 'trigger' block alone is sufficient to enable CI for any repository type, but Azure Pipelines requires an additional UI-based trigger enablement for internal Azure Repos, which is a subtle but critical distinction.

How to eliminate wrong answers

Option A is wrong because 'checkout: internal' is a valid syntax for checking out an internal Azure Repos repository; there is no alternative syntax required. Option B is wrong because the 'ref' property in a trigger can be set to a branch name (e.g., 'refs/heads/main') and does not require a commit SHA. Option C is wrong because branch names in Azure Repos are case-insensitive by default; 'main' and 'Main' are treated as the same branch.

Full explanation →

160

MCQmedium

Your team uses Azure Pipelines to build a React application. The build process runs npm install, npm test, and npm run build. The build succeeds, but the application loads slowly in the browser due to large bundle sizes. What should you add to the pipeline to optimize the build?

A.Add a step to cache the node_modules folder.

B.Add a step to minify JavaScript using Terser.

C.Add a step to run Webpack bundle analyzer and implement code splitting.

D.Add a step to run additional unit tests to catch performance issues.

AnswerC

Running Webpack Bundle Analyzer generates a visual treemap of module and dependency sizes, which helps identify large libraries or accidental duplicates that inflate the bundle. Implementing code splitting via dynamic imports or SplitChunksPlugin then breaks the single bundle into smaller lazy-loaded chunks, directly reducing the initial bundle size and improving load performance.

Why this answer

The issue is large bundle sizes causing slow load times. Running Webpack bundle analyzer identifies which modules contribute most to the bundle, and implementing code splitting (e.g., dynamic imports or React.lazy) allows splitting the bundle into smaller chunks loaded on demand, reducing initial payload size.

Exam trap

The trap here is that candidates confuse build optimization (caching, minification) with bundle size optimization, overlooking that code splitting directly addresses the symptom of slow loading due to large bundles.

How to eliminate wrong answers

Option A is wrong because caching node_modules speeds up the npm install step but does not reduce bundle size or address slow loading in the browser. Option B is wrong because minifying JavaScript with Terser reduces file size only slightly (by removing whitespace and shortening variable names) and does not address the root cause of large bundle sizes from monolithic chunks. Option D is wrong because additional unit tests do not affect bundle size or runtime performance; they only verify code correctness.

Full explanation →

161

MCQmedium

You have a multi-stage YAML pipeline that deploys to Azure App Service. The deployment to the production stage should only proceed if a manual approval is granted. How should you configure this?

A.Use deployment gates with Azure Monitor metrics

B.Configure branch policies on the main branch

C.Add a pipeline decorator to require sign-off

D.Add an approval check on the production environment

AnswerD

Adding an approval check on the production environment in Azure Pipelines creates a manual gate that halts the deployment before it runs, requiring an authorized user to explicitly approve or reject the release. This is the proper native mechanism for enforcing human sign-off on a production deployment in a multi-stage YAML pipeline.

Why this answer

Azure Pipelines supports approval checks on environments, which allow you to require manual approval before a deployment proceeds to a specific stage. By adding an approval check on the production environment, the pipeline will pause at that stage until an authorized user grants approval, meeting the requirement for manual sign-off before production deployment.

Exam trap

The trap here is that candidates often confuse deployment gates (automated health checks) with manual approvals, or mistakenly think branch policies or pipeline decorators can enforce stage-level sign-off, when only environment-level approval checks provide the required manual approval workflow.

How to eliminate wrong answers

Option A is wrong because deployment gates with Azure Monitor metrics are used for automated health checks (e.g., monitoring error rates or latency) and do not provide manual approval functionality; they are designed for automatic validation, not human sign-off. Option B is wrong because branch policies on the main branch control code merging (e.g., requiring pull request reviews) but have no effect on pipeline deployment approvals after the code is merged; they do not gate deployment stages. Option C is wrong because a pipeline decorator is a mechanism to inject additional steps or tasks into every pipeline run (e.g., for compliance scanning) but cannot enforce manual approval; it is not a replacement for environment-level approval checks.

Full explanation →

162

MCQeasy

You need to automatically run a security scan on every pull request in GitHub. The scan should block the PR if critical vulnerabilities are found. Which GitHub feature should you use?

A.GitHub Code Scanning with a CodeQL workflow

B.Dependabot version updates

C.Secret scanning

D.Branch protection rules with required status checks

AnswerA

GitHub Code Scanning with a CodeQL workflow is the correct answer because CodeQL performs semantic analysis of your source code, identifying vulnerabilities such as SQL injection, cross-site scripting, and path traversal. When configured in a GitHub Actions workflow with an `on: pull_request` trigger, CodeQL runs on every pull request and surfaces results directly as a check run in the PR's checks interface. These check runs can then be required by branch protection rules, meaning a pull request is blocked from merging until CodeQL reports no security issues, providing a true automated code-security gate.

Why this answer

GitHub Code Scanning with a CodeQL workflow is the correct choice because it allows you to define a custom security analysis that runs on every pull request. By configuring the workflow to fail on critical-severity alerts, the pull request is automatically blocked, preventing vulnerable code from being merged. This integrates directly with GitHub's checks API to enforce the scan result as a required status check.

Exam trap

The trap here is that candidates often confuse Dependabot (which handles dependency updates) or branch protection rules (which enforce checks) with the actual scanning tool, forgetting that Code Scanning with CodeQL is the specific feature that performs the security analysis and can block PRs based on vulnerability severity.

How to eliminate wrong answers

Option B is wrong because Dependabot version updates only automate the creation of pull requests to update outdated dependencies; it does not perform security scanning or block PRs based on vulnerabilities. Option C is wrong because Secret scanning is a passive detection feature that alerts on exposed secrets (e.g., API keys) in repositories, but it does not run on every pull request or block PRs. Option D is wrong because branch protection rules with required status checks are a mechanism to enforce that certain checks pass, but they do not themselves perform any security scanning; they rely on an external check like CodeQL to provide the status.

Full explanation →

163

Multi-Selecteasy

Your team wants to implement automated testing in the build pipeline. You need to ensure that tests run and results are published. Which TWO tasks should you include?

Select 2 answers

A.Publish Build Artifacts task

B.Copy Files task

C.Visual Studio Test task

D.Publish Test Results task

E.Azure PowerShell task

AnswersC, D

The Visual Studio Test task is the correct choice because it uses vstest.console.exe to run unit tests from test assemblies (MSTest, xUnit, NUnit) and produces test result data (e.g., TRX). It is the built-in Azure Pipelines task that actually executes tests during the build.

Why this answer

The Visual Studio Test task (C) is correct because it is the Azure Pipelines task that discovers and executes tests using the VSTest runner, which is exactly what is needed to run automated tests in the build pipeline. The Publish Test Results task (D) is correct because it takes the test result files produced by the test run and publishes them to the pipeline so results are surfaced in the build summary and reports, satisfying the requirement to publish results. The Publish Build Artifacts task (A) only uploads build outputs for later use and does not run or publish test results.

The Copy Files task (B) merely copies files between directories and has no testing capability. The Azure PowerShell task (E) runs PowerShell scripts against Azure resources and is unrelated to executing or publishing test results.

Exam trap

The trap is selecting tasks that seem related to testing but do not actually run or publish test results, such as Publish Build Artifacts or Azure PowerShell.

Full explanation →

164

Matchingmedium

Match each Azure Repos policy to its enforcement.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Ensures at least N reviewers approve

Requires PR to be associated with a work item

Requires all comments to be resolved before merge

Requires a successful pipeline run before merge

Why these pairings

The correct matches are A, B, C, D. Policy A requires at least two reviewers. Policy B requires linked work items.

Policy C requires a successful build. Policy D limits merge types. Policies E and F are incorrect because they swap the descriptions: E describes merge types but is labeled as reviewer count, and F describes reviewer count but is labeled as work item linking.

Exam trap

Candidates often confuse the 'Require a minimum number of reviewers' policy with merge type restrictions, and 'Check for linked work items' with reviewer approval.

Full explanation →

165

MCQhard

A team uses Terraform to manage Azure infrastructure. They want to store the Terraform state file securely and enable collaboration. What is the recommended approach?

A.Store the state file in an Azure Storage account with state locking enabled

B.Store the state file in a local folder and commit to Git

C.Store the state file in Terraform Cloud

D.Store the state file in a Git repository with manual locking

AnswerA

Azure Storage provides durable, centralised storage for the state file, and blob leasing delivers state locking so concurrent pipeline runs cannot corrupt it. This satisfies both the security and collaboration requirements, unlike local storage, which offers neither shared access nor locking.

Why this answer

Storing the Terraform state file in an Azure Storage account with state locking enabled is the recommended approach because it provides a centralized, durable backend that supports native state locking via Azure Blob Storage leases. This prevents concurrent modifications and state corruption, enabling safe collaboration among team members. Azure Storage also offers encryption at rest and access control via RBAC, aligning with security best practices for infrastructure-as-code.

Exam trap

The trap here is that candidates often assume Terraform Cloud is always the best remote backend, but the question specifies Azure infrastructure, and the recommended approach for Azure is the native Azure Storage backend due to its tight integration, lower latency, and no additional licensing cost.

How to eliminate wrong answers

Option B is wrong because storing the state file in a local folder and committing it to Git exposes sensitive data (e.g., plaintext secrets, resource IDs) in version control and lacks state locking, leading to corruption if multiple team members run Terraform simultaneously. Option C is wrong because while Terraform Cloud is a valid remote backend, the question specifically asks for the recommended approach for Azure infrastructure, and the Azure Storage backend is the native, cost-effective, and fully integrated solution within Azure; Terraform Cloud introduces an external dependency and additional cost. Option D is wrong because storing the state file in a Git repository with manual locking does not prevent concurrent writes—Git does not provide distributed locking, and manual coordination is error-prone and unscalable, risking state conflicts.

Full explanation →

166

MCQmedium

Your Azure DevOps pipeline uses a variable group to store secrets. The variable group is linked to a Key Vault. You need to use a secret variable in a pipeline task. How should you reference the secret in the YAML pipeline?

A.Reference the variable as $(VariableName) but only in a script task using 'env' mapping.

B.Use the 'task.getVariable' method in a PowerShell script.

C.Reference the variable as $(VariableName) in the pipeline tasks.

D.Use the Azure Key Vault task to retrieve the secret and then reference the output variable.

AnswerC

Once an Azure Key Vault variable group is linked, its secrets are automatically surfaced as pipeline variables, so you can reference them directly in any task using the macro syntax $(VariableName). This works because Azure Pipelines resolves the macro during runtime, injecting the secret's value into the task before it executes, without needing a separate Key Vault task or explicit service connection in each task.

Why this answer

When a variable group is linked to an Azure Key Vault, secret variables are automatically available in the pipeline. You can reference them directly using the standard $(VariableName) syntax in any pipeline task. No special task or script is required.

Option A is incorrect because you do not need to restrict to script tasks or use 'env' mapping; the $(VariableName) works everywhere. Option B is incorrect because 'task.getVariable' is a scripting method used within tasks, not a YAML syntax. Option D is incorrect because the Azure Key Vault task is unnecessary; the variable group handles the retrieval automatically.

Full explanation →

167

Multi-Selecthard

Your organization uses Azure Pipelines with Microsoft-hosted agents. The pipeline runs a .NET Core application build. You notice that the build takes longer than expected. Which THREE actions can you take to improve build performance? (Choose three.)

Select 3 answers

A.Add more build steps to the pipeline.

B.Enable caching for NuGet packages.

C.Increase the number of parallel jobs in the pipeline.

D.Use multi-stage build with parallel test execution.

E.Use a self-hosted agent with pre-installed dependencies.

AnswersB, D, E

Caching NuGet packages in Azure Pipelines stores restored packages in a local cache keyed by your package lock files, so subsequent builds restore them from the cache instead of downloading from nuget.org. This dramatically reduces restore time and network latency, directly shortening the overall build duration.

Why this answer

Enabling NuGet package caching reduces build time by avoiding repeated downloads of packages. Using a self-hosted agent with pre-installed dependencies eliminates the need to install and download tools on each run, further reducing overhead. Additionally, structuring the pipeline as a multi-stage build and running tests in parallel across multiple agents can significantly shorten overall pipeline duration by executing independent test suites concurrently.

Together, these optimizations improve build performance.

Exam trap

The trap here is that candidates often confuse increasing parallel jobs (which affects concurrency) with optimizing a single pipeline's execution time, leading them to incorrectly select option C.

Full explanation →

168

MCQmedium

Refer to the exhibit. A developer is on the 'feature/login' branch and wants to integrate the latest changes from 'feature/user-profile' without creating a merge commit. Which Git command should the developer use?

A.git rebase origin/feature/user-profile

B.git pull --rebase origin main

C.git merge origin/feature/user-profile

D.git cherry-pick 9f8e7d6..8a7b6c5

AnswerA

git rebase origin/feature/user-profile is correct because it replays the unique commits from the current feature/login branch on top of the latest commits from origin/feature/user-profile, creating a linear history without a merge commit while preserving the login-specific changes.

Why this answer

To integrate changes from another branch without a merge commit, rebase is appropriate. The developer can rebase feature/login onto feature/user-profile (or onto main after merging user-profile). However, the exhibit shows that feature/user-profile is already merged into main, so rebasing feature/login onto main is also valid.

The simplest is to rebase feature/login onto main, but that would include all changes. Alternatively, rebasing feature/login onto feature/user-profile directly would also work, but since user-profile is merged into main, rebasing onto main is common. The correct answer is rebase.

Full explanation →

169

MCQmedium

Refer to the exhibit. You have a branch policy JSON for Azure Repos. Which statement about this policy is correct?

A.The last person who pushed can approve the pull request.

B.At least two reviewers must approve the pull request.

C.Pull requests to main are automatically squash-merged.

D.Approvals are reset when the source branch is updated.

AnswerB

The branch policy sets requireApprovalCount to 2, meaning that two distinct reviewers (excluding those blocked by policy) must independently approve the PR before it can be completed. This is the correct interpretation of the policy.

Why this answer

The branch policy JSON specifies `minimumApproverCount: 2`, which enforces that at least two distinct reviewers must approve the pull request before it can be completed. This is a standard Azure Repos branch policy setting that controls the required number of approvals, not the identity of the approvers or the merge strategy.

Exam trap

The trap here is that candidates assume the last person who pushed can always approve, but Azure Repos defaults to blocking that unless explicitly overridden, and the policy JSON shown does not include the override setting.

How to eliminate wrong answers

Option A is wrong because Azure Repos branch policies do not automatically allow the last pusher to approve; unless explicitly allowed via the 'Allow approvers to approve their own changes' setting, the last person who pushed is typically blocked from approving. Option C is wrong because the JSON does not set a merge strategy; squash-merge is a separate policy option not shown here. Option D is wrong because the policy does not include `resetOnSourcePush: true`; without that setting, approvals are not automatically reset when the source branch is updated.

Full explanation →

170

Multi-Selectmedium

You are designing a multi-stage YAML pipeline for an application that requires approval for production deployment. The pipeline must run automatically for non-production stages. Which TWO configurations should you use?

Select 2 answers

A.Set the pipeline trigger to include branches used for non-production stages.

B.Define a stage for production with an 'approvals' block.

C.Use a release pipeline instead of a YAML pipeline.

D.Set the pipeline to require manual approval for every stage.

E.Use a single-stage pipeline with conditional approval.

AnswersA, B

Setting the pipeline trigger to include branches used for non-production stages means CI will automatically run the pipeline for changes to develop/feature branches, allowing non-production stages (e.g., build, test, staging) to execute without manual intervention. This is correct in a multi-stage YAML design where automated progression is desired for non-production while production remains approval-gated.

Why this answer

Options A and B are correct. Option A: Setting the pipeline trigger to include branches used for non-production stages enables automatic CI triggers for those branches, so non-production stages run automatically. Option B: Adding an 'approvals' block to the production stage enforces manual approval before deployment to production.

Options C, D, and E are incorrect: C suggests using a release pipeline which is unnecessary; D would require manual approval for every stage, not just production; E describes a single-stage pipeline, which doesn't fit the multi-stage requirement.

Full explanation →

171

MCQmedium

Your release pipeline deploys a .NET Core web app to Azure App Service using a deployment slot for staging. The pipeline runs integration tests against the staging slot. After tests pass, you want to swap the staging slot with production. However, the swap fails sometimes because the staging slot has different configuration settings. What is the best practice to ensure swapping succeeds?

A.Use slot-specific configuration settings (deployment slot settings) for connection strings and app settings that differ between slots.

B.Manually update the production slot settings to match staging before each swap.

C.Perform a swap with preview and then complete the swap after verifying the staging slot.

D.Write a custom PowerShell script to copy configuration from staging to production before swapping.

AnswerA

In Azure App Service, deployment slot settings are marked as 'sticky' so they remain with the slot during swap, ensuring correct connection strings and app settings are applied regardless of swap. This prevents configuration mismatches and eliminates the need for manual updates or scripts. By defining slot-specific settings, production continues to use its intended values while staging uses its own, making swap safe.

Why this answer

Azure App Service allows you to mark specific configuration settings (like connection strings and app settings) as 'deployment slot settings.' When a setting is marked as slot-specific, it stays with the slot during a swap, preventing failures caused by mismatched configurations. This ensures that the staging slot retains its test-specific settings (e.g., a test database connection string) while the production slot keeps its own settings, making the swap predictable and reliable.

Exam trap

The trap here is that candidates often confuse 'swap with preview' (which is about validation and rollback) with the root cause of swap failures, not realizing that slot-sticky settings are the proper mechanism to prevent configuration conflicts during a swap.

How to eliminate wrong answers

Option B is wrong because manually updating production slot settings before each swap is error-prone, violates infrastructure-as-code principles, and introduces downtime or misconfiguration risks. Option C is wrong because swap with preview is a technique to validate the swap outcome, not a solution for configuration mismatches; it does not prevent swap failures caused by slot-specific settings. Option D is wrong because writing a custom PowerShell script to copy configuration is unnecessary complexity and defeats the purpose of Azure's built-in slot-sticky settings; it also risks overwriting production settings unintentionally.

Full explanation →

172

MCQhard

Refer to the exhibit. A pipeline in repository 'MyProject/AppRepo' is configured to trigger when changes are pushed to 'SharedRepo'. A developer pushes a commit to the 'release/v1' branch of 'SharedRepo'. What will happen?

A.The pipeline will trigger only if the commit also includes changes to 'main'.

B.The pipeline will fail because the trigger configuration is invalid.

C.The pipeline will trigger because 'release/v1' matches the 'release/*' include pattern.

D.The pipeline will not trigger because 'release/v1' is not explicitly listed.

AnswerC

The 'release/*' include pattern is a wildcard that matches any branch name beginning with 'release/' and containing any characters after the slash. Because 'release/v1' starts with 'release/', it matches the pattern, satisfying the branch trigger and causing the pipeline to trigger on that branch.

Why this answer

The pipeline's resource trigger uses a branch include pattern 'release/*', and 'release/v1' matches that wildcard, so the push triggers the pipeline. Azure Pipelines resource triggers evaluate the branch filter against the pushed branch name, and wildcard matching is supported. No explicit listing of 'release/v1' is required.

Exam trap

AZ-400 often tests whether candidates recognise that wildcard patterns like 'release/*' match without explicit branch listing — many assume every branch must be named individually.

How to eliminate wrong answers

Option A is wrong because the trigger is scoped to SharedRepo's branch pattern, not to changes in 'main' — there is no requirement that the commit also touch main. Option B is wrong because the trigger configuration is valid; wildcard patterns are supported in resource triggers. Option D is wrong because 'release/*' is a wildcard include, so 'release/v1' matches without being explicitly named.

Full explanation →

173

MCQeasy

Your team uses Azure DevOps and wants to enforce that all changes to the main branch go through a pull request process with at least two approvals. They also want to prevent contributors from approving their own pull requests. Which branch policy settings should they use?

A.Enable 'Check for linked work items' and 'Require a minimum number of reviewers' set to 2, and enable 'Reset code reviewer votes when new changes are pushed'.

B.Add the 'main' branch to the 'Required reviewers' list and add all developers as required reviewers.

C.Enable 'Require a minimum number of reviewers' set to 2, and enable 'Build validation' with a required build.

D.Enable 'Require a minimum number of reviewers' set to 2, and enable 'Allow users to approve their own changes' unchecked (or set to false).

AnswerD

Setting the minimum reviewers to two forces at least two approvals, while unchecking 'Allow users to approve their own changes' prevents the author from counting as one of them, thereby enforcing authentic peer review from two distinct eligible reviewers.

Why this answer

It directly addresses both requirements: setting 'Require a minimum number of reviewers' to 2 enforces at least two approvals, and unchecking 'Allow users to approve their own changes' prevents contributors from approving their own pull requests. These are branch policy settings within Azure Repos that control the pull request workflow on the main branch.

Exam trap

The trap here is that candidates often confuse 'Require a minimum number of reviewers' with 'Required reviewers' (a static list) or think that build validation alone satisfies the approval requirement, missing the need to explicitly disable self-approval.

How to eliminate wrong answers

Option A is wrong because 'Check for linked work items' ensures traceability but does not enforce the number of approvals or prevent self-approval; 'Reset code reviewer votes when new changes are pushed' is unrelated to the approval count or self-approval restriction. Option B is wrong because adding the 'main' branch to 'Required reviewers' and listing all developers as required reviewers would force every developer to be a reviewer on every PR, which is impractical and does not enforce a minimum of two approvals or prevent self-approval. Option C is wrong because 'Build validation' ensures code quality via automated builds but does not control the number of human approvals or self-approval behavior.

Full explanation →

174

MCQmedium

Your organization uses Microsoft Purview to manage sensitive data in Azure DevOps repositories. The compliance team needs to automatically classify and label source code that contains personally identifiable information (PII). Which solution should you use?

A.Use Azure Policy to enforce PII labeling on repositories.

B.Use Microsoft Purview Information Protection to automatically scan and label repositories.

C.Use Microsoft Sentinel to detect PII in repositories.

D.Use Microsoft Defender for Cloud to scan for PII.

AnswerB

Purview Information Protection can automatically classify and label sensitive data in source code.

Why this answer

Microsoft Purview Information Protection provides built-in data classification and labeling capabilities that can automatically scan Azure DevOps repositories for sensitive data such as PII. It uses sensitive information types and machine learning classifiers to detect patterns like social security numbers or credit card numbers, then applies the appropriate sensitivity label directly to the source code files. This meets the compliance team's requirement for automatic classification and labeling without custom development.

Exam trap

The trap here is that candidates often confuse Microsoft Purview Information Protection (which handles data classification and labeling) with Azure Policy (which handles resource governance) or Microsoft Defender for Cloud (which handles security posture), leading them to select a tool that cannot perform content-level scanning or labeling.

How to eliminate wrong answers

Option A is wrong because Azure Policy is used to enforce organizational standards and assess compliance at the resource level (e.g., requiring HTTPS on repos), but it cannot scan file contents or apply sensitivity labels to source code. Option C is wrong because Microsoft Sentinel is a SIEM/SOAR tool for security incident detection and response, not for scanning and labeling data within Azure DevOps repositories. Option D is wrong because Microsoft Defender for Cloud focuses on cloud security posture management and workload protection (e.g., vulnerability scanning, threat detection), not on classifying or labeling PII in source code.

Full explanation →

175

MCQmedium

Your team uses GitHub Flow. A developer pushes a feature branch to origin and creates a pull request to main. After review and approval, the pull request is merged. Which branch should the developer delete after the merge to maintain a clean repository?

A.Delete the feature branch

B.Keep both branches indefinitely

C.Delete the main branch

D.Delete the remote main branch and recreate it

AnswerA

Delete the feature branch. In GitHub Flow, feature branches are ephemeral and should be deleted after their pull request is merged, because the merge already integrates all commits into main; leaving the branch creates stale references and confusion for future work.

Why this answer

In GitHub Flow, feature branches are temporary and should be deleted after their pull request is merged into main. Deleting the feature branch keeps the repository clean by removing stale branches that are no longer needed, reducing clutter and preventing confusion. This practice aligns with the principle of short-lived branches in trunk-based development workflows.

Exam trap

The trap here is that candidates may think keeping feature branches is harmless or that deleting main is acceptable for cleanup, but GitHub Flow explicitly requires deleting feature branches after merge to maintain a clean, linear history and avoid repository clutter.

How to eliminate wrong answers

Option B is wrong because keeping both branches indefinitely violates the GitHub Flow convention of deleting feature branches after merge, leading to repository bloat and potential confusion about active work. Option C is wrong because deleting the main branch would break the repository's default branch and disrupt all future development, as main is the stable integration branch. Option D is wrong because deleting and recreating the remote main branch is unnecessary and destructive; it would require force-pushing and could cause loss of commit history or break CI/CD pipelines that depend on the existing branch.

Full explanation →

176

MCQeasy

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?

A.Workflow triggers

B.Branch protection rules with required status checks

C.Required reviewers

D.Environment protection rules

AnswerB

Branch protection rules with required status checks enforce that a pull request cannot be merged until the specified GitHub Actions checks (reported as commit statuses, e.g., from a job's `check_run` or `status` context) succeed. The protected branch's `required_status_checks` context verifies the list of checks, and the merge is rejected if any required check is failing, pending, or absent — this is the correct GitHub-native mechanism for CI gating.

Why this answer

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.

Exam trap

The trap here is confusing workflow triggers (which control when automation runs) with branch protection rules (which enforce that automation results are satisfied before merging).

How to eliminate wrong answers

Option A is wrong because workflow triggers (e.g., push, pull_request) define when a workflow runs, not whether its results block a merge. Option C is wrong because required reviewers enforce manual approval from specific people, not automated workflow checks. Option D is wrong because environment protection rules control deployments to specific environments (e.g., production) and do not gate pull request merges based on workflow status.

Full explanation →

177

Multi-Selectmedium

Which TWO features in Azure Pipelines allow you to enforce separation of duties between development and operations teams? (Choose two.)

Select 2 answers

A.Pipeline decorators

B.Approvals and checks on environments

C.Service connections with different scopes

D.Environment security roles

E.Branch policies on the main branch

AnswersB, D

Approvals and checks on environments are pre-deployment gates that require designated reviewers or automated checks to approve before a release proceeds; this ensures separation of duties by allowing one group to create a release and a different group to approve it, and checks can enforce policies like branch protection.

Why this answer

Approvals and checks on environments (B) enforce separation of duties by requiring designated approvers (e.g., operations team members) to approve a deployment before it proceeds, ensuring that development cannot directly push to production. Environment security roles (D) allow you to define who can create, view, or manage environments, restricting developers from modifying production environments without operations oversight.

Exam trap

The trap here is that candidates confuse branch policies (which govern code merging) with deployment approvals (which govern release to environments), leading them to select branch policies instead of environment security roles or approvals.

Full explanation →

178

MCQmedium

Your project uses a monorepo in Azure Repos. You want to enforce that changes to a specific folder (/src/security) require approval from the security team. What is the best approach?

A.Add a required reviewer policy for all pull requests.

B.Configure a branch policy with a path filter and require approval from the security team group.

C.Move the security folder to a separate repository with its own policies.

D.Set folder-level permissions to restrict who can modify the folder.

AnswerB

Azure Repos branch policies support path filters, letting you scope required approvals to /src/security only. Assigning the security team group as required reviewer enforces their sign-off on changes touching that folder, while other paths remain unaffected.

Why this answer

Azure Repos branch policies allow you to define path filters that scope policy enforcement to specific folders. By adding a required reviewer policy with a path filter for `/src/security` and assigning the security team group, only pull requests modifying files under that folder will require their approval, leaving other changes unaffected.

Exam trap

The trap here is that candidates often confuse folder-level permissions (which control direct access) with branch policy path filters (which enforce workflow approvals), leading them to select Option D instead of the correct branch policy configuration.

How to eliminate wrong answers

Option A is wrong because a required reviewer policy without a path filter applies to all pull requests across the entire repository, forcing security team approval for every change, which is overly broad and not scoped to the specific folder. Option C is wrong because moving the folder to a separate repository introduces unnecessary complexity, breaks monorepo consistency, and does not leverage Azure Repos' built-in branch policy path filters for granular control. Option D is wrong because folder-level permissions in Azure Repos control direct push access but do not enforce pull request review workflows; a user with write permissions could still bypass approval by pushing directly to the branch if branch policies are not configured.

Full explanation →

179

Multi-Selectmedium

You are designing a release pipeline for a microservices application. Which two strategies can you use to manage configuration across different environments? (Choose two.)

Select 2 answers

A.Use variable groups linked to Azure Key Vault.

B.Use environment-specific variable groups.

C.Use XML transformation tasks for web.config.

D.Use multi-stage YAML pipelines with stage-level variables.

AnswersA, B

Linking variable groups to Azure Key Vault is the recommended way to manage secrets and non-sensitive configuration centrally; it stores values securely in Key Vault, supports access control, auditing, and automatic rotation, and references them in pipelines without exposing secrets in source control.

Why this answer

Options A and B are correct because variable groups provide a centralized and secure way to manage configuration across multiple environments and pipelines. Option A uses Azure Key Vault for secrets, integrating with access policies and rotation, while option B stores non-sensitive environment-specific settings. Option C is incorrect because XML transformation targets web.config files, which are legacy .NET artifacts and not typical for modern microservices that use JSON, YAML, or environment variables.

Option D is incorrect because stage-level variables are scoped to a single pipeline definition and do not offer a reusable, centralized configuration mechanism across different environments or pipelines; variable groups are designed for that purpose.

Exam trap

The trap here is that candidates often confuse pipeline definition techniques (like multi-stage YAML with stage-level variables) with configuration management strategies, or incorrectly assume XML transformations are applicable to modern microservices deployments that use JSON, YAML, or environment variables instead of web.config files.

Why the other options are wrong

XML transformation is for config files, not a variable management strategy.

This is a valid approach but the question asks for 'strategies' and the two most common are variable groups and Key Vault.

Full explanation →

180

MCQeasy

Your team uses Azure Pipelines to build and deploy a web app. You want to send a notification to a Microsoft Teams channel when a build fails. What should you configure?

A.Add a task in the pipeline to send an email on failure.

B.Create a service hook to trigger an Azure Logic App that sends a Teams message.

C.Add a dashboard widget that shows build status.

D.Use the built-in Azure Pipelines Teams integration to send a notification on build failure.

AnswerD

The built-in Azure Pipelines Teams integration lets you subscribe to build pipeline events, such as a failed build, and delivers an adaptive card notification directly to a configured Teams channel. This native subscription uses Azure DevOps service hooks to Teams internally, requiring no custom code, Logic Apps, or extra configuration, and is the canonical solution for notifying Teams of build failures.

Why this answer

Azure Pipelines has a built-in integration with Microsoft Teams that allows you to subscribe to notifications for pipeline events, such as build failures, directly from the Azure DevOps interface. This integration uses a service hook to send adaptive cards to a Teams channel without requiring custom logic or additional tasks.

Exam trap

The trap here is that candidates may overengineer the solution by choosing a custom Logic App or third-party task, overlooking the fact that Azure Pipelines has a first-class, built-in integration with Microsoft Teams that requires no additional code or services.

How to eliminate wrong answers

Option A is wrong because Azure Pipelines does not have a native 'send email on failure' task; email notifications are configured via subscription settings, not as a pipeline task. Option B is wrong because while a service hook can trigger an Azure Logic App to send a Teams message, this is an overly complex solution when the built-in Teams integration provides the same functionality with less overhead. Option C is wrong because a dashboard widget only displays build status visually within Azure DevOps and does not send proactive notifications to Microsoft Teams.

Full explanation →

181

MCQmedium

Your team uses Azure Repos and has a repository with a large number of binary files (e.g., images, compiled libraries) that bloat the repository size. You want to reduce clone times and storage usage while still maintaining version history for those files. Which approach should you recommend?

A.Split the repository into two: one for code and one for binaries.

B.Use git annex to manage large files with a separate store.

C.Use git submodules to reference the large files from another repository.

D.Use Git Large File Storage (LFS) to track large files with pointers.

AnswerD

Git LFS replaces large binaries with small pointer files in the repository while storing the actual content externally, so clones download only pointers plus needed objects. Version history is retained, satisfying the requirement to cut clone times and storage.

Why this answer

Git LFS (Large File Storage) replaces large binary files in the repository with text pointers, while storing the actual file content in a separate remote store. This keeps the repository lightweight for cloning and fetching, but still preserves the full version history of the binary files because each pointer references a specific version in the LFS store. It integrates natively with Azure Repos and requires minimal workflow changes.

Exam trap

The trap here is that candidates often confuse git submodules or repo splitting as valid solutions for large files, but they fail to realize that those approaches do not actually reduce clone times or storage usage for the binary files themselves—they only reorganize the problem.

How to eliminate wrong answers

Option A is wrong because splitting the repository does not reduce the total storage or clone time for the binary files—they still exist in a separate repo and must be cloned separately, and maintaining version history across two repos adds complexity. Option B is wrong because git annex is not a native Azure Repos feature; it requires a separate external store and manual configuration, and it does not integrate seamlessly with Azure DevOps pipelines or pull requests. Option C is wrong because git submodules only link to a specific commit in another repository; they do not reduce clone times for the large files (the submodule must still be cloned in full) and they complicate version management by requiring explicit submodule updates.

Full explanation →

182

Multi-Selecthard

Which THREE are benefits of using 'Environment' resources in YAML pipelines compared to classic release pipelines? (Choose three.)

Select 3 answers

A.Environments provide a dashboard showing the deployment history and resource health.

B.Environments can only be used in classic release pipelines.

C.Environments support checks like approval gates and manual intervention.

D.Environments allow you to define pre-deployment and post-deployment gates using the classic release pipeline interface.

E.Environments can represent Kubernetes namespaces and track deployed versions.

AnswersA, C, E

In Azure DevOps, an environment provides a centralized dashboard that consolidates the deployment history from every pipeline that targets that environment, displaying each run's status, artifact version, and timestamp. It also shows resource health, such as whether a VM agent is online or the current state of a Kubernetes namespace, giving teams immediate visibility into both past deployments and the live readiness of infrastructure. This combined view is essential for quickly diagnosing failed deployments, identifying drift, and ensuring auditability across multi-pipeline release processes.

Why this answer

Option A is correct because Azure DevOps Environments provide a dedicated dashboard that surfaces deployment history and the health/status of the associated resources (VMs, Kubernetes, etc.), giving visibility that classic release pipelines lack in a unified view. Option C is correct because Environments support configurable checks such as approvals, business hours, and manual intervention, which gate pipeline stages before deployment proceeds. Option E is correct because an Environment can be backed by a Kubernetes resource, where the target can be a namespace, and the environment tracks the deployed versions/artifacts to that namespace.

Option B is incorrect because Environments are designed for YAML pipelines, not classic release pipelines. Option D is incorrect because pre-deployment and post-deployment gates are a classic release pipeline feature, not a benefit of Environments in YAML pipelines.

Exam trap

The trap here is that candidates may confuse the classic release pipeline's gate mechanism (Option D) with the YAML pipeline's check system, or incorrectly assume Environments are only for classic pipelines (Option B), when in fact Environments are a cross-pipeline resource that enhances YAML pipelines with deployment tracking and approval workflows.

Full explanation →

183

MCQhard

Your release pipeline deploys to Azure App Service using a deployment slot strategy. After a successful deployment to the staging slot, you run smoke tests, then swap slots. Recently, a swap failed because the staging slot had an incorrect application setting. What is the BEST way to prevent this issue?

A.Use a manual approval gate before swap.

B.Configure the App Service deployment center.

C.Add a task to verify settings before swap.

D.Mark the application setting as a deployment slot setting.

AnswerD

Marking the application setting as a deployment slot setting makes it 'sticky' to the slot, meaning it will not be swapped with the app code between staging and production. This ensures the staging slot retains its own configured value and the production slot's value remains unchanged, thereby preventing the misconfiguration from being promoted during a swap.

Why this answer

Marking the application setting as a deployment slot setting ensures that the setting stays with the slot and is not swapped between staging and production. This prevents the staging slot from having an incorrect value that could cause a swap failure, as the setting is pinned to the slot and not part of the swap payload.

Exam trap

The trap here is that candidates often choose a manual or scripted verification step (like Option C) because they think it adds safety, but the native slot setting feature is the simplest, most reliable, and built-in way to prevent swap failures caused by slot-specific misconfigurations.

How to eliminate wrong answers

Option A is wrong because a manual approval gate only pauses the pipeline for human review; it does not automatically validate or correct application settings before the swap, so the same misconfiguration could still cause a failure. Option B is wrong because the App Service deployment center is a high-level configuration interface for continuous deployment, not a mechanism to validate or pin slot-specific settings before a swap. Option C is wrong because adding a task to verify settings before swap is a reactive workaround that requires custom scripting and maintenance, whereas marking the setting as a slot setting is a native, declarative, and reliable solution that prevents the issue at the configuration level.

Full explanation →

184

MCQmedium

Your organization uses GitHub Copilot for pull request summaries. However, the summaries sometimes miss security-related changes. What should you recommend?

A.Configure Copilot to ignore non-security files.

B.Provide custom instructions to Copilot to emphasize security analysis.

C.Disable Copilot and rely on manual review.

D.Switch to a different AI model specialized in security.

AnswerB

Custom instructions steer Copilot's summary generation toward security-relevant diffs, satisfying the stem's requirement to surface missed security changes. Unlike repository-wide settings or model swaps, instructions directly shape the prompt context Copilot uses when drafting summaries, making security analysis an explicit priority during generation.

Why this answer

GitHub Copilot's pull request summaries can be customized using custom instructions to prioritize security analysis. By providing specific directives in the repository's `.github/copilot-instructions.md` file or through the Copilot settings, you can instruct the AI to explicitly highlight security-related changes, such as those involving authentication, encryption, or input validation. This ensures the generated summaries are more aligned with your organization's security review requirements without disabling the tool.

Exam trap

The trap here is that candidates may assume AI tools are inflexible and require replacement or disabling when they encounter limitations, rather than recognizing that GitHub Copilot supports custom instructions to refine its behavior for specific domains like security analysis.

How to eliminate wrong answers

Option A is wrong because configuring Copilot to ignore non-security files would prevent it from analyzing all files, potentially missing security issues in files that are not exclusively security-related (e.g., a configuration file that contains a security vulnerability). Option C is wrong because disabling Copilot entirely is an overreaction and discards its productivity benefits; the goal is to improve its output, not eliminate it. Option D is wrong because switching to a different AI model specialized in security is unnecessary and disruptive; GitHub Copilot already supports customization through instructions, and a specialized model would require separate integration and may not work seamlessly with pull request summaries.

Full explanation →

185

MCQeasy

You have a GitHub repository with a GitHub Actions workflow that builds a .NET application. The workflow should only run when changes are pushed to the main branch, but it currently runs on every push to any branch. How should you fix the workflow trigger?

A.Add 'on: push: branch: [main]' to the workflow.

B.Add 'on: push: paths: [main]' to the workflow.

C.Add 'on: pull_request: branches: [main]' to the workflow.

D.Add 'on: push: branches: [main]' to the workflow.

AnswerD

This correctly configures the 'push' trigger with the 'branches' filter set to 'main', using the proper plural key. As a result, the workflow will execute only when commits are pushed directly to the 'main' branch, ignoring pushes to other branches.

Why this answer

The GitHub Actions workflow syntax to restrict a push trigger to a specific branch uses `on: push: branches: [main]`. This ensures the workflow only executes when commits are pushed to the main branch, not on pushes to any other branch.

Exam trap

The trap here is that candidates often confuse the singular `branch` with the plural `branches` or mix up `paths` with `branches`, leading them to select options that either use invalid syntax or apply the wrong filter entirely.

How to eliminate wrong answers

Option A is wrong because `branch` is not a valid key under `push`; the correct key is `branches` (plural). Option B is wrong because `paths` filters by file paths changed in the push, not by branch name, so it would not restrict the trigger to the main branch. Option C is wrong because it defines a `pull_request` trigger, not a `push` trigger, so the workflow would run on pull request events instead of push events.

Full explanation →

186

MCQhard

Refer to the exhibit. You deploy this ARM template to create a Log Analytics workspace and a saved search. After deployment, you notice that the saved search returns no results even though there are failed pipeline runs. What is the most likely reason?

A.The savedSearch API version is not supported.

B.The Log Analytics workspace API version is incorrect.

C.The custom table 'AzureDevOpsPipelineEvents_CL' does not exist in the workspace.

D.The category 'Azure Pipelines' is misspelled.

AnswerC

The ARM template deployment fails because the saved search references the custom log table 'AzureDevOpsPipelineEvents_CL', but that table does not exist in the workspace. Custom tables with the _CL suffix must be created beforehand (or data must be ingested to auto-create them); ARM templates do not implicitly create custom tables just because a saved search queries them.

Why this answer

The saved search queries the custom table 'AzureDevOpsPipelineEvents_CL', which is created by the Azure DevOps connector or a custom data ingestion pipeline. If that table has never been created in the target Log Analytics workspace, the saved search KQL query will return zero rows even when failed pipeline runs exist elsewhere. The ARM template only defines the workspace and the saved search — it does not create the underlying custom table or wire up the data source.

Exam trap

AZ-400 often tests the distinction between control-plane deployment success and data-plane readiness — candidates assume a successful ARM deployment means the query will work, forgetting that custom tables must exist before KQL can return results.

How to eliminate wrong answers

Option A is wrong because the savedSearch resource API version (e.g., 2020-08-01) is valid and supported; an unsupported API version would cause a deployment failure, not an empty result set. Option B is wrong because an incorrect workspace API version would also fail at deployment time rather than silently returning no data. Option D is wrong because the 'category' field in a saved search is just a display grouping label in the Azure portal — a misspelling would not affect query results.

Full explanation →

187

MCQeasy

Your team uses Azure Pipelines to deploy to multiple environments. You need to ensure that deployment to the production environment requires approval from the security team. What should you configure?

A.Add a branch policy to the production branch

B.Add an environment approval check for the production environment

C.Use a condition in the YAML pipeline to check a variable

D.Configure a service connection with restricted permissions

AnswerB

An environment approval check adds a required manual approval step before any jobs targeting that environment are executed. The pipeline pauses, and only after an authorized user or group explicitly approves the deployment does it proceed to the production stage, directly fulfilling the need for human sign-off on production deployments.

Why this answer

Environment approval checks in Azure Pipelines allow you to require manual approval before a deployment proceeds to a specific environment, such as production. By adding an approval check to the production environment, you ensure that the security team must explicitly approve the deployment, meeting the requirement without modifying the pipeline code or branch policies.

Exam trap

The trap here is confusing branch policies (which govern code changes) with environment approval checks (which govern deployment gates), leading candidates to incorrectly select a branch policy for deployment control.

How to eliminate wrong answers

Option A is wrong because a branch policy controls code changes to a branch (e.g., requiring pull request reviews) but does not gate deployments to an environment; it operates at the source code level, not the deployment stage. Option C is wrong because a YAML condition checking a variable can skip or run stages based on runtime values, but it cannot enforce a manual approval process; it is purely automated and lacks human intervention. Option D is wrong because a service connection with restricted permissions controls which identities can deploy to a resource, but it does not provide a manual approval gate; it is a security boundary for authentication, not a workflow approval step.

Full explanation →

188

Drag & Dropmedium

Drag and drop the steps to implement a branch policy in Azure Repos for pull requests into the correct order.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

Branch policies are set by accessing repo settings, selecting branch, adding requirements, and saving.

Full explanation →

189

MCQeasy

Your pipeline uses a multi-stage YAML file. You want to conditionally run a stage only if the build originates from the 'main' branch. Which syntax should you use?

A.condition: variables['Build.SourceBranch'] == 'main'

B.condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))

C.condition: eq(variables['Build.SourceBranch'], 'refs/heads/main')

D.condition: eq(variables['Build.SourceBranch'], 'main')

AnswerC

This is the correct condition because Azure Pipelines stores the triggering branch in the `Build.SourceBranch` variable as a full ref string, such as `refs/heads/main` or `refs/pull/123/merge` for PR builds. The `eq()` function performs an exact string comparison, so it will correctly match when pipeline runs are triggered by a push to the `main` branch. This is the minimal, readable expression that achieves the intended gating without any redundant conditions.

Why this answer

The `condition` directive in a YAML pipeline stage evaluates expressions using Azure Pipelines syntax. The `eq()` function compares two values, and `Build.SourceBranch` for the 'main' branch returns `refs/heads/main`, not just `main`. This exact match ensures the stage runs only when the build originates from the 'main' branch.

Exam trap

The trap here is that candidates often forget that `Build.SourceBranch` includes the full ref path (`refs/heads/main`) and incorrectly use just the branch name (`main`), or they misuse the `==` operator instead of the `eq()` function required by Azure Pipelines expression syntax.

How to eliminate wrong answers

Option A is wrong because it uses a simple equality operator (`==`) which is not valid in Azure Pipelines YAML expressions; the correct syntax requires the `eq()` function. Option B is wrong because it adds `and(succeeded(), ...)` which is unnecessary for a stage-level condition (stages do not have a preceding task to succeed or fail) and introduces an extra check that could cause the stage to be skipped incorrectly. Option D is wrong because it compares `Build.SourceBranch` to `'main'` instead of the full ref `'refs/heads/main'`, which will never match and thus the stage will never run.

Full explanation →

190

MCQhard

Your Azure DevOps pipeline uses a YAML template that includes a step to push a Docker image to Azure Container Registry. The pipeline fails with 'unauthorized: authentication required'. The service connection uses a workload identity federation. What is the most likely cause?

A.The Docker image tag contains invalid characters

B.The Azure Container Registry name is incorrect

C.The service principal used by the workload identity does not have the 'acrPush' role

D.The service connection secret has expired

AnswerC

The federated identity credential for the workload identity federation is functioning correctly in the authentication phase, but the associated service principal lacks the 'AcrPush' role assignment on the Azure Container Registry, which is required for pushing Docker images. Without this role, the registry rejects the push with an authorization error (e.g., 'unauthorized: authentication required' or 'insufficient permissions'), even though the service principal authenticated successfully.

Why this answer

The error 'unauthorized: authentication required' indicates that the Docker client could not authenticate with Azure Container Registry. With workload identity federation, the service principal used by the federated credential must have the 'acrPush' role assigned on the ACR scope to push images. Without this role assignment, the authentication token lacks the necessary permissions, even if the identity itself is valid.

Exam trap

The trap here is that candidates confuse authentication (identity validation) with authorization (permission to act), assuming any valid identity can push to ACR, but ACR requires explicit role assignment even for federated identities.

How to eliminate wrong answers

Option A is wrong because invalid characters in the Docker image tag cause a different error (e.g., 'invalid reference format') and do not trigger authentication failures. Option B is wrong because an incorrect ACR name would result in a 'name unknown' or 'repository not found' error, not an authentication error. Option D is wrong because workload identity federation does not use a client secret; it relies on a federated credential token exchange, so secret expiry is irrelevant.

Full explanation →

191

MCQhard

You are a DevOps engineer at a large enterprise that develops a cloud-native application using microservices architecture. The application consists of 15 microservices, each stored in a separate GitHub repository. Your team uses GitHub Actions for CI/CD and Azure Kubernetes Service (AKS) for production. The current deployment process is manual and error-prone. You need to design an automated CI/CD pipeline that supports the following requirements: 1. Each microservice must have its own build and test pipeline triggered on pull requests and merges to the main branch. 2. Upon merging to main, a container image must be built, tagged with the Git commit SHA, and pushed to Azure Container Registry (ACR). 3. A separate release pipeline must deploy the updated images to AKS using a GitOps approach with Flux v2. 4. The release pipeline must support rolling back to a previous version quickly if a deployment fails. 5. The entire solution must be defined as code to ensure reproducibility. Which approach should you recommend?

A.Create a single monorepo with all microservices. Use GitHub Actions with a multi-branch pipeline that builds only changed services. Deploy to AKS using kubectl commands in the pipeline. For rollback, redeploy the previous image tag.

B.Use Azure Pipelines with a single build pipeline that triggers on any change in any repo using webhooks. Use Azure DevOps Release Pipelines to deploy to AKS using Helm. Store Helm charts in Azure Container Registry. For rollback, use Helm rollback command.

C.Use GitHub Actions for CI and deploy directly to AKS using kubectl in the same workflow. Store Kubernetes manifests in each microservice repo. Use Argo CD to monitor the repos and sync.

D.Use GitHub Actions in each microservice repo for CI to build and push images to ACR. Use a separate GitOps repository that contains Kubernetes manifests. Configure Flux v2 in AKS to sync from the GitOps repo. When a new image is pushed to ACR, update the manifest in the GitOps repo via a GitHub Action, triggering Flux to deploy. For rollback, revert the commit in the GitOps repo.

AnswerD

This pattern correctly separates CI from CD: each microservice repository has its own GitHub Actions workflow to build and push only its image to ACR, preserving independent versioning and team autonomy. Kubernetes manifests live in a dedicated GitOps repository, and Flux v2 running in AKS continuously reconciles the cluster to that repository, so updating an image tag in a commit automatically triggers the deployment. Rollback is simply a git revert of that commit, giving an immutable, auditable, declarative rollout/rollback workflow with Git as the single source of truth—fully satisfying the requirements for GitHub Actions, AKS, and GitOps-based rollback.

Why this answer

It aligns with all requirements: each microservice has its own GitHub Actions CI pipeline (requirement 1), images are built and pushed to ACR with commit SHA tags (requirement 2), a separate GitOps repo with Flux v2 handles deployment to AKS (requirement 3), rollback is achieved by reverting the Git commit (requirement 4), and everything is defined as code in repositories (requirement 5). Option A is wrong because it uses a monorepo, violating the separate repository requirement, and uses kubectl in the pipeline instead of GitOps. Option B is wrong because it uses Azure Pipelines, which is not consistent with GitHub Actions, and uses Helm rollback instead of Git-based rollback.

Option C is wrong because it deploys directly via kubectl in the same workflow, mixing CI and CD, and uses Argo CD instead of Flux v2 as specified.

Full explanation →

192

MCQmedium

A team is implementing a release pipeline for a Node.js application. They want to run integration tests against a temporary environment that is destroyed after the tests complete. Which strategy should they use?

A.Use a separate release pipeline that deploys to a production environment for testing.

B.Use a single release pipeline that deploys to a staging slot and runs tests on the slot.

C.Run integration tests in the build pipeline using a mock environment.

D.Use a release pipeline that deploys to a new Azure App Service instance, runs tests, and then removes the instance.

AnswerD

Using a release pipeline that deploys to a new Azure App Service instance, runs tests, and then removes the instance is correct because it provides an ephemeral, isolated environment that closely mirrors production, enabling realistic integration validation and automatic teardown, which avoids lingering state and reduces cost.

Why this answer

It provisions a dedicated, isolated Azure App Service instance for integration testing, runs the tests against the real environment, and then destroys the instance to avoid ongoing costs. This aligns with the ephemeral environment pattern, ensuring tests validate actual deployment behavior without contaminating shared resources.

Exam trap

The trap here is that candidates often confuse staging slots with ephemeral environments, but staging slots are persistent and not automatically destroyed after testing, whereas a new App Service instance can be fully removed to ensure cost and isolation compliance.

How to eliminate wrong answers

Option A is wrong because deploying to a production environment for testing risks corrupting live data and causing downtime, violating the principle of environment isolation. Option B is wrong because a staging slot is a permanent, shared resource that may not be destroyed after tests, and running tests on the slot does not guarantee a clean, disposable environment. Option C is wrong because running integration tests in the build pipeline with a mock environment bypasses real infrastructure validation, missing critical issues like deployment configuration, network dependencies, and service bindings.

Full explanation →

193

Multi-Selectmedium

Your organization uses Azure Pipelines with multiple release stages. You need to instrument the pipeline to capture the duration of each stage and the number of failed tasks. Which TWO approaches should you use?

Select 2 answers

A.Configure pipeline notifications for failed tasks.

B.Implement a 'runOnce' deployment strategy to ensure sequential stages.

C.Enable the 'Summary' tab in the pipeline run to view stage durations.

D.Use the Azure DevOps REST API to retrieve pipeline run statistics after each run.

E.Add a script task at the end of each stage to log stage duration and task results to a custom log file.

AnswersD, E

The Azure DevOps REST API (e.g., Builds - Get or Timelined endpoints) returns detailed run metadata including stage/task durations, results, and timestamps for every run. Calling this API after each pipeline run lets you programmatically collect and persist the exact statistics needed for performance analysis.

Why this answer

Options D and E are correct. The goal is to capture stage duration and failed task counts. Option D uses the Azure DevOps REST API to programmatically retrieve pipeline run statistics, which includes stage-level durations and failure information.

Option E adds a script task at the end of each stage that logs the stage's duration and task results to a custom log file, providing direct instrumentation. Option A is incorrect because pipeline notifications only alert on failures, they don't capture or log durations. Option B is incorrect because 'runOnce' is a deployment strategy that ensures sequential stages, not an instrumentation method.

Option C is incorrect because the 'Summary' tab in the pipeline run provides a high-level overview, not detailed per-stage duration data that can be programmatically captured.

Full explanation →

194

Multi-Selectmedium

Which THREE are valid deployment patterns for Kubernetes? (Choose three.)

Select 3 answers

A.Canary deployment

B.Rolling update

C.A/B testing deployment

D.Helm deployment

E.Blue-green deployment

AnswersA, B, E

Canary deployment is a valid Kubernetes deployment pattern that incrementally routes a small percentage of live traffic to a new version while monitoring key metrics, gradually increasing the canary's share only when the new version proves stable, thereby reducing blast radius and enabling early rollback.

Why this answer

The correct deployment patterns in Kubernetes are canary, rolling update, and blue-green. A canary deployment releases a new version to a small subset of users first, allowing monitoring and gradual traffic shifting. A rolling update incrementally replaces old pods with new ones, ensuring zero downtime.

A blue-green deployment runs two identical environments and switches traffic from the old (blue) to the new (green) environment after validation. Helm is a package manager, not a deployment pattern, and A/B testing is a traffic management technique rather than a core Kubernetes deployment strategy.

Exam trap

The trap here is that candidates confuse deployment patterns (like canary, rolling, blue-green) with deployment tools (like Helm) or traffic management techniques (like A/B testing), leading them to select options that are not actual Kubernetes rollout strategies.

Full explanation →

195

MCQmedium

Your team uses Azure Repos and needs to prevent secrets from being committed to the repository. Which built-in feature should you enable?

A.Enable GitHub secret scanning

B.Enable Azure Policy to scan repositories

C.Configure a pre-commit hook with a secret scanning tool

D.Enable push protection in Azure Repos

AnswerD

Push protection in Azure Repos is a built-in server-side feature that scans incoming commits for known secrets (such as connection strings, passwords, and API keys) and blocks the push if a secret is detected. This provides centralized, enforced protection that prevents secrets from ever entering the repository, directly addressing the need.

Why this answer

Push protection in Azure Repos is a built-in feature that scans commits for high-confidence secrets (e.g., Azure service connection strings, SSH keys, and other credential patterns) and blocks the push if a secret is detected. This prevents secrets from ever reaching the remote repository, enforcing security at the server side without requiring client-side configuration.

Exam trap

The trap here is that candidates confuse client-side pre-commit hooks (Option C) with a built-in server-side solution, overlooking that hooks can be bypassed and are not enforced, while push protection in Azure Repos is a native, unbypassable guard.

How to eliminate wrong answers

Option A is wrong because GitHub secret scanning is a feature of GitHub, not Azure Repos, and the question specifies the team uses Azure Repos. Option B is wrong because Azure Policy is used for governance and compliance of Azure resources (e.g., VM SKUs, resource locations), not for scanning repository contents for secrets. Option C is wrong because configuring a pre-commit hook is a client-side solution that can be bypassed by developers (e.g., by using --no-verify) and requires manual setup per machine, whereas Azure Repos push protection is a server-side, enforced feature.

Full explanation →

196

Multi-Selecthard

Which THREE are required to set up a self-hosted agent for Azure Pipelines?

Select 3 answers

A.A virtual machine running in Azure.

B.Network connectivity to Azure DevOps services.

C.A Personal Access Token (PAT) to authenticate the agent.

D.An agent pool configured in Azure DevOps and the agent configured to use that pool.

E.Docker installed on the agent machine.

AnswersB, C, D

The agent must be able to establish an HTTPS connection to Azure DevOps services over the network to poll for job assignments, download tasks, and report status. Without network connectivity, the agent cannot participate in pipelines, making this a fundamental requirement for any self-hosted agent.

Why this answer

B is correct because the self-hosted agent must communicate with Azure Pipelines to receive job assignments and report status. This requires outbound HTTPS connectivity (port 443) to Azure DevOps services (e.g., dev.azure.com). Without network connectivity, the agent cannot register, poll for jobs, or send logs, making it non-functional.

Exam trap

The trap here is that candidates assume a self-hosted agent must run on an Azure VM (Option A) or require Docker (Option E), when in fact the only infrastructure requirements are network connectivity and authentication, with the agent pool configuration tying it all together.

Full explanation →

197

MCQmedium

Your organization uses GitHub Actions for CI/CD. You have a workflow that builds and deploys a containerized application to Azure Kubernetes Service (AKS). The workflow uses the 'azure/aks-set-context' action to connect to the AKS cluster. Recently, the workflow started failing with authentication errors. The service principal used has Contributor role on the AKS cluster. What is the most likely cause?

A.The service principal must have 'Owner' role on the resource group containing the AKS cluster.

B.The service principal lacks the 'Azure Kubernetes Service Cluster Admin Role' on the AKS cluster.

C.The workflow uses an incorrect Kubernetes version.

D.The AKS cluster has RBAC disabled, causing authentication failures.

AnswerB

The Azure CLI action 'aks get-credentials --admin' requires the service principal to have the 'Azure Kubernetes Service Cluster Admin Role' on the AKS cluster. This role grants the Microsoft.ContainerService/managedClusters/listClusterAdminCredential/action permission, which is mandatory for retrieving the cluster-admin kubeconfig; without it, the workflow fails during the credential download step with an authorization error.

Why this answer

The 'azure/aks-set-context' action requires the service principal to have the 'Azure Kubernetes Service Cluster Admin Role' (or 'Azure Kubernetes Service Cluster User Role') on the AKS cluster to authenticate and set the kubectl context. The Contributor role on the AKS cluster resource does not grant the necessary Kubernetes RBAC permissions to interact with the cluster's API server. Without the specific AKS role, the action fails with authentication errors.

Exam trap

The trap here is that candidates assume the Contributor role on the AKS resource is sufficient for all operations, but Azure separates Azure RBAC (for managing the AKS resource) from Kubernetes RBAC (for interacting with the cluster), and the 'azure/aks-set-context' action specifically requires the AKS Cluster Admin or User Role.

How to eliminate wrong answers

Option A is wrong because the 'Owner' role on the resource group is not required; the service principal only needs the 'Azure Kubernetes Service Cluster Admin Role' on the AKS cluster itself, not Owner on the resource group. Option C is wrong because an incorrect Kubernetes version would cause deployment or compatibility issues, not authentication errors when setting the cluster context. Option D is wrong because disabling RBAC on the AKS cluster would actually reduce authentication requirements, not cause authentication failures; the error is due to missing role assignment, not RBAC being disabled.

Full explanation →

198

Multi-Selectmedium

Which TWO actions should you take to implement a CI/CD pipeline for a microservices application using Azure Pipelines? (Choose two.)

Select 2 answers

A.Use a classic release pipeline instead of YAML for the deployment stages.

B.Publish build artifacts and use them in the release stages.

C.Store deployment credentials directly in the YAML file.

D.Use a multi-stage YAML pipeline that includes build, test, and deploy stages.

E.Create a separate pipeline for each microservice.

AnswersB, D

Publishing build artifacts is essential because it decouples the build phase from the release phase, producing an immutable, versioned binary that can be downloaded by any downstream stage or release pipeline. The Publish Pipeline Artifact task stores files in Azure Pipelines and associates them with the run, so the exact bits that passed tests are the ones deployed, eliminating drift between environments and supporting reliable rollback because each deployment can reference a known artifact version. Without this, release stages would have to rebuild or restore packages, breaking reproducibility and atomic deployment.

Why this answer

Option B is correct because publishing build artifacts (via the PublishBuildArtifacts or PublishPipelineArtifact task) creates an immutable, versioned output that downstream deployment stages can consume, ensuring the same tested binaries are promoted across environments rather than rebuilt. Option D is correct because a multi-stage YAML pipeline natively models build, test, and deploy stages in a single versioned definition, enabling CI/CD with stage dependencies, gates, and environment approvals as code. Option A is not appropriate because classic release pipelines are the legacy, UI-based approach and do not provide the pipeline-as-code benefits expected for a modern microservices CI/CD implementation.

Option C is wrong because storing deployment credentials directly in YAML exposes secrets in source control; secrets should be kept in Azure Key Vault or variable groups linked to the pipeline. Option E is not required because a single multi-stage YAML pipeline can build and deploy multiple microservices using templates, paths filters, or matrix strategies, so a separate pipeline per microservice is not a necessary action.

Exam trap

The trap is thinking that classic release pipelines are still preferred or that separate pipelines per microservice are necessary, when modern best practices favor YAML multi-stage pipelines and artifact reuse.

Full explanation →

199

Multi-Selecthard

You are designing a security compliance plan for a GitHub Enterprise environment. Which THREE practices should you implement? (Select THREE.)

Select 3 answers

A.Disable two-factor authentication for automation accounts

B.Allow repository admins to bypass branch protection rules

C.Configure branch protection rules to require pull request reviews

D.Enable Dependabot alerts for dependency vulnerability monitoring

E.Enable secret scanning to detect accidental credential commits

AnswersC, D, E

Requiring pull request reviews ensures that every change is reviewed by at least one other collaborator before merging, enforcing code quality and reducing the risk of introducing vulnerabilities or broken code. It also provides a clear audit trail of who approved each change, which is essential for compliance.

Why this answer

Branch protection rules with required pull request reviews enforce mandatory code review before merging, Dependabot alerts automatically monitor dependency vulnerabilities, and secret scanning detects accidental credential commits. Together these practices strengthen security compliance in GitHub Enterprise.

Exam trap

The trap here is that candidates may confuse automation account security with human user security, incorrectly assuming that 2FA can be disabled for automation accounts, or they may think bypassing branch protection is acceptable for admins, when in fact compliance requires consistent enforcement across all users.

Full explanation →

200

MCQeasy

Your team uses GitHub Actions to build a Docker image and push it to Azure Container Registry (ACR). The workflow fails with the error 'unauthorized: authentication required'. The workflow uses the 'azure/docker-login@v1' action. What is the most likely cause?

A.The 'azure/docker-login@v1' action does not support ACR.

B.The Dockerfile is not in the repository root.

C.The service principal used for authentication lacks the AcrPush role on the ACR.

D.The workflow uses the registry admin credentials, which are disabled.

AnswerC

To push an image to Azure Container Registry, the authenticated identity (here, the service principal) must have the AcrPush role granted on the registry. If that role is missing, docker login succeeds but docker push fails with a permissions error, making this the likeliest root cause of the push failure.

Why this answer

The 'azure/docker-login@v1' action authenticates Docker with Azure Container Registry using a service principal. If the service principal lacks the AcrPush role, Docker login succeeds but the subsequent push fails with 'unauthorized: authentication required' because the identity does not have permission to push images. The error occurs at push time, not login time, which is a key diagnostic clue.

Exam trap

The trap here is that candidates assume the error means the login itself failed, but the 'azure/docker-login@v1' action can succeed with a valid service principal that lacks push permissions, and the 'unauthorized' error surfaces only during the subsequent docker push, leading test-takers to incorrectly suspect admin credentials or Dockerfile location.

How to eliminate wrong answers

Option A is wrong because 'azure/docker-login@v1' explicitly supports ACR by accepting a username and password (from a service principal) and logging in to the ACR login server. Option B is wrong because the location of the Dockerfile does not affect authentication; it only affects the build context and is unrelated to the 'unauthorized' error. Option D is wrong because if the workflow used registry admin credentials (which are disabled), the error would be 'authentication required' at login, not at push, and the question does not indicate admin credentials are being used; the action defaults to service principal authentication.

Full explanation →

201

MCQmedium

A company recently migrated its CI/CD pipelines from Jenkins to Azure Pipelines. The development team is experiencing frequent build failures due to conflicting changes when multiple developers push code simultaneously. The team wants to maintain a linear history and avoid merge commits. Which strategy should you recommend?

A.Switch to Git with a central repository and require merge commits.

B.Enforce a rebase strategy for all pull requests in the branch policy.

C.Use Team Foundation Version Control (TFVC) with exclusive checkout enabled.

D.Configure Azure Repos to use squash merge when completing pull requests.

AnswerC

TFVC with exclusive checkout is correct because it enables server-side, per-file locking: as soon as one developer checks out a file, any other user's attempt to check out that same file is blocked until the first check-in, thereby ensuring no concurrent edits can create conflicts and enforcing a strictly linear history over the shared files.

Why this answer

Team Foundation Version Control (TFVC) with exclusive checkout enforces a lock on a file when a developer checks it out, preventing simultaneous edits. This eliminates conflicting changes that cause build failures when multiple developers push code concurrently, and since TFVC does not use merge commits, it maintains a linear history. The scenario explicitly requires avoiding merge commits and resolving conflicts from simultaneous pushes, which TFVC’s exclusive checkout directly addresses.

Exam trap

The trap here is that candidates often assume Git-based strategies (like rebase or squash merge) can prevent simultaneous push conflicts, but they only manage how history looks after a merge, not the underlying conflict that occurs when two developers push changes to the same file at the same time.

How to eliminate wrong answers

Option A is wrong because switching to Git with a central repository and requiring merge commits would introduce merge commits, violating the requirement to maintain a linear history and avoid merge commits. Option B is wrong because enforcing a rebase strategy for pull requests in Git still allows conflicting changes when multiple developers push simultaneously; rebase rewrites commit history but does not prevent conflicts at the push stage, and it can lead to non-linear history if not handled carefully. Option D is wrong because configuring Azure Repos to use squash merge when completing pull requests collapses all commits into one, but it still requires a pull request and merge operation, which can introduce merge commits if conflicts arise, and it does not prevent simultaneous push conflicts; squash merge is about commit history compression, not conflict prevention.

Full explanation →

202

MCQhard

Your organization uses Azure DevOps and wants to enforce that all pipelines use a specific set of approved tasks. How can you achieve this?

A.Use the task restrictions feature in Azure DevOps to block unapproved tasks

B.Assign permissions to the task group to limit who can add tasks

C.Create a YAML template with the approved tasks and require all pipelines to use it

D.Configure a service hook to notify when an unapproved task is used

AnswerA

Use the task restrictions feature in Azure DevOps to block unapproved tasks: This organization-level policy lets you explicitly whitelist approved task IDs; any pipeline attempt to use a task outside the list is blocked or produces a warning, providing actual enforcement at the pipeline execution level rather than relying on user compliance.

Why this answer

Use the task restrictions feature in Azure DevOps to block unapproved tasks. Azure DevOps provides a 'Task restrictions' policy under Organization Settings > Policies > Add new policy, where you can specify which tasks are allowed or blocked across all pipelines. This enforces that only approved tasks are used.

Option B is incorrect because assigning permissions to a task group only controls who can modify the group, not which tasks are used in pipelines. Option C is incorrect because while YAML templates can standardize tasks, they do not enforce mandatory usage; pipelines can still be created without the template. Option D is incorrect because service hooks only trigger notifications when an unapproved task is used, but do not block its usage.

Full explanation →

203

MCQmedium

You are designing a security compliance plan for Azure Pipelines. The plan must ensure that no pipeline can use variables containing secrets unless those variables are stored in Azure Key Vault and referenced via a variable group linked to Key Vault. What is the best way to enforce this across all pipelines in an Azure DevOps organization?

A.Create a YAML template that mandates the use of Key Vault references.

B.Implement an Azure Policy that audits variable groups and requires Key Vault integration.

C.Require manual approval for all pipeline runs that use variables.

D.Use branch policies to prevent merging code that contains secrets.

AnswerA

A YAML template can enforce secure secret management across all pipelines by defining a standard structure that must be extended. Using the Azure DevOps 'required template' feature (under project settings or via pipeline decorators), you can force every pipeline to use a template that injects an AzureKeyVault task or a Key Vault-linked variable group, and optionally includes a script that fails the build if any inline secrets are detected. This gives you a central, versioned mechanism to mandate Key Vault references, which is enforceable at queue time rather than relying on manual review.

Why this answer

You can enforce a YAML template at the organization level using required template policies. This ensures all pipelines include a template that mandates Key Vault references for secrets, providing a scalable enforcement mechanism. Option B is incorrect because Azure Policy applies to Azure resources, not Azure DevOps constructs like variable groups.

Option C is incorrect because manual approvals do not enforce Key Vault usage. Option D is incorrect because branch policies control code, not variable usage during execution.

Full explanation →

204

MCQmedium

Your build pipeline uses the 'NuGetCommand@2' task to restore NuGet packages. You want to use packages from an Azure Artifacts feed that requires authentication. How should you configure the pipeline to authenticate with the feed?

A.Store the Personal Access Token (PAT) in a variable and use it in the NuGet config.

B.Create an Azure Artifacts service connection and select it in the NuGet task.

C.Add a 'NuGetAuthenticate@1' task before the NuGet restore task.

D.Install the NuGet credential provider on the agent manually.

AnswerC

NuGetAuthenticate@1 injects credentials for Azure Artifacts feeds into the NuGet configuration at runtime, authenticating via the pipeline's service connection or Microsoft Entra ID identity. Placing it before NuGetCommand@2 satisfies the stem's requirement that the authenticated feed restore succeeds without hard-coded credentials in nuget.config.

Why this answer

The 'NuGetAuthenticate@1' task is the correct way to authenticate with Azure Artifacts feeds in a pipeline because it automatically handles credential acquisition using the built-in Azure Artifacts credential provider. It works without needing to store or manage Personal Access Tokens (PATs) manually, and it integrates seamlessly with the pipeline's identity (e.g., the project collection build service). This task must be placed before the 'NuGetCommand@2' restore task to ensure the credentials are available for package restoration.

Exam trap

The trap here is that candidates often confuse service connections (which are used for external services like GitHub or generic endpoints) with the built-in Azure Artifacts authentication, leading them to select Option B, but Azure Artifacts feeds do not require a service connection because authentication is handled automatically via the pipeline's identity and the 'NuGetAuthenticate@1' task.

How to eliminate wrong answers

Option A is wrong because storing a PAT in a variable and using it in a NuGet config is a manual, less secure approach that requires managing token expiration and rotation, whereas Azure Artifacts provides a built-in authentication mechanism via the credential provider. Option B is wrong because an Azure Artifacts service connection is not a valid connection type for the 'NuGetCommand@2' task; the task expects a NuGet service connection (e.g., external feed) or relies on the 'NuGetAuthenticate@1' task for Azure Artifacts feeds. Option D is wrong because manually installing the NuGet credential provider on the agent is unnecessary and not a pipeline configuration step; the 'NuGetAuthenticate@1' task handles this automatically on Microsoft-hosted agents and can be configured for self-hosted agents.

Full explanation →

205

MCQmedium

The pipeline fails with the error 'The resource with name 'myregistry' could not be found'. What is the most likely cause?

A.The Azure Container Registry name is incorrect

B.The build ID variable is not defined

C.The service connection does not have permission to access the registry

D.The Azure CLI is not installed on the agent

AnswerA

The error 'resource with name m' indicates Azure DevOps cannot locate the specified Azure Container Registry (ACR) resource, which means the registry name provided in the task or variable does not exist or is misspelled in the current subscription/tenant. A correct ACR name must exactly match the globally unique registry name (e.g., 'myregistry.azurecr.io' without the domain), and any typo or mismatch will result in a 'not found' exception, not an authentication or CLI failure.

Why this answer

The error 'The resource with name 'myregistry' could not be found' indicates that the pipeline is trying to reference an Azure Container Registry that does not exist or is misspelled. The most likely cause is that the registry name in the pipeline configuration is incorrect, such as a typo or wrong environment variable. This is a resource resolution error, not a permissions or tooling issue.

Exam trap

AZ-400 often tests the distinction between resource-not-found errors and permission errors; candidates may incorrectly choose the service connection permission option when the error explicitly says the resource could not be found.

How to eliminate wrong answers

Option B is wrong because an undefined build ID variable would typically cause a different error related to variable expansion, not a resource-not-found message for a registry. Option C is wrong because insufficient permissions would produce an authorization error (e.g., 403 Forbidden), not a resource-not-found error. Option D is wrong because a missing Azure CLI would cause a command-not-found error, not a registry lookup failure.

Full explanation →

206

MCQhard

You are configuring a multi-stage YAML pipeline that deploys to Azure App Service. The deployment stage must use a service connection with least privilege. You create a service connection using the Azure Resource Manager service connection type. Which authentication method should you choose to avoid storing a client secret?

A.Workload identity federation (automatic)

B.Managed identity

C.Publish profile

D.Service principal (automatic)

AnswerA

Workload identity federation allows Azure Pipelines to authenticate to Azure without storing a secret. It uses OpenID Connect (OIDC) to obtain short-lived tokens. This is the recommended method for least privilege and secretless authentication. It eliminates the need to manage and rotate client secrets, reducing security risks and administrative overhead.

Why this answer

Workload identity federation (automatic) is the correct choice because it uses OpenID Connect to authenticate without storing a secret. The Azure DevOps service connection exchanges a token from Azure Pipelines with Microsoft Entra ID to obtain an access token. This method aligns with least privilege and secretless authentication, as no client secret is persisted in the service connection.

Exam trap

The trap here is assuming that service principal (automatic) is secretless, but it actually creates and stores a client secret that must be rotated.

Full explanation →

207

MCQmedium

Your release pipeline deploys to Azure App Service using a deployment slot. You need to ensure that after swapping slots, the staging slot retains the previous production configuration for rollback. Which deployment strategy should you use?

A.Rolling deployment

B.Blue-green deployment

C.Swap with preview

D.Canary deployment

AnswerC

Swap with preview is correct because it deploys the new build to a staging slot, allows you to validate it before performing a manual swap, and retains the previous configuration in the staging slot for easy rollback. This is the standard Azure App Service pattern for safe, zero-downtime releases.

Why this answer

Swap with preview (multi-phase swap) is the correct strategy because it uses Azure App Service deployment slots to validate the staged version before completing the swap. When the swap is completed, the staging slot receives the previous production code and configuration, preserving a rollback state. If a problem occurs, you can swap back to the staging slot.

Note that a standard slot swap also preserves the previous production state in staging, but swap with preview adds the benefit of preview validation before finalizing the swap, which aligns with the requirement of maintaining rollback capability.

Exam trap

The trap is that candidates may confuse general deployment strategies like blue-green or canary with Azure App Service's slot swap mechanics. While blue-green deployment is conceptually similar, the specific Azure feature that uses deployment slots and supports preview validation before swap is 'swap with preview'. A common mistake is to think a standard swap does not retain the previous production configuration in the staging slot, but in reality it does; the key differentiator of swap with preview is the preview phase that allows you to validate the app before the swap is finalized.

How to eliminate wrong answers

Option A is wrong because rolling deployment gradually replaces instances of the application with the new version, but it does not use deployment slots and does not inherently retain the previous production configuration in a separate slot for immediate rollback. Option B is wrong because blue-green deployment typically involves two separate environments (e.g., two App Service slots) and a full swap, but without the 'swap with preview' feature, the previous production configuration is overwritten in the staging slot during the swap, losing the rollback state. Option D is wrong because canary deployment routes a small percentage of traffic to the new version while keeping the old version running, but it does not use Azure App Service deployment slots for a full swap and does not guarantee that the staging slot retains the previous production configuration after the canary completes.

Full explanation →

208

Multi-Selectmedium

Which THREE practices are recommended for effective source control in a GitHub monorepo? (Choose three.)

Select 3 answers

A.Store large binary files directly in the repository

B.Use branch protection rules to enforce CI checks

C.Use a single build definition for all projects

D.Use code owners to automatically request reviewers

E.Use path filters to trigger only relevant CI workflows

AnswersB, D, E

Branch protection rules on the main branch require status checks to pass before merging, so every pull request in the monorepo is validated by CI. This enforces the stem's requirement for effective source control practise in a GitHub monorepo.

Why this answer

Option B is correct because branch protection rules on a monorepo's shared branches (e.g., main) can require status checks from CI workflows to pass before merging, preventing broken code from entering a repository that many teams depend on. Option D is correct because a CODEOWNERS file maps paths to owners and automatically requests the appropriate reviewers for pull requests, which is essential in a monorepo where different directories belong to different teams. Option E is correct because path filters (e.g., the paths: key in GitHub Actions workflow triggers) ensure that a change in one project only runs the CI workflows relevant to that path, avoiding unnecessary builds across the whole monorepo.

Option A is not recommended because large binaries bloat repository history and should instead be handled with Git LFS or external artifact storage, and option C is not recommended because a single build definition for all projects reduces isolation and forces unrelated projects to rebuild together, whereas per-project or path-filtered build definitions are preferred.

Exam trap

The trap here is that candidates confuse 'monorepo best practices' with 'single repo simplicity' and incorrectly assume a single build definition is efficient, when in reality path-filtered, modular CI is essential to avoid unnecessary builds and long feedback loops.

Full explanation →

209

MCQmedium

You are designing a release pipeline for a Node.js application that deploys to Azure App Service. The pipeline must run integration tests against the deployed application. You want to use deployment slots to minimize downtime. What is the recommended approach?

A.Deploy to a staging slot, run tests against the staging slot, then swap to production.

B.Deploy to the production slot directly and run tests after deployment.

C.Deploy to a staging slot, swap, then run tests.

D.Deploy to a staging slot, run tests, then delete the staging slot.

AnswerA

Deploying to a staging slot allows the new build to run in a production-like environment, where automated and smoke tests validate functionality without affecting live users; the subsequent swap is atomic and fast, switching the production slot to the staged version with zero downtime and preserving the previous deployment for immediate rollback if needed.

Why this answer

Deploying to a staging slot first allows you to validate the application by running integration tests against the staging slot without impacting production traffic. After successful testing, swapping the staging slot with the production slot ensures zero-downtime deployment, as Azure App Service swaps the underlying virtual directories and configuration settings instantly.

Exam trap

The trap here is that candidates often confuse the order of operations, mistakenly thinking swapping before testing (Option C) is acceptable, but this would bypass the validation that slots are designed to provide.

How to eliminate wrong answers

Option B is wrong because deploying directly to the production slot and running tests after deployment risks exposing untested code to live users and can cause downtime if tests fail. Option C is wrong because swapping before running tests means the staging slot becomes production, and any issues found during testing would already be live, defeating the purpose of using slots for safe validation. Option D is wrong because deleting the staging slot after testing discards the validated deployment, requiring a redeployment to production and losing the ability to swap back if issues arise.

Full explanation →

210

MCQmedium

You have a multi-stage pipeline that deploys to multiple regions. You want to ensure that if the deployment to one region fails, the pipeline does not proceed to the next region. What is the best way to implement this?

A.Use pipeline decorators to inject error handling steps.

B.Add a manual approval between regions.

C.Configure each region deployment as a separate stage with no dependencies.

D.Define stage dependencies with 'dependsOn' and set 'condition' to 'succeeded()'.

AnswerD

Setting `dependsOn` with `condition: succeeded()` makes each regional stage run only when every preceding dependency completed successfully, so a failed region halts downstream stages. This directly satisfies the stem's requirement that the pipeline must not proceed to the next region after a failure, using native YAML stage gating rather than manual checks.

Why this answer

Azure Pipelines allows you to define stage dependencies using 'dependsOn' and control execution flow with 'condition'. By setting each region deployment as a separate stage that depends on the previous region's stage succeeding (condition: 'succeeded()'), the pipeline will automatically halt if any region deployment fails, preventing progression to subsequent regions.

Exam trap

The trap here is that candidates often confuse manual approvals (Option B) with automatic failure handling, not realizing that approvals only pause for human input and do not inherently stop the pipeline on a deployment failure.

How to eliminate wrong answers

Option A is wrong because pipeline decorators are used to inject steps into every pipeline or stage automatically (e.g., for compliance or security checks), not to implement conditional stage execution based on previous stage success. Option B is wrong because manual approvals pause the pipeline for human intervention but do not automatically prevent progression on failure; they require manual action and do not react to deployment failures. Option C is wrong because configuring stages with no dependencies means they run in parallel or independently, which would allow deployment to other regions even if one fails, defeating the requirement to stop on failure.

Full explanation →

211

MCQmedium

You are reviewing the branch protection policy for the main branch in an Azure DevOps repository. Based on the exhibit, what happens when a stale review exists on a pull request after new changes are pushed?

A.Admins are exempt from the review requirement

B.The stale review is automatically dismissed, and the PR requires new approvals

C.The PR still requires only 2 approvals, but stale reviews are not dismissed

D.The PR can be merged even without the required reviews

AnswerB

Because `dismissStaleReviews` is enabled, any approval given before a new commit that changes the code is automatically dismissed, and the PR must obtain fresh approvals from the required number of reviewers before it can be completed.

Why this answer

The branch protection policy for the main branch has 'Reset code reviewer votes when there are new changes' enabled. When a stale review exists after new changes are pushed, Azure DevOps automatically dismisses the previous approval(s) and requires new approvals to meet the minimum number of reviewers (2). This ensures that reviewers re-evaluate the latest code changes before the pull request can be merged.

Exam trap

The trap here is that candidates may confuse 'stale reviews are not dismissed' with the default behavior of Azure DevOps, but the exhibit explicitly shows the 'Reset code reviewer votes when there are new changes' checkbox is enabled, which forces dismissal.

How to eliminate wrong answers

Option A is wrong because the exhibit does not show any exemption for admins from the review requirement; the policy applies equally to all users unless explicitly configured otherwise. Option C is wrong because when 'Reset code reviewer votes when there are new changes' is enabled, stale reviews are dismissed, not retained. Option D is wrong because the policy still requires the minimum number of approvals (2) to be met; the PR cannot be merged without the required reviews.

Full explanation →

212

MCQhard

You are debugging a production issue using Application Insights Snapshot Debugger. The exhibit shows a snapshot from a NullReferenceException. The variable _dbContext is null. What is the most likely root cause?

A.The call to the database is not awaited, causing a race condition.

B.The DbContext is not registered in the dependency injection container.

C.The database connection string is invalid in appsettings.json.

D.The OnGet method is missing a null check for _dbContext before usage.

AnswerB

A null _dbContext at runtime indicates the dependency injection container never supplied the instance. If DbContext were registered, constructor injection would populate it; its absence means the service was not added to the container during startup configuration.

Why this answer

In ASP.NET Core, when a constructor-injected service like a DbContext is null at runtime, the most likely root cause is that the service (the DbContext) has not been registered in the dependency injection container. Page models themselves do not require registration. The missing null check (Option D) is a symptom, not the root cause, and the other options are unrelated.

Exam trap

Candidates may mistakenly choose Option D (missing null check) because it directly prevents the exception, but the root cause is the missing DI registration.

How to eliminate wrong answers

Option A is wrong because an unawaited database call would cause a race condition or incomplete operation, but the snapshot clearly shows _dbContext is null, not that the call was started and not completed. Option C is wrong because an invalid connection string would cause a runtime exception when the DbContext attempts to open a connection, not a NullReferenceException from a null _dbContext variable. Option D is wrong because while adding a null check would prevent the crash, it does not address the root cause—the missing DI registration—and would only mask the underlying configuration error.

Full explanation →

213

MCQmedium

You have a release pipeline that deploys to multiple environments. You need to ensure that a manual approval is required before deploying to production. What should you configure?

A.Add a manual intervention task in the production stage

B.Set a post-deployment approval on the production stage

C.Set a pre-deployment approval on the production stage

D.Set a branch policy on the release branch

AnswerC

A pre-deployment approval is a release-stage gate that pauses the pipeline immediately before the production stage starts, and it requires a designated approver or approval group to explicitly approve the deployment. This ensures the artifact is not deployed to production until manual authorization is granted, and Azure Pipelines records the approver, timestamp, and any comments for full auditability. Unlike branch policies or post-deployment hooks, this mechanism directly satisfies the requirement to approve before production deployment and provides a clean separation of duties between build and release. Additionally, you can configure policies such as re-approval if the artifact changes, making it the correct, policy-driven approach.

Why this answer

Pre-deployment approvals are configured on a stage in Azure Pipelines to require manual sign-off before any deployment to that stage begins. Since the question specifies that approval is needed before deploying to production, a pre-deployment approval on the production stage enforces that gate before the release pipeline executes any deployment tasks in that environment.

Exam trap

The trap here is confusing pre-deployment approvals with post-deployment approvals or manual intervention tasks, as candidates often think a manual task can substitute for a formal approval gate, but only pre-deployment approvals enforce the 'before deployment' requirement with proper workflow and audit trail.

Why the other options are wrong

Manual intervention task is for classic releases, but approvals are a better fit and work in YAML too.

Post-deployment approval occurs after deployment, not before.

Branch policies affect pull requests, not release pipelines.

Full explanation →

214

MCQhard

You are the DevOps lead for a large enterprise that uses GitHub for source control and Azure Pipelines for CI/CD. The organization has hundreds of repositories, each with its own pipeline. Recently, the security team mandated that all pipelines must use a centralized set of tasks for secret scanning and compliance checks before any deployment. You need to design a solution that enforces these mandatory tasks across all pipelines without modifying each pipeline individually. The solution should allow pipeline authors to add their own custom steps after the mandatory steps. The mandatory steps must be versioned and updated centrally. You also need to ensure that the mandatory steps are not bypassed by pipeline authors. What should you do?

A.Store the mandatory tasks as a YAML template in a central repository. In each pipeline, use the 'template' reference to include the mandatory steps. Use branch protection rules on the central repository to require approval for changes to the template.

B.Use a global list of tasks in the Azure DevOps organization settings that automatically get injected into every pipeline.

C.Create a single pipeline that runs across all repositories and include the mandatory tasks in that pipeline.

D.Create a custom Azure DevOps extension that adds the mandatory tasks to all pipelines using a pre-job hook.

AnswerD

Custom Azure DevOps extensions cannot reliably enforce mandatory tasks in all pipelines because extensions must be installed and are not automatically injected into every pipeline. There is no supported pre-job hook in the extension model that can force tasks to run; pipeline authors can simply omit or disable the extension, so it does not provide central enforcement.

Why this answer

D is correct. A custom Azure DevOps extension with a pre-job hook (pipeline decorator) automatically injects mandatory steps into every pipeline without requiring changes to individual pipelines. It is centrally managed and versioned, and cannot be bypassed by pipeline authors.

A is incorrect because it requires adding a template reference to each pipeline and the template inclusion is optional; branch protection only prevents tampering with the template, not its omission. B is invalid because Azure DevOps has no global task list injection. C is invalid because a single pipeline cannot run across all repositories with custom steps.

Exam trap

A YAML template with branch protection is often mistaken for an enforcement mechanism, but it does not require pipelines to include the template.

Full explanation →

215

MCQhard

You are designing a pipeline that deploys to an Azure Kubernetes Service (AKS) cluster. You need to securely pass the Kubernetes cluster credentials to the pipeline without hardcoding them. Which approach should you use?

A.Store credentials in a pipeline variable with 'secret' type.

B.Use a variable group linked to Azure Key Vault.

C.Hardcode the credentials in the pipeline YAML.

D.Use a secure file in the pipeline library.

AnswerB

A variable group linked to Azure Key Vault securely references secrets stored in Key Vault, so Azure DevOps fetches the current values at pipeline runtime rather than storing them in the pipeline definition. This leverages Key Vault's RBAC, versioning, and rotation, and allows the same service principal to be used across many pipelines without exposing it in YAML.

Why this answer

Azure Key Vault provides a secure, centralized store for secrets like Kubernetes cluster credentials, and linking a variable group to Key Vault allows the pipeline to dynamically retrieve those secrets at runtime without exposing them in the pipeline definition or logs. This approach follows the principle of least privilege and ensures credentials are never hardcoded or stored in plaintext within the pipeline.

Exam trap

The trap here is that candidates may think a pipeline secret variable is sufficient for security, but Azure DevOps specifically recommends using Key Vault for production-grade secret management to avoid storing secrets in the pipeline's internal database and to enable centralized lifecycle management.

Why the other options are wrong

While secure, it does not leverage Key Vault for secret management and rotation.

This is insecure and violates best practices.

Secure files are for files like certificates, not for credentials; but they can be used for kubeconfig, but variable group with Key Vault is more direct.

Full explanation →

216

MCQhard

Your organization uses Azure DevOps and has a strict compliance requirement: all changes to the main branch must be reviewed by at least two members of the 'ComplianceTeam' group. Additionally, a static code analysis tool must run and its results must be published to the pull request. The ComplianceTeam is a custom group defined in Azure DevOps, not a Microsoft Entra ID group. The team wants to enforce this using branch policies. You need to configure the minimum number of reviewers and also ensure that the code analysis results are visible to reviewers. What should you do?

A.Add a branch policy 'Require a minimum number of reviewers' set to 2, and specify the ComplianceTeam as required reviewers. Additionally, add a build policy that runs the code analysis and publishes results as a build summary.

B.Add a branch policy 'Require code owner review' and define the ComplianceTeam as code owners in a CODEOWNERS file.

C.Add a branch policy 'Comment resolution' and configure the ComplianceTeam to resolve comments.

D.Add a branch policy 'Automatically included reviewers' and set the ComplianceTeam to be automatically added to all PRs.

AnswerA

Setting 'Require a minimum number of reviewers' to 2 and specifying ComplianceTeam as required reviewers enforces exactly two approvals from that team before a pull request can be merged. Because required reviewers are mandatory, any approval from a team member counts toward the minimum, and the policy blocks the merge until both approvals are present. Adding a build policy that runs code analysis and publishes results as a build summary integrates the compliance gate directly into the PR, giving reviewers the evidence needed to approve confidently. This combination fully satisfies the strict compliance requirement.

Why this answer

The 'Require a minimum number of reviewers' branch policy enforces that at least two members from the ComplianceTeam must approve the pull request. Adding a build policy that runs static code analysis and publishes results as a build summary ensures the analysis output is visible directly in the PR, meeting the compliance requirement for both reviewer count and code analysis visibility.

Exam trap

The trap here is that candidates often confuse 'Automatically included reviewers' (which only adds reviewers but does not enforce approval) with 'Require a minimum number of reviewers' (which enforces the actual approval count), leading them to choose Option D instead of A.

How to eliminate wrong answers

Option B is wrong because 'Require code owner review' only mandates that a code owner (defined in a CODEOWNERS file) must approve changes to specific files; it does not enforce a minimum number of reviewers or require two specific members from the ComplianceTeam. Option C is wrong because 'Comment resolution' only tracks whether comments on a PR are resolved, not reviewer count or code analysis visibility. Option D is wrong because 'Automatically included reviewers' merely adds the ComplianceTeam as optional reviewers to the PR but does not enforce that at least two of them must approve the changes.

Full explanation →

217

MCQeasy

Your pipeline uses a multi-stage YAML file. You want to conditionally run a stage only when the build is triggered from the 'main' branch. Which expression should you use in the 'condition' property of the stage?

A.startsWith(variables['Build.SourceBranch'], 'main')

B.eq(variables['Build.SourceBranchName'], 'refs/heads/main')

C.eq(variables['Build.SourceBranch'], 'refs/heads/main')

D.eq(variables['Build.SourceBranch'], 'main')

AnswerC

This condition is correct because Build.SourceBranch contains the complete Git ref path, and comparing it directly to the exact string 'refs/heads/main' uniquely identifies the main branch without matching maintenance or other similarly named branches. It is the precise and recommended way to gate on the main branch in Azure Pipelines.

Why this answer

The `Build.SourceBranch` variable in Azure Pipelines contains the full Git ref path (e.g., `refs/heads/main`). The `condition` property evaluates expressions at runtime, and using `eq(variables['Build.SourceBranch'], 'refs/heads/main')` precisely matches the full ref for the main branch, ensuring the stage runs only when the trigger originates from that branch.

Exam trap

The trap here is that candidates often confuse `Build.SourceBranch` (full ref) with `Build.SourceBranchName` (short name) or assume a simple substring match like `startsWith` is sufficient, leading them to pick options that either compare the wrong variable or use an imprecise matching function.

How to eliminate wrong answers

Option A is wrong because `startsWith(variables['Build.SourceBranch'], 'main')` would incorrectly match branches like `main-feature` or `maintenance` since it only checks the prefix, not the exact ref. Option B is wrong because `Build.SourceBranchName` contains only the short branch name (e.g., `main`), not the full ref path `refs/heads/main`, so the comparison fails. Option D is wrong because `Build.SourceBranch` always includes the full ref path (e.g., `refs/heads/main`), so comparing it to just `'main'` will never evaluate to true.

Full explanation →

218

MCQmedium

Your team uses Azure Pipelines to build a .NET Core application. The build runs successfully on Windows agents, but you need to also run the build on Linux agents to validate cross-platform compatibility. The pipeline currently has a single `windows-latest` agent pool. What is the most efficient way to run the build on both platforms without duplicating the entire pipeline?

A.Create two separate pipelines, one for each platform.

B.Use a multi-job pipeline with two jobs, each specifying a different pool.

C.Use a multi-stage pipeline with a stage for each platform.

D.Add a `strategy` with a `matrix` that specifies `vmImage: ['windows-latest', 'ubuntu-latest']` in the job.

AnswerD

Adding a `strategy` with a `matrix` to a job instructs Azure Pipelines to expand that job into multiple job instances at queue time, each with the same steps but with the matrix variables assigned from a specific entry. By mapping a variable like `vmImage` to `['windows-latest', 'ubuntu-latest']` and then referencing it via `$(vmImage)` in the pool specification, the same job runs simultaneously on both Windows and Linux agents, producing a true parallel cross-platform build. This is the idiomatic Azure Pipelines pattern because it keeps the job logic in one place, eliminates duplication, and makes adding or removing a platform as simple as editing a list in the matrix.

Why this answer

Using a `strategy` with a `matrix` allows the same job to run on multiple agent pools in parallel, enabling cross-platform validation without duplicating the pipeline. Option A duplicates the entire pipeline, which is inefficient. Option B would require separate jobs, but not as concise as the matrix strategy.

Option C uses stages, which run sequentially, not in parallel for this purpose.

Full explanation →

219

Multi-Selecthard

Which TWO actions should you take to implement Git-based source control for a large enterprise with multiple teams and a single repository (monorepo)? (Select TWO.)

Select 2 answers

A.Require all teams to work on a single branch

B.Use Git submodules to separate team code

C.Use forking workflow for each team

D.Configure path-based branch policies

E.Use sparse checkout to reduce clone time

AnswersD, E

Configuring path-based branch policies in Azure DevOps lets you assign specific reviewers and required checks to changes under particular directories (e.g., src/teamA), so each team enforces its own quality gates while still integrating into a shared trunk. This targets code review and CI to the relevant parts of the monorepo, improving both safety and development velocity.

Why this answer

Option D is correct because in a monorepo with multiple teams, path-based branch policies let you scope required reviewers, build validation, and status checks to specific folders or paths, so each team's changes are governed by the right rules without blocking unrelated teams. Option E is correct because a large monorepo produces a huge working tree and history; sparse checkout (git sparse-checkout, often combined with partial clone such as --filter=blob:none) limits the files materialized in the working directory, cutting clone time and disk usage for each developer. Option A is wrong because forcing everyone onto one branch removes isolation and makes concurrent team work and controlled integration impractical.

Option B is wrong because submodules are for embedding separate repositories at pinned commits, which fragments the monorepo rather than implementing source control within a single repository. Option C is wrong because a forking workflow creates per-team repository copies, which contradicts the stated single-repository monorepo requirement.

Exam trap

AZ-400 often tests the confusion between monorepo best practices and alternative workflows like forking or submodules, which are not suitable for a single repository with multiple teams.

Full explanation →

220

MCQhard

You are designing a release pipeline for a critical application that must minimize downtime during deployment. The application runs on Azure Kubernetes Service (AKS) and uses Azure SQL Database. Which deployment strategy should you recommend?

A.Rolling update with health probes.

B.Canary deployment with progressive exposure.

C.Blue-green deployment with traffic manager.

D.Recreate deployment by deleting the old version first.

AnswerC

Blue-green deployment with traffic manager provisions two identical environments, with the traffic manager routing 100% of traffic to the blue environment. At switchover, it instantly shifts traffic to the green environment by updating DNS/routing rules, and rollback is equally immediate, so downtime is reduced to seconds or less.

Why this answer

Blue-green deployment with Traffic Manager is recommended because it allows you to maintain two identical environments (blue and green) and instantly switch traffic between them via Azure Traffic Manager. This minimizes downtime to the time it takes to update DNS or routing rules, and provides immediate rollback capability by switching back to the previous environment. For a critical application on AKS with Azure SQL Database, this strategy avoids the complexity of managing state during rolling updates and ensures zero-downtime cutover.

Exam trap

The trap here is that candidates often choose rolling updates (Option A) because they assume health probes guarantee zero downtime, but they overlook the fact that rolling updates still involve a gradual transition that can cause brief unavailability or require complex rollback logic, whereas blue-green provides instant, atomic cutover with Traffic Manager.

How to eliminate wrong answers

Option A is wrong because rolling updates with health probes, while reducing downtime, still involve gradual replacement of pods, which can cause brief periods of reduced capacity or partial unavailability if health probes are misconfigured; they also do not provide instant rollback. Option B is wrong because canary deployment with progressive exposure is designed for testing new versions with a small subset of users, not for minimizing downtime during a full production deployment—it introduces complexity in routing and monitoring and does not guarantee zero-downtime cutover. Option D is wrong because recreating by deleting the old version first causes full downtime until the new version is fully deployed, which violates the requirement to minimize downtime.

Full explanation →

221

Multi-Selecthard

Which THREE are required components to implement a secure CI/CD pipeline using Azure Pipelines and GitHub?

Select 3 answers

A.An Azure service connection to authenticate to Azure resources.

B.A container registry to store Docker images.

C.A YAML pipeline definition with stages and jobs.

D.A GitHub personal access token stored as a plain text variable.

E.Branch protection rules requiring status checks to pass.

AnswersA, C, E

A service connection is required for secure authentication to Azure resources, storing credentials or using workload identity federation so the pipeline can deploy without hard-coded secrets. It is a core component because every Azure-bound task needs a valid, authorized identity.

Why this answer

Option A is correct because an Azure service connection (a service principal or workload identity federation stored in Azure DevOps) is the mechanism Azure Pipelines uses to authenticate to Azure subscriptions and deploy resources securely without embedding credentials in code. Option C is correct because a YAML pipeline definition with stages and jobs is the declarative pipeline artifact that Azure Pipelines executes to build, test, and deploy code in a repeatable, version-controlled manner. Option E is correct because branch protection rules requiring status checks to pass prevent unreviewed or failing code from being merged, enforcing quality and security gates in the GitHub workflow.

Option B is not required because a container registry is only needed when the pipeline builds and stores Docker images, which is not a universal requirement for a secure CI/CD pipeline. Option D is not required and is in fact insecure, since storing a GitHub personal access token as a plain text variable exposes the secret; tokens should be kept in Azure Key Vault or a secret variable group instead.

Exam trap

The trap here is that candidates often assume a container registry is universally required, but it is only needed for container-based workflows, not for all secure CI/CD pipelines.

Full explanation →

222

Drag & Dropmedium

Drag and drop the steps to configure Azure DevOps artifact feeds for NuGet packages into the correct order.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

Feed setup starts with creation, upstream sources, permissions, publishing, and consumption.

Full explanation →

223

MCQmedium

You are designing a build validation policy for a GitHub repository. You want to ensure that all pull requests pass a CI check before they can be merged. What should you configure?

A.Enable Dependabot alerts on the repository.

B.Configure a repository rule to require a pull request before merging.

C.Add a GitHub Actions workflow that runs on 'pull_request' and set it as a required status check in branch protection.

D.Create a webhook to trigger a build on Azure Pipelines.

AnswerC

Adding a GitHub Actions workflow with a `pull_request` trigger executes CI on each PR, and then marking the resulting status check as required in branch protection blocks merging until that workflow completes successfully. This creates a hard enforcement gate that validates the build before changes can be merged, making it the correct approach for build validation.

Why this answer

To require a CI check before merge, you add a GitHub Actions workflow triggered on 'pull_request' and then configure branch protection (or a repository ruleset) to mark that workflow's job as a required status check. This blocks merging until the check passes.

Exam trap

AZ-400 often tests the confusion between merely triggering a build (webhook or workflow) and actually enforcing it as a required status check in branch protection — only the latter blocks merges.

How to eliminate wrong answers

Option A is wrong because Dependabot alerts notify about vulnerable dependencies and do not run CI or block merges. Option B is wrong because requiring a pull request before merging only enforces that a PR exists — it does not require any CI check to pass. Option D is wrong because a webhook merely triggers an external build; without a required status check configured in branch protection, the merge is not blocked by the build result.

Full explanation →

224

Multi-Selecthard

Which THREE components are required to set up a self-hosted agent in Azure Pipelines? (Choose three.)

Select 3 answers

A.An Azure Resource Manager service connection

B.A personal access token (PAT) with Agent Pools (read, manage) scope

C.A machine (virtual or physical) to run the agent software

D.The agent software downloaded from the Azure DevOps organization

E.An Azure Active Directory account for the agent

AnswersB, C, D

A PAT scoped to Agent Pools (read, manage) is required because it is the primary authentication mechanism for registering a self-hosted agent against an Azure DevOps organization. This token grants the agent the necessary permissions to appear in the target agent pool and receive job assignments.

Why this answer

A personal access token (PAT) with Agent Pools (read, manage) scope is required because the self-hosted agent uses this token to authenticate with Azure DevOps during the configuration step. The agent registers itself into the specified agent pool, and the PAT must have the 'Agent Pools (read, manage)' scope to authorize this registration and subsequent communication.

Exam trap

The trap here is that candidates often confuse a service connection (needed for deploying to Azure) with the authentication mechanism required to register the agent itself, leading them to select Option A instead of recognizing that only the PAT with Agent Pools scope is needed.

Full explanation →

225

MCQhard

Your Azure Pipelines release pipeline deploys to multiple stages. You need to implement a manual approval gate that requires two specific users to approve before deployment proceeds to production. The approval should expire after 8 hours. Which configuration should you use?

A.Pre-deployment conditions: Add approvers (user1, user2) with 'All' policy and set timeout to 480 minutes

B.Pre-deployment conditions: Add approvers (user1, user2) with 'Any one' policy

C.Pre-deployment conditions: Add approvers (user1, user2) with 'All' policy and set 'Allow deployment without approval' to true

D.Post-deployment conditions: Add approvers (team) with 'All' policy

AnswerA

Setting pre-deployment approvers to user1 and user2 with the 'All' policy requires both users to explicitly approve the release before deployment proceeds. The 480-minute timeout ensures that if either approver does not respond within 8 hours, the approval process times out, preventing indefinite blocking of the pipeline. This satisfies the requirement that both specific individuals must approve, with an 8-hour window.

Why this answer

It configures a pre-deployment approval gate requiring both user1 and user2 to approve (the 'All' policy) before the production stage proceeds, and sets the timeout to 480 minutes (8 hours) to expire the approval request. This matches the requirement for two specific users to approve and an 8-hour expiration.

Exam trap

The trap here is confusing pre-deployment vs. post-deployment conditions and misinterpreting the 'All' vs. 'Any one' policy, leading candidates to select an option that allows a single approver or applies the gate after deployment.

How to eliminate wrong answers

Option B is wrong because the 'Any one' policy allows either user1 or user2 to approve, not both, which fails the requirement for two specific users to approve. Option C is wrong because setting 'Allow deployment without approval' to true would bypass the approval gate entirely, contradicting the requirement for manual approval. Option D is wrong because post-deployment conditions apply after the deployment runs, not before, and the requirement is for a pre-deployment gate; additionally, it specifies a team rather than two specific users.

Full explanation →

Microsoft Azure DevOps Engineer Expert AZ-400 (AZ-400) — Questions 151–225