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

MCQhard

Your organization uses GitHub Actions for CI/CD. You need to ensure that secrets stored in GitHub are not exposed in build logs. A developer accidentally printed a secret to the console in a workflow step. How can you prevent this from happening in the future?

A.Enable 'Secret scanning' and 'Push protection' for the repository.

B.Add the secret to the 'Secret scanning' exclusion list.

C.Instruct developers to avoid using 'echo' and use '::set-output' instead.

D.Use the 'actions/secrets' action to mask secrets automatically.

AnswerA

These features detect and block secrets in code and logs.

Why this answer

Enabling Secret scanning and Push protection for the repository helps prevent secrets from being exposed in build logs. Secret scanning can detect secrets when they are pushed or used in workflows, and Push protection blocks pushes containing secrets. Additionally, GitHub Actions automatically masks any string that matches a repository secret or organization secret if it appears in logs, but the developer accidentally printed it.

Enabling these features provides proactive detection and prevention. Option B is incorrect because adding the secret to the exclusion list would allow it to be exposed. Option C is incorrect because echoing with `::set-output` still prints the value to logs.

Option D is incorrect because the `actions/secrets` action does not exist; secrets are accessed via the `secrets` context.

Full explanation →

MCQeasy

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

A.Runs the pipeline on all branches with the variable.

B.Runs the pipeline and sets a secret variable.

C.Runs the pipeline named 'MyPipeline' on the 'main' branch with a variable 'myVar' set to 'value1'.

D.Creates a new pipeline named 'MyPipeline' with a variable.

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

MCQmedium

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

A.Use Azure Monitor diagnostic settings for the App Service.

B.Enable Application Insights Java agent in the App Service.

C.Attach a profiler from Visual Studio to the App Service process.

D.Configure App Service diagnostic logs to capture stdout/stderr.

AnswerB

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

Why this answer

The Application Insights Java agent automatically captures JVM metrics such as heap usage and garbage collection, and it integrates with Azure Pipelines to correlate deployment events with these metrics. Option A is incorrect because Azure Monitor diagnostic settings capture Azure platform logs, not application-level JVM metrics. Option C is incorrect because the Visual Studio profiler is designed for local or development debugging, not for automatic production monitoring.

Option D is incorrect because diagnostic logs for stdout/stderr capture application output, not JVM internals.

Full explanation →

MCQhard

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

A.Configure a branch policy on the main branch that requires a successful build and security scan before merging, and use a single pipeline that includes the scan.

B.Integrate the security scan as a step early in the CI pipeline, and configure branch policies on the main branch to require two reviewers from different teams and a successful CI build including the scan. Document the process and use Copilot to generate commit messages that reference work items.

C.Create a separate security scan pipeline triggered on pull request creation, and require its successful completion via branch policy. Then set up a separate PR policy requiring two reviewers.

D.Add a manual approval gate in the release pipeline that requires the security officer to approve after the scan completes.

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

Multi-Selecthard

Your organization uses Azure Key Vault to store secrets and certificates used in Azure Pipelines. You need to implement a security and compliance plan that ensures secrets are rotated automatically and access is audited. Which THREE actions should you take?

Select 3 answers

A.Enable soft-delete and purge protection on the Key Vault.

B.Use a resource lock on the Key Vault to prevent deletion.

C.Use a Key Vault access policy to grant developers full access.

D.Use Managed Identity to authenticate Azure Pipelines to Key Vault.

E.Configure Key Vault certificate auto-rotation with a specified lifetime.

AnswersA, D, E

Soft-delete and purge protection are critical for compliance to recover deleted secrets and prevent permanent loss.

Why this answer

Enabling soft-delete and purge protection ensures deleted secrets and certificates can be recovered and permanent deletion is blocked, which is important for compliance and recovery. Using a managed identity for Azure Pipelines removes the need to store and rotate credentials, and each access is tied to a known identity, enabling access auditing. Configuring certificate auto-rotation with a specified lifetime ensures secrets are rotated automatically.

Together, these actions address recovery, secure access, and automatic rotation as required.

Exam trap

The trap here is that candidates often confuse resource locks (Option B) with soft-delete/purge protection, thinking that a resource lock alone satisfies compliance requirements, but it does not provide the recovery and audit capabilities required for secret rotation and access auditing.

Full explanation →

MCQmedium

Your organization uses Microsoft Defender XDR to secure Azure DevOps pipelines. You need to ensure that any build pipeline triggered by a pull request automatically runs a security scan and fails if critical vulnerabilities are found. What should you configure?

A.Code scanning alerts in GitHub

B.Azure Policy for Pipelines

C.Branch protection rule with required status check

D.Pipeline security gate

AnswerC

In Azure Repos, branch protection rules (often called branch policies) allow you to require that a specific status check succeeds before a pull request can be merged. You can create a pipeline that runs your security scan on PRs and publishes a status named 'security-scan,' then configure the branch policy to require that check. This creates a hard enforcement gate: merges are blocked until the status check passes, ensuring only scanned code is merged into the protected branch. This is the correct approach for integrating a security scan into the merge workflow.

Why this answer

Branch protection rules in Azure Repos or GitHub can require a status check from a build pipeline. By configuring a required status check that runs a security scan, the pull request cannot be merged if the scan fails. Option A (Code scanning alerts in GitHub) is for identifying vulnerabilities in code, not blocking merges based on pipeline results.

Option B (Azure Policy for Pipelines) enforces governance on Azure resources, not pipeline security scans. Option D (Pipeline security gate) is not a feature in Azure DevOps.

Full explanation →

MCQhard

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

A.Add a step that pauses the pipeline until a manual approval is received via a custom webhook.

B.Use a workflow_dispatch trigger and require the senior developer to manually run the production deployment.

C.Use a build matrix to run staging and production deployments in parallel.

D.Use two environments (staging and production) with required reviewers on the production environment, and use conditional steps to deploy to staging first.

AnswerD

Environment protection rules enforce approvals, and conditional steps ensure order.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

MCQmedium

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

A.Configure a Sentinel analytics rule with the alert and use automated response to send an email.

B.Set up an Azure DevOps service hook that triggers on pipeline events.

C.Use Azure Policy to deny changes to service connections.

D.Create a Sentinel playbook using Azure Logic Apps that calls the Azure DevOps REST API to update the service connection status.

AnswerD

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

Why this answer

Sentinel playbooks (based on Azure Logic Apps) can automate responses to alerts, including calling the Azure DevOps REST API to disable a service connection. Option A is incorrect because an analytics rule with automated response can send notifications but cannot directly interact with Azure DevOps to disable a connection. Option B is incorrect because Azure DevOps service hooks trigger on pipeline events, not on Sentinel alerts.

Option C is incorrect because Azure Policy can prevent changes to service connections but cannot disable an existing active service connection.

Full explanation →

MCQeasy

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

A.Agent Health dashboard

B.Release Analytics

C.Test Analytics

D.Pipeline Run Analytics

AnswerA

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

Why this answer

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

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

MCQhard

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

A.Whether secure files are rotated within 90 days

B.Whether pipelines use secure files with extensions other than .pfx, .p12, or .cer

C.Whether secure files are encrypted at rest

D.Whether secure files are used in production pipelines

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

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 →

MCQhard

Your release pipeline uses deployment groups to deploy to on-premises servers. You want to ensure that only one deployment runs at a time on each server. Which option should you configure?

A.Set the deployment queue to 'Deploy one at a time' with 'Exclusive lock'.

B.Configure a pre-deployment condition that checks the current deployment status.

C.Add a manual approval step before each deployment.

D.Set the deployment queue to 'Deploy all in parallel' with 'Number of parallel deployments' set to 1.

AnswerA

Exclusive lock ensures that only one deployment runs on each target at a time.

Why this answer

Setting the deployment queue to 'Deploy one at a time' with 'Exclusive lock' ensures that only one deployment runs at a time on each server in the deployment group. This lock prevents concurrent deployments to the same target, which is essential for on-premises servers that cannot handle parallel updates without conflicts.

Exam trap

The trap here is that candidates confuse 'Deploy one at a time' with a simple queue setting, but the key is the 'Exclusive lock' option, which specifically prevents concurrent deployments to the same resource, unlike parallel deployment settings that only control the number of simultaneous runs across different targets.

How to eliminate wrong answers

Option B is wrong because a pre-deployment condition that checks the current deployment status does not enforce a queue-based lock; it only evaluates a condition before starting a deployment, but multiple deployments could still start simultaneously if the condition passes. Option C is wrong because a manual approval step only pauses the pipeline for human intervention, but it does not prevent concurrent deployments to the same server once approved. Option D is wrong because setting 'Deploy all in parallel' with 'Number of parallel deployments' set to 1 still allows parallel deployments across multiple servers, not a per-server exclusive lock, and it does not prevent concurrent runs on the same server.

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 →

MCQhard

Your team uses Azure Pipelines to deploy a web app to Azure App Service. The deployment uses the 'AzureWebApp@1' task with a deployment slot. You need to ensure that after a successful deployment to the staging slot, the slot swap happens automatically and the staging slot is warmed up before the swap. Which configuration should you use?

A.Use the 'Azure App Service manage' task to swap slots after deployment.

B.Set the 'Slot' parameter to 'staging' and enable 'Swap with production' in the task.

C.Use the 'Azure CLI' task to run 'az webapp deployment slot swap' after deployment.

D.Configure the deployment task to deploy to staging and then use a separate task to swap.

AnswerB

This automatically swaps after deployment with warmup.

Why this answer

The 'AzureWebApp@1' task includes a 'Swap with production' checkbox that, when enabled, automatically performs a slot swap after the deployment to the specified slot (e.g., staging) completes. This ensures the staging slot is warmed up by the deployment process before the swap, as the swap operation respects the warm-up phase of the target slot, preventing downtime and ensuring the production slot receives a fully initialized application.

Exam trap

The trap here is that candidates often think a separate swap task or CLI command is required for slot swapping, but the 'AzureWebApp@1' task's built-in 'Swap with production' option handles both deployment and warm-up automatically, making it the simplest and most reliable choice.

How to eliminate wrong answers

Option A is wrong because the 'Azure App Service manage' task is a separate task that can swap slots, but it does not inherently integrate with the deployment task to ensure automatic warm-up before swap; it requires manual sequencing and does not leverage the built-in warm-up behavior of the deployment task. Option C is wrong because using the 'Azure CLI' task to run 'az webapp deployment slot swap' after deployment adds unnecessary complexity and does not automatically handle warm-up; the CLI command performs a swap but does not guarantee the staging slot is warmed up before the swap unless additional warm-up logic is explicitly implemented. Option D is wrong because deploying to staging and then using a separate task to swap is a valid approach but lacks the automatic warm-up guarantee provided by the 'Swap with production' setting in the 'AzureWebApp@1' task; the separate swap task may swap before the staging slot is fully warmed up, leading to potential downtime or cold-start issues.

Full explanation →

MCQmedium

An organization has multiple Git repositories. Developers often forget to update the repository README file after making changes. What is the most effective way to ensure the README is always up-to-date?

A.Apply a label to PRs that touch certain files and require review

B.Add a task in the CI pipeline that checks if the README was modified

C.Use a repository template with a mandatory README file structure

D.Require a pull request comment that confirms README update

AnswerB

Adding a CI pipeline task that checks if the README was modified automatically verifies that any code changes are accompanied by a corresponding README update, ensuring the README remains accurate.

Why this answer

Adding a task in the CI pipeline that checks whether the README was modified directly enforces that developers include README updates in the same pull request that contains code changes. This ensures the README stays current with the codebase. In Azure Repos, CI pipelines can easily validate file changes using scripts or tasks.

Option C (repository template) only ensures a README exists for new repositories but does not enforce updates after initial creation, so it does not address the core issue of keeping the README up-to-date over time.

Exam trap

Candidates often choose repository templates because they enforce structure, but they miss that templates only apply at creation time. The real challenge is keeping the README current with ongoing changes, which requires automated enforcement in the CI/CD pipeline.

How to eliminate wrong answers

Option A is wrong because applying a label to PRs that touch certain files and requiring review only flags changes to specific files but does not enforce that the README is updated; developers can still submit PRs without modifying the README, and the label alone does not block the PR. Option B is wrong because adding a task in the CI pipeline that checks if the README was modified only detects whether the README file has changed, but it cannot determine if the README content is actually up-to-date with the code changes; a developer could make a trivial edit to the README to satisfy the check without ensuring accuracy. Option D is wrong because requiring a pull request comment that confirms a README update relies on manual developer discipline and is not enforceable; a developer could simply add the comment without actually updating the README, and there is no automated validation to verify the claim.

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, branches, and pull requests creates end-to-end traceability from requirement to deployed code, enabling validation that completed work aligns with the work item and supporting auditability.

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

PR trigger matches main branch.

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 →

MCQmedium

Your team uses Azure Boards to manage work items. They want to automatically update the status of a work item to 'Resolved' when a pull request that contains the work item ID is merged. Which feature should you configure?

A.Enable the 'Automatically update work item status' setting in the repository's pull request configuration.

B.Instruct developers to manually update the work item after merging.

C.Set up a branch policy that requires linked work items.

D.Create a service hook to call Azure DevOps REST API on pull request merge.

AnswerA

The 'Automatically update work item status' setting in a repository's Pull Request configuration is the native Azure DevOps mechanism that transitions linked work items to their resolved/closed state (e.g., Done) when the pull request is successfully merged. This server-side automation triggers on merge, uses the work item state mapping defined in the project's process configuration, and requires zero custom code or maintenance. For a team wanting automated status updates, this is the built-in, supported approach.

Why this answer

Azure Repos provides a setting in the repository's pull request configuration to automatically update linked work items to a specified state (e.g., 'Resolved') when a pull request is merged. This setting automatically updates work items that are linked via the work item ID in the pull request description. Option B is incorrect because it requires manual effort, which is not automatic.

Option C is incorrect because branch policies for linked work items only enforce linking, not automatic status updates. Option D is incorrect because although service hooks can be used to call REST APIs, Azure DevOps already provides a built-in mechanism for this scenario, making it unnecessary to create custom hooks.

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 →

MCQeasy

Your organization uses Microsoft Defender for Cloud to monitor Azure resources. The compliance team needs to ensure that all Azure DevOps projects have their pipelines scanned for security issues before deployment. Which integration should you use?

A.Configure branch policies in Azure Repos to require a security scan.

B.Enable GitHub Advanced Security for Azure DevOps in Microsoft Defender for Cloud.

C.Configure deployment gates in Azure Pipelines to require a security scan.

D.Use Azure Policy to enforce scanning on Azure DevOps pipelines.

AnswerB

This integration provides code scanning and secret scanning for Azure DevOps pipelines and repos.

Why this answer

Enabling GitHub Advanced Security for Azure DevOps in Microsoft Defender for Cloud allows Defender for Cloud to ingest security alerts from Azure DevOps repositories and pipelines, including secret scanning, code scanning, and dependency scanning. This integration ensures that all Azure DevOps projects are monitored for security issues before deployment, meeting the compliance team's requirement for centralized visibility and enforcement.

Exam trap

The trap here is that candidates often confuse Azure Policy (which enforces compliance on Azure resources) with the ability to enforce pipeline scanning, but Azure Policy cannot directly control Azure DevOps pipeline behavior, whereas the Defender for Cloud integration with GitHub Advanced Security provides the required centralized monitoring and enforcement.

How to eliminate wrong answers

Option A is wrong because branch policies in Azure Repos can require a security scan to be run on pull requests, but they do not integrate with Microsoft Defender for Cloud for centralized compliance monitoring and reporting. Option C is wrong because deployment gates in Azure Pipelines can invoke security checks (e.g., via REST APIs or Azure Functions) but are not a native integration with Microsoft Defender for Cloud; they require custom logic and do not provide the unified security posture management that Defender for Cloud offers. Option D is wrong because Azure Policy can enforce resource compliance for Azure resources (e.g., VMs, storage accounts) but cannot directly enforce scanning on Azure DevOps pipelines; Azure Policy does not have a built-in effect to control pipeline behavior or integrate with Azure Repos.

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 →

100

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 →

101

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 →

102

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 →

103

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 →

104

Multi-Selectmedium

Your release pipeline deploys to multiple environments (dev, test, prod). You need to ensure that only authorized users can approve production deployments. Which TWO actions should you take?

Select 2 answers

A.Use a manual intervention task in the pipeline.

B.Set environment permissions to allow only specific users to create releases.

C.Configure deployment gates to check for user approval.

D.Add a 'Approval' check on the production environment.

E.Add a pre-deployment approval to the production stage.

AnswersD, E

Checks can require approval from specific users or groups.

Why this answer

The correct actions to ensure only authorized users can approve production deployments are to add an 'Approval' check on the production environment (option D) and to add a pre-deployment approval to the production stage (option E). Both methods require explicit user approval before deployment proceeds. Option A is incorrect because a manual intervention task pauses the pipeline for interactive validation but does not enforce user authorization checks; it is typically used for prompts, not approval gates.

Option B is incorrect because environment permissions control who can create releases or manage environments, not who can approve deployments to production—they manage access at a higher level. Option C is incorrect because deployment gates are automated health checks (e.g., monitoring metrics) that can block deployment based on conditions, but they do not handle user approval; approval is a separate check type.

Full explanation →

105

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 →

106

MCQhard

Your organization uses GitHub Advanced Security. A developer accidentally committed a file containing production database connection strings to a feature branch. The push was not yet merged into main. What is the best way to remove the secrets from the branch history while minimizing disruption?

A.Use git filter-repo to remove the file from the branch's history, then force push the branch.

B.Use BFG Repo-Cleaner to delete the file from the branch's history, then force push.

C.Delete the feature branch and have the developer recreate the branch without the secret file.

D.Revert the commit that added the file, then push the revert.

AnswerA

git filter-repo completely removes the file from all commits, and force push updates the remote.

Why this answer

`git filter-repo` is the recommended modern tool for rewriting Git history, including removing a specific file from all commits in a branch. After rewriting the branch's history to exclude the file, a force push (`git push --force`) overwrites the remote branch, effectively purging the secret from the branch's history. This approach minimizes disruption by preserving the branch's other commits and avoiding the need to recreate the branch or lose work.

Exam trap

The trap here is that candidates often confuse reverting a commit (which only adds a new commit and does not remove the secret from history) with rewriting history (which actually purges the secret), leading them to choose the revert option despite its failure to address the security concern.

How to eliminate wrong answers

Option B is wrong because BFG Repo-Cleaner is a Java-based tool that operates on a cloned repository's entire history, but it is less precise for a single branch and requires additional steps to avoid affecting other branches; it also does not natively support branch-specific rewrites as cleanly as `git filter-repo`. Option C is wrong because deleting the feature branch and recreating it loses all commits and work on that branch, causing significant disruption and potential loss of unmerged changes. Option D is wrong because reverting the commit only adds a new commit that undoes the changes, but the secret remains in the commit history and is still accessible via `git log` or direct commit inspection, failing to remove the secret from the branch's history.

Full explanation →

107

MCQmedium

You have an Azure DevOps pipeline that deploys a web app to Azure App Service. You want to capture deployment frequency and change failure rate as metrics in Application Insights. Which built-in analytics view should you use?

A.Deployment Frequency

B.Application Dashboard

C.Time to Restore Service

D.Azure DevOps Pipeline Telemetry

AnswerB

The Application Dashboard is a built-in analytics view in Application Insights that can be customized with metric tiles to display deployment frequency and change failure rate.

Why this answer

The Application Dashboard in Application Insights is a built-in analytics view that provides a customizable overview of your application's metrics. While it does not natively display deployment frequency or change failure rate, you can configure it with metric tiles to show these values if telemetry is properly instrumented. Option A is incorrect because 'Deployment Frequency' is a report in Azure DevOps Analytics, not a built-in view in Application Insights.

Exam trap

Candidates may assume that 'Deployment Frequency' is a built-in Application Insights view because it appears in the Azure DevOps UI. However, it is a report within Azure DevOps Analytics, not a view in Application Insights. The question specifically asks for an Application Insights built-in analytics view.

How to eliminate wrong answers

Option B is wrong because the Application Dashboard is a customizable overview of application health and performance metrics (e.g., requests, failures, dependencies), but it does not include built-in views for deployment frequency or change failure rate. Option C is wrong because Time to Restore Service is a separate metric focused on mean time to recovery (MTTR) after an incident, not on deployment frequency or change failure rate. Option D is wrong because Azure DevOps Pipeline Telemetry is not a built-in analytics view in Application Insights; it refers to telemetry data from pipeline runs, but Application Insights does not have a dedicated view with that name for deployment metrics.

Full explanation →

108

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 →

109

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 →

110

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 →

111

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 →

112

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 →

113

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 →

114

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 →

115

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 →

116

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 →

117

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 →

118

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 →

119

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 →

120

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 →

121

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 →

122

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 →

123

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 →

124

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 →

125

MCQhard

You are deploying a web app to Azure App Service using Azure Pipelines. The security team requires that all secrets are stored in Azure Key Vault and retrieved at deployment time. What is the best approach?

A.Add an Azure Key Vault task in the pipeline to download secrets

B.Store secrets in pipeline variables and mark them as secret

C.Use Variable Groups linked to Key Vault

D.Reference Key Vault secrets directly in App Service configuration

AnswerA

This retrieves secrets directly from Key Vault during the pipeline run.

Why this answer

The Azure Key Vault task in Azure Pipelines directly downloads secrets from Key Vault as pipeline variables at deployment time, ensuring secrets are never stored in the pipeline definition or source control. This meets the security team's requirement for retrieving secrets at deployment time without exposing them in logs or build artifacts.

Exam trap

The trap is that candidates may mistakenly believe that Variable Groups linked to Key Vault (Option C) do not retrieve secrets at deployment time, but they do; however, the Azure Key Vault task is the best approach because it provides explicit control over secret retrieval timing and minimizes exposure as pipeline variables.

How to eliminate wrong answers

Option B is wrong because storing secrets in pipeline variables, even if marked as secret, still stores them within the Azure DevOps project and can be exposed in logs or exported by users with edit permissions, violating the requirement to use Key Vault. Option C is wrong because Variable Groups linked to Key Vault retrieve secrets at pipeline runtime but require the variable group to be explicitly linked and authorized, which adds complexity and does not enforce retrieval at deployment time as directly as the Key Vault task. Option D is wrong because referencing Key Vault secrets directly in App Service configuration (e.g., using @Microsoft.KeyVault references) retrieves secrets at runtime in the App Service, not at deployment time in the pipeline, failing the requirement for retrieval at deployment time.

Full explanation →

126

MCQmedium

Your organization is adopting Microsoft Entra ID for identity management. You need to configure Azure DevOps to trust tokens issued by Entra ID for service connections. Which authentication method should you use?

A.Service principal with client secret

B.Managed identity

C.OAuth 2.0 authorization code grant

D.Personal access token (PAT)

AnswerB

Managed identities provide an automatically managed identity in Entra ID for service connections.

Why this answer

Managed identity (Option B) is correct because it allows Azure DevOps to authenticate to Microsoft Entra ID without storing any credentials, using an identity automatically managed by Azure. This is the recommended approach for service connections when the Azure DevOps agent runs on an Azure resource (e.g., a VM or App Service) that supports managed identities, as it eliminates the need for secret rotation and reduces security risk.

Exam trap

The trap here is that candidates often confuse managed identity with service principal authentication, thinking that a client secret is required for any non-interactive authentication, but managed identity provides a secretless, automatically rotated credential that is specifically designed for Azure-hosted resources.

How to eliminate wrong answers

Option A is wrong because a service principal with a client secret requires manual management and rotation of the secret, which introduces security overhead and potential exposure, whereas the question asks for a method where Azure DevOps trusts tokens issued by Entra ID without storing secrets. Option C is wrong because OAuth 2.0 authorization code grant is an interactive flow designed for user delegation, not for automated service-to-service authentication in a CI/CD pipeline, and it would require user interaction or a refresh token. Option D is wrong because a personal access token (PAT) is a user-bound token that must be manually created and scoped, and it does not leverage Entra ID's token issuance for service connections; it is not a trust-based authentication method with Entra ID.

Full explanation →

127

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 →

128

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 →

129

Multi-Selectmedium

Which TWO of the following are valid strategies to securely store and use secrets in Azure Pipelines?

Select 2 answers

A.Link a variable group to Azure Key Vault and reference variables in the pipeline.

B.Use the 'AzureKeyVault' task to download secrets during the pipeline run.

C.Use the 'secret' variable type in YAML and hardcode the value.

D.Store secrets in a text file in the repository and use a script to read them.

E.Use encrypted environment variables in GitHub Actions.

AnswersA, B

This securely stores secrets in Key Vault.

Why this answer

Azure Pipelines allows you to link a variable group to Azure Key Vault, enabling secure retrieval of secrets as pipeline variables without exposing them in YAML or logs. This integration uses Azure Key Vault's access policies and managed identities to authenticate, ensuring secrets are never stored in the pipeline definition.

Exam trap

The trap here is that candidates often confuse the 'secret' variable type in YAML as a secure storage mechanism, not realizing it still requires the value to be defined in the pipeline file or library, whereas true security comes from external secret stores like Key Vault.

Full explanation →

130

MCQhard

Your team uses Azure DevOps and wants to implement a change management process where all production releases must be approved by a change advisory board (CAB) after the build is complete but before deployment. The approval must be recorded in the pipeline. What is the best approach?

A.Configure a branch policy requiring CAB member approval on pull requests.

B.Add a manual intervention task in the YAML pipeline.

C.Set up a service hook to send an email to the CAB and wait for a reply.

D.Create a release pipeline with a pre-deployment approval gate for the production stage.

AnswerD

Pre-deployment approvals allow designated approvers to approve before deployment, with full audit trail.

Why this answer

A release pipeline with a pre-deployment approval gate for the production stage enforces that a designated approver (or group, such as the CAB) must approve the release before deployment begins. The approval is recorded in the pipeline's audit trail, satisfying the requirement for documented change management. This approach aligns with Azure DevOps release management best practices for gating production deployments.

Exam trap

The trap here is that candidates often confuse manual intervention tasks (Option B) with formal approval gates, not realizing that manual intervention lacks the built-in approval recording and multi-approver workflow required for CAB sign-off in a change management process.

How to eliminate wrong answers

Option A is wrong because branch policies on pull requests control code merging into a branch, not post-build pre-deployment approvals; they do not gate the deployment pipeline after the build is complete. Option B is wrong because a manual intervention task in a YAML pipeline pauses the pipeline for an interactive input, but it does not provide a formal approval gate with recorded sign-off; it is typically used for manual steps like data entry, not for CAB approval workflows. Option C is wrong because a service hook that sends an email and waits for a reply is not a built-in approval mechanism; it requires custom logic to parse replies and does not integrate with Azure DevOps' native approval recording and audit features.

Full explanation →

131

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

Wiki provides persistent, searchable documentation.

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 →

132

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 →

133

MCQmedium

Your Azure DevOps pipeline deploys an ARM template to create a storage account. The deployment fails with 'AuthorizationFailed' error. The service principal used by the service connection has 'Contributor' role on the resource group. What is the most likely issue?

A.The 'Microsoft.Storage' resource provider is not registered for the subscription, and the service principal lacks permission to register it at subscription scope.

B.The storage account name is already taken.

C.The ARM template is using an unsupported API version.

D.The service principal does not have 'Contributor' role at the subscription scope.

AnswerA

Correct. If the Microsoft.Storage resource provider is not registered for the subscription, the deployment fails with an authorization error because the service principal cannot register it (requires subscription-level permissions).

Why this answer

The AuthorizationFailed error is likely due to the Microsoft.Storage resource provider not being registered for the subscription. The service principal has Contributor on the resource group, but registering a resource provider requires Microsoft.Register/action at the subscription scope, which the principal does not have. The service principal itself is not registered for the resource provider; resource providers are registered at the subscription level.

Exam trap

Candidates often confuse resource provider registration with RBAC permissions. Even with Contributor on the resource group, if the resource provider is not registered, the deployment can fail because the principal cannot register it at the subscription level.

How to eliminate wrong answers

Option A is wrong because the 'AuthorizationFailed' error is a permissions issue, not a resource provider registration issue; an unregistered resource provider would cause a 'RegistrationFailed' or 'MissingSubscriptionRegistration' error. Option B is wrong because a duplicate storage account name would result in a 'Conflict' or 'StorageAccountAlreadyTaken' error, not 'AuthorizationFailed'. Option C is wrong because an unsupported API version would produce a 'BadRequest' or 'InvalidTemplate' error, not an authorization failure.

Full explanation →

134

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 →

135

Multi-Selecthard

Which TWO Azure DevOps features can be used to automate the process of updating work items when a build or release completes?

Select 2 answers

A.Pipeline task 'Update work item' from the Azure DevOps extension.

B.Service hooks to trigger an Azure function.

C.Release gates with work item update actions.

D.Work item query charts.

E.Branch policy with required reviewers.

AnswersA, B

The 'Update work item' pipeline task is a built-in task that directly modifies work items (e.g., change state, assignee) upon pipeline completion, making it a native automation feature.

Why this answer

The 'Update work item' pipeline task, available via the Azure DevOps Extension, directly modifies work items as part of a build or release pipeline, providing native automation. Option B is correct because service hooks can trigger external processes (e.g., an Azure function) that update work items via the REST API, offering flexibility for custom logic. Option C is incorrect because release gates are designed to evaluate conditions (e.g., quality checks) and do not include built-in actions to directly update work items.

Options D and E are unrelated; query charts are for visualization, and branch policies with required reviewers enforce code review, not work item updates.

Exam trap

The trap here is that candidates may confuse release gates (Option C) as a direct automation feature for work item updates. However, release gates only evaluate conditions and lack native work item update actions. The correct features are the 'Update work item' pipeline task (native) and service hooks (customizable via external triggers).

Full explanation →

136

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 →

137

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 →

138

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 →

139

MCQhard

You are reviewing an Azure Policy definition applied to an Azure DevOps project. The project has a build pipeline that deploys to production. What is the effect of this policy on the build pipeline?

A.The policy blocks the pipeline from running if fewer than two reviewers approve.

B.The policy requires two reviewers and blocks the pipeline if not met.

C.The policy audits the pipeline but does not enforce any mandatory reviewers.

D.The policy does not apply to build pipelines because the field type is teamProjects.

AnswerC

The audit effect logs compliance without blocking.

Why this answer

Azure Policy definitions applied to Azure DevOps projects use the 'audit' effect by default for policy types that do not support 'deny' or 'enforce' on build pipelines. Since the policy in question does not specify a mandatory reviewer requirement with enforcement, it only audits the pipeline's compliance without blocking execution. Therefore, the pipeline runs regardless, and the policy logs a compliance state.

Exam trap

The trap here is that candidates assume Azure Policy can enforce pipeline-level controls like mandatory reviewers, but in Azure DevOps, Azure Policy only audits or denies resource-level configurations, not pipeline execution logic.

How to eliminate wrong answers

Option A is wrong because Azure Policy cannot block a build pipeline from running based on reviewer count; it only audits or denies resource creation, not pipeline execution. Option B is wrong because the policy does not enforce mandatory reviewers; it only audits, and Azure Policy does not have a 'require' effect for pipeline reviewers. Option D is wrong because Azure Policy applies to Azure DevOps projects via the 'Microsoft.DevOps/pipelines' resource type, and the field type 'teamProjects' is not a valid exclusion for build pipelines.

Full explanation →

140

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

Secret variables are masked in logs and output.

Why this answer

To protect secrets like API keys and passwords in Azure Pipelines, you should implement three key measures. First, mark variables as 'Secret' in pipeline YAML or UI definitions (Option B). This prevents the secret from being displayed in logs or output.

Second, use service connections with managed identity instead of personal access tokens (Option D). Managed identities eliminate the need to store credentials and reduce secret exposure. Third, store secrets in Azure Key Vault and reference them via a Key Vault task (Option E).

This centralizes secret management and allows fine-grained access control. Option A is incorrect because storing secrets as plain text in a Git repo, even with restricted access, is insecure—secrets should never be committed to source control. Option C is incorrect because environment variables are not encrypted by default and can be exposed in logs or to other pipeline tasks, making them unsafe for secret passing.

Full explanation →

141

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 →

142

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

It uses path filters in the pipeline trigger to only run when files in the changed projects are modified, and a custom script detects dependencies between projects to also build any dependent projects. This minimizes build time while ensuring all affected projects are built. Option A builds all projects on every commit, which is inefficient.

Option C only builds changed projects but ignores dependency chains, potentially breaking the build. Option D requires manual triggers, which is not automated and defeats the purpose of CI/CD.

Full explanation →

143

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 →

144

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 →

145

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 →

146

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 →

147

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

The recommended approach is to create a central repository with reusable workflows and reference them using the 'uses' keyword. This is a native GitHub Actions feature that allows you to define shared workflow files in one repository and call them from any other repository in your organization. This ensures all workflows stay up to date centrally.

The other options are not recommended: B uses API scheduling which is unnecessary and harder to manage; C downloads workflows from blob storage as inline scripts which loses the benefits of shared workflow versioning; D uses Git submodules which are designed for code dependencies and do not integrate well with GitHub Actions workflow execution.

Full explanation →

148

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 →

149

MCQmedium

You have a multi-stage YAML pipeline that deploys to Azure Kubernetes Service (AKS). The pipeline uses a deployment job with a strategy of 'runOnce'. You need to ensure that if the deployment fails, the pipeline automatically redeploys the previous successful version. Which strategy should you use instead?

A.Use the 'canary' strategy with manual intervention

B.Use the 'rolling' strategy and configure 'on:failure: always'

C.Use the 'blueGreen' strategy and configure automatic swap

D.Use the 'runOnce' strategy with a rollback task

AnswerD

Correct. Adding a rollback task to the existing 'runOnce' strategy allows automatic redeployment of the previous successful version on failure, meeting the requirement without changing the strategy.

Why this answer

The requirement can be met by adding a rollback task to the existing 'runOnce' strategy. When a deployment fails, the rollback task can automatically redeploy the previous successful version. Option A requires manual intervention, which contradicts the 'automatically' requirement.

Option B uses invalid syntax ('on:failure: always')—the correct hook is 'on: failure: rollback'—and option C's automatic swap does not revert the deployment on failure.

Exam trap

Candidates often think they must change the deployment strategy to achieve rollback, but the requirement can be satisfied by adding a rollback task to the existing 'runOnce' strategy. They may also confuse 'on:failure' actions and incorrectly use 'always' instead of 'rollback'.

Why the other options are wrong

Canary strategy does not automatically roll back; it requires manual approval or additional steps.

BlueGreen strategy requires manual swap; it does not roll back automatically.

Full explanation →

150

Multi-Selectmedium

Which two actions can you use to validate that a deployment to a staging environment is successful before promoting to production? (Choose two.)

Select 2 answers

A.Configure gates on the staging environment to check health metrics.

B.Add a manual intervention task in the pipeline.

C.Set a post-deployment approval on the staging stage.

D.Use a pull request to validate the deployment.

E.Run a load test as part of the pipeline.

AnswersA, C

Gates on the staging environment evaluate pre-defined health metrics (e.g., error rate, latency, availability) after deployment completes but before promotion to production. These gates continuously query the chosen Azure Monitor or other data sources during a configurable timeout; if the metrics don't meet the threshold, the pipeline is blocked and ultimately fails, providing objective, automated validation of actual workload health.

Why this answer

Gates with health checks can monitor metrics like error rates before allowing promotion. Manual intervention with a post-deployment approval also allows a human to validate before proceeding. Both are valid methods.

Exam trap

Candidates may select 'Use a pull request' which is for code review, not deployment validation.

Why the other options are wrong

Manual intervention tasks are deprecated; use approvals instead.

Pull requests validate code changes, not deployments.

Load testing is a good practice but not a direct validation mechanism for promotion approval.

Full explanation →

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