Courseiva

Microsoft Azure DevOps Engineer Expert AZ-400 (AZ-400) — Questions 1–75

696 questions total · 10pages · All types, answers revealed

Take a mock examExam hub

Page 1 of 10

Page 2
1
MCQeasy

Your team uses GitHub for source control. You need to ensure that sensitive data, such as connection strings, is never committed to the repository. Which tool should you use?

A.GitHub Actions
B.Dependabot
C.Git Large File Storage (LFS)
D.GitHub secret scanning
AnswerD

GitHub secret scanning is the correct feature because it automatically scans repositories for known patterns of secrets, including connection strings, API keys, and authentication tokens. It alerts on detected secrets and can partner with secret providers to help prevent exposure, directly addressing the need to ensure secrets are not left in source control.

Why this answer

GitHub secret scanning automatically detects sensitive data like connection strings, API keys, and tokens as they are pushed to a repository, preventing them from being committed. It scans for known patterns and can block the push or alert the repository administrator, making it the correct tool for this requirement.

Exam trap

The trap here is that candidates often confuse secret scanning with Dependabot (which handles dependency vulnerabilities, not secrets) or assume GitHub Actions can be scripted to scan for secrets, but secret scanning is a dedicated, built-in feature that operates at the push level without requiring workflow configuration.

How to eliminate wrong answers

Option A is wrong because GitHub Actions is a CI/CD automation platform for building, testing, and deploying code, not a tool for scanning or blocking sensitive data in commits. Option B is wrong because Dependabot is used for automated dependency updates and security vulnerability alerts, not for detecting secrets or connection strings in source code. Option C is wrong because Git LFS is designed to handle large binary files by replacing them with text pointers, not for scanning or preventing sensitive data from being committed.

Full explanation →
2
MCQeasy

A development team uses Git for source control. They want to ensure that all code changes are reviewed before merging into the main branch. Which branch policy should they configure in Azure Repos?

A.Configure a branch policy that requires a minimum number of reviewers and resolves all comments.
B.Configure a branch policy that requires commit messages to follow a specific pattern.
C.Configure a branch policy that requires a successful build.
D.Configure a branch policy that requires linked work items.
AnswerA

This branch policy enforces mandatory peer review by requiring at least a specified number of reviewers to approve the pull request, and also requires that all comment threads be resolved before merging. This ensures that code is reviewed by multiple team members before integration, directly serving the goal of ensuring peer review.

Why this answer

Azure Repos branch policies allow you to enforce that pull requests require a minimum number of reviewers and that all comments are resolved before merging. This directly ensures that all code changes are reviewed and any feedback is addressed, meeting the team's requirement for mandatory code review before merging into the main branch.

Exam trap

The trap here is that candidates may confuse 'code review' with other quality gates like build validation or work item linking, but the question explicitly asks for a policy that ensures all changes are reviewed before merging, which is directly addressed only by reviewer and comment resolution policies.

How to eliminate wrong answers

Option B is wrong because requiring commit messages to follow a specific pattern enforces formatting conventions, not code review. Option C is wrong because requiring a successful build ensures code quality and integration, but does not mandate human review of the changes. Option D is wrong because requiring linked work items enforces traceability to tasks or user stories, not a code review process.

Full explanation →
3
MCQhard

Your organization uses GitHub Actions for CI/CD. You need to ensure that secrets stored in GitHub are not exposed in logs. A developer reports that a secret value appeared in the workflow run log. What is the most likely reason?

A.The workflow was triggered via repository_dispatch.
B.The secret was printed using a script that bypassed automatic masking.
C.The secret name was used in the log output.
D.The workflow used 'debug' log level.
AnswerB

Correct: When a script or action writes a secret value to stdout in a format that GitHub's log redaction does not recognize—for example, by printing it in base64, with escaped characters, or through an intermediate environment variable that is not pre-registered as a secret—the automatic masking may fail and expose the value. GitHub masks secrets that appear verbatim in the log, but only if the exact string is seen; any transformation bypasses that protection.

Why this answer

GitHub Actions automatically masks secrets in logs by replacing their values with '***', but this masking can be bypassed if a script transforms the secret (e.g., base64 encoding, splitting, or printing it in a way that changes its exact string) before outputting it. The most likely reason a secret value appeared in the log is that the script printed it in a form that bypassed the automatic masking. This is a known limitation of GitHub's secret masking.

Exam trap

AZ-400 often tests the misconception that GitHub Actions masks secrets in all cases, when in fact masking can be bypassed by transforming the secret value before printing.

How to eliminate wrong answers

Option A is wrong because triggering a workflow via repository_dispatch does not affect secret masking; secrets are still masked regardless of trigger type. Option C is wrong because using the secret name (not its value) in log output is safe — masking applies to the value, not the name. Option D is wrong because enabling debug logging does not disable secret masking; GitHub still masks secrets even in debug logs, though debug logs may reveal more context.

Full explanation →
4
MCQeasy

Your organization is adopting GitHub Copilot and wants to ensure that no proprietary code is used to train models. Which setting should you configure in the GitHub organization?

A.Enable secret scanning.
B.Enable Dependabot alerts.
C.Disable GitHub Copilot for the organization.
D.Opt out of allowing GitHub to use code snippets for product improvement.
AnswerD

Opting out of allowing GitHub to use code snippets for product improvement is the exact setting that prevents Copilot from using your code as training data. This is the correct action when you want to retain Copilot's functionality while ensuring your proprietary code is not used to improve the model.

Why this answer

GitHub provides an organization-level setting to opt out of allowing GitHub to use code snippets for product improvement, which prevents Copilot from training on that code. Option A is incorrect because secret scanning is unrelated to model training. Option B is incorrect because Dependabot alerts focus on dependency vulnerabilities, not data usage.

Option C is incorrect because disabling Copilot prevents its use but does not address the underlying data usage for training; the organization may still want to use Copilot while preventing training on proprietary code.

Full explanation →
5
MCQeasy

You are using Azure Pipelines to deploy a function app. You need to automatically roll back the deployment if the post-deployment smoke tests fail. What should you do?

A.Add a stage that runs only when the previous stage fails, executing a rollback script.
B.Configure the pipeline to retry the deployment on failure.
C.Use a pre-deployment approval gate to validate the build before deployment.
D.Set up a manual validation gate that requires operations to initiate a rollback.
AnswerA

In Azure Pipelines, you can define a conditional stage using the `condition: failed()` expression on the deployment stage. This stage runs only when the preceding stage fails, allowing you to execute a rollback script that reverts the function app to its previous healthy version. This approach automates the rollback process, ensuring immediate recovery without manual intervention.

Why this answer

Azure Pipelines supports conditional stage execution using expressions like `eq(variables['Build.Reason'], 'IndividualCI')` or `failed()`. By adding a stage that runs only when the previous deployment stage fails (e.g., `condition: failed()`), you can execute a rollback script that reverts the function app to its previous stable version. This ensures automatic rollback upon smoke test failure without manual intervention.

Exam trap

The trap here is that candidates confuse automatic rollback with retry logic or manual gates, failing to recognize that Azure Pipelines' conditional stage execution (`failed()`) is the native mechanism to trigger a rollback stage automatically when smoke tests fail.

How to eliminate wrong answers

Option B is wrong because retrying the deployment on failure does not roll back; it simply re-attempts the same failing deployment, which will likely fail again if the underlying issue persists. Option C is wrong because a pre-deployment approval gate validates the build before deployment, not after; it cannot detect or respond to post-deployment smoke test failures. Option D is wrong because a manual validation gate requires human approval to proceed, but it does not automatically trigger a rollback; it pauses the pipeline and relies on an operator to manually initiate rollback, which contradicts the requirement for automatic rollback.

Full explanation →
6
MCQhard

You are analyzing Azure DevOps audit logs with the KQL query above. Your security team wants to ensure that only approved service connections are used. After running the query, you find multiple service connections created by a user who is not on the approved list. What should you do next?

A.Immediately delete all service connections created by that user.
B.Disable the user's account in Microsoft Entra ID.
C.Review each unapproved service connection's permissions and usage.
D.Modify the query to also include the user's email address.
AnswerC

Reviewing each unapproved service connection's permissions and usage is the correct response because it enables you to determine whether the connection is malicious, misconfigured, or a legitimate access grant that requires tracking. By examining scopes, used-by pipelines, and activity logs, you can assess risk and decide which connections to revoke, modify, or leave in place with proper oversight.

Why this answer

The immediate priority is to assess the risk of each unapproved service connection before taking action. Service connections in Azure DevOps can have varying permissions and may be used by pipelines, so blindly deleting them could break critical deployments. The correct next step is to review each connection's permissions (e.g., who can use it, which service principals are linked) and its usage history (e.g., which pipelines reference it) to determine whether it is malicious or simply an oversight.

Exam trap

The trap here is that candidates often jump to a punitive action (deleting connections or disabling accounts) instead of following a structured incident response process that first investigates and validates the risk before taking corrective measures.

How to eliminate wrong answers

Option A is wrong because immediately deleting all service connections created by that user could disrupt running pipelines and deployments, and it bypasses the necessary investigation to confirm whether any of those connections are legitimate or approved for specific use cases. Option B is wrong because disabling the user's account in Microsoft Entra ID is a drastic measure that may be premature; the user might have created connections with proper authorization for a different project, and disabling the account could block other legitimate work without addressing the specific service connections. Option D is wrong because modifying the query to include the user's email address does not resolve the security concern; it only provides more information for analysis, but the question asks what to do next after finding unapproved connections, not how to improve the query.

Full explanation →
7
MCQmedium

Refer to the exhibit. A developer pushes a new commit to an existing pull request targeting the main branch. What is the effect on the pull request?

A.The pull request is automatically merged.
B.The existing approvals remain valid, and no re-review is needed.
C.All existing approvals are revoked, and the pull request must be re-approved.
D.The new commit is rejected because it was pushed without a code review.
AnswerC

With the reset-approvals policy enabled, all previously granted approvals are revoked as soon as a new commit is pushed to the source branch, requiring reviewers to re-approve the latest changes before the pull request can be merged.

Why this answer

The policy 'Reset code reviewer votes when new changes are pushed' is set to true. Therefore, when a new commit is pushed, all previous reviewer votes are reset. The required number of reviewers is 2, but minimum is 1, so at least one reviewer must approve again.

Full explanation →
8
MCQhard

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

A.Create two separate workflows: one for CI (build, test, deploy staging) and one for CD (deploy production) that triggers manually.
B.Use a single workflow with a step that deploys to staging and then to production, using a condition to require manual approval via GitHub Issues.
C.Create a single GitHub Actions workflow with multiple jobs. Use a job for build and test, then a job for deploy to staging, and a job for deploy to production with an environment that requires approval.
D.Use Azure Pipelines with a multi-stage YAML pipeline that includes a stage for staging and a stage for production with pre-deployment approvals.
AnswerC

The correct approach defines one workflow with three jobs: build/test, deploy to staging, and deploy to production; the production job references an environment configured with required reviewers, which automatically pauses the job until approval is granted. This gives a native audit trail and allows environment-specific secrets to be used safely.

Why this answer

The correct approach is to create a single GitHub Actions workflow with multiple jobs: one for build and test, one for deploy to staging, and one for deploy to production that uses a GitHub Environment with required reviewers. This allows automatic deployment to staging on push to main, and manual approval for production. The official Azure actions (e.g., azure/functions-action) can be used.

Option C is the only one that meets all requirements.

Exam trap

AZ-400 often tests the use of GitHub Environments for approvals versus other approval mechanisms like GitHub Issues or Azure Pipelines approvals; candidates might choose separate workflows or Azure Pipelines, but the question specifies GitHub Actions and manual approval via GitHub Environments.

How to eliminate wrong answers

Option A is wrong because it uses two separate workflows and triggers production manually, which does not automatically promote after staging and lacks the integrated approval via GitHub Environments. Option B is wrong because it uses GitHub Issues for approval, not GitHub Environments, and does not separate jobs for clarity. Option D is wrong because it uses Azure Pipelines instead of GitHub Actions, which does not meet the requirement to use GitHub Actions and official Azure actions.

Full explanation →
9
MCQhard

You are a DevOps engineer at a company that uses Azure DevOps. The security team requires that all code commits to the main branch are signed and verified. You need to enforce this using branch policies. Which policy should you configure?

A.Require approval from a specific user or group.
B.Require a minimum number of reviewers.
C.Check for linked work items.
D.Require signed commits.
AnswerD

The 'Require signed commits' branch policy ensures that all commits pushed to the protected branch have a valid GPG or SSH signature. This directly enforces that commits are signed and verified, meeting the security team's requirement. It prevents unsigned commits from being merged, ensuring integrity and authenticity.

Why this answer

The 'Require signed commits' branch policy is the only policy that enforces cryptographic signing of commits. It ensures that every commit to the protected branch is signed and verified, providing authenticity and integrity. Other policies focus on review, work item linking, or approvals, none of which verify signatures.

Exam trap

The trap here is confusing commit signing with other branch policies that provide security, such as required reviewers or linked work items, but these do not verify signatures.

Full explanation →
10
Multi-Selecthard

Your build pipeline uses a YAML template that references variables from a variable group. The variable group is linked to a library. You need to ensure that sensitive variables are not exposed in logs. Which THREE actions should you take?

Select 3 answers
A.Set the variable group to 'Allow access to all pipelines'.
B.Store the secrets in Azure Key Vault and reference them in the variable group.
C.Use 'Write-Host' to output the variable values for debugging.
D.Mark the variables as 'secret' in the variable group.
E.Configure permissions on the library to restrict which pipelines can use the variable group.
AnswersB, D, E

Storing secrets in Azure Key Vault and referencing them via a variable group is the recommended secure approach, as Azure DevOps retrieves these values at runtime and automatically masks them in logs. It enables centralized secret rotation, access policies, and auditing without storing sensitive data in the pipeline definition itself.

Why this answer

To keep sensitive variables out of pipeline logs, you should store secrets in Azure Key Vault and reference them in a variable group (B), mark variables as secret in the variable group (D), and configure permissions on the library to restrict which pipelines can use the variable group (E). Key Vault integration and secret marking ensure that values are masked automatically, while restricting access limits the risk of unauthorized pipelines that could expose secrets.

Exam trap

Candidates may incorrectly think that allowing access to all pipelines is harmless or that explicitly writing secret values to logs with Write-Host is safe. In reality, both actions can expose sensitive data. Restricting library permissions is a key security measure to prevent unauthorized pipeline access.

Full explanation →
11
MCQmedium

You have an Azure Pipelines YAML file with the following trigger configuration: ```yaml trigger: branches: include: - main paths: include: - /src/* ``` The team reports that the pipeline does not trigger when changes are pushed to the main branch that modify files outside the /src folder. What is the most likely reason?

A.The path filter restricts the trigger to only changes in /src/.
B.The trigger syntax is incorrect; 'branch' should be 'branches'.
C.The script step is missing a display name.
D.The pool vmImage is not specified correctly.
AnswerA

The path filter in the trigger uses the 'paths' keyword with an 'include' clause, which restricts the pipeline to run only when changes are made to files under the /src/ directory. Any commits affecting other paths, such as the root or documentation, will not trigger the pipeline, making this statement correct.

Why this answer

The most likely reason is that a path filter is configured in the trigger, restricting the pipeline to only trigger on changes under /src/. The other options are incorrect because they either refer to minor syntax issues or irrelevant details.

Exam trap

The trap is that candidates may overlook the path filter's restrictive behavior and instead focus on minor syntax details like 'branch' vs 'branches', missing that the core issue is the include pattern limiting triggers to only the /src folder. Without seeing the exhibit, it's essential to recognize that path filters are the most likely cause.

How to eliminate wrong answers

Option B is wrong because 'branch' is actually a valid property in the trigger block (though 'branches' is also accepted as an alias), and the syntax shown is correct for specifying branch filters; the issue is not with the branch property but with the path filter. Option C is wrong because a missing display name on a script step does not affect pipeline triggering; it only affects the UI label in pipeline runs. Option D is wrong because the pool vmImage specification (e.g., 'ubuntu-latest') is syntactically correct and does not impact trigger behavior; it only defines the build agent environment.

Full explanation →
12
MCQmedium

Refer to the exhibit. You monitor an Azure App Service web app. At 10:30 AM, you observe a spike in HTTP 5xx errors and response time. Based on the metrics, what is the most likely cause?

A.The web app reached its scaling limit and could not handle the increased load.
B.A deployment of new code at 10:30 AM introduced a bug.
C.A DDoS attack started at 10:30 AM.
D.A database outage caused the errors and slow responses.
AnswerA

The correct explanation is that the App Service plan reached its maximum configured instance count, causing a capacity bottleneck. As request volume steadily increased throughout the morning, CPU/RAM utilization and the request queue grew until hitting the scaling ceiling at 10:30 AM. At that point, the service could not spawn additional instances, and Azure began responding with HTTP 500/503 errors and severe latency, which matches the sharp degradation in the exhibit.

Why this answer

The request count increased gradually from 1200 to 2500 before the errors started at 10:30 AM. The sharp rise in errors and response time coinciding with peak load indicates the app reached its capacity limit (e.g., instance count or plan limits).

Full explanation →
13
MCQmedium

You are designing a build pipeline for a Python application that uses Anaconda environments. The pipeline must create a Conda environment, install dependencies, and run tests. The pipeline should also cache the Conda environment to speed up subsequent builds. Which configuration should you use?

A.Use the 'UsePythonVersion' task with a version spec, and add a script to create the Conda environment.
B.Use a Docker container with Anaconda pre-installed and run the pipeline inside the container.
C.Use the 'CondaEnvironment' task to create the environment, and use the 'Cache' task to cache the Conda packages folder.
D.Use a script to run 'conda create' and 'conda install', and manually cache the environment by specifying a path.
AnswerC

The 'CondaEnvironment' task is specifically designed to create a Conda environment from a YAML file or package specification, ensuring the environment is set up correctly and integrated with the pipeline. Pairing it with the 'Cache' task to cache the Conda packages folder (typically 'pkgs') reduces re-download overhead and speeds up subsequent runs.

Why this answer

The 'CondaEnvironment' task is purpose-built for creating and updating Conda environments from an environment.yml file, and combining it with the 'Cache' task to cache the Conda packages folder (typically `$(Pipeline.Workspace)/conda_pkgs`) significantly reduces build time by avoiding re-downloading packages on subsequent runs. This approach aligns with Azure DevOps best practices for dependency caching and Conda environment management.

Exam trap

The trap here is that candidates often assume manual scripting (Option D) is more flexible or that Docker (Option B) is always the best isolation strategy, but they overlook the purpose-built 'CondaEnvironment' task and its seamless integration with the 'Cache' task for efficient, maintainable pipelines.

How to eliminate wrong answers

Option A is wrong because the 'UsePythonVersion' task is designed for standard Python installations (e.g., from the Microsoft-hosted agent's Python versions), not for managing Conda environments; it cannot create or activate Conda environments, and it lacks caching capabilities. Option B is wrong because using a Docker container with Anaconda pre-installed adds unnecessary complexity and overhead (e.g., image build/pull time, volume mounts) and does not natively integrate with Azure DevOps caching tasks for Conda packages; it also bypasses the simplicity of the built-in CondaEnvironment task. Option D is wrong because manually scripting 'conda create' and 'conda install' is error-prone (e.g., missing environment activation, inconsistent environment names) and manually caching by specifying a path requires extra boilerplate code to handle cache keys and restore logic, whereas the CondaEnvironment task and Cache task provide a standardized, tested solution.

Full explanation →
14
MCQhard

Your organization requires that all code changes must be built and tested before merging to the main branch. You plan to use branch policies in Azure Repos. Which policy enforcement will ensure that a pull request cannot be completed unless the build succeeds?

A.Require a linked work item in the pull request.
B.Require a minimum number of reviewers.
C.Add a build validation policy that triggers a build on each PR update.
D.Reset code reviewer votes when new changes are pushed.
AnswerC

Adding a build validation policy queues a build on every pull request update and blocks completion unless the build succeeds. This directly enforces that all code changes are built successfully before merging, preventing broken code from entering the target branch.

Why this answer

Azure Repos branch policies include a 'Build validation' policy that triggers a specified build pipeline on each pull request (PR) update. The policy enforces that the PR cannot be completed unless the build succeeds, directly meeting the requirement that all code changes must be built and tested before merging to the main branch.

Exam trap

The trap here is that candidates may confuse a 'build validation' policy with other branch policies like 'Require a linked work item' or 'Minimum number of reviewers', thinking any policy that adds a check will enforce build success, but only build validation directly triggers and gates on a build pipeline result.

How to eliminate wrong answers

Option A is wrong because requiring a linked work item ensures traceability but does not enforce any build or test execution. Option B is wrong because requiring a minimum number of reviewers enforces peer review but does not trigger or validate a build. Option D is wrong because resetting code reviewer votes when new changes are pushed ensures re-review but does not enforce build success before merge.

Full explanation →
15
Multi-Selectmedium

Which TWO actions should you take to ensure that your Azure DevOps pipeline securely manages secrets?

Select 2 answers
A.Use Azure Key Vault variable groups
B.Enable 'Allow scripts to access the system token' and print secrets in logs for debugging
C.Store secrets directly in the YAML pipeline file
D.Use secret variables set in the pipeline UI or variable groups
E.Store secrets as plain text in the repository
AnswersA, D

Azure Key Vault variable groups securely store secrets in Azure Key Vault and link them to pipelines via variable group metadata, enabling pipelines to fetch secrets at runtime without writing them into YAML or repository files; access is governed by Azure RBAC and Key Vault access policies.

Why this answer

Option A is correct because linking an Azure Key Vault to a variable group lets the pipeline fetch secrets at runtime from Key Vault, so the secret values are never stored in the pipeline definition and access is governed by Key Vault access policies or RBAC. Option D is correct because secret variables defined in the pipeline UI or in variable groups are encrypted at rest by Azure DevOps, masked in logs, and not exposed in the YAML source, which is the supported way to hold secrets the pipeline needs directly. Option B is wrong because enabling scripts to access the system token and printing secrets to logs deliberately exposes credentials, defeating masking and enabling token theft.

Option C is wrong because secrets committed in the YAML pipeline file are stored in source control in plain text and visible to anyone with repo access. Option E is wrong because storing secrets as plain text in the repository exposes them to all readers of the repo and to its history, with no encryption or masking.

Exam trap

AZ-400 often tests the temptation to 'debug' by printing secrets or storing them in YAML — candidates must recognize that only Key Vault variable groups and UI-defined secret variables are secure.

Full explanation →
16
MCQmedium

Your company uses GitHub Enterprise for source control and GitHub Actions for CI/CD. The development team is distributed across three time zones. You are designing a process to improve communication and collaboration for code reviews. The team currently uses email notifications for pull request reviews, which often get missed. You want to implement a more efficient system that integrates with Microsoft Teams and provides real-time updates. Additionally, you need to ensure that critical pull requests (e.g., those affecting production) are escalated if not reviewed within 4 hours. You also want to automatically assign reviewers based on the files changed. Which combination of actions should you take?

A.Use a GitHub App (e.g., Pull Request Assigner) to automatically assign reviewers based on file patterns. Create a GitHub Action that sends a message to Microsoft Teams via webhook when a pull request is opened. Set up a second GitHub Action that runs every hour and checks pull request age, sending an escalation to Teams if older than 4 hours.
B.Use GitHub's built-in code owners feature to automatically request reviews based on file patterns. Create a GitHub Action that posts a notification to Microsoft Teams via webhook when a pull request is opened. For escalation, create a scheduled workflow (e.g., using cron) that runs every 30 minutes to identify pull requests older than 4 hours and sends an alert to Teams.
C.Configure GitHub branch protection rules to require pull request reviews. Create a Microsoft Teams webhook connector and add it to the repository to post notifications. Instruct team leads to manually tag reviewers based on file changes.
D.Use a third-party service like PullRequest.com to manage code reviews. Configure GitHub Actions to send notifications to Teams. For escalation, use a GitHub Action that triggers on pull request review request and uses conditional logic to escalate after 4 hours.
AnswerB

This is the correct approach because CODEOWNERS natively assigns reviewers automatically based on file patterns (e.g., requiring the frontend team for .tsx changes), which is reliable and free. A GitHub Action triggered on pull_request opened sends an immediate webhook notification to Microsoft Teams, giving the team instant visibility. For escalation, a scheduled workflow using cron (e.g., every 30 minutes) queries open pull requests and alerts Teams for any PR older than 4 hours, providing timely detection without constant polling or wasted CI minutes. This combination leverages built-in GitHub features, avoids external services, and ensures stale reviews are automatically escalated.

Why this answer

It uses GitHub's built-in code owners feature for automatic reviewer assignment based on file patterns, which is native and requires no third-party app. It then uses a GitHub Action with a webhook to post real-time notifications to Microsoft Teams when a pull request is opened. For escalation, a scheduled workflow (cron) running every 30 minutes checks pull request age and sends an alert to Teams if older than 4 hours, meeting the real-time and escalation requirements without manual intervention.

Exam trap

The trap here is that candidates may choose Option A because it seems comprehensive, but they overlook that GitHub's built-in code owners feature is the recommended and simpler approach for automatic reviewer assignment, and that a scheduled workflow (cron) is necessary for time-based escalation rather than relying on event-driven triggers.

How to eliminate wrong answers

Option A is wrong because it relies on a third-party GitHub App (Pull Request Assigner) instead of GitHub's native code owners feature, which is simpler and more maintainable; also, checking pull request age every hour may miss the 4-hour escalation window if the check runs at the wrong interval. Option C is wrong because it requires manual tagging of reviewers based on file changes, which is inefficient and error-prone for a distributed team; it also lacks automated escalation for critical pull requests. Option D is wrong because it uses a third-party service (PullRequest.com) for code reviews, which adds unnecessary complexity and cost; the escalation approach using a GitHub Action triggered on review request with conditional logic is not reliable for time-based escalation because it only fires on events, not on a schedule, and cannot detect pull requests that have not been reviewed after 4 hours.

Full explanation →
17
Multi-Selecteasy

Your organization uses GitHub and wants to automatically assign pull request reviewers based on the files changed. Which three steps should you take?

Select 3 answers
A.Configure 'Code owner review requirement' in branch protection.
B.Create a CODEOWNERS file in the repository defining teams for file patterns.
C.Enable 'Require pull request reviews before merging' branch protection rule.
D.Enable 'Protected branches' for the main branch.
E.Configure team synchronization for the organization.
AnswersA, B, C

Enabling 'Code owner review requirement' under branch protection mandates that any pull request modifying files with designated code owners must receive an approving review from at least one of those owners before merging. This setting enforces the approval from the exact responsible party, making it the correct automatic review-assignment mechanism.

Why this answer

Configuring 'Code owner review requirement' in branch protection enforces that pull requests affecting files with defined code owners must be approved by those owners before merging. This ensures that changes to specific file patterns automatically require review from the designated teams or individuals, aligning with the goal of automatic assignment based on files changed.

Exam trap

The trap here is that candidates may confuse 'Require pull request reviews before merging' (which only requires any reviewer approval) with 'Code owner review requirement' (which specifically requires approval from the code owner defined in CODEOWNERS), leading them to think option C alone is sufficient without the CODEOWNERS file and the code owner enforcement.

Full explanation →
18
MCQhard

Your organization uses Azure Pipelines to build a large monolithic application. The build takes over 60 minutes. Management wants to reduce the build time to under 30 minutes. The application has multiple independent modules that could be built in parallel. What is the most effective strategy to reduce build time?

A.Reduce the number of unit tests run during the build.
B.Upgrade the build agent to a larger VM size with more CPU and memory.
C.Move the build to a self-hosted agent in the same network as the source code repository.
D.Refactor the build pipeline to use multiple parallel jobs, each building a separate module.
AnswerD

A monorepo with independent modules can be split into multiple parallel jobs, each building a separate module on its own agent; this leverages true concurrency to reduce overall wall-clock time, provided you correctly manage inter-module dependencies and publish artifacts for downstream consumption.

Why this answer

The build time is dominated by sequential compilation of independent modules. By refactoring the pipeline to use multiple parallel jobs, each building a separate module, Azure Pipelines can leverage its built-in parallelism to reduce wall-clock time significantly. This directly addresses the root cause—lack of concurrency—without sacrificing code quality or infrastructure cost.

Exam trap

The trap here is that candidates often choose 'upgrade the build agent' (Option B) because they assume more CPU/RAM will linearly speed up compilation, but for a build with many independent modules, the real bottleneck is sequential execution; adding parallelism yields the greatest reduction. Hardware upgrades may help somewhat but do not remove the sequential dependency.

How to eliminate wrong answers

Option A is wrong because reducing unit tests may compromise code quality and does not address the core issue of sequential module compilation; tests typically run after compilation and are not the primary bottleneck in a 60-minute build. Option B is wrong because upgrading to a larger VM size provides only linear CPU/memory improvements, which cannot reduce build time by half if the build is I/O-bound or constrained by sequential dependencies; parallel execution is far more effective. Option C is wrong because moving to a self-hosted agent in the same network as the source repository reduces network latency but does not change the sequential build process; the bottleneck is compilation time, not network transfer.

Full explanation →
19
Multi-Selecteasy

Which TWO tasks can be used to run unit tests in an Azure Pipeline?

Select 2 answers
A.DotNetCoreCLI@2
B.VSTest@2
C.NuGetCommand@2
D.PublishBuildArtifacts@1
E.CopyFiles@2
AnswersA, B

DotNetCoreCLI@2 runs the `dotnet test` command, which discovers and executes unit tests in .NET Core and .NET 5+ projects using the dotnet test runner, supporting VSTest and xUnit/NUnit/MSTest adapters via the `command: test` and `arguments` inputs.

Why this answer

The DotNetCoreCLI@2 task can run unit tests for .NET Core and .NET 5+ projects by invoking the 'dotnet test' command, which discovers and executes tests in the specified project files. The VSTest@2 task runs unit tests using the Visual Studio Test Runner, supporting a wide range of test frameworks (MSTest, xUnit, NUnit) and can run tests from assemblies or test containers. Both tasks are designed specifically for executing unit tests within an Azure Pipeline, making them the correct choices.

Exam trap

The trap here is that candidates may confuse tasks that are part of the build process (like NuGetCommand or CopyFiles) with tasks that actually execute tests, or assume that any task with 'Test' in its name (like VSTest) is the only correct option, overlooking DotNetCoreCLI@2 which also runs tests via 'dotnet test'.

Full explanation →
20
MCQhard

Your organization uses Azure DevOps with multiple teams. You are tasked with creating a security and compliance plan. The environment includes: Azure Repos for source control, Azure Pipelines for CI/CD, and Azure Artifacts for package management. Requirements: 1) All code changes to the main branch must be reviewed by at least one member of the security team. 2) Deployment to production requires approval from a manager. 3) Secrets must be stored securely and rotated every 90 days. 4) Pipeline logs must be retained for 1 year for audit purposes. You have configured branch policies requiring a minimum number of reviewers and mandatory security team review. For production deployments, you have added a manual approval gate. Secrets are stored in Azure Key Vault with automatic rotation. However, the audit team reports that pipeline logs are only retained for 30 days. You need to extend log retention to 1 year. What should you do?

A.Export pipeline logs to Azure Blob Storage and set a lifecycle policy to retain for 365 days.
B.Configure diagnostic settings in Azure Monitor to stream pipeline logs to a Log Analytics workspace.
C.In Azure DevOps project settings, navigate to Pipelines > Retention and releases, and set the retention policy to 365 days.
D.Enable Azure DevOps audit logs and export them to a Log Analytics workspace with a 365-day retention.
AnswerC

To retain pipeline logs for 365 days, use the project-level retention policy under Project Settings > Pipelines > Retention and releases, setting the maximum retention for pipeline runs and logs to the desired number of days.

Why this answer

In Azure DevOps, pipeline retention policies for runs are configured at the project level under Project Settings > Pipelines > Retention and releases. Setting the retention to 365 days will keep pipeline run records and logs for one year. Option A is incorrect because exporting pipeline logs to Azure Blob Storage is not a built-in feature; pipeline logs are retained according to DevOps retention policies.

Option B is incorrect because diagnostic settings in Azure Monitor stream Azure resource logs, not Azure DevOps pipeline logs. Option D is incorrect because audit logs capture events like changes to policies, not pipeline execution logs, and they have separate retention settings.

Full explanation →
21
Multi-Selectmedium

Your company uses Azure Key Vault to store secrets. Which TWO actions should you take to ensure secure access? (Select TWO.)

Select 2 answers
A.Restrict access using Key Vault access policies
B.Use managed identities to authenticate applications
C.Enable HTTP access for performance
D.Disable audit logging to reduce exposure
E.Enable soft-delete to recover deleted secrets
AnswersA, B

Restrict access using Key Vault access policies: Access policies are evaluated for each principal, allowing fine-grained permissions such as get, list, and set on secrets, certs, and keys. By assigning only the minimum required permissions to each user, group, or service principal, you implement least privilege and directly reduce the attack surface for unauthorized secret access.

Why this answer

Restricting access using Key Vault access policies (Option A) is correct because Azure Key Vault uses a granular permission model where you assign specific permissions (e.g., GET, LIST, SET) to individual security principals (users, groups, or service principals) at the vault level. This ensures that only authorized identities can read or manage secrets, keys, and certificates, following the principle of least privilege. Using managed identities (Option B) is correct because they provide an automatically managed identity in Azure AD for applications to authenticate to Key Vault without storing credentials in code or configuration, eliminating the risk of secret leakage.

Exam trap

The trap here is that candidates often confuse data protection features (like soft-delete) with access control mechanisms, or mistakenly think enabling HTTP improves performance without realizing Key Vault enforces HTTPS exclusively, leading them to select options that address recovery or monitoring rather than secure authentication and authorization.

Full explanation →
22
MCQeasy

Your team uses GitHub for source control and Azure Pipelines for CI/CD. You need to ensure that only pull requests from specific branches trigger a build pipeline. Which trigger configuration should you use?

A.pr: paths: include: - main - develop
B.pr: branches: only: - main
C.trigger: branches: include: - main - develop
D.pr: branches: include: - main - develop
AnswerD

This is the correct YAML syntax for filtering PR triggers by target branch. The `pr` keyword enables PR validation, and `branches: include` specifies that only PRs targeting `main` or `develop` should be built, ensuring the pipeline runs only for those branches.

Why this answer

The `pr` trigger in Azure Pipelines controls which pull requests trigger a pipeline. By using `branches` with `include`, you specify that only PRs targeting the `main` and `develop` branches should trigger the build. This directly meets the requirement to restrict PR triggers to specific branches.

Exam trap

The trap here is confusing `pr` triggers (for pull requests) with `trigger` triggers (for CI builds on commits), leading candidates to select option C which targets commits instead of PRs.

How to eliminate wrong answers

Option A is wrong because `paths` filters changes by file paths, not branches; it would still trigger on PRs to any branch if the specified paths are modified. Option B is wrong because `only` is not a valid keyword under `pr.branches`; the correct syntax uses `include` and `exclude`. Option C is wrong because `trigger` controls CI triggers for commits, not pull request triggers; it would run builds on direct pushes to `main` and `develop`, not on PRs.

Full explanation →
23
MCQhard

Your team uses Azure Pipelines with a YAML-based build pipeline. The pipeline builds a .NET application and runs unit tests. Recently, the unit tests are failing intermittently due to flaky tests. You need to ensure that the pipeline fails only if the same test fails in two consecutive runs. Which feature should you configure?

A.Implement a GitHub Actions workflow with 're-run' trigger.
B.Use the 'Re-run failed stages' option in the pipeline run.
C.Enable 'Automatically rerun failed jobs' in the pipeline settings.
D.Configure the 'retry failed tests' setting in the pipeline's test tab.
AnswerD

The 'retry failed tests' setting in the pipeline's Test tab is the correct way to handle flaky tests: it automatically re-executes only the failed test cases (not entire jobs or stages) a configurable number of times during the same run. If a retried test passes, it is reported as 'Passed on retry' in the Test tab, giving you visibility into which tests are flaky while keeping the overall run green.

Why this answer

The correct feature is the 'Retry failed tests' setting in the pipeline's test tab. This allows you to configure the number of times a failed test is automatically retried. If the test passes on retry, the pipeline is marked as succeeded with warnings, effectively requiring two consecutive failures for the pipeline to fail.

Option A is incorrect because GitHub Actions workflows are not relevant to Azure Pipelines. Option B is for rerunning failed stages, not individual tests. Option C reruns failed jobs, not tests.

Full explanation →
24
MCQhard

You are designing a build pipeline that must be triggered only when changes are made to specific folders in the repository. The pipeline should ignore documentation changes. Which trigger configuration should you use?

A.Configure a scheduled trigger to run the pipeline daily.
B.Configure a branch trigger with an include filter for the main branch.
C.Configure a path trigger with include paths for source code and exclude paths for docs.
D.Configure a tag trigger with a pattern that matches release tags.
AnswerC

A path trigger uses include/exclude patterns on file paths to decide whether a push starts the pipeline. By including paths to source code folders and excluding paths to docs, the pipeline runs only when actual code changes, precisely matching the trigger requirement while ignoring doc-only commits.

Why this answer

Azure Pipelines path triggers allow you to specify include and exclude filters on file paths. By including only source code folders and excluding the docs folder, the pipeline will only run when relevant code changes are made, ignoring documentation updates.

Exam trap

The trap here is that candidates often confuse branch triggers with path triggers, thinking that filtering by branch alone can ignore documentation changes, but branch filters only control which branches trigger the pipeline, not which files within those branches.

How to eliminate wrong answers

Option A is wrong because a scheduled trigger runs the pipeline at specified times regardless of any changes, so it would not respond to specific folder changes. Option B is wrong because a branch trigger with an include filter for the main branch only restricts which branch triggers the pipeline, not which paths within that branch; it would still trigger on any change to the main branch, including documentation. Option D is wrong because a tag trigger is designed to run the pipeline when a Git tag matching a pattern is pushed, not for monitoring changes to specific folders.

Full explanation →
25
MCQeasy

Your team uses GitHub and wants to automatically detect and block secrets pushed to repositories. Which GitHub feature should you enable?

A.Dependabot alerts
B.Code scanning
C.Push protection
D.Secret scanning
AnswerC

Push protection is not an independent feature; it is a layer built into secret scanning that blocks git pushes when a known secret is detected. It relies entirely on secret scanning's detection engine, so it cannot be the feature that automatically detects secrets by itself.

Why this answer

Push protection is the GitHub feature that automatically detects known types of secrets in pushed content and blocks the push, preventing exposure. Secret scanning, on the other hand, scans for secrets and alerts after they exist in the repository but does not block the push unless push protection is enabled. Since the requirement is to 'automatically detect and block secrets pushed', the feature to enable is Push protection.

Exam trap

A common mistake is selecting 'Secret scanning' because it is a broader feature, but the question specifically requires blocking. Push protection is the sub-feature that actually blocks the push, while secret scanning provides the underlying detection mechanism. You can enable push protection as part of secret scanning, but the blocking action is performed by push protection.

How to eliminate wrong answers

Option A is wrong because Dependabot alerts are focused on vulnerable dependencies and outdated package versions, not on detecting secrets in code. Option B is wrong because Code scanning uses CodeQL to find code quality and security vulnerabilities (e.g., SQL injection, XSS), but it does not scan for hardcoded secrets or block pushes. Option C is wrong because Push protection is a sub-feature of Secret scanning that blocks pushes containing secrets, not a standalone feature; the question asks which feature to enable, and the parent feature is Secret scanning.

Full explanation →
26
MCQmedium

A company uses Azure Pipelines to deploy a web app to Azure App Service. They want to ensure that the deployment is first validated in a staging slot before swapping to production. What should they configure?

A.Create two separate pipelines for staging and production
B.Use Azure Traffic Manager to route traffic
C.Use deployment slots in the App Service and configure auto-swap
D.Use an App Service plan with multiple instances
AnswerC

Deployment slots are separate, warm environments in the same App Service plan that allow you to deploy and validate a build without affecting the production slot. Configuring auto-swap promotes the verified staging slot to production instantly with zero downtime, making it the recommended pattern for Azure Pipelines deployments to App Service.

Why this answer

Azure App Service deployment slots allow you to deploy a web app to a staging slot, validate it, and then swap it to production with zero downtime. Auto-swap automates this process by swapping the staging slot into production after a successful deployment, ensuring validation occurs before the production slot receives the new code.

Exam trap

The trap here is that candidates often confuse deployment slots with separate pipelines or scaling, not realizing that slots provide a built-in, zero-downtime validation mechanism within the same App Service.

How to eliminate wrong answers

Option A is wrong because creating two separate pipelines for staging and production introduces manual overhead and potential configuration drift, whereas deployment slots within a single pipeline enable seamless validation and swap. Option B is wrong because Azure Traffic Manager is a DNS-based traffic load balancer for routing traffic across regions, not for validating deployments within a single App Service; it does not provide slot swapping or pre-production validation. Option D is wrong because scaling an App Service plan with multiple instances improves availability and performance but does not provide a staging environment for validating deployments before they reach production.

Full explanation →
27
MCQhard

You have a YAML pipeline that deploys to multiple environments. The pipeline uses environment approvals. You need to ensure that the pipeline waits for manual approval before deploying to the production environment. The production environment is named 'Production'. Which configuration should you add to the deployment job?

A.Add 'environment: Production' to the deployment job and configure approvals on the environment in the Azure DevOps portal
B.Add 'approvals: Production' to the deployment job
C.Add 'checks: Production' to the deployment job
D.Add 'dependsOn: ProductionApproval' and use a separate stage for approval
AnswerA

In Azure DevOps, attaching a deployment job to an environment named 'Production' and configuring approvals on that environment in the portal is the correct, native mechanism. The environment acts as a gate that pauses the pipeline before deployment, waiting for the designated approvers to approve or reject the release, with full audit trail and notifications.

Why this answer

Environment approvals in Azure DevOps are configured on the environment resource itself, not in the pipeline YAML. By adding 'environment: Production' to the deployment job, the pipeline references the environment, and the manual approval gate is enforced by the approvals configured on that environment in the Azure DevOps portal. This ensures the pipeline waits for approval before proceeding to the production deployment job.

Exam trap

The trap here is that candidates often assume approvals can be defined directly in the YAML pipeline (like a task or a key), but Azure DevOps requires approvals to be configured on the environment resource in the portal, not in the pipeline code.

Why the other options are wrong

B

'approvals' is not a valid keyword in YAML pipeline syntax.

C

'checks' is not a valid keyword; checks are configured on environments.

D

While you can create a separate stage for approval, it's not the standard way; environment approvals are built-in.

Full explanation →
28
MCQhard

You have the YAML pipeline shown in the exhibit. What will be the output of the script in the Deploy stage?

A.The Deploy stage will be skipped
B.Deploying to prod
C.Deploying to dev
D.The script will fail because variable is not defined
AnswerB

The Deploy stage defines the variable 'environment' with the value 'prod' in its stage-level variables block. This stage-scoped variable overrides any same-named variable from the pipeline or global scope, so when the script executes 'echo Deploying to $(environment)', it outputs 'Deploying to prod'.

Why this answer

The YAML pipeline defines a variable `environment` at the stage level with the value `prod`. The script in the Deploy stage references `$(environment)`, which resolves to `prod`, so the output is `Deploying to prod`. Stage-level variables override any pipeline-level or default variables for that stage.

Exam trap

The trap here is that candidates may assume the variable `environment` is undefined or defaults to `dev` from a pipeline-level variable, but they overlook that the stage-level definition explicitly sets it to `prod`, which overrides any broader scope.

How to eliminate wrong answers

Option A is wrong because the Deploy stage is not skipped; it runs normally with the stage-level variable `environment` set to `prod`. Option C is wrong because the variable `environment` is explicitly set to `prod` in the stage, not `dev`; if no stage-level variable were defined, it might default to `dev` from a pipeline-level variable, but here the stage-level value takes precedence. Option D is wrong because the variable `environment` is defined at the stage level, so it is available to the script; the script will not fail due to an undefined variable.

Full explanation →
29
MCQmedium

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

A.Configure a branch policy on the main branch to require a specific service connection.
B.Use a pipeline decorator to validate the service connection and fail the pipeline if an unauthorized connection is used.
C.Restrict the use of PATs by setting an agent pool-level permission.
D.Store the service connection ID in a variable group and reference it in each pipeline.
AnswerB

Pipeline decorators are injected into every job at execution time, allowing you to add a validation step that inspects the service connection ID used by tasks such as AzureCLI or AzurePowerShell. Because the decorator runs as part of the job definition, you can compare the connection against an approved list and call an error to fail the pipeline before deployment proceeds. This control is centralized at the organization level and cannot be bypassed by a repository without modifying the decorator itself, making it the only enforceable option.

Why this answer

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

Exam trap

The trap here is that candidates confuse branch policies (which control code changes) with runtime enforcement mechanisms, overlooking that only pipeline decorators can inject mandatory validation into every pipeline execution.

How to eliminate wrong answers

Option A is wrong because branch policies apply to pull request validation and merge gates, not to the service connection used during pipeline execution; they cannot enforce which connection is used at runtime. Option C is wrong because agent pool-level permissions control who can use or manage the pool, not which authentication method (PAT vs. managed identity) is used in pipeline tasks. Option D is wrong because storing the service connection ID in a variable group does not enforce its use; developers can still reference a different connection directly in their YAML or override the variable.

Full explanation →
30
MCQeasy

You need to trigger a pipeline whenever changes are pushed to the 'main' branch of a GitHub repository. Which trigger should you configure in the YAML pipeline?

A.trigger: branches: include: - main
B.pr: branches: include: - main
C.resources: repositories: - repository: self trigger: branches: include: - main
D.schedules: - cron: "0 0 * * *" branches: include: - main
AnswerA

This is the standard YAML syntax in Azure Pipelines to trigger a pipeline on a push to the main branch in GitHub. It uses the `trigger` keyword with branch filters under `branches.include`, causing the pipeline to run automatically when commits are pushed to that branch.

Why this answer

The `trigger` keyword at the root of a YAML pipeline defines the CI trigger that automatically starts a pipeline run when changes are pushed to the specified branch. By including `main` under `branches.include`, the pipeline will trigger on any push to the `main` branch of the GitHub repository, which is the standard way to set up a CI trigger for a single branch.

Exam trap

The trap here is that candidates often confuse the `trigger` (CI push trigger) with the `pr` (pull request trigger), or incorrectly assume that a resource-level trigger is required for the self repository, when the root-level `trigger` is the correct and simplest configuration for push-based CI on the same repository.

Why the other options are wrong

B

This triggers on pull request creation, not on push.

C

This is for triggering from another repository, not the self repo.

D

This is a scheduled trigger, not on push.

Full explanation →
31
MCQmedium

Your team uses GitHub Actions to build and deploy a Node.js application to Azure App Service. The deployment succeeds, but the app crashes after startup with an error indicating a missing module. The build artifact includes the node_modules folder. What is the most likely cause?

A.The .gitignore file excludes node_modules from the artifact.
B.The Node.js version on the runner differs from the App Service runtime, causing native module incompatibility.
C.The workflow YAML has an indentation error that causes the deploy step to fail silently.
D.The build step does not run npm ci, so the package-lock.json is ignored.
AnswerB

The runner and Azure App Service runtime must use the same Node.js major version (or at least a compatible ABI) for native modules such as bcrypt or sharp. If the workflow builds with a different Node.js version than the App Service runtime, those native addons are compiled against incompatible V8/N-API binaries and fail to load at startup, producing a 'module not found' or similar crash.

Why this answer

The most likely cause is that the Node.js version on the GitHub Actions runner differs from the version on Azure App Service, leading to native module incompatibility. Native modules (e.g., those using node-gyp) are compiled against the specific Node.js ABI (Application Binary Interface) of the build environment. If the runtime version differs, the compiled .node binaries will fail to load, resulting in a 'missing module' error even though the node_modules folder is present in the artifact.

Exam trap

The trap here is that candidates assume a missing module error always means the file wasn't included in the artifact, but in this scenario the node_modules folder is present, so the real issue is ABI incompatibility between the build and runtime Node.js versions.

How to eliminate wrong answers

Option A is wrong because the .gitignore file does not affect the build artifact; GitHub Actions artifacts are created from the workspace after the build step, and the workflow explicitly includes node_modules in the artifact. Option C is wrong because an indentation error in the YAML would cause the workflow to fail at parse time, not silently skip the deploy step; the deployment succeeded, so the YAML is valid. Option D is wrong because npm ci is used for deterministic installs based on package-lock.json, but the error is about a missing module at runtime, not about the install process; the artifact includes node_modules, so npm ci was likely run or the modules were otherwise included.

Full explanation →
32
MCQmedium

Your Azure DevOps project contains a Git repository with multiple branches. You need to ensure that code reviews are mandatory for all pull requests targeting the 'release' branch. Additionally, the build pipeline must pass before merging. How should you configure branch policies?

A.Enable 'Build validation' only.
B.Enable 'Require a minimum number of reviewers' only.
C.Enable 'Require a minimum number of reviewers' and 'Build validation'.
D.Enable 'Require a minimum number of reviewers' and 'Comment resolution'.
AnswerC

Combining 'Require a minimum number of reviewers' and 'Build validation' enforces both peer review and a successful build pipeline. This ensures that changes are approved by the required reviewers and meet the build quality gate before merging, delivering comprehensive branch protection.

Why this answer

The requirement specifies two distinct conditions: mandatory code reviews (enforced by 'Require a minimum number of reviewers') and a passing build pipeline before merge (enforced by 'Build validation'). In Azure Repos, branch policies allow you to combine multiple checks; enabling only one of these would leave the other requirement unmet. Therefore, both policies must be enabled to satisfy the full criteria.

Exam trap

The trap here is that candidates often assume 'Comment resolution' implies code review completion, but it only requires that all discussion comments are resolved, not that a specific number of reviewers have approved the changes.

How to eliminate wrong answers

Option A is wrong because enabling only 'Build validation' ensures the pipeline passes but does not enforce mandatory code reviews, leaving the review requirement unmet. Option B is wrong because enabling only 'Require a minimum number of reviewers' enforces code reviews but does not require the build pipeline to pass before merging, violating the build condition. Option D is wrong because 'Comment resolution' ensures all comments are resolved before merging, but it does not enforce a minimum number of reviewers or build validation, so it fails both stated requirements.

Full explanation →
33
Drag & Dropmedium

Drag and drop the steps to configure Azure Monitor alerts for application performance into the correct order.

Drag or tap steps into the slots.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4

Why this order

Alert setup begins with enabling monitoring, creating rule, setting condition, action groups, and testing.

Full explanation →
34
Multi-Selectmedium

A company deploys a web application to Azure App Service. They want to monitor application performance and detect anomalies using Application Insights. Which two components should be configured?

Select 2 answers
A.Deploy the Azure Monitor agent on the App Service instance
B.Configure sampling to reduce data volume
C.Create a Log Analytics workspace and configure data collection rules
D.Enable application-side SDK for telemetry
E.Enable diagnostics settings to stream logs to Event Hubs
AnswersB, D

Configuring sampling in Application Insights filters telemetry while preserving a representative subset of the data. This reduces ingestion and storage costs while still retaining enough data to detect performance anomalies, making it an effective and necessary optimization for high-volume applications.

Why this answer

Sampling in Application Insights reduces the volume of telemetry data while preserving statistically correct analysis, which is essential for managing cost and performance in high-traffic applications. Option D is correct because the application-side SDK (e.g., Application Insights SDK for .NET, Java, or Node.js) is required to instrument the code and collect detailed telemetry such as requests, dependencies, and exceptions for performance monitoring and anomaly detection.

Exam trap

The trap here is that candidates often confuse the Azure Monitor agent (for VMs) with the App Service diagnostics settings or Log Analytics workspaces, thinking they are required for Application Insights instrumentation, when in fact the SDK and sampling are the two core components for application performance monitoring and anomaly detection.

Full explanation →
35
Multi-Selecthard

Which THREE of the following are valid considerations when designing a release pipeline to deploy to multiple environments (dev, test, prod) using Azure Pipelines YAML?

Select 3 answers
A.Use variable groups scoped to environments to override variables per stage.
B.Use environment-level approvals to gate production deployments.
C.Use stage-level approvals to gate each stage.
D.Use conditions on stages to filter based on branch.
E.Use YAML templates to define each environment's deployment steps.
AnswersA, B, D

In Azure Pipelines, variable groups can be linked to an environment, allowing environment-specific variable values to be automatically injected into deployment jobs that target that environment. This enables per-stage overrides without duplicating pipeline code, because each stage can reference a different environment and thus consume its linked variable group, making it a valid and recommended practice.

Why this answer

Variable groups can be reused across pipelines and stages. In a multi-stage YAML pipeline, you can use different variable groups for each environment by referencing them in the `variables` section of each stage (e.g., a variable group for dev, test, and prod). This allows you to override values such as connection strings per environment without duplicating pipeline code.

For production deployments, you should configure approvals and checks on the Azure Pipelines environment resource (e.g., 'prod') to require manual sign-off before the deployment job runs. Stage-level approvals do not exist in Azure Pipelines; approvals are always attached to an environment or a service connection. For branch-based filtering, you can use stage `condition` expressions, such as `and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))`, to control which stages run based on the source branch.

To reduce duplication, use YAML templates with parameters to define a single deployment template that is reused across environments rather than creating separate templates per environment.

Exam trap

The trap here is that candidates often confuse stage-level approvals (which do not exist) with environment-level approvals, and they mistakenly think YAML templates should be used to define separate deployment steps per environment instead of parameterizing a single template.

Full explanation →
36
Multi-Selecthard

Which THREE practices improve the efficiency of code review processes in GitHub?

Select 3 answers
A.Allow direct pushes to main for urgent fixes.
B.Enable required status checks to pass before merging.
C.Use pull request templates with checklists.
D.Require at least 5 reviewers for every PR.
E.Keep pull requests small and focused.
AnswersB, C, E

Required status checks gate merging on automated build, test, and validation results, so reviewers avoid manually verifying code that CI already proves sound. This reduces review cycles and prevents broken code entering protected branches, directly improving code review efficiency.

Why this answer

Option B is correct because enabling required status checks (branch protection rules that block merging until CI checks pass) ensures automated tests, linting, and builds succeed before human review, reducing review cycles spent on broken or untested code. Option C is correct because pull request templates with checklists standardize what authors provide (e.g., description, testing steps, linked issues), so reviewers spend less time requesting missing context and more time on substantive feedback. Option E is correct because small, focused pull requests are easier and faster to review, produce more precise comments, and reduce merge conflicts and review fatigue, directly improving review efficiency.

Option A is not appropriate because allowing direct pushes to main bypasses review entirely and undermines branch protection, increasing risk rather than improving the review process. Option D is not appropriate because requiring at least 5 reviewers for every PR creates bottlenecks, slows merge times, and adds redundant approvals without proportional quality gains.

Exam trap

The trap here is that candidates may confuse 'efficiency' with 'speed' and choose Option A (direct pushes) to bypass review, but the question asks for practices that improve efficiency of the review process itself, not shortcuts that undermine it.

Full explanation →
37
Multi-Selecthard

Which TWO approaches can you use to enforce consistent commit message formatting across your organization? (Choose two.)

Select 2 answers
A.Use a pre-receive hook in GitHub to validate commit messages
B.Use a GitHub workflow that checks PR titles
C.Configure a branch policy in Azure Repos to require commit message validation
D.Provide a commit message template to developers
E.Use Git hooks only on client side
AnswersA, C

A pre-receive hook in GitHub executes on the server for every push and can reject commits with invalid message formats before they are accepted, providing a hard enforcement point that developers cannot bypass locally. This centralizes policy and guarantees consistent commit message history across all contributions.

Why this answer

GitHub's pre-receive hooks are server-side scripts that execute on the repository before accepting a push, allowing you to enforce commit message format validation across all contributors. Similarly, Azure Repos branch policies can include a commit message pattern check, which validates commit messages against a regex and rejects pushes with non-conforming messages. Both approaches enforce the standard on the server side, regardless of local client configurations.

Exam trap

The trap here is that candidates often confuse client-side Git hooks (which are optional and local) with server-side hooks (which enforce policy remotely), or they mistakenly believe that PR title checks or templates provide the same level of enforcement as server-side validation.

Full explanation →
38
MCQeasy

You are designing a release pipeline that deploys a web app to Azure App Service. You need to ensure that configuration secrets (e.g., database connection strings) are not stored in the pipeline YAML file. Which approach should you use?

A.Define the secrets as agent-scoped variables in the release pipeline.
B.Hardcode the secrets in the App Service configuration and reference them in the pipeline.
C.Use an Azure Key Vault variable group linked to the pipeline.
D.Store the secrets as pipeline variables and mark them as 'Secret'.
AnswerC

Linking an Azure Key Vault variable group to the release pipeline is the recommended approach because secrets are never stored in the pipeline definition or on the agent. Instead, Azure DevOps securely retrieves the latest secret values from Key Vault at runtime using the configured ARM service connection, which in turn uses a service principal or managed identity. This enables centralized secret management with fine-grained access policies, automatic rotation support, and eliminates the risk of exposing secrets in logs, version control, or build artifacts.

Why this answer

Azure Key Vault variable groups allow you to securely reference secrets stored in Azure Key Vault from within a pipeline without exposing them in the YAML file. The pipeline retrieves the secrets at runtime via a linked service connection, ensuring they never appear in source control or pipeline logs.

Exam trap

The trap is that candidates often choose Option D (secret pipeline variables) because they mask output in logs, but they fail to realize that the secret value is still stored in the pipeline definition (not in YAML, but in Azure DevOps) and can be viewed by users with access to the pipeline settings or exported via API. Key Vault variable groups provide better security through centralized secret management, permissions, and audit logging.

How to eliminate wrong answers

Option A is wrong because agent-scoped variables are not designed for secrets; they are used to scope variables to a specific agent and do not provide secure storage or access control for secrets. Option B is wrong because hardcoding secrets in App Service configuration still requires the pipeline to know the secrets to set them, and referencing them in the pipeline would expose them in the YAML or logs. Option D is wrong because marking pipeline variables as 'Secret' only masks their value in logs, but the secrets are still stored in the pipeline definition and can be exposed if the pipeline YAML is shared or stored in source control.

Full explanation →
39
Multi-Selecteasy

Which TWO metrics should you monitor to evaluate the reliability of a web application according to the DORA metrics?

Select 2 answers
A.Lead Time for Changes
B.Change Failure Rate
C.Mean Time to Restore (MTTR)
D.CPU Usage
E.Deployment Frequency
AnswersB, C

Change Failure Rate is the percentage of deployments that cause a failure in production, such as a service impairment or rollback. It is a core DORA reliability metric because it directly quantifies how often changes disrupt service, making it essential for evaluating system stability.

Why this answer

The DORA metrics define four key measures for software delivery performance: Deployment Frequency, Lead Time for Changes, Mean Time to Restore (MTTR), and Change Failure Rate. For evaluating the reliability of a web application, the two most directly relevant metrics are Change Failure Rate (B), which measures the percentage of deployments causing a failure in production, and Mean Time to Restore (MTTR) (C), which measures the time it takes to recover from a failure. These two metrics directly quantify stability and resilience, whereas Deployment Frequency and Lead Time for Changes focus on throughput and speed.

Exam trap

The trap here is that candidates often confuse throughput metrics (Deployment Frequency, Lead Time for Changes) with reliability metrics, but DORA specifically separates them into 'throughput' and 'stability' categories, and the question explicitly asks for reliability.

Full explanation →
40
MCQhard

You configured a multi-stage YAML pipeline with a deployment job that uses a deployment strategy like 'runOnce' or 'rolling'. You need to ensure that the deployment target is marked as 'succeeded' only after the deployment job completes successfully, and that any previous deployment to the same environment is preserved for rollback. Which setting must you configure?

A.Set the environment's 'retain' property to 1 or more
B.Set the deployment job's 'continueOnError' to true
C.Use the 'deployment' job with 'strategy: rolling'
D.Set the 'deploymentStrategy' to 'blueGreen'
AnswerA

Setting the environment's 'retain' property to 1 or more instructs Azure Pipelines to keep the specified number of previous deployments for that environment. This retained deployment history enables rollback to a prior version, as the pipeline can redeploy the previous artifact without needing to recreate it.

Why this answer

Setting the environment's 'retain' property to 1 or more ensures that the previous deployment (e.g., the last successful run) is preserved as a 'retained' revision in the environment. This allows you to redeploy that specific revision for rollback purposes. The deployment job marks the environment target as 'succeeded' only after the job completes successfully, and retaining previous revisions prevents them from being automatically cleaned up.

Exam trap

The trap here is that candidates often confuse deployment strategies (rolling, blue-green) with revision retention, assuming that a strategy like 'rolling' or 'blueGreen' inherently preserves previous deployments for rollback, when in fact retention is a separate environment-level setting.

Why the other options are wrong

B

This would continue on failure, not preserve previous deployments.

C

This defines the update strategy but does not control retention of history.

D

Blue-green is a deployment strategy, but retention is still controlled by environment settings.

Full explanation →
41
MCQeasy

Your organization uses Microsoft Purview to classify and protect sensitive data. You need to ensure that source code in Azure DevOps repositories containing credit card numbers is detected and flagged. What should you configure?

A.Create a Data Loss Prevention (DLP) policy in Microsoft 365.
B.Set up Microsoft Sentinel to monitor Azure DevOps logs.
C.Configure a Microsoft Purview Data Classification scan for Azure DevOps repositories.
D.Enable Microsoft Defender for Cloud to scan repositories.
AnswerC

Microsoft Purview provides data governance and classification capabilities, and its data map can register and scan Azure DevOps repositories to automatically classify sensitive data such as credentials, connection strings, and personal information. This directly aligns with the requirement to classify and protect sensitive information in your organization's code repositories.

Why this answer

Microsoft Purview Data Classification scans can be configured to scan Azure DevOps repositories for sensitive data types, such as credit card numbers, using built-in or custom sensitive information types. This allows the organization to detect and flag source code containing credit card numbers directly within the repository, aligning with the requirement to classify and protect sensitive data under a compliance plan.

Exam trap

The trap here is that candidates often confuse Microsoft Purview Data Classification (which can scan Azure DevOps repositories) with Microsoft 365 DLP policies (which are limited to Microsoft 365 workloads), leading them to select Option A incorrectly.

How to eliminate wrong answers

Option A is wrong because Data Loss Prevention (DLP) policies in Microsoft 365 are designed to protect data in Microsoft 365 services (e.g., Exchange, SharePoint, OneDrive) and do not natively scan Azure DevOps repositories for sensitive data. Option B is wrong because Microsoft Sentinel is a Security Information and Event Management (SIEM) tool that monitors security logs and alerts, not a data classification service for scanning source code content in repositories. Option D is wrong because Microsoft Defender for Cloud focuses on cloud security posture management and workload protection, not on scanning source code for sensitive data classification like credit card numbers.

Full explanation →
42
MCQmedium

A company deploys a .NET Core web application to Azure App Service. The application uses Application Insights for monitoring. The operations team reports that dependency tracking is missing for calls to a third-party REST API made using HttpClient. The application is instrumented with the Application Insights SDK. Which action should be taken to enable dependency tracking for HttpClient calls?

A.Ensure the SDK is configured using services.AddApplicationInsightsTelemetry(); in the Startup.cs file.
B.Install the Application Insights Agent on the App Service instance.
C.Add a reference to Microsoft.ApplicationInsights.DependencyCollector and call DependencyTrackingModule.Initialize().
D.Use the Application Insights Status Monitor to enable dependency tracking.
AnswerA

In ASP.NET Core, calling services.AddApplicationInsightsTelemetry() in the Startup.ConfigureServices method registers all Application Insights services with the built-in dependency injection container. This extension automatically initializes the DependencyTrackingModule, enabling outbound dependency calls (such as HttpClient) to be tracked without writing any additional initialization code, and it reads the instrumentation key or connection string from app settings.

Why this answer

`services.AddApplicationInsightsTelemetry()` in `Startup.cs` automatically registers the `DependencyTrackingModule` for .NET Core applications. This module collects dependency telemetry for `HttpClient` calls made via `IHttpClientFactory` or typed `HttpClient` instances, provided the SDK is properly configured. Since the application already uses the Application Insights SDK, this single line enables automatic dependency tracking without additional packages or agents.

Exam trap

The trap here is that candidates confuse the .NET Core SDK approach with legacy .NET Framework tools like Status Monitor or manual `DependencyTrackingModule.Initialize()`, assuming dependency tracking requires extra packages or agent installation, when in fact `AddApplicationInsightsTelemetry()` handles it automatically for .NET Core.

How to eliminate wrong answers

Option B is wrong because the Application Insights Agent (formerly Status Monitor v2) is designed for .NET Framework applications hosted on IIS or Azure VMs, not for .NET Core on App Service; .NET Core apps require SDK-based instrumentation. Option C is wrong because `DependencyTrackingModule.Initialize()` is a legacy approach for .NET Framework apps; in .NET Core, the module is automatically initialized by the SDK when `AddApplicationInsightsTelemetry()` is called, and adding a manual reference is unnecessary and may cause duplicate initialization. Option D is wrong because Status Monitor is a .NET Framework tool that cannot instrument .NET Core applications; Azure App Service for .NET Core relies on the SDK or the App Service 'Application Insights' blade settings, not Status Monitor.

Full explanation →
43
MCQmedium

A development team wants to ensure that all code changes are reviewed by at least two senior developers before merging into the main branch. They use Azure Repos. What should they configure?

A.Enable the build validation policy on the branch.
B.Set up a release pipeline with gated deployments.
C.Configure a branch policy requiring a minimum number of reviewers.
D.Add a status check policy using Azure Functions.
AnswerC

Branch policies in Azure Repos can enforce a minimum number of reviewers on pull requests, blocking completion until the required number of approved reviews is met; this directly ensures that every code change receives the mandated human review before merging.

Why this answer

Azure Repos branch policies allow you to enforce a minimum number of reviewers on pull requests. By setting the 'Minimum number of reviewers' policy to 2, the team ensures that at least two senior developers must approve any code change before it can be merged into the main branch. This directly meets the requirement without involving build validation, release pipelines, or external function calls.

Exam trap

The trap here is that candidates often confuse build validation policies (which ensure code compiles) with reviewer policies (which ensure human oversight), leading them to select option A instead of C.

How to eliminate wrong answers

Option A is wrong because enabling the build validation policy ensures that a build succeeds before merging, but it does not enforce any requirement for human code reviews or a minimum number of reviewers. Option B is wrong because a release pipeline with gated deployments controls when artifacts are deployed to environments, not when code is merged into a branch; it does not enforce pre-merge review requirements. Option D is wrong because a status check policy using Azure Functions can call external services to report a status, but it does not natively enforce a minimum number of reviewers; it would require custom logic and does not replace the built-in reviewer policy.

Full explanation →
44
Multi-Selecthard

You are designing a YAML pipeline in Azure Pipelines that must deploy an application to Azure Kubernetes Service (AKS). You need to ensure that the pipeline uses a Kubernetes service connection to authenticate to the AKS cluster and that the deployment is performed using a Helm chart. Which two actions should you include in the pipeline? (Choose two.)

Select 2 answers
A.Use the `HelmDeploy@0` task to deploy the Helm chart.
B.Create a Kubernetes service connection in Azure DevOps that points to the AKS cluster.
C.Use the `KubernetesManifest@0` task to deploy the application.
D.Use the `AzureResourceManagerTemplateDeployment@3` task to deploy the Helm chart.
E.Use the `Kubectl@0` task to apply the Helm chart.
AnswersA, B

The HelmDeploy task is specifically designed to deploy Helm charts to a Kubernetes cluster. It supports various commands like install, upgrade, and uninstall, and can authenticate using a Kubernetes service connection. This task is the correct choice for deploying a Helm chart in Azure Pipelines.

Why this answer

To deploy a Helm chart to AKS using Azure Pipelines, you should use the HelmDeploy task, which is designed for Helm deployments. You also need a Kubernetes service connection to authenticate to the AKS cluster. The other tasks are either for different deployment methods or not suitable for Helm charts.

Exam trap

The trap here is assuming that the KubernetesManifest task can deploy Helm charts directly, when it is intended for raw Kubernetes manifests.

Full explanation →
45
MCQmedium

Your team uses GitHub Actions to build a Python application. The workflow includes a step to run unit tests with pytest. The tests pass locally but fail in CI with 'ModuleNotFoundError: No module named 'myapp''. The repository structure has the application code in a subdirectory 'src/'. What is the most likely fix?

A.Set the working directory of the test step to 'src/'.
B.Add a step to install dependencies with 'pip install -r requirements.txt'.
C.Set the environment variable PYTHONPATH to 'src/' before running tests.
D.Add a step to run 'pip install -e .' from the repository root.
AnswerC

Setting PYTHONPATH to 'src/' before running tests adds the 'src' directory to Python's module search path, allowing the test runner to import the local package modules directly. This is a standard and effective fix for a src-layout project where the package has not been installed, directly resolving the ModuleNotFoundError.

Why this answer

The Python interpreter cannot find the 'myapp' module when tests run in CI, even though the code is present in the 'src/' subdirectory. Setting PYTHONPATH to 'src/' tells Python to include that directory in the module search path, allowing 'import myapp' to resolve correctly without moving or copying files. This is the most direct fix for a missing module path issue in a CI environment where the working directory is not automatically set to the source folder.

Exam trap

The trap here is that candidates often confuse changing the working directory (Option A) with modifying the module search path, not realizing that Python's import resolution depends on sys.path, not the current working directory.

How to eliminate wrong answers

Option A is wrong because setting the working directory to 'src/' would only change where the test step runs, but it does not add 'src/' to Python's module search path; the tests would still fail if they import 'myapp' from a parent directory. Option B is wrong because installing dependencies with 'pip install -r requirements.txt' addresses missing third-party packages, not the inability to find the local 'myapp' module. Option D is wrong because 'pip install -e .' installs the package in editable mode from the repository root, but if the setup.py or pyproject.toml is not configured to include the 'src/' layout, it may not make 'myapp' importable; even if it did, it is an over-engineered solution compared to simply setting PYTHONPATH.

Full explanation →
46
MCQhard

You have the above branch policy configuration for the main branch. A developer pushes a new commit to an existing pull request. What happens?

A.The existing approvals are reset, but no new build is queued.
B.The pull request is automatically completed.
C.The existing approvals are reset, and a new build is automatically queued.
D.The existing approvals remain valid, and the build is not requeued.
AnswerC

This is correct because the branch policy has two relevant settings: 'Reset approvals on new push' is enabled, so existing approvals are invalidated when new commits are pushed, and the build validation policy has 'Queue new build on source update only' set to true, so a new build is automatically queued. Both actions occur as a direct result of the new push to the PR source branch.

Why this answer

When a new commit is pushed to an existing pull request and the branch policy includes a build validation with 'Reset approvals on new changes' enabled, Azure DevOps resets all existing approvals and automatically queues a new build to validate the updated code. This ensures that approvals are only valid for the exact code revision that was reviewed. The behavior is standard for branch policies that require a build and have the reset option configured.

Exam trap

AZ-400 often tests the misconception that approvals persist across new commits, when in fact branch policies with reset enabled invalidate them and trigger a new build.

How to eliminate wrong answers

Option A is wrong because it states no new build is queued, but the policy automatically triggers a new build when the pull request is updated. Option B is wrong because the pull request is not automatically completed; it still requires approvals and a successful build. Option D is wrong because existing approvals do not remain valid; they are reset to prevent stale approvals from being used on new code.

Full explanation →
47
MCQhard

You have a YAML pipeline that uses a multi-stage build. You want to cache the restored NuGet packages across builds to improve performance. Which caching strategy should you use?

A.Use the Cache@2 task with key: 'nuget | "$(Agent.OS)" | packages.lock.json', path: '$(System.DefaultWorkingDirectory)/packages'
B.Use the NuGetCommand@2 task with the -Cache argument.
C.Set the NUGET_PACKAGES environment variable to a custom path and rely on pipeline caching plugin.
D.Use the DotNetCoreCLI@2 task with the --no-restore flag and manually copy packages.
AnswerA

The Cache@2 task is the correct built-in mechanism for caching NuGet packages in Azure Pipelines. The composite key, combining 'nuget', the agent OS, and packages.lock.json, invalidates the cache only when the OS or the lock file changes, ensuring restore artifacts are reused across runs. The path points to the packages folder (typically the global packages folder) so subsequent restore operations can use the cached packages without hitting the network.

Why this answer

The Cache@2 task is the recommended way to cache NuGet packages in Azure Pipelines. By using a cache key that includes the agent OS and the packages.lock.json file, the cache is invalidated only when the lock file changes, ensuring restored packages are reused across builds. The path points to the NuGet global packages folder, which is typically $(System.DefaultWorkingDirectory)/packages when NUGET_PACKAGES is set.

Exam trap

The trap here is that candidates may confuse the Cache@2 task's explicit key-path pairing with other NuGet-specific arguments or environment variables, assuming a simpler flag exists, when in fact Azure DevOps requires the Cache@2 task for reliable cross-build caching.

Why the other options are wrong

B

NuGetCommand does not have a -Cache argument for cross-build caching.

C

The environment variable is useful but caching must be explicitly configured.

D

--no-restore skips restore, not caching.

Full explanation →
48
MCQhard

You are reviewing an Azure Policy assignment in a DevOps environment. The exhibit shows the policy assignment JSON. The policy set includes the built-in policy 'Allowed Locations' with effect Deny. During a pipeline deployment, a resource creation fails with a policy violation error. The resource being deployed is a storage account in the 'centralus' region. What is the most likely reason for the failure?

A.The policy assignment is misconfigured because it does not specify a policy set definition.
B.The resource being deployed is in a region that is not allowed by the policy assignment parameters.
C.The resource group is located in a region that overrides the policy assignment.
D.The policy set definition does not include the 'Allowed Locations' policy.
AnswerB

The allowedLocations parameter in the policy assignment restricts permissible deployment regions to eastus and westus only. Since the resource being deployed is in centralus, which is not included in those parameters, the 'Allowed Locations' policy denies the deployment as non-compliant.

Why this answer

The policy assignment includes the built-in 'Allowed Locations' policy with the Deny effect. The resource being deployed (a storage account) is in the 'centralus' region, but the policy assignment parameters likely specify a list of allowed regions that does not include 'centralus'. Since the Deny effect prevents any non-compliant resource creation, the deployment fails with a policy violation error.

This is the most direct and common cause of such failures in Azure Policy.

Exam trap

The trap here is that candidates may assume the resource group's location influences policy evaluation, but Azure Policy evaluates each resource's location independently, and the resource group's location is irrelevant unless explicitly referenced in the policy rule.

How to eliminate wrong answers

Option A is wrong because the exhibit shows the policy assignment JSON includes a 'policySetDefinitionId' field, so the assignment is correctly linked to a policy set definition. Option C is wrong because the resource group's location does not override a policy assignment; Azure Policy evaluates resources individually based on the policy rules, not the resource group's location. Option D is wrong because the policy set definition explicitly includes the 'Allowed Locations' policy, as shown in the exhibit's 'policyDefinitions' array.

Full explanation →
49
Multi-Selectmedium

Your organization uses Azure Repos and wants to implement a Git branching strategy that supports continuous delivery with hotfix capabilities. Which THREE practices should be part of the strategy?

Select 3 answers
A.Feature branches have long lifetimes and are merged to main only after full feature completion.
B.Release branches are used to stabilize a release before merging to main.
C.Main branch is always in a deployable state.
D.Hotfixes are merged directly to develop and then cherry-picked to main.
E.Hotfix branches are created from main and merged back into main and develop.
AnswersB, C, E

Release branches allow final testing, bug fixes, and version tagging without disrupting ongoing development on main, ensuring the release is production-ready before main integration. This stabilizes the release while keeping main available for concurrent feature work.

Why this answer

Option B is correct because release branches let you stabilize and harden a release (final testing, version bumps, minor fixes) in isolation while main continues to receive new work, which is essential for continuous delivery. Option C is correct because keeping main always in a deployable state is the core invariant of a CD-oriented branching strategy, enabling any commit on main to be released at any time. Option E is correct because hotfix branches must be cut from main (the production-ready line), fixed, then merged back into main for immediate release and also merged into develop so the fix is not lost in ongoing development.

Option A is wrong because long-lived feature branches cause merge conflicts and delay integration, contradicting continuous delivery's need for short-lived branches and frequent merges. Option D is wrong because merging hotfixes directly into develop and cherry-picking to main inverts the correct flow and risks divergence, since the hotfix should originate from main and be propagated to both main and develop.

Exam trap

The trap is confusing the hotfix branching model with the incorrect practice of merging hotfixes directly to develop and cherry-picking to main. Hotfix branches should be created from main (the production branch) so the fix is based on the latest production code, and the fix should be merged into both main and develop to ensure it is not lost in subsequent development.

Full explanation →
50
MCQeasy

Your organization uses Azure DevOps and has a project with multiple teams. The 'AlphaTeam' wants a branch policy on their feature branch 'feature/alpha' that requires a successful build from the CI pipeline and approval from at least one member of 'AlphaTeam'. However, the 'BetaTeam' should be able to push directly to 'feature/alpha' without a pull request. You need to configure the branch policy accordingly. What should you do?

A.Create a new repository for AlphaTeam and apply the policy there.
B.Set a branch policy at the repository level that applies to all branches, then grant BetaTeam bypass permission.
C.Configure the branch policy on 'feature/alpha' to require build and approval, and set 'Allow direct pushes' to 'Everyone'.
D.Configure the branch policy on 'feature/alpha' to require build and approval from AlphaTeam, and set 'Allow direct pushes' to 'Selected users' and add BetaTeam.
AnswerD

Configuring the 'feature/alpha' branch policy to require build and approval from AlphaTeam while setting 'Allow direct pushes' to 'Selected users' and adding BetaTeam grants BetaTeam a scoped bypass only for direct pushes to that specific branch. AlphaTeam and other non-selected users still must submit a pull request and satisfy the build and approval requirements. This balances the need for BetaTeam to push directly with the need to keep the feature branch protected, and it does not affect any other branches.

Why this answer

Azure DevOps branch policies allow you to configure 'Allow direct pushes' to specific users or groups while still enforcing PR requirements for others. By setting the policy on 'feature/alpha' to require a successful build and approval from at least one AlphaTeam member, and then selecting 'Selected users' for direct pushes with BetaTeam added, BetaTeam can push directly without a PR, while AlphaTeam must follow the PR policy.

Exam trap

The trap here is that candidates often confuse 'Allow direct pushes' with a global bypass permission, not realizing it can be scoped to specific users while still enforcing policies for others.

How to eliminate wrong answers

Option A is wrong because creating a separate repository is unnecessary and does not solve the requirement for a single repository with differentiated access; it would also break the existing project structure. Option B is wrong because setting a branch policy at the repository level applies to all branches, which would force PRs on BetaTeam's branches as well, and granting bypass permission would remove all policy enforcement, including the build requirement. Option C is wrong because setting 'Allow direct pushes' to 'Everyone' would allow anyone, including AlphaTeam, to bypass the PR requirement, which contradicts the need for AlphaTeam to use pull requests.

Full explanation →
51
MCQhard

You are the Azure DevOps administrator for a large enterprise with multiple projects using the Scrum process. The organization has recently adopted a new compliance policy requiring that all work items of type 'Epic' must be approved by a compliance officer before they can be moved to the 'Committed' state. The compliance officers are external to the development teams and should not have direct access to modify work items. You need to implement this requirement with minimal administrative overhead. The current process has the following states for Epics: New, Proposed, Committed, In Progress, Done. The desired flow is: from 'Proposed' to 'Committed', a compliance officer must approve the transition. Compliance officers are part of a security group named 'Compliance Officers'. They should be able to approve the transition without having to edit the work item directly. What should you do?

A.In the process template for Epic, add a work item rule on the transition from 'Proposed' to 'Committed' that requires approval from a member of the 'Compliance Officers' group.
B.Use a service hook to send an email to the compliance officers when an Epic is moved to 'Proposed', and rely on them to manually approve the transition.
C.Modify the Epic work item type to add a field 'Compliance Approval' and set the compliance officer as a required reviewer in the field settings.
D.Configure a branch policy on the main branch that requires approval from the 'Compliance Officers' group for pull requests.
AnswerA

This is the correct solution because Azure DevOps process template rules for work item types can enforce approvals on specific state transitions. Adding a rule to the Epic workflow that requires approval from the 'Compliance Officers' group when moving from 'Proposed' to 'Committed' ensures the transition cannot be completed without that group's authorization, directly enforcing the compliance gate at the work item level.

Why this answer

Azure DevOps process templates allow you to add work item rules on state transitions. By adding a rule on the 'Proposed' to 'Committed' transition for the Epic work item type that requires approval from a member of the 'Compliance Officers' group, you enforce the compliance policy without granting those officers direct edit permissions. This leverages built-in approval gates within the work item tracking system, minimizing administrative overhead.

Exam trap

The trap here is that candidates may confuse work item rules with branch policies or service hooks, mistakenly thinking that notification-based or code-review mechanisms can enforce work item state transitions.

How to eliminate wrong answers

Option B is wrong because a service hook only sends a notification; it does not enforce an approval gate or prevent the transition from occurring without approval, so the compliance policy would not be technically enforced. Option C is wrong because adding a custom field and setting a required reviewer does not create an approval workflow on the state transition; it merely adds a field that can be filled without blocking the transition, and compliance officers would still need direct edit access to modify the field. Option D is wrong because branch policies apply to pull requests on code repositories, not to work item state transitions, and are unrelated to the Scrum process or Epic work items.

Full explanation →
52
Multi-Selecteasy

You are configuring a YAML pipeline in Azure Pipelines. The pipeline must trigger only when changes are pushed to the main branch. Which setting should you configure?

Select 1 answer
A.Set the PR trigger to include main.
B.Set the pipeline to run on every push regardless of branch.
C.Use a schedule trigger with cron expression.
D.Set the trigger to include the main branch.
E.Set the trigger to none for other branches.
AnswersD

Setting the trigger to include the main branch is the standard and correct approach. In a YAML pipeline, the `trigger` section with `branches.include: [main]` defines a whitelist so that only pushes to the main branch start the pipeline. Any push to a branch not listed under `include` is implicitly ignored, giving precise control over which branches trigger CI.

Why this answer

In Azure Pipelines YAML, the `trigger` section controls which branches cause a CI pipeline to run. By setting `trigger.branches.include` to `main`, only pushes to `main` will trigger the pipeline. All other branches are automatically excluded.

There is no separate setting required to disable triggers for other branches; the include list is authoritative.

Exam trap

The trap is confusing CI triggers with PR triggers, or thinking that an include list also requires explicit exclusions. In YAML, an include list actually means only those branches are included, so no extra 'none' setting is needed.

Full explanation →
53
MCQeasy

You are designing a release pipeline for a mission-critical application. The pipeline must deploy to multiple environments (dev, test, prod) in sequence, with manual approval required before production deployment. Which Azure Pipelines feature should you use?

A.Pre-deployment approvals
B.Variable groups
C.Pipeline triggers
D.Deployment gates
AnswerA

Pre-deployment approvals define mandatory manual sign-off by designated approvers before a release is deployed to a stage. They act as a compliance checkpoint in the release pipeline and are distinct from automated gates, ensuring human oversight for mission-critical environments.

Why this answer

Pre-deployment approvals are the correct feature because they allow you to require manual sign-off before a release proceeds to a specific stage. In this scenario, you need a manual approval gate before production deployment, which is exactly what pre-deployment approvals enforce—the release pauses at the production stage until an authorized user approves it.

Exam trap

The trap here is that candidates often confuse pre-deployment approvals with deployment gates, thinking both are manual checks, but deployment gates are automated and based on external signals, not human approval.

How to eliminate wrong answers

Option B is wrong because variable groups store configuration values (like connection strings or secrets) and do not provide any approval or gating mechanism for deployment stages. Option C is wrong because pipeline triggers control when a pipeline starts (e.g., on code commit or schedule), not manual approval gates within a release. Option D is wrong because deployment gates are automated health checks (e.g., monitoring metrics or incident status) that evaluate conditions continuously, not manual approval steps requiring human intervention.

Full explanation →
54
MCQhard

Your team uses a monorepo in Azure Repos with multiple projects. You want to trigger a pipeline only when changes are made to a specific subfolder. Which configuration should you use?

A.Use a branch filter in the CI trigger.
B.Add a 'paths' filter to the CI trigger.
C.Configure the checkout step to only include the subfolder.
D.Use a 'file_match' condition on the job.
AnswerB

A paths filter on the CI trigger restricts pipeline execution to commits touching specified subfolders, so changes elsewhere in the monorepo are ignored. This directly satisfies the requirement to trigger only for a specific subfolder without splitting the repository.

Why this answer

Azure Pipelines CI triggers support a 'paths' filter that allows you to specify include or exclude patterns for file changes. When a monorepo contains multiple projects in separate subfolders, adding a 'paths' filter to the CI trigger ensures the pipeline only runs when changes are detected within that specific subfolder, avoiding unnecessary builds for unrelated projects.

Exam trap

The trap here is that candidates confuse the checkout step's sparse checkout or path filtering with trigger-level path filtering, mistakenly believing that limiting what is downloaded also prevents the pipeline from being triggered by changes outside that path.

How to eliminate wrong answers

Option A is wrong because a branch filter in the CI trigger controls which branches trigger the pipeline, not which file paths within the repository; it cannot restrict triggers to a specific subfolder. Option C is wrong because configuring the checkout step to only include the subfolder limits what files are downloaded to the agent, but it does not prevent the pipeline from being triggered by changes outside that subfolder; the trigger still fires on any change in the repo. Option D is wrong because Azure Pipelines does not support a 'file_match' condition on a job; path-based triggering is configured at the pipeline trigger level, not as a job condition.

Full explanation →
55
MCQeasy

Your build pipeline uses a hosted agent. You notice that every build starts with a clean workspace, increasing build time. You want to improve performance by caching the Node.js 'node_modules' folder. Which task should you add to the pipeline?

A.Publish Build Artifacts task
B.Copy Files task
C.Download Build Artifacts task
D.Cache task
AnswerD

The Cache task is designed exactly for this: it captures a specified folder after a run and restores it on subsequent runs using a defined key (typically a hash of package manifests) and cache hit variables. When the key matches, it avoids expensive re-downloads or recompilation, making it the correct way to persist dependency caches on hosted agents. Its whole purpose is cross-run reuse, unlike tasks that publish, copy, or download artifacts.

Why this answer

The Cache task (option D) is correct because it allows you to cache the 'node_modules' folder between pipeline runs on hosted agents, avoiding the need to reinstall dependencies from scratch each time. By specifying a cache key (e.g., based on package-lock.json) and the path to cache, subsequent builds can restore the folder from cache, significantly reducing build time.

Exam trap

The trap here is that candidates confuse the Cache task with artifact tasks (Publish/Download Build Artifacts), assuming artifacts can be used for caching, but artifacts are designed for immutable output storage and lack the key-based restoration and automatic eviction that the Cache task provides for performance optimization.

How to eliminate wrong answers

Option A is wrong because the Publish Build Artifacts task is used to store build outputs (e.g., compiled binaries) for later use or release, not for caching intermediate folders like node_modules across builds. Option B is wrong because the Copy Files task simply copies files from source to destination within the workspace, but does not persist them across pipeline runs or provide caching functionality. Option C is wrong because the Download Build Artifacts task retrieves previously published artifacts, but artifacts are immutable and not designed for the incremental, key-based caching of node_modules that the Cache task provides.

Full explanation →
56
MCQhard

Refer to the exhibit. You are deploying this ARM template using Azure Pipelines. The pipeline passes the parameter 'environmentName' with value 'prod'. What will be the name of the virtual network?

A.vnet-default
B.vnet-prod
C.vnet-prod-vnet
D.vnet-dev
AnswerB

The ARM template variable expression uses string concatenation to join the prefix 'vnet-' with the value of the environment parameter. Because the parameter is set to (or defaults to) 'prod', the variable correctly resolves to 'vnet-prod', which is the intended name for the virtual network.

Why this answer

The ARM template uses the `concat` function to combine the string 'vnet-' with the value of the `environmentName` parameter. Since the pipeline passes 'prod' for `environmentName`, the resulting virtual network name is 'vnet-prod'. This is a standard pattern for parameterizing resource names in Azure Resource Manager templates.

Exam trap

The trap here is that candidates may assume the parameter's default value ('dev') is used instead of recognizing that the pipeline explicitly overrides it with 'prod', leading them to incorrectly select 'vnet-dev'.

How to eliminate wrong answers

Option A is wrong because 'vnet-default' would only be the result if the `environmentName` parameter had a default value of 'default' and no override was provided, but the pipeline explicitly passes 'prod'. Option C is wrong because 'vnet-prod-vnet' would require an additional concatenation or a different expression, such as `concat('vnet-', parameters('environmentName'), '-vnet')`, which is not present in the template. Option D is wrong because 'vnet-dev' would only be produced if the parameter value were 'dev', but the pipeline passes 'prod'.

Full explanation →
57
MCQmedium

A team uses Azure Pipelines to build a .NET application. The build takes 30 minutes, and developers complain that the pipeline runs slowly. The pipeline uses the 'windows-latest' agent and installs the .NET SDK in each run. Which action would MOST reduce the build time?

A.Enable pipeline caching for the .NET SDK.
B.Deploy a self-hosted agent in Azure.
C.Increase the number of parallel jobs.
D.Change the agent pool to 'ubuntu-latest'.
AnswerA

Enabling pipeline caching for the .NET SDK stores the downloaded SDK and NuGet packages in a shared cache, so subsequent pipeline runs can reuse them instead of re-downloading and re-extracting the SDK from the network. This directly reduces the repetitive setup time that dominates the pipeline's build time, especially when the project specifies a pinned SDK version.

Why this answer

Enabling pipeline caching for the .NET SDK allows the SDK to be restored from a cache instead of being downloaded and installed on every run. This eliminates the recurring overhead of SDK installation, which is a significant portion of the 30-minute build time, directly addressing the slow pipeline complaint.

Exam trap

The trap here is that candidates often confuse reducing build time with scaling resources (parallel jobs or self-hosted agents) instead of recognizing that eliminating redundant work (SDK installation) via caching directly shortens the pipeline duration.

How to eliminate wrong answers

Option B is wrong because deploying a self-hosted agent does not reduce the time spent installing the .NET SDK; it only removes agent provisioning delays, and the SDK must still be installed each run unless caching is also used. Option C is wrong because increasing parallel jobs speeds up concurrent builds but does not reduce the duration of a single build pipeline. Option D is wrong because changing to 'ubuntu-latest' would require a different .NET SDK installation and may introduce compatibility issues, but the SDK still needs to be installed each run without caching, so build time would not be significantly reduced.

Full explanation →
58
Multi-Selectmedium

Which TWO conditions must be met for a self-hosted agent to be used in an Azure Pipelines agent pool? (Choose two.)

Select 2 answers
A.The agent must be in the Default pool.
B.The agent must have network access to Azure Pipelines.
C.The agent must run on Windows Server.
D.The agent must be installed on a virtual machine.
E.The agent must be registered with the agent pool.
AnswersB, E

A self-hosted agent must have outbound network connectivity to the Azure Pipelines service over HTTPS. This connection is required to poll for queued jobs, download task definitions and source code, and report execution status back to the service; without it the agent cannot participate in pipelines.

Why this answer

A self-hosted agent must have outbound network connectivity to Azure Pipelines (specifically to the Azure DevOps service endpoints) in order to receive job assignments, download tasks, and report status. Without this network access, the agent cannot communicate with the orchestration layer and will remain offline. This is a fundamental requirement for any agent, whether hosted or self-hosted.

Exam trap

The trap here is that candidates often assume self-hosted agents must be in the Default pool or run on a specific OS, but Azure Pipelines allows any pool and any supported OS (Windows, Linux, macOS) as long as the agent is registered and has network access.

Full explanation →
59
MCQhard

Your organization uses GitHub Actions for CI/CD. You need to implement a deployment strategy where a new version of the application is gradually shifted from the stable environment to a canary environment, and if health checks pass, the traffic is fully shifted to the canary. Which GitHub Actions deployment strategy should you use?

A.Recreate deployment
B.Canary deployment
C.Blue-green deployment
D.Rolling deployment
AnswerB

Canary deployment is correct because it gradually shifts traffic to the new version, starting with a small percentage, and promotes it only if health checks and key metrics pass. If the health checks fail partway through, the rollout can be halted or rolled back, and only the small canary slice of users has been exposed to the problematic version. This satisfies the requirement for a gradual, safer release with a limited blast radius and controlled promotion.

Why this answer

A canary deployment gradually shifts traffic from the stable environment to a new canary environment, using health checks to validate the new version before fully routing all traffic to it. This matches the requirement of a gradual shift with health-check gating. GitHub Actions supports this via deployment strategies like `canary` in environments or custom workflows with traffic-splitting tools.

Exam trap

The trap here is that candidates confuse canary deployment with blue-green deployment, assuming both involve a full cutover, but canary specifically requires gradual traffic shifting with health-check validation before full promotion.

How to eliminate wrong answers

Option A is wrong because a recreate deployment tears down the existing environment and deploys the new version all at once, with no gradual traffic shift or canary phase. Option C is wrong because a blue-green deployment swaps all traffic from the stable (blue) environment to the new (green) environment in one cutover, not gradually shifting traffic to a canary. Option D is wrong because a rolling deployment updates instances incrementally but does not typically use a separate canary environment with health-check gating before full traffic shift.

Full explanation →
60
MCQmedium

A team is migrating from TFVC to Git in Azure Repos. They have a large repository with a history of 10,000+ commits. They want to preserve the full history while minimizing migration time. Which approach should they recommend?

A.Use git-tfs to clone the TFVC repository with full history, then push to Azure Repos.
B.Check out the latest version from TFVC, initialize a new Git repo, and push.
C.Use the Azure Repos import repository feature to import from TFVC.
D.Clone the TFVC repository using Git and push to Azure Repos.
AnswerA

git-tfs is a tool that bridges TFVC and Git, allowing you to clone a TFVC repository including all changesets, branches, and history, converting them into Git commits. After cloning, you push the local Git repository to Azure Repos as a new Git repository, preserving the full migration history. This is the recommended approach when you need to retain historical context.

Why this answer

Git-tfs is a specialized bridge tool that can clone a TFVC repository with full history into a local Git repository, preserving all commits, branches, and metadata. This approach minimizes migration time by performing the conversion locally without network overhead, after which the Git repo can be pushed to Azure Repos. Other methods either lose history or are not supported for TFVC-to-Git migration.

Exam trap

The trap here is that candidates may assume Azure Repos has a built-in TFVC import feature (Option C) or that Git can natively clone TFVC (Option D), when in fact only git-tfs or similar third-party tools can perform a full-history migration from TFVC to Git.

How to eliminate wrong answers

Option B is wrong because checking out only the latest version from TFVC and initializing a new Git repo discards all historical commits, which violates the requirement to preserve full history. Option C is wrong because the Azure Repos import repository feature only supports importing from external Git repositories (e.g., GitHub, Bitbucket), not from TFVC. Option D is wrong because Git cannot directly clone a TFVC repository; TFVC uses a different version control protocol and data model, so a standard Git clone operation will fail.

Full explanation →
61
MCQmedium

You have a multi-stage YAML pipeline that builds and deploys a Java application. The pipeline runs on a Microsoft-hosted agent. The build stage fails intermittently with 'OutOfMemoryError: Java heap space'. What should you do to resolve this issue?

A.Set the environment variable 'MAVEN_OPTS' to '-Xmx2048m'.
B.Use a self-hosted agent with more memory.
C.Set the environment variable 'GRADLE_OPTS' to '-Xmx2048m'.
D.Use the 'Maven@3' task with the 'jdkVersion' option set to 'jdk11'.
AnswerA

Setting MAVEN_OPTS to -Xmx2048m explicitly sets the maximum JVM heap size for the Maven process, ensuring the build has 2GB of heap available and directly addressing the OutOfMemoryError during compilation or tests. This is the standard environment variable for passing JVM arguments to Maven, and -Xmx is the primary switch to increase heap space.

Why this answer

The 'OutOfMemoryError: Java heap space' in a Maven build indicates that the JVM running Maven needs more heap memory. Setting the environment variable 'MAVEN_OPTS' to '-Xmx2048m' increases the maximum heap size for the Maven JVM process to 2048 MB, which resolves the memory issue. This is the standard and correct approach for Maven-based builds.

Exam trap

The trap here is that candidates may confuse 'MAVEN_OPTS' with 'GRADLE_OPTS' or think that increasing agent memory (Option B) will automatically increase JVM heap, but the JVM heap is independent of physical memory and must be explicitly configured.

How to eliminate wrong answers

Option B is wrong because using a self-hosted agent with more memory does not directly address the JVM heap limit; the error is caused by insufficient heap allocated to the Maven process, not the agent's physical memory. Option C is wrong because 'GRADLE_OPTS' is used for Gradle builds, not Maven; setting it would have no effect on a Maven pipeline. Option D is wrong because changing the JDK version with the 'jdkVersion' option does not affect JVM heap settings; it only selects the Java Development Kit version for compilation.

Full explanation →
62
MCQmedium

You are implementing a release pipeline for a web application deployed to multiple Azure App Service instances across different regions (West US, East US, and North Europe). The deployment must follow a phased rollout: first West US, then East US, then North Europe, with a manual approval gate between each region. Each region should have its own slot for staging and production. You need to design the pipeline to minimize duplication of stages and tasks. What should you do?

A.Use a multi-stage YAML pipeline with environment per region and a manual approval on each environment.
B.Create three separate stages (one per region) and duplicate the deployment tasks in each.
C.Use a single stage with parallel deployment to all regions and add manual approvals before each region's deployment.
D.Use a single stage with a deployment group job that targets agents tagged with region names, and use deployment group tags to control phased rollout.
AnswerA

While this approach provides a manual approval gate per region via separate environments, it still requires the pipeline author to define and manage duplicate environment objects and job logic for each region, significantly increasing YAML complexity and maintenance burden compared to a single reusable job that targets tagged deployment group agents.

Why this answer

A multi-stage YAML pipeline with one environment per region and a manual approval check on each environment provides the phased rollout with approval gates while keeping stage definitions DRY through templates or repeated environment references. Environments in Azure DevOps natively support approval checks, so no duplicated approval logic is needed. This satisfies the minimize-duplication requirement.

Exam trap

AZ-400 often tests whether candidates confuse deployment groups (agent-tag-based targeting for on-prem) with environments (approval-gated deployment targets) — the manual approval requirement points to environments, not deployment groups.

How to eliminate wrong answers

Option B is wrong because duplicating deployment tasks across three separate stages increases maintenance burden and violates the minimize-duplication requirement, even though it could technically achieve phased rollout. Option C is wrong because a single stage with parallel deployment cannot enforce sequential regional rollout with approvals between regions — parallel jobs run concurrently, not in sequence. Option D is wrong because deployment groups target agents by tags for on-premises/IaaS scenarios and do not provide the environment-based approval gates or the App Service deployment slot semantics required here.

Full explanation →
63
MCQeasy

A team is using Azure Repos Git and wants to integrate their repository with Azure Boards so that they can create branches directly from work items and track commits and pull requests against those work items. What should they do?

A.Install the Azure Boards extension from the Visual Studio Marketplace and configure a service connection to the repository.
B.Create a YAML pipeline that uses the PublishWorkItem task to associate commits with work items.
C.Ensure the repository and the Azure Boards project are in the same Azure DevOps organization and project, then use work item links in commits and pull requests.
D.Enable the Boards integration from the repository settings by linking the repository to an Azure Boards project.
AnswerC

When a Git repository and an Azure Boards project are in the same Azure DevOps organization and project, the integration is active by default. Developers can reference work items with #ID syntax in commits and pull requests, and Azure Boards shows linked commits, branches, and pull requests without additional configuration. This satisfies the requirement out of the box.

Why this answer

Azure Repos and Azure Boards integrate automatically when they are in the same Azure DevOps organization and project. Developers can then use #ID references in commits and pull requests, create branches from work items, and view linked artifacts in Boards. No extension, service connection, or custom pipeline task is needed for this native integration.

Exam trap

The trap here is assuming that a marketplace extension or service connection must be installed to link Azure Repos with Azure Boards, when the integration is built in for repositories in the same organization and project.

Full explanation →
64
MCQhard

Your team uses Azure DevOps to deploy a Node.js web app to Azure App Service on Linux. The build pipeline runs `npm install` and `npm run build`, then publishes the `dist` folder. The release pipeline uses the 'Azure App Service deploy' task. Recently, deployments fail intermittently with 'ERR_MODULE_NOT_FOUND' for a custom module. The module is listed in `package.json` and is present in the `node_modules` folder on the build agent. What is the most likely cause?

A.The 'Azure App Service deploy' task modifies package.json during deployment.
B.The 'Azure App Service deploy' task runs npm install on the target, but it fails due to network restrictions.
C.The build artifact does not include node_modules; the app requires them at runtime.
D.The deployment slot's Kudu service fails to sync the dist folder.
AnswerC

The build artifact contains only the dist folder because the pipeline's publish step excluded node_modules, yet the Node.js app needs those dependencies at runtime to load modules. Without node_modules in the artifact, the deployed app cannot find required packages and fails to start, regardless of how the App Service deploy task behaves.

Why this answer

The most likely cause is that the build artifact does not include the `node_modules` folder. The build pipeline runs `npm install` and `npm run build`, which installs dependencies on the build agent, but only the `dist` folder is published as the artifact. At deployment time, the Azure App Service on Linux expects the `node_modules` folder to be present in the deployed artifact because it does not automatically run `npm install` for Node.js apps on Linux (unlike Windows-based App Services).

Without `node_modules`, the app cannot resolve custom modules at runtime, leading to the `ERR_MODULE_NOT_FOUND` error.

Exam trap

The trap here is that candidates often assume the Azure App Service deploy task automatically runs `npm install` on the target (like it does on Windows), but on Linux, the default behavior is to deploy the artifact as-is without dependency restoration unless explicitly configured.

How to eliminate wrong answers

Option A is wrong because the 'Azure App Service deploy' task does not modify `package.json` during deployment; it simply transfers the artifact to the target App Service. Option B is wrong because the 'Azure App Service deploy' task does not run `npm install` on the target for Linux App Service; it relies on the artifact containing all necessary dependencies. Option D is wrong because the Kudu service (which is a Windows-based deployment engine) is not used for Azure App Service on Linux; Linux App Service uses Oryx or direct artifact deployment, and the error is not related to sync failures of the `dist` folder.

Full explanation →
65
MCQeasy

You need to integrate security scanning into your build pipeline to detect vulnerable open-source dependencies. Which Azure DevOps extension should you use?

A.WhiteSource Bolt
B.Azure Policy
C.GitHub Advanced Security
D.SonarQube
AnswerA

WhiteSource Bolt is a build-task extension in Azure DevOps that scans open-source components from package managers like npm, NuGet, and Maven against the Whitesource vulnerability database, failing the pipeline on known CVEs and generating an inline report. It fits the requirement directly because it performs security scanning during the build, whereas other options either do not target open-source dependencies or are not integrated into Azure Pipelines.

Why this answer

WhiteSource Bolt is a free Azure DevOps extension that integrates directly into build pipelines to automatically scan open-source dependencies for known vulnerabilities. It identifies vulnerable components, provides remediation guidance, and enforces security policies without requiring additional configuration or external tools, making it the correct choice for this scenario.

Exam trap

The trap here is that candidates may confuse Azure Policy (a governance tool) or SonarQube (a code quality tool) with a dedicated dependency vulnerability scanner, overlooking that WhiteSource Bolt is purpose-built for open-source security scanning in Azure Pipelines.

How to eliminate wrong answers

Option B is wrong because Azure Policy is a governance tool for enforcing compliance rules on Azure resources (e.g., tagging, location restrictions), not a dependency scanner for open-source libraries in a build pipeline. Option C is wrong because GitHub Advanced Security is a suite of security features for GitHub repositories (including code scanning and secret scanning), but it is not an Azure DevOps extension and does not integrate directly into Azure Pipelines for dependency scanning. Option D is wrong because SonarQube is a code quality and static analysis tool that focuses on code smells, bugs, and technical debt, not specifically on detecting vulnerable open-source dependencies; it requires additional plugins or configurations to perform dependency scanning.

Full explanation →
66
MCQhard

Your organization uses GitHub Enterprise and wants to enforce that all repositories have a consistent CODEOWNERS file. Which approach should you use to centrally manage this?

A.Use repository rulesets to require that the CODEOWNERS file exists and has a specified pattern
B.Create a CODEOWNERS file at the organization level
C.Use a script to push CODEOWNERS to each repo manually
D.Create a GitHub Actions workflow that runs on push to check CODEOWNERS
AnswerB

CODEOWNERS is repository-specific; GitHub does not support an organization-level CODEOWNERS file that applies across repositories. Placing it at the organization level would have no effect on individual repository's code review ownership, so each repo must still contain its own file.

Why this answer

In GitHub Enterprise, you can create a special repository named `.github` at the organization level. A CODEOWNERS file stored in that repository is applied as a default to all repositories in the organization, providing centralized management. Repository rulesets cannot require that a file exists; they enforce branch/tag rules such as required reviews and status checks, but not file existence.

Exam trap

The trap is that candidates assume organization-level CODEOWNERS does not exist, or believe rulesets can enforce file existence. In reality, a .github repository with a CODEOWNERS file serves as the organization-wide default, while rulesets are not designed for this.

How to eliminate wrong answers

Option B is wrong because GitHub does not support a single organization-level CODEOWNERS file; CODEOWNERS must be defined per repository within a .github/ or root directory. Option C is wrong because manually pushing CODEOWNERS to each repo via a script is error-prone, lacks centralized enforcement, and does not prevent future non-compliance. Option D is wrong because a GitHub Actions workflow that runs on push to check CODEOWNERS only detects violations after the fact, rather than preventing non-compliant pushes or enforcing the file's existence proactively.

Full explanation →
67
Multi-Selectmedium

Which TWO actions should you take to ensure that your Git repository in Azure Repos remains performant as it grows?

Select 2 answers
A.Use shallow clones in CI/CD pipelines.
B.Store large binary files directly in the repository.
C.Use Git LFS for large binary files.
D.Keep all branches indefinitely to preserve history.
E.Encourage developers to commit all changes in a single commit per day.
AnswersA, C

Use `git clone --depth 1` or shallow fetch in CI/CD pipelines to retrieve only the most recent commit(s), drastically reducing clone time and disk usage since full history is rarely needed for build and test operations.

Why this answer

Shallow clones fetch only the most recent commit history rather than the entire repository history, which significantly reduces the amount of data transferred and stored during CI/CD pipeline runs. This keeps pipeline execution fast and avoids performance degradation as the repository grows. Azure Repos and Azure Pipelines support shallow clone options via the `--depth` parameter in Git commands or through pipeline YAML settings.

Exam trap

The trap here is that candidates may think storing binaries directly in the repo is acceptable for performance, or that reducing commit frequency improves performance, when in fact these actions degrade performance or violate source control best practices.

Full explanation →
68
MCQmedium

You are an Azure DevOps administrator for a team that wants to automatically link work items to pull requests in Azure Repos. The team uses a single Git repository and requires that every pull request has at least one linked work item before it can be completed. You need to configure the repository settings to enforce this requirement. What should you do?

A.Add a required template to the pull request description that includes a work item ID field.
B.Configure a branch policy that requires a minimum number of reviewers.
C.Enable the 'Check for linked work items' setting in the repository's policies.
D.Create a work item query that lists all pull requests without linked work items.
AnswerC

This setting, found under Repos > Policies, enforces that every pull request must have at least one linked work item before it can be completed. It directly satisfies the requirement to automatically link work items and prevent completion without them. Enabling this policy ensures compliance with the team's process without manual intervention.

Why this answer

Enabling the 'Check for linked work items' policy in Azure Repos ensures that every pull request must have at least one linked work item before completion. This directly enforces the team's requirement, unlike reviewer policies, queries, or templates, which do not prevent completion without a link. The policy is configured per repository and is the standard method for this enforcement.

Exam trap

The trap here is confusing code review policies with work item linking policies, assuming that any branch policy can enforce work item association.

Full explanation →
69
MCQeasy

The exhibit shows an Azure CLI command to run a pipeline. What does this command do?

A.Runs the pipeline on all branches with the variable.
B.Runs the pipeline and sets a secret variable.
C.Runs the pipeline named 'MyPipeline' on the 'main' branch with a variable 'myVar' set to 'value1'.
D.Creates a new pipeline named 'MyPipeline' with a variable.
AnswerC

This option correctly describes `az pipelines run --name MyPipeline --branch main --variables myVar=value1`: it triggers an existing pipeline definition named `MyPipeline`, targets the `main` branch, and injects a non-secret variable `myVar` with the value `value1` for that run.

Why this answer

The Azure CLI command `az pipelines run --name MyPipeline --branch main --variables myVar=value1` triggers an existing pipeline named 'MyPipeline' on the 'main' branch, passing a plain-text variable 'myVar' with the value 'value1'. The `--variables` parameter sets pipeline variables at runtime, but they are not automatically marked as secret; to set a secret variable, you must use the `--secret-variables` parameter instead. This matches option C exactly.

Exam trap

The trap here is that candidates confuse the `--variables` parameter with `--secret-variables`, assuming all variables passed at runtime are automatically secured, when in fact Azure CLI requires an explicit flag to treat them as secret.

How to eliminate wrong answers

Option A is wrong because the command specifies a single branch (`--branch main`), not 'all branches'; running on all branches would require omitting the `--branch` parameter or using a wildcard, which Azure CLI does not support. Option B is wrong because the `--variables` parameter sets a plain-text variable, not a secret variable; to set a secret variable, you must use the `--secret-variables` parameter (e.g., `--secret-variables mySecret=value`). Option D is wrong because `az pipelines run` triggers an existing pipeline, it does not create a new one; creating a pipeline requires the `az pipelines create` command.

Full explanation →
70
MCQmedium

You are deploying a Java application to Azure App Service using Azure Pipelines. You want to automatically capture JVM metrics (heap usage, garbage collection) and correlate them with deployment events. What should you do?

A.Use Azure Monitor diagnostic settings for the App Service.
B.Enable Application Insights Java agent in the App Service.
C.Attach a profiler from Visual Studio to the App Service process.
D.Configure App Service diagnostic logs to capture stdout/stderr.
AnswerB

The Application Insights Java agent (javaagent) attaches to the JVM at startup and automatically collects JVM metrics such as heap memory, GC pauses, thread count, and class loading, along with distributed traces and custom telemetry, making it the correct and minimally invasive approach for monitoring a Java app on App Service.

Why this answer

To automatically capture JVM metrics (heap usage, garbage collection) and correlate them with deployment events, you should enable the Application Insights Java agent in the App Service. The Java agent auto-instruments the JVM, collecting detailed metrics and telemetry without code changes. Application Insights integrates with Azure Pipelines, allowing deployment annotations to be correlated with telemetry.

Exam trap

AZ-400 often tests the distinction between platform-level monitoring and application-level APM; candidates may choose Azure Monitor diagnostic settings or stdout logs, missing the need for JVM-specific instrumentation.

How to eliminate wrong answers

Option A is wrong because Azure Monitor diagnostic settings for App Service capture platform-level logs and metrics, but not JVM-specific metrics like heap usage or garbage collection. Option C is wrong because attaching a profiler from Visual Studio is a manual, interactive debugging session, not an automated monitoring solution. Option D is wrong because App Service diagnostic logs capture stdout/stderr and HTTP logs, but not JVM metrics; they are not designed for deep JVM monitoring.

Full explanation →
71
MCQhard

Your team manages a large-scale microservices application deployed on Azure Kubernetes Service (AKS). The code is hosted in Azure Repos, and you use Azure Pipelines for CI/CD. You have recently adopted GitHub Copilot for code suggestions. Your compliance team requires that all pipeline runs include a security scan using Microsoft Defender for Cloud. Additionally, all pull requests must have at least two reviewers from separate teams before merging. The current pipeline completes in 45 minutes, and you want to minimize overhead. You need to design a process that enforces these requirements without degrading developer productivity. Which approach should you recommend?

A.Configure a branch policy on the main branch that requires a successful build and security scan before merging, and use a single pipeline that includes the scan.
B.Integrate the security scan as a step early in the CI pipeline, and configure branch policies on the main branch to require two reviewers from different teams and a successful CI build including the scan. Document the process and use Copilot to generate commit messages that reference work items.
C.Create a separate security scan pipeline triggered on pull request creation, and require its successful completion via branch policy. Then set up a separate PR policy requiring two reviewers.
D.Add a manual approval gate in the release pipeline that requires the security officer to approve after the scan completes.
AnswerB

This is the optimal solution because it embeds the security scan as an early CI step, ensuring vulnerabilities are detected immediately after code is pushed, and branch policies explicitly require two reviewers from different teams plus a successful pipeline run. Configuring the scan as part of the CI build avoids extra pipeline overhead and eliminates parallel wait times, while branch policies for reviewers are applied automatically on every pull request. Using Copilot to generate commit messages that reference work items enhances traceability without additional manual effort, ensuring that every change can be linked to a work item. This approach efficiently enforces both the scan and the review policy with minimal complexity.

Why this answer

It integrates the security scan early in the CI pipeline, ensuring it runs on every build without adding a separate pipeline overhead. Branch policies enforce both the required two reviewers from different teams and the successful CI build (including the scan) before merging, which minimizes additional pipeline complexity and maintains developer productivity.

Exam trap

The trap here is that candidates may think a separate security scan pipeline (Option C) is necessary for compliance, but Azure Pipelines allows integrating the scan into the existing CI pipeline, which is more efficient and still meets the requirement of running on every pull request.

How to eliminate wrong answers

Option A is wrong because it only requires a successful build and security scan before merging but does not enforce the mandatory two-reviewer requirement from separate teams, which is a compliance necessity. Option C is wrong because creating a separate security scan pipeline triggered on pull request creation adds unnecessary overhead and complexity, degrading developer productivity compared to integrating the scan into the existing CI pipeline. Option D is wrong because a manual approval gate in the release pipeline occurs after the build and scan, which does not enforce the scan requirement on every pull request before merging, and it introduces a bottleneck that reduces productivity.

Full explanation →
72
MCQhard

Your organization uses GitHub Actions for CI/CD. You need to ensure that deployment to production only occurs after a successful deployment to a staging environment and requires approval from a senior developer. The deployment workflow is defined in a single YAML file. What is the most efficient way to achieve this?

A.Add a step that pauses the pipeline until a manual approval is received via a custom webhook.
B.Use a workflow_dispatch trigger and require the senior developer to manually run the production deployment.
C.Use a build matrix to run staging and production deployments in parallel.
D.Use two environments (staging and production) with required reviewers on the production environment, and use conditional steps to deploy to staging first.
AnswerD

GitHub environments hold protection rules, so the production environment's required reviewers gate the job until a senior developer approves. Staging deploys first via job ordering, satisfying both the sequencing and approval constraints within one YAML workflow.

Why this answer

GitHub Actions supports deployment environments with required reviewers. By defining separate 'staging' and 'production' environments, you can use a conditional step to deploy to staging first, and then require manual approval from a senior developer before the production deployment proceeds. This approach is built into GitHub Actions and does not require external webhooks or manual workflow triggers, making it the most efficient and secure method.

Exam trap

The trap here is that candidates may think a build matrix or manual trigger is sufficient, but they overlook the need for sequential deployment and built-in approval gating, which is exactly what GitHub Environments with required reviewers provide.

How to eliminate wrong answers

Option A is wrong because pausing a pipeline via a custom webhook is not a native GitHub Actions feature; it would require building and maintaining external infrastructure, which is inefficient and error-prone. Option B is wrong because using a workflow_dispatch trigger requires the senior developer to manually run the workflow, which bypasses the staging deployment check and does not enforce the sequential dependency (staging must succeed first). Option C is wrong because a build matrix runs jobs in parallel, but the requirement is for staging to complete before production; parallel execution would allow production deployment without staging success, violating the sequential dependency.

Full explanation →
73
MCQmedium

Your company uses Microsoft Sentinel for security monitoring. Azure DevOps pipelines deploy resources to production. You need to create an automated response that triggers when Sentinel detects a high-severity alert related to unauthorized pipeline changes. The response should temporarily disable the service connection used by the pipeline and notify the security team. What should you do?

A.Configure a Sentinel analytics rule with the alert and use automated response to send an email.
B.Set up an Azure DevOps service hook that triggers on pipeline events.
C.Use Azure Policy to deny changes to service connections.
D.Create a Sentinel playbook using Azure Logic Apps that calls the Azure DevOps REST API to update the service connection status.
AnswerD

This is correct because a Sentinel playbook is an Azure Logic Apps workflow specifically designed to automate incident response to Sentinel alerts. By calling the Azure DevOps REST API endpoint for service endpoints (e.g., PUT https://dev.azure.com/{organization}/{project}/_apis/serviceendpoint/endpoints/{endpointId}?api-version=7.1) and setting the `isReady` field to false or updating the service endpoint status to disabled, the playbook can immediately revoke access. It can also send a notification email afterwards, satisfying both the disable and notify requirements in a single automated response.

Why this answer

A Sentinel playbook built with Azure Logic Apps can be triggered by a Sentinel alert and execute custom actions, such as calling the Azure DevOps REST API to disable a service connection and sending notifications. This provides the automated response required. The playbook integrates with Sentinel's automation rules to run when the high-severity alert fires.

Exam trap

AZ-400 often tests the confusion between notification-only responses and actual remediation actions; candidates may pick email alerts thinking they satisfy 'automated response' when the question requires disabling a resource.

How to eliminate wrong answers

Option A is wrong because sending an email only notifies; it does not disable the service connection. Option B is wrong because an Azure DevOps service hook triggers on pipeline events, not on Sentinel alerts, and cannot disable a service connection. Option C is wrong because Azure Policy denies changes to resources but does not respond to security alerts or disable existing service connections.

Full explanation →
74
MCQeasy

You need to monitor the health of your Azure Pipeline agents. Which Azure DevOps Analytics view should you use to identify agents that have not reported in the last hour?

A.Agent Health dashboard
B.Release Analytics
C.Test Analytics
D.Pipeline Run Analytics
AnswerA

The Agent Health dashboard in Azure DevOps provides a real-time view of pipeline agents, including their status (online/offline), enabled state, and the last time the agent contacted the service. It is the appropriate tool for monitoring agent health, as it directly surfaces connectivity and availability issues for both Microsoft-hosted and self-hosted agents.

Why this answer

The Agent Health dashboard in Azure DevOps provides real-time status of pipeline agents, including their last communication timestamp. By filtering for agents that have not reported in the last hour, you can identify unhealthy or disconnected agents. This dashboard directly surfaces agent connectivity and health metrics.

Note that this is a dashboard, not an Analytics view like Release Analytics, Test Analytics, or Pipeline Run Analytics.

Exam trap

Candidates may confuse 'Release Analytics' or 'Pipeline Run Analytics' with agent health monitoring, because they assume any analytics view related to pipelines would include agent status, but Azure DevOps separates agent infrastructure health (monitored via the Agent Health dashboard) from pipeline execution analytics.

How to eliminate wrong answers

Option B (Release Analytics) is wrong because it focuses on release pipeline performance metrics (e.g., deployment frequency, lead time) and does not expose agent-level health or connectivity status. Option C (Test Analytics) is wrong because it provides insights into test results, pass rates, and test execution trends, not agent reporting or health. Option D (Pipeline Run Analytics) is wrong because it analyzes pipeline run durations, success rates, and stage-level metrics, but does not include agent heartbeat or last-reported-time data.

Full explanation →
75
MCQhard

You are evaluating an Azure Policy assignment for Azure Pipelines. What does this policy audit?

A.Whether secure files are rotated within 90 days
B.Whether pipelines use secure files with extensions other than .pfx, .p12, or .cer
C.Whether secure files are encrypted at rest
D.Whether secure files are used in production pipelines
AnswerB

The policy is designed to audit which file extensions are allowed for secure files in Azure Pipelines, specifically restricting to .pfx, .p12, or .cer. Any secure file with a different extension (e.g., .txt, .key, .pem) would be non-compliant. This directly matches the policy's scope of validating file types used as secure inputs.

Why this answer

The Azure Policy for Azure Pipelines audits whether secure files have file extensions other than .pfx, .p12, or .cer. This policy is designed to enforce that only certificate-related secure files (which are typically used for code signing or TLS) are allowed, preventing the upload of arbitrary file types that could introduce security risks or misconfiguration.

Exam trap

The trap here is that candidates may confuse the audit of file extensions with other security controls like encryption or rotation, leading them to select options that describe general best practices rather than the specific policy behavior.

How to eliminate wrong answers

Option A is wrong because Azure Policy does not audit rotation intervals for secure files; rotation policies are managed separately via pipeline settings or manual processes, not through built-in policy definitions. Option C is wrong because encryption at rest for secure files is a platform-level guarantee provided by Azure DevOps (using Azure Storage encryption), not something that Azure Policy audits—the policy focuses on file extension compliance, not encryption status. Option D is wrong because the policy does not differentiate between production and non-production pipelines; it applies to all pipelines using secure files, regardless of environment, and audits the file extension, not the pipeline usage context.

Full explanation →

Page 1 of 10

Page 2

All pages

12345678910

Practice AZ-400 by domain

Target a specific domain to shore up weak areas.

Design and implement source controlConfigure processes and communicationsDevelop a security and compliance planImplement an instrumentation strategyDesign and implement build and release pipelinesDesign and implement a source control strategy
See all domains with question counts →