Microsoft Azure DevOps Engineer Expert AZ-400 AZ-400 Questions 376–450 | Page 6/10

376

MCQmedium

You are designing a multi-stage YAML pipeline for a .NET Core application. The pipeline must build, test, and deploy to a staging environment. You want to ensure that the deployment stage only runs if the build and test stages succeed, and that the staging deployment uses the exact same bits that were built. Which strategy should you use?

A.Set up a release pipeline that uses the same build artifact and requires manual approval.

B.Create separate stages for build, test, and deploy. Use the 'dependsOn' keyword and publish artifact in build stage, download in deploy stage.

C.Use a build trigger on the staging branch to deploy after each commit, ignoring test results.

D.Define the pipeline with a single stage and use a condition to skip test on failure.

AnswerB

Separating build, test, and deploy into distinct stages with dependsOn ensures strict sequential execution: build completes, tests pass, then deploy runs. Publishing the artifact in the build stage and downloading it in the deploy stage preserves the exact compiled output, making the pipeline reliable and providing automatic gatekeeping based on test success.

Why this answer

Using separate stages with 'dependsOn' ensures the deployment stage only runs after successful build and test stages. Publishing the build artifact in the build stage and downloading it in the deploy stage guarantees that the exact same compiled bits are used for deployment, maintaining consistency across environments.

Exam trap

The trap here is that candidates may confuse release pipelines with multi-stage YAML pipelines, thinking manual approval is required for deployment control, but the question specifically requires using the exact same bits and conditional stage execution, which is directly achieved with 'dependsOn' and artifact publishing/downloading.

How to eliminate wrong answers

Option A is wrong because it suggests using a release pipeline with manual approval, which does not inherently ensure that the deployment uses the exact same bits from the build; it could use a different artifact version if not properly configured, and manual approval is not required for the scenario. Option C is wrong because using a build trigger on the staging branch and ignoring test results violates the requirement that the deployment stage only runs if tests succeed; it would deploy regardless of test outcomes. Option D is wrong because defining a single stage with a condition to skip tests on failure does not enforce that the deployment uses the same bits from the build; it also does not provide the multi-stage separation needed for the build, test, and deploy phases.

Full explanation →

377

MCQhard

You are implementing a build pipeline for a .NET application that uses GitHub Advanced Security (GHAS) for code scanning. The pipeline must run CodeQL analysis on every pull request to the main branch. You have added the CodeQL task to the pipeline. However, the analysis results are not appearing in the 'Security' tab of the repository on GitHub. What is the most likely cause?

A.The pipeline is missing the 'Publish Security Analysis Logs' step to upload SARIF results to GitHub.

B.The GitHub repository is private, so security alerts are disabled.

C.The .NET project is not supported by CodeQL.

D.CodeQL analysis is not supported on pull request triggers.

AnswerA

In Azure DevOps, CodeQL results are produced as SARIF files, but they do not automatically appear in the GitHub Security tab. You must explicitly include the 'Publish Security Analysis Logs' task (or equivalent) to upload those SARIF logs to GitHub, which is what enables the findings to be displayed in the security alerts. Without this step, the analysis may run but the results are never surfaced.

Why this answer

CodeQL analysis results are uploaded to GitHub as SARIF files. Without the 'Publish Security Analysis Logs' step (or the equivalent 'upload-sarif' action), the SARIF file generated by CodeQL is not sent to GitHub, so the findings never appear in the Security tab. The pipeline must explicitly include this step to complete the integration with GitHub Advanced Security.

Exam trap

The trap here is that candidates assume adding the CodeQL analysis task alone is sufficient, overlooking the mandatory SARIF upload step that bridges the analysis output to GitHub's security dashboard.

How to eliminate wrong answers

Option B is wrong because GitHub Advanced Security and security alerts are fully supported on private repositories; the repository's visibility does not block results from appearing. Option C is wrong because CodeQL supports .NET (including C#, VB.NET, and F#) via the standard CodeQL queries; .NET is a first-class supported language. Option D is wrong because CodeQL analysis is explicitly supported on pull request triggers; the issue is not the trigger but the missing upload step.

Full explanation →

378

MCQmedium

Your team uses GitHub Actions for CI/CD and needs to ensure that secrets such as Azure service principal credentials are not exposed in logs. What is the best practice to prevent secret exposure?

A.Store secrets as GitHub Actions secrets and reference them in workflows

B.Store secrets in the workflow YAML file

C.Use environment protection rules to mask secrets

D.Encrypt workflow logs after the run completes

AnswerA

GitHub Actions secrets are encrypted at rest and automatically masked in logs, so referencing them via secrets context prevents credential exposure. Hardcoding values or echoing them would leak the service principal credentials the stem warns against.

Why this answer

GitHub Actions secrets are encrypted environment variables that are automatically masked in workflow logs when referenced. By storing Azure service principal credentials as GitHub Actions secrets and using the `${{ secrets.SECRET_NAME }}` syntax in workflows, the actual secret values are never written to logs, preventing exposure. This is the recommended approach for handling sensitive data in GitHub Actions CI/CD pipelines.

Exam trap

The trap here is that candidates may confuse environment protection rules (which control deployment gates and approvals) with the built-in secret masking feature of GitHub Actions secrets, leading them to incorrectly select option C.

How to eliminate wrong answers

Option B is wrong because storing secrets directly in the workflow YAML file exposes them in plaintext in the repository, making them visible to anyone with access to the repository and potentially leaking them in logs or pull request comments. Option C is wrong because environment protection rules control deployment approvals and branch restrictions, but they do not mask or redact secrets from logs; secret masking is a built-in feature of GitHub Actions secrets, not environment rules. Option D is wrong because encrypting workflow logs after the run completes does not prevent secrets from being displayed in plaintext during the run or in the unencrypted logs before encryption; the secret would still be exposed in the log output.

Full explanation →

379

Multi-Selecteasy

Which TWO triggers can start a release in Azure Pipelines?

Select 2 answers

A.Continuous integration

B.Schedule

C.Build completion

D.Work item state change

E.Pull request

AnswersB, C

A schedule trigger starts a release automatically at defined times, independent of code changes. This satisfies the question's requirement for a valid release trigger, enabling recurring deployments such as nightly or maintenance-window releases without manual intervention.

Why this answer

Option B (Schedule) is correct because Azure Pipelines release pipelines support scheduled triggers, configured via the pipeline's Triggers tab or YAML scheduled triggers, which start a release at defined times (e.g., cron-based schedules). Option C (Build completion) is correct because a release can be triggered when a specified build (artifact source) completes successfully, using the build completion trigger that monitors a chosen build pipeline. Option A (Continuous integration) is not a release trigger in this context; CI triggers start builds, not releases (the release equivalent is the continuous deployment trigger on an artifact).

Option D (Work item state change) is not a supported release trigger in Azure Pipelines. Option E (Pull request) is a build/CI trigger (PR triggers on branches), not a release trigger.

Exam trap

The trap here is that candidates confuse triggers that apply to build pipelines (CI, PR) with those that apply to release pipelines, leading them to select 'Continuous integration' or 'Pull request' as valid release triggers.

Full explanation →

380

MCQeasy

Your team uses GitHub Actions for CI/CD. You need to ensure that only specific branches can trigger the deployment workflow to production. Which workflow trigger should you configure?

A.on: push: branches: [main]

B.on: pull_request: branches: [main]

C.on: workflow_dispatch: inputs: branch: description: 'Select branch'

D.on: schedule: cron: '0 0 * * *'

AnswerA

This trigger fires the workflow automatically on every push to the main branch. The branch filter ensures that only commits pushed to main start the CI pipeline, so builds and tests run on the intended integration branch while ignoring feature branches.

Why this answer

The `on: push: branches: [main]` trigger ensures that the deployment workflow runs only when a push event occurs on the `main` branch. This directly enforces the requirement that only specific branches (here, `main`) can trigger production deployments, preventing accidental or unauthorized deployments from other branches.

Exam trap

The trap here is that candidates often confuse `pull_request` triggers with `push` triggers, thinking a PR merge to `main` counts as a push, but `pull_request` triggers on PR lifecycle events (like `opened` or `synchronize`), not the merge commit itself, which would require a `push` trigger on `main`.

How to eliminate wrong answers

Option B is wrong because `on: pull_request: branches: [main]` triggers the workflow on pull request events (opened, synchronized, etc.) targeting `main`, not on direct pushes; this would run the workflow in the context of a PR, not a production deployment, and could lead to unintended executions during code review. Option C is wrong because `workflow_dispatch` allows manual triggering from the GitHub UI or API with a branch input, but it does not restrict execution to specific branches by default—any user with write access can select any branch, violating the requirement for branch-specific restriction. Option D is wrong because `on: schedule: cron: '0 0 * * *'` triggers the workflow on a time-based schedule (daily at midnight), which is unrelated to branch-based triggers and would not enforce branch restrictions at all.

Full explanation →

381

MCQmedium

Your team uses a multi-stage YAML pipeline to build and deploy a .NET Core application. The build stage runs successfully, but the deployment to a Linux web app fails with an error indicating that the Kudu service cannot start because the startup command is missing. What is the most likely cause?

A.The pipeline is missing the 'AzureWebApp@1' task with a 'StartupCommand' parameter.

B.The service connection lacks permission to access the web app.

C.The web app is configured with a Windows runtime stack.

D.The build output does not include the web.config file.

AnswerA

On Linux-based Azure App Service, the runtime is containerized and requires an explicit entry point to start the application. The AzureWebApp@1 task (or AzureWebAppContainer@1 when deploying a container) exposes a StartupCommand parameter that injects this command (for example, `pm2 start /home/site/wwwroot/server.js`) into the App Service configuration. Without that parameter, the platform falls back to a default command that may not exist, producing the exact error about a missing startup command. The fix is to add the task with the appropriate StartupCommand, or to configure the startup command in the app's Application settings.

Why this answer

The Kudu service on Linux web apps requires a startup command to launch the .NET Core application. The 'AzureWebApp@1' task's 'StartupCommand' parameter specifies this command (e.g., 'dotnet myapp.dll'). Without it, Kudu cannot start the process, causing the deployment failure.

Exam trap

The trap here is that candidates might think the issue is a missing web.config file (common for Windows deployments) or a permission problem, but on Linux, the startup command is the critical missing piece, not a configuration file.

How to eliminate wrong answers

Option B is wrong because a permission issue would typically cause an authorization error (e.g., 403) during deployment, not a Kudu startup failure. Option C is wrong because the error explicitly occurs on a Linux web app; a Windows runtime stack would not cause a missing startup command error on Linux. Option D is wrong because .NET Core applications on Linux do not require a web.config file; they rely on a startup command or a process file (e.g., 'server.js' for Node.js) to start.

Full explanation →

382

Multi-Selectmedium

Your team uses GitHub Advanced Security to identify vulnerabilities in code. Which TWO actions can you take to ensure that critical security alerts are addressed before code is merged?

Select 2 answers

A.Enable secret scanning push protection.

B.Create a repository rule that allows bypassing pull request requirements.

C.Configure branch protection rules to require status checks from code scanning.

D.Enable Dependabot auto-merge for pull requests.

E.Use pull request annotations to display code scanning alerts.

AnswersC, E

Configuring branch protection rules to require code scanning status checks creates a hard merge gate: if CodeQL or other scanning tools detect critical vulnerabilities, the status check fails and the pull request is blocked. This enforces alert resolution before code can enter the protected branch, making it the correct answer.

Why this answer

Branch protection rules can require passing status checks from code scanning and secret scanning. Pull request annotations show alerts directly in the PR. Dependabot auto-merge and repository rules for bypassing are not relevant for blocking merges based on security alerts.

Full explanation →

383

Multi-Selecthard

You are building a comprehensive instrumentation strategy for a large-scale Azure DevOps environment. You need to ensure that all pipeline events (build, release, test) are automatically tracked and correlated with application performance data. Which THREE components should you include?

Select 3 answers

A.A shared Correlation ID that flows from pipeline to application.

B.Azure Monitor Workbooks to visualize pipeline data.

C.Custom pipeline tasks that send telemetry to Application Insights.

D.Azure Boards to track pipeline run metadata.

E.OpenTelemetry SDK in the application to emit trace context.

AnswersA, C, E

A shared Correlation ID that flows from pipeline to application is correct because it enables end-to-end traceability, linking build/release pipeline events to application telemetry. This ID is propagated via environment variables or HTTP headers, allowing every log, metric, and trace to be correlated across the CI/CD boundary, which is essential for diagnosing failures that span pipeline and runtime.

Why this answer

Options A, C, and E are correct. A shared Correlation ID (A) flows from pipeline to application, enabling end-to-end trace correlation. Custom pipeline tasks (C) send telemetry (e.g., build/release events) to Application Insights.

The OpenTelemetry SDK (E) emits trace context from the application, which can include the correlation ID. Option B is wrong because Azure Monitor Workbooks are visualization tools, not data collection components. Option D is wrong because Azure Boards is for work item tracking, not pipeline event capture.

Full explanation →

384

MCQhard

Refer to the exhibit. A build pipeline fails at the 'Publish Artifact' step. The pipeline has two jobs: 'Build' and 'Test'. Both jobs have a 'PublishBuildArtifacts' task with artifact name 'drop'. What is the most likely cause?

A.The artifact name 'drop' contains invalid characters.

B.The artifact is too large to publish.

C.Two jobs are publishing artifacts with the same name.

D.The pipeline does not have permission to publish artifacts.

AnswerC

When two or more jobs in the same pipeline publish artifacts with an identical artifact name, the Azure DevOps PublishPipelineArtifact task fails because artifact names must be unique within the entire pipeline run. The second job's attempt to publish 'drop' conflicts with the first job's already published artifact, causing the build to fail.

Why this answer

In Azure Pipelines, artifact names must be unique within a pipeline run. When two jobs (Build and Test) each run a PublishBuildArtifacts task with the same artifact name 'drop', the second publish conflicts with the first, causing the 'Publish Artifact' step to fail. The fix is to use distinct artifact names per job or use a single job to publish.

Exam trap

The trap is assuming the failure is environmental (size, permissions, naming rules) when the exhibit actually shows two jobs publishing the same artifact name — a classic Azure DevOps uniqueness constraint.

How to eliminate wrong answers

Option A is wrong because 'drop' is a valid artifact name; Azure DevOps allows alphanumeric names and common characters, so invalid characters are not the issue. Option B is wrong because artifact size limits (e.g., 2 GB per file for Azure Pipelines) are far larger than typical build outputs and would produce a different, size-specific error. Option D is wrong because the pipeline's build service account has publish permissions by default; a permissions failure would show an authorization error, not a naming conflict.

Full explanation →

385

MCQeasy

You need to create a build pipeline that runs on a Microsoft-hosted agent. You want to use the latest Ubuntu image. Which YAML snippet should you use?

A.pool: vmImage: 'ubuntu-latest'

B.pool: name: 'ubuntu-latest'

C.agent: vmImage: 'ubuntu-latest'

D.resources: vmImage: 'ubuntu-latest'

AnswerA

In Azure Pipelines YAML, the `pool` keyword defines the execution agent, and for Microsoft-hosted agents you must specify the VM image using the `vmImage` property. `'ubuntu-latest'` is a valid alias that resolves to the current stable Ubuntu LTS image, so this is the correct syntax.

Why this answer

In Azure Pipelines YAML, the `pool` keyword is used to specify the agent pool, and `vmImage` is a sub-property that defines the virtual machine image for Microsoft-hosted agents. Setting `vmImage: 'ubuntu-latest'` within the `pool` section selects the latest Ubuntu LTS image provided by Microsoft, ensuring the build runs on a current, maintained environment.

Exam trap

The trap here is that candidates confuse the `pool.name` property (used for self-hosted agents) with `pool.vmImage` (used for Microsoft-hosted agents), leading them to select option B, or they mistakenly use `agent` or `resources` as top-level keys for specifying the VM image.

Why the other options are wrong

The 'name' property is for agent pools, not VM images.

'agent' is not a valid top-level key; use 'pool'.

Resources are for external resources, not agent specification.

Full explanation →

386

MCQmedium

Your team uses a multi-stage YAML pipeline. The 'Build' stage compiles the code and runs unit tests. The 'Deploy' stage deploys to a staging environment. You notice that if the 'Build' stage fails, the 'Deploy' stage still starts because it depends on a condition that always evaluates to true. How should you modify the pipeline to prevent the 'Deploy' stage from running if the 'Build' stage fails?

A.Add 'condition: succeeded()' to the Deploy stage.

B.Add 'condition: eq(variables['Build.Succeeded'], 'true')' to the Deploy stage.

C.Add 'condition: and(succeeded(), eq(variables['Build.Succeeded'], 'true'))' to the Deploy stage.

D.Add 'dependsOn: Build' to the Deploy stage.

AnswerA

The 'succeeded()' function is a predefined pipeline expression that evaluates to true only if all prior stages and jobs in the pipeline have completed successfully, so adding 'condition: succeeded()' to the Deploy stage ensures it runs only after the Build stage succeeds, which is exactly the desired behavior.

Why this answer

The `succeeded()` function in Azure Pipelines evaluates whether all previous stages (or jobs, depending on context) have completed successfully. By adding `condition: succeeded()` to the Deploy stage, the stage will only run if the Build stage (its implicit or explicit dependency) succeeded. This directly prevents the Deploy stage from starting when the Build stage fails.

Exam trap

The trap here is that candidates often think `dependsOn` alone enforces success, but it only sets the dependency order; without an explicit `condition: succeeded()`, a custom condition that always evaluates to true will still trigger the stage regardless of the dependency's status.

How to eliminate wrong answers

Option B is wrong because `variables['Build.Succeeded']` is not a predefined variable in Azure Pipelines; the correct variable is `Agent.JobStatus` or you must use the `succeeded()` function. Option C is wrong because it combines an invalid variable reference with `succeeded()`, which is redundant and still relies on a non-existent variable. Option D is wrong because adding `dependsOn: Build` only establishes the dependency order but does not enforce a success condition; without an explicit condition, the Deploy stage will still run even if the Build stage fails, as the default condition is `succeeded()` only when `dependsOn` is used without a custom condition—but here the question states a condition that always evaluates to true overrides that default, so `dependsOn` alone is insufficient.

Full explanation →

387

MCQhard

You are deploying an ARM template using the parameters file shown. The deployment fails with an error that the referenced secret cannot be found. What is the most likely cause?

A.The secret name in the parameters file does not match the actual secret name in Key Vault.

B.The Key Vault does not have an access policy granting the deployment user 'Get' secret permission.

C.The resource group 'rg-kv' does not exist.

D.The Key Vault is in a different region than the deployment.

AnswerA

An ARM template dynamic Key Vault reference resolves the secret by name exactly as specified in the parameters file. If the name contains a typo or does not match the secret's actual name in Key Vault (including case sensitivity for secret names), Azure returns a 'Secret not found' error, even if the Key Vault and access policies are correctly configured.

Why this answer

The error 'referenced secret cannot be found' directly indicates that the secret name specified in the parameters file does not match the actual secret name stored in Azure Key Vault. ARM template deployment uses the `reference()` function to retrieve the secret value at deployment time, and if the secret name is misspelled or incorrect, the deployment fails with this specific error.

Exam trap

The trap here is that candidates often confuse the 'secret not found' error with permission issues (Option B), but the error message specifically indicates the secret name mismatch, not an access policy problem.

How to eliminate wrong answers

Option B is wrong because an incorrect access policy would produce a different error, such as 'Access denied' or 'Forbidden', not 'secret cannot be found'. Option C is wrong because if the resource group 'rg-kv' did not exist, the deployment would fail with a resource group not found error, not a secret not found error. Option D is wrong because Key Vault region does not affect secret retrieval; ARM templates can reference Key Vaults in any region as long as the deployment user has appropriate permissions.

Full explanation →

388

MCQeasy

You are configuring a build pipeline in Azure Pipelines that compiles a .NET application. You need to ensure that the pipeline uses a specific version of the .NET SDK, which is installed on the agents. The agents are Microsoft-hosted. What should you add to your YAML pipeline?

A.A variable named 'DotNetVersion' set to the desired version and referenced in the build task.

B.The UseDotNet@2 task with the desired version specified.

C.A task that runs 'dotnet --version' to verify the SDK version.

D.A script that downloads and installs the .NET SDK from the official website.

AnswerB

The UseDotNet@2 task installs or selects the specified .NET SDK version on the agent. This ensures that subsequent tasks, such as the build, use the correct SDK. It is the recommended way to pin the .NET SDK version in Azure Pipelines.

Why this answer

The UseDotNet@2 task is designed to install or select a specific .NET SDK version on the agent. This ensures that the build uses the correct SDK. Other options do not effectively control the SDK version used by the build.

Exam trap

The trap here is assuming that a script to check the version or a variable will influence which SDK is used; only the UseDotNet@2 task actually sets the SDK for subsequent tasks.

Full explanation →

389

Multi-Selecthard

Which THREE are valid approaches to securely store secrets used in Azure Pipelines? (Choose three.)

Select 3 answers

A.Inline secret variables defined in the YAML file

B.Secret variables defined in the pipeline UI

C.Azure Key Vault task to fetch secrets at runtime

D.Variable groups linked to Azure Key Vault

E.Environment variables set on the build agent

AnswersB, C, D

Secret variables defined in the pipeline UI are stored encrypted in Azure DevOps and automatically masked in all logs, ensuring they are never exposed during the build or release execution. They can be scoped to the pipeline run and are the recommended way to handle non-Key Vault secrets.

Why this answer

Secret variables defined in the pipeline UI (B) are encrypted at rest and masked in logs, preventing exposure in source control. The Azure Key Vault task (C) retrieves secrets from Azure Key Vault at runtime, avoiding storage in Azure DevOps. Variable groups linked to Azure Key Vault (D) allow you to reference Key Vault secrets directly as pipeline variables, keeping them out of YAML and providing centralized access control.

All three approaches ensure secrets are not stored in plaintext in repositories or pipeline definitions.

Exam trap

The trap here is that candidates may think inline YAML secrets (Option A) are secure because they are marked as 'secret' in the YAML, but they are still stored in plaintext in the repository, which is a common security misconception.

Full explanation →

390

Matchingmedium

Match each Azure DevOps service to its primary function.

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

Concepts

Matches

Agile planning and work tracking

Source control with Git or TFVC

CI/CD build and release automation

Manual and exploratory testing

Package management and sharing

Why these pairings

The correct matches are: Azure Boards for agile planning, Azure Repos for version control, Azure Pipelines for CI/CD, and Azure Artifacts for package management. Common confusions include swapping Boards with Repos or Pipelines.

Full explanation →

391

MCQhard

A development team uses a forking workflow in Azure Repos. They want to ensure that only specific users can create forks of the main repository. How can they achieve this?

A.Use branch security to restrict who can create forks

B.Set branch policies on the main branch to prevent forks

C.Configure the repository to disable forks globally

D.Remove the 'Create Fork' permission from all users except the required group

AnswerD

The 'Create Fork' permission is a repository-level security permission in Azure Repos, stored separately from branch permissions. To allow only a specific group to create forks, you remove the 'Create Fork' permission from all other users and groups (for example, Contributors and Readers) in the repository's Security page, then explicitly set it to 'Allow' for the required group. This is the only per-repository mechanism that enforces the requirement precisely, since it leaves fork creation available to the approved group while denying everyone else.

Why this answer

In Azure Repos, the ability to create forks is controlled by the 'Create Fork' permission, which is a repository-level permission, not a branch-level setting. By default, all contributors have this permission. To restrict fork creation to only specific users, navigate to the repository settings, go to Security (or Permissions), remove the 'Create Fork' permission from all users and groups, then explicitly grant it only to the desired group or individuals.

Therefore, the correct answer is D: remove the 'Create Fork' permission from all users except the required group.

Exam trap

The trap is that candidates often confuse repository-level permissions with branch-level settings. They may think 'branch security' controls fork creation because both involve permissions, but fork creation is managed at the repository level, not the branch level.

How to eliminate wrong answers

Option A is correct because it directly addresses the permission control needed. Option B is wrong because branch policies on the main branch (e.g., requiring pull request reviews) do not control who can create forks; they only enforce rules on commits and merges to that branch. Option C is wrong because Azure Repos does not have a global 'disable forks' setting; fork creation is controlled per-repository via permissions.

Option D is wrong because 'Create Fork' is not a permission that can be removed from users; it is a permission that must be explicitly denied or granted, and the correct approach is to remove the permission from all users and grant it only to the required group.

Full explanation →

392

Multi-Selecthard

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

Select 3 answers

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

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

C.The approver must have the 'Approve pipeline permissions' permission for the environment.

D.The pipeline must be a Release Pipeline or a YAML pipeline that uses the 'environment' resource.

E.You must create an environment in Azure Pipelines and add an approval check to it.

AnswersC, D, E

To successfully approve a deployment to an environment, the designated approver must have the 'Approve pipeline permissions' permission on that environment. This permission is managed through the environment's security settings and is separate from permissions like 'View' or 'Manage'. Without this permission, even if a user is listed as an approver, they will not be able to approve the deployment.

Why this answer

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

Without an environment resource, the approval check cannot be configured; without the permission, approval requests cannot be validated.

Exam trap

The trap here is that candidates often assume approvals must be configured in the release pipeline's pre-deployment conditions only, but Azure Pipelines also supports approvals in post-deployment conditions and as environment-level checks in YAML pipelines, making option B a common distractor.

Full explanation →

393

MCQeasy

Your team uses Azure Pipelines for CI/CD. The pipeline builds a Docker image and pushes it to Azure Container Registry (ACR). You need to ensure that only the main branch triggers a build of the Docker image. What should you configure in the pipeline YAML?

A.Set 'pr: branches: include: - main'

B.Add a condition: 'eq(variables['Build.SourceBranch'], 'refs/heads/main')' to the job.

C.Set 'trigger: branches: include: - *'

D.Set 'trigger: branches: include: - main'

AnswerD

Setting `trigger: branches: include: - main` defines the CI trigger to fire only on commits pushed to the `main` branch. This ensures that pushes to feature or other branches do not create pipeline runs, while any commit to `main` correctly starts a new CI build, satisfying the requirement to restrict builds to the main branch.

Why this answer

Setting `trigger: branches: include: - main` in the pipeline YAML configures a CI trigger that only starts a new pipeline run when changes are pushed to the `main` branch. This ensures that the Docker image build and push to ACR occurs exclusively for the main branch, meeting the requirement.

Exam trap

The trap here is that candidates often confuse CI triggers (`trigger`) with PR triggers (`pr`) or try to use job-level conditions to filter branches, not realizing that conditions only skip job execution but still trigger the pipeline, wasting resources and potentially causing unintended side effects like failed runs or unnecessary ACR pushes.

How to eliminate wrong answers

Option A is wrong because `pr: branches: include: - main` configures a pull request (PR) trigger, not a CI build trigger; it would cause the pipeline to run when a PR targets main, not when code is pushed directly to main. Option B is wrong because adding a condition like `eq(variables['Build.SourceBranch'], 'refs/heads/main')` to a job would still allow the pipeline to be triggered by any branch, but the job would be skipped for non-main branches; this does not prevent the pipeline from being triggered at all, which is inefficient and does not meet the requirement to 'only trigger a build' on main. Option C is wrong because `trigger: branches: include: - *` uses a wildcard that includes all branches, which would trigger the pipeline on every push to any branch, not just main.

Full explanation →

394

MCQmedium

You are configuring a multi-stage YAML pipeline that builds a .NET Core application and deploys it to Azure Kubernetes Service (AKS). The build stage produces a container image that is pushed to Azure Container Registry (ACR). The deploy stage needs to use the image from ACR. How should you pass the image tag from the build stage to the deploy stage?

A.Write the image tag to a file and publish it as a build artifact, then read it in the deploy stage.

B.Define a pipeline variable at the top level and set it in the build stage.

C.Use the 'stageDependencies' syntax to retrieve the output variable of a job in the build stage.

D.Use the 'Azure CLI' task in the deploy stage to query the ACR for the latest image tag.

AnswerC

Output variables are the intended mechanism for sharing a value between stages: a job in the build stage sets the variable with `task.setvariable` and `isoutput=true`, making it available in the job's output context. A subsequent stage's job can then retrieve that exact value at runtime using the syntax `$[stageDependencies.buildStage.buildJob.outputs['imageTag']]` in a variable definition, condition, or argument. This guarantees the consuming stage receives the precise tag produced by the build, independent of ordering or naming conventions, and avoids the overhead of publishing artifacts for a single string value.

Why this answer

Azure DevOps supports cross-stage output variables, allowing a job in the build stage to set a variable (e.g., imageTag) that can be consumed in the deploy stage using the stageDependencies syntax. This avoids the overhead of artifacts or external queries and ensures the exact tag produced during the build is used in deployment.

Exam trap

The trap here is that candidates often assume artifacts are the only way to pass data between stages, overlooking the built-in cross-stage variable feature that is more efficient and purpose-built for this scenario.

How to eliminate wrong answers

Option A is wrong because writing the image tag to a file and publishing it as a build artifact introduces unnecessary complexity and latency; artifacts are designed for binary files, not simple variable passing, and require extra steps to download and parse. Option B is wrong because pipeline variables defined at the top level are static and cannot be dynamically set by a stage; they are evaluated at pipeline start, not updated during execution. Option D is wrong because querying ACR for the latest image tag is unreliable—there may be multiple tags, race conditions, or no guarantee that the tag corresponds to the specific build just completed, leading to deployment of the wrong image.

Full explanation →

395

MCQhard

Your organization uses GitHub Actions with self-hosted runners on Azure virtual machines. You notice that some workflows are taking longer than expected because runners are busy. You need to improve the performance without adding more permanent runners. Which solution should you implement?

A.Migrate all workflows to GitHub-hosted runners.

B.Reduce the number of concurrent jobs in each workflow.

C.Implement auto-scaling for self-hosted runners using a scale set or Kubernetes-based runner controller.

D.Increase the size of the existing self-hosted runner VMs to handle more jobs.

AnswerC

Implementing auto-scaling for self-hosted runners using a scale set or Kubernetes-based Actions Runner Controller dynamically matches runner count to job demand, provisioning new runners during peak times and scaling to zero when idle, which optimizes both latency and cost.

Why this answer

Auto-scaling self-hosted runners using a scale set or a Kubernetes-based runner controller (e.g., actions-runner-controller) dynamically provisions and deprovisions runner instances based on workflow demand. This eliminates idle runner waste while ensuring sufficient capacity during peak loads, directly addressing the bottleneck without adding permanent infrastructure.

Exam trap

The trap here is that candidates often confuse vertical scaling (increasing VM size) with horizontal scaling (adding more runner instances), mistakenly believing a larger VM can process multiple jobs concurrently when in fact each self-hosted runner handles only one job at a time.

How to eliminate wrong answers

Option A is wrong because migrating to GitHub-hosted runners may increase costs and does not leverage existing self-hosted infrastructure; it also does not solve the core issue of scaling capacity dynamically. Option B is wrong because reducing concurrent jobs limits parallelism and throughput, which would worsen performance rather than improve it. Option D is wrong because increasing VM size (vertical scaling) does not increase the number of concurrent jobs a runner can handle; a single runner processes one job at a time regardless of its size.

Full explanation →

396

MCQeasy

Your build pipeline fails intermittently with the error: 'The job running on agent 'Azure Pipelines' exceeded the maximum execution time of 60 minutes.' How can you resolve this issue?

A.Increase the 'timeoutInMinutes' property in the pipeline YAML for the job.

B.Split the pipeline into multiple stages to reduce job duration.

C.Enable parallel jobs to run the pipeline faster.

D.Use a self-hosted agent with more CPU cores.

AnswerA

Increasing the timeoutInMinutes property in the pipeline YAML for the job extends the maximum allowed duration for the job, preventing Azure DevOps from cancelling it when it exceeds the default 60-minute limit. This directly addresses the intermittent timeout error by giving the job more time to complete. Note: for Microsoft-hosted agents, the max is 360 minutes, while self-hosted agents can use 0 for no limit.

Why this answer

The error indicates the job exceeded the default 60-minute timeout for Azure Pipelines hosted agents. Increasing the 'timeoutInMinutes' property in the pipeline YAML for the job explicitly extends the maximum execution time, directly resolving the timeout issue. This property can be set at the job level to allow longer-running tasks without changing the pipeline structure.

Exam trap

The trap here is that candidates may confuse job timeout with pipeline performance, incorrectly assuming that optimizing speed (parallelism or faster agents) resolves a timeout error, when the actual fix is to adjust the timeout limit.

How to eliminate wrong answers

Option B is wrong because splitting the pipeline into multiple stages does not reduce the execution time of a single job; it only organizes the workflow, and each stage still runs within its own job timeout. Option C is wrong because enabling parallel jobs runs multiple jobs concurrently but does not affect the timeout of an individual job that exceeds 60 minutes. Option D is wrong because using a self-hosted agent with more CPU cores may improve performance but does not change the maximum execution time limit; the job would still fail if it runs longer than the default or configured timeout.

Full explanation →

397

Multi-Selectmedium

Which TWO are valid strategies for reducing build times in Azure Pipelines? (Choose two.)

Select 2 answers

A.Reduce the number of parallel jobs and increase the number of steps in a single job.

B.Remove unit tests from the build pipeline and run them only in the release pipeline.

C.Implement caching for package dependencies (e.g., npm, NuGet, Maven) to avoid restoring on every build.

D.Configure incremental builds by enabling 'Build in parallel' and using 'msbuild' or 'dotnet' build with appropriate flags to skip unchanged projects.

E.Increase the number of agents in the pool and run all jobs on the same agent.

AnswersC, D

Caching package dependencies avoids redundant network downloads of unchanged packages across pipeline runs, which is often the biggest time sink in a cold build. Use Azure Pipelines' Cache task or built-in caching (keyed on lockfiles) so restores are near-instant when dependencies haven't changed.

Why this answer

Caching package dependencies (e.g., npm, NuGet, Maven) avoids restoring them on every build, reducing download time. Incremental builds (e.g., using 'dotnet build --no-restore' with appropriate flags or MSBuild's incremental building) skip projects that haven't changed, reducing compilation time. Option A is incorrect because reducing parallel jobs and adding steps increases build time.

Option B is incorrect because removing unit tests compromises quality and is not a valid strategy. Option E is incorrect because increasing agents without parallelizing jobs or running all jobs on the same agent does not reduce build time.

Full explanation →

398

Multi-Selectmedium

Your team uses Azure DevOps with a Git repository. You want to enforce that all pull requests to main must have at least one reviewer from the 'security' group. Which two configurations are required? (Choose two.)

Select 2 answers

A.Configure automatic reviewers for the security group.

B.Add the security group as a required reviewer for the main branch policy.

C.Create a repository policy for the main branch.

D.Set the minimum number of reviewers to 1 in the branch policy.

E.Configure a branch protection rule in GitHub.

AnswersB, D

Adding the security group as a required reviewer in the Azure DevOps branch policy for main is the correct approach. This policy blocks pull request completion until a member of that group approves, making the security review a hard condition. The policy can also specify 'Required' reviewers, which prevents the PR from being completed without the mandated approval. This is the standard, declarative way to enforce that a specific team always signs off on merges to the main branch.

Why this answer

You can add the security group as a required reviewer in the branch policy. Option D is correct because setting the minimum number of reviewers to 1 ensures at least one reviewer is required. Option A is incorrect because automatic reviewers are not the same as required reviewers; they only suggest reviewers but do not enforce mandatory review.

Option C is incorrect because a repository policy applies to all branches, not just main, and does not enforce required reviewers for pull requests; a branch policy is needed. Option E is incorrect because a branch protection rule is a GitHub feature, not available in Azure Repos.

Full explanation →

399

MCQmedium

Your team uses GitHub and wants to automatically link pull requests to work items in Azure Boards. What should you configure?

A.Add a repository secret with Azure Boards connection string

B.Install the Azure Boards app for GitHub and configure the integration

C.Configure branch protection rules to require a linked work item

D.Create a GitHub Actions workflow that posts comments to Azure Boards

AnswerB

Installing the Azure Boards app for GitHub and configuring the connection authenticates the two services and enables mention-based linking, so commits and pull requests referencing AB# work item IDs appear automatically on the board. This satisfies the requirement to link pull requests to work items.

Why this answer

The Azure Boards app for GitHub is the official integration that synchronizes work items with GitHub commits, branches, and pull requests. Once installed and configured, it automatically links pull requests to Azure Boards work items based on mention patterns (e.g., 'AB#123') in the PR description or commit messages, enabling traceability without custom scripting.

Exam trap

The trap here is that candidates confuse 'requiring a linked work item' (a branch protection rule) with 'automatically linking work items' (the integration), leading them to pick Option C, which enforces a precondition rather than establishing the actual linking mechanism.

How to eliminate wrong answers

Option A is wrong because repository secrets are used for storing sensitive tokens or credentials (e.g., for GitHub Actions), not for establishing a cross-service integration like Azure Boards; there is no 'Azure Boards connection string' concept. Option C is wrong because branch protection rules can require a linked work item for PRs, but they do not automatically link PRs to work items—they only enforce that a link already exists, which requires the integration from Option B to be in place first. Option D is wrong because while a GitHub Actions workflow could theoretically post comments to Azure Boards, this is a brittle, custom workaround that duplicates the purpose-built Azure Boards app, which handles bidirectional linking, status updates, and automation natively.

Full explanation →

400

MCQeasy

Your DevOps team is using Microsoft Defender for Cloud to monitor Azure resources. Which of the following is a security recommendation that Defender for Cloud might provide?

A.Allow all inbound traffic on port 22 for SSH

B.Enable Transparent Data Encryption (TDE) on SQL databases

C.Disable auditing on storage accounts to reduce overhead

D.Configure web apps to use HTTP instead of HTTPS

AnswerB

Enabling Transparent Data Encryption (TDE) encrypts SQL database data files, transaction logs, and backups at rest, protecting against data exfiltration if storage is compromised. This is a recommended security control in Defender for Cloud and helps meet compliance requirements for encryption at rest.

Why this answer

Microsoft Defender for Cloud provides security recommendations based on best practices and compliance frameworks. Enabling Transparent Data Encryption (TDE) on SQL databases is a standard security recommendation because it encrypts data at rest, protecting against unauthorized access to the physical database files. This aligns with the 'Develop a security and compliance plan' domain, as TDE helps meet regulatory requirements like GDPR or HIPAA.

Exam trap

The trap here is that candidates may confuse security recommendations with operational shortcuts, such as disabling auditing or using HTTP, thinking they reduce overhead, when in fact Defender for Cloud always promotes security hardening and compliance.

How to eliminate wrong answers

Option A is wrong because allowing all inbound traffic on port 22 (SSH) is a security risk, not a recommendation; Defender for Cloud would recommend restricting SSH access to specific IP ranges or using just-in-time (JIT) VM access. Option C is wrong because disabling auditing on storage accounts reduces visibility for security monitoring and compliance, whereas Defender for Cloud recommends enabling auditing to track access and changes. Option D is wrong because configuring web apps to use HTTP instead of HTTPS exposes data in transit to interception and man-in-the-middle attacks; Defender for Cloud recommends enforcing HTTPS to ensure encrypted communication.

Full explanation →

401

Drag & Dropmedium

Drag and drop the steps to set up a continuous integration pipeline in Azure Pipelines into the correct order.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

The correct order for setting up a continuous integration pipeline in Azure Pipelines is: first create the pipeline, then select the source repository (e.g., Azure Repos or GitHub), then configure triggers (e.g., on commit or PR), then add tasks (build, test, etc.), and finally validate the pipeline by running it. This sequence is reflected in option A. Starting with source selection or adding tasks before creation is incorrect.

Full explanation →

402

MCQeasy

Refer to the exhibit. You run the Azure CLI command to trigger a pipeline run. The pipeline fails because tests were skipped but should have run. What is the most likely issue?

A.The JSON value for skipTests must be a boolean without quotes.

B.The pipeline name is incorrect.

C.The command uses a flag '--variables-parameters' which is not a valid Azure DevOps CLI option.

D.The branch 'feature/new-feature' does not exist.

AnswerA

The Azure DevOps CLI `az pipelines run` accepts variable values as JSON strings via `--variables`, and quoted booleans are passed as strings. However, the actual failure is that `--variables-parameters` is an invalid flag, so the command never parses this JSON to begin with.

Why this answer

The Azure DevOps CLI `az pipelines run` supports `--variables` and `--parameters` but not `--variables-parameters`. If that invalid flag were used, the command would fail before any pipeline run is triggered. The symptom says the pipeline ran and skipped tests, which is typically caused by passing `skipTests` as a string value (e.g., `"false"`) rather than a boolean `false`.

In Azure DevOps, pipeline variables are strings, so a value of `'false'` is interpreted as a non-empty string and evaluated as `true` in conditional logic. For runtime parameters of type boolean, the correct syntax is `--parameters '{"skipTests":false}'` (value without quotes).

Exam trap

Candidates may incorrectly blame an invalid CLI flag when the actual issue is with how a runtime parameter value is passed. Remember: `--variables` are strings; `--parameters` accepts JSON and requires boolean values without quotes.

How to eliminate wrong answers

Option A is wrong because in Azure CLI, JSON values passed via `--variables` are interpreted as strings; the `skipTests` value being `"true"` (a quoted string) is acceptable and does not cause tests to be skipped—the issue is the flag itself. Option B is wrong because if the pipeline name were incorrect, the CLI would return a 'pipeline not found' error, not a failure due to skipped tests. Option D is wrong because if the branch did not exist, the pipeline run would fail with a 'branch not found' error, not a test-skipping issue.

Full explanation →

403

Multi-Selecteasy

Which TWO practices help you manage build artifacts efficiently in Azure Pipelines?

Select 2 answers

A.Set retention policies to automatically delete old artifacts

B.Copy artifacts to each agent's local storage

C.Download all artifacts manually after each build

D.Publish build artifacts using the Publish Build Artifacts task

E.Store artifacts as large single files to reduce number of files

AnswersA, D

Setting retention policies automatically prunes outdated build artifacts, preventing storage bloat and reducing costs without manual intervention. You can define branch-specific or pipeline-specific retention rules, and the system cleans up old runs and their associated artifacts while preserving recent or stable builds. This ensures storage remains manageable and aligns with governance and compliance requirements.

Why this answer

Setting retention policies (A) helps automate cleanup of old artifacts, reducing storage waste. Using the Publish Build Artifacts task (D) is the standard way to store artifacts from builds efficiently. Option B (copying to each agent) is wasteful because it duplicates artifacts unnecessarily.

Option C (manual download) is inefficient because it requires human intervention and does not scale. Option E (large single files) makes downloads and incremental updates difficult.

Full explanation →

404

MCQmedium

Your team uses a monorepo in Azure Repos with multiple microservices. Developers frequently report merge conflicts due to long-lived feature branches. Which branching strategy minimizes merge conflicts while supporting continuous integration?

A.Use release branches for all development work and merge to main only at release time

B.Use GitFlow with separate develop and main branches, and long-lived feature branches

C.Use a forking workflow where each developer works in a personal fork and submits pull requests

D.Use trunk-based development with short-lived feature branches and frequent merges to main

AnswerD

Trunk-based development keeps branches short-lived and merges into main frequently, so divergent changes stay small and conflicts stay rare. Long-lived branches are the stated cause of conflicts; frequent integration directly removes that divergence while preserving continuous integration.

Why this answer

Trunk-based development with short-lived feature branches (typically lasting less than a day) minimizes merge conflicts by ensuring that changes are integrated into the main branch frequently, often multiple times per day. This approach reduces the divergence between branches, making conflicts less likely and easier to resolve. It also supports continuous integration by triggering automated builds and tests on every merge to main, aligning with the team's need for rapid feedback and reduced integration overhead.

Exam trap

The trap here is that candidates often associate GitFlow (Option B) with structured branching and mistakenly believe it reduces conflicts, but in reality, its long-lived feature branches increase conflict frequency and hinder continuous integration, making trunk-based development (Option D) the correct choice for minimizing conflicts and supporting CI.

How to eliminate wrong answers

Option A is wrong because using release branches for all development work and merging only at release time creates long-lived branches that accumulate significant divergence, leading to frequent and complex merge conflicts, and it violates CI principles by delaying integration. Option B is wrong because GitFlow with separate develop and main branches and long-lived feature branches encourages prolonged branch lifetimes, increasing the risk of merge conflicts and making continuous integration difficult due to infrequent merges to the main integration branch. Option C is wrong because a forking workflow, while useful for open-source projects with external contributors, introduces additional overhead in synchronizing forks and does not inherently reduce merge conflicts; it can actually increase them if forks diverge significantly before submitting pull requests.

Full explanation →

405

MCQmedium

Your team uses GitHub Issues to track work. You want to enforce that all new issues include a specific set of labels based on the issue type (bug, feature, task). What is the most efficient way to achieve this?

A.Configure branch protection rules to require label assignments.

B.Use a CODEOWNERS file to auto-assign labels.

C.Create YAML-based issue forms in the .github/ISSUE_TEMPLATE folder.

D.Set up a repository ruleset to restrict label modifications.

AnswerC

YAML-based issue forms in the `.github/ISSUE_TEMPLATE` folder allow you to define structured issue templates with fields and a `labels:` key that automatically applies specified labels when the form is submitted, enforcing consistent label assignment at issue creation.

Why this answer

GitHub issue forms, defined as YAML files in the .github/ISSUE_TEMPLATE folder, allow you to create structured templates that can enforce required fields, including mandatory label assignments. When a user submits an issue via a form, the labels specified in the template are automatically applied, ensuring consistency without manual intervention or additional automation.

Exam trap

The trap here is that candidates confuse branch protection rules or repository rulesets (which manage code changes) with issue management features, or mistakenly think CODEOWNERS can assign labels instead of reviewers.

How to eliminate wrong answers

Option A is wrong because branch protection rules apply to pull requests and branches, not to issue creation; they cannot enforce label assignments on new issues. Option B is wrong because CODEOWNERS is designed to automatically request reviews from specific teams or individuals based on file paths in a repository, not to assign labels to issues. Option D is wrong because repository rulesets control permissions and restrictions on branches and tags, not on issue metadata like labels; they cannot enforce label assignments on new issues.

Full explanation →

406

MCQmedium

Your build pipeline runs on a self-hosted agent pool. You need to ensure that only authorized pipelines can use these agents. Which security measure should you implement?

A.Set permissions on the agent pool

B.Use agent tokens

C.Use variable groups

D.Configure agent queues

AnswerA

Set permissions on the agent pool to control which pipelines can queue jobs on that pool. In Azure Pipelines, agent pool security roles (Reader, User, Administrator) govern authorization at the pool level, so you can restrict a pipeline or project from using specific self-hosted agents by modifying these permissions.

Why this answer

In Azure DevOps, agent pool security is controlled through the pool's permissions. By setting permissions on the agent pool, you can restrict which projects, pipelines, or users are allowed to use the agents, ensuring only authorized pipelines can run on them. This is the direct, built-in mechanism for securing a self-hosted agent pool.

Exam trap

AZ-400 often tests the confusion between agent registration tokens (used to join an agent to a pool) and pool permissions (used to control which pipelines can use the pool).

How to eliminate wrong answers

Option B is wrong because agent tokens are used during agent registration to authenticate the agent to the pool, not to authorize which pipelines can use the pool. Option C is wrong because variable groups store variables and secrets for pipelines; they have no role in controlling agent pool access. Option D is wrong because 'agent queues' is not a distinct Azure DevOps security feature — queues are associated with pools, and access is governed by pool permissions, not by configuring queues.

Full explanation →

407

MCQhard

Refer to the exhibit. An Azure CLI command outputs the configuration of an Azure Web App. Your pipeline deploys to this Web App using the 'AzureWebApp@1' task. The deployment fails with an error indicating that the runtime stack is not supported. What is the most likely cause?

A.The Web App is not a Linux app.

B.The ASPNETCORE_ENVIRONMENT setting is incorrect.

C.The runtime stack (DOTNETCORE|6.0) is not compatible with the deployed application.

D.The resource group name is incorrect.

AnswerC

The AzureWebApp@1 task deploys the built artefact to the Web App's configured runtime; if the app's stack is DOTNETCORE|6.0 but the artefact targets an incompatible framework, the task rejects it. The mismatch between configured stack and application is the cause.

Why this answer

The error 'runtime stack is not supported' indicates that the Azure Web App's configured runtime stack (DOTNETCORE|6.0) does not match the application being deployed. The AzureWebApp@1 task uses the Web App's stack setting to determine how to deploy and run the code; if the deployed app requires a different runtime (e.g., .NET 8.0 or a non-.NET framework), the deployment fails. Option C correctly identifies this mismatch as the root cause.

Exam trap

The trap here is that candidates often confuse runtime stack errors with environment variable misconfigurations (like ASPNETCORE_ENVIRONMENT) or OS-level issues, but the error message directly points to a mismatch between the Web App's configured stack and the deployed application's framework.

How to eliminate wrong answers

Option A is wrong because the runtime stack error is unrelated to whether the Web App is Linux or Windows; both platforms support runtime stack configurations, and the error specifically points to an unsupported stack, not the OS type. Option B is wrong because the ASPNETCORE_ENVIRONMENT setting controls the environment name (e.g., Development, Production) and does not affect runtime stack compatibility; it is an application-level configuration, not a deployment-level one. Option D is wrong because an incorrect resource group name would cause a different error (e.g., 'Resource group not found') during the task's initial resource lookup, not a runtime stack error during deployment.

Full explanation →

408

Multi-Selectmedium

Which TWO are true about Azure Pipelines YAML templates? (Choose two.)

Select 2 answers

A.Templates must be stored in the same repository as the main pipeline.

B.Template expressions are evaluated at compile time.

C.Templates require parameters to be defined.

D.Templates can be nested by including other templates.

E.Templates can only define a single job.

AnswersB, D

Expressions like '${{ variables.var }}' are expanded when the pipeline is compiled, before any runtime execution. This enables conditional inclusion of stages, jobs, or steps based on parameters or compile-time variables, but they cannot reference runtime values like agent-specific variables.

Why this answer

Template expressions in Azure Pipelines YAML are evaluated at compile time, before the pipeline runs. This allows the template to inject variables, conditions, and other logic into the pipeline definition statically, ensuring that the final pipeline structure is fully resolved before execution begins.

Exam trap

The trap here is that candidates often confuse compile-time evaluation with runtime evaluation, leading them to think template expressions can use runtime variables, or they mistakenly believe templates must be in the same repo or require parameters, when in fact templates are flexible and optional in their structure.

Full explanation →

409

MCQeasy

Your organization is adopting DevSecOps and wants to integrate security scanning into the CI/CD pipeline. Which tool should you use to scan container images for vulnerabilities?

A.Azure Monitor

B.GitHub Copilot

C.Microsoft Defender for Cloud

D.Azure Logic Apps

AnswerC

Microsoft Defender for Cloud, specifically through Microsoft Defender for Containers, includes vulnerability scanning for container images in Azure Container Registry (ACR) and other registries. It uses Microsoft Defender Vulnerability Management to detect OS and language-level CVEs and can be integrated into a CI/CD pipeline as a quality gate, blocking vulnerable images from being promoted to production.

Why this answer

Microsoft Defender for Cloud (Option C) is the correct tool for scanning container images for vulnerabilities in a CI/CD pipeline, as it integrates with Azure Container Registry to perform vulnerability assessments. Option A (Azure Monitor) is incorrect because it is a monitoring and observability service, not a security scanner. Option B (GitHub Copilot) is incorrect as it is an AI code completion tool.

Option D (Azure Logic Apps) is incorrect because it is a workflow automation service, not a security scanning tool.

Full explanation →

410

Multi-Selectmedium

Which THREE of the following are prerequisites for implementing a CI/CD pipeline for a .NET Core application?

Select 3 answers

A.Build agent (Microsoft-hosted or self-hosted)

B.Source control repository (e.g., Git)

C.Unit test framework

D.Docker container registry

E.Target deployment environment (e.g., App Service)

AnswersA, B, E

A build agent, whether Microsoft-hosted or self-hosted, provides the compute environment where pipeline tasks such as restore, build, test, and publish execute. Without an available and properly configured agent, the pipeline has no infrastructure to run on, making it an absolute prerequisite for any implementation.

Why this answer

A build agent is required to execute the pipeline tasks, such as compiling code, running tests, and packaging artifacts. Microsoft-hosted agents provide a pre-configured environment with common tools, while self-hosted agents allow custom configurations and access to on-premises resources. Without a build agent, the CI/CD pipeline cannot perform any automated build or deployment steps.

Exam trap

The trap here is that candidates often mistake optional pipeline components (like unit tests or container registries) as prerequisites, when in fact only the core infrastructure (agent, source control, and target environment) is mandatory for a basic CI/CD pipeline.

Full explanation →

411

Multi-Selecthard

You are designing a release pipeline for a .NET Core application that must comply with regulatory requirements. The pipeline must sign the assembly with a code-signing certificate stored in Azure Key Vault. Which THREE actions should you perform?

Select 3 answers

A.Add a step to download the certificate from Key Vault using the AzureKeyVault task.

B.Use a script task to invoke the signing tool (e.g., signtool.exe) after the build.

C.Grant the Azure Pipelines service principal access to the Key Vault.

D.Store the certificate in a secure file in the build artifact.

E.Package the application before signing to avoid signature corruption.

AnswersA, B, C

The AzureKeyVault task retrieves the code-signing certificate from Key Vault into the pipeline agent, making it available to the signing step. This satisfies the regulatory requirement that the certificate stays in Key Vault rather than being stored insecurely in the repository.

Why this answer

Option A is correct because the AzureKeyVault task (AzureKeyVault@2) is the supported pipeline task for retrieving secrets, including a code-signing certificate, from an Azure Key Vault so the certificate can be used during the build. Option B is correct because after the assembly is built, a script or command-line step must invoke a signing tool such as signtool.exe with the certificate to apply the code-signing signature to the .NET Core assembly. Option C is correct because the Azure Pipelines service principal (or the identity running the pipeline) must be granted access to the Key Vault, typically via an access policy or Azure RBAC role such as Key Vault Secrets User, otherwise the AzureKeyVault task cannot retrieve the certificate.

Option D is not correct because storing the certificate in a secure file in the build artifact does not satisfy the requirement to use a certificate stored in Azure Key Vault and can expose the private key in the artifact. Option E is not correct because packaging before signing would leave the package unsigned; signing must occur on the assembly before it is packaged so the signature is included in the final artifact.

Exam trap

AZ-400 often tests whether candidates confuse 'storing the certificate in a secure file' (a legacy, non-compliant pattern) with the modern Key Vault task approach, and whether they understand signing must occur post-build but pre-packaging.

Full explanation →

412

MCQmedium

A developer pushes a commit to a branch named 'releases/v1.0'. What will happen?

A.The pipeline runs but fails because the branch name contains a dot.

B.The pipeline runs only if a pull request is created.

C.The pipeline runs automatically on the push.

D.The pipeline does not run because the branch is not main.

AnswerC

This outcome is expected because the repository's Azure Pipelines YAML defines a continuous integration (CI) trigger with a branch include filter such as `releases/*`. Since `releases/v1.0` matches that pattern, the push event automatically queues a new pipeline run, even without a pull request. The filter comparison uses glob-style matching on the full branch ref, and Azure Pipelines evaluates it at the time the push is received, making the run immediate and unattended.

Why this answer

Azure Pipelines, by default, triggers a pipeline run automatically on any push to any branch unless a trigger filter is explicitly configured. The branch name 'releases/v1.0' is valid and does not contain any characters that would prevent a trigger; dots are allowed in branch names. The pipeline will execute the steps defined in the YAML file for that branch.

Exam trap

The trap here is that candidates may assume branch names with dots are invalid or that pipelines only run on the main branch, but Azure Pipelines treats all branches equally by default and dots are perfectly valid in Git branch names.

How to eliminate wrong answers

Option A is wrong because Azure Pipelines does not restrict branch names containing dots; dots are valid characters in Git branch names and do not cause pipeline failures. Option B is wrong because a push to a branch triggers the pipeline automatically by default, regardless of whether a pull request is created; pull request triggers are a separate configuration. Option D is wrong because Azure Pipelines does not require the branch to be 'main' to run; pipelines can be configured to trigger on any branch, and by default they trigger on all branches.

Full explanation →

413

MCQmedium

Your organization uses GitHub Actions. You need to create a reusable workflow that builds and tests a Node.js application. Which approach should you use to define the workflow?

A.Define a standard workflow in .github/workflows/build.yml

B.Use a composite action to encapsulate the build steps

C.Create a custom action and reference it in multiple workflows

D.Define a reusable workflow with 'on: workflow_call'

AnswerD

Defining a reusable workflow with on: workflow_call is correct because it makes the workflow callable from other workflows using the uses: syntax (e.g., uses: ./.github/workflows/build.yml), allowing you to create a standard build pipeline that can be referenced by many workflows without duplicating job definitions.

Why this answer

A reusable workflow in GitHub Actions is defined by placing a workflow file in .github/workflows/ and adding the 'on: workflow_call' trigger. This allows the workflow to be called from other workflows in the same repository or organization, enabling centralized build and test logic. Unlike composite actions, reusable workflows can contain multiple jobs and run on their own runners, making them ideal for orchestrating complex CI/CD pipelines like building and testing a Node.js app.

Exam trap

AZ-400 often tests the confusion between reusable workflows and composite actions, where candidates mistakenly believe a composite action can be called like a workflow or that a standard workflow can be reused without the workflow_call trigger.

How to eliminate wrong answers

Option A is wrong because a standard workflow with triggers like 'on: push' or 'on: pull_request' cannot be directly invoked by other workflows; it only runs on its own events. Option B is wrong because a composite action encapsulates a series of steps within a single job and cannot define multiple jobs or use its own runner, limiting its reusability for full build and test workflows. Option C is wrong because a custom action (JavaScript or Docker) is a single task, not a workflow; it cannot contain jobs or be called as a workflow, and referencing it in multiple workflows still requires duplicating the job structure.

Full explanation →

414

MCQhard

You are reviewing a Data Collection Rule (DCR) for an Azure virtual machine. The DCR is assigned to the VM, and the Azure Monitor Agent is installed. After one hour, no performance data appears in the Log Analytics workspace. What is the most likely cause?

A.The workspace resource ID is incorrectly formatted.

B.The data flow streams property does not include 'Microsoft-Perf'.

C.The counter specifier uses the wrong format for Windows performance counters.

D.The sampling frequency of 60 seconds is too low and data is being throttled.

AnswerB

The data flow streams property does not include 'Microsoft-Perf'. For Windows performance counters to be collected in an Azure Monitor DCR, the 'dataFlows' section must map the 'Microsoft-Perf' stream to the destination workspace; without this stream explicitly listed, the DCR lacks the required linkage for performance data ingestion, and no counter data will flow.

Why this answer

The most likely cause is that the data flow streams property in the DCR does not include 'Microsoft-Perf'. The Azure Monitor Agent uses DCRs to define which data to collect and where to send it. Without the 'Microsoft-Perf' stream specified in the dataFlows section, performance counters are not collected, even if the counter specifiers are correctly defined.

The workspace resource ID and counter format may be correct, but the missing stream prevents any performance data from being ingested.

Exam trap

The trap here is that candidates focus on the counter specifier format or sampling frequency, overlooking the critical data flow stream property which is the actual pipeline that enables data ingestion.

How to eliminate wrong answers

Option A is wrong because an incorrectly formatted workspace resource ID would typically cause a configuration error or a failure to connect, not a silent absence of data after one hour; the agent would log an error. Option B is wrong because it is actually the correct answer, not a wrong option. Option C is wrong because the counter specifier format (e.g., '\Processor(_Total)\% Processor Time' for Windows) is validated at DCR creation time, and an incorrect format would result in a schema validation error, not a one-hour delay with no data.

Option D is wrong because a sampling frequency of 60 seconds is standard and not too low; Azure Monitor does not throttle data based on sampling frequency, and throttling would affect all data types, not just performance counters.

Full explanation →

415

MCQmedium

Refer to the exhibit. You have this YAML pipeline in an Azure Repos repository. What is the expected behavior when a pull request is created from a feature branch to the main branch?

A.The pipeline runs twice: once on PR creation and once on merge.

B.The pipeline runs automatically on the PR to main, triggered by the pr trigger.

C.The pipeline runs when the PR is merged to main, triggered by the trigger block.

D.The pipeline does not run automatically on the PR; it must be triggered manually or via branch policy.

AnswerD

Without a PR trigger or branch policy configured in the YAML, the pipeline has no event that fires on pull request creation, so it stays idle until manually queued or invoked by a build validation policy.

Why this answer

The YAML pipeline shown does not include a `pr` trigger, and the `trigger` block only applies to CI (continuous integration) builds on branch pushes, not pull requests. Without a `pr` trigger, Azure Pipelines does not automatically run on pull request creation; it must be triggered manually or via a branch policy configured in the repository settings.

Exam trap

The trap here is that candidates often assume the `trigger` block also applies to pull requests, but in Azure Pipelines, `trigger` and `pr` are separate, and omitting `pr` means no automatic PR build occurs.

How to eliminate wrong answers

Option A is wrong because the pipeline does not have a `pr` trigger, so it will not run on PR creation, and the `trigger` block only triggers on merges to main, not on PR creation. Option B is wrong because the `pr` trigger is not defined in the YAML; without it, Azure Pipelines does not automatically run on PRs to main. Option C is wrong because while the `trigger` block would cause the pipeline to run on a merge to main, the question asks about behavior when a PR is created, not when it is merged.

Full explanation →

416

MCQhard

Your team uses Azure Boards with a custom process. You need to ensure that when a bug is closed, it automatically triggers a new release pipeline. Which approach should you use?

A.Configure a CI trigger in the release pipeline.

B.Add a release gate that checks for closed bugs.

C.Create an Azure Function that polls work items.

D.Set up a Service Hook from Azure Boards to Azure Pipelines.

AnswerD

Service Hooks in Azure Boards can subscribe to work item state change events and directly trigger an Azure Pipelines release, providing the native, event-driven integration needed to initiate a release when a bug is closed or another work item field is updated.

Why this answer

Service Hooks in Azure DevOps allow you to integrate Azure Boards with Azure Pipelines by subscribing to events like 'work item updated' or 'work item state changed'. When a bug is closed (state changed to 'Closed'), a Service Hook can automatically trigger a release pipeline, enabling event-driven automation without polling or custom code. This is the correct approach because it directly connects the work item state change to pipeline execution.

Exam trap

The trap here is that candidates often confuse CI triggers (which respond to code changes) with event-driven triggers from work items, or mistakenly think release gates can initiate pipelines rather than just gate ongoing releases.

How to eliminate wrong answers

Option A is wrong because a CI trigger in a release pipeline is designed to fire on code changes (e.g., a commit or pull request merge), not on work item state changes in Azure Boards. Option B is wrong because release gates are conditions evaluated during a release (e.g., checking for approvals or quality metrics), not triggers that initiate a new release; they cannot start a pipeline based on a work item being closed. Option C is wrong because creating an Azure Function to poll work items introduces unnecessary complexity, latency, and overhead compared to the native event-driven Service Hook mechanism, which is simpler and more reliable.

Full explanation →

417

MCQhard

Your company uses Microsoft Defender for Cloud to monitor Azure DevOps environments. You receive an alert that a service principal has excessive permissions. What is the first step you should take to investigate and remediate?

A.Reduce the service principal's permissions to the minimum required.

B.Review the Microsoft Entra ID audit logs for the service principal.

C.Immediately delete the service principal.

D.Reset the service principal's credentials.

AnswerB

Reviewing the Microsoft Entra ID audit logs is the correct first step because these logs provide a detailed trail of the service principal's sign-ins, granted permissions, and activities, allowing you to determine whether the alert indicates a real threat or normal operation before taking any corrective action.

Why this answer

Reviewing the Microsoft Entra ID audit logs is the correct first step because it allows you to investigate the service principal's activity, such as which resources it accessed, when, and from where, before taking any remediation action. This forensic analysis is essential to understand the scope of the excessive permissions and to ensure that reducing permissions or other actions do not inadvertently disrupt legitimate operations. Without this step, you risk breaking functionality or missing evidence of misuse.

Exam trap

The trap here is that candidates often jump to immediate remediation (reducing permissions or deleting the principal) without first performing a forensic investigation, failing to recognize that the first step in incident response is always to gather evidence via audit logs to understand the scope and impact.

How to eliminate wrong answers

Option A is wrong because reducing permissions immediately without first investigating the audit logs could disrupt legitimate automated processes or deployments that depend on those permissions, and it skips the necessary forensic step to understand the context of the alert. Option C is wrong because immediately deleting the service principal is a drastic action that could cause widespread service outages, as the service principal may be essential for CI/CD pipelines or other automated tasks, and it destroys the ability to audit past activities. Option D is wrong because resetting the service principal's credentials (e.g., client secret or certificate) addresses credential compromise but does not remediate the root cause of excessive permissions, and it should be done only after investigation to avoid breaking active sessions without understanding the impact.

Full explanation →

418

MCQhard

You are designing a centralized logging strategy for multiple microservices hosted in Azure Kubernetes Service (AKS). Each microservice writes logs in JSON format to stdout/stderr. The operations team needs to query logs across all services and correlate them with application performance metrics. Which solution provides the best integration?

A.Configure AKS to send logs to Azure Blob Storage and use Azure Storage Analytics for querying.

B.Enable Container Insights in Azure Monitor to collect stdout/stderr logs and metrics into a Log Analytics workspace.

C.Stream logs to Azure Event Hubs and then to Azure Data Explorer for analysis.

D.Deploy the Application Insights agent as a DaemonSet in AKS and send logs directly to Application Insights.

AnswerB

Container Insights is the native Azure Monitor solution for AKS: it deploys a Log Analytics agent as a DaemonSet to collect stdout/stderr logs, performance metrics, and container inventory into a Log Analytics workspace. This enables rich Kusto Query Language (KQL) queries, alerting, and correlation with other Azure Monitor data, making it the correct centralized logging approach for AKS workloads.

Why this answer

Container Insights in Azure Monitor is the best solution because it natively collects stdout/stderr logs from AKS containers and correlates them with performance metrics (CPU, memory, disk, network) in a single Log Analytics workspace. This enables the operations team to query logs across all microservices using KQL and join them with metrics for end-to-end troubleshooting, without additional infrastructure or data movement.

Exam trap

The trap here is that candidates often confuse Application Insights (designed for application-level telemetry) with Container Insights (designed for container-level logs and metrics), leading them to choose Option D, which lacks the native AKS metric correlation and Log Analytics workspace integration required for centralized querying.

How to eliminate wrong answers

Option A is wrong because Azure Blob Storage is a cold storage tier with no native query capability for JSON logs; Storage Analytics provides only storage metrics, not log search or correlation with application performance metrics. Option C is wrong because streaming logs to Event Hubs and then to Azure Data Explorer adds unnecessary complexity and latency; while ADX is a powerful analytics engine, it is not the integrated, out-of-the-box solution for AKS log and metric correlation that Container Insights provides. Option D is wrong because the Application Insights agent as a DaemonSet sends logs directly to Application Insights, which is designed for application-level telemetry (traces, exceptions, requests) rather than container stdout/stderr logs and AKS node/container metrics; it lacks the native integration with AKS cluster-level metrics and Log Analytics workspace that Container Insights offers.

Full explanation →

419

MCQmedium

Refer to the exhibit. An Azure DevOps pipeline has the YAML configuration shown. A developer creates a pull request from a feature branch to the develop branch. What will happen?

A.The pipeline runs only if the PR is merged

B.The pipeline runs as a CI build on the feature branch

C.The pipeline runs as a PR validation build

D.The pipeline does not run automatically

AnswerD

The CI trigger only includes `develop` and `main`, while the PR trigger only includes `main`; the exhibited feature-branch push/PR matches neither branch filter. Consequently, the pipeline has no automatic trigger event and will not run on its own.

Why this answer

The YAML configuration does not include a `trigger` or `pr` trigger, so by default the pipeline only runs on pushes to branches that have a pipeline configured, not on pull requests. Since the developer creates a PR from a feature branch to develop, and no trigger is defined for the feature branch or PR validation, the pipeline does not run automatically.

Exam trap

The trap here is that candidates assume a pull request automatically triggers a pipeline, but Azure DevOps requires an explicit `pr` trigger for PR validation builds, and without it, no automatic execution occurs.

How to eliminate wrong answers

Option A is wrong because the pipeline does not run on merge unless a trigger is defined for the target branch (develop) or the PR is configured to trigger on completion; without a trigger, no automatic run occurs. Option B is wrong because a CI build on the feature branch would require a `trigger` (e.g., `trigger: branches: include: ['feature/*']`) which is absent in the YAML. Option C is wrong because a PR validation build requires a `pr` trigger (e.g., `pr: branches: include: ['develop']`) which is not present in the configuration.

Full explanation →

420

MCQmedium

Your team deploys a web application to Azure App Service using Azure Pipelines. The application requires a configuration file that contains connection strings and app settings. You need to ensure that the configuration is environment-specific and that sensitive values are not exposed in the pipeline logs. The configuration file is stored in a Git repository with different branches for each environment. You also need to support local development with the same configuration approach. Which strategy should you use?

A.Store all settings, including secrets, in the config file in each branch. Use a script to replace tokens.

B.Use Azure App Service slots with sticky settings and store all settings in a single config file committed to the repository.

C.Store environment-specific settings in Azure App Service configuration, and use variable groups in Azure Pipelines for secrets. Use token replacement in the config file during deployment.

D.Use the same config file for all environments and override settings using pipeline variables based on branch name.

AnswerC

Token replacement keeps the same config file across branches while substituting environment-specific values at deploy time, and variable groups hold secrets so they are masked in logs. App Service configuration supplies runtime settings, satisfying environment-specificity, secret protection and local development parity.

Why this answer

The correct strategy is to store environment-specific settings in Azure App Service configuration (which can be set per slot/environment) and use Azure Pipelines variable groups for secrets, ensuring they are not exposed in logs. Token replacement in the config file during deployment allows the same config file to be used across environments while injecting environment-specific values. This supports local development because developers can use local settings or user secrets without committing sensitive data.

Exam trap

AZ-400 often tests the misconception that storing secrets in config files or pipeline variables without proper masking is acceptable, or that a single config file with overrides is sufficient; candidates must recognize the need for secure secret storage and environment-specific configuration.

How to eliminate wrong answers

Option A is wrong because storing secrets in a config file in each branch exposes them in the repository and pipeline logs, violating security best practices. Option B is wrong because using a single config file with all settings committed to the repository still exposes secrets and does not provide environment-specific separation; sticky settings alone do not secure secrets. Option D is wrong because using the same config file and overriding with pipeline variables based on branch name can work for non-sensitive values but does not address secure storage of secrets and may still expose them if not handled properly; it also lacks a clear mechanism for local development.

Full explanation →

421

MCQeasy

Your team uses GitHub and wants to enforce that all commits to the main branch are signed with a GPG key. Which branch protection rule should you configure?

A.Require pull request reviews before merging.

B.Require status checks to pass before merging.

C.Require linear history.

D.Require signed commits.

AnswerD

Requiring signed commits is a branch protection rule that rejects any commit not cryptographically signed with a verified GPG or S/MIME key, authenticating the committer and ensuring content integrity. This directly enforces that every commit must be signed, exactly as the requirement demands.

Why this answer

The 'Require signed commits' branch protection rule enforces that every commit pushed to the protected branch must be signed with a GPG key. This ensures cryptographic verification of the commit author's identity, directly addressing the requirement to enforce signed commits on the main branch.

Exam trap

The trap here is that candidates confuse 'Require signed commits' with 'Require status checks to pass before merging', mistakenly thinking a CI status check can enforce signing, but GitHub's built-in rule is the only way to natively reject unsigned commits at the server level.

How to eliminate wrong answers

Option A is wrong because requiring pull request reviews before merging enforces code review, not commit signing. Option B is wrong because requiring status checks to pass before merging enforces CI/CD pipeline checks (e.g., tests, builds), not cryptographic signing of commits. Option C is wrong because requiring linear history enforces a linear commit graph (no merge commits), but does not require commits to be signed with a GPG key.

Full explanation →

422

Multi-Selectmedium

You are designing an instrumentation strategy for a new application that will be deployed to Azure. The application consists of an Azure App Service web front end, an Azure Functions backend, and an Azure SQL Database. You need to collect telemetry that allows you to correlate requests across all components and analyze performance bottlenecks. You plan to use Application Insights. Which two actions should you perform? (Choose two.)

Select 2 answers

A.Enable sampling in each component with different sampling rates to optimize telemetry volume.

B.Enable the Application Insights SDK in the App Service and Azure Functions code to track requests and dependencies.

C.Configure the Azure SQL Database to send diagnostic logs to a Log Analytics workspace and link the workspace to Application Insights.

D.Deploy the Application Insights status monitor to the App Service and Azure Functions to enable automatic instrumentation.

E.Use the same Application Insights resource for all components to enable cross-component correlation.

AnswersB, E

To correlate requests across components, each component must emit telemetry with a common operation ID. The Application Insights SDK provides automatic instrumentation for incoming requests and outgoing dependencies, and it propagates the correlation context across HTTP calls. This is essential for end-to-end transaction diagnostics in Application Insights.

Why this answer

To correlate requests across App Service, Azure Functions, and Azure SQL, you need application-level instrumentation in each component and a shared Application Insights resource. The SDK tracks requests and dependencies and propagates correlation context, while a single resource stores all telemetry for unified analysis. Database logs and inconsistent sampling do not provide the required end-to-end view.

Exam trap

The trap here is thinking that enabling diagnostic logs on Azure SQL Database and linking workspaces will automatically correlate database calls with application telemetry, when correlation requires SDK instrumentation and a shared Application Insights resource.

Full explanation →

423

MCQhard

You are implementing a release pipeline for a containerized application using Azure Kubernetes Service (AKS). The pipeline should use canary deployments to gradually shift traffic from the stable version to the new version. Which strategy should you use to manage the traffic shift?

A.Blue-green deployment strategy

B.Rolling update strategy

C.A/B testing with feature flags

D.Canary deployment using a service mesh (e.g., Istio)

AnswerD

Canary deployment using a service mesh (e.g., Istio) is correct because Istio's traffic management rules (VirtualService and DestinationRule) allow precise percentage-based traffic splitting between the stable and canary versions of a containerized workload. This enables gradual exposure, real-time metrics collection, and automated or manual rollback, making it the ideal strategy for safely validating a new release in production.

Why this answer

A service mesh like Istio provides fine-grained traffic management capabilities (e.g., using VirtualService and DestinationRule resources) that allow you to route a specific percentage of traffic to the new canary version while the rest goes to the stable version. This enables gradual traffic shifting without modifying application code, and supports advanced routing rules based on headers or weights, which is essential for canary deployments in AKS.

Exam trap

The trap here is that candidates confuse canary deployments with blue-green or rolling updates, not realizing that only a service mesh (or similar traffic-splitting mechanism) provides the precise, percentage-based traffic shifting required for a true canary release in Kubernetes.

How to eliminate wrong answers

Option A is wrong because blue-green deployment switches all traffic at once between two environments (blue and green), not gradually shifting traffic as required by canary deployments. Option B is wrong because a rolling update replaces pods incrementally but does not allow fine-grained traffic splitting between versions; it updates all pods to the new version over time without a controlled canary phase. Option C is wrong because A/B testing with feature flags controls feature exposure at the application level (e.g., via code toggles), not at the network/traffic level, and does not inherently manage traffic shifting between container versions in a Kubernetes cluster.

Full explanation →

424

MCQeasy

You are creating a YAML pipeline in Azure Pipelines that must run three jobs: 'Build', 'Test', and 'Deploy'. The 'Test' job must run only after the 'Build' job completes successfully, and the 'Deploy' job must run only after the 'Test' job completes successfully. You need to configure the dependencies between jobs. What should you use?

A.condition

B.dependsOn

C.continueOnError

D.stages

AnswerB

The 'dependsOn' keyword in Azure Pipelines YAML defines the order of job execution. By specifying 'dependsOn: Build' in the Test job and 'dependsOn: Test' in the Deploy job, you ensure that each job runs only after its dependency completes successfully. This is the correct way to model sequential job dependencies.

Why this answer

To enforce sequential job execution where each job runs only after the previous one succeeds, you must use the 'dependsOn' keyword. This explicitly defines the dependency graph, ensuring that the Test job waits for Build and the Deploy job waits for Test, and that a failure in a dependency prevents dependent jobs from running.

Exam trap

The trap here is confusing 'condition' with 'dependsOn'; 'condition' controls whether a job runs but does not create a dependency, so jobs would still run in parallel unless 'dependsOn' is also specified.

Full explanation →

425

Drag & Dropmedium

Drag and drop the steps to implement infrastructure as code with Azure Resource Manager (ARM) templates into the correct order.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

The correct order for implementing infrastructure as code with ARM templates is: first define the ARM template, then parameterize it to make it reusable, then store it in version control (e.g., Git) to track changes, then validate the deployment using the what-if operation to preview changes, and finally deploy the template to Azure.

Full explanation →

426

MCQeasy

A DevOps engineer needs to ensure that only approved Azure Resource Manager (ARM) templates are used for deployments. They want to enforce this at the subscription level. Which Azure service should they use?

A.Azure Role-Based Access Control (RBAC)

B.Azure Policy

C.Azure Blueprints

D.Azure Management Groups

AnswerB

Azure Policy can evaluate ARM template properties during deployment and deny or audit resources that do not comply with defined rules, such as allowed template versions or specific resource types. This enables enforcing approved templates across the enterprise by blocking non-compliant deployment attempts.

Why this answer

Azure Policy is the correct service because it allows you to create, assign, and manage policies that enforce specific rules on your Azure resources. You can define a custom policy to audit or deny resources that do not contain metadata indicating they were deployed from an approved ARM template. Azure Policy evaluates all resource creation and update requests against these rules, blocking or auditing non-compliant deployments at the subscription level.

RBAC only controls who can deploy, not what is deployed; Azure Blueprints packages templates but does not enforce their exclusive use.

Exam trap

The trap here is that candidates often confuse Azure Policy with Azure RBAC, thinking that role-based access can restrict template content, when in fact RBAC only controls who can deploy, not what they deploy.

How to eliminate wrong answers

Option A is wrong because Azure RBAC controls who can perform actions (authentication and authorization) on resources, not what specific ARM templates are allowed; it cannot inspect the content or source of a template. Option C is wrong because Azure Blueprints is used to orchestrate the deployment of a repeatable set of Azure resources (including policies, RBAC, and resource groups) but does not itself enforce which ARM templates are used; it relies on Azure Policy for enforcement. Option D is wrong because Azure Management Groups provide a hierarchical structure for managing access, policies, and compliance across multiple subscriptions, but they do not directly enforce ARM template restrictions; they are a container for applying policies, not the enforcement mechanism itself.

Full explanation →

427

MCQhard

Your team uses GitHub Actions for CI/CD. You need to enforce that all workflows use approved actions from a private marketplace. Which GitHub feature should you configure?

A.Use environment secrets to store allowed action names.

B.Require self-hosted runners.

C.Set the Actions permissions to 'Allow only specified actions'.

D.Configure OpenID Connect (OIDC) for Actions.

AnswerC

Setting Actions permissions to 'Allow only specified actions' creates an explicit allowlist at the repository or organization level, so only actions (and optional version constraints) that you add are permitted. Any action not on that list is blocked from running, which is exactly the enforcement mechanism needed for this policy.

Why this answer

The 'Allow only specified actions' setting in GitHub Actions permissions allows you to restrict workflow execution to a curated list of actions from a private marketplace or specific verified publishers. This enforces governance by preventing the use of unapproved actions, which is critical for compliance and security in enterprise CI/CD pipelines.

Exam trap

The trap here is that candidates often confuse runner-level controls (self-hosted runners) with action-level governance, mistakenly thinking that restricting where code runs also restricts what actions can be used.

How to eliminate wrong answers

Option A is wrong because environment secrets are used to store sensitive values like API tokens, not to enforce action allowlists; they cannot control which actions are permitted at the repository or organization level. Option B is wrong because self-hosted runners control where workflows execute, not which actions they can use; they do not provide a mechanism to restrict action selection. Option D is wrong because OpenID Connect (OIDC) is used for short-lived authentication tokens between GitHub Actions and cloud providers, not for managing action permissions or marketplace access.

Full explanation →

428

MCQhard

You have the YAML pipeline snippet shown in the exhibit. The first run produces version 1.0.0. What will be the version produced on the third run?

A.1.0.1

B.1.0.3

C.1.0.2

D.1.0.0

AnswerC

The counter expression returns 0 on the first run, 1 on the second, and 2 on the third for a given key. With the prefix '1.0', the third run correctly produces 1.0.2, matching the exhibit.

Why this answer

The YAML pipeline uses a counter expression `$[counter(format('{0}.{1}', variables['major'], variables['minor']), 0)]` for the patch version. The counter starts at 0 for the first run, producing version 1.0.0. Each subsequent run increments the counter by 1, so the second run produces 1.0.1, and the third run produces 1.0.2.

Therefore, option C is correct.

Exam trap

The trap here is that candidates may mistakenly think the counter starts at 1 or that the version increments by more than 1 per run, leading them to choose 1.0.1 or 1.0.3 instead of understanding the exact sequential increment from the seed value.

How to eliminate wrong answers

Option A is wrong because 1.0.1 would be the version produced on the second run, not the third. Option B is wrong because 1.0.3 would be the version produced on the fourth run, as the counter increments by 1 each run. Option D is wrong because 1.0.0 is the version produced on the first run, and the counter does not reset to 0 on subsequent runs.

Full explanation →

429

MCQhard

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

A.Add the 'azure/login' action with Azure credentials

B.Add the 'actions/setup-node' action

C.Add the 'azure/webapps-deploy' action

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

AnswerA

Adding the 'azure/login' action with Azure credentials is correct because it authenticates the Azure CLI with a service principal, establishing an Azure session (via the `AZURE_CREDENTIALS` secret containing client ID, client secret, tenant ID, and subscription ID) that subsequent steps can use to run `az` commands. Without this authentication step, any Azure CLI command in the workflow fails with an authentication error, even if the workflow itself runs successfully.

Why this answer

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

Exam trap

The trap here is that candidates may assume any Azure action (like 'azure/webapps-deploy') implicitly handles authentication, but in reality, authentication must be explicitly performed before any Azure CLI or SDK calls.

How to eliminate wrong answers

Option B is wrong because 'actions/setup-node' sets up a Node.js environment and has no role in Azure authentication. Option C is wrong because 'azure/webapps-deploy' deploys to Azure Web Apps but does not authenticate the Azure CLI; it relies on prior authentication from 'azure/login'. Option D is wrong because 'actions/github-script' runs scripts using the GitHub token, which is not valid for authenticating to Azure resources.

Full explanation →

430

MCQhard

Your release pipeline uses a 'Run Azure CLI' task to execute a script. The script authenticates using a service principal. However, the deployment fails with 'insufficient privileges to complete the operation'. What is the most likely cause?

A.The Azure CLI task is not logged in.

B.The service principal secret has expired.

C.The service principal lacks the necessary RBAC role on the target resource.

D.The service principal does not have a secret.

AnswerC

The service principal is authenticated but does not have the required Azure RBAC role (e.g., Contributor, Reader, or a custom role) on the target resource or resource group. Azure CLI commands that attempt to perform an action without the necessary role assignment will return an authorization error, so assigning the appropriate RBAC role resolves the issue.

Why this answer

The error 'insufficient privileges to complete the operation' indicates that the service principal successfully authenticated but lacks the required Azure RBAC role on the target resource. Even with a valid secret and a logged-in Azure CLI session, the service principal must have an assigned role (e.g., Contributor, Owner, or a custom role) that grants the specific permissions needed for the deployment operation.

Exam trap

The trap here is that candidates confuse authentication failures (invalid credentials, expired secrets) with authorization failures (insufficient RBAC permissions), leading them to incorrectly select options related to credential issues when the error message explicitly states 'insufficient privileges'.

How to eliminate wrong answers

Option A is wrong because the 'Run Azure CLI' task automatically handles authentication via the service principal connection; if the task were not logged in, the error would be an authentication failure (e.g., 'login failed' or 'unable to acquire token'), not an authorization error. Option B is wrong because an expired secret would cause an authentication failure (e.g., 'invalid client secret' or 'AADSTS7000222'), not an 'insufficient privileges' error which occurs after successful token acquisition. Option D is wrong because if the service principal had no secret, the Azure CLI task would fail to authenticate entirely, producing a credential-related error rather than an RBAC authorization error.

Full explanation →

431

MCQeasy

You are designing a release pipeline in Azure Pipelines that deploys a web app to multiple environments (dev, test, prod). You want to ensure that the same build artifact is deployed to each environment without rebuilding. Which trigger type should you use?

A.Pull request trigger

B.Continuous deployment trigger on the release pipeline

C.Schedule trigger

D.Build completion trigger

AnswerB

A continuous deployment trigger on the release pipeline is the artifact trigger that watches a connected build artifact for a successful build. When a new version of that artifact is produced, the trigger automatically creates a release and promotes that exact artifact through every stage, so all environments test and receive the same immutable build. This precisely matches the requirement to use the same artifact without rebuilding or recompiling.

Why this answer

A continuous deployment trigger on the release pipeline automatically starts a new release deployment whenever a new build artifact is available, ensuring the same build artifact is deployed to each environment without rebuilding. This is the correct choice because the requirement is to deploy the same artifact across multiple environments, and the continuous deployment trigger is designed to initiate a release pipeline after a build completes, preserving the artifact for downstream stages.

Exam trap

The trap here is that candidates often confuse build completion triggers (which chain builds) with continuous deployment triggers (which chain builds to releases), leading them to select build completion trigger thinking it will automatically deploy to environments, but it only triggers another build pipeline, not a release.

How to eliminate wrong answers

Option A is wrong because a pull request trigger is used to validate code changes in a build pipeline, not to deploy existing artifacts to multiple environments; it triggers a build on PR creation, not a release deployment. Option C is wrong because a schedule trigger runs the release pipeline at specified times, which does not guarantee that the same build artifact is used across environments and may deploy outdated or different artifacts if builds occur between scheduled runs. Option D is wrong because a build completion trigger is used to chain build pipelines, not release pipelines; it triggers another build pipeline when a build completes, not a release deployment.

Full explanation →

432

MCQhard

Your company uses Azure DevOps for CI/CD. You have a YAML build pipeline that builds a .NET Core application and publishes artifacts. The build runs on a Microsoft-hosted agent. Recently, the build started failing with the error 'The process cannot access the file because it is being used by another process.' This occurs intermittently during the 'dotnet build' step. The pipeline uses multiple jobs that run in parallel. You suspect that one job is interfering with another because they share the same workspace on the agent. You need to ensure that each job runs in its own isolated workspace. What should you do?

A.Add a 'demands' section to the job to ensure each job runs on a different agent.

B.Set 'workspace: clean' in the pipeline root.

C.Use a 'multi-job' configuration with a matrix to run each job in separate folders.

D.Set 'clean: all' on the checkout step in each job.

AnswerD

Setting `clean: all` on the checkout step in each job is the correct fix because it deletes the entire workspace, including all files from previous jobs, before the repository is checked out. This guarantees a fresh, isolated environment for every job, preventing stale artifacts from affecting the build.

Why this answer

Setting 'clean: all' on the checkout step ensures that the workspace is cleaned before each job runs, preventing file conflicts caused by shared workspace on the agent. Option A is wrong because 'demands' are for selecting agents with specific capabilities, not for workspace isolation. Option B is wrong because 'workspace: clean' is not a valid setting at the pipeline root; workspace cleaning is configured per checkout step.

Option C is wrong because a multi-job configuration with a matrix is used for parallelizing builds across different configurations, not for isolating workspaces.

Full explanation →

433

MCQeasy

Your team uses GitHub Copilot for code suggestions. To comply with your organization's data protection policies, you need to ensure that code snippets and prompts sent to Copilot are not stored or used by Microsoft for service improvement. What should you configure?

A.Set a compliance grade in Microsoft Defender for Cloud

B.Enable the 'Data Exclusion' setting in Copilot's enterprise settings

C.Apply a Microsoft Purview Data Loss Prevention policy

D.Configure Azure OpenAI Service content filtering

AnswerB

Enabling the 'Data Exclusion' setting in Copilot's enterprise settings is the correct action because it instructs GitHub not to store or use your code snippets for service improvement purposes, aligning with your requirement to ensure code is not retained or used for model training. This setting is specifically designed to prevent Microsoft from retaining or using your code data beyond what is necessary to provide the Copilot service.

Why this answer

GitHub Copilot's enterprise settings include a 'Data Exclusion' feature that, when enabled, prevents Microsoft from storing or using your code snippets and prompts for service improvement. This directly addresses the data protection policy requirement by ensuring that your organization's code is not retained or analyzed by Microsoft beyond the immediate suggestion generation.

Exam trap

The trap here is that candidates may confuse data protection controls for Copilot with broader Microsoft security tools like Defender for Cloud or Purview DLP, which address different compliance aspects and do not directly control Copilot's data storage behavior.

How to eliminate wrong answers

Option A is wrong because Microsoft Defender for Cloud compliance grades assess the security posture of cloud resources, not the data handling policies of third-party tools like GitHub Copilot. Option C is wrong because Microsoft Purview Data Loss Prevention (DLP) policies are designed to prevent sensitive data from being shared or leaked across services like email or SharePoint, but they do not control how GitHub Copilot processes or stores code snippets. Option D is wrong because Azure OpenAI Service content filtering applies to content moderation in Azure OpenAI deployments, not to GitHub Copilot's data storage or usage policies.

Full explanation →

434

MCQhard

Refer to the exhibit. A developer queues a build with a variable 'BuildConfiguration' set to 'Release'. The pipeline definition has a default variable 'BuildConfiguration' set to 'Debug' and does not allow overrides at queue time. What will be the value of 'BuildConfiguration' during the build?

A.Debug

B.Release

C.null

D.The build fails with an error

AnswerA

Because the variable has a default value defined in the pipeline and overrides at queue time are not enabled, the build uses the configured default "Debug". The system substitutes this value before any tasks run, so the build executes as if Debug were explicitly set.

Why this answer

In Azure Pipelines, when a variable is defined in the pipeline YAML and the 'Settable at queue time' option is not enabled, the queue-time value is ignored and the pipeline definition's default value is used. Since the default is 'Debug' and overrides are not allowed, the build runs with BuildConfiguration=Debug (A). The developer's attempt to set 'Release' at queue time has no effect.

Exam trap

AZ-400 often tests variable precedence and the 'Settable at queue time' setting, tricking candidates into assuming queue-time values always override pipeline defaults.

How to eliminate wrong answers

Option B is wrong because the queue-time value 'Release' is discarded when the variable is not marked as settable at queue time — the pipeline definition value takes precedence. Option C is wrong because the variable is defined with a default of 'Debug', so it is never null. Option D is wrong because supplying a queue-time value for a non-overridable variable does not cause a build failure; Azure Pipelines silently ignores the override and proceeds with the default.

Full explanation →

435

MCQhard

Refer to the exhibit. A team wants to release version 1.0 from the main branch. They notice that the tag v1.0 is already on the current main commit. However, they also see that the origin/feature/experiment branch has commits that are not merged into main. What is the most likely scenario?

A.The team should delete the experiment branch because it is not merged.

B.The tag v1.0 was applied to the wrong commit; it should be on the merge commit of the experiment branch.

C.The main branch is missing the experiment branch commits; a merge is required before release.

D.The experiment branch contains experimental work that was not intended for release; the tag v1.0 correctly marks the release on main.

AnswerD

The experiment branch was created for isolated, exploratory work and has intentionally never been merged into main, so none of its commits are part of the v1.0 release history. Tagging the main branch's commit correctly captures the exact state of the code that was built, tested, and validated for release. This is consistent with standard branching practices where release tags are applied to integration branches, not to feature or experiment branches.

Why this answer

The tag v1.0 sits on the current main commit, and the experiment branch has unmerged commits — this is the normal, expected state when experimental work is intentionally kept out of a release. Tags mark specific commits as release points; they do not require every branch to be merged. The most likely scenario is that the experiment branch is exploratory work not destined for v1.0, so the tag correctly identifies the release commit on main.

Exam trap

AZ-400 often tests the misconception that an unmerged branch must be merged before a release can be tagged, confusing branch hygiene with release tagging — candidates wrongly assume the tag is misplaced rather than recognizing parallel experimental work.

How to eliminate wrong answers

Option A is wrong because deleting an unmerged branch is a destructive action with no technical justification — unmerged branches are routinely kept for ongoing or abandoned experiments, and deletion is a policy decision, not a diagnosis of the tag's placement. Option B is wrong because it assumes the tag must be on a merge commit of the experiment branch, but tags mark release points on whatever commit represents the release; there is no rule requiring experimental branches to be merged before tagging. Option C is wrong because it assumes the experiment branch commits belong in the release, but the scenario gives no evidence they were intended for v1.0 — merging unvetted experimental code would be the actual mistake.

Full explanation →

436

MCQmedium

Your organization uses Azure DevOps and requires that all pipelines enforce branch policy for pull requests. A developer creates a pipeline that builds and tests code on push to any branch. The security team wants to ensure that no code can be deployed to production without passing through a pull request with required reviewers. Which action should you take to meet this requirement?

A.Disable CI triggers on the pipeline and require manual builds.

B.Modify the service connection to require admin approval.

C.Set the pipeline to require approval from the security team before running.

D.Configure branch policy on the main branch to require a pull request with a minimum number of reviewers.

AnswerD

Branch policies on the main branch are the correct Azure DevOps mechanism to enforce pull request requirements, including a minimum number of reviewers; once configured, any update to the main branch must go through a PR that meets the required reviewer count, preventing unreviewed changes from being merged.

Why this answer

Azure DevOps branch policies enforce that all changes to the main branch must go through a pull request with required reviewers. This ensures no code can be deployed to production without passing through the defined review process, meeting the security team's requirement.

Exam trap

The trap here is that candidates confuse pipeline-level approvals (like pre-deployment gates) with branch policies, which are the correct mechanism to enforce pull request workflows at the source control level.

How to eliminate wrong answers

Option A is wrong because disabling CI triggers and requiring manual builds does not enforce pull request review; it only prevents automatic builds on push, leaving the deployment path unsecured. Option B is wrong because modifying the service connection to require admin approval controls access to Azure resources but does not enforce a pull request workflow or code review before deployment. Option C is wrong because setting the pipeline to require approval from the security team before running adds a manual gate but does not prevent direct pushes to the main branch or enforce a pull request with reviewers.

Full explanation →

437

MCQmedium

You are reviewing an Azure Policy definition that denies pipeline creation if the pipeline template path is not '/pipeline-templates/my-template.yml'. What does this policy do?

A.Denies pipelines that use an outdated template version.

B.Allows only pipelines that use a specific YAML template.

C.Allows only pipelines in the pipeline-templates folder.

D.Denies any pipeline that does not use a specific YAML template.

AnswerD

This is correct because the policy definition uses a deny effect that triggers when the pipeline's YAML template path does not equal the specified value. As a result, any pipeline creation or update that references a different template or a non-matching path is blocked, effectively forcing all pipelines to use that exact YAML template.

Why this answer

This Azure Policy definition uses a 'deny' effect with a condition that checks whether the pipeline references a specific YAML template. If the pipeline does not reference that template, the policy denies the pipeline creation or update. Option D is correct because the policy explicitly denies any pipeline that does not use the specified YAML template, enforcing compliance by blocking non-compliant pipelines.

Exam trap

The trap here is that candidates often confuse 'deny' with 'audit' or 'allow' effects, or misinterpret the condition as restricting folder paths instead of template references, leading them to select options that describe permissive or location-based policies.

How to eliminate wrong answers

Option A is wrong because the policy does not check template version; it checks for the presence of a specific YAML template reference, not its version. Option B is wrong because the policy uses the 'deny' effect, not 'allow' or 'audit'; it blocks non-compliant pipelines rather than allowing only those that match. Option C is wrong because the policy does not restrict pipelines to a specific folder; it evaluates the YAML template reference in the pipeline definition, not the file path location.

Full explanation →

438

MCQeasy

Your organization uses GitHub for source control. You need to enforce that all pull requests require at least one approval and that branches must be up to date with the base branch before merging. Which branch protection rule settings should you enable?

A.Require branches to be up to date only

B.Require a pull request before merging only

C.Require status checks to pass before merging only

D.Require a pull request before merging and require branches to be up to date

AnswerD

Enabling require a pull request before merging enforces the one-approval gate, while require branches to be up to date blocks merging until the head branch includes the latest base branch commits, satisfying both stated conditions in GitHub branch protection.

Why this answer

GitHub branch protection rules allow you to enforce both that pull requests require at least one approval and that branches are up to date with the base branch before merging. The 'Require a pull request before merging' setting ensures that changes cannot be pushed directly to the protected branch and must go through a PR with required approvals. The 'Require branches to be up to date' setting (under 'Require status checks to pass before merging') ensures that the branch is tested against the latest base branch code, preventing stale merges.

Exam trap

The trap here is that candidates often think 'Require status checks to pass before merging' alone covers both the approval and up-to-date requirements, but it does not enforce the pull request workflow or the branch freshness check unless those specific status checks are explicitly configured.

How to eliminate wrong answers

Option A is wrong because 'Require branches to be up to date only' does not enforce that pull requests require approval; it only ensures the branch is current, leaving the repository vulnerable to direct pushes without review. Option B is wrong because 'Require a pull request before merging only' does not enforce that the branch is up to date with the base branch, allowing merges from outdated branches that may break the build. Option C is wrong because 'Require status checks to pass before merging only' does not inherently require a pull request or an approval; it only mandates that defined status checks (e.g., CI tests) succeed, which can be bypassed by direct pushes if no PR requirement is set.

Full explanation →

439

Multi-Selectmedium

Which TWO features can you use to enforce quality gates before a production deployment in Azure Pipelines?

Select 2 answers

A.Scheduled triggers

B.Branch policies on repositories

C.Pipeline decorators

D.Approval checks on environments

E.Deployment gates evaluating health metrics

AnswersD, E

Approval checks on environments are a valid quality gate feature in Azure Pipelines. They require designated users or groups to explicitly approve a deployment before it is released to that environment, providing manual sign-off as a gate.

Why this answer

Approval checks on environments allow you to require manual sign-off before a release proceeds to a production stage. This enforces a quality gate by ensuring that a designated approver reviews and authorizes the deployment. Option E is correct because deployment gates evaluate health metrics (e.g., from Azure Monitor or Application Insights) automatically, blocking or allowing the deployment based on predefined conditions such as error rates or performance thresholds.

Exam trap

The trap here is that candidates confuse pre-deployment quality checks (like branch policies or scheduled triggers) with the specific deployment-time gates and approvals that Azure Pipelines provides for production environments.

Full explanation →

440

MCQmedium

You are implementing a secrets management strategy for a multi-cloud deployment. You need to securely store and rotate API keys for a third-party service. Which Azure service should you use?

A.Azure Key Vault

B.Microsoft Entra ID

C.Azure App Configuration

D.Azure Storage Blob

AnswerA

Azure Key Vault is a cloud service for securely storing and accessing secrets, keys, and certificates. It provides centralized secret management, fine-grained access policies, and built-in rotation capabilities, making it the appropriate choice for implementing a secrets management strategy.

Why this answer

Azure Key Vault is the correct service because it is designed specifically for securely storing and managing secrets, including API keys, with built-in support for automatic rotation via integration with Azure Event Grid and Azure Functions. It provides hardware security module (HSM)-backed encryption, access policies, and auditing, making it ideal for multi-cloud secrets management.

Exam trap

The trap here is that candidates often confuse Azure App Configuration's encrypted storage with Key Vault's secrets management, but App Configuration lacks automatic rotation and HSM-backed security, making it unsuitable for API keys.

How to eliminate wrong answers

Option B is wrong because Microsoft Entra ID (formerly Azure AD) is an identity and access management service for authentication and authorization, not a secrets store; it cannot natively store or rotate API keys. Option C is wrong because Azure App Configuration is optimized for managing application configuration settings and feature flags, not secrets; it lacks automatic rotation capabilities and HSM-backed encryption. Option D is wrong because Azure Storage Blob is an unstructured object storage service with no native secrets management features, rotation policies, or access control granularity required for API keys.

Full explanation →

441

MCQeasy

You are setting up a CI/CD pipeline for a microservices application deployed to Azure Kubernetes Service (AKS). Your team wants to automatically generate release notes from commit messages and work items. Which Azure DevOps feature should you use?

A.Copy Files task

B.Azure Repos Wiki

C.Azure Test Plans

D.Generate release notes task (from YAML pipeline)

AnswerD

The Generate release notes task in a YAML pipeline is purpose-built to automatically create a Markdown or HTML changelog from the build's associated commits, work items, and test results. It queries the build's metadata through Azure DevOps APIs and uses Handlebars or custom templates to render a formatted release-notes file, which can then be published as a pipeline artifact or copied to a target. This is the correct answer because it directly transforms source-control and work-item data into release documentation without manual authoring.

Why this answer

The Generate release notes task (from YAML pipeline) is the correct choice because it is specifically designed to automatically generate release notes from commit messages and work items in Azure Pipelines. This task parses the commit history and linked work items between two Git refs (e.g., tags or branches) and outputs a formatted markdown file, which can be published as an artifact or used in a release pipeline. It directly addresses the requirement to derive release notes from commits and work items without manual effort.

Exam trap

The trap here is that candidates may confuse the Generate release notes task with other documentation or file-copy tasks, but only this task is purpose-built to parse commit messages and work items into structured release notes within a YAML pipeline.

How to eliminate wrong answers

Option A is wrong because the Copy Files task is used to copy files from a source folder to a destination folder within the pipeline, not to generate release notes from commit messages or work items. Option B is wrong because Azure Repos Wiki is a documentation repository for project wikis, not a pipeline task that can automatically generate release notes from commits and work items. Option C is wrong because Azure Test Plans is a testing and quality management tool for manual and exploratory testing, not a feature for generating release notes from commit messages or work items.

Full explanation →

442

Multi-Selectmedium

Which TWO actions help reduce the size of a Git repository over time?

Select 2 answers

A.Use Git LFS for large binary files.

B.Squash commits before pushing to the remote.

C.Perform shallow clones when cloning the repository.

D.Regularly run 'git gc' to compress objects.

E.Use 'git filter-branch' or 'git filter-repo' to remove obsolete files from history.

AnswersA, E

Git LFS reduces repository size by replacing large binary files with lightweight text pointers in the commit graph, while the actual file content is stored on a separate LFS server. During clone or fetch, only these pointers are transferred, so the Git object database never contains the bulky binary blobs. This keeps the repository lean and prevents the historical growth that would otherwise occur with frequently updated binary assets.

Why this answer

Option A is correct because Git LFS (Large File Storage) replaces large binary files in the repository with small pointer files while storing the actual content on a separate LFS server, so the Git object database no longer accumulates massive blobs and stays small over time. Option E is correct because 'git filter-branch' or the newer 'git filter-repo' rewrites history to purge obsolete files (e.g., large blobs or secrets) from all commits, and after the rewritten history is pushed and garbage collection runs, those objects are permanently removed, shrinking the repository. Option B is not correct because squashing commits only consolidates commit metadata and does not remove the underlying file blobs, so it has negligible effect on repository size.

Option C is not correct because shallow clones ('--depth') only limit history fetched into a local clone; they do not reduce the size of the remote repository itself. Option D is not correct because 'git gc' compresses and packs existing loose objects and prunes unreachable ones, which optimizes storage but does not eliminate reachable large files or obsolete content still referenced in history.

Exam trap

The trap here is that candidates often confuse 'reducing repository size' with 'improving performance' or 'reducing clone time', leading them to select shallow clones or commit squashing as valid answers, when in fact only actions that remove or externalize file content (like LFS or history rewriting) actually shrink the repository size.

Full explanation →

443

Multi-Selecteasy

Which THREE are true about using deployment groups in Azure Pipelines? (Choose 3)

Select 3 answers

A.Each machine in a deployment group must have the Azure Pipelines agent installed.

B.Deployment groups can only be used with Windows-based machines.

C.Deployment groups allow you to deploy an application to multiple machines in a rolling fashion.

D.Deployment groups can be used in classic release pipelines.

E.Deployment groups are tied to a specific environment.

AnswersA, C, D

The Azure Pipelines agent is required on every machine in a deployment group because it is the execution engine that receives and runs tasks from the pipeline. Without the agent, the deployment group cannot communicate with Azure Pipelines or execute any deployment steps on that target machine.

Why this answer

Each target machine in a deployment group requires the Azure Pipelines agent (either the Windows or Linux agent) to be installed and configured. The agent is responsible for executing the deployment tasks on that machine, and without it, the deployment group cannot communicate with or deploy to the machine.

Exam trap

The trap here is that candidates often confuse deployment groups with environments, assuming they are the same concept, but deployment groups are a legacy feature for multi-machine deployments while environments are a newer, more flexible abstraction that supports Kubernetes, virtual machines, and other resources.

Full explanation →

444

MCQmedium

Refer to the exhibit. An Azure DevOps administrator has configured the branch policy for the main branch as shown. A developer attempts to push a commit directly to the main branch. What will happen?

A.The push triggers the build validation pipeline

B.The push is allowed because allowForcePush is false

C.The push is rejected because branch policies require a pull request

D.The push is allowed because requireLinearHistory is false

AnswerC

A branch policy requiring a pull request blocks direct pushes to main. Azure DevOps rejects the developer's push at the server, because commits must arrive through a completed pull request that satisfies the configured reviewers and build validation, rather than bypassing the policy via a local commit.

Why this answer

The branch policy for the main branch requires that all changes be submitted via a pull request. When a developer attempts to push a commit directly to main, Azure Repos enforces this policy by rejecting the push. The push is blocked at the server level before any build validation or other checks occur.

Exam trap

The trap here is that candidates assume build validation or other policies are the primary gate, when in fact the 'Require a pull request before merging' setting is the first and most restrictive policy that blocks direct pushes regardless of other policy states.

How to eliminate wrong answers

Option A is wrong because the push is rejected before any build validation pipeline can be triggered; build validation only runs on pull request creation or updates, not on rejected direct pushes. Option B is wrong because allowForcePush being false only prevents force pushes, but the standard push is still blocked by the pull request requirement. Option D is wrong because requireLinearHistory being false does not affect the push rejection; linear history is a separate policy that controls merge commit types, not the ability to push directly.

Full explanation →

445

MCQmedium

A team is designing a release pipeline for a .NET Core web application. They want to deploy to Azure App Service using a blue-green deployment strategy to minimize downtime. Which Azure App Service feature should they use to implement this?

A.Use Azure Load Balancer in front of two separate App Services.

B.Use deployment slots with swap operation.

C.Configure auto-scaling rules.

D.Use Azure Traffic Manager to route traffic between slots.

AnswerB

Deployment slots with swap operation are the correct choice because they enable blue-green deployment: the new release is deployed to a staging slot, validated, and then swapped with the production slot, making the new version live with zero downtime. App Service automatically handles slot swap by warming up the target slot and preserving production settings, and the swap operation allows instant rollback if issues arise, which is ideal for a .NET Core web app release pipeline.

Why this answer

Deployment slots in Azure App Service support swap operations that enable blue-green deployment by swapping the production slot with a staging slot. This minimizes downtime because the swap is warm-up and validation is done in the staging slot before traffic is redirected, and the swap itself is instantaneous under the hood. No external load balancer or traffic manager is needed because the swap operation handles the routing internally.

Exam trap

The trap here is that candidates may confuse Azure Traffic Manager or Load Balancer as necessary for blue-green deployments, but Azure App Service's built-in deployment slots with swap operation are the correct and simplest implementation for this specific service.

How to eliminate wrong answers

Option A is wrong because using Azure Load Balancer in front of two separate App Services adds unnecessary complexity and cost; it does not leverage the built-in slot swap mechanism that Azure App Service provides for zero-downtime deployments. Option C is wrong because auto-scaling rules handle scaling out or in based on demand, not traffic routing or deployment strategies like blue-green. Option D is wrong because Azure Traffic Manager is a DNS-based traffic routing service that operates at the DNS level and cannot perform instant slot swaps; it would introduce DNS propagation delays and is not designed for the warm-up and validation workflow of blue-green deployments.

Full explanation →

446

MCQeasy

A company uses Azure DevOps and has a security policy that all pipeline runs must use a specific service connection scoped to a resource group. A developer reports that a pipeline fails with the error: 'The service connection does not have permission to access the resource.' What is the most likely cause?

A.The Azure subscription linked to the service connection is disabled.

B.The service connection name is misspelled in the pipeline YAML.

C.The variable group in the library does not include the service connection ID.

D.The service principal used by the service connection does not have the required role assignment on the resource group.

AnswerD

The service connection's service principal lacks a role assignment (such as Contributor) scoped to the target resource group, so Azure RBAC denies access. Granting the required role on that resource group resolves the permission error.

Why this answer

The error 'The service connection does not have permission to access the resource' indicates that the service principal associated with the service connection lacks the necessary Azure RBAC role assignment on the target resource group. In Azure DevOps, a service connection authenticates via a service principal, and that principal must have a role (e.g., Contributor) explicitly assigned at the resource group scope to perform actions like deploying resources. Without this role assignment, the pipeline fails with an access-denied error.

Exam trap

The trap here is that candidates often confuse service connection authentication (which always works if the connection is valid) with authorization (RBAC role assignments), leading them to pick options about disabled subscriptions or misspelled names instead of the missing role assignment.

How to eliminate wrong answers

Option A is wrong because a disabled Azure subscription would cause a different error (e.g., 'Subscription not found' or 'Authorization failed'), not a specific permission-denied message on a resource group. Option B is wrong because a misspelled service connection name in the YAML would result in a 'Service connection not found' error, not a permission error. Option C is wrong because variable groups in the library store variables, not service connection IDs; service connections are referenced by name in the pipeline, and the ID is not required for permission checks.

Full explanation →

447

MCQeasy

You need to ensure that only authorized users can access the Azure DevOps organization. Which identity provider should you configure for single sign-on (SSO)?

A.Microsoft Entra ID

B.Google Workspace

C.Microsoft account (MSA)

D.GitHub ID

AnswerA

Microsoft Entra ID (formerly Azure AD) is the native identity provider for Azure DevOps, enabling enterprise-grade SSO, conditional access, and multi-factor authentication. It is the only supported option for centrally managing user permissions and access control across an Azure DevOps organization, making it the correct choice.

Why this answer

Microsoft Entra ID (formerly Azure AD) is the required identity provider for configuring single sign-on (SSO) for Azure DevOps organizations. Azure DevOps relies on Entra ID to authenticate users and enforce conditional access policies, ensuring only authorized identities from your tenant can sign in. This integration also supports SAML-based SSO and OAuth 2.0 flows, making it the native and only supported IdP for Azure DevOps SSO.

Exam trap

The trap here is that candidates may confuse personal Microsoft accounts (MSA) or external identity providers like Google Workspace as valid SSO options, but Azure DevOps SSO exclusively requires a Microsoft Entra ID tenant for organizational access control.

How to eliminate wrong answers

Option B (Google Workspace) is wrong because Azure DevOps does not support Google Workspace as a direct identity provider for SSO; it can only be used as an external identity source if federated through Microsoft Entra ID. Option C (Microsoft account, MSA) is wrong because MSAs are personal accounts and cannot be used for organizational SSO; Azure DevOps requires a tenant-backed identity for centralized access control and policy enforcement. Option D (GitHub ID) is wrong because GitHub IDs are used for GitHub authentication, not for Azure DevOps; while Azure DevOps and GitHub can be linked, SSO for the Azure DevOps organization itself must be configured via Microsoft Entra ID.

Full explanation →

448

MCQmedium

A team is migrating from TFVC to Git. They have a large codebase with many branches. What is the recommended approach to preserve the history during migration?

A.Copy the latest version of the code to a new Git repository and start fresh

B.Use the Git-TF tool to clone the TFVC repository

C.Use the git-tfs tool to clone the TFVC repository with changesets

D.Export TFVC as a Git bundle and import with --no-metadata

AnswerC

git-tfs is the standard community-maintained bridge that clones a TFVC repository by replaying each TFVC changeset into a corresponding Git commit, preserving the original author, timestamp, commit message, branch structure, and merge topology. It handles the TFVC-to-Git ID mapping and can also fetch shelvesets, making it the preferred tool for a full-fidelity migration. Because it reconstructs the entire commit graph rather than just copying files, it maintains the historical context needed for auditing, bisecting, and code review — which is exactly what the team needs when moving from TFVC to Git.

Why this answer

Git-tfs is a specialized bridge tool that converts TFVC changesets into Git commits, preserving the full history, author information, and branch structure during migration. Unlike Git-TF, which is deprecated and lacks support for newer TFVC features, git-tfs handles complex scenarios like merges and shelvesets, making it the recommended approach for preserving history when moving from TFVC to Git.

Exam trap

The trap here is that candidates confuse Git-TF with git-tfs, assuming both are equivalent, but Git-TF is deprecated and lacks branch support, while git-tfs is the actively maintained tool for full history preservation.

How to eliminate wrong answers

Option A is wrong because copying only the latest version discards all historical changesets, defeating the purpose of preserving history and losing audit trail and rollback capability. Option B is wrong because Git-TF (Git-TF) is a deprecated tool that does not support TFVC branches or shelvesets, and its last update was in 2015, making it unsuitable for modern TFVC repositories. Option D is wrong because TFVC does not natively support Git bundle export; the `--no-metadata` flag is irrelevant as TFVC changesets cannot be directly converted to Git bundles without a bridge tool like git-tfs.

Full explanation →

449

MCQeasy

You are designing a process for incident management. When a critical bug is reported, you need to automatically create a work item in Azure Boards and notify the on-call engineer via Microsoft Teams. Which Azure DevOps feature should you use?

A.Create a release pipeline that triggers on work item creation.

B.Set up a service hook that sends a message to Teams when a bug is created.

C.Configure a work item notification in Azure DevOps to email the on-call engineer.

D.Use a work item template to pre-populate the bug form.

AnswerB

Azure DevOps service hooks can subscribe to events such as 'work item created' and send an HTTP POST to a Teams connector or webhook. This immediately posts a message to a Teams channel when a bug is created, meeting the incident management requirement.

Why this answer

Service hooks are used to notify external systems (like Microsoft Teams) when an event occurs in Azure DevOps, such as a work item being created. They do not create the work item itself; they react to its creation. To automatically create the work item when a critical bug is reported, you would use a separate mechanism such as the Azure Boards REST API or an external integration.

Among the provided options, B is the correct feature for the Teams notification, but the explanation should clarify that the automated creation is handled outside the service hook.

Exam trap

The trap here is that candidates confuse 'work item notifications' (email-based) with 'service hooks' (webhook-based), assuming any notification feature can send to Teams, but only service hooks support direct integration with external chat systems like Teams or Slack.

How to eliminate wrong answers

Option A is wrong because a release pipeline triggers on code commits or build artifacts, not on work item creation, and is designed for deployment automation, not incident notification. Option C is wrong because work item notifications in Azure DevOps are limited to email alerts and cannot send messages to Microsoft Teams; they also require manual configuration per user and do not support dynamic on-call routing. Option D is wrong because a work item template only pre-populates fields in the bug form, it does not automate creation or notification; it is a static template, not a reactive automation mechanism.

Full explanation →

450

MCQmedium

Your team uses Azure Pipelines to build a .NET application. You notice that the build takes 15 minutes because of dependency restoration. You want to cache the NuGet packages to speed up subsequent builds. Which task should you add to your pipeline?

A.DownloadBuildArtifacts task

B.NuGet restore task with the 'noCache' option set to false

C.DotNetCoreCLI task with the 'restore' command

D.Cache task with a key based on the package lock file

AnswerD

The Cache task stores restored NuGet packages between runs, keyed on the hash of `packages.lock.json`, so a cache hit skips the 15-minute dependency restoration entirely. Keying on the lock file invalidates the cache precisely when dependencies change, satisfying the requirement to speed up subsequent builds without serving stale packages.

Why this answer

The Cache task (D) is the correct choice because it allows you to cache the NuGet packages folder (typically `~/.nuget/packages`) based on a key derived from the package lock file (e.g., `packages.lock.json`). This ensures that when the lock file hasn't changed, the cached packages are restored from the pipeline cache instead of being downloaded from the NuGet feed, significantly reducing build time. The key is computed from the lock file's content hash, so any change in dependencies automatically invalidates the cache.

Exam trap

The trap here is that candidates often confuse the NuGet local HTTP cache (controlled by the 'noCache' option) with the pipeline-level Cache task. The 'noCache' option only disables the HTTP cache on the local agent, but that cache persists across builds on that agent. It does not provide a distributed cache across different agents.

The pipeline Cache task caches files in Azure DevOps and restores them on any agent, which is why it's the correct approach for speeding up builds across runs.

How to eliminate wrong answers

Option A is wrong because the DownloadBuildArtifacts task is used to download build artifacts from a previous pipeline run, not to cache NuGet packages for dependency restoration. Option B is wrong because the NuGet restore task's 'noCache' option controls whether NuGet uses its local HTTP cache, not the pipeline-level cache; setting it to false does not introduce pipeline caching. Option C is wrong because the DotNetCoreCLI task with the 'restore' command performs a standard restore without any built-in caching mechanism; it would still download packages from the feed each time unless combined with a separate Cache task.

Full explanation →

Microsoft Azure DevOps Engineer Expert AZ-400 (AZ-400) — Questions 376–450