Microsoft Azure DevOps Engineer Expert AZ-400 AZ-400 Questions 76–150 | Page 2/10

MCQhard

Your company uses GitHub Enterprise and wants to implement a secret scanning policy to detect and block secrets (e.g., API keys) in code pushes. The policy must allow exceptions for test repositories that use fake secrets. What is the recommended approach?

A.Use a pre-commit hook to detect secrets and allow developers to bypass it.

B.Implement a GitHub Actions workflow that scans for secrets and fails the push.

C.Enable secret scanning for all repositories, then manually disable it for test repositories.

D.Configure secret scanning with custom patterns and use the 'secret_scanning_push_protection' setting with an allow-list for test repositories.

AnswerD

Secret scanning with custom patterns is a server-side, centrally enforced feature that can detect organization-specific secrets, and enabling the `secret_scanning_push_protection` setting blocks pushes containing matching secrets while an allow-list lets you exempt designated test repositories from the block without disabling detection—so real secrets are blocked, and test exceptions are managed predictably.

Why this answer

GitHub Enterprise's secret scanning push protection can be configured with custom patterns and an allow-list (via the `secret_scanning_push_protection` setting in the repository's security settings or through the API). This allows you to block pushes containing secrets across all repositories while explicitly exempting test repositories that use fake secrets, meeting the requirement for exceptions without manual intervention.

Exam trap

The trap here is that candidates confuse client-side pre-commit hooks (which are bypassable) with server-side push protection (which is enforced), or mistakenly think GitHub Actions can block a push before it completes.

How to eliminate wrong answers

Option A is wrong because pre-commit hooks are client-side and can be bypassed by developers (e.g., using `--no-verify`), providing no enforcement at the server level. Option B is wrong because GitHub Actions workflows run after a push is accepted, not before; they cannot block the push itself, only react to it (e.g., by creating an issue). Option C is wrong because manually disabling secret scanning for test repositories is not scalable and violates the requirement for a policy that automatically allows exceptions; it also does not leverage the push protection feature to block secrets in non-test repos.

Full explanation →

MCQmedium

Your team uses a multi-stage YAML pipeline in Azure Pipelines. The pipeline includes a stage that runs integration tests against a test environment. You want to ensure that the integration tests are not affected by other pipelines that deploy to the same environment concurrently. What should you implement?

A.Set the environment's 'Exclusive lock' check to enabled.

B.Set the pipeline's 'Maximum number of parallel deployments' to 1.

C.Configure a required template check on the environment.

D.Add a manual approval check on the environment.

AnswerA

Enabling the Exclusive lock check on an environment in Azure DevOps ensures that only one pipeline run can deploy to that environment at a time; any other runs that attempt to acquire the lock are queued until the current run releases it, providing the required concurrency control without limiting deployments across unrelated environments.

Why this answer

The 'Exclusive lock' check on an environment ensures that only one pipeline deployment can use that environment at a time. When enabled, Azure Pipelines will queue any other pipeline runs that target the same environment, preventing concurrent deployments that could interfere with integration tests. This directly addresses the requirement to avoid conflicts from parallel deployments.

Exam trap

The trap here is confusing pipeline-level concurrency limits (Option B) with environment-level exclusive access, leading candidates to think limiting a single pipeline's parallelism is sufficient when multiple pipelines could still collide.

How to eliminate wrong answers

Option B is wrong because setting 'Maximum number of parallel deployments' on the pipeline limits the number of concurrent runs of that specific pipeline, but does not prevent other pipelines from deploying to the same environment simultaneously. Option C is wrong because a required template check enforces that a specific YAML template is used in the pipeline, but does not control concurrency or access to the environment. Option D is wrong because a manual approval check pauses the deployment for human approval but does not prevent concurrent deployments from other pipelines once approved; it does not provide exclusive access.

Full explanation →

Multi-Selecthard

Your organization uses GitHub for source control. You need to implement a secure source control strategy that prevents secrets from being exposed and ensures code quality. Which THREE practices should you implement?

Select 3 answers

A.Configure branch protection rules requiring status checks to pass

B.Store secrets in a .env file committed to the repository

C.Require commit signing using GPG keys

D.Enable GitHub secret scanning for the repository

E.Use pre-commit hooks to scan for secrets before commits

AnswersA, D, E

Configure branch protection rules to require status checks to pass, so pull requests cannot be merged unless the specified CI checks (e.g., tests, builds, and linting) succeed. This enforces code quality gates automatically, ensuring that only code meeting defined criteria is integrated into the main branch.

Why this answer

Branch protection rules enforce required status checks (e.g., CI builds, code reviews) before merging, ensuring only validated changes enter protected branches—this supports code quality. GitHub secret scanning automatically detects known types of secrets in repositories and alerts on exposure, directly preventing secret leaks. Pre-commit hooks scan code for secrets before a commit is created, blocking accidental commits of credentials or tokens.

Together, A, D, and E address both secret prevention and code quality. Commit signing (C) verifies authorship but does not prevent secret exposure or enforce code quality checks.

Exam trap

The trap here is that candidates may confuse commit signing (which ensures authenticity) with secret scanning or code quality enforcement, leading them to select option C instead of recognizing that it does not address the stated goals of preventing secret exposure or ensuring code quality.

Full explanation →

Multi-Selectmedium

Which THREE practices help ensure that work item tracking is effective in Azure Boards?

Select 3 answers

A.Avoid customizing work item types to maintain consistency.

B.Link work items to code changes and pull requests.

C.Keep work items small and granular.

D.Regularly update work item fields (e.g., Remaining Work).

E.Create large work items that cover multiple features.

AnswersB, C, D

Linking work items to commits and pull requests creates traceability between planned work and delivered code, satisfying the requirement for effective tracking. Azure Boards then surfaces development links on the work item, so reviewers and auditors can verify which changes implemented each requirement without manual cross-referencing.

Why this answer

Linking work items to code changes and pull requests creates a traceable path from requirements to implementation, enabling teams to understand the context of changes and automatically update work item status (e.g., via GitHub integration or Azure Repos). Keeping work items small and granular allows for accurate estimation, faster delivery, and meaningful progress tracking; large items hide complexity and make it difficult to measure velocity. Regularly updating fields such as Remaining Work ensures that burndown charts and sprint reports reflect reality, supporting accurate forecasting and early detection of issues.

Exam trap

The trap here is that candidates may think customizing work item types is always harmful (Option A) or that large work items simplify tracking (Option E), but Azure Boards is designed to be flexible and granularity is key for effective Agile metrics like velocity and burndown.

Full explanation →

Multi-Selecthard

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

Select 3 answers

A.An Azure Resource Manager service connection.

B.A YAML pipeline definition.

C.The Azure Pipelines agent software installed on the machine.

D.A virtual machine or physical server to host the agent.

E.A personal access token (PAT) with agent pool management permissions.

AnswersC, D, E

The Azure Pipelines agent software is the core executable that runs on the self-hosted machine to request work from Azure DevOps and execute pipeline jobs. Without this software installed, the machine cannot act as an agent, so it is an essential component for implementing a self-hosted agent.

Why this answer

The Azure Pipelines agent software is the core component that executes pipeline jobs on the self-hosted machine. Without installing the agent software (via the agent configuration script), the machine cannot register with Azure Pipelines or run any tasks, making it a mandatory requirement for a self-hosted agent pool.

Exam trap

The trap here is that candidates often confuse the authentication method for the agent (PAT) with the service connection used for Azure resource deployments, leading them to incorrectly select the ARM service connection as a required component.

Full explanation →

MCQhard

Your Azure Pipeline is configured as shown in the exhibit. A developer pushes a commit to a feature branch named 'feature/new-login' and creates a pull request targeting the main branch. Which pipeline runs will be triggered?

A.No pipeline runs

B.Only a PR build

C.Only a CI build on the feature branch

D.Both a CI build on the feature branch and a PR build

AnswerB

Branch policies configured for the main branch trigger a PR build when a pull request targets main, validating the merge before completion. Because no CI trigger matches the feature branch push itself, only the PR build run is queued.

Why this answer

The pipeline is configured with a PR trigger that activates on pull requests targeting the main branch. When a developer pushes a commit to 'feature/new-login' and creates a PR to main, only the PR build is triggered. The CI trigger is not configured for the feature branch (only for main), so no CI build runs on the feature branch itself.

Exam trap

The trap here is that candidates often assume a push to a feature branch automatically triggers a CI build, but the CI trigger's branch filter must explicitly include the branch; otherwise, only the PR trigger (if configured) will fire.

How to eliminate wrong answers

Option A is wrong because a PR trigger is configured, so a pipeline run does occur. Option C is wrong because the CI trigger is set to only trigger on the main branch, not on feature branches like 'feature/new-login'. Option D is wrong because the CI trigger does not apply to the feature branch, so only the PR build runs, not both.

Full explanation →

MCQhard

Your organization uses Azure Repos and requires that all code changes pass a security scan before merging. The scan is run as a build validation policy. However, the scan takes 30 minutes and developers often bypass it by pushing directly to main. How can you enforce the policy for all changes?

A.Turn off direct push permissions for all users and force all changes through pull requests

B.Delete the main branch and recreate it as a protected branch

C.Set a branch policy on main that requires a build validation with the security scan

D.Use a service hook to run the scan on every push to main

AnswerC

Setting a branch policy on main that requires a build validation is the correct approach because Azure DevOps will run the specified security scan pipeline for every pull request targeting main and block the merge if the scan fails. Additionally, branch policies enforce the scan on every push to main and prevent bypasses, ensuring all code that enters the protected branch has passed the mandatory security validation.

Why this answer

Setting a branch policy on main that requires a build validation with the security scan enforces the scan as a mandatory gate for all pull requests targeting main. This prevents developers from bypassing the scan by pushing directly, as the policy blocks direct pushes and only allows changes through pull requests that must pass the configured build validation.

Exam trap

The trap here is that candidates may think a service hook or simply disabling direct pushes is sufficient, but they fail to recognize that only a branch policy with a required build validation can enforce the scan as a gate for all changes.

How to eliminate wrong answers

Option A is wrong because turning off direct push permissions for all users does not by itself enforce the security scan; it only prevents direct pushes, but changes could still be merged via pull requests without the scan if no policy requires it. Option B is wrong because deleting and recreating the main branch as a protected branch does not enforce the security scan; it only resets branch protections, and without a build validation policy, the scan is not required. Option D is wrong because using a service hook to run the scan on every push to main does not block the push if the scan fails; service hooks are asynchronous and cannot enforce policy, so developers can still push directly and bypass the scan.

Full explanation →

MCQhard

Your organization uses GitHub Flow with branch protections. Developers must link every pull request to an issue using a closing keyword (e.g., 'Fixes #123'). You need to enforce this linking automatically. What should you do?

A.Create a GitHub Actions workflow that validates the PR description contains a closing keyword.

B.Configure an issue template with a closing keyword prompt.

C.Add a branch protection rule requiring a linked issue.

D.Use a required status check from a third-party app.

AnswerA

A GitHub Actions workflow can be triggered on the pull_request event and inspect the PR description for a closing keyword such as 'closes', 'fixes', or 'resolves' followed by an issue number. The workflow can use a regex or a simple string check to validate the pattern, and then be configured as a required status check in branch protection, making it a reliable first-party enforcement mechanism.

Why this answer

A GitHub Actions workflow can be configured to run on pull request events and parse the PR description for a closing keyword pattern (e.g., regex matching 'Fixes #\d+'). If the keyword is missing, the workflow can fail the check, blocking the merge via branch protection rules that require status checks to pass. This directly enforces the linking requirement without relying on human compliance or third-party tools.

Exam trap

The trap here is that candidates often confuse the 'Require a linked issue' branch protection rule (which only enforces a UI-based link) with the need to validate the PR description text for a closing keyword, leading them to incorrectly select option C.

How to eliminate wrong answers

Option B is wrong because an issue template only provides a prompt for creating new issues; it does not enforce that existing pull requests reference an issue via a closing keyword. Option C is wrong because GitHub's branch protection rule for 'Require a linked issue' only checks that a PR has an issue linked via the GitHub UI (the sidebar), not that the PR description contains a closing keyword like 'Fixes #123'. Option D is wrong because a required status check from a third-party app would still need to be implemented to validate the closing keyword; the option is too vague and does not specify a concrete enforcement mechanism, whereas a GitHub Actions workflow is the direct, built-in solution.

Full explanation →

MCQeasy

You are creating a release pipeline that deploys to Azure App Service. You want to ensure that the deployment uses the 'Run from package' feature for faster deployments and reduced downtime. Which deployment method should you select in the 'Azure App Service deploy' task?

A.Web Deploy

B.Container

C.RunFromPackage

D.Zip Deploy

AnswerC

RunFromPackage is the correct deployment method for Azure Functions because it deploys a zip package and sets the WEBSITE_RUN_FROM_PACKAGE app setting, which makes the function app run directly from the mounted zip blob. This approach provides benefits like atomic deployment, faster startup, and avoids file lock issues, and it is the recommended deployment mechanism for Azure Functions.

Why this answer

The 'Run from package' feature deploys your app as a zip package directly to Azure App Service, bypassing the file copy and compilation steps of traditional methods. This reduces deployment time and downtime because the app runs from the package without extracting it to the wwwroot folder. Selecting 'RunFromPackage' in the Azure App Service deploy task enables this behavior by setting the WEBSITE_RUN_FROM_PACKAGE app setting to 1.

Exam trap

The trap here is that candidates confuse 'Zip Deploy' with 'Run from package' because both use zip files, but Zip Deploy extracts the package to wwwroot, while Run from package runs directly from the zip, offering faster deployments and reduced downtime.

How to eliminate wrong answers

Option A is wrong because Web Deploy (msdeploy) performs incremental file synchronization and can cause longer deployment times and potential downtime due to file locking. Option B is wrong because Container deployment is used for deploying Docker containers to App Service, not for deploying code packages with the 'Run from package' feature. Option D is wrong because Zip Deploy extracts the zip package to the wwwroot folder, which can lead to file locking and slower deployments compared to running directly from the package.

Full explanation →

MCQmedium

You need to implement a compliance framework that ensures Azure Pipelines build agents are always patched with the latest security updates. What should you use?

A.Azure Update Management to schedule patching

B.Azure VM Image Builder to create patched images

C.Azure Policy to enforce that agents must be patched

D.Azure Automation State Configuration to enforce desired state

AnswerA

Azure Update Management, part of Azure Automation, is the appropriate solution here because it directly schedules and orchestrates the installation of OS updates on Azure VMs and on-premises servers, with compliance reporting and maintenance window control.

Why this answer

Azure Update Management is the correct choice because it provides a native, scheduled patching solution for Azure Pipelines build agents. It integrates with Azure Automation and Log Analytics to assess missing updates and deploy them on a recurring schedule, ensuring agents remain compliant with the latest security patches without manual intervention.

Exam trap

The trap here is that candidates often confuse 'enforcing compliance' (Azure Policy) with 'actually performing the patching action' (Azure Update Management), or they mistake image creation (VM Image Builder) for ongoing patch management, leading them to select a tool that only audits or provisions rather than schedules updates.

How to eliminate wrong answers

Option B is wrong because Azure VM Image Builder creates and maintains custom VM images with pre-applied patches, but it does not provide ongoing, scheduled patching for existing build agents; it is used for image lifecycle management, not runtime patching. Option C is wrong because Azure Policy enforces compliance rules (e.g., requiring agents to be patched) but cannot actually deploy patches; it only audits or denies non-compliant resources, leaving the patching action unaddressed. Option D is wrong because Azure Automation State Configuration (DSC) enforces a desired state configuration (e.g., ensuring specific software is installed), but it is not designed for recurring security update deployment; it focuses on configuration drift correction rather than scheduled patch management.

Full explanation →

MCQmedium

Your team uses GitHub Actions to build and deploy a static website to Azure Storage. The workflow uses the 'azure/storage-blob-upload' action to deploy to a storage account static website. Recently, deployments started failing with 'Error: Failed to get credentials'. The workflow uses OpenID Connect (OIDC) for authentication. What is the most likely cause?

A.The service principal used for OIDC does not have the 'Storage Blob Data Contributor' role on the storage account.

B.The storage account firewall is blocking the GitHub Actions IP range.

C.The OIDC configuration in GitHub is missing the 'client secret' field.

D.The 'azure/storage-blob-upload' action does not support static websites.

AnswerA

OIDC only authenticates the GitHub workflow as the service principal; for the upload to succeed, that principal must also be authorized for data operations. Without the 'Storage Blob Data Contributor' role assigned on the storage account (or a containing scope), Azure returns an authorization failure even though authentication succeeded.

Why this answer

The 'azure/storage-blob-upload' action requires the service principal used for OIDC authentication to have the 'Storage Blob Data Contributor' role on the storage account to upload static website content. Without this role, the action fails to obtain credentials for blob write operations, resulting in the 'Failed to get credentials' error.

Exam trap

The trap here is that candidates often confuse authentication (OIDC token exchange) with authorization (role assignment), assuming a valid OIDC configuration automatically grants access, when in fact the service principal must have the appropriate Azure RBAC role on the target resource.

How to eliminate wrong answers

Option B is wrong because a storage account firewall blocking GitHub Actions IP ranges would cause a network connectivity error (e.g., '403 Forbidden' or timeout), not a credential retrieval failure. Option C is wrong because OIDC authentication in GitHub Actions does not use a client secret; it relies on a federated identity credential and token exchange, so a missing client secret is irrelevant. Option D is wrong because the 'azure/webapps-deploy' action fully supports deploying to Azure Storage static websites when the correct role and permissions are configured.

Full explanation →

Multi-Selecthard

Which THREE practices are recommended for managing technical debt in a DevOps environment?

Select 3 answers

A.Allocate time for refactoring in each iteration

B.Defer unit tests until after deployment

C.Automate unit and integration tests

D.Integrate static code analysis into the CI pipeline

E.Ignore low-priority code smells

AnswersA, C, D

Incrementally dedicating a fixed amount of time to refactoring within each sprint or iteration—often called the 'boy scout rule'—prevents technical debt from accumulating and keeps the codebase maintainable. This continuous small-scale design improvement reduces the risk of large-scale rework later, because complexity and coupling are regularly addressed, and it aligns with Agile principles of sustainable pace. It also complements automated tests, which provide the safety net needed to refactor confidently.

Why this answer

Options A, C, and D are correct because managing technical debt in a DevOps environment requires proactive and automated quality practices. Allocating time for refactoring each iteration (A) prevents debt accumulation. Automating unit and integration tests (C) ensures early detection of regressions and quality issues.

Integrating static code analysis into the CI pipeline (D) provides continuous feedback on code quality and debt indicators. Option B is incorrect because deferring unit tests increases technical debt by delaying detection. Option E is incorrect because ignoring low-priority code smells allows debt to grow, which should be tracked and addressed systematically.

Exam trap

The trap here is that candidates may incorrectly assume that low-priority code smells can be safely ignored, but Azure DevOps and SonarQube best practices emphasize that all debt should be tracked and addressed systematically to prevent long-term degradation.

Full explanation →

MCQhard

Your company uses GitHub for source control. The security team requires that all commits to the main branch be signed with an approved GPG key. Additionally, developers must use their corporate email for commits. You need to configure branch protection rules and repository settings to enforce these requirements. Which combination of settings should you use?

A.Configure repository to require commit signature verification via SSH keys.

B.Enable 'Require signed commits' in branch protection rules and use a pre-receive hook to validate email domain.

C.Use a GitHub Actions workflow that checks commit signatures and email and rejects if invalid.

D.Enable 'Require signed commits' in branch protection and use a required status check that runs a custom action to verify commit author email.

AnswerD

Branch protection rules can require signed commits, and a required status check can run a custom GitHub Action that verifies the commit author's email against an allowed domain. This combination successfully enforces both signature and email constraints during pulls.

Why this answer

GitHub branch protection rules can require signed commits, but they only verify that a commit is signed with any GPG key, not that the signer's email matches a corporate domain. To enforce the corporate email requirement, you must add a required status check that runs a custom action (e.g., using `actions-ecosystem/action-check-commit-email`) to verify the commit author email matches the corporate domain. This combination satisfies both the GPG signature and email domain requirements.

Exam trap

The trap here is that candidates assume 'Require signed commits' alone enforces both signature and email domain, but it only ensures the commit is signed with a verified GPG key—it does not restrict the email domain, so an additional status check is needed.

How to eliminate wrong answers

Option A is wrong because GitHub requires GPG keys, not SSH keys, for commit signature verification; SSH keys are used for authentication, not signing. Option B is wrong because pre-receive hooks are only available in GitHub Enterprise Server (self-hosted), not in GitHub.com (SaaS), and the question does not specify an on-premises environment. Option C is wrong because while a GitHub Actions workflow could check signatures and email, it cannot reject commits at the push level; it can only add a failing status check, which must be configured as a required status check in branch protection to block merges.

Full explanation →

Multi-Selectmedium

Which TWO benefits does using Git LFS (Large File Storage) provide? (Select TWO.)

Select 2 answers

A.Automatically compresses all files in the repository

B.Prevents large files from being stored in the Git history

C.Replaces .gitignore for excluding large files

D.Speeds up diff operations for binary files

E.Reduces the size of Git repositories by storing large files as pointers

AnswersB, E

With Git LFS, the large file's content is never committed into the local repository or pushed to the remote Git server; instead only a lightweight pointer file is tracked in history. This prevents the large binary from bloating every clone, fetch, and push, keeping the Git history lean and manageable.

Why this answer

Git LFS (Large File Storage) prevents large files from being stored directly in the Git repository history (option B). Instead, it stores a small pointer file in the repo while the actual large file content is stored externally, which reduces the size of the Git repository (option E). Options A, C, and D are incorrect because LFS does not automatically compress all files, replace .gitignore, or speed up diff operations for binary files.

Exam trap

The trap here is that candidates often confuse Git LFS with general compression or diff optimization, but LFS specifically addresses repository bloat by externalizing large binary storage, not by compressing or speeding up diffs.

Full explanation →

Multi-Selectmedium

Which THREE elements are essential for an effective incident response process in a DevOps environment? (Choose three.)

Select 3 answers

A.Automated rollback or remediation capabilities.

B.A blame-free culture that identifies the person at fault.

C.Post-incident reviews with actionable improvements.

D.Manual approval gates for every change.

E.A clear escalation path and on-call rotation.

AnswersA, C, E

Automated rollback or remediation capabilities are essential because they enable rapid, deterministic recovery from failed deployments or incidents without human latency, reducing mean time to recovery (MTTR) and preventing error-prone manual steps. This aligns with DevOps principles of automation and resilience.

Why this answer

Automated rollback or remediation capabilities are essential because they enable rapid, consistent recovery from incidents without manual intervention. In a DevOps environment, this is typically implemented through deployment pipelines (e.g., Azure Pipelines) that support automatic rollback to a previous known-good version when health checks fail, or through infrastructure-as-code tools like Terraform that can revert state. This minimizes mean time to recovery (MTTR) and reduces human error during high-pressure situations.

Exam trap

The trap here is that candidates confuse a 'blame-free culture' with identifying the person at fault, when in reality the exam expects you to recognize that blameless postmortems focus on process improvements, not individual accountability.

Full explanation →

MCQhard

You are designing a release pipeline for a microservices application deployed to Azure Kubernetes Service (AKS). You need to implement a strategy that allows rolling back to the previous version quickly if a deployment fails. The pipeline should also support canary deployments. Which tool or feature should you use?

A.Terraform with Kubernetes provider.

B.Helm package manager with Helm deploy task.

C.Azure Pipelines Kubernetes manifest task with kubectl apply.

D.Kubectl task with rolling update strategy.

AnswerB

Correct: Helm supports rollback and canary deployments.

Why this answer

Helm is the correct choice because it provides native support for rollbacks via `helm rollback`, which can revert a release to a previous revision quickly. Additionally, Helm supports canary deployments through its upgrade strategy (e.g., `--set canary.enabled=true`) and integration with tools like Flagger or Argo Rollouts, enabling fine-grained traffic shifting. The Helm deploy task in Azure Pipelines wraps these capabilities, making it the most suitable tool for both rollback and canary requirements.

Exam trap

The trap here is that candidates often confuse `kubectl apply` (which only applies manifests) with a full release management tool, overlooking Helm's built-in rollback and canary support that are explicitly required by the question.

How to eliminate wrong answers

Option A is wrong because Terraform with Kubernetes provider is an infrastructure-as-code tool focused on provisioning and managing Kubernetes resources, not on release management or rollback strategies; it lacks native support for canary deployments or quick rollbacks of application releases. Option C is wrong because the Azure Pipelines Kubernetes manifest task with `kubectl apply` applies manifests directly but does not provide built-in rollback mechanisms or canary deployment capabilities; it relies on manual `kubectl rollout undo` commands and lacks revision history management. Option D is wrong because the `kubectl task with rolling update strategy` only supports basic rolling updates and does not natively support canary deployments or automated rollbacks; it requires custom scripting for traffic splitting and revision tracking.

Full explanation →

Multi-Selectmedium

Which TWO tasks can be used to deploy an Azure Web App using YAML pipelines in Azure DevOps?

Select 2 answers

A.AzureWebApp

B.CopyFilesOverSSH

C.AzureRmWebAppDeployment

D.AzureFunctionApp

E.AzureVMAppDeployment

AnswersA, C

AzureWebApp is a first-class Azure Pipelines deployment task designed specifically for Azure App Service. It supports multiple deployment methods, including ZIP deploy, Web Deploy, and container images, and can be used on both Windows and Linux agents, making it a correct choice for deploying an Azure web app.

Why this answer

The AzureWebApp task is correct because it is the dedicated Azure DevOps YAML pipeline task for deploying code to an Azure Web App (App Service). It supports deployment methods like Web Deploy (msdeploy), Kudu REST API, and ZIP deploy, making it the standard choice for web app deployments.

Exam trap

The trap here is that candidates often confuse AzureRmWebAppDeployment as a deprecated or incorrect task, but it remains a valid YAML pipeline task for Azure Web App deployments, especially when using ARM-based deployment slots.

Full explanation →

MCQeasy

Your team uses Azure Pipelines for CI/CD. You want to enforce that every build produces a versioned artifact that includes the Git commit ID. Which predefined variable should you use to get the commit ID in a YAML pipeline?

A.Build.Repository.Name

B.Build.BuildId

C.Build.SourceVersion

D.Build.SourceBranch

AnswerC

Build.SourceVersion contains the full commit ID (SHA) of the source that triggered the pipeline. This is the appropriate predefined variable to enforce policies, tag builds, or take actions based on the exact commit, making it the correct answer.

Why this answer

The `Build.SourceVersion` predefined variable in Azure Pipelines resolves to the commit ID (full SHA) of the commit that triggered the pipeline. This makes it the correct choice for embedding the Git commit ID into a versioned artifact. Other variables like `Build.BuildId` or `Build.SourceBranch` do not provide the commit hash.

Exam trap

The trap here is that candidates often confuse `Build.BuildId` (a pipeline run counter) with a Git commit identifier, or assume `Build.SourceBranch` contains the commit hash because it includes 'Source' in its name.

How to eliminate wrong answers

Option A is wrong because `Build.Repository.Name` returns the name of the repository (e.g., 'my-repo'), not the commit ID. Option B is wrong because `Build.BuildId` is a numeric identifier for the pipeline run, not a Git commit hash. Option D is wrong because `Build.SourceBranch` returns the branch or tag reference (e.g., 'refs/heads/main'), not the commit ID.

Full explanation →

MCQmedium

You are designing a compliance plan for Azure DevOps. The compliance officer requires that all changes to build pipelines are audited and cannot be reverted without approval. What should you implement?

A.Enable Azure DevOps audit logs

B.Store pipeline YAML in a repository with branch policies

C.Use release approval gates

D.Set pipeline retention policies

AnswerB

Storing the pipeline YAML in a Git repository with branch policies enforces mandatory peer review and approval for any pull request that modifies the pipeline definition. This creates a gated change process with full traceability, ensures separation of duties, and directly prevents unauthorized or accidental reverts, making it the appropriate compliance control for protecting pipeline definitions.

Why this answer

Storing pipeline YAML in a repository with branch policies ensures that every change to the pipeline definition goes through a pull request (PR) process, which is auditable and requires approval before merging. Once merged, the change is recorded in the Git history, and reverting it requires another PR with approval, meeting the compliance requirement that changes cannot be reverted without approval.

Exam trap

The trap here is confusing audit logging (which only records events) with enforcement mechanisms (like branch policies) that actually prevent unapproved changes and reverts.

How to eliminate wrong answers

Option A is wrong because enabling Azure DevOps audit logs captures who performed what action and when, but it does not prevent reverts or enforce approval for changes to build pipelines. Option C is wrong because release approval gates control the deployment of releases to stages, not changes to the pipeline definition itself. Option D is wrong because pipeline retention policies control how long pipeline runs and artifacts are kept, not how changes to the pipeline are audited or reverted.

Full explanation →

Multi-Selecthard

Which TWO GitHub Actions features can be used to enforce deployment approvals for a production environment? (Choose two.)

Select 2 answers

A.Deployment protection rules that require approval.

B.The 'deployment' event trigger in a workflow.

C.Environments with required reviewers.

D.Branch protection rules that require pull request reviews.

E.OpenID Connect (OIDC) for cloud provider authentication.

AnswersA, C

Deployment protection rules, when configured on an environment, can require manual approval from specified reviewers before a job referencing that environment can run. This pauses the workflow and enforces a human gate prior to deployment.

Why this answer

Deployment protection rules in GitHub Actions allow you to define required approvals before a workflow job can deploy to an environment. These rules are configured at the environment level and can mandate that a specific number of reviewers approve the deployment, effectively enforcing a manual approval gate for production environments.

Exam trap

The trap here is confusing branch protection rules (which control code merges) with environment-level deployment protection rules (which control deployment approvals), leading candidates to incorrectly select branch protection rules as a mechanism for deployment approvals.

Full explanation →

MCQmedium

You are designing a communication strategy for your DevOps team. They use Microsoft Teams for collaboration. You need to automatically notify the team when a release to production fails. Which Azure DevOps integration should you use?

A.Set up an email subscription to the DevOps team

B.Create a service hook to call a custom API

C.Publish a Wiki page with deployment status

D.Configure a notification subscription in Azure DevOps to send a Teams webhook

AnswerD

Azure DevOps notification subscriptions can be configured with an incoming webhook to send release failure alerts directly to a Teams channel. This leverages built-in integration, delivers real-time messages, and avoids custom development or additional hosting.

Why this answer

Azure DevOps notification subscriptions can be configured to send alerts to a Teams channel via an incoming webhook. This allows automatic, real-time notifications to the DevOps team when a release to production fails, directly within their collaboration platform.

Exam trap

The trap here is that candidates may confuse a generic email subscription or a custom service hook with the purpose-built Teams webhook integration, overlooking that Azure DevOps provides a direct notification subscription type for Teams that requires no custom development.

How to eliminate wrong answers

Option A is wrong because email subscriptions are a generic notification method that do not integrate directly with Microsoft Teams; they would require the team to check email separately, which is less efficient for real-time collaboration. Option B is wrong because creating a service hook to call a custom API is an overly complex and indirect approach; while it could theoretically work, it is not the standard or recommended integration for sending notifications to Teams. Option C is wrong because publishing a Wiki page with deployment status is a manual or static documentation method, not an automated notification mechanism; it does not provide real-time alerts when a release fails.

Full explanation →

MCQhard

Your release pipeline uses a multi-stage YAML with environments. You need to ensure that only one deployment runs at a time to a production environment to avoid conflicts. Which feature should you use?

A.Use a condition to check if a previous deployment is in progress.

B.Add a pre-deployment approval gate.

C.Set the 'parallel' deployment option to 1.

D.Configure an exclusive lock policy on the production environment.

AnswerD

Configuring an exclusive lock policy on the Production environment ensures that only a single pipeline run can deploy to that environment at any given time. Once a deployment job acquires the lock, any other deployment jobs targeting the same environment will be queued and wait until the lock is released.

Why this answer

An exclusive lock policy on an environment ensures that only one deployment can run at a time to that environment. When a deployment starts, it acquires a lock on the environment; subsequent deployments are queued until the lock is released. This prevents conflicts from concurrent deployments to the same production environment.

Exam trap

The trap here is that candidates often confuse 'parallel deployment' settings (which control concurrency within a single stage) with environment-level locking (which controls concurrency across multiple pipeline runs targeting the same environment).

How to eliminate wrong answers

Option A is wrong because conditions in YAML evaluate at runtime based on variables or previous job status, but they do not provide a queuing mechanism to prevent concurrent deployments; they only skip or run a stage based on a boolean expression. Option B is wrong because pre-deployment approval gates add manual or automated checks before a deployment starts, but they do not serialize deployments; multiple approvals can be granted concurrently, leading to simultaneous deployments. Option C is wrong because the 'parallel' deployment option controls the number of parallel deployment jobs within a single stage, not across stages or environments; setting it to 1 only limits parallelism within that stage, not across different pipeline runs targeting the same environment.

Full explanation →

MCQeasy

You are using Application Insights to monitor a web application. You need to create an alert that triggers when the average server response time exceeds 2 seconds over a 5-minute window. You want to minimize false positives by requiring the condition to be met for at least two consecutive 5-minute periods. What should you configure?

A.A metric alert with a threshold of 2 seconds, aggregation type Maximum, period 5 minutes, and evaluation frequency 1 minute, with an alert rule that triggers immediately.

B.An activity log alert that monitors the server response time metric and triggers when the average exceeds 2 seconds.

C.A log search alert using a Kusto query that calculates the average response time over 5 minutes and triggers if the result exceeds 2 seconds.

D.A metric alert with a threshold of 2 seconds, aggregation type Average, period 5 minutes, and evaluation frequency 5 minutes, with an alert rule that triggers after two consecutive evaluations.

AnswerD

Metric alerts in Azure Monitor support specifying the aggregation, period, and evaluation frequency. To require two consecutive periods, you set the alert rule to trigger only after the condition is met for the specified number of evaluations. This reduces false positives by ensuring the threshold is breached consistently, not just in a single spike.

Why this answer

Metric alerts in Azure Monitor allow you to specify the aggregation (Average), period (5 minutes), evaluation frequency (5 minutes), and the number of consecutive evaluations before triggering. This precisely matches the requirement of alerting only when the average response time exceeds 2 seconds for two consecutive 5-minute windows, reducing false positives from transient spikes.

Exam trap

The trap here is selecting a log search alert or using Maximum aggregation, which may seem simpler but fails to enforce the consecutive evaluation requirement or misinterprets the metric aggregation.

Full explanation →

MCQhard

You are designing a build pipeline that produces a NuGet package. The pipeline must conditionally sign the assembly only when the build is triggered by a tag starting with 'v' (e.g., v1.0.0). The pipeline uses a script task that signs the assembly. Which expression should you use in the condition of the script task?

A.and(succeeded(), startsWith(variables['Build.SourceBranch'], 'refs/tags/v'))

B.and(succeeded(), startsWith(variables['Build.SourceBranchName'], 'v'))

C.and(succeeded(), startsWith(variables['Build.SourceVersion'], 'v'))

D.and(succeeded(), eq(variables['Build.Reason'], 'IndividualCI'))

AnswerA

The Build.SourceBranch variable holds the full Git ref, which for a tag push is exactly 'refs/tags/vX.Y.Z'. By using startsWith(..., 'refs/tags/v'), the condition first verifies that the ref is under the 'refs/tags/' namespace, ensuring it is a tag rather than a branch, and then checks that the tag name starts with 'v' to restrict to version-style tags. This accurately limits the signing step to semantic-version tags, making it the correct condition.

Why this answer

The condition uses `startsWith(variables['Build.SourceBranch'], 'refs/tags/v')` to check if the build was triggered by a tag whose full Git ref starts with `refs/tags/v`. This ensures the signing script runs only when the source branch is a tag reference matching the 'v' prefix, which is the standard way to identify version tags in Azure Pipelines. The `and(succeeded(), ...)` wrapper guarantees the previous tasks completed successfully before signing.

Exam trap

The trap here is that candidates often confuse `Build.SourceBranchName` (short name) with `Build.SourceBranch` (full ref), leading them to choose Option B, which would incorrectly match branches or other refs starting with 'v' instead of only tags.

Why the other options are wrong

Build.SourceBranchName for a tag is the tag name, so this would also work but is less precise; however, the official documentation recommends using Build.SourceBranch.

Build.SourceVersion is the commit SHA, not the tag.

Build.Reason checks for CI trigger, not tag.

Full explanation →

100

MCQmedium

Your team is using GitHub Actions for CI/CD. The workflow builds a container image and pushes it to Azure Container Registry (ACR). However, the workflow fails with an authentication error when pushing to ACR. What is the most likely cause?

A.The repository name in the workflow is incorrect.

B.The Dockerfile is missing a required LABEL instruction.

C.The ACR allows anonymous pull access.

D.The workflow does not include an 'azure/login' step to authenticate with Azure.

AnswerD

The azure/login action establishes Azure credentials for the job, and a subsequent docker login step (or azure/docker-login) uses those credentials to authenticate with the ACR. Without the azure/login step, the workflow has no authenticated context for Azure, so the Docker push receives an unauthorized or authentication-required response, exactly matching the reported failure.

Why this answer

GitHub Actions workflows that push container images to Azure Container Registry (ACR) must first authenticate with Azure. Without an 'azure/login' step (using Azure CLI or Azure PowerShell actions), the workflow lacks the necessary OAuth2 tokens or service principal credentials to authorize the 'docker push' command against the ACR endpoint. The authentication error occurs because the Docker client cannot obtain a valid ACR access token without prior Azure authentication.

Exam trap

The trap here is that candidates assume Docker authentication is handled automatically by the Docker client or that ACR allows anonymous pushes, when in fact Azure requires explicit Azure AD authentication via the 'azure/login' action before any registry write operations.

How to eliminate wrong answers

Option A is wrong because an incorrect repository name would cause a 'repository does not exist' or 'name unknown' error, not an authentication error (HTTP 401/403). Option B is wrong because a missing LABEL instruction in the Dockerfile does not affect authentication; it is a metadata instruction that has no impact on registry push permissions. Option C is wrong because anonymous pull access (if enabled) only allows pulling images without authentication, not pushing; pushing always requires authenticated access regardless of pull settings.

Full explanation →

101

Multi-Selectmedium

Which TWO branch policies can be configured in Azure Repos to enforce code quality?

Select 2 answers

A.Status check

B.Comment requirements

C.Build validation

D.Work item linking

E.Merge strategy

AnswersA, C

Status check is a valid branch policy in Azure Repos that requires an external service (e.g., SonarQube, Jenkins) to post a successful status to the PR before it can be completed. The policy defines a context name, and the service must report 'succeeded' via the Status API; otherwise, the PR is blocked. This enforces quality gates from CI/CD or analysis tools.

Why this answer

Status check (A) is correct because Azure Repos allows you to require that a status check passes before a pull request can be completed. This enforces code quality by integrating with external or built-in services (e.g., Azure Pipelines, SonarQube) that run automated tests, linting, or security scans. Build validation (C) is correct because it triggers a build pipeline automatically when a pull request is created, ensuring the code compiles and passes defined quality gates before merging.

Exam trap

The trap here is that candidates often confuse 'comment requirements' with 'reviewer requirements' or assume 'work item linking' enforces quality, when in fact it only ensures traceability, not code quality.

Full explanation →

102

MCQmedium

Refer to the exhibit. The pipeline YAML includes an Azure CLI script that sets an app setting on a Web App. The pipeline fails with an authentication error. What is the most likely cause?

A.The resource group name is incorrect.

B.The pipeline does not have an Azure service connection configured for authentication.

C.The DEPLOYMENT_SLOT setting name is invalid.

D.The script syntax is invalid.

AnswerB

The Azure CLI task (AzureCLI@2) requires an Azure service connection to authenticate to Azure. Without a service connection defined in the pipeline's inputs (e.g., azureSubscription), the task cannot obtain credentials, causing an authentication error before any script executes.

Why this answer

The Azure CLI script in the pipeline attempts to run `az webapp config appsettings set`, which requires authentication to Azure. Without an Azure service connection configured in the pipeline, there is no authenticated session or service principal to authorize the command, resulting in an authentication error. The service connection provides the necessary credentials (e.g., via Azure AD) for the pipeline to interact with Azure resources.

Exam trap

The trap here is that candidates may focus on the script content or resource details (like the slot name or resource group) instead of recognizing that the fundamental authentication mechanism for Azure CLI in a pipeline is the service connection, not the script itself.

How to eliminate wrong answers

Option A is wrong because an incorrect resource group name would cause a 'ResourceNotFound' or similar error, not an authentication error. Option C is wrong because an invalid DEPLOYMENT_SLOT setting name would cause a validation or runtime error when the app setting is applied, not an authentication failure. Option D is wrong because invalid script syntax would produce a syntax or parsing error before any Azure CLI command is executed, not an authentication error.

Full explanation →

103

MCQhard

You are a DevOps engineer at a company that develops a cloud-based SaaS application. The application consists of multiple microservices, each stored in its own Git repository within a single Azure DevOps project. The team has grown rapidly, and developers frequently need to make changes that span multiple services. They often complain about the overhead of managing multiple pull requests and coordinating merges across repositories. To improve efficiency, the team lead suggests consolidating all microservices into a single monorepo. However, the lead architect is concerned about the impact on build times, as the CI pipeline currently builds each service independently. You are tasked with designing a source control strategy that reduces cross-repository coordination overhead while maintaining fast, independent builds. You propose using a monorepo with a structure that allows selective building. Which approach should you recommend?

A.Keep separate repositories but create a meta-repo that references them as submodules

B.Create a single monorepo with a build pipeline that uses path filters to trigger builds only for changed services

C.Keep separate repositories but use Git submodules to share code

D.Create a single monorepo with all services and a single build pipeline that builds everything

AnswerB

This allows atomic commits across services, while path filters in the pipeline trigger builds only for changed services, preserving build independence and reducing unnecessary builds. It provides the benefits of a monorepo without the cost of building everything.

Why this answer

Using a single monorepo with path filters in the build pipeline allows you to trigger builds only for the microservices that have changed, reducing cross-repository coordination overhead while maintaining fast, independent builds. Path filters in Azure Pipelines (e.g., `paths` in YAML) enable selective triggering based on file paths, so unchanged services are not rebuilt, preserving CI efficiency.

Exam trap

The trap here is that candidates may confuse a monorepo with a monolithic build, assuming all code must be built together, when in fact path filters allow selective building to maintain CI speed.

How to eliminate wrong answers

Option A is wrong because a meta-repo with submodules does not reduce coordination overhead; developers still need to manage multiple repositories and pull requests for changes across submodules, and submodules introduce complexity with detached HEAD states and synchronization issues. Option C is wrong because keeping separate repositories with Git submodules for shared code does not address the core problem of coordinating changes across multiple services; submodules add overhead for version pinning and updates, and do not enable selective building across services. Option D is wrong because a single monorepo with a single build pipeline that builds everything would dramatically increase build times, as every change would trigger a full build of all services, defeating the goal of maintaining fast, independent builds.

Full explanation →

104

MCQhard

You are managing a pipeline that deploys a microservices application to multiple Azure Kubernetes Service (AKS) clusters in different regions. You want to implement a progressive exposure strategy where the deployment first goes to a small cluster (canary), then to a medium cluster, and finally to all clusters. The deployment should be automated but with the ability to halt if errors occur. What should you use?

A.Use manual approval gates between stages.

B.Use deployment gates with evaluation of health metrics (e.g., error rate) before proceeding to the next stage.

C.Configure a rolling deployment strategy on each cluster.

D.Use a manual validation step in the pipeline.

AnswerB

Deployment gates automatically evaluate predefined health metrics, such as error rate, latency, or availability, before allowing the pipeline to proceed to the next stage. They continuously assess these signals and can halt or fail the deployment if thresholds are exceeded, enabling safe, automated progressive exposure across clusters without manual intervention.

Why this answer

Deployment gates in Azure Pipelines allow you to automatically evaluate health metrics (such as error rate, CPU usage, or custom metrics from Application Insights) before promoting a release to the next stage. This enables a progressive exposure strategy (canary → medium → all clusters) with automated rollback or halt if the metrics breach thresholds, without requiring manual intervention.

Exam trap

The trap here is that candidates confuse manual approval gates (Option A) with automated deployment gates (Option B), assuming any 'gate' requires human approval, when in fact deployment gates can be fully automated based on health metrics.

How to eliminate wrong answers

Option A is wrong because manual approval gates require a human to manually approve each stage, which defeats the automation requirement and introduces delay and human error risk; they do not automatically evaluate health metrics. Option C is wrong because a rolling deployment strategy is a per-cluster update mechanism (e.g., gradually replacing pods) and does not provide cross-stage gating or health-based promotion between different clusters. Option D is wrong because a manual validation step is a human-in-the-loop check, not an automated health metric evaluation, and does not support the progressive exposure logic across multiple clusters.

Full explanation →

105

MCQhard

Your team uses Azure Pipelines for CI/CD. A release pipeline fails intermittently during deployment to an Azure App Service slot. The error message indicates 'Failed to fetch access token for Azure Resource Manager service endpoint.' The service principal used has been granted Contributor role on the resource group. The issue resolves after re-creating the service connection in Azure DevOps. What is the most likely cause?

A.The service principal client secret has expired.

B.The user who created the service connection has been removed from Azure DevOps.

C.The Azure DevOps organization is behind a firewall that blocks outbound requests to Azure Resource Manager.

D.The service principal lacks the required role on the target resource group.

AnswerA

The service principal client secret has expired. Because Azure DevOps caches Azure AD tokens for a period, the pipeline may succeed on cached tokens and then fail when it must refresh them, producing the intermittent behavior seen here. Once the secret expires, any new token request to Azure AD is rejected with a 401, so the ARM deployment service connection fails. Re-creating the service connection generates a fresh client secret, which is why that is the correct remedy.

Why this answer

Service principal credentials (client secret) can expire, causing intermittent token fetch failures. Re-creating the service connection generates a new secret, temporarily resolving the issue until it expires again. Option B is wrong because the service connection is bound to the service principal, not the user who created it; removing the user does not affect the existing connection.

Option C is wrong because network restrictions would cause consistent failure, not intermittent. Option D is wrong because the service principal already has the Contributor role on the resource group.

Full explanation →

106

MCQeasy

You are setting up a build pipeline for a .NET Core application. The build should run on every pull request to the 'main' branch. Which trigger configuration should you use in the YAML pipeline?

A.trigger: pr: branches: include: - main

B.trigger: branches: include: - main

C.pr: branches: include: - main

D.pr: autoCancel: false branches: include: - '*'

AnswerC

This YAML snippet correctly configures a pull request trigger for the pipeline using the top-level `pr` key. By specifying `branches: include: main`, the pipeline will automatically run as PR validation whenever a pull request targets the `main` branch, which is exactly the desired behavior. Unlike `trigger`, which controls CI builds on branch pushes, `pr` is the dedicated mechanism for pull request validation in Azure Pipelines. This configuration is valid and requires no additional nesting or modifiers to achieve the stated goal.

Why this answer

In Azure Pipelines YAML, the `pr` trigger is used to define pull request validation triggers, separate from the `trigger` keyword which controls CI triggers on branch pushes. By specifying `pr: branches: include: - main`, the pipeline will automatically run on every pull request targeting the `main` branch, which matches the requirement exactly.

Exam trap

The trap here is that candidates often confuse the `trigger` keyword (for CI pushes) with the `pr` keyword (for pull request validation), leading them to incorrectly nest PR settings under `trigger` or use `trigger` alone for PR scenarios.

How to eliminate wrong answers

Option A is wrong because it incorrectly nests the `pr` configuration under the `trigger` keyword; `trigger` is for CI (push) triggers, not PR triggers, and this syntax would cause a YAML parsing error or be ignored. Option B is wrong because it uses only the `trigger` keyword with a branch include, which would run the pipeline on every push to `main`, not on pull requests to `main`. Option D is wrong because it sets `autoCancel: false` (which prevents cancellation of existing PR builds when new commits are pushed) and includes all branches with `'*'`, but the requirement is specifically to trigger only on PRs to `main`, not all branches.

Full explanation →

107

Multi-Selecthard

Which THREE options are valid strategies for implementing progressive exposure in Azure Pipelines?

Select 3 answers

A.Rolling update.

B.Ring-based deployment.

C.Canary deployment.

D.Immutable infrastructure.

E.Blue-green deployment.

AnswersB, C, E

Ring-based deployment is a progressive delivery strategy that releases a new version to small, successively larger groups of users (rings), such as internal testers, then a small percentage of production users, and finally all users, allowing monitoring and rollback at each ring boundary.

Why this answer

Ring-based deployment, canary deployment, and blue-green deployment are all valid strategies for progressive exposure. Ring-based deployment gradually rolls out to increasing groups of users (rings), often using deployment gates and percentage-based rollout. Canary deployment routes a small percentage of traffic to the new version before increasing it, allowing monitoring and rollback.

Blue-green deployment runs two identical environments (blue and green) and switches traffic from the old to the new version, enabling immediate rollback. These strategies all provide controlled, incremental exposure to validate changes before full rollout.

Exam trap

The trap here is that candidates confuse rolling updates (which are about instance replacement) with progressive exposure strategies (which are about user-based or traffic-based phased rollouts), leading them to incorrectly select 'Rolling update' as a valid option.

Full explanation →

108

Multi-Selectmedium

Which TWO are valid strategies for managing secrets in Azure Pipelines?

Select 2 answers

A.Store secrets in plain text in a variable group.

B.Use a variable group linked to Azure Key Vault and mark variables as secret.

C.Store secrets in a Git repository and read them during build.

D.Embed secrets directly in the pipeline YAML file.

E.Use the Azure Key Vault task to fetch secrets and map them to pipeline variables.

AnswersB, E

A variable group linked to Azure Key Vault securely references secrets stored in Key Vault, allowing pipeline tasks to consume them as secret variables. Marking them as secret ensures they are masked in logs and not exposed, while Key Vault enforces access policies and rotation, making this a recommended, secure strategy.

Why this answer

Linking a variable group to Azure Key Vault allows secrets to be securely referenced without exposing them in plaintext; when variables are marked as secret, Azure Pipelines masks their values in logs. Alternatively, the Azure Key Vault task can fetch secrets at runtime and map them to pipeline variables for use in tasks, which also keeps secrets out of YAML and logs. Both approaches are valid strategies for secret management.

Exam trap

The trap here is that candidates may think variable groups alone are secure, but only when linked to Key Vault and marked as secret do they provide proper secret management; plain-text variable groups or YAML embedding are common missteps.

Full explanation →

109

MCQmedium

Refer to the exhibit. After executing the delete command, what is the state of the repository?

A.The tag v1.0-rc is removed, but the commit it pointed to is also deleted from the repository.

B.The tag v1.0-rc is removed, and the branch feature/new-feature is also deleted because it was the same object.

C.The tag v1.0-rc is removed, and the repository now contains only one tag (v1.0) and three branches.

D.The command fails because the tag does not exist.

AnswerC

The delete command removes the tag ref refs/tags/v1.0-rc, which is the only operation performed; all other refs remain untouched. The repository still holds the tag ref refs/tags/v1.0, and the three branch refs (refs/heads/main, refs/heads/feature/new-feature, and refs/heads/feature/old-feature, as shown in the exhibit) are independent pointers under refs/heads. Because the tag deletion only removes that one ref under refs/tags, the net result is exactly one tag (v1.0) and three branches remaining.

Why this answer

The command deleted the tag refs/tags/v1.0-rc. After deletion, the tag is no longer available. The other refs (branches and tags) remain unchanged.

The repository now has only one tag: v1.0. The branches main, develop, and feature/new-feature still exist.

Full explanation →

110

MCQmedium

You are designing a communication strategy for a large Azure DevOps migration. The team is distributed across multiple time zones. Which approach best supports asynchronous collaboration?

A.Use Slack huddles for quick sync-ups.

B.Maintain a wiki in Azure DevOps with status and decisions.

C.Use email threads for status updates.

D.Schedule daily standup meetings at a fixed time.

E.Record all team meetings and share links.

AnswerB

A wiki in Azure DevOps stores status and decisions as versioned Markdown, letting distributed team members read and contribute at any hour without scheduling overlap. This directly satisfies the asynchronous collaboration constraint, unlike synchronous channels such as stand-ups or chat, which require simultaneous availability across time zones.

Why this answer

Maintaining a wiki in Azure DevOps provides a persistent, searchable, and asynchronous record of status and decisions, which is ideal for distributed teams across time zones. Option A is wrong because Slack huddles are real-time and require synchronous participation. Option C is wrong because email threads can be hard to search and lack integration with Azure DevOps.

Option D is wrong because daily standup meetings at a fixed time require synchronous attendance. Option E is wrong because recording meetings is passive and not easily searchable; the information is not structured for quick reference.

Full explanation →

111

MCQhard

You have the above YAML task in a pipeline. The task runs but no secrets are available in subsequent tasks. What is the most likely cause?

A.The secrets are not automatically mapped to environment variables; you must reference them using $(secretName).

B.The SecretsFilter is set to '*' which is invalid.

C.The service principal does not have 'Get' permission on the key vault.

D.The key vault name 'mykv' does not exist.

AnswerA

The Azure Key Vault task downloads secrets as pipeline variables, but it does not automatically export them to the environment of subsequent tasks. To use a secret inside a script or tool, you must reference it explicitly with the macro syntax $(secretName) or map it into the `env` section of a task. Without such explicit mapping, the secret is not visible as an environment variable, even though the task itself completed successfully.

Why this answer

By default, secrets downloaded from Azure Key Vault in a pipeline task are not automatically mapped to environment variables for subsequent tasks. You must explicitly reference them using the macro syntax `$(secretName)` or map them as environment variables with the `env` keyword. Without this explicit mapping, the secret values remain inaccessible to later tasks, even though the download task succeeds.

Exam trap

The trap here is that candidates assume downloading secrets automatically makes them available as environment variables in all subsequent tasks, but Azure DevOps requires explicit mapping via `$(secretName)` or the `env` keyword to prevent accidental leakage.

How to eliminate wrong answers

Option B is wrong because `SecretsFilter: '*'` is a valid wildcard that downloads all secrets from the key vault; it does not cause the task to fail or prevent secrets from being available. Option C is wrong because if the service principal lacked 'Get' permission on the key vault, the task itself would fail with an authorization error, not silently succeed with no secrets available. Option D is wrong because if the key vault name 'mykv' did not exist, the task would fail immediately with a 'VaultNotFound' error, not complete successfully with no secrets.

Full explanation →

112

MCQhard

Refer to the exhibit. This multi-stage YAML pipeline has a variable 'publishEnabled' set to false. The team wants the Publish stage to run only when 'publishEnabled' is true. However, the Publish stage never runs, even when the variable is changed to true at queue time. What is the most likely cause?

A.The condition syntax is wrong; it should use 'eq(variables.publishEnabled, true)'.

B.The Publish stage is missing 'dependsOn: Build'.

C.The variable 'publishEnabled' is not settable at queue time; it is a compile-time variable.

D.The 'dependsOn' syntax is incorrect; it should be 'dependsOn: Build'.

AnswerC

In Azure DevOps YAML pipelines, variables declared in the `variables` section are compile-time constants; they are evaluated when the pipeline is created and cannot be overridden at queue time unless defined as `runtime` parameters. Therefore, the condition referencing `publishEnabled` will always use the value from the YAML, not any queue-time value, making this the correct diagnosis.

Why this answer

In Azure DevOps YAML pipelines, variables set at the pipeline level (not in a variable group or at queue time) are evaluated at compile time, not at runtime. When 'publishEnabled' is defined as a simple variable in the YAML file, changing it at queue time does not affect the compiled pipeline stages; the condition is evaluated against the compile-time value (false), so the Publish stage never runs. To make it settable at queue time, the variable must be defined as a runtime parameter, or explicitly defined in the pipeline UI with the 'Let users override this value when running this pipeline' checkbox enabled.

Exam trap

The trap here is that candidates confuse variable evaluation timing—assuming all variables can be overridden at queue time—when in fact only parameters or explicitly settable variables can be changed, while compile-time variables are baked into the pipeline definition before runtime.

How to eliminate wrong answers

Option A is wrong because the condition syntax 'eq(variables.publishEnabled, true)' is actually correct for YAML expressions; the issue is not syntax but the variable's evaluation timing. Option B is wrong because the Publish stage does not need an explicit 'dependsOn: Build' if it already runs after the Build stage by default in a sequential multi-stage pipeline; missing dependsOn would cause a different error (e.g., stage not running at all), not the described behavior. Option D is wrong because the 'dependsOn' syntax shown in the exhibit (likely 'dependsOn: Build') is correct; the problem is not a syntax error but the variable's compile-time evaluation.

Full explanation →

113

MCQeasy

Your team is using Git with Azure Repos. A developer accidentally committed a large binary file to the main branch. What is the recommended way to permanently remove it from the repository history?

A.Delete the file and commit the deletion

B.Ignore the file using .gitignore

C.Revert the commit using 'git revert'

D.Use 'git filter-branch' to remove the file from history

AnswerD

git filter-branch rewrites the commit history by applying a filter (e.g., --index-filter or --tree-filter) to remove the file from every commit, making it as if the file never existed. This permanently removes the file from history, but it rewrites commit SHAs and requires force-pushing and coordination with all collaborators to avoid reintroducing the file.

Why this answer

`git filter-branch` (or its modern replacement `git filter-repo`) rewrites the entire repository history to permanently remove a file from all commits. This is the recommended approach when a large binary file has been committed to the main branch and must be expunged from history to reduce repository size and prevent it from being cloned by others.

Exam trap

The trap here is that candidates often confuse `git revert` (which creates a new commit that undoes changes but preserves history) with `git filter-branch` (which rewrites history to permanently remove content), leading them to choose option C despite it leaving the large file accessible in the commit log.

How to eliminate wrong answers

Option A is wrong because simply deleting the file and committing the deletion only removes it from the current commit; the file remains in the Git history, meaning it can still be accessed and the repository size is not reduced. Option B is wrong because adding the file to `.gitignore` only prevents future tracking of the file; it does nothing to remove the file from existing commits or history. Option C is wrong because `git revert` creates a new commit that undoes the changes of a previous commit, but the original commit with the large binary file remains in the history, so the file is still present in the repository's commit log.

Full explanation →

114

MCQeasy

Your team uses GitHub Actions for CI/CD. You want to securely store a database connection string used in a workflow. Where should you store it?

A.GitHub Secrets.

B.Workflow environment variables.

C.Directly in the workflow YAML.

D.In a configuration file committed to repo.

AnswerA

GitHub Secrets are encrypted at rest and by default are masked in workflow logs, making them the recommended way to store sensitive values like API tokens or connection strings. They can be scoped to a repository, environment, or organization and are only exposed to workflows that explicitly reference them via ${{ secrets.NAME }}.

Why this answer

GitHub Secrets is the correct choice because it provides encrypted storage for sensitive data like database connection strings. When you store a value in GitHub Secrets, it is encrypted via libsodium before being stored, and it is only exposed to GitHub Actions workflows as an environment variable or input when explicitly referenced. This prevents the secret from being logged or leaked in the workflow output, unlike other storage methods that risk exposure.

Exam trap

The trap here is that candidates may confuse environment variables (which are plain text and visible in logs) with secrets (which are encrypted and masked), leading them to choose workflow environment variables as a simpler but insecure alternative.

How to eliminate wrong answers

Option B is wrong because workflow environment variables are stored in plain text within the workflow YAML or GitHub UI and can be printed in logs, making them insecure for secrets. Option C is wrong because directly embedding the connection string in the workflow YAML exposes it in the repository history and to anyone with read access to the repo, violating security best practices. Option D is wrong because committing a configuration file with the connection string to the repository stores it in plain text in version control, making it accessible to all users with repo access and impossible to rotate without a new commit.

Full explanation →

115

Multi-Selectmedium

Which TWO options are benefits of using Git LFS (Large File Storage) in a team environment? (Select TWO.)

Select 2 answers

A.Prevents large files from being stored in the Git history

B.Automatically detects and tracks all binary files in the repository

C.Reduces the size of Git repository clones and fetches for team members

D.Works only with GitHub and Azure Repos

E.Eliminates the need for Git when working with large binary files

AnswersA, C

LFS replaces large files with small text pointers in the repository, while the actual binary content is stored in a separate external store. This keeps the Git history lightweight and avoids bloating the .git directory with large objects.

Why this answer

Git LFS replaces large files in the repository with text pointer files, while the actual file content is stored in a separate remote store. This prevents the large files from bloating the Git history, which would otherwise permanently increase repository size for all clones and fetches.

Exam trap

The trap here is that candidates may assume Git LFS automatically handles all binary files (Option B) or that it works only with specific platforms (Option D), when in fact it requires explicit configuration and is widely supported across providers.

Full explanation →

116

Multi-Selectmedium

Which THREE measures should you implement to protect secrets (e.g., API keys, passwords) used in Azure Pipelines?

Select 3 answers

A.Store secrets as plain text in a secure Git repo with restricted access

B.Mark variables as 'Secret' in pipeline YAML or UI definitions

C.Use environment variables in the pipeline to pass secrets at runtime

D.Use service connections with managed identity instead of personal access tokens

E.Store secrets in Azure Key Vault and reference them via a Key Vault task

AnswersB, D, E

Marking variables as secret encrypts their values at rest and masks them in logs, preventing accidental exposure during pipeline runs. This directly satisfies the stem's requirement to protect API keys and passwords stored in Azure Pipelines.

Why this answer

Option B is correct because marking variables as 'Secret' in the pipeline YAML (using the secret variable syntax) or in the UI variable group causes Azure Pipelines to encrypt the value at rest, mask it in logs, and avoid exposing it in plain text during runs. Option D is correct because service connections backed by managed identity (or workload identity federation) eliminate long-lived personal access tokens and stored credentials, letting the pipeline authenticate to Azure resources without embedding secrets. Option E is correct because Azure Key Vault centralizes secret storage with access policies/RBAC and auditing, and the AzureKeyVault@2 task (or Key Vault variable group linking) retrieves secrets at runtime so they are never committed to the repo.

Option A is not appropriate because storing secrets as plain text in Git—even a restricted repo—leaves them in version history and readable by anyone with repo access. Option C is not a distinct protection measure because environment variables alone do not encrypt, mask, or vault the secret; without the 'Secret' marking or Key Vault integration the value can still leak into logs or process listings.

Exam trap

AZ-400 often tests the misconception that environment variables or restricted Git repos are secure for secrets, tempting candidates to choose options that still expose credentials.

Full explanation →

117

MCQmedium

Your organization uses GitHub Actions for CI/CD. The security team requires that all workflows are stored in a central repository and that only approved actions can be used. What should you implement?

A.Configure the repository to use only self-hosted runners.

B.Store all workflows in a central repository and use branch protection rules.

C.In the organization settings, configure the 'Actions permissions' to 'Allow specified actions' and add the approved actions to the allow list.

D.Enable 'Allow GitHub Actions to create and approve pull requests' in the repository settings.

AnswerC

Configuring 'Actions permissions' to 'Allow specified actions' in the organization's Actions settings builds an explicit allowlist that only permits pre-approved actions in all workflows. Any action not on the list is blocked, which enforces the security requirement by preventing use of unapproved third-party actions.

Why this answer

The security team's requirement to restrict workflows to only approved actions is directly met by configuring 'Actions permissions' in the organization settings to 'Allow specified actions' and then populating the allow list with the approved actions. This enforces a policy where any workflow, regardless of where it is stored, can only reference actions that have been explicitly allowed, preventing the use of unverified or malicious third-party actions.

Exam trap

The trap here is that candidates often confuse controlling where workflows are stored (centralization) with controlling which actions are allowed to execute, mistakenly thinking branch protection or runner restrictions can substitute for an explicit action allow list.

How to eliminate wrong answers

Option A is wrong because using only self-hosted runners controls the execution environment but does not restrict which actions can be used in workflows; workflows can still reference any action from the marketplace or external sources. Option B is wrong because storing workflows in a central repository and using branch protection rules controls who can modify the workflows but does not restrict which actions those workflows can call; a workflow in the central repo could still reference an unapproved action. Option D is wrong because enabling 'Allow GitHub Actions to create and approve pull requests' is a permission setting for automation, not a security control for restricting which actions are allowed to run.

Full explanation →

118

MCQhard

Your organization uses GitHub for source control and Azure Pipelines for CI/CD. You have a monorepo with multiple projects. You need to design a pipeline that only builds and tests the projects that have changed in each commit. You want to minimize build time and avoid unnecessary runs. The pipeline should also handle dependencies between projects. Which approach should you use?

A.Create a single pipeline that builds all projects on every commit

B.Configure path filters in the pipeline trigger, and use a custom script to detect dependencies and build only affected projects plus their dependents

C.Use a single pipeline with a condition that checks which files changed and runs only the corresponding job

D.Create separate pipelines for each project and trigger them manually

AnswerB

Configuring path filters in the pipeline trigger limits pipeline runs to commits that touch relevant project paths, while a custom dependency detection script builds the transitive closure of affected projects and their dependents. This ensures that changes to a shared library still downstream projects to rebuild, maintaining artifact integrity while drastically reducing CI time compared to build-all approaches.

Why this answer

To build only changed projects in a monorepo, you need to detect which files changed and then determine the affected projects and their dependents. Path filters in the pipeline trigger can limit the pipeline to run only when specific paths change, but they don't handle dependencies. A custom script can analyze the dependency graph and build only the affected projects plus their dependents, minimizing build time.

This approach is flexible and can be implemented in Azure Pipelines using scripts or tools like Nx or Lerna.

Exam trap

AZ-400 often tests the misconception that path filters alone can handle monorepo builds; candidates may forget that dependencies between projects require additional logic to ensure all affected projects are built.

How to eliminate wrong answers

Option A is wrong because building all projects on every commit wastes time and resources, especially in a large monorepo. Option C is wrong because a single pipeline with a condition that checks changed files and runs corresponding jobs can work, but it does not inherently handle dependencies between projects; you would still need to manually define dependencies or use a script. Option D is wrong because separate pipelines triggered manually do not automate the process and do not minimize build time; manual triggers are error-prone and not scalable.

Full explanation →

119

MCQeasy

Refer to the exhibit. You have a YAML pipeline that deploys an ARM template. The pipeline runs successfully on the first commit to main, but subsequent commits fail with 'The resource group myResourceGroup already exists'. How should you modify the pipeline to avoid this error?

A.Change the location to a different region.

B.Add a condition to check if the resource group exists before creating it.

C.Use a different service connection for each deployment.

D.Rename the pipeline to trigger a clean build.

AnswerB

Using an Azure CLI or PowerShell task condition such as `az group exists` (which returns a boolean) before invoking the resource group creation step makes the pipeline idempotent. If the resource group already exists, the creation task is skipped, preventing the 'The resource group already exists' error while still allowing subsequent deployment tasks to run.

Why this answer

Adding a condition to check if the resource group exists before creating it avoids the error when the resource group already exists from a previous deployment. Options A, C, and D are incorrect: changing the location (A) does not prevent the existence error, using a different service connection (C) does not address resource group existence, and renaming the pipeline (D) triggers a new pipeline but does not affect resource group existence.

Full explanation →

120

Matchingmedium

Match each Git branching strategy to its description.

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

Concepts

Matches

Uses develop and feature branches with release branches

Feature branches merged to main with pull requests

Short-lived branches merged frequently to main

Main branch with release branches for production

Why these pairings

Git branching strategies vary in complexity. Git Flow uses long-lived branches (develop, release), GitHub Flow is simple with feature branches to main, GitLab Flow adds environment branches, and trunk-based development centers on frequent commits to main. Common confusions involve swapping descriptions between Git Flow and GitHub Flow.

Full explanation →

121

MCQhard

Refer to the exhibit. You are reviewing a branch protection rule for the main branch of a GitHub repository. A developer complains that after pushing new commits to an existing pull request, the existing approvals from two reviewers are dismissed, and the pull request cannot be merged even though the CI checks pass. What is the most likely cause?

A.The 'dismiss_stale_reviews' setting is enabled, which dismisses approvals when new commits are pushed.

B.The 'strict' setting requires the branch to be up to date with the base branch, which is not the case.

C.The code owner review is required but no code owner has reviewed.

D.The CI check 'continuous-integration/jenkins/pr-merge' failed.

AnswerA

The 'dismiss_stale_reviews' setting is enabled, which automatically invalidates prior pull request approvals whenever new commits are pushed to the branch. This directly explains why previously granted approvals no longer count, forcing re-review after each update.

Why this answer

The 'dismiss_stale_reviews' setting in GitHub branch protection rules automatically dismisses existing pull request approvals when new commits are pushed to the branch. This explains why the developer sees approvals removed after pushing new commits, even though CI checks pass. The setting is designed to ensure that reviewers re-evaluate changes after updates.

Exam trap

The trap here is that candidates may confuse the 'dismiss_stale_reviews' behavior with the 'strict' branch requirement, thinking that being out of date causes approval dismissal, when in fact 'strict' only blocks the merge button without affecting existing approvals.

How to eliminate wrong answers

Option B is wrong because the 'strict' setting (require branches to be up to date) would block merging if the branch is behind the base branch, but it does not dismiss existing approvals; it only prevents merge until the branch is updated. Option C is wrong because code owner review requirement would block merging if no code owner has approved, but it does not dismiss existing approvals from other reviewers; the complaint specifically mentions existing approvals being dismissed. Option D is wrong because the CI check 'continuous-integration/jenkins/pr-merge' passing is stated in the scenario, so a failed check is not the cause of dismissed approvals.

Full explanation →

122

MCQeasy

You want to ensure that every commit message in your repository follows a specific format. Which GitHub feature can enforce this?

A.Webhooks to validate and reject pushes

B.Branch protection rules

C.GitHub Actions workflow with push trigger

D.Required status checks with a commit lint action

AnswerD

A required status check created by a commit lint action (e.g., a GitHub Actions workflow that runs on pull_request and push events) validates commit messages against a convention and reports a success/failure status. By marking that status check as required in branch protection rules, the push or merge is blocked until the commit messages pass the linting rule.

Why this answer

Required status checks, when combined with a commit lint action in a GitHub Actions workflow, can enforce commit message formatting. The workflow runs on push or pull request events, and the status check must pass before a pull request can be merged, effectively rejecting commits that do not conform to the specified format.

Exam trap

The trap here is that candidates confuse a GitHub Actions workflow that runs a commit lint action (which alone does not enforce anything) with the combination of that workflow and a required status check in branch protection rules, which is what actually enforces the commit message format.

How to eliminate wrong answers

Option A is wrong because webhooks can trigger external services to validate pushes, but they cannot directly reject pushes; they only send event payloads. Option B is wrong because branch protection rules can require status checks, code reviews, or prevent force pushes, but they cannot enforce commit message formatting on their own. Option C is wrong because a GitHub Actions workflow with a push trigger can run a commit lint action, but without a required status check configured in branch protection rules, the workflow result does not block non-conforming commits from being merged.

Full explanation →

123

MCQhard

Your organization has multiple GitHub repositories that use shared workflows. You want to centrally manage these workflows and ensure they are always up to date. What is the recommended approach?

A.Create a central repository with reusable workflows and reference them using the 'uses' keyword in your workflows.

B.Use the GitHub API to push workflow files to each repository on a schedule.

C.Download the workflows from a central blob storage and include them as inline scripts.

D.Store the workflows in a separate repository and use Git submodules to include them.

AnswerA

Reusable workflows are the official GitHub Actions pattern: you store a workflow file in a central repository and invoke it from other repositories using the `uses` keyword with a path like `owner/repo/.github/workflows/reusable.yml@ref`. This approach supports inputs, secrets, and version pinning, and is the recommended way to avoid duplicating CI/CD logic across many GitHub repositories.

Why this answer

GitHub reusable workflows are the native mechanism for centralizing workflow logic across repositories. By storing workflows in a central repository and referencing them with the 'uses' keyword (e.g., 'uses: org/central-repo/.github/workflows/build.yml@main'), all consuming repositories automatically inherit updates when the central workflow changes. This eliminates duplication and ensures consistency without manual synchronization.

Exam trap

AZ-400 often tests whether candidates confuse reusable workflows (native, referenced via 'uses') with submodules or API-based file copying — the trap is assuming any 'central storage' approach achieves the same result, when only reusable workflows provide live, version-controlled inheritance.

How to eliminate wrong answers

Option B is wrong because pushing workflow files via the GitHub API on a schedule is a fragile, custom-built synchronization mechanism that creates drift between pushes and requires managing API tokens, rate limits, and error handling. Option C is wrong because downloading workflows from blob storage and running them as inline scripts bypasses GitHub's native workflow engine, loses version control integration, and cannot leverage GitHub's workflow syntax, secrets, or runner context. Option D is wrong because Git submodules track a specific commit SHA, so consuming repositories remain pinned to an old workflow version until someone manually updates the submodule pointer — defeating the 'always up to date' requirement.

Full explanation →

124

MCQhard

You are debugging a recent issue introduced in the main branch. Based on the exhibit, which command would you run to revert the 'Fix login bug' commit while preserving the merge commit?

A.git revert -m 1 HEAD

B.git reset --hard HEAD~1

C.git revert HEAD

D.git revert c3a2b1e -m 2

AnswerA

git revert -m 1 HEAD is the correct approach because the -m 1 flag specifies the first parent (the mainline) as the baseline against which to reverse the changes brought in by the merge commit. This creates a new commit that undoes the merge's net effect on the main branch while preserving the original merge commit and the full branch history, making it a safe, non-destructive reversal for an already-integrated merge.

Why this answer

The 'Fix login bug' commit is a merge commit. To revert a merge commit while preserving its merge parent (i.e., the mainline), you must use `git revert -m 1 HEAD`. The `-m 1` flag specifies that the first parent (the main branch) should be kept, effectively reverting the changes brought by the merge.

Option C, `git revert HEAD`, would fail because Git requires the `-m` flag when reverting a merge commit. Option B destroys history, which is not desired. Option D uses `-m 2`, which would revert the changes from the secondary parent (the feature branch), not the merge itself.

Exam trap

The trap is that candidates assume `git revert HEAD` works for any commit, but reverting a merge commit requires the `-m` flag to specify which parent to keep. Without it, Git returns an error. Also, using `-m 2` would revert the wrong set of changes.

How to eliminate wrong answers

Option A is wrong because `git revert -m 1 HEAD` reverts the merge commit but keeps the changes from the first parent (the main branch), effectively undoing the entire merge and discarding the 'Fix login bug' commit's changes from the merged branch, which is not a simple revert of the commit itself. Option B is wrong because `git reset --hard HEAD~1` removes the merge commit and all its changes from history, which is destructive and does not preserve the merge commit as required. Option D is wrong because `git revert c3a2b1e -m 2` reverts the merge commit while keeping the changes from the second parent (the feature branch), which would undo the merge but retain the 'Fix login bug' commit's changes, contrary to the goal of reverting that specific commit.

Full explanation →

125

Multi-Selectmedium

Your team uses Azure Repos and wants to prevent developers from committing secrets and large binary files into a shared repository. You plan to enforce this with client-side and server-side controls. Which two actions should you take? (Choose two.)

Select 2 answers

A.Require all contributors to sign commits with a GPG key before they can push to the repository.

B.Add a server-side push hook or pipeline validation that rejects pushes containing files above a size limit or matching secret patterns.

C.Install a pre-commit hook that scans staged changes for high-entropy strings and file size thresholds.

D.Configure a .gitignore file in the repository root to exclude build output and binary artifact folders.

E.Enable a branch policy requiring a minimum number of reviewers on the main branch.

AnswersB, C

Server-side enforcement is the authoritative control because it applies to every push regardless of local configuration, which developers can bypass or forget to install. A push hook or validation pipeline can inspect incoming objects, reject oversized files, and scan for credential patterns. This guarantees the repository policy is enforced even when client hooks are absent or disabled.

Why this answer

Effective prevention pairs a local pre-commit hook, which gives fast feedback and stops offending content before it enters history, with authoritative server-side validation, which cannot be bypassed by skipping client hooks. Together they cover both the developer experience and the guarantee. .gitignore, reviewer policies, and commit signing each address different concerns and cannot detect or block secrets and large binaries on their own.

Exam trap

The trap here is treating .gitignore or commit signing as enforcement; only server-side validation reliably blocks content that local controls miss.

Full explanation →

126

Multi-Selecthard

Which THREE practices are recommended for managing secrets in a Git repository? (Select THREE.)

Select 3 answers

A.Use tools like GitLeaks to scan for accidentally committed secrets

B.Store secrets in a separate encrypted file committed to the repository

C.Use GitHub Secrets or Azure Pipelines secret variables

D.Use Azure Key Vault to store and retrieve secrets at build/release time

E.Commit a .env file with default values to the repository

AnswersA, C, D

GitLeaks and similar secret-scanning tools inspect repository history, staging areas, and CI/CD diffs for high-entropy strings and known provider patterns (e.g., AWS Access Key IDs, GitHub tokens). They are typically run as a pre-commit hook or a separate pipeline stage, so leaks are caught early before they propagate to forks or downstream branches. This is a detection control, not a prevention control; it complements secure storage options by providing visibility and enforcing policy on legacy codebases.

Why this answer

The recommended practices for managing secrets in a Git repository include using tools like GitLeaks to scan for accidentally committed secrets (Option A), using GitHub Secrets or Azure Pipelines secret variables (Option C), and using Azure Key Vault to store and retrieve secrets at build/release time (Option D). These approaches help avoid storing secrets directly in the repository. Option B is incorrect because storing secrets in an encrypted file committed to the repository still exposes them to anyone who can access the repo and the decryption key.

Option E is incorrect because committing a .env file with default values risks including sensitive data and is not a secure practice.

Full explanation →

127

Multi-Selecteasy

Your team uses Git for source control. You want to maintain a clean commit history on the main branch by avoiding merge commits. Which TWO merge strategies in a pull request achieve this?

Select 2 answers

A.Rebase merge

B.Merge commit

C.Squash merge

D.Three-way merge

E.Fast-forward merge

AnswersA, C

Rebase merge is the correct choice when you want linear history: it takes each commit from the source branch and applies it onto the latest target branch tip, creating a straight-line history with no merge commit while preserving individual commits.

Why this answer

A rebase merge (option A) rewrites the commit history of the feature branch onto the tip of the target branch, creating a linear sequence of commits without any merge commits. This maintains a clean, linear history on the main branch. A squash merge (option C) combines all commits from the feature branch into a single new commit on the target branch, also avoiding merge commits and keeping the history clean.

Exam trap

The trap here is that candidates often confuse 'fast-forward merge' with a clean history strategy, but fast-forward merges only avoid merge commits when the branches haven't diverged; they do not rewrite or consolidate commits, so they fail to maintain a clean history in the general case.

Full explanation →

128

MCQhard

An Azure Policy is defined as shown in the exhibit. You attempt to create a storage account with HTTPS traffic only set to false. What will happen?

A.The policy will only apply if the storage account is in a specific resource group

B.The storage account will be created but HTTPS will be enforced

C.The storage account will be created and an audit event will be logged

D.The creation will be denied with an error message

AnswerD

The policy effect is 'deny', which causes Azure Resource Manager to evaluate the request and, if the storage account does not have supportsHttpsTrafficOnly set to true, reject the creation with a policy violation error message. The resource is never created as a result.

Why this answer

The Azure Policy in the exhibit uses a 'Deny' effect for the condition that storage accounts must have HTTPS traffic enabled. When you attempt to create a storage account with 'HTTPS traffic only' set to false, the policy evaluation detects a non-compliant resource and denies the creation request, returning an error message. This is because the 'Deny' effect blocks the resource deployment entirely, preventing the non-compliant configuration from being provisioned.

Exam trap

The trap here is that candidates often confuse the 'Deny' effect with 'Audit' or 'Modify', mistakenly thinking the policy will either log the violation or auto-correct the setting, rather than understanding that 'Deny' blocks the operation entirely.

How to eliminate wrong answers

Option A is wrong because the policy definition does not include a scope restriction to a specific resource group; Azure Policies apply at the assigned scope (e.g., subscription or management group) unless a parameter or condition explicitly filters by resource group. Option B is wrong because the 'Deny' effect prevents the storage account from being created at all; it does not allow creation and then enforce HTTPS after the fact—enforcement would require a 'Modify' or 'DeployIfNotExists' effect. Option C is wrong because the 'Deny' effect blocks creation and logs a denial event, but it does not allow creation with an audit event; an 'Audit' effect would log the non-compliance without blocking.

Full explanation →

129

Multi-Selecthard

Your organization uses GitHub Actions for CI/CD. You need to enforce branch protection rules and ensure that all pull requests to the main branch require a successful status check from a specific workflow. Which TWO actions should you take? (Choose two.)

Select 2 answers

A.Configure a GitHub environment with required reviewers.

B.Add a workflow to the repository that runs tests and reports a conclusion status.

C.Use a repository ruleset to require status checks.

D.Set up branch policies in Azure Repos for the main branch.

E.In the repository settings, enable 'Require status checks to pass before merging' under branch protection rules.

AnswersB, E

Adding a workflow that runs tests and reports a conclusion status is the essential first step because it creates a check run (status check) whose conclusion can later be required. Without such a workflow, there is no status check for branch protection rules to enforce, so this is the correct way to enable test validation before merging.

Why this answer

A workflow that runs tests and reports a conclusion status provides the status check that branch protection rules can require. Option E is correct because enabling 'Require status checks to pass before merging' under branch protection rules in the repository settings enforces that the specific workflow's status check must succeed before a pull request can be merged into the main branch.

Exam trap

The trap here is confusing GitHub's branch protection rules with repository rulesets or Azure Repos policies, leading candidates to select options that are either for a different platform or for a different enforcement mechanism.

Full explanation →

130

MCQeasy

You need to ensure that only specific branches can trigger a release to production in Azure Pipelines. What should you configure?

A.Add an approval gate that requires a manager to approve the release.

B.Add a deployment gate that checks the source branch.

C.Add a branch filter to the release pipeline's artifact trigger.

D.Add a branch filter to the build pipeline trigger.

AnswerC

In Azure Pipelines, a release pipeline's artifact trigger can be configured with a branch filter to specify which branches of the source repository are allowed to initiate a release. When you add a branch filter under the artifact trigger of the release pipeline, only builds from those branches (or builds that match the filter) will cause a release to be created, directly meeting the requirement to restrict which branches can trigger a release.

Why this answer

A branch filter on the release pipeline's artifact trigger allows you to specify which branches of the source artifact (e.g., a build pipeline) should automatically trigger a release. By configuring this filter to only include branches like 'main' or 'release/*', you ensure that only builds from those specific branches can initiate a release to production, providing precise control over deployment triggers.

Exam trap

The trap here is confusing branch filters on build pipeline triggers (which control when code is built) with branch filters on release pipeline artifact triggers (which control when releases are created from those builds), leading candidates to incorrectly select Option D.

How to eliminate wrong answers

Option A is wrong because an approval gate requires a manager to approve the release after it is triggered, but it does not restrict which branches can trigger the release; any branch could still initiate the release, and the gate only adds a manual approval step. Option B is wrong because a deployment gate checks conditions (like source branch) at deployment time, but it does not prevent the release from being triggered; it only evaluates whether to proceed with the deployment after the release is already created. Option D is wrong because a branch filter on the build pipeline trigger controls which branches trigger a build, not which branches trigger a release; this would affect when code is compiled, not when a release is deployed to production.

Full explanation →

131

MCQhard

Your team uses GitHub and wants to automatically label pull requests based on the content of the changes (e.g., 'frontend' for changes in /frontend folder, 'backend' for /backend). Which approach should you use?

A.Use branch protection rules to require specific labels based on branch name patterns.

B.Set up a webhook that triggers an Azure Function to parse the pull request diff and add labels.

C.Create a GitHub Actions workflow that runs on pull_request events and uses an action like 'actions/labeler' to add labels based on path patterns.

D.Use a CODEOWNERS file to assign labels based on file paths.

AnswerC

The actions/labeler GitHub Action runs on the pull_request event and uses a declarative configuration file (typically .github/labeler.yml) to map file path patterns to labels. When a PR modifies files matching a pattern, the action automatically adds the corresponding label, making this the purpose-built, native GitHub solution for path-based auto-labeling.

Why this answer

GitHub Actions provides a native, event-driven way to automate labeling based on pull request changes. The 'actions/labeler' action specifically inspects file paths in the diff and applies labels defined in a configuration file, making it the simplest and most maintainable solution for path-based labeling.

Exam trap

The trap here is confusing CODEOWNERS (which assigns reviewers) with label automation, leading candidates to pick option D despite it having no labeling functionality.

How to eliminate wrong answers

Option A is wrong because branch protection rules enforce policies on merging (e.g., required status checks, number of reviewers) but cannot automatically add labels based on branch name patterns. Option B is wrong because while a webhook plus Azure Function could technically work, it introduces unnecessary complexity and external dependencies when a built-in GitHub Actions workflow is available and simpler. Option D is wrong because CODEOWNERS files define who is responsible for code reviews based on file paths, not for automatically applying labels to pull requests.

Full explanation →

132

Multi-Selecthard

Which TWO actions should you take to ensure that Azure Pipelines artifacts are securely stored and access is audited?

Select 2 answers

A.Configure the storage account firewall to only allow access from Azure Pipelines IP ranges

B.Use Azure Policy to enforce that artifacts are only deployed to production storage accounts

C.Enable Azure Artifacts retention policies to automatically delete old artifact versions

D.Enable customer-managed keys (CMK) for artifact encryption

E.Configure audit logging for artifact downloads via Azure DevOps audit logs

AnswersC, E

Enabling Azure Artifacts retention policies automatically deletes old artifact versions, reducing the attack surface and limiting the window in which outdated or potentially vulnerable artifacts can be downloaded or exploited. This is a security best practice that ensures only recent, vetted versions remain available to the pipeline.

Why this answer

Azure Artifacts retention policies allow you to automatically delete older versions of packages, reducing the attack surface and ensuring that only current, approved artifacts are stored. This is a key security practice to prevent outdated or vulnerable artifacts from being accessed. Option E is correct because enabling audit logging for artifact downloads via Azure DevOps audit logs provides a detailed, immutable record of who accessed which artifact and when, which is essential for compliance and security investigations.

Exam trap

The trap here is that candidates often confuse Azure Policy with pipeline governance (e.g., deployment gates) or assume that network-level controls like storage firewalls are the primary security mechanism for Azure Artifacts, when in fact Azure Artifacts is a PaaS service within Azure DevOps that does not expose a direct storage account endpoint for artifact downloads.

Full explanation →

133

MCQmedium

Your team uses Azure Pipelines to deploy a web app to Azure App Service. You need to ensure that secrets (e.g., connection strings) are not exposed in the pipeline logs. What is the recommended approach?

A.Remove all logging from the pipeline.

B.Use secret pipeline variables and reference them in the pipeline.

C.Store secrets in Azure Key Vault and retrieve them in the pipeline, then log them for debugging.

D.Store secrets as environment variables in the pipeline.

AnswerB

Secret pipeline variables are stored encrypted and automatically masked in Azure Pipelines logs, so connection strings never appear in plain text during task execution. Referencing them via `$(variableName)` satisfies the stem's requirement that secrets stay hidden from logs, unlike plain variables which are echoed verbatim.

Why this answer

Azure Pipelines supports secret pipeline variables that are masked in logs, preventing exposure of sensitive data like connection strings. When you mark a variable as secret, its value is automatically hidden from pipeline output, and you can reference it securely using $(variableName) syntax. This is the recommended approach for handling secrets directly within the pipeline without additional service dependencies.

Exam trap

The trap here is that candidates may think storing secrets in Azure Key Vault automatically prevents log exposure, but the retrieval and subsequent logging of those values in the pipeline still leaks them unless they are explicitly marked as secret variables.

How to eliminate wrong answers

Option A is wrong because removing all logging eliminates valuable debugging and auditing information, which is not a practical or recommended security practice; Azure Pipelines provides selective masking instead. Option C is wrong because logging secrets for debugging directly contradicts the goal of preventing exposure; even if retrieved from Key Vault, logging them would still leak sensitive data. Option D is wrong because environment variables in the pipeline are not automatically masked; they can appear in logs if echoed or printed, unlike secret variables which are explicitly hidden.

Full explanation →

134

MCQeasy

Your team is using YAML pipelines in Azure DevOps and wants to ensure that a specific stage runs only for changes to the 'main' branch. Which condition should you add to the stage?

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

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

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

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

AnswerD

This condition uses eq() to perform an exact string comparison against the full source ref 'refs/heads/main'. In Azure Pipelines, Build.SourceBranch contains the full ref, so this matches only the actual main branch and excludes all others, including branches that merely contain 'main' as a substring. It is the precise, minimal condition that satisfies the requirement without adding extra behavior such as succeeded() checks.

Why this answer

The `eq(variables['Build.SourceBranch'], 'refs/heads/main')` condition evaluates to true only when the pipeline is triggered by a change to the 'main' branch. In YAML pipelines, conditions are evaluated as expressions, and this simple equality check ensures the stage runs exclusively for that branch. The other options either invert the logic, use a partial match that could include other branches, or unnecessarily combine conditions.

Exam trap

The trap here is that candidates often choose option B (`contains`) thinking it is a simpler way to match the branch, but they overlook that `contains` does a substring match and will incorrectly trigger on branches like 'maintenance' or 'main-feature', whereas the exact ref comparison in option D is the precise and safe approach.

How to eliminate wrong answers

Option A is wrong because `ne(variables['Build.SourceBranch'], 'refs/heads/main')` runs the stage when the source branch is NOT 'main', which is the opposite of the requirement. Option B is wrong because `contains(variables['Build.SourceBranch'], 'main')` would match any branch containing 'main' in its ref path (e.g., 'refs/heads/main-feature' or 'refs/heads/notmain'), not just the exact 'main' branch. Option C is wrong because while it correctly checks for 'main', it adds `and(succeeded(), ...)` which is redundant since stages default to running only if the previous stage succeeded; this extra condition does not break the logic but is unnecessary and not the simplest correct answer.

Full explanation →

135

Multi-Selectmedium

Your organization is implementing a security compliance plan for Azure DevOps. Which TWO actions help enforce the principle of least privilege?

Select 2 answers

A.Allow all team members to edit security permissions

B.Use Azure DevOps security groups to grant minimal permissions

C.Use built-in roles without customizing

D.Restrict who can create new agent pools to a small admin team

E.Grant Project Collection Administrators group to all developers

AnswersB, D

Azure DevOps security groups let you assign permissions to teams rather than individuals, granting only the access each role needs. This directly enforces least privilege by scoping rights to group membership instead of broad default permissions.

Why this answer

Option B is correct because Azure DevOps security groups (such as Project Administrators, Contributors, or custom groups) let you assign only the specific permissions each team needs, directly implementing least privilege instead of granting broad access. Option D is correct because restricting agent pool creation to a small admin team limits a powerful, organization- or project-level capability (managing agent pools and their security) to the few users who require it, reducing the attack surface. Option A is wrong because allowing all team members to edit security permissions grants everyone the ability to change ACLs, which violates least privilege.

Option C is wrong because using built-in roles without customizing can over-grant permissions, since built-in roles often include more rights than a given user needs. Option E is wrong because Project Collection Administrators is the highest-privilege group in Azure DevOps and should be tightly limited, not assigned to all developers.

Exam trap

The trap here is that candidates often assume built-in roles are always the safest choice (Option C), but Azure DevOps built-in roles like 'Project Administrators' grant broad permissions that exceed least privilege, whereas custom security groups with minimal permissions are more secure.

Full explanation →

136

MCQmedium

You are configuring a release pipeline that deploys to multiple environments. You want to automate the deployment to the staging environment only if the build succeeds, and then require manual approval before deploying to production. Which strategy should you use?

A.Define an environment with approvals required for the production stage.

B.Use deployment gates in the production stage to check for manual intervention.

C.Use a classic release pipeline with pre-deployment approvals.

D.Configure a branch policy on the main branch to require approval for pull requests.

AnswerA

Defining an environment and enabling the approval check on its production stage is the correct way to require a manual sign-off before deployment. This approval is configured on the environment itself and naturally integrates with multi-stage YAML pipelines, ensuring that only authorized users can deploy to production.

Why this answer

Azure Pipelines allows you to define environments with explicit approval checks. By adding a manual approval gate on the production environment stage, the pipeline will automatically deploy to staging after a successful build, but pause before production until an authorized user approves the release. This directly meets the requirement for automated staging deployment and manual production approval.

Exam trap

The trap here is that candidates often confuse deployment gates (which are automated checks) with manual approvals, leading them to incorrectly select Option B, even though gates cannot provide the required manual intervention step.

How to eliminate wrong answers

Option B is wrong because deployment gates are designed for automated health checks (e.g., monitoring metrics, incident status) and do not support manual intervention; they evaluate conditions automatically, not wait for human approval. Option C is wrong because classic release pipelines with pre-deployment approvals are a legacy approach that still works, but the question asks for a strategy in the context of modern YAML-based multi-stage pipelines, where environment approvals are the recommended method. Option D is wrong because branch policies on the main branch control pull request merges and code quality, not release deployment approvals; they are unrelated to the release pipeline's manual approval requirement.

Full explanation →

137

Multi-Selecthard

Which TWO actions should you take to ensure that Azure Pipelines artifacts are scanned for vulnerabilities before production deployment? (Choose two.)

Select 2 answers

A.Run dependency scanning on the artifact manifest

B.Sign the artifacts with a code signing certificate

C.Use Microsoft Defender for Cloud to scan the artifact during the pipeline

D.Scan the infrastructure as code templates

E.Run static code analysis on the source code

AnswersA, C

Dependency scanning on the artifact manifest examines the SBOM or dependency lock files (e.g., package-lock.json, packages.lock.json) to identify known Common Vulnerabilities and Exposures (CVEs) in third-party libraries. In Azure Pipelines, this is done with tools like Trivy or OWASP Dependency Check, ensuring that the exact dependency versions that ship in the artifact are assessed for vulnerabilities.

Why this answer

Option A is correct because running dependency scanning on the artifact manifest inspects the exact third-party packages and versions recorded in the artifact (e.g., via tools like Trivy, Grype, or OWASP Dependency-Check against SBOM/manifest files), catching known CVEs in the components that will actually ship to production. Option C is correct because Microsoft Defender for Cloud (specifically Defender for DevOps/Defender for Containers) integrates with Azure Pipelines to scan artifacts such as container images and IaC during the build/release flow and surface vulnerability findings before deployment. Option B is not correct because code signing provides integrity and authenticity assurance, not vulnerability detection.

Option D is not correct because scanning IaC templates finds misconfigurations in infrastructure definitions, not vulnerabilities in the deployed artifact itself. Option E is not correct because static code analysis examines source code for coding flaws, not the built artifact that is promoted to production.

Exam trap

The trap is substituting adjacent security practices — code signing, IaC scanning, or SAST — for actual artifact vulnerability scanning; only manifest/dependency scanning and Defender for Cloud artifact scanning detect CVEs in the built artifact.

Full explanation →

138

MCQhard

Your release pipeline uses deployment groups to deploy to Windows servers. You need to securely pass credentials to a script that runs on target machines. What is the recommended approach?

A.Hardcode credentials in the script and encrypt the script file

B.Store credentials as pipeline variables and reference them

C.Use Azure Key Vault task to fetch secrets during deployment

D.Use environment variables on the target machines

AnswerC

The Azure Key Vault task securely retrieves secrets from Key Vault at deployment time and injects them as variables, ensuring that credentials are not stored in the pipeline or exposed in logs while centralizing access and enabling rotation.

Why this answer

The Azure Key Vault task securely retrieves secrets (e.g., passwords) from an Azure Key Vault during deployment, avoiding hardcoded or exposed credentials. This integrates with Azure Pipelines to pass secrets to scripts without storing them in the pipeline or on target machines, adhering to least-privilege and secure secret management practices.

Exam trap

The trap here is that candidates may choose Option B (pipeline variables) thinking they are secure because they can be marked as secret, but they lack the centralized management, rotation, and access control that Azure Key Vault provides, which is the recommended approach for production secrets.

How to eliminate wrong answers

Option A is wrong because hardcoding credentials in a script, even if encrypted, violates security best practices and is difficult to rotate or audit; encryption keys can be compromised. Option B is wrong because pipeline variables, even marked as secret, are stored in the pipeline definition and can be exposed in logs or export operations, and they do not provide centralized secret management. Option D is wrong because environment variables on target machines are static, not centrally managed, and can be read by any process or user on the machine, leading to credential leakage.

Full explanation →

139

MCQhard

Your Azure DevOps project uses a self-hosted agent pool. Users report that builds are randomly failing with a 'disk full' error. The agents have 50 GB of disk space. What is the most effective way to mitigate this issue?

A.Add more agents to the pool

B.Use the 'Clean all build directories' option in the agent configuration

C.Enable the 'Clean after build' option on the build pipeline

D.Set 'Maximum number of parallel jobs' to 1

AnswerC

Enabling 'Clean after build' on the build pipeline triggers an automated workspace purge, typically using commands like `git clean -fdx` or equivalent, immediately after each job finishes. This removes source files, compiled outputs, test binaries, and cached dependencies from the agent's working directory (e.g., `_work`) at the point when they are no longer needed, so disk space is reclaimed on a per-build basis. This directly prevents the steady accumulation of stale build artifacts that ultimately exhausts the agent's local storage.

Why this answer

Enabling 'Clean after build' ensures workspace cleanup after each run, reclaiming disk space to prevent failures. Option A is wrong because adding more agents doesn't free disk space on existing agents. Option B is wrong because 'Clean all build directories' cleans before builds, which may not prevent mid-build disk full errors and can disrupt parallel builds.

Option D is wrong because limiting parallel jobs doesn't free disk space; a single build can still consume all available disk space.

Full explanation →

140

MCQeasy

You are setting up a release pipeline that deploys to multiple environments (dev, test, prod) sequentially. Each environment requires approval before deployment. What is the best way to implement this in Azure Pipelines?

A.Define pipeline stages with environment resources and pre-deployment approvals.

B.Use environment resources with 'auto' trigger and no approvals.

C.Use classic release pipelines with approval gates per environment.

D.Use a custom PowerShell script to pause and prompt for approval.

AnswerA

Defining stages with environment resources and pre-deployment approvals is the correct approach because each environment maps to a resource in Azure DevOps, and pre-deployment approvals provide a built-in, auditable manual sign-off before the deployment proceeds, making it the native and recommended YAML pipeline pattern.

Why this answer

Azure Pipelines supports multi-stage YAML pipelines where each stage can reference an environment resource. Pre-deployment approvals are configured on the environment itself, ensuring that before a stage deploys to that environment, the specified approvers must grant approval. This provides a native, auditable, and integrated approval gate without custom scripting or legacy tooling.

Exam trap

The trap here is that candidates may think classic release pipelines are still the best practice, but Microsoft has not deprecated classic releases; they are legacy and Microsoft recommends YAML pipelines with environment resources for better traceability, consistency, and integration with modern DevOps practices.

How to eliminate wrong answers

Option B is wrong because using 'auto' trigger with no approvals would automatically deploy to each environment without any manual intervention, failing the requirement for approval before deployment. Option C is wrong because classic release pipelines are a legacy approach; while they do support approval gates, the modern and recommended approach for multi-environment sequential deployments is to use YAML pipelines with environment resources and pre-deployment approvals. Option D is wrong because using a custom PowerShell script to pause and prompt for approval is brittle, non-auditable, bypasses the built-in approval workflow, and does not integrate with Azure Pipelines' environment resource tracking or deployment history.

Full explanation →

141

MCQmedium

Your organization requires compliance with SOC 2 and needs to audit all changes to Azure Pipelines. What should you enable?

A.Azure Policy

B.Microsoft Purview

C.Azure Blueprints

D.Azure DevOps audit logs

AnswerD

Azure DevOps audit logs capture security-relevant events such as pipeline run changes, permission modifications, and user access updates, and they can be exported to Log Analytics or SIEM tools for SOC 2 compliance. They provide the immutable, timestamped record of who did what and when, directly meeting the audit requirement.

Why this answer

Azure DevOps audit logs capture all changes to pipelines and can be exported for compliance with SOC 2. Option A is incorrect because Azure Policy enforces governance rules on Azure resources, not pipeline changes. Option B is incorrect because Microsoft Purview is a data governance service, not for auditing DevOps changes.

Option C is incorrect because Azure Blueprints (now deprecated) were used to define repeatable Azure environments, not for audit logging.

Full explanation →

142

MCQmedium

Your team uses Microsoft-hosted agents for builds. Recently, builds are taking longer to start. What is the best way to reduce queue times?

A.Increase the number of parallel jobs in the organization.

B.Use more pipeline triggers.

C.Provision self-hosted agents.

D.Reduce the number of parallel jobs.

AnswerC

Self-hosted agents are owned and managed by your team, providing dedicated compute capacity that operates independently of Microsoft's hosted agent pool. By registering self-hosted agents in an agent pool that your pipelines target, you can scale out processing capacity and reduce or eliminate queue waiting times, especially for high-frequency builds.

Why this answer

Microsoft-hosted agents share a global pool with other Azure DevOps organizations, so queue times increase during peak usage. Provisioning self-hosted agents gives you dedicated compute resources that are always available, eliminating dependency on the shared pool and reducing queue wait times.

Exam trap

The trap here is that candidates confuse 'parallel jobs' (concurrency limit) with 'agent availability' (queue wait time), assuming that buying more parallelism will speed up agent assignment when it only affects how many builds can run at once.

How to eliminate wrong answers

Option A is wrong because increasing parallel jobs only allows more builds to run concurrently once they start, but does not reduce the time a build waits in the queue for an available agent. Option B is wrong because pipeline triggers control when a build is initiated, not how quickly an agent is assigned to run it; more triggers could actually increase queue congestion. Option D is wrong because reducing parallel jobs would decrease the number of builds that can run simultaneously, likely increasing queue times further.

Full explanation →

143

MCQmedium

Your organization uses GitHub Actions for CI/CD. You want to enforce that all workflows pass required checks before a pull request can be merged. The repository is in an organization that uses GitHub Enterprise Cloud. What should you configure?

A.Add a branch protection rule that requires status checks to pass.

B.Enable 'Require approval for all workflows' in the organization settings.

C.Set the workflow to be required in the 'Require status check' settings of each pull request.

D.Create a repository ruleset that requires linear history.

AnswerA

Branch protection rules with required status checks block merging until specified GitHub Actions workflows report success. This enforces that all required checks pass before any pull request merges into the protected branch, satisfying the organisation's gating requirement.

Why this answer

Branch protection rules in GitHub Enterprise Cloud allow you to require status checks to pass before merging a pull request. By configuring a branch protection rule on the target branch (e.g., main) and selecting the specific GitHub Actions workflow status checks that must succeed, you enforce that all required CI/CD checks pass before a merge is allowed. This directly meets the requirement to enforce workflow checks on pull requests.

Exam trap

The trap here is confusing organization-level workflow approval settings (which control workflow execution) with branch-level status check requirements (which control merge permissions), leading candidates to select option B or C instead of the correct branch protection rule.

How to eliminate wrong answers

Option B is wrong because 'Require approval for all workflows' is a setting that controls whether external contributors' workflows require approval before running, not a mechanism to enforce status checks on pull requests. Option C is wrong because there is no 'Require status check' setting on individual pull requests; status checks are configured at the branch or repository level via branch protection rules or rulesets. Option D is wrong because requiring linear history enforces a linear commit history (e.g., via rebase or squash merges) but does not enforce that workflows pass checks before merging.

Full explanation →

144

Multi-Selecthard

Which THREE are valid security best practices for Azure Pipelines? (Choose three.)

Select 3 answers

A.Restrict agent pool permissions to only necessary users

B.Use Microsoft Entra ID to control access to pipelines

C.Store secrets as plain text in YAML files

D.Use variable groups with Azure Key Vault integration for secrets

E.Run build agents on domain controllers

AnswersA, B, D

Agent pool permissions determine which identities can queue jobs onto agents, so restricting them to necessary users prevents unauthorised pipeline runs and credential exposure on shared agents. This enforces least privilege at the compute boundary, a core Azure Pipelines security control.

Why this answer

Option A is correct because restricting agent pool permissions to only necessary users enforces least privilege, preventing unauthorized users from creating or modifying agents that could execute malicious pipeline jobs. Option B is correct because Microsoft Entra ID (formerly Azure AD) provides centralized identity and access control for Azure DevOps, enabling conditional access, MFA, and role-based assignments to secure pipeline access. Option D is correct because variable groups integrated with Azure Key Vault keep secrets out of YAML and pipeline definitions, retrieving them securely at runtime with proper access policies.

Option C is not a best practice because storing secrets as plain text in YAML files exposes them to anyone with repository read access and to logs or history. Option E is not a best practice because running build agents on domain controllers violates the principle of least privilege and exposes critical identity infrastructure to pipeline workloads.

Exam trap

The trap here is that candidates may think storing secrets in YAML files is acceptable if the repository is private, but Azure Pipelines explicitly warns against this because secrets can be exposed in pipeline logs, build artifacts, or through source control history.

Full explanation →

145

MCQhard

Your Azure DevOps pipeline deploys a microservice to a Kubernetes cluster using Helm. The Helm chart requires a values file that contains environment-specific configurations. You want to store the values file securely and use it during deployment. What is the recommended approach?

A.Store the values in a variable group and map them to Helm values.

B.Store the values file in Azure Key Vault and use the HelmDeploy task's 'overrideValues' parameter to set values.

C.Store the values file as a secure file in Azure Pipelines library.

D.Store the values file in a separate Git repository and clone it during the pipeline.

AnswerC

Secure files in the Azure Pipelines Library are encrypted at rest and can be downloaded during a pipeline run using the DownloadSecureFile task, which yields a temporary file path. This makes it the correct choice for storing a sensitive Helm values file because the original file never resides in source control and is exposed only as an encrypted library artifact.

Why this answer

Azure Pipelines provides a 'Secure files' library feature specifically designed to store files (like Helm values files, certificates, or keystores) that need to be downloaded securely during a pipeline run. The DownloadSecureFile task retrieves the file at runtime, and it can then be passed to the HelmDeploy task, keeping environment-specific configuration out of source control.

Exam trap

AZ-400 often tests the distinction between variable groups (key-value), Key Vault (secrets/certs), and Secure files (arbitrary files), so candidates who default to 'Key Vault for everything secure' pick the wrong answer for file-based configuration.

How to eliminate wrong answers

Option A is wrong because variable groups store key-value pairs, not files, and mapping them to Helm values is cumbersome and doesn't handle multi-line YAML structures well. Option B is wrong because Azure Key Vault stores secrets, keys, and certificates — not arbitrary YAML files — and the HelmDeploy task's overrideValues parameter expects inline values, not a Key Vault reference. Option D is wrong because storing the values file in a separate Git repository still exposes it to anyone with repo access and does not provide the secure, access-controlled storage that the Secure files library offers.

Full explanation →

146

MCQeasy

You have an Azure DevOps pipeline that deploys to multiple environments. You need to ensure that approvals are required before production deployment. Which pipeline configuration should you use?

A.Set the pipeline trigger to 'Manual' only

B.Add a 'Manual Intervention' task in the pipeline

C.Configure branch policies on the main branch

D.Define an environment with required approvers for the production stage

AnswerD

Defining an environment with required approvers is the correct approach because Azure Pipelines environments provide pre-deployment approval checks that pause the pipeline before the production stage runs. Each deployment to that environment must be explicitly approved by the listed users or groups, creating an auditable, enforceable gate before any production release proceeds.

Why this answer

Azure DevOps environments allow you to define required approvers for a specific stage (e.g., production). When a pipeline deploys to that environment, it pauses and waits for manual approval before proceeding, ensuring that production deployments are gated by authorized personnel.

Exam trap

The trap here is that candidates confuse branch policies (which control code merging) with deployment approvals (which control release execution), leading them to select option C instead of the environment-based approval mechanism.

How to eliminate wrong answers

Option A is wrong because setting the pipeline trigger to 'Manual' only prevents automatic pipeline runs but does not enforce approvals during the deployment process; approvals are a separate gate mechanism. Option B is wrong because the 'Manual Intervention' task is a legacy feature that pauses the pipeline for manual input, but it is not designed for multi-environment approval workflows and does not integrate with Azure DevOps environment-based approval gates. Option C is wrong because branch policies on the main branch control code quality and pull request merges, not deployment approvals; they do not gate the release pipeline after code is merged.

Full explanation →

147

MCQhard

Your company uses Azure DevOps and must comply with SOC 2. The auditor requires proof that all production deployments went through a change management process with approval. What should you implement?

A.Use branch policies to require pull request approvals

B.Set pipeline retention policies to keep deployment records

C.Enable audit logging for all pipelines

D.Configure release approval gates in Azure Pipelines

AnswerD

Release approval gates in Azure Pipelines require designated approvers to explicitly approve a release stage before it continues, directly enforcing a formal sign-off step for production deployments—this aligns with SOC 2's change-management and authorization requirements by making approval a mandatory precondition.

Why this answer

Release approval gates in Azure Pipelines allow you to define approvers who must approve a deployment before it proceeds. This enforces a change management process with documented approval, providing an audit trail that satisfies SOC 2 requirements. Approval gates can be configured for specific environments or stages, ensuring that all production deployments are reviewed.

Exam trap

AZ-400 often tests the difference between code review approvals (branch policies) and deployment approvals (release gates), and candidates may incorrectly choose branch policies for deployment change management.

How to eliminate wrong answers

Option A is wrong because branch policies require pull request approvals, which are for code changes, not specifically for production deployments; they do not enforce approval at the deployment stage. Option B is wrong because retention policies only control how long records are kept, not whether approvals occurred. Option C is wrong because audit logging records activities but does not enforce approvals; it is a detective control, not a preventive one.

Full explanation →

148

Multi-Selecteasy

Which TWO strategies can you use to manage secrets in Azure Pipelines securely?

Select 2 answers

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

B.Store secrets directly in the YAML pipeline file.

C.Use the 'secret' variable type in the pipeline UI.

D.Use environment variables in the build agent.

E.Print the secret in a script to verify it is correct.

AnswersA, C

A variable group linked to Azure Key Vault enables pipelines to reference secrets stored in Key Vault without never copying them into the pipeline definition. Access is governed by Azure RBAC, and secret values are dynamically retrieved at run time, keeping them out of source control and logs.

Why this answer

Options A and C are correct. Variable groups can be linked to Azure Key Vault to fetch secrets, and you can mark variables as secret in the pipeline UI to prevent them from being displayed in logs. Option B is wrong because storing secrets in YAML files exposes them in source control.

Option D is wrong because using environment variables on the build agent is not inherently secure; they can be accessed by other processes and may be logged. Option E is wrong because printing secrets in scripts exposes them in the pipeline logs, which is a security risk.

Full explanation →

149

MCQeasy

Your organization uses Microsoft Entra ID. You want to ensure that only users from specific countries can access Azure DevOps. Which security feature should you configure?

A.Microsoft Entra ID Conditional Access policies

B.Azure Network Security Group (NSG) rules

C.Azure DevOps security groups with allowed IP ranges

D.Microsoft Intune compliance policies

AnswerA

Microsoft Entra ID Conditional Access policies evaluate signals like user location, device state, and risk at sign-in time, allowing you to enforce restrictions such as blocking access from untrusted IP ranges or requiring MFA when users connect from outside the corporate network.

Why this answer

Microsoft Entra ID Conditional Access policies allow you to enforce location-based access controls by specifying allowed countries or IP ranges. By configuring a Conditional Access policy that targets Azure DevOps (as a cloud app) and setting the condition to 'Locations' with 'Selected countries,' you can restrict sign-ins to only users from those countries. This is the correct approach because Azure DevOps relies on Entra ID for authentication, and Conditional Access is the native mechanism to control access based on geographic location.

Exam trap

The trap here is that candidates often confuse network-level controls (NSGs) or IP allowlisting in Azure DevOps with identity-based location policies, overlooking that Conditional Access is the correct mechanism for restricting access by country in a SaaS context like Azure DevOps.

How to eliminate wrong answers

Option B is wrong because Azure Network Security Group (NSG) rules operate at the network layer (L3/L4) to filter traffic to Azure resources like VMs or virtual networks, but they cannot restrict user authentication to Azure DevOps, which is a SaaS service accessed over the internet. Option C is wrong because Azure DevOps security groups do not support IP range restrictions; IP allowlisting is configured at the organization level via 'Organization settings > Policies > Security policies,' not through security groups, and it applies to all users, not per-group. Option D is wrong because Microsoft Intune compliance policies are designed to enforce device compliance (e.g., OS version, encryption) for managed devices, not to restrict access based on user location or country.

Full explanation →

150

MCQeasy

Your team uses Azure Test Plans. You need to ensure that testers can easily see which test cases are blocked by a known bug. What should you do?

A.Configure the test plan to show only failed tests.

B.Create a test suite for each bug.

C.Link test cases to the bug and create a query for linked items.

D.Copy the test case and mark it as blocked.

AnswerC

Linking each blocked test case to its bug creates a traceable relationship, and a work item query filtering on linked items surfaces those test cases, giving testers a clear view of what the known bug blocks.

Why this answer

Azure Test Plans allows test cases to be linked directly to bugs via work item linking. By creating a query for linked items (e.g., a shared query that returns all test cases linked to a specific bug), testers can instantly see which test cases are blocked by that known bug. This provides a dynamic, filterable view without duplicating or reorganizing test artifacts.

Exam trap

The trap here is that candidates often confuse 'marking a test as blocked' (a manual status change) with the proper traceability approach of linking work items, leading them to choose Option D or B instead of leveraging Azure DevOps' built-in query and linking capabilities.

How to eliminate wrong answers

Option A is wrong because configuring the test plan to show only failed tests does not indicate which failures are caused by a known bug; it simply filters out passed tests, leaving all failures regardless of root cause. Option B is wrong because creating a test suite for each bug would require manual duplication and maintenance of test cases, leading to redundancy and confusion when bugs are fixed or closed. Option D is wrong because copying a test case and marking it as blocked creates an unnecessary duplicate that must be manually tracked and updated, breaking the traceability between the original test case and the bug.

Full explanation →

Microsoft Azure DevOps Engineer Expert AZ-400 (AZ-400) — Questions 76–150