Microsoft Azure DevOps Engineer Expert AZ-400 AZ-400 Questions 526–600 | Page 8/10

526

MCQhard

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

A.The reference function cannot be used in a properties object.

B.The reference function syntax is incorrect.

C.The Application Insights component is not defined as a resource in the template.

D.The apiVersion for the config resource is outdated.

AnswerC

The deployment fails because ARM cannot resolve a reference to a resource absent from the template. Application Insights requires an explicit `Microsoft.Insights/components` resource declaration; without it, the App Service's instrumentation settings reference a non-existent resource, satisfying the stem's "not defined in the template" constraint.

Why this answer

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

Exam trap

The trap here is that candidates often confuse a missing resource definition with a syntax error in the `reference()` function or an API version issue, but the error message explicitly says 'not defined', which points directly to the resource not being declared in the template's `resources` section.

How to eliminate wrong answers

Option A is wrong because the `reference()` function can be used in a `properties` object to retrieve runtime values from other resources, as long as those resources are defined in the template. Option B is wrong because the error message specifically states the resource is 'not defined', not that the syntax of `reference()` is incorrect; a syntax error would produce a different parsing error. Option D is wrong because an outdated `apiVersion` would cause a different error (e.g., 'The apiVersion parameter ... is not supported'), not a 'not defined' error for the resource itself.

Full explanation →

527

MCQhard

A development team is using Git for source control. They have a main branch that should always be deployable. Developers work on feature branches and create pull requests to merge into main. Recently, a feature branch with incomplete work was accidentally merged into main, causing build failures. What is the best Git branch strategy to prevent this in the future while maintaining fast feedback?

A.Require at least one code reviewer approval for all pull requests into main.

B.Configure branch protection on main to require status checks (CI build and tests) to pass before merging.

C.Adopt a GitFlow-like branching model with a separate release branch for stable code.

D.Disable direct pushes to main and enforce all merges through pull requests.

E.Require a linear history on main by enabling 'Rebase and merge' for all pull requests.

AnswerB

Branch protection blocks merges to main until required status checks — the CI build and tests — pass, so incomplete feature work cannot land and break the deployable main. This directly prevents the accidental merge while keeping fast feedback through pull requests.

Why this answer

Configuring branch protection on main to require status checks (CI build and tests) to pass before merging directly prevents incomplete or broken code from being merged. This enforces that every pull request must pass automated validation, ensuring main remains deployable while still allowing fast feedback through the CI pipeline.

Exam trap

The trap here is that candidates often confuse process controls (like requiring pull requests or code reviews) with automated quality gates (like status checks), mistakenly believing that human review alone is sufficient to catch all integration issues.

How to eliminate wrong answers

Option A is wrong because requiring code reviewer approval alone does not prevent incomplete or broken code from being merged; reviewers may miss issues or approve without running builds. Option C is wrong because adopting GitFlow with a separate release branch adds complexity and delays feedback, contradicting the need for fast feedback and not directly preventing accidental merges of incomplete work. Option D is wrong because disabling direct pushes and enforcing merges through pull requests is a prerequisite but does not enforce that the code is complete or passes validation; it only controls the merge mechanism.

Option E is wrong because requiring a linear history via 'Rebase and merge' only affects commit history structure, not the quality or completeness of the code being merged.

Full explanation →

528

Multi-Selectmedium

Which TWO actions should you take to implement a secure build pipeline that uses Azure Key Vault to store secrets? (Choose two.)

Select 2 answers

A.Store the Key Vault name and secret names in a secure file in the repository.

B.Define secrets as pipeline variables and mark them as secret.

C.Grant the Azure DevOps service principal 'Get' and 'List' permissions on the Key Vault.

D.Use the 'Azure CLI' task to run 'az keyvault secret show' for each secret.

E.Use the 'Azure Key Vault' task to download secrets as pipeline variables.

AnswersC, E

Granting the Azure DevOps service principal 'Get' and 'List' permissions on the Key Vault is a mandatory prerequisite for the pipeline to retrieve secret names and values; without these permissions, the Azure Key Vault task fails, so you must configure an access policy or RBAC role assignment for the service principal.

Why this answer

The Azure DevOps service principal (the identity used by Azure Pipelines) must be granted 'Get' and 'List' permissions on the Key Vault's access policy. This allows the pipeline to retrieve secret values securely without storing credentials in the repository or pipeline configuration. Without these permissions, any attempt to read secrets from the vault will fail with an authorization error.

Exam trap

The trap here is that candidates often think storing secrets as pipeline variables (Option B) is sufficient, but the question specifically requires using Azure Key Vault, so the correct approach is to retrieve secrets from Key Vault at runtime using the dedicated task, not to hardcode them as pipeline variables.

Full explanation →

529

MCQmedium

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

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

B.The variable 'resourceGroupName' uses $(environment) which cannot reference a parameter.

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

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

AnswerB

The macro syntax `$(environment)` in a variable resolves to a runtime variable named 'environment', not to a pipeline parameter. Parameters are expanded at compile time via `${{ parameters.environment }}`, so this use would produce a null/empty value and cause the resource group name to be incorrect or undefined.

Why this answer

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

Exam trap

The trap here is that candidates confuse the syntax for referencing parameters (`${{ }}`) with the syntax for referencing variables (`$()`), assuming both are interchangeable in YAML pipelines.

How to eliminate wrong answers

Option A is wrong because the script type 'pscore' (PowerShell Core) is fully supported on Ubuntu agents in Azure Pipelines; it runs pwsh, which is cross-platform. Option C is wrong because parameters are fully supported in YAML pipelines directly, not only in templates; they can be defined at the pipeline level using the `parameters:` keyword. Option D is wrong because `trigger: none` only disables CI triggers, but the pipeline can still be run manually or via other triggers; it does not cause a failure due to unresolved variables.

Full explanation →

530

MCQeasy

You need to run a set of tasks only when the build pipeline runs for the main branch. Which condition should you add to the job or step?

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

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

C.condition: and(succeeded(), eq(variables['System.PullRequest.TargetBranch'], 'main'))

D.condition: ne(variables['Build.Reason'], 'PullRequest')

AnswerA

This condition is correct because the Build.SourceBranch variable returns the full ref path, such as 'refs/heads/main', so the equality check accurately triggers only when the build originates from the main branch, ignoring other branches or tags.

Why this answer

The `Build.SourceBranch` variable in Azure Pipelines contains the full Git ref (e.g., `refs/heads/main`). Using `eq(variables['Build.SourceBranch'], 'refs/heads/main')` ensures the condition evaluates to true only when the pipeline runs on the main branch. This is the standard way to filter by branch in YAML pipeline conditions.

Exam trap

The trap here is that candidates often assume `Build.SourceBranch` contains only the short branch name (like `main`) rather than the full Git ref path (`refs/heads/main`), leading them to choose Option B.

Why the other options are wrong

Missing 'refs/heads/' prefix, so it won't match.

This checks PR target branch, not the source branch.

This excludes PRs but does not limit to main branch.

Full explanation →

531

MCQhard

Your YAML pipeline uses the 'AzureResourceManagerTemplateDeployment' task to deploy ARM templates. You need to handle incremental deployments and ensure that the task fails if any resource already exists and cannot be updated. Which deployment mode should you specify?

A.Incremental

B.Complete

C.Validate

D.CreateOrUpdate

AnswerA

Incremental mode is the default ARM deployment mode that only adds, updates, or deletes resources that are specified in the template, leaving all other resources in the resource group untouched. This allows users to perform partial updates by modifying only the relevant resources without affecting the entire resource group's existing configuration.

Why this answer

The 'Incremental' deployment mode in the AzureResourceManagerTemplateDeployment task handles only changes specified in the template, leaving existing resources unchanged. If a resource already exists and cannot be updated (e.g., due to a property conflict or immutable resource), the deployment fails, meeting the requirement to fail on such conflicts. This mode is the standard for additive, non-destructive ARM template deployments.

Exam trap

The trap here is that candidates confuse 'Incremental' with 'Complete' mode, mistakenly thinking 'Complete' is safer for incremental updates, when in fact 'Complete' can delete resources not in the template, leading to data loss.

Why the other options are wrong

Complete mode deletes resources not in the template; it does not fail on existing resources that cannot be updated.

Validate mode only validates the template without actually deploying resources.

There is no deployment mode named 'CreateOrUpdate'; it is a behavior of Incremental mode.

Full explanation →

532

MCQeasy

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

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

B.Define secrets as environment variables directly in the workflow YAML.

C.Store secrets in GitHub repository secrets and reference them in workflows using ${{ secrets.SECRET_NAME }}. GitHub automatically masks secrets in logs.

D.After the workflow runs, delete the logs from GitHub.

AnswerC

This is the recommended approach because GitHub encrypts secrets at rest, restricts access to authorized users/actions, and automatically detects the exact secret value used in the workflow to redact it from all log output. Referencing secrets via ${{ secrets.SECRET_NAME }} keeps the actual value out of the YAML source and ensures that any accidental printing of that value is masked in real time.

Why this answer

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

Exam trap

The trap here is that candidates may think manual masking or log deletion is necessary, overlooking GitHub's built-in automatic secret masking that works seamlessly when secrets are properly referenced via the ${{ secrets.SECRET_NAME }} syntax.

How to eliminate wrong answers

Option A is wrong because using a custom action to manually mask secrets is error-prone and unnecessary; GitHub already provides automatic masking for secrets referenced in the standard way. Option B is wrong because defining secrets as environment variables directly in the workflow YAML file would expose the secret values in plain text within the repository, defeating the purpose of secure storage. Option D is wrong because deleting logs after a run does not prevent exposure during the run or before deletion, and it also removes valuable debugging information; the correct approach is to prevent exposure proactively.

Full explanation →

533

Multi-Selectmedium

Your release pipeline deploys to multiple environments sequentially: Dev, QA, Staging, Production. You need to implement manual approval gates before Staging and Production deployments. Which TWO configurations should you use? (Choose two.)

Select 2 answers

A.Add a post-deployment approval gate to the Dev and QA stages.

B.Use the 'Approvals and gates' settings in the release pipeline stage.

C.Configure branch policy on the release branch to require approvals.

D.Add a 'Manual Validation' task in the YAML pipeline.

E.Add a pre-deployment approval gate to the Staging and Production stages.

AnswersB, E

In classic release pipelines, the 'Approvals and gates' settings are configured per stage and allow you to add pre-deployment and post-deployment approvals, as well as gates such as query-based checks or Azure Monitor alerts. Pre-deployment approvals are the built-in mechanism to pause the pipeline before a stage runs, ensuring authorized reviewers approve the release before it reaches environments like Staging and Production.

Why this answer

The 'Approvals and gates' settings in a release pipeline stage allow you to configure pre-deployment approvals, which require designated users to approve the deployment before it proceeds. This is the standard mechanism in Azure DevOps for implementing manual approval gates. Option E is correct because adding a pre-deployment approval gate specifically to the Staging and Production stages ensures that deployments to these environments are blocked until the required approvals are granted, meeting the requirement for manual approval before Staging and Production.

Exam trap

The trap here is that candidates often confuse post-deployment approvals (which happen after deployment) with pre-deployment approvals (which gate the deployment), or they incorrectly think branch policies or manual validation tasks are the correct way to add manual approval gates in a release pipeline.

Full explanation →

534

Multi-Selecteasy

Which TWO actions help improve communication and collaboration in a distributed Azure DevOps team?

Select 2 answers

A.Maintain a shared wiki with project documentation and decisions.

B.Use multiple chat channels for each topic to organize discussions.

C.Use long email threads for decision-making to ensure full documentation.

D.Schedule daily stand-up meetings at a time that works for all time zones.

E.Avoid using pull request comments to reduce noise.

AnswersA, D

Maintaining a shared wiki centralizes project documentation and decisions in a single source of truth, with versioning and searchability that reduce redundant questions and ensure all team members, regardless of location or role, can access consistent, up-to-date information.

Why this answer

A shared wiki (e.g., Azure DevOps Wiki) provides a single source of truth for project documentation and decisions, accessible asynchronously—critical for distributed teams. Additionally, scheduling daily stand-up meetings at a time that works for all time zones ensures regular synchronous alignment and promotes collaboration. Multiple chat channels can fragment discussions, long email threads are hard to follow, and avoiding PR comments removes a key asynchronous review/discussion mechanism.

Exam trap

The trap here is that candidates may think multiple chat channels improve organization, but Azure DevOps emphasizes asynchronous, traceable communication via work items, pull requests, and wikis rather than real-time chat fragmentation.

Full explanation →

535

MCQeasy

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

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

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

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

D.Use template parameters with a 'steps' object that can be injected to override the step.

AnswerD

This is the supported pattern: declare a template parameter of type 'steps' and pass it through to the steps section of a job or stage. For example, define `parameters: - name: stepsOverride type: steps default: []` and then use `steps: ${{ parameters.stepsOverride }}` in the template; the caller can supply a list of steps as an argument to replace the default behavior. Because the parameter is a full steps object, the calling pipeline can inject any arbitrary step definitions without modifying the template file itself. This approach keeps the template reusable while allowing per-pipeline overrides.

Why this answer

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

Exam trap

The trap here is that candidates may confuse the fictional 'overrides' keyword (Option A) with a real feature, or incorrectly assume that conditional logic in the template (Option C) is the only way to control step execution, when in fact Azure DevOps provides a dedicated parameter injection pattern for step replacement using a steps object parameter.

How to eliminate wrong answers

Option A is wrong because Azure DevOps YAML does not support an `overrides` keyword; this is a fictional construct. Option B is wrong because creating a copy of the template defeats the purpose of reuse and introduces maintenance overhead, which is not the intended solution for overriding steps without modifying the template. Option C is wrong because using a conditional `if` statement in the template requires modifying the template itself, which violates the requirement to avoid modifying the template.

Full explanation →

536

Matchingmedium

Match each Azure Test Plans concept to its definition.

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

Concepts

Matches

Container for test suites and configurations

Group of test cases

Individual test with steps and expected results

Execution of a set of test cases

Why these pairings

In Azure Test Plans, a Test Plan is a container for test suites and test cases with settings. A Test Suite groups test cases. A Test Case has steps and expected results.

A Test Run is an execution of test cases. A Test Point is a test case with a specific configuration.

Full explanation →

537

MCQhard

Your organization uses GitHub Actions for CI/CD. You need to ensure that secrets stored in GitHub are not exposed in build logs. A developer accidentally printed a secret to the console in a workflow step. What built-in feature of GitHub Actions automatically prevents this?

A.Audit log monitoring

B.Secret scanning alerts

C.Required reviewers on workflows

D.Automatic log redaction

AnswerD

Automatic log redaction is the correct answer because GitHub Actions detects values of configured secrets in a job's output and replaces them with '***' in real time across all workflow run logs, effectively preventing secrets from appearing.

Why this answer

GitHub Actions includes a built-in feature that automatically redacts secrets from workflow run logs. When a secret is printed to the console, GitHub detects the secret value and replaces it with '***' in the log output, preventing accidental exposure. This redaction happens at the log rendering layer, not in the workflow execution, so the secret is never visible to users viewing the logs.

Exam trap

The trap here is that candidates often confuse secret scanning (which detects secrets in source code) with log redaction (which prevents secrets from appearing in CI/CD output), leading them to choose Option B instead of D.

How to eliminate wrong answers

Option A is wrong because audit log monitoring records administrative actions and events in the organization, but it does not prevent secrets from appearing in build logs—it only provides a historical record after the fact. Option B is wrong because secret scanning alerts detect secrets committed to repositories (e.g., in code or configuration files), not secrets printed during workflow execution in logs. Option C is wrong because required reviewers on workflows enforce approval for pull request workflows, but they do not inspect or redact log output for secrets.

Full explanation →

538

MCQmedium

Your team uses Azure Pipelines for CI/CD. You need to enforce that all builds produce a signed artifact. Which approach should you use?

A.Add a YAML template that includes the signing task and require all pipelines to extend it.

B.Set a branch policy requiring a signed build status.

C.Configure a manual approval gate on the build pipeline.

D.Use a Pipeline decorator to inject the signing task into every build pipeline.

AnswerD

Pipeline decorators are extension-based components that automatically inject a set of tasks into every pipeline (or a filtered subset) at either the start or end of a job, at the organization level. Because the decorator runs outside the individual pipeline definition, it cannot be bypassed by pipeline authors and does not require changes to existing YAML or classic builds. This provides the required guarantee that the signing task is applied to every build pipeline.

Why this answer

Pipeline decorators allow injecting tasks (like signing) into every pipeline globally without modifying individual pipeline definitions. Option A is wrong because YAML templates require each pipeline to explicitly extend them; they do not enforce automatic inclusion. Option B is wrong because branch policies control pull request merge conditions, not build steps.

Option C is wrong because manual approval gates are used in release pipelines to control promotion, not to enforce signing during build.

Full explanation →

539

MCQeasy

Your team uses GitHub Flow and wants to ensure that every pull request is reviewed by at least one team member. Which branch protection rule should you enable?

A.Require a pull request before merging and set required number of reviewers to 1

B.Require signed commits

C.Require status checks to pass before merging

D.Require conversation resolution before merging

AnswerA

Requiring a pull request before merging and setting the required number of reviewers to 1 ensures every change is proposed via a PR and must receive at least one human approval before merge. This directly enforces the code review requirement by blocking merges until a reviewer explicitly approves the pull request.

Why this answer

GitHub Flow relies on pull requests for collaboration, and the 'Require a pull request before merging' rule with a required number of reviewers set to 1 enforces that every PR must be reviewed by at least one team member before it can be merged. This directly satisfies the requirement of ensuring code review for all changes.

Exam trap

The trap here is that candidates may confuse 'requiring status checks' (automated validation) with 'requiring pull request reviews' (human validation), leading them to select option C instead of A.

How to eliminate wrong answers

Option B is wrong because requiring signed commits ensures commit authenticity and integrity via GPG or S/MIME signatures, but it does not enforce any review process. Option C is wrong because requiring status checks to pass before merging ensures that CI/CD checks (e.g., tests, builds) succeed, but it does not mandate human review. Option D is wrong because requiring conversation resolution before merging ensures that all comments on a PR are marked as resolved, but it does not guarantee that a specific number of reviewers have approved the changes.

Full explanation →

540

MCQeasy

You are designing a build pipeline for a Node.js application. The team wants to ensure that the pipeline runs unit tests and publishes test results to Azure DevOps. Which task should you add to the pipeline?

A.Publish Test Results task

B.Copy Files task

C.npm test

D.Publish Build Artifacts task

AnswerA

The Publish Test Results task is correct because it explicitly consumes test result files (e.g., JUnit, NUnit, VSTest) and uploads them to Azure Pipelines, enabling test analytics, failure reporting, and trend dashboards in the build summary.

Why this answer

The Publish Test Results task (A) is correct because it specifically ingests test result files (e.g., JUnit, NUnit, xUnit, or TRX formats) and publishes them to Azure DevOps, enabling test analytics, trend charts, and pass/fail reporting in the pipeline summary. For a Node.js application, after running unit tests with a framework like Jest or Mocha, the test results are typically output as JUnit XML files, and this task is required to make those results visible in the DevOps portal.

Exam trap

The trap here is that candidates confuse running tests (npm test) with publishing test results, not realizing that Azure DevOps requires a separate task to ingest and display test outcomes in the pipeline UI.

How to eliminate wrong answers

Option B (Copy Files task) is wrong because it only copies files from source to a destination folder; it does not parse or publish test results. Option C (npm test) is wrong because it is a script step that runs the test command defined in package.json, but it does not publish test results to Azure DevOps—it only executes the tests locally in the pipeline. Option D (Publish Build Artifacts task) is wrong because it publishes build outputs (e.g., compiled code, binaries) as artifacts for deployment, not test result files for reporting.

Full explanation →

541

MCQhard

Refer to the exhibit. A developer queues a build manually but notices the build status remains 'notStarted' for an extended period. The pipeline has no demands and priority is normal. Which is the most likely cause?

A.The variable 'BuildConfiguration' is misspelled.

B.The branch 'main' does not exist.

C.All agents in the pool are currently busy.

D.The pipeline definition ID is incorrect.

AnswerC

When a build is queued without explicit agent demands, Azure Pipelines can run it on any agent in the specified pool. If all agents in that pool are currently executing other jobs, the build will remain in a queued state until an agent becomes available—this is a common cause of a build appearing stuck. The queue shows the build as 'Queued' or 'Waiting for agent' without raising an immediate error, which matches the exhibit behavior.

Why this answer

When a build remains in 'notStarted' status for an extended period, it typically means the pipeline is waiting for an available agent. Since the pipeline has no demands and priority is normal, the most likely cause is that all agents in the specified agent pool are currently busy executing other jobs, so the build is queued until an agent becomes free.

Exam trap

The trap here is that candidates often assume a 'notStarted' status is caused by a configuration error (like a missing branch or misspelled variable) rather than recognizing it as a classic symptom of agent pool exhaustion or queue saturation.

How to eliminate wrong answers

Option A is wrong because a misspelled variable like 'BuildConfiguration' would cause a build-time error or unexpected behavior during the build process, not prevent the build from starting; the build would still be assigned to an agent and run. Option B is wrong because if the branch 'main' does not exist, the build would fail at the source fetch step or trigger a 'not found' error, but the build would still be assigned to an agent and attempt to run, not remain 'notStarted'. Option D is wrong because the pipeline definition ID is used internally by Azure DevOps to identify the pipeline; an incorrect ID would prevent the build from being queued at all, resulting in an error when triggering the build, not a 'notStarted' status.

Full explanation →

542

MCQmedium

Your team is designing a build pipeline for a Java application that uses Maven. The pipeline must run unit tests and integration tests separately, and fail the build if integration tests fail. However, integration tests require a running database container. Which approach should you use to ensure the database is available for the integration tests?

A.Use a Docker Compose task in the pipeline to start the database container before running integration tests.

B.Configure the pipeline to use a self-hosted agent that has the database already installed and running.

C.Install the database as a service in the pipeline using the Service Fabric task.

D.Use a PowerShell script in the pipeline to install and start the database on the build agent.

AnswerA

A Docker Compose task starts the database container as a service before the integration test step runs, so the dependency is available when tests execute. This satisfies the requirement that integration tests need a running database, and the task fails the pipeline if the container cannot start.

Why this answer

Docker Compose allows you to define and start a database container as a dependency before running integration tests in a build pipeline. By using a Docker Compose task, you can ensure the database container is running in a clean, isolated environment, and the pipeline can fail the build if the integration tests fail. This approach is ideal for CI/CD pipelines where ephemeral, disposable infrastructure is needed for testing.

Exam trap

The trap here is that candidates may confuse the Docker Compose task with other Azure DevOps tasks like Service Fabric or generic scripting, failing to recognize that Docker Compose is the standard, built-in method for managing container dependencies in a pipeline.

How to eliminate wrong answers

Option B is wrong because using a self-hosted agent with a pre-installed database introduces statefulness and environment drift, making builds non-reproducible and harder to maintain across agents. Option C is wrong because the Service Fabric task is designed for deploying and managing microservices on Azure Service Fabric, not for starting a database container as a service in a build pipeline. Option D is wrong because using a PowerShell script to install and start a database on the build agent is error-prone, slow, and pollutes the agent's environment, whereas Docker Compose provides a cleaner, containerized solution.

Full explanation →

543

MCQmedium

Your organization uses GitHub for source control and Azure Pipelines for CI/CD. You need to implement a policy that requires all pull requests to pass a status check before merging. The status check should be provided by a pipeline that runs when a pull request is created. Which type of trigger should you configure in the pipeline YAML?

A.Push trigger

B.Manual trigger

C.PR trigger

D.Scheduled trigger

AnswerC

A PR trigger in Azure Pipelines automatically starts a pipeline whenever a pull request is created or gets new commits, enabling validation of code changes before merging. This is the correct trigger type for validating pull requests, as it directly responds to PR events.

Why this answer

A PR trigger (pr:) in Azure Pipelines YAML automatically runs the pipeline when a pull request is created or updated against a specified branch. This allows the pipeline to produce a status check that GitHub enforces as a required check before merging, fulfilling the policy requirement.

Exam trap

The trap here is that candidates often confuse push triggers with PR triggers, thinking a push to the target branch will suffice, but the status check must be tied to the PR's merge commit or head branch, which only a PR trigger can automate.

How to eliminate wrong answers

Option A is wrong because a push trigger runs the pipeline on commits to a branch, not on pull request creation, so it cannot provide a status check tied to the PR lifecycle. Option B is wrong because a manual trigger requires a user to explicitly start the pipeline, which is not automated and cannot enforce a required status check without human intervention. Option D is wrong because a scheduled trigger runs the pipeline at specified times (e.g., nightly), independent of pull request events, so it cannot provide a real-time status check for PRs.

Full explanation →

544

Multi-Selecteasy

Which TWO are best practices when configuring alerts in Azure Monitor for a production application?

Select 2 answers

A.Use metric alerts only for simple threshold-based conditions.

B.Use dynamic thresholds for metrics with seasonal patterns.

C.Create separate alert rules for each condition to avoid complexity.

D.Configure action groups to send notifications and run automated actions.

E.Ensure each alert rule uses a unique action group to isolate notifications.

AnswersB, D

Dynamic thresholds employ machine learning to model historical metric behavior, continuously adjusting the baseline to account for seasonal patterns such as time-of-day, weekly, or yearly fluctuations. This adaptive behavior minimizes false positives during predictable peaks and troughs, while still detecting genuine deviations that deviate from the learned pattern. For metrics with recurring seasonality, dynamic thresholds are the recommended approach because they automatically recalibrate as the baseline shifts, unlike static thresholds that require manual updates.

Why this answer

Dynamic thresholds in Azure Monitor use machine learning to automatically detect and adjust alert thresholds based on historical patterns, making them ideal for metrics with seasonal or cyclical behavior (e.g., CPU usage that spikes during business hours). This reduces alert noise and manual tuning effort compared to static thresholds.

Exam trap

The trap here is that candidates often assume metric alerts are only for simple thresholds (Option A) and overlook that dynamic thresholds are purpose-built for seasonal patterns, while also mistakenly thinking unique action groups per rule (Option E) improve isolation rather than creating unnecessary complexity.

Full explanation →

545

MCQhard

You have a multi-stage YAML pipeline in Azure DevOps that deploys to multiple environments. The pipeline uses a deployment job with environment approvals. You need to ensure that the deployment to the production environment is only triggered after a manual approval is granted. However, you also want the deployment to automatically roll back if the post-deployment health check fails. Which configuration should you implement?

A.Use a release pipeline with a pre-deployment approval and a post-deployment automatic rollback trigger.

B.Configure pre-deployment approvals on the production environment and use a post-deployment gate that fails the deployment.

C.Configure pre-deployment approvals and add a manual intervention task to roll back if health check fails.

D.Enable 'Auto-revert' on the production environment and set post-deployment conditions.

AnswerD

Auto-revert is a native environment setting that, when enabled, automatically redeploys the previously successful version (the last known good deployment) whenever post-deployment conditions, such as health-check gates, mark the current deployment as failed. This provides the automatic rollback behavior required without human intervention or a classic release pipeline, and it is fully integrated with YAML multi-stage pipelines. Setting post-deployment conditions ensures that the health check is evaluated before the revert trigger fires.

Why this answer

Azure DevOps environments support an 'Auto-revert' setting that automatically triggers a rollback to the previous successful deployment when a post-deployment health check (defined via post-deployment conditions) fails. This combines manual approval (pre-deployment approvals on the environment) with automatic rollback, meeting both requirements without additional tasks or release pipelines.

Exam trap

The trap here is that candidates confuse 'Auto-revert' with classic release pipeline features or assume manual intervention tasks are needed for rollback, overlooking the environment-level automatic rollback capability in YAML pipelines.

How to eliminate wrong answers

Option A is wrong because it suggests using a release pipeline with pre-deployment approvals and a post-deployment automatic rollback trigger, but the question specifies a multi-stage YAML pipeline, not a classic release pipeline; the 'Auto-revert' feature is environment-specific and not a release pipeline trigger. Option B is wrong because configuring a post-deployment gate that fails the deployment does not automatically roll back; it only marks the deployment as failed, requiring manual intervention to revert. Option C is wrong because adding a manual intervention task to roll back contradicts the requirement for automatic rollback; manual intervention tasks require human action, not automation.

Full explanation →

546

MCQmedium

Your team uses GitHub for source control and wants to enforce that all pull requests into the main branch require at least two reviewers and must pass a status check from a CI pipeline. Which branch protection rule configurations should you apply?

A.Require a minimum of 2 reviewers, require status checks to pass before merging

B.Require signed commits and status checks

C.Require status checks to pass, but do not require reviewers

D.Require a minimum of 2 reviewers, but do not require status checks

AnswerA

This branch protection configuration enforces both mandatory peer review and automated quality gates: at least two reviewers must approve the pull request, and all required status checks (e.g., CI build and test jobs) must pass before merging. This is the correct combination to meet the stated requirements.

Why this answer

GitHub branch protection rules allow you to require a minimum number of reviewers before merging and to require status checks to pass. By setting 'Require a minimum number of reviewers' to 2 and enabling 'Require status checks to pass before merging', you enforce that every pull request into the main branch must be approved by at least two reviewers and must pass the CI pipeline status check, meeting the stated requirements.

Exam trap

The trap here is that candidates may think requiring signed commits or only status checks is sufficient, but the question explicitly demands both two reviewers and a CI status check, which only option A satisfies.

How to eliminate wrong answers

Option B is wrong because requiring signed commits ensures commit authenticity but does not enforce the required two reviewers or the CI status check. Option C is wrong because it omits the requirement for at least two reviewers, which is explicitly needed. Option D is wrong because it omits the requirement for status checks to pass, leaving the CI pipeline result unenforced.

Full explanation →

547

Multi-Selectmedium

You manage a release pipeline for a Java application that is deployed to Azure App Service. The pipeline currently uses manual approval gates. You need to implement automated quality gates to reduce manual intervention. Which THREE conditions can you use in the 'Post-deployment approvals' settings of a release pipeline? (Choose three.)

Select 3 answers

A.Azure Policy

B.Manual approval

C.Invoke Azure Functions

D.REST API

E.Query Azure Monitor alerts

AnswersC, D, E

Invoke Azure Functions is a native release gate that executes an Azure Function with the release context, using the function's response (e.g., success/failure, custom payload) to determine if the deployment should proceed. This enables robust, custom quality logic to be hosted serverlessly and automatically evaluated.

Why this answer

'Invoke Azure Functions' is a valid gate type in Azure DevOps release pipelines. It allows you to call an Azure Function as a quality gate, enabling custom automated checks (e.g., validating deployment health or running custom logic) without manual intervention. This directly supports the goal of reducing manual approvals by automating post-deployment validation.

Exam trap

The trap here is that candidates may confuse Azure Policy (a governance tool) with a pipeline gate, or think that manual approval can be automated, when in fact the question explicitly asks for automated quality gates that reduce manual intervention.

Full explanation →

548

Multi-Selectmedium

Which THREE measures should be implemented to protect secrets in Azure Pipelines? (Choose three.)

Select 3 answers

A.Restrict which pipelines can access the variable group

B.Log secret values to pipeline console for debugging

C.Use variable groups with locked variables

D.Link Azure Key Vault as a variable group

E.Store secrets in code as environment variables

AnswersA, C, D

Scoping access reduces exposure.

Why this answer

Restricting which pipelines can access a variable group ensures that only authorized pipelines can use secrets stored in that group, preventing unauthorized access or accidental exposure. This is a key security measure in Azure Pipelines to enforce the principle of least privilege.

Exam trap

The trap here is that candidates may think logging secrets is acceptable for debugging or that storing secrets in environment variables is safe, but both practices directly contradict Azure security best practices and can lead to credential leakage.

Full explanation →

549

MCQeasy

Your team wants to automatically assign a code reviewer from a specific security group when a pull request modifies files in a 'security' folder. Which Azure DevOps feature should you use?

A.Add a required reviewer policy for the branch.

B.Enable 'Automatically approve' for security group.

C.Code ownership policy with automatic reviewer assignment.

D.Branch policy with minimum number of reviewers.

AnswerA

A required reviewer policy on a branch mandates that at least one specified reviewer must approve every pull request targeting that branch, but it does not automatically assign a specific person based on the code changes; it simply enforces a generic approval requirement and cannot dynamically select a reviewer based on file paths or expertise.

Why this answer

Azure DevOps branch policies include a 'Required reviewers' policy that can be configured with a path filter. By specifying the path 'security' and adding the security group as required reviewers, the system will automatically add those reviewers to any pull request that modifies files in that folder. This is the built-in feature designed for this scenario.

A CODEOWNERS file can also suggest reviewers based on file paths, but it is not a branch policy and does not enforce that the review must occur.

Exam trap

Candidates may confuse CODEOWNERS with branch policies. The correct approach is to use a branch policy with required reviewers and a path filter, not the CODEOWNERS file alone.

How to eliminate wrong answers

Option A is wrong because a 'required reviewer policy' for a branch is a generic branch policy that mandates a specific reviewer for all pull requests targeting that branch, but it does not allow file-path-based conditional assignment like the security folder scenario requires. Option B is wrong because 'Automatically approve' is not a built-in Azure DevOps feature; it would bypass the review process entirely, which contradicts the goal of assigning a reviewer for security oversight. Option D is wrong because a branch policy with a minimum number of reviewers only enforces a count of reviewers, not the specific assignment of a reviewer from a particular security group based on file changes.

Full explanation →

550

MCQhard

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

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

B.Create a GitHub Actions workflow that triggers on push to main, attempts to merge main into develop, and if conflicts occur, opens a pull request for manual resolution.

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

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

AnswerB

This workflow triggers on every push to main, uses a script or git commands to merge main into develop, and if conflicts arise, it creates a pull request for manual conflict resolution, providing timely automation while preserving human oversight for conflicting changes.

Why this answer

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

Exam trap

The trap here is that candidates may choose a scheduled workflow (Option C) thinking it is sufficient, but it fails to handle merges that occur between scheduled runs and does not gracefully manage merge conflicts by opening a pull request.

How to eliminate wrong answers

Option A is wrong because a branch protection rule on main requiring a pull request to merge into develop does not automate the merge process; it only enforces a policy, leaving the team to remember to perform the merge. Option C is wrong because a scheduled daily workflow may miss merges that occur between runs, and it does not handle conflicts gracefully by opening a pull request—it only merges if there are no conflicts, which could silently skip merges. Option D is wrong because setting up a webhook to call an Azure Function introduces unnecessary complexity and external dependencies, and it does not natively handle merge conflicts by opening a pull request within GitHub.

Full explanation →

551

Multi-Selectmedium

Which TWO practices should you adopt to improve the security of your Azure DevOps pipeline? (Choose two.)

Select 2 answers

A.Grant the least privilege to service connections

B.Use Azure Key Vault to store secrets and fetch them at runtime

C.Use the default hosted agent for all builds

D.Store secrets as plain text in pipeline variables

E.Allow contributors to bypass the required reviewer policy

AnswersA, B

Granting least privilege to service connections means configuring each Azure Pipelines service connection with only the minimum permissions required for its intended tasks, limiting the blast radius if credentials are compromised and preventing accidental or malicious overreach to unrelated Azure resources.

Why this answer

Granting the least privilege to service connections (Option A) is a core security principle that limits the permissions of automated processes to only what is strictly necessary, reducing the blast radius of a compromised connection. Using Azure Key Vault to store secrets and fetch them at runtime (Option B) ensures that sensitive values like API keys and passwords are never exposed in pipeline definitions or logs, and are securely retrieved via managed identities or service principals at execution time.

Exam trap

The trap here is that candidates may think using default hosted agents is secure because Microsoft manages them, but they overlook the risk of unpatched vulnerabilities or unnecessary software in the default image, and they may also mistakenly believe that storing secrets as pipeline variables is acceptable if they are marked as 'secret' in the UI, when in fact they are still stored in the pipeline's metadata and can be exposed in logs.

Full explanation →

552

Multi-Selecthard

Which THREE measures should you implement to protect secrets used in GitHub Actions workflows? (Choose three.)

Select 3 answers

A.Use hardcoded secrets in workflow files for simplicity.

B.Enable secret scanning to detect secrets in code pushes.

C.Use the same secret across all environments to reduce management overhead.

D.Use OpenID Connect (OIDC) to authenticate to Azure without storing credentials.

E.Store secrets as GitHub repository secrets or organization secrets.

AnswersB, D, E

Enabling secret scanning on GitHub automatically detects known secret formats (e.g., Azure keys, GitHub tokens) during code pushes, alerts repository administrators and the secret owner, and can block the push or trigger remediation workflows, preventing secrets from being merged.

Why this answer

Option B is correct because enabling secret scanning (including push protection) lets GitHub detect and block credentials committed to the repository, catching accidental leaks before they are exploited. Option D is correct because configuring OpenID Connect (OIDC) with a federated identity credential allows GitHub Actions to authenticate to Azure via short-lived tokens, eliminating the need to store long-lived cloud credentials as secrets. Option E is correct because storing values as GitHub repository secrets or organization secrets keeps them encrypted at rest, masks them in logs, and injects them only at runtime rather than exposing them in workflow files.

Option A is wrong because hardcoding secrets in workflow YAML exposes them in plaintext to anyone with repository read access and in logs. Option C is wrong because reusing one secret across all environments removes isolation, so a compromise in a low-trust environment grants access to production.

Exam trap

The trap here is that candidates may confuse 'secret scanning' with 'secret management' and overlook that OIDC is a valid measure because it removes the need to store secrets altogether, while hardcoding secrets (Option A) seems convenient but is a critical security anti-pattern.

Full explanation →

553

MCQmedium

You maintain a classic release pipeline that deploys to multiple environments. You need to ensure that a deployment to the Production environment only proceeds after a manual approval from a specific group of users. Which feature should you configure?

A.Post-deployment approvals on the Production environment

B.Deployment queue settings on the Production environment

C.Deployment gates on the Production environment

D.Pre-deployment approvals on the Production environment

AnswerD

Pre-deployment approvals are explicitly designed to pause the release pipeline before a deployment to an environment begins, requiring a designated approver to review and approve the release. For a Production environment, this ensures that a human sign-off is obtained before any code is deployed to Production.

Why this answer

Pre-deployment approvals are configured on an environment to require manual sign-off before a release is deployed to that environment. In a classic release pipeline, this ensures that the deployment to Production only proceeds after a specific group of users has approved it, meeting the requirement for manual approval before deployment.

Exam trap

The trap here is confusing pre-deployment approvals with deployment gates, as both can pause a deployment, but gates are automated checks (e.g., monitoring metrics) while approvals require explicit human action from a designated group.

How to eliminate wrong answers

Option A is wrong because post-deployment approvals occur after the deployment has already completed, not before, so they cannot gate the deployment to Production. Option B is wrong because deployment queue settings control how releases are queued and parallel execution, not manual approval requirements for a specific environment. Option C is wrong because deployment gates evaluate health metrics or external conditions automatically (e.g., via Azure Monitor or REST APIs) and do not provide manual approval from a specific group of users.

Full explanation →

554

MCQmedium

Your build pipeline uses a YAML template to define steps. You want to pass a parameter to the template to conditionally run a task. What syntax should you use in the template?

A.parameters:

B.arguments:

C.inputs:

D.variables:

AnswerA

Template parameters are defined under the `parameters:` key at the top of a YAML template file, allowing values to be passed from the calling pipeline via `${{ parameters.paramName }}` syntax. This makes templates reusable and configurable at compile time, before the pipeline runs.

Why this answer

The 'parameters' key in a YAML template is used to define parameters that can be passed to the template, allowing conditional execution based on the parameter value. Option B is incorrect: 'arguments' is not a standard YAML key for passing parameters to templates; it is used for specifying script arguments. Option C is incorrect: 'inputs' is used for task inputs within a step, not for template parameters.

Option D is incorrect: 'variables' are used to define pipeline variables, not for passing parameters to templates.

Full explanation →

555

MCQmedium

Refer to the exhibit. You are reviewing the branch policy configuration for the main branch in Azure DevOps. The policy requires a successful status check for 'continuous-integration/azure-devops' but not for 'security-scanner'. The minimum approver count is 0 and direct push is disallowed. What is the effect of this policy?

A.Developers can push directly to main without a pull request.

B.Pull requests require at least two reviewers.

C.Both status checks are required to pass.

D.Pull requests must pass the 'continuous-integration/azure-devops' check, but no reviewer approval is needed.

AnswerD

The branch policy lists 'continuous-integration/azure-devops' under required status checks, so a pull request cannot be merged until that CI check succeeds. However, the Minimum approver count is explicitly configured to 0, meaning no reviewer approval is part of the merge gate. Thus, the pull request is blocked only by the CI pipeline result, not by human code review.

Why this answer

The policy requires a successful status check for 'continuous-integration/azure-devops' but not for 'security-scanner'. With a minimum approver count of 0 and direct push disallowed, pull requests must pass the required CI check, but no reviewer approval is needed. This means the PR can be completed automatically once the CI check passes, without any human reviewer.

Exam trap

The trap here is that candidates assume 'minimum approver count = 0' means direct push is allowed, or that all listed status checks are required, when in fact only explicitly selected checks are mandatory.

How to eliminate wrong answers

Option A is wrong because direct push is disallowed, so developers cannot push directly to main without a pull request. Option B is wrong because the minimum approver count is 0, meaning no reviewer approval is required, not at least two. Option C is wrong because the policy explicitly requires only 'continuous-integration/azure-devops' to pass; 'security-scanner' is not required.

Full explanation →

556

MCQmedium

Refer to the exhibit. A developer commits code to the 'develop' branch. The pipeline does not trigger. What is the most likely reason?

A.The trigger is configured to only run on the 'main' branch.

B.The pipeline requires a manual trigger.

C.The pipeline has a CI trigger disabled.

D.The pool 'ubuntu-latest' is not available.

AnswerA

The YAML pipeline defines a CI trigger using `trigger: - main`, which instructs Azure Pipelines to start a run only for pushes that land on the `main` branch. A commit pushed to `devel` does not match that branch filter, so no pipeline run is created. Therefore the reason for the missing run is scope, not a bad agent pool or manual mode.

Why this answer

The pipeline did not trigger on a commit to the 'develop' branch. The most likely reason is that the YAML pipeline's trigger is configured to only include the 'main' branch, so commits to 'develop' are ignored. Azure Pipelines CI triggers default to all branches unless specified, but if the trigger explicitly includes only 'main', then 'develop' commits won't trigger.

Other options are less likely: manual trigger would require explicit run, but the question implies automatic trigger expected; CI trigger disabled would prevent any automatic trigger, but the question specifies 'develop' branch, suggesting other branches might work; pool availability would cause failure after trigger, not prevent trigger.

Exam trap

The trap is assuming that the pipeline triggers on all branches by default. In Azure DevOps, if you explicitly specify a trigger for only 'main', commits to other branches like 'develop' will not trigger the pipeline. Candidates often overlook the branch filters in the YAML.

How to eliminate wrong answers

Option B is wrong because if the pipeline required a manual trigger, it would not trigger on any branch automatically, but the scenario implies that commits to other branches might trigger, or the expectation is automatic. Option C is wrong because if the CI trigger were disabled entirely, no commits would trigger the pipeline, but the question focuses on the 'develop' branch specifically, implying that other branches might trigger. Option D is wrong because pool availability affects where the pipeline runs, not whether it triggers; an unavailable pool would cause the pipeline to fail after triggering, not prevent the trigger.

Full explanation →

557

MCQhard

Your company has a large monorepo with multiple microservices. You have a single YAML-based Azure Pipeline that builds the entire solution on every commit to the main branch. The pipeline takes over an hour to complete, causing long feedback loops. Developers often submit changes to only one service, but the whole pipeline runs. You need to reduce build time while maintaining quality. You are considering splitting the pipeline into multiple pipelines, each for a service, and using path triggers. However, some services have dependencies on shared libraries that are updated infrequently. You also need to ensure that integration tests that span multiple services still run when necessary. What should you do?

A.Create separate pipelines for each service with path triggers, and create an additional comprehensive pipeline that triggers only when shared libraries change.

B.Keep the single pipeline but add caching for dependencies.

C.Use a single pipeline but add conditional stages to skip unchanged services.

D.Create separate pipelines for each service with path triggers, and disable the comprehensive pipeline.

AnswerA

This approach uses path-based triggers to run individual service pipelines only when their source changes, reducing build time and resource usage. The additional comprehensive pipeline, triggered only by modifications to shared libraries, ensures cross-service integration tests still run when dependencies change, preserving integration testing without unnecessary builds.

Why this answer

It uses path triggers to run only the pipeline for the changed service, drastically reducing build time. The additional comprehensive pipeline, triggered only when shared libraries change, ensures that integration tests spanning multiple services still run when dependencies are updated, maintaining quality.

Exam trap

The trap here is that candidates may think caching (Option B) or conditional stages (Option C) are sufficient, but they fail to address the need for integration tests across services when shared libraries change, which requires a separate comprehensive pipeline with path triggers.

How to eliminate wrong answers

Option B is wrong because caching dependencies reduces build time for repeated steps but does not address the core issue of running the entire pipeline for every commit, including unchanged services. Option C is wrong because conditional stages to skip unchanged services still require evaluating the entire pipeline, and Azure Pipelines does not natively support skipping stages based on changed paths without complex scripting; it also does not solve the integration test problem for shared library changes. Option D is wrong because disabling the comprehensive pipeline means integration tests that span multiple services will not run when shared libraries change, breaking the requirement to maintain quality.

Full explanation →

558

MCQmedium

Your team uses Azure Pipelines to deploy a Node.js application. Recently, deployments have been failing intermittently due to a missing npm package. The pipeline runs successfully on the local agent but fails on the hosted agent. Which instrumentation strategy should you implement to identify the root cause?

A.Replace the hosted agent with a self-hosted agent.

B.Configure Application Insights for the Node.js app to monitor runtime errors.

C.Enable verbose logging for the npm install task and compare the output between pipeline runs.

D.Add a pipeline cache task for npm packages to ensure consistent restore.

AnswerC

Verbose logging on the npm install task exposes dependency resolution, registry access and package versions, revealing why the hosted agent differs from the local one. Comparing outputs pinpoints the missing package's source, satisfying the need to diagnose intermittent hosted-agent failures.

Why this answer

Verbose logging on the npm install task surfaces the exact package resolution, registry URL, and dependency tree being used on the hosted agent, which is where the failure occurs. Comparing that output against the successful local run reveals differences such as a missing package-lock.json, a different registry, or a case-sensitivity issue on the Linux hosted agent. This is a diagnostic instrumentation step, which is what the question asks for.

Exam trap

AZ-400 often tests the distinction between build-time instrumentation (pipeline task logging) and runtime monitoring (Application Insights), luring candidates toward APM tools when the failure occurs during the build/restore phase.

How to eliminate wrong answers

Option A is wrong because switching to a self-hosted agent changes the environment rather than instrumenting the pipeline to identify the root cause, and it may mask the underlying issue. Option B is wrong because Application Insights monitors runtime application errors after deployment, not build-time npm restore failures. Option D is wrong because caching npm packages improves performance and consistency but does not provide diagnostic visibility into why the package is missing.

Full explanation →

559

MCQhard

You are designing a Git branching strategy for a large enterprise with multiple Azure DevOps projects. The strategy must support hotfixes for production releases, feature development in isolated branches, and release branches for stabilization. The team uses CI/CD pipelines that trigger on branch creation. You need to minimize merge conflicts and ensure that hotfix changes are propagated to all active branches. Which branching model should you recommend and how should you configure branch policies?

A.Use GitHub Flow with feature branches merging directly to main. Use a release branch for stabilization. Use pull requests for all merges.

B.Use trunk-based development with short-lived feature branches. Use feature toggles for incomplete work. No separate hotfix branch.

C.Use a forking workflow where each developer forks the repository and submits pull requests. Use branch policies on the upstream main branch.

D.Use GitFlow with main, develop, and hotfix branches. Configure branch policies on main and develop to enforce pull requests with required reviewers. Use a pipeline to automatically merge hotfix branches into both main and develop.

AnswerD

GitFlow's dedicated hotfix branches, created from main and merged back into both main and develop, satisfy the requirement that hotfix changes propagate to all active branches. Branch policies on main and develop enforce pull requests with required reviewers, minimising conflicts during stabilisation.

Why this answer

GitFlow is designed for projects with multiple release cycles and hotfixes. It uses main, develop, feature, release, and hotfix branches. Configuring branch policies on main and develop enforces pull requests with required reviewers, ensuring code quality.

Automatically merging hotfix branches into both main and develop ensures that hotfix changes are propagated to all active branches, minimizing merge conflicts and ensuring consistency.

Exam trap

AZ-400 often tests the misconception that trunk-based development is always best, but for complex release management, GitFlow with hotfix propagation is required.

How to eliminate wrong answers

Option A is wrong because GitHub Flow with feature branches merging directly to main lacks a develop branch and a structured hotfix process; it may not propagate hotfixes to all active branches. Option B is wrong because trunk-based development with feature toggles does not use separate hotfix branches; while it can work, it does not explicitly ensure hotfix propagation to multiple branches. Option C is wrong because a forking workflow is more about open-source contributions and does not inherently provide a branching model for hotfixes and releases.

Full explanation →

560

MCQmedium

Your Azure DevOps project uses Git for source control. You want to enforce that all code changes are reviewed before merging into the main branch. Which branch policy should you enable?

A.Allow only comment resolution.

B.Require a successful build before merging.

C.Limit merge types to squash merge.

D.Require a minimum number of reviewers.

AnswerD

Setting a minimum number of reviewers is the branch policy that directly enforces code review: a pull request cannot be completed until the specified number of distinct users have explicitly approved it. This ensures that changes receive independent human verification before they are merged into the target branch.

Why this answer

The 'Require a minimum number of reviewers' branch policy in Azure DevOps enforces that a specified number of approvers must sign off before a pull request can be completed, directly satisfying the requirement that all code changes are reviewed before merging. This policy can be set on the main branch and optionally reset votes on new pushes. It is the standard mechanism for mandatory code review in Azure Repos.

Exam trap

AZ-400 often tests the confusion between build validation policies (CI gates) and reviewer policies (human approval), leading candidates to choose 'Require a successful build' when the question explicitly asks for code review.

How to eliminate wrong answers

Option A is wrong because 'Allow only comment resolution' merely requires that comments be resolved before merge; it does not require any reviewer approval, so changes could merge without review. Option B is wrong because requiring a successful build enforces CI quality gates but does not mandate human review; a build can pass without any reviewer. Option C is wrong because limiting merge types to squash merge controls commit history shape, not review requirements.

Full explanation →

561

MCQmedium

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

A.The Prod environment requires manual approval before deployment.

B.The release definition ID 5 is incorrect.

C.The Prod environment has a pre-deployment condition that waits for the Dev environment to succeed.

D.The build artifact with ID 123 is not accessible.

AnswerC

The Prod environment's pre-deployment condition is configured to trigger only after a successful deployment to the Dev environment. In Azure DevOps release pipelines, environment-level pre-deployment gates can be set to 'After environment' and specify a dependency on a prior environment's completion. If that condition is set to require Dev to succeed, the Prod deployment will remain in a 'Waiting' state until Dev finishes, which precisely matches the observed behavior. This is the default dependency model when you add environments sequentially, and it explains why Prod is delayed even though the artifact is valid and no approvals are configured.

Why this answer

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

Exam trap

The AZ-400 exam often tests the distinction between manual approval and sequential environment dependencies, where candidates mistakenly assume a missing approval gate when the real issue is a pre-deployment condition waiting for a prior environment to succeed.

How to eliminate wrong answers

Option A is wrong because while manual approval is a common pre-deployment condition, the exhibit does not show any approval gates configured; the most likely reason based on the default behavior is the sequential dependency. Option B is wrong because the release definition ID 5 is used to create the release, and if it were incorrect, the release creation itself would fail, not just the Prod deployment. Option D is wrong because if the build artifact with ID 123 were not accessible, the release creation or Dev deployment would fail first, not specifically block Prod while Dev is deploying.

Full explanation →

562

MCQmedium

Your team uses Azure Boards to manage work items. You need to ensure that when a work item is moved to 'Closed', all linked pull requests in Azure Repos are automatically completed. What should you configure?

A.Service hook to a custom Azure Function

B.Work item 'Pull Request' tab

C.Work item rule (state transition rule)

D.Branch policy on the target branch

AnswerA

A service hook in Azure DevOps can subscribe to a 'Pull request completed' or 'Pull request merged' event and invoke an HTTP endpoint, such as an Azure Function, which then uses the REST API to transition an Azure Boards work item to the appropriate state. This is a valid external automation approach because it is not a built-in feature and requires custom code to correlate the PR to work items and call the update.

Why this answer

Azure Boards service hooks can trigger a custom Azure Function when a work item state changes to 'Closed', and that function can complete linked pull requests via Azure Repos REST API. Option C is incorrect because work item rules (state transition rules) in Azure Boards do not have a built-in action to automatically complete pull requests; they only allow changes to work item fields, not external actions like completing PRs.

Full explanation →

563

Multi-Selecteasy

Your organization uses GitHub Actions for CI/CD. You need to ensure that workflows are only triggered when changes are pushed to the main branch or when a pull request is opened against main. Which two trigger types should you specify in the workflow?

Select 2 answers

A.pull_request: branches: [ main ]

B.push: branches: [ main ]

C.release

D.workflow_dispatch

E.schedule

AnswersA, B

The `pull_request` event triggers the workflow when a pull request is opened, synchronized, or reopened, and the `branches: [ main ]` filter ensures it only runs for PRs whose base branch is `main`. This is the correct choice because it enables CI on proposed changes before merging, catching issues early in the review process while avoiding runs for PRs targeting other branches.

Why this answer

The `pull_request` trigger with `branches: [ main ]` ensures the workflow runs when a pull request is opened (or updated) targeting the main branch. Option B is correct because the `push` trigger with `branches: [ main ]` ensures the workflow runs when commits are pushed directly to the main branch. Together, these two triggers cover the exact requirement: changes pushed to main and pull requests opened against main.

Exam trap

The trap here is that candidates often confuse `pull_request` with `pull_request_target` or forget that `push` and `pull_request` are separate events, leading them to select only one trigger or add irrelevant triggers like `release` or `schedule`.

Full explanation →

564

MCQeasy

Your team is using GitHub Actions to deploy a containerized application to Azure Kubernetes Service (AKS). You need to securely authenticate the workflow to AKS without storing credentials in the repository. What should you use?

A.Use OpenID Connect (OIDC) with a federated identity credential.

B.Use the GITHUB_TOKEN to authenticate to Azure.

C.Use an SSH deploy key to authenticate to AKS.

D.Store an Azure service principal password as a GitHub secret.

AnswerA

OpenID Connect (OIDC) with a federated identity credential is the recommended approach because it eliminates static secrets: GitHub Actions exchanges a short-lived token with Azure AD, and Azure trusts the federated identity without requiring you to store any passwords or client secrets. This provides passwordless, rotation-free authentication that is more secure and easier to manage.

Why this answer

OpenID Connect (OIDC) allows GitHub Actions to exchange a short-lived token for Azure credentials using a federated identity credential, eliminating the need to store any long-lived secrets in the repository. This is the recommended approach for secure, passwordless authentication to Azure services, including AKS, because it uses token-based authentication that automatically rotates and is scoped to specific workflows.

Exam trap

The trap here is that candidates often confuse the GITHUB_TOKEN (which is for GitHub API calls) with an Azure authentication token, or they assume that storing a service principal password as a secret is acceptable, missing the security and compliance benefits of OIDC-based federated identity.

How to eliminate wrong answers

Option B is wrong because the GITHUB_TOKEN is scoped to the GitHub repository and cannot authenticate to Azure resources; it is used for GitHub API operations only. Option C is wrong because SSH deploy keys are used for Git repository access (e.g., cloning private repos), not for authenticating to Azure Kubernetes Service or any Azure resource. Option D is wrong because storing an Azure service principal password as a GitHub secret still requires managing a long-lived credential, which violates the requirement to avoid storing credentials in the repository and introduces security risks such as secret rotation and exposure.

Full explanation →

565

Multi-Selecthard

Which THREE are benefits of using a monorepo with Azure Repos and CI/CD pipelines?

Select 3 answers

A.Granular repository-level permissions

B.Faster build times due to smaller codebase

C.Easier code sharing across projects

D.Simplified dependency management

E.Atomic cross-component commits

AnswersC, D, E

A monorepo lets several projects import shared libraries directly from one repository, so a change to a common module is immediately visible to every consumer. This satisfies the stem's code-sharing benefit, since Azure Pipelines can trigger builds across affected projects without cross-repository package publishing or version pinning.

Why this answer

Option C is correct because a monorepo places all projects in a single repository, so shared libraries, utilities, and interfaces can be referenced directly rather than published and consumed as versioned packages across multiple repos. Option D is correct because dependencies between components are resolved from one consistent source tree, avoiding version-skew and cross-repo package coordination that complicates dependency management. Option E is correct because a single commit can change multiple components together, so a cross-component change lands atomically and CI/CD can validate the whole change set in one pipeline run.

Option A is not a benefit of a monorepo; granular repository-level permissions are actually harder because everything lives in one repo, and Azure Repos permissions are typically applied at repo, branch, or path level rather than per project. Option B is not a benefit either, since a monorepo is a larger codebase and builds are not inherently faster; faster builds usually require path filters, incremental builds, or pipeline caching rather than resulting from the monorepo itself.

Exam trap

The trap here is that candidates confuse the benefits of a monorepo with those of a multi-repo setup, assuming that a monorepo inherently improves build times or permissions granularity, when in reality it often worsens both without specific pipeline optimizations like sparse checkout or path-based triggers.

Full explanation →

566

MCQmedium

A development team uses Azure Repos Git. They need to ensure that every commit pushed to the main branch includes a valid work item link, but they do not want to block developers from pushing to feature branches. What should they configure?

A.A required reviewer policy on main that assigns a specific team.

B.A branch policy on main that checks for linked work items.

C.A repository-level policy that requires all commits to be signed.

D.A branch policy on main that requires a minimum number of reviewers.

AnswerB

The linked work items policy on the main branch requires that every commit or pull request targeting main be associated with at least one Azure Boards work item. Feature branches remain unaffected because the policy is scoped only to main, so developers can push freely to feature branches while main stays compliant.

Why this answer

The linked work items branch policy on main enforces that commits or pull requests targeting main are associated with at least one work item, while leaving feature branches unrestricted. Reviewer count, commit signing, and required reviewer policies address different concerns and do not enforce work item linkage.

Exam trap

The trap here is confusing approval-related policies such as minimum reviewers or required reviewers with the linked work items policy that specifically validates work item association.

Full explanation →

567

MCQeasy

You are configuring a release pipeline to deploy to Azure App Service. You want to use the 'Deploy Azure App Service' task. Which authentication method should you use to securely connect Azure DevOps to the Azure subscription?

A.Azure CLI authentication with a user account.

B.Azure Resource Manager service connection using a service principal.

C.Use a SAS token for the App Service.

D.Managed Identity assigned to the Azure DevOps agent.

AnswerB

An Azure Resource Manager service connection using a service principal is the recommended secure, automated authentication method for CI/CD pipelines; it uses an app registration with a secret or certificate, enables fine-grained role-based access control, and avoids interactive login requirements.

Why this answer

The 'Deploy Azure App Service' task requires a secure, non-interactive connection between Azure DevOps and Azure. An Azure Resource Manager service connection using a service principal is the recommended and supported method because it uses Azure AD authentication with a client secret or certificate, enabling automated, credential-free deployments without user interaction or token expiry issues.

Exam trap

The trap here is that candidates confuse SAS tokens (used for storage-level access) with service principal authentication, or mistakenly think Managed Identity can be directly assigned to a non-Azure-hosted DevOps agent, when in fact service connections require a service principal for secure, automated subscription access.

How to eliminate wrong answers

Option A is wrong because Azure CLI authentication with a user account requires interactive login and is not suitable for automated pipelines; it also lacks the necessary service principal permissions for headless deployment. Option C is wrong because a SAS token is used for granting delegated access to Azure Storage resources (like blobs or files), not for authenticating Azure DevOps to the Azure subscription or App Service management plane. Option D is wrong because Managed Identity cannot be assigned directly to an Azure DevOps agent; it is a feature for Azure resources (e.g., VMs, App Services) and is not supported as an authentication method for Azure DevOps service connections.

Full explanation →

568

MCQmedium

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

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

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

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

D.Use a command-line task (e.g., Bash, PowerShell) to execute the security scan tool.

AnswerD

A Command-Line, Bash, or PowerShell task can directly invoke any installed security scanning executable (e.g., Trivy, OWASP ZAP, a custom CLI, or a vendor's command-line tool) with the appropriate arguments, run it against the repository workspace, and fail the pipeline based on the tool's exit code. This is the standard, supported way to integrate command-line-based security scanning into an Azure Pipeline because it runs inside the agent job and can produce actionable results.

Why this answer

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

Exam trap

The trap here is that candidates may assume a marketplace task or service hook is required for any third-party tool, overlooking the simplicity and directness of using a command-line task when the tool is already installed on a self-hosted agent.

How to eliminate wrong answers

Option A is wrong because the 'Install Tool' task is designed to download and install tools from a specified URL or Azure storage, not to execute a tool already installed on the agent; adding the tool as a capability only labels the agent for targeting, it does not run the scan. Option B is wrong because the 'Run Security Scan' task from the marketplace does not exist for this specific third-party tool; marketplace tasks are pre-built integrations, and if the tool is not available there, you cannot use a generic marketplace task to execute it. Option C is wrong because creating a custom service hook to trigger the scan externally and wait for results introduces unnecessary complexity, latency, and potential failure points; service hooks are for event-driven notifications, not for synchronous execution of a local tool within a pipeline job.

Full explanation →

569

MCQhard

You are setting up a GitHub Actions workflow to deploy a containerized application to Azure Kubernetes Service (AKS). You need to securely authenticate to the AKS cluster using a service principal. What is the recommended way to store and use the service principal credentials?

A.Use managed identity for GitHub Actions and assign it to the AKS cluster

B.Store the service principal credentials in a Kubernetes secret in the AKS cluster

C.Store the service principal credentials as GitHub Actions secrets and reference them in the 'azure/login' action

D.Store the service principal credentials as environment variables in the workflow file

AnswerC

GitHub Actions secrets are encrypted at rest, masked in logs, and injected into the workflow runtime only when explicitly referenced, making them the secure, supported way to pass service principal credentials. The 'azure/login' action accepts these credentials via secret inputs (e.g., 'client-id', 'client-secret', 'subscription-id', 'tenant-id') and uses them to establish an authenticated session with Azure, so storing them as GitHub Actions secrets and referencing them in that action is the correct, best-practice approach.

Why this answer

GitHub Actions secrets are the recommended secure mechanism for storing sensitive credentials like a service principal's client ID and secret. The 'azure/login' action can directly reference these secrets (e.g., `${{ secrets.AZURE_CREDENTIALS }}`) to authenticate to Azure, and then the 'azure/aks-set-context' action uses that authenticated session to connect to the AKS cluster. This approach avoids hardcoding credentials in the workflow file and leverages GitHub's encrypted storage.

Exam trap

The trap here is that candidates may confuse storing credentials in Kubernetes secrets (which is valid for in-cluster applications) with the initial authentication needed from an external CI/CD system, or they may think managed identities can be directly assigned to GitHub Actions runners, which is not supported.

How to eliminate wrong answers

Option A is wrong because managed identity for GitHub Actions is not directly supported for authenticating to AKS; managed identities are Azure resources that cannot be assigned to GitHub Actions runners, and the AKS cluster would need to trust the GitHub runner's identity, which is not a standard authentication flow. Option B is wrong because storing service principal credentials in a Kubernetes secret within the AKS cluster does not help the GitHub Actions workflow authenticate to the cluster initially; the workflow needs credentials to access the cluster before it can read any Kubernetes secrets. Option D is wrong because storing credentials as environment variables in the workflow file exposes them in plain text in the workflow logs and repository, violating security best practices and potentially leaking secrets.

Full explanation →

570

MCQhard

You are deploying a multi-container application to Azure Kubernetes Service (AKS) using Azure Pipelines. You need to ensure that the deployment rollback automatically if the health checks fail. Which strategy should you implement?

A.Configure a rolling update with readiness and liveness probes

B.Use a blue-green deployment strategy

C.Use Helm charts with pre-upgrade hooks

D.Implement a canary deployment with manual verification

AnswerA

Configure a rolling update with readiness and liveness probes: This approach leverages Kubernetes' native deployment controller to gradually replace pods while continuously checking health signals. If a readiness probe fails on new pods, the rollout immediately stops and Kubernetes automatically rolls back to the last healthy replica set, ensuring zero manual intervention and no downtime.

Why this answer

A rolling update with readiness and liveness probes is the correct strategy because Kubernetes automatically monitors pod health via these probes. If a new pod fails its readiness probe, the rolling update pauses; if the liveness probe fails, the pod is restarted. Azure Pipelines can be configured to detect probe failures and trigger a rollback to the previous stable ReplicaSet, ensuring automated recovery without manual intervention.

Exam trap

The trap here is that candidates often confuse deployment strategies (blue-green, canary) with the mechanism for automated health-check-based rollback, overlooking that Kubernetes native probes combined with rolling updates provide the simplest and most automatic solution.

How to eliminate wrong answers

Option B is wrong because blue-green deployment requires manual or scripted traffic switching and does not inherently provide automatic rollback based on health checks; it typically relies on external verification. Option C is wrong because Helm pre-upgrade hooks run before the upgrade and are used for tasks like database migrations, not for monitoring health after deployment or triggering rollbacks. Option D is wrong because canary deployment with manual verification depends on human approval to proceed or roll back, which contradicts the requirement for automatic rollback based on health checks.

Full explanation →

571

Multi-Selecthard

Which THREE features are available in GitHub Actions for managing secrets across environments?

Select 3 answers

A.Encrypted variables in workflows

B.Organization-level secrets

C.Secret scanning alerts

D.Environment-specific secrets

E.Repository-level secrets

AnswersB, D, E

Organization-level secrets are a core GitHub Actions feature that lets administrators define secrets once at the organization level so they are available to all repositories within that organization, enabling centralized management and consistent access across multiple workflows without duplicating sensitive values.

Why this answer

GitHub Actions supports three types of secrets for managing sensitive data: organization-level secrets, which are encrypted and shared across multiple repositories within an organization; repository-level secrets, which are available to all workflows in a single repository; and environment-specific secrets, which are scoped to a particular environment (e.g., production) within a repository. Together these allow centralized and scoped management of secrets across different environments and repositories. Options A and C are incorrect: 'encrypted variables in workflows' is not the official GitHub Actions secret feature, and secret scanning alerts is a reactive security service, not a secret management feature.

Exam trap

The trap here is that candidates confuse 'secret scanning alerts' (a reactive security feature) with proactive secret management features, or assume 'encrypted variables' is a valid term when GitHub Actions officially uses 'secrets' for encrypted sensitive data.

Full explanation →

572

MCQhard

You manage an Azure Kubernetes Service (AKS) cluster that runs a microservices application. You have enabled Azure Monitor for containers and configured Application Insights for the services. The development team reports that they cannot see the dependency calls between microservices in the Application Insights Application Map. You need to ensure that the Application Map shows the dependencies between the microservices. What should you do?

A.Configure the Application Insights SDK in each microservice to track dependencies and use the W3C Trace Context protocol for correlation.

B.Enable Azure Monitor for containers and ensure that the Container Insights agent is collecting performance data from all nodes.

C.Deploy the Application Insights Kubernetes add-on to the cluster and configure it to collect logs from all pods.

D.Use Azure Monitor Logs to query the ContainerLog table and create a custom workbook that visualizes the dependencies.

AnswerA

The Application Map relies on dependency telemetry and correlated operation IDs. For microservices, each service must be instrumented to track outgoing dependencies and propagate trace context. Using the W3C Trace Context standard ensures that the correlation headers are passed between services, allowing Application Insights to stitch together the distributed trace and display dependencies in the Application Map.

Why this answer

The Application Map in Application Insights is built from dependency telemetry and correlated operation IDs. To show dependencies between microservices, each service must be instrumented to track outgoing calls and propagate trace context using a standard like W3C Trace Context. Container-level monitoring and log collection do not provide the necessary application telemetry.

Exam trap

The trap here is confusing infrastructure monitoring with application performance monitoring; enabling container monitoring does not automatically create the dependency telemetry needed for the Application Map.

Full explanation →

573

MCQeasy

You need to configure a build pipeline that triggers only when changes are pushed to the 'release/*' branch. Which trigger configuration should you use?

A.Set 'trigger: none' in YAML

B.Set 'trigger: branches: include: - release/*'

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

D.Set 'trigger: tags: include: - v*'

AnswerB

Setting 'trigger: branches: include: - release/*' configures the pipeline to automatically run on every push to any branch matching the release/* wildcard. This precisely matches the requirement to trigger only for release branches, making it the correct choice.

Why this answer

The YAML trigger configuration 'trigger: branches: include: - release/*' explicitly specifies that the pipeline should run only when changes are pushed to any branch matching the 'release/*' wildcard pattern. This is the standard way to define branch-based triggers in Azure Pipelines YAML, ensuring that only pushes to release branches initiate the build.

Exam trap

The trap here is that candidates often confuse branch triggers with tag triggers or forget that omitting a trigger defaults to 'include all branches', leading them to incorrectly select a tag-based option or a branch that doesn't match the required pattern.

How to eliminate wrong answers

Option A is wrong because 'trigger: none' disables all CI triggers, meaning the pipeline will never run automatically on any branch push, which contradicts the requirement to trigger on 'release/*' branches. Option C is wrong because it includes only the 'main' branch, which does not match the 'release/*' pattern and would ignore pushes to release branches. Option D is wrong because it configures a tag-based trigger (tags starting with 'v'), not a branch-based trigger; tags are separate from branches and do not respond to branch pushes.

Full explanation →

574

Multi-Selecthard

Which TWO of the following are valid ways to trigger a pipeline in Azure DevOps when a pull request is created?

Select 2 answers

A.Pull request trigger in YAML pipeline

B.Scheduled trigger

C.Continuous integration trigger

D.Branch policy with build validation

E.Pipeline completion trigger

AnswersA, D

A YAML pipeline can define a pull request trigger with the 'pr:' keyword, causing the pipeline to run automatically whenever a pull request is created or updated against the specified branch, enabling validation of the proposed changes before merge.

Why this answer

Azure DevOps YAML pipelines support a `pr` trigger that automatically runs the pipeline when a pull request is created or updated. This trigger is defined directly in the YAML file and can be scoped to specific branches or paths, making it a native and flexible way to respond to PR events.

Exam trap

The trap here is that candidates often confuse the continuous integration trigger (which fires on push) with the pull request trigger, or they overlook that branch policy build validation is a separate but equally valid method to trigger a pipeline on PR creation.

Full explanation →

575

Multi-Selecthard

Which THREE factors should you consider when designing a strategy for managing secrets in Azure Pipelines? (Choose three.)

Select 3 answers

A.Hardcode secrets in the pipeline YAML for simplicity.

B.Store secrets as plain text variables in YAML pipelines.

C.Use Azure Key Vault to store secrets.

D.Use a library variable group linked to Azure Key Vault.

E.Reference secrets as secret variables in pipeline tasks.

AnswersC, D, E

Use Azure Key Vault to store secrets because it is a centralized, cloud-based secret management service that provides strong encryption, granular access policies with Azure AD authentication, audit logging, and automated secret rotation, ensuring secrets are never exposed in code or logs.

Why this answer

Azure Key Vault is the recommended service for securely storing and managing secrets, keys, and certificates. By integrating Key Vault with Azure Pipelines, you can avoid exposing sensitive information in YAML files or pipeline logs. This approach ensures secrets are never hardcoded and are dynamically retrieved at runtime.

Exam trap

The trap here is that candidates may think storing secrets as plain text variables is acceptable if they are marked as 'secret' in the pipeline UI, but those values are still stored in the pipeline definition and can be exposed in logs or exports, whereas Key Vault provides centralized, audited secret management.

Full explanation →

576

MCQhard

The exhibit shows a parameters file for an ARM template deployment. During a release pipeline, the deployment fails with the error 'The provided value for the template parameter 'sku' is not valid'. The ARM template defines the 'sku' parameter as an allowed value set of ['F1', 'D1', 'B1', 'S1']. What could be the issue?

A.The parameter file contains an extra space or hidden character in the 'sku' value.

B.The parameter file is missing the '$schema' property.

C.The 'sku' parameter is defined in the 'variables' section instead of 'parameters'.

D.The ARM template expects a different API version for the resource.

AnswerA

ARM parameter validation compares the supplied string against the allowed value set exactly, so a trailing space or non-printing character makes 'S1 ' fail to match 'S1'. The template rejects the value as invalid even though it looks correct in the file.

Why this answer

ARM parameter files are JSON, and the allowed-values check is a strict string comparison against the template's allowed set. A trailing space, non-breaking space, or hidden Unicode character in the 'sku' value (for example 'F1 ' instead of 'F1') causes the value to fail the allowed-values validation even though it looks correct in the editor. This is the classic cause of 'The provided value for the template parameter is not valid' when the value visually matches the allowed list.

Exam trap

The trap is that the value looks identical to an allowed value on screen, so candidates assume the problem must be structural (schema, variables, API version) rather than an invisible character in the string.

How to eliminate wrong answers

Option B is wrong because a missing '$schema' property in a parameter file does not cause a parameter value validation error — it may cause schema validation warnings but not the allowed-values failure. Option C is wrong because if 'sku' were defined in variables rather than parameters, the deployment would fail with a different error about an undefined parameter, not an invalid value. Option D is wrong because an API version mismatch produces errors about the resource type or API version, not a parameter value validation failure against the allowed set.

Full explanation →

577

MCQeasy

A company uses Azure DevOps and needs to ensure that all pipelines use approved YAML templates from a central repository. The security team wants to prevent developers from referencing unapproved templates. What is the best way to enforce this?

A.Create a branch policy on the repository that requires all pull requests to be approved by security team members.

B.Configure a variable group with the approved template repository and require it in all pipelines.

C.Use a pipeline decorator to check the template origin and fail the pipeline if unapproved.

D.Set the 'Required template' repository setting in the Azure DevOps project to the approved central repository.

AnswerC

A custom pipeline decorator could technically inspect template origins and fail the build, but it requires you to write, publish, and maintain a private extension, which is complex and error-prone. The built-in 'Required template' repository setting provides the same enforcement more simply and reliably without custom code.

Why this answer

The correct approach is to use a pipeline decorator that runs at the start of every pipeline, inspects the YAML for template references, and fails the pipeline if any template is not from the approved central repository. The 'Required template' setting forces inclusion of a template but does not block additional unapproved template references.

Exam trap

The trap is that candidates may assume 'Required template' blocks all unapproved templates. In reality, it only enforces inclusion of a mandatory template. Pipeline decorators are a valid and robust way to enforce template origin restrictions.

How to eliminate wrong answers

Option A is wrong because a branch policy requiring pull request approval by security team members only controls changes to the repository's code, not the templates referenced in pipelines; developers could still merge code that references unapproved templates in other repositories. Option B is wrong because a variable group can store the approved repository URL, but it does not enforce that pipelines actually use it; developers can still hardcode or override the template source in their YAML files. Option C is wrong because pipeline decorators are injected at runtime and can check template origins, but they are not a native enforcement mechanism; they require custom scripting and maintenance, and can be bypassed if the decorator is not applied to all pipelines or if the pipeline agent has sufficient permissions.

Full explanation →

578

Drag & Dropmedium

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

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

Blue-green deployment involves creating a slot, deploying to it, validating, swapping, and monitoring.

Full explanation →

579

MCQhard

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

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

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

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

D.Create a protected variable group that stores the approval gate configuration and set the pipeline to use it. Restrict edit permissions on the release pipeline to a security group that does not include developers. For configuration changes, use an Azure Resource Manager template with a deployment script that sends logs to Azure Monitor.

AnswerD

Protected variable groups allow you to store critical configuration like approval gate settings and restrict access through pipeline permissions, ensuring only authorized users can modify those gates, and referencing the variable group in the pipeline makes the approval logic itself subject to governance. Restricting edit permissions on the release pipeline to a security group that excludes developers prevents developers from altering the pipeline definition to remove or bypass the required approvals, which is essential for compliance. Using an Azure Resource Manager template with a deployment script that sends logs to Azure Monitor provides an auditable, infrastructure-as-code approach for configuration changes, capturing exactly what was changed and who deployed it, and seamlessly integrating with Azure Monitor for centralized log retention and alerting. This layered defense enforces mandatory approval gates and provides complete change auditability, satisfying financial services compliance requirements.

Why this answer

It addresses both requirements: restricting pipeline edit permissions to a security group that excludes developers prevents them from removing the approval gate, and using an ARM template with a deployment script that sends logs to Azure Monitor ensures configuration changes are audited. Protected variable groups secure sensitive configuration, but the key is permission separation and audit logging via ARM deployment scripts.

Exam trap

The trap here is that candidates assume environment-level approvals or branch policies alone are sufficient, but they overlook that users with 'Edit release pipeline' permissions can bypass these controls by modifying the pipeline definition.

How to eliminate wrong answers

Option A is wrong because creating a new service connection with limited permissions does not prevent developers with 'Edit release pipeline' permissions from modifying the pipeline to bypass the approval gate; Azure Policy audits Azure resources but does not enforce pipeline-level approval gates. Option B is wrong because environment-level approvals in a release pipeline can still be bypassed if developers have 'Edit release pipeline' permissions to remove the environment or its approvals; Azure Policy does not enforce pipeline deployment flows. Option C is wrong because a branch policy on the YAML file only protects changes to the pipeline definition, not runtime bypass of the approval gate, and webhooks for configuration change events do not replace the need for audit logging to Azure Monitor via diagnostic settings or deployment scripts.

Full explanation →

580

MCQhard

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

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

B.Create a multi-stage YAML pipeline with a gate on the production stage that evaluates test results from the staging stage.

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

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

AnswerB

This approach leverages a single YAML pipeline with multiple stages, where the staging stage deploys and runs tests, publishing results as artifacts. A pre-deployment gate on the production stage uses those published test results (e.g., pass rate or coverage) to automatically block or allow the promotion, ensuring the exact same build that passed staging is deployed. Because gates are evaluated automatically before the stage starts, no manual approval is required, yet the release is safely gated by objective quality signals.

Why this answer

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

Exam trap

The trap here is that candidates often confuse stage-level gates with task-level conditions, assuming a single stage with conditional tasks can achieve the same result, but gates operate at the stage boundary and can evaluate aggregated results from the entire previous stage, not just individual task outcomes.

How to eliminate wrong answers

Option A is wrong because using a single stage with conditional tasks does not provide a true stage-level gate; tasks within a stage run sequentially and cannot block the entire stage based on results from a previous stage, leading to potential deployment to production even if tests fail. Option C is wrong because using two separate pipelines with a pipeline trigger does not allow the production pipeline to evaluate test results from the staging pipeline; triggers only start the next pipeline upon completion, not based on test outcomes. Option D is wrong because pre-deployment approvals are manual and not automated based on test results; they require human intervention and do not evaluate integration test pass/fail status.

Full explanation →

581

MCQeasy

The exhibit shows a draft Azure Monitor alert rule for Key Vault secret expiry. However, the query fails to return results for secrets that have already expired. What is the most likely reason?

A.The query does not include secrets that have no expiry date set.

B.The condition `DaysToExpiry > 0` excludes secrets that have already expired.

C.The query only checks secrets that are enabled.

D.The `limit 10` clause restricts to only 10 secrets, which may miss expired ones.

AnswerB

Expired secrets have a DaysToExpiry value that is negative because their expiry date is in the past. Using the condition DaysToExpiry > 0 filters out those negative values, so the alert rule excludes already expired secrets and only reports on those expiring in the future.

Why this answer

The query filters on `DaysToExpiry > 0`, which only returns secrets with a positive number of days remaining until expiry. Once a secret has expired, its `DaysToExpiry` becomes zero or negative, so it is excluded from the results. This is a logical filter error: the condition should be `DaysToExpiry <= 0` or remove the filter entirely to include expired secrets.

Exam trap

The trap here is that candidates focus on the syntax or limits of the query (like `limit 10`) rather than recognizing that the logical filter `DaysToExpiry > 0` inherently excludes the very data the alert is supposed to detect—expired secrets.

How to eliminate wrong answers

Option A is wrong because the query does not filter on whether a secret has an expiry date set; the issue is specifically about expired secrets, not those without an expiry date. Option C is wrong because the query does not include any condition that checks the enabled status of secrets; the problem is purely with the `DaysToExpiry` filter. Option D is wrong because the `limit 10` clause only affects the number of results returned, not the logical inclusion of expired secrets; even if more secrets were returned, expired ones would still be excluded by the `DaysToExpiry > 0` condition.

Full explanation →

582

MCQhard

You are a DevOps engineer for a large e-commerce company. The development team uses GitHub for source control and GitHub Actions for CI/CD. The application is a microservices architecture with 15 services, each in its own repository. You need to implement a continuous delivery pipeline that builds and deploys each service to a Kubernetes cluster in Azure (AKS). The pipeline must meet the following requirements: - Each service must have its own pipeline that triggers on pushes to the main branch. - Deployment to AKS must use Helm charts. - The pipeline must automatically increment the Helm chart version and update the deployment manifest in the repository. - Security scanning must be performed on container images before deployment. - The pipeline must support manual approval for production deployment. - All secrets (e.g., AKS credentials, registry credentials) must be stored securely and not exposed in logs. You need to design the workflow. What is the best course of action?

A.Use Azure Pipelines instead of GitHub Actions because it has better integration with AKS. Store secrets in Azure Key Vault and use variable groups.

B.Create a reusable workflow with OIDC authentication to Azure. Use Helm to deploy, increment chart version, and commit back. Use GitHub environments for approval gates. Integrate container scanning with Docker Scout or Trivy.

C.Create a workflow per service with direct deployment. Use kubectl commands to deploy. Store all secrets in a single GitHub secret. Skip security scanning to save time.

D.Create a single reusable workflow that each service calls. Use Azure CLI to deploy Helm charts. Store AKS credentials as GitHub secrets. Use a manual approval step via environment protection rules.

AnswerB

Using OIDC eliminates long-lived Azure credentials by exchanging short-lived tokens from GitHub Actions, satisfying secure auth without storing secrets. Helm manages releases with chart version increments and rollback capabilities, and committing the bumped chart back maintains GitOps traceability. GitHub environments provide protected branches and approval gates per stage, while Trivy or Docker Scout scans container images for vulnerabilities before deployment.

Why this answer

Option B satisfies every stated requirement using native GitHub Actions capabilities: reusable workflows provide DRY pipeline logic across the 15 service repos, OIDC federation eliminates long-lived AKS/registry credentials by exchanging short-lived tokens with Microsoft Entra ID, GitHub Environments supply the manual approval gate for production, and Trivy/Docker Scout integrate cleanly as a scanning step before Helm deployment. Helm handles chart versioning, and committing the bumped chart back to the repo closes the GitOps loop.

Exam trap

AZ-400 often tests whether candidates recognize that OIDC plus GitHub Environments replaces the older pattern of storing Azure service principal secrets and using Azure DevOps approval gates, so answers that keep static credentials or switch tools get eliminated.

How to eliminate wrong answers

Option A is wrong because migrating to Azure Pipelines contradicts the stated GitHub Actions requirement and adds no AKS capability that GitHub Actions lacks via OIDC and azure/k8s-deploy actions. Option C is wrong because kubectl bypasses Helm (violating the Helm requirement), a single shared GitHub secret violates least-privilege and secret isolation, and skipping scanning violates an explicit security requirement. Option D is wrong because storing AKS credentials as static GitHub secrets ignores the OIDC requirement, and using Azure CLI instead of Helm-native actions breaks the chart versioning/commit-back workflow.

Full explanation →

583

MCQhard

You are a security engineer for a large financial institution. The organization uses Azure DevOps with multiple projects, each containing hundreds of pipelines. The security team recently discovered that several pipeline variables marked as 'Secret' were inadvertently printed to logs due to a custom script task that echoed the variable. Consequently, the compliance officer requires that all secrets used in pipelines must be centrally managed in Azure Key Vault, and any pipeline that references a variable not from Key Vault must be blocked from running. Additionally, the solution must minimize administrative overhead and provide real-time enforcement across all projects in the organization. You have the following options: Option A: Develop a custom pipeline task that checks at runtime whether all secret variables originate from Key Vault, and add it to every pipeline YAML file manually. Option B: Create an Azure Policy definition that audits pipelines for the use of non-Key Vault variables and attach it to the management group containing the Azure DevOps resources. Option C: Use Azure DevOps Audit Logs to periodically review pipeline runs and manually identify pipelines that use non-Key Vault secrets. Option D: Configure a pipeline decorator in the organization settings that injects a task at the beginning of every pipeline to validate that all secret variables are linked to Key Vault, and fail the pipeline if any are not. Which option meets the requirements most effectively?

A.Develop a custom pipeline task that checks at runtime whether all secret variables originate from Key Vault

B.Create an Azure Policy definition that audits pipelines for the use of non-Key Vault variables

C.Use Azure DevOps Audit Logs to periodically review pipeline runs

D.Configure a pipeline decorator in the organization settings that injects a task at the beginning of every pipeline to validate that all secret variables are linked to Key Vault

AnswerD

A pipeline decorator injects a validation task into every pipeline across all projects automatically, failing runs whose secrets are not Key Vault-linked. This enforces centrally managed secrets organisation-wide with minimal administrative overhead, unlike per-pipeline YAML edits or periodic audit reviews.

Why this answer

A pipeline decorator is an organization-level extension that automatically injects tasks into every pipeline across all projects without modifying individual YAML files. By injecting a validation task at the start of each pipeline that checks whether secret variables are linked to Azure Key Vault and fails the run otherwise, it provides real-time enforcement, central management, and minimal administrative overhead — exactly matching the requirements.

Exam trap

AZ-400 often tests whether candidates confuse Azure Policy (which governs Azure resources) with Azure DevOps governance mechanisms (decorators, checks, approvals), so options invoking Azure Policy for pipeline control are classic distractors.

How to eliminate wrong answers

Option A is wrong because a custom task added manually to every pipeline YAML file does not scale across hundreds of pipelines in multiple projects and creates ongoing maintenance burden, violating the 'minimize administrative overhead' requirement. Option B is wrong because Azure Policy governs Azure resources (ARM), not Azure DevOps pipelines — Azure DevOps is not an Azure resource provider subject to Azure Policy evaluation, so this approach cannot enforce pipeline variable rules. Option C is wrong because periodic audit log review is detective, not preventive, and manual identification is slow, error-prone, and cannot block non-compliant pipelines from running.

Full explanation →

584

MCQhard

Refer to the exhibit. You have a YAML pipeline with the above steps. The pipeline publishes a web app and deploys to Azure App Service. The deployment fails with error: 'Could not find the package in the specified path.' What is the most likely cause?

A.The package path is wrong; the zip file is in $(Build.ArtifactStagingDirectory).

B.The AzureWebApp task input 'appType' is incorrect.

C.The dotnet publish command did not generate a zip file.

D.The service connection 'MyServiceConnection' is not authorized.

AnswerA

The AzureWebApp task's `package` input is configured with an incorrect file path. The `dotnet publish` command, when run in a YAML pipeline, defaults to publishing the zip package into `$(Build.ArtifactStagingDirectory)`, not into a subfolder like `$(System.DefaultWorkingDirectory)/published` unless explicitly redirected. Because the package path does not point to that staging directory, the task fails with a 'file not found' or 'no package found' error before deployment can begin. Setting `package: '$(Build.ArtifactStagingDirectory)/**/*.zip'` resolves the issue by correctly referencing the output location.

Why this answer

The error 'Could not find the package in the specified path' indicates that the AzureWebApp task is looking for a deployment package (typically a .zip file) at a path that does not exist. In the exhibit, the `dotnet publish` command outputs to `$(Build.ArtifactStagingDirectory)`, but the subsequent AzureWebApp task likely references a different path (e.g., `$(System.DefaultWorkingDirectory)` or a hardcoded path). The correct path should be `$(Build.ArtifactStagingDirectory)/**/*.zip` to match the published artifact.

Option A correctly identifies this path mismatch as the root cause.

Exam trap

The trap here is that candidates often assume the error is due to a missing zip file (Option C) or a misconfigured service connection (Option D), but the actual cause is a path variable mismatch between the publish output and the deployment task input.

How to eliminate wrong answers

Option B is wrong because the `appType` input (e.g., 'webApp' or 'webAppLinux') affects runtime stack selection but does not cause a 'package not found' error; it would instead cause a deployment failure related to incorrect app settings or runtime. Option C is wrong because the `dotnet publish` command with `--output $(Build.ArtifactStagingDirectory)` does generate a zip file (if configured) or at least the published output; the error is about the path, not the absence of a zip. Option D is wrong because an unauthorized service connection would result in an authentication/authorization error (e.g., 401 or 403), not a 'package not found' error, which is a file system issue.

Full explanation →

585

MCQmedium

Refer to the exhibit. You executed the Azure CLI command to list variable groups. A security audit requires that all variable groups containing secrets are configured to be authorized for all pipelines. Which statement is true based on the output?

A.The variable group 'ProdVars' contains a secret variable, but the output does not indicate whether it is authorized for all pipelines

B.The variable group 'ProdVars' is not authorized for all pipelines because no such property exists

C.The variable group 'ProdVars' has exposed the secret value in the output

D.The variable group 'ProdVars' is authorized for all pipelines because it has secret variables

AnswerA

The `az pipelines variable-group show` command returns the variable group's metadata and variable definitions. For a secret variable, the value is returned as null (or an empty string depending on the CLI version), which confirms the variable is secret. However, the output does not include an authorization flag such as `isAuthorized` or `authorizedForAllPipelines`; that is a separate property managed at the pipeline/library level. Therefore, while the output clearly indicates the presence of a secret variable, it provides no information about whether the variable group has been authorized for use in all pipelines.

Why this answer

The JSON output shows that 'ProdVars' has an 'ApiKey' variable with a null value, indicating it is a secret variable (values are masked). The output does not include any authorization properties, so we cannot determine if it is authorized for all pipelines. Option B is incorrect because the property 'authorized' may exist but is not shown in the list command; you need to use 'az pipelines variable-group show' or check the settings separately.

Option C is incorrect because the secret value is masked (null), not exposed. Option D is incorrect because having secret variables does not automatically authorize the group for all pipelines; authorization must be explicitly configured.

Full explanation →

586

MCQmedium

During a sprint review, stakeholders complain that they don't receive notifications about completed work items. The team uses Azure Boards with a custom notification subscription. What is the most likely cause?

A.Email notifications are disabled at the organization level.

B.The subscription is set to deliver only to the team members.

C.The subscription's 'Deliver to' filter excludes stakeholders.

D.The subscription was automatically disabled after the first notification.

AnswerC

The 'Deliver to' filter in an Azure DevOps notification subscription controls exactly which roles, groups, or individuals receive the alert. If stakeholders are omitted from that filter, they will not get any notifications from this subscription even though the subscription itself is active and functioning, which directly explains the symptom.

Why this answer

The most likely cause is that the custom notification subscription's 'Deliver to' filter is configured to exclude stakeholders. In Azure Boards, notification subscriptions can have filters that restrict delivery to specific groups or roles, and if stakeholders are not included in the filter, they will not receive notifications even if the subscription is active. This directly addresses the complaint that stakeholders are not getting notified about completed work items.

Exam trap

The trap here is that candidates might assume the issue is a global email disable or an automatic subscription expiry, rather than understanding that Azure Boards notification subscriptions rely on explicit filter configurations that can exclude specific roles like stakeholders.

How to eliminate wrong answers

Option A is wrong because if email notifications were disabled at the organization level, no one would receive any notifications, not just stakeholders, and the team would likely be aware of a global setting change. Option B is wrong because the subscription being set to deliver only to team members would explain why stakeholders don't receive notifications, but the question specifies a custom subscription with a 'Deliver to' filter, and the correct filter-based exclusion is more precise; however, the 'Deliver to' filter is the mechanism that controls who receives the notification, and excluding stakeholders is the direct cause. Option D is wrong because Azure Boards notification subscriptions are not automatically disabled after the first notification; they remain active until manually disabled or deleted, and there is no built-in behavior that disables subscriptions after a single delivery.

Full explanation →

587

MCQhard

Refer to the exhibit. A build pipeline produces the above logs. Which change would resolve the build failure?

A.Change the build configuration from Release to Debug.

B.Add a definition for 'MyMethod' in the 'MyClass' class.

C.Remove the '--no-build' flag from the test step.

D.Add the '--no-restore' flag to the build step.

AnswerB

The build error is a CS1061 compilation error: the C# compiler cannot find a member named 'MyMethod' on the type 'MyClass'. This means the calling code references a method that is not declared anywhere in the class definition. Adding a method with the exact name 'MyMethod' and a compatible signature (parameter list and return type) to the 'MyClass' class is the only way to satisfy the compiler. Without this addition, any downstream steps (like tests) will have no valid assembly to run.

Why this answer

The build failure is caused by a missing method definition. The logs indicate that the test step is attempting to invoke 'MyMethod' on an instance of 'MyClass', but the compiler cannot find it. Adding the missing method to the class resolves the compilation error, which is the root cause of the pipeline failure.

Exam trap

The trap here is that candidates may focus on build flags like '--no-build' or configuration settings, overlooking the actual compilation error message that clearly indicates a missing method definition.

How to eliminate wrong answers

Option A is wrong because switching from Release to Debug configuration does not fix a missing method; it only changes optimization and debug symbols. Option C is wrong because removing the '--no-build' flag would force a rebuild before tests, but the failure is a compilation error in the test project itself, not a stale build artifact. Option D is wrong because adding '--no-restore' skips NuGet package restore, which would likely cause additional dependency errors and does not address the missing method definition.

Full explanation →

588

MCQeasy

Your company is migrating to Microsoft Entra ID and needs to manage secrets used in Azure Pipelines. Which service should you use to securely store and rotate secrets?

A.Azure Key Vault

B.GitHub Secrets

C.Azure App Configuration

D.Microsoft Purview

AnswerA

Azure Key Vault is the Azure-native service for securely storing and managing secrets, keys, and certificates. It integrates directly with Azure Pipelines through service connections or variable groups, providing centralized access control, auditing, and rotation of secrets used in pipeline tasks.

Why this answer

Azure Key Vault is the correct service to securely store and rotate secrets used in Azure Pipelines. It is natively integrated with Azure Pipelines via library variable groups, allowing secrets to be referenced in pipelines without exposing them. Option B, GitHub Secrets, is designed for GitHub Actions, not Azure Pipelines.

Option C, Azure App Configuration, manages feature flags and configuration settings, not secrets. Option D, Microsoft Purview, is for data governance and compliance, not secret management.

Full explanation →

589

MCQmedium

Refer to the exhibit. You have a YAML pipeline that references a repository resource with a tag. When will this pipeline trigger?

A.When a new tag v1.0 is pushed to the referenced repository.

B.When changes are pushed to any branch of the referenced repository.

C.When changes are pushed to the main branch of the current repository.

D.The pipeline will never trigger because no trigger is defined.

AnswerC

The YAML pipeline defines a branch trigger with `branches.include: main` for the current repository, so any push to the main branch of that repository will automatically start the pipeline. This is the standard CI trigger behavior in Azure Pipelines.

Why this answer

By default, a YAML pipeline triggers on changes to the main branch of the repository where the pipeline definition resides, even when a repository resource with a tag is referenced. The tag in the repository resource only controls which version of the resource is used at runtime, not the trigger behavior. Without an explicit trigger section, the pipeline uses the default CI trigger on the main branch of the self-repo.

Exam trap

The trap here is that candidates assume a referenced repository resource with a tag will automatically trigger the pipeline on tag pushes, but Azure Pipelines does not trigger on resource changes unless a pipeline resource trigger is explicitly configured.

How to eliminate wrong answers

Option A is wrong because a tag push to the referenced repository does not trigger the pipeline unless a trigger is explicitly defined for tags (e.g., using `trigger: tags: include: ['v1.0']`). Option B is wrong because changes to any branch of the referenced repository do not trigger the pipeline; only changes to the main branch of the current repository trigger it by default. Option D is wrong because a default CI trigger exists for the main branch of the current repository when no trigger is defined, so the pipeline will trigger on pushes to that branch.

Full explanation →

590

MCQeasy

Your Azure DevOps pipeline uses a YAML template that defines variables. You want to override a variable value when running the pipeline manually. What is the best approach?

A.Create a variable group and link it to the pipeline.

B.Edit the template YAML file to hardcode the desired value.

C.Use the 'Variables' tab in the pipeline run UI to set a new value for the variable.

D.Define a parameter in the template and pass the value via the 'Override' parameter in the pipeline.

AnswerC

The pipeline run UI's Variables tab provides a runtime override mechanism specifically designed for this scenario: when you start a manual run, you can expand the 'Variables' section and enter a new value for a YAML-defined variable, and that value is used for that run only without modifying the repository. This works because YAML variables are evaluated at runtime (after the pipeline is triggered), so the override seamlessly replaces the default value defined in the template or pipeline. Crucially, this approach requires zero changes to version-controlled files and leaves the pipeline definition untouched, making it the intended, non-invasive method for ad-hoc manual overrides.

Why this answer

Azure Pipelines allows you to override the value of a YAML-defined variable directly in the pipeline run UI via the 'Variables' tab when manually triggering a run. This approach is the simplest and most flexible way to change a variable's value without modifying the YAML template or pipeline definition, and it supports runtime parameterization for manual runs.

Exam trap

The trap here is that candidates often confuse variables with parameters, assuming that parameters are the only way to pass values at runtime, but Azure Pipelines explicitly supports overriding YAML-defined variables via the UI without needing to convert them to parameters.

How to eliminate wrong answers

Option A is wrong because variable groups are used to manage sets of variables across pipelines, but they cannot override a variable already defined in a YAML template at runtime; they are linked at queue time and have lower precedence than variables set in the UI. Option B is wrong because hardcoding a value in the template YAML file defeats the purpose of dynamic override and requires a commit to the repository, which is not a runtime override mechanism. Option D is wrong because while parameters can be used to pass values into templates, there is no 'Override' parameter in Azure Pipelines; the correct way to pass a parameter value is via the pipeline run UI's 'Parameters' section (if defined as a parameter), but the question specifically asks about overriding a variable, not a parameter.

Full explanation →

591

MCQeasy

You have a YAML pipeline that builds a .NET application. You need to ensure that the pipeline uses the .NET SDK version 6.0.x. Which task should you add to the pipeline?

A.UseDotNet@2

B.NuGetToolInstaller@1

C.DotNetCoreCLI@2

D.PowerShell@2

AnswerA

UseDotNet@2 is the correct task because it explicitly installs a specified .NET Core/.NET SDK version on the build agent, making that SDK available for subsequent pipeline steps. It can also read a global.json to select the exact SDK version, ensuring the pipeline uses the intended toolset.

Why this answer

The UseDotNet@2 task is the correct choice because it explicitly installs a specific .NET SDK version (6.0.x) on the build agent, ensuring the pipeline uses the required SDK for building the .NET application. This task downloads and caches the SDK, making it available for subsequent tasks like DotNetCoreCLI@2.

Exam trap

The trap here is that candidates often confuse DotNetCoreCLI@2 (which runs .NET commands) with UseDotNet@2 (which installs the SDK), assuming the build task itself can set the SDK version, but DotNetCoreCLI@2 only uses whatever SDK is already available.

Why the other options are wrong

This installs NuGet, not the .NET SDK.

This runs .NET commands but does not install a specific SDK version.

PowerShell can install SDK but it's not the built-in task for this purpose.

Full explanation →

592

MCQhard

An organization uses Azure Repos with multiple Git repositories. They want to enforce that all commits to the main branch are signed using GPG keys. Which combination of actions is required to enforce commit signing?

A.Configure branch policy to require signed commits and have developers add their SSH public key to Azure Repos.

B.Configure repository settings to require a personal access token (PAT) for each commit.

C.Configure branch policy to require signed commits and have developers configure Git to sign commits with their GPG key.

D.Use Azure Key Vault to store signing keys and configure Azure Repos to automatically sign commits.

AnswerC

Azure Repos branch policies can enforce that every commit in a protected branch is signed, and developers must configure their local Git client to sign commits with a GPG key (e.g., set user.signingkey and commit.gpgsign=true). When a developer pushes a signed commit, Azure Repos verifies the GPG signature against the developer's configured public key, while the private key remains securely on the developer's machine.

Why this answer

Azure Repos supports a branch policy that requires commits to be signed, and developers must configure Git to sign commits with their GPG key using `git config --global user.signingkey` and `git commit -S`. This ensures that only signed commits are accepted into the main branch, enforcing non-repudiation and integrity.

Exam trap

The trap here is confusing authentication methods (SSH keys, PATs) with commit signing (GPG keys), leading candidates to select options that address access control rather than cryptographic integrity.

How to eliminate wrong answers

Option A is wrong because SSH public keys are used for authentication, not for signing commits; commit signing requires GPG keys, not SSH keys. Option B is wrong because a personal access token (PAT) is used for authentication to Azure Repos, not for signing commits; it does not enforce cryptographic signing. Option D is wrong because Azure Key Vault can store keys but Azure Repos does not automatically sign commits; signing must be performed client-side by the developer using Git.

Full explanation →

593

Matchingmedium

Match each YAML pipeline trigger to its behavior.

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

Concepts

Matches

Runs pipeline on code push

Runs pipeline on pull request creation

Runs pipeline at specified times

Runs pipeline after another pipeline completes

Why these pairings

In Azure Pipelines YAML, each trigger type has a distinct purpose: CI for push events, PR for pull requests, Schedules for cron-based runs, and Pipeline for cross-pipeline dependencies. Common confusions mix the behaviors of CI/PR or PR/Pipeline triggers.

Full explanation →

594

MCQeasy

Your team uses Azure DevOps and wants to automatically scan pull requests for secrets before they are merged. Which Azure DevOps feature should you use?

A.Azure Policy.

B.Secret scanning in Azure DevOps.

C.GitHub Advanced Security.

D.Branch policy with a required reviewer.

AnswerC

GitHub Advanced Security (GHAS) is a suite of security tools—including secret scanning, code scanning, and dependency review—that is tightly integrated with GitHub repositories, not with Azure Repos in Azure DevOps. Because GHAS secret scanning only works within the GitHub ecosystem and cannot be configured to scan Azure Repos, it is not applicable to this Azure DevOps pipeline scenario.

Why this answer

GitHub Advanced Security (GHAS) for Azure DevOps provides secret scanning that automatically detects secrets (e.g., API keys, passwords, connection strings) in pull requests before they are merged. This feature is integrated into Azure Repos when Advanced Security is enabled and triggers on PR creation, blocking the merge if secrets are found. Therefore, the correct choice is GitHub Advanced Security, not a separate 'Secret scanning in Azure DevOps' feature, which does not exist as a native built-in feature.

Exam trap

Candidates may confuse the built-in secret scanning with a standalone feature, but in Azure DevOps, secret scanning is only available through GitHub Advanced Security (which requires appropriate licensing).

How to eliminate wrong answers

Option A is wrong because Azure Policy is a governance tool for enforcing compliance rules on Azure resources (e.g., VM SKUs, resource locations), not for scanning code or pull requests for secrets. Option C is wrong because GitHub Advanced Security is a feature set for GitHub repositories (including secret scanning), but the question specifies Azure DevOps, which uses its own secret scanning feature, not GitHub Advanced Security. Option D is wrong because a branch policy with a required reviewer only mandates manual approval from a designated user; it does not perform automated secret scanning or content analysis.

Full explanation →

595

MCQeasy

You are setting up a new GitHub repository for a project that requires strict access control. Only specific team members should be able to push to the main branch, but all team members should be able to create branches and open pull requests. What is the best way to achieve this?

A.Add all team members as administrators of the repository.

B.Remove write permissions for non-core team members and give them read-only access.

C.Use a branch protection rule to restrict pushes to the main branch to specific users or teams.

D.Set the repository to private and invite only core team members.

AnswerC

A branch protection rule on the main branch can restrict direct pushes to specific users or teams, while still allowing branch creation and pull requests. This ensures that only authorized personnel can push to main, and all other changes must go through PR reviews, which directly addresses your requirement.

Why this answer

Branch protection rules in GitHub allow you to enforce restrictions on specific branches, such as requiring pull request reviews or restricting who can push directly. By configuring a rule for the main branch that limits push access to only designated users or teams, you ensure that all team members can create branches and open PRs, but only authorized members can merge into main. This directly meets the requirement without over-provisioning permissions or blocking collaboration.

Exam trap

The trap here is that candidates often confuse restricting push access with removing write permissions entirely, not realizing that branch protection rules allow granular control over specific branches while preserving write-level collaboration on other branches.

How to eliminate wrong answers

Option A is wrong because adding all team members as administrators grants them full control over the repository, including the ability to bypass any restrictions and push directly to main, which violates the strict access control requirement. Option B is wrong because removing write permissions for non-core members and giving them read-only access prevents them from creating branches or opening pull requests, which contradicts the requirement that all team members should be able to do so. Option D is wrong because setting the repository to private and inviting only core team members excludes non-core members entirely, preventing them from creating branches or opening pull requests, which is not the desired outcome.

Full explanation →

596

Drag & Dropmedium

Drag and drop the steps to troubleshoot a failed Azure DevOps release pipeline into the correct order.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

Troubleshooting starts with logs, then task identification, variable check, debug run, and fix.

Full explanation →

597

MCQeasy

You are configuring Application Insights for a .NET Core web application deployed to Azure App Service. The application must capture telemetry for all HTTP requests, exceptions, and dependency calls with minimal code changes. What should you do?

A.Enable the Application Insights site extension in the App Service 'Application Insights' blade.

B.Configure diagnostics logging in the App Service and stream logs to Application Insights.

C.Install the Microsoft.ApplicationInsights.AspNetCore NuGet package and add services.AddApplicationInsightsTelemetry() in Startup.cs.

D.Add the Application Insights JavaScript SDK to each page.

AnswerA

The Application Insights site extension in the App Service 'Application Insights' blade is the correct choice because it attaches the Application Insights agent directly to the App Service runtime, automatically collecting server-side telemetry such as requests, dependencies, exceptions, and performance counters without requiring any code changes, recompilation, or redeployment.

Why this answer

Enabling the Application Insights site extension via the App Service 'Application Insights' blade automatically instruments the .NET Core application without requiring any code changes. This extension injects the necessary telemetry modules to capture HTTP requests, exceptions, and dependency calls at the runtime level, leveraging the Azure App Service integration for zero-code instrumentation.

Exam trap

The trap here is that candidates often assume the NuGet package (Option C) is always required for .NET Core instrumentation, overlooking the zero-code site extension option that meets the 'minimal code changes' requirement more directly.

How to eliminate wrong answers

Option B is wrong because configuring diagnostics logging and streaming logs to Application Insights captures only platform-level logs (e.g., IIS logs, failed request tracing) and does not automatically capture application-level telemetry like dependency calls or exceptions without additional custom code. Option C is wrong because while installing the NuGet package and adding services.AddApplicationInsightsTelemetry() is a valid code-based approach, the question explicitly requires 'minimal code changes,' making the site extension (zero-code) the better choice. Option D is wrong because the JavaScript SDK is for client-side browser telemetry (page views, client exceptions), not for server-side HTTP requests, exceptions, or dependency calls in a .NET Core web application.

Full explanation →

598

MCQhard

You are designing a build pipeline that must run on Microsoft-hosted agents. The pipeline has a dependency on a native library that is not pre-installed. You want to minimize pipeline duration. Which approach should you use?

A.Use a container job with a custom Docker image that includes the library

B.Use a self-hosted agent with the library pre-installed

C.Add a script step to install the library using a package manager

D.Download the library from Azure Blob Storage in each build

AnswerA

Using a container job with a custom Docker image that includes the library allows the pipeline to run on Microsoft-hosted agents while avoiding the time needed to install the library in each run. This minimizes pipeline duration and meets the requirement.

Why this answer

Using a container job with a custom Docker image that includes the native library allows the pipeline to run on Microsoft-hosted agents while eliminating installation overhead, thus minimizing pipeline duration. This approach meets the requirement of using Microsoft-hosted agents and avoids the time cost of installing the library in each run.

Exam trap

Candidates may think self-hosted agents are required for pre-installed dependencies, but container jobs on Microsoft-hosted agents achieve the same benefit with less management overhead and still meet the requirement.

How to eliminate wrong answers

Option A is wrong because container jobs with custom Docker images still require pulling the image on each run, which adds significant time and does not leverage the pre-installed nature of a self-hosted agent. Option C is wrong because adding a script step to install the library using a package manager incurs runtime installation overhead, increasing pipeline duration. Option D is wrong because downloading the library from Azure Blob Storage in each build adds network transfer time and does not avoid the installation step, thus not minimizing duration.

Full explanation →

599

MCQhard

An organization uses Azure DevOps and wants to implement a change management process where all changes to the main branch require approval from a change advisory board (CAB). The CAB members are not part of the development team. How should they configure this?

A.Set branch permissions to restrict push to main and only allow CAB to approve via manual process.

B.Create a new branch policy on main that requires a minimum number of reviewers from a separate CAB group.

C.Use a service hook to notify CAB when a PR is created, and rely on manual approval.

D.Add the CAB as members of the development team and require team review.

AnswerB

A branch policy on main can require a minimum number of reviewers from a specific Azure DevOps group, such as a separate CAB. This ensures automated enforcement of the approval requirement, so pull requests cannot be completed without the mandated CAB reviews.

Why this answer

Azure DevOps branch policies allow you to enforce a minimum number of reviewers from a specific security group (e.g., a CAB group) on pull requests targeting the main branch. This ensures that every change to main requires explicit approval from CAB members, who are separate from the development team, without relying on manual processes or altering team membership.

Exam trap

The trap here is that candidates often confuse branch permissions (which control who can push) with branch policies (which control the review process), leading them to choose Option A instead of the correct policy-based solution.

How to eliminate wrong answers

Option A is wrong because restricting push permissions to main would block all direct pushes, but it does not enforce a review process; it would require a manual, non-auditable workflow outside Azure DevOps. Option C is wrong because a service hook only sends a notification when a PR is created; it does not enforce approval as a required gate, so changes could still be completed without CAB sign-off. Option D is wrong because adding CAB members to the development team would grant them unnecessary permissions and violate the requirement that CAB is separate from the development team; the team review policy would also apply to all team members, not specifically to CAB.

Full explanation →

600

MCQeasy

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

A.$(System.JobId)

B.$(System.TeamProject)

C.$(Build.BuildNumber)

D.$(Build.BuildId)

AnswerC

Build.BuildNumber is a human-readable, configurable build name that often includes non-alphanumeric characters like colons, dashes, or custom text. Docker tags must be lowercase alphanumeric and may contain only periods, underscores, and hyphens, so directly using BuildNumber risks invalid tags that fail the build unless the value is sanitized.

Why this answer

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

Exam trap

Candidates may confuse `Build.BuildNumber` (the human-readable build name) with `Build.BuildId` (the internal numeric ID). The stem explicitly says 'based on the build number', so `Build.BuildNumber` is the correct choice.

How to eliminate wrong answers

Option A is wrong because `$(System.JobId)` is a unique identifier for a specific job run within a pipeline, not the overall build number, and is not intended for image tagging. Option B is wrong because `$(System.TeamProject)` contains the name of the Azure DevOps project, which is static and does not provide a unique or incrementing value for tagging. Option C is wrong because `$(Build.BuildNumber)` is a user-defined or default formatted string (e.g., '20250401.1') that can contain non-numeric characters and is not guaranteed to be strictly incrementing or unique across parallel builds, making it less reliable for Docker tags than the integer `$(Build.BuildId)`.

Full explanation →

Microsoft Azure DevOps Engineer Expert AZ-400 (AZ-400) — Questions 526–600