Microsoft Azure DevOps Engineer Expert AZ-400 AZ-400 Questions 226–300 | Page 4/11

226

MCQeasy

Your pipeline uses a multi-stage YAML file. You want to conditionally run a stage only if the build originates from the 'main' branch. Which syntax should you use?

A.condition: variables['Build.SourceBranch'] == 'main'

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

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

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

AnswerC

This is the correct condition because Azure Pipelines stores the triggering branch in the `Build.SourceBranch` variable as a full ref string, such as `refs/heads/main` or `refs/pull/123/merge` for PR builds. The `eq()` function performs an exact string comparison, so it will correctly match when pipeline runs are triggered by a push to the `main` branch. This is the minimal, readable expression that achieves the intended gating without any redundant conditions.

Why this answer

The `condition` directive in a YAML pipeline stage evaluates expressions using Azure Pipelines syntax. The `eq()` function compares two values, and `Build.SourceBranch` for the 'main' branch returns `refs/heads/main`, not just `main`. This exact match ensures the stage runs only when the build originates from the 'main' branch.

Exam trap

The trap here is that candidates often forget that `Build.SourceBranch` includes the full ref path (`refs/heads/main`) and incorrectly use just the branch name (`main`), or they misuse the `==` operator instead of the `eq()` function required by Azure Pipelines expression syntax.

How to eliminate wrong answers

Option A is wrong because it uses a simple equality operator (`==`) which is not valid in Azure Pipelines YAML expressions; the correct syntax requires the `eq()` function. Option B is wrong because it adds `and(succeeded(), ...)` which is unnecessary for a stage-level condition (stages do not have a preceding task to succeed or fail) and introduces an extra check that could cause the stage to be skipped incorrectly. Option D is wrong because it compares `Build.SourceBranch` to `'main'` instead of the full ref `'refs/heads/main'`, which will never match and thus the stage will never run.

Full explanation →

227

MCQhard

Your Azure DevOps pipeline uses a YAML template that includes a step to push a Docker image to Azure Container Registry. The pipeline fails with 'unauthorized: authentication required'. The service connection uses a workload identity federation. What is the most likely cause?

A.The Docker image tag contains invalid characters

B.The Azure Container Registry name is incorrect

C.The service principal used by the workload identity does not have the 'acrPush' role

D.The service connection secret has expired

AnswerC

The federated identity credential for the workload identity federation is functioning correctly in the authentication phase, but the associated service principal lacks the 'AcrPush' role assignment on the Azure Container Registry, which is required for pushing Docker images. Without this role, the registry rejects the push with an authorization error (e.g., 'unauthorized: authentication required' or 'insufficient permissions'), even though the service principal authenticated successfully.

Why this answer

The error 'unauthorized: authentication required' indicates that the Docker client could not authenticate with Azure Container Registry. With workload identity federation, the service principal used by the federated credential must have the 'acrPush' role assigned on the ACR scope to push images. Without this role assignment, the authentication token lacks the necessary permissions, even if the identity itself is valid.

Exam trap

The trap here is that candidates confuse authentication (identity validation) with authorization (permission to act), assuming any valid identity can push to ACR, but ACR requires explicit role assignment even for federated identities.

How to eliminate wrong answers

Option A is wrong because invalid characters in the Docker image tag cause a different error (e.g., 'invalid reference format') and do not trigger authentication failures. Option B is wrong because an incorrect ACR name would result in a 'name unknown' or 'repository not found' error, not an authentication error. Option D is wrong because workload identity federation does not use a client secret; it relies on a federated credential token exchange, so secret expiry is irrelevant.

Full explanation →

228

MCQhard

A team uses Git-LFS to store large binary files. They observe that cloning the repository takes a long time because Git-LFS files are downloaded. How can they improve clone performance?

A.Use a shallow clone with depth 1

B.Use the --filter=blob:none option when cloning

C.Use sparse checkout to limit files in working directory

D.Configure git lfs prune to run automatically

AnswerB

This partial clone defers downloading LFS blobs until they are accessed.

Why this answer

The `--filter=blob:none` option performs a partial clone, which omits all blob objects (including Git-LFS pointer files and other large blobs) from the initial download. This significantly reduces clone time by only fetching commit and tree metadata, and then lazily downloading blobs on demand when they are actually accessed. For Git-LFS specifically, this avoids downloading the large binary files stored in LFS until they are needed, improving clone performance.

Exam trap

The trap here is that candidates confuse shallow clones (which limit history) or sparse checkouts (which limit working tree files) with partial clones (which limit object downloads), not realizing that Git-LFS files are downloaded during checkout regardless of history depth or sparse patterns unless blob filtering is used.

How to eliminate wrong answers

Option A is wrong because a shallow clone with depth 1 reduces the commit history but does not prevent Git-LFS files from being downloaded; Git-LFS still downloads all LFS objects during checkout. Option C is wrong because sparse checkout limits the working directory to a subset of files but does not affect the download of Git-LFS objects; all LFS files in the checked-out commit are still fetched. Option D is wrong because `git lfs prune` removes local copies of LFS files that are no longer referenced, but it runs after cloning and does not improve initial clone performance.

Full explanation →

229

MCQhard

You are a DevOps engineer at a large enterprise that develops a cloud-native application using microservices architecture. The application consists of 15 microservices, each stored in a separate GitHub repository. Your team uses GitHub Actions for CI/CD and Azure Kubernetes Service (AKS) for production. The current deployment process is manual and error-prone. You need to design an automated CI/CD pipeline that supports the following requirements: 1. Each microservice must have its own build and test pipeline triggered on pull requests and merges to the main branch. 2. Upon merging to main, a container image must be built, tagged with the Git commit SHA, and pushed to Azure Container Registry (ACR). 3. A separate release pipeline must deploy the updated images to AKS using a GitOps approach with Flux v2. 4. The release pipeline must support rolling back to a previous version quickly if a deployment fails. 5. The entire solution must be defined as code to ensure reproducibility. Which approach should you recommend?

A.Create a single monorepo with all microservices. Use GitHub Actions with a multi-branch pipeline that builds only changed services. Deploy to AKS using kubectl commands in the pipeline. For rollback, redeploy the previous image tag.

B.Use Azure Pipelines with a single build pipeline that triggers on any change in any repo using webhooks. Use Azure DevOps Release Pipelines to deploy to AKS using Helm. Store Helm charts in Azure Container Registry. For rollback, use Helm rollback command.

C.Use GitHub Actions for CI and deploy directly to AKS using kubectl in the same workflow. Store Kubernetes manifests in each microservice repo. Use Argo CD to monitor the repos and sync.

D.Use GitHub Actions in each microservice repo for CI to build and push images to ACR. Use a separate GitOps repository that contains Kubernetes manifests. Configure Flux v2 in AKS to sync from the GitOps repo. When a new image is pushed to ACR, update the manifest in the GitOps repo via a GitHub Action, triggering Flux to deploy. For rollback, revert the commit in the GitOps repo.

AnswerD

This pattern correctly separates CI from CD: each microservice repository has its own GitHub Actions workflow to build and push only its image to ACR, preserving independent versioning and team autonomy. Kubernetes manifests live in a dedicated GitOps repository, and Flux v2 running in AKS continuously reconciles the cluster to that repository, so updating an image tag in a commit automatically triggers the deployment. Rollback is simply a git revert of that commit, giving an immutable, auditable, declarative rollout/rollback workflow with Git as the single source of truth—fully satisfying the requirements for GitHub Actions, AKS, and GitOps-based rollback.

Why this answer

It aligns with all requirements: each microservice has its own GitHub Actions CI pipeline (requirement 1), images are built and pushed to ACR with commit SHA tags (requirement 2), a separate GitOps repo with Flux v2 handles deployment to AKS (requirement 3), rollback is achieved by reverting the Git commit (requirement 4), and everything is defined as code in repositories (requirement 5). Option A is wrong because it uses a monorepo, violating the separate repository requirement, and uses kubectl in the pipeline instead of GitOps. Option B is wrong because it uses Azure Pipelines, which is not consistent with GitHub Actions, and uses Helm rollback instead of Git-based rollback.

Option C is wrong because it deploys directly via kubectl in the same workflow, mixing CI and CD, and uses Argo CD instead of Flux v2 as specified.

Full explanation →

230

MCQhard

You are designing a release pipeline for a mission-critical application that must achieve zero-downtime deployments to Azure App Service (Web App for Containers). The application uses Azure SQL Database with schema migrations. The current deployment slot strategy uses staging and production slots. You need to ensure that during a swap, the staging slot is warmed up and the database schema is rolled back if the swap fails. Which combination of deployment slots and pre/post-swap actions should you implement?

A.Use three slots: production, staging, and a new slot for the new version. Apply schema changes in the new slot, then swap new to staging, warm up staging, then swap staging to production. On failure, swap staging back to production.

B.Use two slots (staging and production) with auto-swap enabled. The auto-swap handles warm-up automatically. If the swap fails, Azure automatically rolls back.

C.Use three slots: production, staging, and a new slot for the new version. Apply schema changes in the new slot, then swap new slot to staging, then staging to production. On failure, swap staging back to production.

D.Use two slots (staging and production). Apply schema changes in staging before swap. If swap fails, manually redeploy the old version to production.

AnswerA

This allows you to test schema changes in the new slot, warm up in staging, and swap staging to production. If the final swap fails, you swap staging back to production, which still has the old code and old schema.

Why this answer

It uses three slots to isolate schema changes in a new slot, then swaps to staging for warm-up, and finally swaps to production. If the swap fails, rolling back staging to production reverses the schema changes, ensuring zero-downtime. This approach aligns with Azure App Service slot-swap best practices for mission-critical applications requiring database rollback capability.

Exam trap

The trap here is that candidates assume auto-swap handles database rollback automatically, but Azure App Service does not manage database schema changes—only application code and configuration are swapped, so a manual rollback strategy is required.

How to eliminate wrong answers

Option B is wrong because auto-swap does not support schema rollback; if the swap fails, Azure does not automatically revert database changes, leading to potential data inconsistency. Option C is wrong because it omits explicit warm-up of the staging slot before the final swap, risking cold-start latency during the production swap. Option D is wrong because manual redeployment of the old version to production after a failed swap causes downtime and does not guarantee atomic rollback of schema changes.

Full explanation →

231

MCQmedium

A team is implementing a release pipeline for a Node.js application. They want to run integration tests against a temporary environment that is destroyed after the tests complete. Which strategy should they use?

A.Use a separate release pipeline that deploys to a production environment for testing.

B.Use a single release pipeline that deploys to a staging slot and runs tests on the slot.

C.Run integration tests in the build pipeline using a mock environment.

D.Use a release pipeline that deploys to a new Azure App Service instance, runs tests, and then removes the instance.

AnswerD

Using a release pipeline that deploys to a new Azure App Service instance, runs tests, and then removes the instance is correct because it provides an ephemeral, isolated environment that closely mirrors production, enabling realistic integration validation and automatic teardown, which avoids lingering state and reduces cost.

Why this answer

It provisions a dedicated, isolated Azure App Service instance for integration testing, runs the tests against the real environment, and then destroys the instance to avoid ongoing costs. This aligns with the ephemeral environment pattern, ensuring tests validate actual deployment behavior without contaminating shared resources.

Exam trap

The trap here is that candidates often confuse staging slots with ephemeral environments, but staging slots are persistent and not automatically destroyed after testing, whereas a new App Service instance can be fully removed to ensure cost and isolation compliance.

How to eliminate wrong answers

Option A is wrong because deploying to a production environment for testing risks corrupting live data and causing downtime, violating the principle of environment isolation. Option B is wrong because a staging slot is a permanent, shared resource that may not be destroyed after tests, and running tests on the slot does not guarantee a clean, disposable environment. Option C is wrong because running integration tests in the build pipeline with a mock environment bypasses real infrastructure validation, missing critical issues like deployment configuration, network dependencies, and service bindings.

Full explanation →

232

MCQeasy

Your company is migrating from on-premises Jenkins to Azure Pipelines. You have a Jenkins pipeline that builds a C++ application using MSBuild. The build environment requires specific Visual Studio components and SDKs. You need to set up a build agent in Azure Pipelines that matches the Jenkins environment. You want to minimize administrative overhead and ensure the agent is always up to date with the latest patches. What should you do?

A.Use a self-hosted agent on an Azure VM with a custom image that includes Visual Studio and SDKs.

B.Deploy a container-based agent using a Docker image that includes Visual Studio.

C.Use a Microsoft-hosted agent with the 'windows-2022' image that includes Visual Studio Build Tools.

D.Provision a self-hosted agent on an Azure VM and install required components manually.

AnswerC

The Microsoft-hosted 'windows-2022' agent is pre-provisioned with Visual Studio Build Tools and common SDKs, auto-patched and recycled per job, eliminating infrastructure maintenance while supporting most build scenarios—making it the simplest, most reliable choice for this migration.

Why this answer

Microsoft-hosted agents include Visual Studio Build Tools and are automatically updated, minimizing administrative overhead. Option A is incorrect because using a custom image on a self-hosted agent still requires maintaining the image and applying updates. Option B is incorrect because container-based agents require building and managing a custom Docker image that includes Visual Studio and SDKs, which adds overhead.

Option D is incorrect because a self-hosted agent on an Azure VM requires manual installation of required components and ongoing patching, increasing administrative effort.

Full explanation →

233

Multi-Selectmedium

Your organization uses Azure Pipelines with multiple release stages. You need to instrument the pipeline to capture the duration of each stage and the number of failed tasks. Which TWO approaches should you use?

Select 2 answers

A.Configure pipeline notifications for failed tasks.

B.Implement a 'runOnce' deployment strategy to ensure sequential stages.

C.Enable the 'Summary' tab in the pipeline run to view stage durations.

D.Use the Azure DevOps REST API to retrieve pipeline run statistics after each run.

E.Add a script task at the end of each stage to log stage duration and task results to a custom log file.

AnswersD, E

The Azure DevOps REST API (e.g., Builds - Get or Timelined endpoints) returns detailed run metadata including stage/task durations, results, and timestamps for every run. Calling this API after each pipeline run lets you programmatically collect and persist the exact statistics needed for performance analysis.

Why this answer

Options D and E are correct. The goal is to capture stage duration and failed task counts. Option D uses the Azure DevOps REST API to programmatically retrieve pipeline run statistics, which includes stage-level durations and failure information.

Option E adds a script task at the end of each stage that logs the stage's duration and task results to a custom log file, providing direct instrumentation. Option A is incorrect because pipeline notifications only alert on failures, they don't capture or log durations. Option B is incorrect because 'runOnce' is a deployment strategy that ensures sequential stages, not an instrumentation method.

Option C is incorrect because the 'Summary' tab in the pipeline run provides a high-level overview, not detailed per-stage duration data that can be programmatically captured.

Full explanation →

234

Multi-Selectmedium

Which THREE are valid deployment patterns for Kubernetes? (Choose three.)

Select 3 answers

A.Canary deployment

B.Rolling update

C.A/B testing deployment

D.Helm deployment

E.Blue-green deployment

AnswersA, B, E

Canary deployment is a valid Kubernetes deployment pattern that incrementally routes a small percentage of live traffic to a new version while monitoring key metrics, gradually increasing the canary's share only when the new version proves stable, thereby reducing blast radius and enabling early rollback.

Why this answer

The correct deployment patterns in Kubernetes are canary, rolling update, and blue-green. A canary deployment releases a new version to a small subset of users first, allowing monitoring and gradual traffic shifting. A rolling update incrementally replaces old pods with new ones, ensuring zero downtime.

A blue-green deployment runs two identical environments and switches traffic from the old (blue) to the new (green) environment after validation. Helm is a package manager, not a deployment pattern, and A/B testing is a traffic management technique rather than a core Kubernetes deployment strategy.

Exam trap

The trap here is that candidates confuse deployment patterns (like canary, rolling, blue-green) with deployment tools (like Helm) or traffic management techniques (like A/B testing), leading them to select options that are not actual Kubernetes rollout strategies.

Full explanation →

235

MCQmedium

Your team uses Azure Repos and needs to prevent secrets from being committed to the repository. Which built-in feature should you enable?

A.Enable GitHub secret scanning

B.Enable Azure Policy to scan repositories

C.Configure a pre-commit hook with a secret scanning tool

D.Enable push protection in Azure Repos

AnswerD

Push protection in Azure Repos is a built-in server-side feature that scans incoming commits for known secrets (such as connection strings, passwords, and API keys) and blocks the push if a secret is detected. This provides centralized, enforced protection that prevents secrets from ever entering the repository, directly addressing the need.

Why this answer

Push protection in Azure Repos is a built-in feature that scans commits for high-confidence secrets (e.g., Azure service connection strings, SSH keys, and other credential patterns) and blocks the push if a secret is detected. This prevents secrets from ever reaching the remote repository, enforcing security at the server side without requiring client-side configuration.

Exam trap

The trap here is that candidates confuse client-side pre-commit hooks (Option C) with a built-in server-side solution, overlooking that hooks can be bypassed and are not enforced, while push protection in Azure Repos is a native, unbypassable guard.

How to eliminate wrong answers

Option A is wrong because GitHub secret scanning is a feature of GitHub, not Azure Repos, and the question specifies the team uses Azure Repos. Option B is wrong because Azure Policy is used for governance and compliance of Azure resources (e.g., VM SKUs, resource locations), not for scanning repository contents for secrets. Option C is wrong because configuring a pre-commit hook is a client-side solution that can be bypassed by developers (e.g., by using --no-verify) and requires manual setup per machine, whereas Azure Repos push protection is a server-side, enforced feature.

Full explanation →

236

Multi-Selecthard

Which THREE are required to set up a self-hosted agent for Azure Pipelines?

Select 3 answers

A.A virtual machine running in Azure.

B.Network connectivity to Azure DevOps services.

C.A Personal Access Token (PAT) to authenticate the agent.

D.An agent pool configured in Azure DevOps and the agent configured to use that pool.

E.Docker installed on the agent machine.

AnswersB, C, D

The agent must be able to establish an HTTPS connection to Azure DevOps services over the network to poll for job assignments, download tasks, and report status. Without network connectivity, the agent cannot participate in pipelines, making this a fundamental requirement for any self-hosted agent.

Why this answer

B is correct because the self-hosted agent must communicate with Azure Pipelines to receive job assignments and report status. This requires outbound HTTPS connectivity (port 443) to Azure DevOps services (e.g., dev.azure.com). Without network connectivity, the agent cannot register, poll for jobs, or send logs, making it non-functional.

Exam trap

The trap here is that candidates assume a self-hosted agent must run on an Azure VM (Option A) or require Docker (Option E), when in fact the only infrastructure requirements are network connectivity and authentication, with the agent pool configuration tying it all together.

Full explanation →

237

MCQmedium

Your organization uses GitHub Actions for CI/CD. You have a workflow that builds and deploys a containerized application to Azure Kubernetes Service (AKS). The workflow uses the 'azure/aks-set-context' action to connect to the AKS cluster. Recently, the workflow started failing with authentication errors. The service principal used has Contributor role on the AKS cluster. What is the most likely cause?

A.The service principal must have 'Owner' role on the resource group containing the AKS cluster.

B.The service principal lacks the 'Azure Kubernetes Service Cluster Admin Role' on the AKS cluster.

C.The workflow uses an incorrect Kubernetes version.

D.The AKS cluster has RBAC disabled, causing authentication failures.

AnswerB

The Azure CLI action 'aks get-credentials --admin' requires the service principal to have the 'Azure Kubernetes Service Cluster Admin Role' on the AKS cluster. This role grants the Microsoft.ContainerService/managedClusters/listClusterAdminCredential/action permission, which is mandatory for retrieving the cluster-admin kubeconfig; without it, the workflow fails during the credential download step with an authorization error.

Why this answer

The 'azure/aks-set-context' action requires the service principal to have the 'Azure Kubernetes Service Cluster Admin Role' (or 'Azure Kubernetes Service Cluster User Role') on the AKS cluster to authenticate and set the kubectl context. The Contributor role on the AKS cluster resource does not grant the necessary Kubernetes RBAC permissions to interact with the cluster's API server. Without the specific AKS role, the action fails with authentication errors.

Exam trap

The trap here is that candidates assume the Contributor role on the AKS resource is sufficient for all operations, but Azure separates Azure RBAC (for managing the AKS resource) from Kubernetes RBAC (for interacting with the cluster), and the 'azure/aks-set-context' action specifically requires the AKS Cluster Admin or User Role.

How to eliminate wrong answers

Option A is wrong because the 'Owner' role on the resource group is not required; the service principal only needs the 'Azure Kubernetes Service Cluster Admin Role' on the AKS cluster itself, not Owner on the resource group. Option C is wrong because an incorrect Kubernetes version would cause deployment or compatibility issues, not authentication errors when setting the cluster context. Option D is wrong because disabling RBAC on the AKS cluster would actually reduce authentication requirements, not cause authentication failures; the error is due to missing role assignment, not RBAC being disabled.

Full explanation →

238

Multi-Selectmedium

Which TWO actions should you take to implement a CI/CD pipeline for a microservices application using Azure Pipelines? (Choose two.)

Select 2 answers

A.Use a classic release pipeline instead of YAML for the deployment stages.

B.Publish build artifacts and use them in the release stages.

C.Store deployment credentials directly in the YAML file.

D.Use a multi-stage YAML pipeline that includes build, test, and deploy stages.

E.Create a separate pipeline for each microservice.

AnswersB, D

Publishing build artifacts is essential because it decouples the build phase from the release phase, producing an immutable, versioned binary that can be downloaded by any downstream stage or release pipeline. The Publish Pipeline Artifact task stores files in Azure Pipelines and associates them with the run, so the exact bits that passed tests are the ones deployed, eliminating drift between environments and supporting reliable rollback because each deployment can reference a known artifact version. Without this, release stages would have to rebuild or restore packages, breaking reproducibility and atomic deployment.

Why this answer

Options B and D are correct. B: Publishing build artifacts and using them in release stages ensures consistency between build and deploy. D: Using a multi-stage YAML pipeline allows you to define build, test, and deploy stages in a single file.

Option A is wrong because classic release pipelines are not recommended; YAML is preferred for CI/CD. Option C is wrong because credentials should not be stored in YAML; use variable groups or Azure Key Vault. Option E is wrong because a single multi-stage pipeline can handle multiple microservices using matrix strategies; separate pipelines increase complexity.

Full explanation →

239

Multi-Selecthard

You are designing a security compliance plan for a GitHub Enterprise environment. Which THREE practices should you implement? (Select THREE.)

Select 3 answers

A.Disable two-factor authentication for automation accounts

B.Allow repository admins to bypass branch protection rules

C.Configure branch protection rules to require pull request reviews

D.Enable Dependabot alerts for dependency vulnerability monitoring

E.Enable secret scanning to detect accidental credential commits

AnswersC, D, E

Requiring pull request reviews ensures that every change is reviewed by at least one other collaborator before merging, enforcing code quality and reducing the risk of introducing vulnerabilities or broken code. It also provides a clear audit trail of who approved each change, which is essential for compliance.

Why this answer

Branch protection rules with required pull request reviews enforce mandatory code review before merging, Dependabot alerts automatically monitor dependency vulnerabilities, and secret scanning detects accidental credential commits. Together these practices strengthen security compliance in GitHub Enterprise.

Exam trap

The trap here is that candidates may confuse automation account security with human user security, incorrectly assuming that 2FA can be disabled for automation accounts, or they may think bypassing branch protection is acceptable for admins, when in fact compliance requires consistent enforcement across all users.

Full explanation →

240

MCQeasy

Your team uses GitHub Actions to build a Docker image and push it to Azure Container Registry (ACR). The workflow fails with the error 'unauthorized: authentication required'. The workflow uses the 'azure/docker-login@v1' action. What is the most likely cause?

A.The 'azure/docker-login@v1' action does not support ACR.

B.The Dockerfile is not in the repository root.

C.The service principal used for authentication lacks the AcrPush role on the ACR.

D.The workflow uses the registry admin credentials, which are disabled.

AnswerC

To push an image to Azure Container Registry, the authenticated identity (here, the service principal) must have the AcrPush role granted on the registry. If that role is missing, docker login succeeds but docker push fails with a permissions error, making this the likeliest root cause of the push failure.

Why this answer

The 'azure/docker-login@v1' action authenticates Docker with Azure Container Registry using a service principal. If the service principal lacks the AcrPush role, Docker login succeeds but the subsequent push fails with 'unauthorized: authentication required' because the identity does not have permission to push images. The error occurs at push time, not login time, which is a key diagnostic clue.

Exam trap

The trap here is that candidates assume the error means the login itself failed, but the 'azure/docker-login@v1' action can succeed with a valid service principal that lacks push permissions, and the 'unauthorized' error surfaces only during the subsequent docker push, leading test-takers to incorrectly suspect admin credentials or Dockerfile location.

How to eliminate wrong answers

Option A is wrong because 'azure/docker-login@v1' explicitly supports ACR by accepting a username and password (from a service principal) and logging in to the ACR login server. Option B is wrong because the location of the Dockerfile does not affect authentication; it only affects the build context and is unrelated to the 'unauthorized' error. Option D is wrong because if the workflow used registry admin credentials (which are disabled), the error would be 'authentication required' at login, not at push, and the question does not indicate admin credentials are being used; the action defaults to service principal authentication.

Full explanation →

241

Multi-Selectmedium

Your organization uses Azure DevOps and Azure Policy to enforce compliance. You need to ensure that all Azure resources deployed by Azure DevOps pipelines have specific tags (e.g., CostCenter and Environment) applied. Which TWO approaches can achieve this? (Choose TWO.)

Select 2 answers

A.Configure the service connection to only allow deployments with tags.

B.Create an Azure Policy with the 'audit' effect to report non-compliant resources.

C.Create an Azure Policy with the 'deny' effect that requires the tags to be present at resource creation.

D.Add a pipeline task after resource creation that applies the required tags using Azure CLI or PowerShell.

E.Configure a branch policy on the main branch to require tag verification in pull requests.

AnswersC, D

Deny policy blocks deployment of non-compliant resources.

Why this answer

An Azure Policy with the 'deny' effect prevents the creation of any resource that does not include the required tags (e.g., CostCenter and Environment). This enforces compliance at the moment of deployment, blocking non-compliant resources from being provisioned by Azure DevOps pipelines. Option D is correct because adding a pipeline task (using Azure CLI or PowerShell) after resource creation programmatically applies the required tags, ensuring resources are tagged even if the initial deployment omitted them.

Exam trap

The trap here is that candidates often confuse Azure Policy effects (audit vs. deny) and overlook that a post-deployment task can also enforce tagging, leading them to select only the deny policy or incorrectly choose audit as a compliance enforcement mechanism.

Full explanation →

242

MCQmedium

A company recently migrated its CI/CD pipelines from Jenkins to Azure Pipelines. The development team is experiencing frequent build failures due to conflicting changes when multiple developers push code simultaneously. The team wants to maintain a linear history and avoid merge commits. Which strategy should you recommend?

A.Switch to Git with a central repository and require merge commits.

B.Enforce a rebase strategy for all pull requests in the branch policy.

C.Use Team Foundation Version Control (TFVC) with exclusive checkout enabled.

D.Configure Azure Repos to use squash merge when completing pull requests.

AnswerC

TFVC with exclusive checkout is correct because it enables server-side, per-file locking: as soon as one developer checks out a file, any other user's attempt to check out that same file is blocked until the first check-in, thereby ensuring no concurrent edits can create conflicts and enforcing a strictly linear history over the shared files.

Why this answer

Team Foundation Version Control (TFVC) with exclusive checkout enforces a lock on a file when a developer checks it out, preventing simultaneous edits. This eliminates conflicting changes that cause build failures when multiple developers push code concurrently, and since TFVC does not use merge commits, it maintains a linear history. The scenario explicitly requires avoiding merge commits and resolving conflicts from simultaneous pushes, which TFVC’s exclusive checkout directly addresses.

Exam trap

The trap here is that candidates often assume Git-based strategies (like rebase or squash merge) can prevent simultaneous push conflicts, but they only manage how history looks after a merge, not the underlying conflict that occurs when two developers push changes to the same file at the same time.

How to eliminate wrong answers

Option A is wrong because switching to Git with a central repository and requiring merge commits would introduce merge commits, violating the requirement to maintain a linear history and avoid merge commits. Option B is wrong because enforcing a rebase strategy for pull requests in Git still allows conflicting changes when multiple developers push simultaneously; rebase rewrites commit history but does not prevent conflicts at the push stage, and it can lead to non-linear history if not handled carefully. Option D is wrong because configuring Azure Repos to use squash merge when completing pull requests collapses all commits into one, but it still requires a pull request and merge operation, which can introduce merge commits if conflicts arise, and it does not prevent simultaneous push conflicts; squash merge is about commit history compression, not conflict prevention.

Full explanation →

243

MCQhard

Your organization uses Azure DevOps and wants to enforce that all pipelines use a specific set of approved tasks. How can you achieve this?

A.Use the task restrictions feature in Azure DevOps to block unapproved tasks

B.Assign permissions to the task group to limit who can add tasks

C.Create a YAML template with the approved tasks and require all pipelines to use it

D.Configure a service hook to notify when an unapproved task is used

AnswerA

Use the task restrictions feature in Azure DevOps to block unapproved tasks: This organization-level policy lets you explicitly whitelist approved task IDs; any pipeline attempt to use a task outside the list is blocked or produces a warning, providing actual enforcement at the pipeline execution level rather than relying on user compliance.

Why this answer

Use the task restrictions feature in Azure DevOps to block unapproved tasks. Azure DevOps provides a 'Task restrictions' policy under Organization Settings > Policies > Add new policy, where you can specify which tasks are allowed or blocked across all pipelines. This enforces that only approved tasks are used.

Option B is incorrect because assigning permissions to a task group only controls who can modify the group, not which tasks are used in pipelines. Option C is incorrect because while YAML templates can standardize tasks, they do not enforce mandatory usage; pipelines can still be created without the template. Option D is incorrect because service hooks only trigger notifications when an unapproved task is used, but do not block its usage.

Full explanation →

244

MCQmedium

You are designing a security compliance plan for Azure Pipelines. The plan must ensure that no pipeline can use variables containing secrets unless those variables are stored in Azure Key Vault and referenced via a variable group linked to Key Vault. What is the best way to enforce this across all pipelines in an Azure DevOps organization?

A.Create a YAML template that mandates the use of Key Vault references.

B.Implement an Azure Policy that audits variable groups and requires Key Vault integration.

C.Require manual approval for all pipeline runs that use variables.

D.Use branch policies to prevent merging code that contains secrets.

AnswerA

A YAML template can enforce secure secret management across all pipelines by defining a standard structure that must be extended. Using the Azure DevOps 'required template' feature (under project settings or via pipeline decorators), you can force every pipeline to use a template that injects an AzureKeyVault task or a Key Vault-linked variable group, and optionally includes a script that fails the build if any inline secrets are detected. This gives you a central, versioned mechanism to mandate Key Vault references, which is enforceable at queue time rather than relying on manual review.

Why this answer

You can enforce a YAML template at the organization level using required template policies. This ensures all pipelines include a template that mandates Key Vault references for secrets, providing a scalable enforcement mechanism. Option B is incorrect because Azure Policy applies to Azure resources, not Azure DevOps constructs like variable groups.

Option C is incorrect because manual approvals do not enforce Key Vault usage. Option D is incorrect because branch policies control code, not variable usage during execution.

Full explanation →

245

MCQmedium

Your build pipeline uses the 'NuGetCommand@2' task to restore NuGet packages. You want to use packages from an Azure Artifacts feed that requires authentication. How should you configure the pipeline to authenticate with the feed?

A.Store the Personal Access Token (PAT) in a variable and use it in the NuGet config.

B.Create an Azure Artifacts service connection and select it in the NuGet task.

C.Add a 'NuGetAuthenticate@1' task before the NuGet restore task.

D.Install the NuGet credential provider on the agent manually.

AnswerC

This task authenticates with Azure Artifacts.

Why this answer

The 'NuGetAuthenticate@1' task is the correct way to authenticate with Azure Artifacts feeds in a pipeline because it automatically handles credential acquisition using the built-in Azure Artifacts credential provider. It works without needing to store or manage Personal Access Tokens (PATs) manually, and it integrates seamlessly with the pipeline's identity (e.g., the project collection build service). This task must be placed before the 'NuGetCommand@2' restore task to ensure the credentials are available for package restoration.

Exam trap

The trap here is that candidates often confuse service connections (which are used for external services like GitHub or generic endpoints) with the built-in Azure Artifacts authentication, leading them to select Option B, but Azure Artifacts feeds do not require a service connection because authentication is handled automatically via the pipeline's identity and the 'NuGetAuthenticate@1' task.

How to eliminate wrong answers

Option A is wrong because storing a PAT in a variable and using it in a NuGet config is a manual, less secure approach that requires managing token expiration and rotation, whereas Azure Artifacts provides a built-in authentication mechanism via the credential provider. Option B is wrong because an Azure Artifacts service connection is not a valid connection type for the 'NuGetCommand@2' task; the task expects a NuGet service connection (e.g., external feed) or relies on the 'NuGetAuthenticate@1' task for Azure Artifacts feeds. Option D is wrong because manually installing the NuGet credential provider on the agent is unnecessary and not a pipeline configuration step; the 'NuGetAuthenticate@1' task handles this automatically on Microsoft-hosted agents and can be configured for self-hosted agents.

Full explanation →

246

MCQmedium

The pipeline fails with the error 'The resource with name 'myregistry' could not be found'. What is the most likely cause?

A.The Azure Container Registry name is incorrect

B.The build ID variable is not defined

C.The service connection does not have permission to access the registry

D.The Azure CLI is not installed on the agent

AnswerA

The error 'resource with name m' indicates Azure DevOps cannot locate the specified Azure Container Registry (ACR) resource, which means the registry name provided in the task or variable does not exist or is misspelled in the current subscription/tenant. A correct ACR name must exactly match the globally unique registry name (e.g., 'myregistry.azurecr.io' without the domain), and any typo or mismatch will result in a 'not found' exception, not an authentication or CLI failure.

Why this answer

The error 'The resource with name 'myregistry' could not be found' indicates that the Azure Container Registry name specified in the pipeline is incorrect or does not exist in the subscription. Option A is correct because the most likely cause is a misspelled or wrong registry name. Option B is incorrect because the build ID variable is unrelated to finding a registry resource.

Option C is incorrect because permission issues typically result in authorization errors, not 'not found'. Option D is incorrect because Azure CLI availability does not affect resource lookup, and the error is about resource existence, not CLI installation.

Full explanation →

247

MCQmedium

Refer to the exhibit. You are migrating repository policies from Azure Repos to GitHub. The JSON shows a branch protection rule you plan to apply to the main branch. A developer pushes a hotfix directly to main without a pull request. What happens?

A.The push is blocked because required status checks are not met.

B.The push is blocked because enforceAdmins is true.

C.The push succeeds because no push restriction is defined.

D.The push is rejected because lockBranch is false.

AnswerC

The push succeeds because no branch policy restricts direct pushes to this branch, so only the repository's standard Git permissions apply. As long as the user has Contribute permission on the repository, a direct push to a non-locked branch is permitted.

Why this answer

The branch protection rule includes required status checks and lockBranch (set to false), but it does not require pull requests before merging. In GitHub, direct pushes to a branch are only blocked if 'Require a pull request before merging' is enabled. Since that is not present here, the developer can push directly to main without a pull request, and the push succeeds.

Options A and B are incorrect because required status checks and enforceAdmins do not block direct pushes; they only affect pull request merges. Option D is incorrect because lockBranch set to false allows modifications.

Exam trap

Remember that 'Require a pull request before merging' is the only setting that restricts direct pushes. Status checks and enforceAdmins apply to pull requests, not direct pushes.

Full explanation →

248

MCQmedium

Your release pipeline deploys to Azure App Service using a deployment slot. You need to ensure that after swapping slots, the staging slot retains the previous production configuration for rollback. Which deployment strategy should you use?

A.Rolling deployment

B.Blue-green deployment

C.Swap with preview

D.Canary deployment

AnswerC

Swap with preview is correct because it deploys the new build to a staging slot, allows you to validate it before performing a manual swap, and retains the previous configuration in the staging slot for easy rollback. This is the standard Azure App Service pattern for safe, zero-downtime releases.

Why this answer

Swap with preview (multi-phase swap) is the correct strategy because it uses Azure App Service deployment slots to validate the staged version before completing the swap. When the swap is completed, the staging slot receives the previous production code and configuration, preserving a rollback state. If a problem occurs, you can swap back to the staging slot.

Note that a standard slot swap also preserves the previous production state in staging, but swap with preview adds the benefit of preview validation before finalizing the swap, which aligns with the requirement of maintaining rollback capability.

Exam trap

The trap is that candidates may confuse general deployment strategies like blue-green or canary with Azure App Service's slot swap mechanics. While blue-green deployment is conceptually similar, the specific Azure feature that uses deployment slots and supports preview validation before swap is 'swap with preview'. A common mistake is to think a standard swap does not retain the previous production configuration in the staging slot, but in reality it does; the key differentiator of swap with preview is the preview phase that allows you to validate the app before the swap is finalized.

How to eliminate wrong answers

Option A is wrong because rolling deployment gradually replaces instances of the application with the new version, but it does not use deployment slots and does not inherently retain the previous production configuration in a separate slot for immediate rollback. Option B is wrong because blue-green deployment typically involves two separate environments (e.g., two App Service slots) and a full swap, but without the 'swap with preview' feature, the previous production configuration is overwritten in the staging slot during the swap, losing the rollback state. Option D is wrong because canary deployment routes a small percentage of traffic to the new version while keeping the old version running, but it does not use Azure App Service deployment slots for a full swap and does not guarantee that the staging slot retains the previous production configuration after the canary completes.

Full explanation →

249

Multi-Selectmedium

Which THREE practices are recommended for effective source control in a GitHub monorepo? (Choose three.)

Select 3 answers

A.Store large binary files directly in the repository

B.Use branch protection rules to enforce CI checks

C.Use a single build definition for all projects

D.Use code owners to automatically request reviewers

E.Use path filters to trigger only relevant CI workflows

AnswersB, D, E

Branch protection rules prevent direct pushes to main and require pull requests to pass required status checks (e.g., CI pipeline) before merging, enforcing quality gates and reducing regressions.

Why this answer

Branch protection rules (B) enforce required status checks like CI builds and tests before merging, maintaining stability in a monorepo with many contributors. Code owners (D) automatically request reviewers from the responsible teams for changes in their respective paths, ensuring proper review and accountability. Path filters (E) trigger only the CI workflows relevant to the changed code, avoiding unnecessary builds and reducing feedback loops.

Storing large binaries in the repo (A) is poor practice, and a single build definition for all projects (C) is inefficient because it forces full builds on every change.

Exam trap

The trap here is that candidates confuse 'monorepo best practices' with 'single repo simplicity' and incorrectly assume a single build definition is efficient, when in reality path-filtered, modular CI is essential to avoid unnecessary builds and long feedback loops.

Full explanation →

250

MCQmedium

You are designing a release pipeline for a Node.js application that deploys to Azure App Service. The pipeline must run integration tests against the deployed application. You want to use deployment slots to minimize downtime. What is the recommended approach?

A.Deploy to a staging slot, run tests against the staging slot, then swap to production.

B.Deploy to the production slot directly and run tests after deployment.

C.Deploy to a staging slot, swap, then run tests.

D.Deploy to a staging slot, run tests, then delete the staging slot.

AnswerA

Deploying to a staging slot allows the new build to run in a production-like environment, where automated and smoke tests validate functionality without affecting live users; the subsequent swap is atomic and fast, switching the production slot to the staged version with zero downtime and preserving the previous deployment for immediate rollback if needed.

Why this answer

Deploying to a staging slot first allows you to validate the application by running integration tests against the staging slot without impacting production traffic. After successful testing, swapping the staging slot with the production slot ensures zero-downtime deployment, as Azure App Service swaps the underlying virtual directories and configuration settings instantly.

Exam trap

The trap here is that candidates often confuse the order of operations, mistakenly thinking swapping before testing (Option C) is acceptable, but this would bypass the validation that slots are designed to provide.

How to eliminate wrong answers

Option B is wrong because deploying directly to the production slot and running tests after deployment risks exposing untested code to live users and can cause downtime if tests fail. Option C is wrong because swapping before running tests means the staging slot becomes production, and any issues found during testing would already be live, defeating the purpose of using slots for safe validation. Option D is wrong because deleting the staging slot after testing discards the validated deployment, requiring a redeployment to production and losing the ability to swap back if issues arise.

Full explanation →

251

MCQmedium

You have a multi-stage pipeline that deploys to multiple regions. You want to ensure that if the deployment to one region fails, the pipeline does not proceed to the next region. What is the best way to implement this?

A.Use pipeline decorators to inject error handling steps.

B.Add a manual approval between regions.

C.Configure each region deployment as a separate stage with no dependencies.

D.Define stage dependencies with 'dependsOn' and set 'condition' to 'succeeded()'.

AnswerD

Stage dependencies with conditions ensure that subsequent stages only run if previous stages succeeded.

Why this answer

Azure Pipelines allows you to define stage dependencies using 'dependsOn' and control execution flow with 'condition'. By setting each region deployment as a separate stage that depends on the previous region's stage succeeding (condition: 'succeeded()'), the pipeline will automatically halt if any region deployment fails, preventing progression to subsequent regions.

Exam trap

The trap here is that candidates often confuse manual approvals (Option B) with automatic failure handling, not realizing that approvals only pause for human input and do not inherently stop the pipeline on a deployment failure.

How to eliminate wrong answers

Option A is wrong because pipeline decorators are used to inject steps into every pipeline or stage automatically (e.g., for compliance or security checks), not to implement conditional stage execution based on previous stage success. Option B is wrong because manual approvals pause the pipeline for human intervention but do not automatically prevent progression on failure; they require manual action and do not react to deployment failures. Option C is wrong because configuring stages with no dependencies means they run in parallel or independently, which would allow deployment to other regions even if one fails, defeating the requirement to stop on failure.

Full explanation →

252

MCQmedium

You are reviewing the branch protection policy for the main branch in an Azure DevOps repository. Based on the exhibit, what happens when a stale review exists on a pull request after new changes are pushed?

A.Admins are exempt from the review requirement

B.The stale review is automatically dismissed, and the PR requires new approvals

C.The PR still requires only 2 approvals, but stale reviews are not dismissed

D.The PR can be merged even without the required reviews

AnswerB

Because `dismissStaleReviews` is enabled, any approval given before a new commit that changes the code is automatically dismissed, and the PR must obtain fresh approvals from the required number of reviewers before it can be completed.

Why this answer

The branch protection policy for the main branch has 'Reset code reviewer votes when there are new changes' enabled. When a stale review exists after new changes are pushed, Azure DevOps automatically dismisses the previous approval(s) and requires new approvals to meet the minimum number of reviewers (2). This ensures that reviewers re-evaluate the latest code changes before the pull request can be merged.

Exam trap

The trap here is that candidates may confuse 'stale reviews are not dismissed' with the default behavior of Azure DevOps, but the exhibit explicitly shows the 'Reset code reviewer votes when there are new changes' checkbox is enabled, which forces dismissal.

How to eliminate wrong answers

Option A is wrong because the exhibit does not show any exemption for admins from the review requirement; the policy applies equally to all users unless explicitly configured otherwise. Option C is wrong because when 'Reset code reviewer votes when there are new changes' is enabled, stale reviews are dismissed, not retained. Option D is wrong because the policy still requires the minimum number of approvals (2) to be met; the PR cannot be merged without the required reviews.

Full explanation →

253

MCQhard

You are debugging a production issue using Application Insights Snapshot Debugger. The exhibit shows a snapshot from a NullReferenceException. The variable _dbContext is null. What is the most likely root cause?

A.The call to the database is not awaited, causing a race condition.

B.The DbContext is not registered in the dependency injection container.

C.The database connection string is invalid in appsettings.json.

D.The OnGet method is missing a null check for _dbContext before usage.

AnswerB

Incorrect. In Razor Pages, the page model (IndexModel) is automatically instantiated by the framework. It does not need to be registered in the DI container for construction injection to work.

Why this answer

In ASP.NET Core, when a constructor-injected service like a DbContext is null at runtime, the most likely root cause is that the service (the DbContext) has not been registered in the dependency injection container. Page models themselves do not require registration. The missing null check (Option D) is a symptom, not the root cause, and the other options are unrelated.

Exam trap

Candidates may mistakenly choose Option D (missing null check) because it directly prevents the exception, but the root cause is the missing DI registration.

How to eliminate wrong answers

Option A is wrong because an unawaited database call would cause a race condition or incomplete operation, but the snapshot clearly shows _dbContext is null, not that the call was started and not completed. Option C is wrong because an invalid connection string would cause a runtime exception when the DbContext attempts to open a connection, not a NullReferenceException from a null _dbContext variable. Option D is wrong because while adding a null check would prevent the crash, it does not address the root cause—the missing DI registration—and would only mask the underlying configuration error.

Full explanation →

254

MCQmedium

You have a release pipeline that deploys to multiple environments. You need to ensure that a manual approval is required before deploying to production. What should you configure?

A.Add a manual intervention task in the production stage

B.Set a post-deployment approval on the production stage

C.Set a pre-deployment approval on the production stage

D.Set a branch policy on the release branch

AnswerC

A pre-deployment approval is a release-stage gate that pauses the pipeline immediately before the production stage starts, and it requires a designated approver or approval group to explicitly approve the deployment. This ensures the artifact is not deployed to production until manual authorization is granted, and Azure Pipelines records the approver, timestamp, and any comments for full auditability. Unlike branch policies or post-deployment hooks, this mechanism directly satisfies the requirement to approve before production deployment and provides a clean separation of duties between build and release. Additionally, you can configure policies such as re-approval if the artifact changes, making it the correct, policy-driven approach.

Why this answer

Pre-deployment approvals are configured on a stage in Azure Pipelines to require manual sign-off before any deployment to that stage begins. Since the question specifies that approval is needed before deploying to production, a pre-deployment approval on the production stage enforces that gate before the release pipeline executes any deployment tasks in that environment.

Exam trap

The trap here is confusing pre-deployment approvals with post-deployment approvals or manual intervention tasks, as candidates often think a manual task can substitute for a formal approval gate, but only pre-deployment approvals enforce the 'before deployment' requirement with proper workflow and audit trail.

Why the other options are wrong

Manual intervention task is for classic releases, but approvals are a better fit and work in YAML too.

Post-deployment approval occurs after deployment, not before.

Branch policies affect pull requests, not release pipelines.

Full explanation →

255

MCQhard

You are the DevOps lead for a large enterprise that uses GitHub for source control and Azure Pipelines for CI/CD. The organization has hundreds of repositories, each with its own pipeline. Recently, the security team mandated that all pipelines must use a centralized set of tasks for secret scanning and compliance checks before any deployment. You need to design a solution that enforces these mandatory tasks across all pipelines without modifying each pipeline individually. The solution should allow pipeline authors to add their own custom steps after the mandatory steps. The mandatory steps must be versioned and updated centrally. You also need to ensure that the mandatory steps are not bypassed by pipeline authors. What should you do?

A.Store the mandatory tasks as a YAML template in a central repository. In each pipeline, use the 'template' reference to include the mandatory steps. Use branch protection rules on the central repository to require approval for changes to the template.

B.Use a global list of tasks in the Azure DevOps organization settings that automatically get injected into every pipeline.

C.Create a single pipeline that runs across all repositories and include the mandatory tasks in that pipeline.

D.Create a custom Azure DevOps extension that adds the mandatory tasks to all pipelines using a pre-job hook.

AnswerD

Custom Azure DevOps extensions cannot reliably enforce mandatory tasks in all pipelines because extensions must be installed and are not automatically injected into every pipeline. There is no supported pre-job hook in the extension model that can force tasks to run; pipeline authors can simply omit or disable the extension, so it does not provide central enforcement.

Why this answer

D is correct. A custom Azure DevOps extension with a pre-job hook (pipeline decorator) automatically injects mandatory steps into every pipeline without requiring changes to individual pipelines. It is centrally managed and versioned, and cannot be bypassed by pipeline authors.

A is incorrect because it requires adding a template reference to each pipeline and the template inclusion is optional; branch protection only prevents tampering with the template, not its omission. B is invalid because Azure DevOps has no global task list injection. C is invalid because a single pipeline cannot run across all repositories with custom steps.

Exam trap

A YAML template with branch protection is often mistaken for an enforcement mechanism, but it does not require pipelines to include the template.

Full explanation →

256

MCQeasy

You want to trigger a pipeline automatically when a new tag is pushed to a GitHub repository. Which trigger should you configure in the pipeline YAML?

A.pr:

B.schedules:

C.trigger: tags:

D.resources: pipelines:

AnswerC

This is the correct syntax to trigger on tags.

Why this answer

The `trigger` block in Azure Pipelines YAML supports a `tags` filter that instructs the pipeline to run automatically when a Git tag matching the specified pattern is pushed. By configuring `trigger: tags: include: ['*']` or a specific tag pattern, the pipeline will start on any new tag push to the GitHub repository, which is the exact requirement.

Exam trap

The trap here is that candidates often confuse `trigger:` with `pr:` or `schedules:`, mistakenly thinking any trigger keyword can handle tag events, but only the `tags` sub-property of `trigger:` is designed for Git tag-based automation.

How to eliminate wrong answers

Option A is wrong because `pr:` configures pull request validation triggers, not tag-based triggers; it would start the pipeline on PR creation or update, not on tag push. Option B is wrong because `schedules:` defines cron-based scheduled runs (e.g., nightly builds) and has no relation to Git tag events. Option D is wrong because `resources: pipelines:` is used to trigger this pipeline from another pipeline's completion (pipeline resource trigger), not from a Git tag push event.

Full explanation →

257

MCQhard

You are designing a pipeline that deploys to an Azure Kubernetes Service (AKS) cluster. You need to securely pass the Kubernetes cluster credentials to the pipeline without hardcoding them. Which approach should you use?

A.Store credentials in a pipeline variable with 'secret' type.

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

C.Hardcode the credentials in the pipeline YAML.

D.Use a secure file in the pipeline library.

AnswerB

A variable group linked to Azure Key Vault securely references secrets stored in Key Vault, so Azure DevOps fetches the current values at pipeline runtime rather than storing them in the pipeline definition. This leverages Key Vault's RBAC, versioning, and rotation, and allows the same service principal to be used across many pipelines without exposing it in YAML.

Why this answer

Azure Key Vault provides a secure, centralized store for secrets like Kubernetes cluster credentials, and linking a variable group to Key Vault allows the pipeline to dynamically retrieve those secrets at runtime without exposing them in the pipeline definition or logs. This approach follows the principle of least privilege and ensures credentials are never hardcoded or stored in plaintext within the pipeline.

Exam trap

The trap here is that candidates may think a pipeline secret variable is sufficient for security, but Azure DevOps specifically recommends using Key Vault for production-grade secret management to avoid storing secrets in the pipeline's internal database and to enable centralized lifecycle management.

Why the other options are wrong

While secure, it does not leverage Key Vault for secret management and rotation.

This is insecure and violates best practices.

Secure files are for files like certificates, not for credentials; but they can be used for kubeconfig, but variable group with Key Vault is more direct.

Full explanation →

258

MCQeasy

Your build pipeline uses a hosted agent. You need to securely pass a connection string to a deployment task. The connection string contains a password. What is the recommended approach to store and use this secret in Azure Pipelines?

A.Define the connection string as a plain variable in the YAML pipeline.

B.Hardcode the connection string in the deployment script and set the file as read-only.

C.Define the connection string as a secret variable in the pipeline's variable group or in the pipeline settings UI, and reference it as `$(connectionString)`.

D.Store the connection string in Azure Key Vault and use the 'Azure Key Vault' task to retrieve it at runtime.

AnswerC

Secret variables are encrypted and masked in logs.

Why this answer

The recommended approach is to define the connection string as a secret variable in the pipeline's variable group or in the pipeline settings UI, and reference it as $(connectionString). Secret variables are encrypted at rest and never exposed in logs or to other tasks. Option A is incorrect because plain variables are visible in logs and YAML.

Option B is incorrect because hardcoding secrets in scripts is insecure and violates best practices. Option D, while secure, is overkill for a simple secret and requires additional configuration and permissions, making it less recommended for this scenario.

Exam trap

Candidates may overthink and choose Azure Key Vault for all secrets, but for a single static secret used within a pipeline, secret variables are simpler and equally secure.

Full explanation →

259

MCQhard

Your organization uses Azure DevOps and has a strict compliance requirement: all changes to the main branch must be reviewed by at least two members of the 'ComplianceTeam' group. Additionally, a static code analysis tool must run and its results must be published to the pull request. The ComplianceTeam is a custom group defined in Azure DevOps, not a Microsoft Entra ID group. The team wants to enforce this using branch policies. You need to configure the minimum number of reviewers and also ensure that the code analysis results are visible to reviewers. What should you do?

A.Add a branch policy 'Require a minimum number of reviewers' set to 2, and specify the ComplianceTeam as required reviewers. Additionally, add a build policy that runs the code analysis and publishes results as a build summary.

B.Add a branch policy 'Require code owner review' and define the ComplianceTeam as code owners in a CODEOWNERS file.

C.Add a branch policy 'Comment resolution' and configure the ComplianceTeam to resolve comments.

D.Add a branch policy 'Automatically included reviewers' and set the ComplianceTeam to be automatically added to all PRs.

AnswerA

Setting 'Require a minimum number of reviewers' to 2 and specifying ComplianceTeam as required reviewers enforces exactly two approvals from that team before a pull request can be merged. Because required reviewers are mandatory, any approval from a team member counts toward the minimum, and the policy blocks the merge until both approvals are present. Adding a build policy that runs code analysis and publishes results as a build summary integrates the compliance gate directly into the PR, giving reviewers the evidence needed to approve confidently. This combination fully satisfies the strict compliance requirement.

Why this answer

The 'Require a minimum number of reviewers' branch policy enforces that at least two members from the ComplianceTeam must approve the pull request. Adding a build policy that runs static code analysis and publishes results as a build summary ensures the analysis output is visible directly in the PR, meeting the compliance requirement for both reviewer count and code analysis visibility.

Exam trap

The trap here is that candidates often confuse 'Automatically included reviewers' (which only adds reviewers but does not enforce approval) with 'Require a minimum number of reviewers' (which enforces the actual approval count), leading them to choose Option D instead of A.

How to eliminate wrong answers

Option B is wrong because 'Require code owner review' only mandates that a code owner (defined in a CODEOWNERS file) must approve changes to specific files; it does not enforce a minimum number of reviewers or require two specific members from the ComplianceTeam. Option C is wrong because 'Comment resolution' only tracks whether comments on a PR are resolved, not reviewer count or code analysis visibility. Option D is wrong because 'Automatically included reviewers' merely adds the ComplianceTeam as optional reviewers to the PR but does not enforce that at least two of them must approve the changes.

Full explanation →

260

MCQeasy

Your pipeline uses a multi-stage YAML file. You want to conditionally run a stage only when the build is triggered from the 'main' branch. Which expression should you use in the 'condition' property of the stage?

A.startsWith(variables['Build.SourceBranch'], 'main')

B.eq(variables['Build.SourceBranchName'], 'refs/heads/main')

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

D.eq(variables['Build.SourceBranch'], 'main')

AnswerC

This condition is correct because Build.SourceBranch contains the complete Git ref path, and comparing it directly to the exact string 'refs/heads/main' uniquely identifies the main branch without matching maintenance or other similarly named branches. It is the precise and recommended way to gate on the main branch in Azure Pipelines.

Why this answer

The `Build.SourceBranch` variable in Azure Pipelines contains the full Git ref path (e.g., `refs/heads/main`). The `condition` property evaluates expressions at runtime, and using `eq(variables['Build.SourceBranch'], 'refs/heads/main')` precisely matches the full ref for the main branch, ensuring the stage runs only when the trigger originates from that branch.

Exam trap

The trap here is that candidates often confuse `Build.SourceBranch` (full ref) with `Build.SourceBranchName` (short name) or assume a simple substring match like `startsWith` is sufficient, leading them to pick options that either compare the wrong variable or use an imprecise matching function.

How to eliminate wrong answers

Option A is wrong because `startsWith(variables['Build.SourceBranch'], 'main')` would incorrectly match branches like `main-feature` or `maintenance` since it only checks the prefix, not the exact ref. Option B is wrong because `Build.SourceBranchName` contains only the short branch name (e.g., `main`), not the full ref path `refs/heads/main`, so the comparison fails. Option D is wrong because `Build.SourceBranch` always includes the full ref path (e.g., `refs/heads/main`), so comparing it to just `'main'` will never evaluate to true.

Full explanation →

261

MCQmedium

Your team uses Azure Pipelines to build a .NET Core application. The build runs successfully on Windows agents, but you need to also run the build on Linux agents to validate cross-platform compatibility. The pipeline currently has a single `windows-latest` agent pool. What is the most efficient way to run the build on both platforms without duplicating the entire pipeline?

A.Create two separate pipelines, one for each platform.

B.Use a multi-job pipeline with two jobs, each specifying a different pool.

C.Use a multi-stage pipeline with a stage for each platform.

D.Add a `strategy` with a `matrix` that specifies `vmImage: ['windows-latest', 'ubuntu-latest']` in the job.

AnswerD

Adding a `strategy` with a `matrix` to a job instructs Azure Pipelines to expand that job into multiple job instances at queue time, each with the same steps but with the matrix variables assigned from a specific entry. By mapping a variable like `vmImage` to `['windows-latest', 'ubuntu-latest']` and then referencing it via `$(vmImage)` in the pool specification, the same job runs simultaneously on both Windows and Linux agents, producing a true parallel cross-platform build. This is the idiomatic Azure Pipelines pattern because it keeps the job logic in one place, eliminates duplication, and makes adding or removing a platform as simple as editing a list in the matrix.

Why this answer

Using a `strategy` with a `matrix` allows the same job to run on multiple agent pools in parallel, enabling cross-platform validation without duplicating the pipeline. Option A duplicates the entire pipeline, which is inefficient. Option B would require separate jobs, but not as concise as the matrix strategy.

Option C uses stages, which run sequentially, not in parallel for this purpose.

Full explanation →

262

Multi-Selecthard

Which TWO actions should you take to implement Git-based source control for a large enterprise with multiple teams and a single repository (monorepo)? (Select TWO.)

Select 2 answers

A.Require all teams to work on a single branch

B.Use Git submodules to separate team code

C.Use forking workflow for each team

D.Configure path-based branch policies

E.Use sparse checkout to reduce clone time

AnswersD, E

Configuring path-based branch policies in Azure DevOps lets you assign specific reviewers and required checks to changes under particular directories (e.g., src/teamA), so each team enforces its own quality gates while still integrating into a shared trunk. This targets code review and CI to the relevant parts of the monorepo, improving both safety and development velocity.

Why this answer

Using sparse checkout reduces clone size. Path-based branch policies enforce team-specific reviews. Forking is not typical for monorepos.

Submodules introduce complexity. Single branch for all teams causes conflicts.

Full explanation →

263

Multi-Selectmedium

You are implementing a release pipeline with multiple stages. You want to automatically trigger the next stage only if the previous stage succeeds and the build is from the 'main' branch. Which TWO conditions should you configure?

Select 2 answers

A.Add a condition that checks if the source branch is 'main'.

B.Set the trigger on the stage to 'After stage' and select the previous stage.

C.Add a condition: 'eq(variables['Build.SourceBranch'], 'main')' to the stage.

D.Add a condition: 'succeeded()' to the stage.

E.Add a condition: 'eq(variables['Build.SourceBranch'], 'main')' with correct syntax.

AnswersA, B

Required to restrict to main branch.

Why this answer

The correct answers are A and B. To automatically trigger the next stage only when the previous stage succeeds and the build is from the 'main' branch, you need two configurations: first, set the stage trigger to 'After stage' and select the previous stage (option B), which ensures the stage runs after the previous stage completes successfully. Second, add a condition that checks the source branch—Option A correctly identifies this need, though the exact expression should be `eq(variables['Build.SourceBranch'], 'refs/heads/main')`.

Option D is incorrect because `succeeded()` only checks that all previous stages succeeded but does not enforce the branch condition. Option C is wrong due to incorrect syntax (missing 'refs/heads/'). Option E is also incorrect because the syntax shown is not correct; the correct syntax requires 'refs/heads/main'.

Full explanation →

264

MCQhard

You are designing a release pipeline for a critical application that must minimize downtime during deployment. The application runs on Azure Kubernetes Service (AKS) and uses Azure SQL Database. Which deployment strategy should you recommend?

A.Rolling update with health probes.

B.Canary deployment with progressive exposure.

C.Blue-green deployment with traffic manager.

D.Recreate deployment by deleting the old version first.

AnswerC

Blue-green deployment with traffic manager provisions two identical environments, with the traffic manager routing 100% of traffic to the blue environment. At switchover, it instantly shifts traffic to the green environment by updating DNS/routing rules, and rollback is equally immediate, so downtime is reduced to seconds or less.

Why this answer

Blue-green deployment with Traffic Manager is recommended because it allows you to maintain two identical environments (blue and green) and instantly switch traffic between them via Azure Traffic Manager. This minimizes downtime to the time it takes to update DNS or routing rules, and provides immediate rollback capability by switching back to the previous environment. For a critical application on AKS with Azure SQL Database, this strategy avoids the complexity of managing state during rolling updates and ensures zero-downtime cutover.

Exam trap

The trap here is that candidates often choose rolling updates (Option A) because they assume health probes guarantee zero downtime, but they overlook the fact that rolling updates still involve a gradual transition that can cause brief unavailability or require complex rollback logic, whereas blue-green provides instant, atomic cutover with Traffic Manager.

How to eliminate wrong answers

Option A is wrong because rolling updates with health probes, while reducing downtime, still involve gradual replacement of pods, which can cause brief periods of reduced capacity or partial unavailability if health probes are misconfigured; they also do not provide instant rollback. Option B is wrong because canary deployment with progressive exposure is designed for testing new versions with a small subset of users, not for minimizing downtime during a full production deployment—it introduces complexity in routing and monitoring and does not guarantee zero-downtime cutover. Option D is wrong because recreating by deleting the old version first causes full downtime until the new version is fully deployed, which violates the requirement to minimize downtime.

Full explanation →

265

Drag & Dropmedium

Drag and drop the steps to configure Azure DevOps artifact feeds for NuGet packages into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

Feed setup starts with creation, upstream sources, permissions, publishing, and consumption.

Full explanation →

266

MCQmedium

Your team uses a monorepo in Azure Repos containing multiple projects. You want to set up CI/CD so that only the projects affected by a commit are built and deployed. Which approach should you use?

A.Use Git hooks to detect changes and run only the relevant build scripts locally.

B.Create separate Azure Pipelines for each project, each configured to trigger on changes to that project's folder.

C.Use a single YAML pipeline that includes all projects, and use the 'condition' keyword to skip steps based on changed files.

D.Use a single YAML pipeline with path-based triggers and path filters in the 'trigger' section for each project's folder.

AnswerB

This can work but is harder to maintain than a single pipeline with path filters.

Why this answer

In a monorepo, to build and deploy only affected projects, create one Azure Pipeline per project and configure each with path-based triggers that include only that project's folder. This way, a commit touching a specific project triggers only that project's pipeline. While a single pipeline can use path filters and conditions to skip steps, the straightforward and recommended approach is separate pipelines.

Exam trap

Candidates often pick a single pipeline with path triggers (option D) thinking it will run only affected projects, but path triggers only decide whether the whole pipeline starts; to limit execution within a single pipeline, you need additional conditions. Separate pipelines per project are a cleaner solution.

How to eliminate wrong answers

Option A is wrong because Git hooks are client-side scripts that run locally on a developer's machine, not in the CI/CD pipeline, and they cannot enforce centralized build triggers or deployment automation. Option B is wrong because creating separate pipelines for each project is a valid approach but is not the single YAML pipeline approach described in the question; the question asks for a single pipeline solution, and separate pipelines would require managing multiple pipeline definitions. Option C is wrong because the `condition` keyword in YAML pipelines evaluates at runtime based on variables or expressions, not directly on changed files; it cannot skip steps based on which files changed in a commit without additional logic like `git diff` commands, making it less efficient and more complex than path-based triggers.

Full explanation →

267

MCQmedium

You are designing a build validation policy for a GitHub repository. You want to ensure that all pull requests pass a CI check before they can be merged. What should you configure?

A.Enable Dependabot alerts on the repository.

B.Configure a repository rule to require a pull request before merging.

C.Add a GitHub Actions workflow that runs on 'pull_request' and set it as a required status check in branch protection.

D.Create a webhook to trigger a build on Azure Pipelines.

AnswerC

Adding a GitHub Actions workflow with a `pull_request` trigger executes CI on each PR, and then marking the resulting status check as required in branch protection blocks merging until that workflow completes successfully. This creates a hard enforcement gate that validates the build before changes can be merged, making it the correct approach for build validation.

Why this answer

Branch protection rules in GitHub can require status checks to pass before merging. You set up a rule that requires the CI workflow to succeed.

Full explanation →

268

MCQmedium

Your team uses Azure Boards to track work items. They want to automatically update the 'Remaining Work' field on a task when a developer completes a pull request linked to that task. Which Azure DevOps feature should you configure?

A.Define a pipeline variable to update the field during build.

B.Use a service hook to trigger an Azure Function that updates the work item.

C.Create a work item template that sets remaining work.

D.Configure a branch policy to automatically update work items on PR completion.

AnswerD

This is the correct feature to update work items when a PR is completed.

Why this answer

Azure DevOps branch policies include a setting to automatically update work items linked to a pull request upon completion. Specifically, under branch policy settings, you can enable 'Automatically update work items' which, when a PR is completed, sets the 'Remaining Work' field to zero (or another configured value) for linked tasks. This directly meets the requirement without custom scripting or external services.

Exam trap

The trap here is that candidates may overcomplicate the solution by choosing a custom integration (like service hooks) or misapply pipeline variables, missing the fact that Azure DevOps provides a native, configuration-only feature under branch policies to automatically update work items on PR completion.

How to eliminate wrong answers

Option A is wrong because pipeline variables are used to pass values during build or release execution, not to update work item fields in Azure Boards; they have no direct mechanism to modify work items. Option B is wrong because while service hooks can trigger an Azure Function to update work items, this is an overly complex, custom-coded solution when a built-in branch policy feature exists for exactly this purpose. Option C is wrong because work item templates are used to pre-populate fields when creating new work items, not to update existing work items automatically upon PR completion.

Full explanation →

269

MCQmedium

You are designing a build pipeline for a Java application that uses Maven. The build must run unit tests and integration tests separately. You want to publish test results to Azure Pipelines. Which task configuration should you use?

A.Use two Gradle tasks, one for unit tests and one for integration tests.

B.Use a single Maven task with goals 'test verify', and configure the task to publish test results.

C.Use two Maven tasks with goals 'test' and 'verify', and configure the Publish Test Results task to publish results from both runs.

D.Use two Visual Studio Test tasks, one for unit tests and one for integration tests.

AnswerC

Correct: Maven can run tests and PublishTestResults can publish results.

Why this answer

It uses two separate Maven tasks with the 'test' and 'verify' goals, which allows unit tests and integration tests to run independently. The Publish Test Results task is then configured to consume the test result files (typically JUnit XML reports) from both runs, enabling Azure Pipelines to display a unified test summary. This approach aligns with the requirement to run unit and integration tests separately while still publishing all results.

Exam trap

The trap here is that candidates assume a single Maven task with both goals can achieve separation, but Azure Pipelines executes all goals in one run, so the tests are not isolated; the correct approach requires two distinct tasks to enforce separate execution and independent result publishing.

How to eliminate wrong answers

Option A is wrong because Gradle tasks are not applicable; the question specifies a Java application that uses Maven, not Gradle. Option B is wrong because using a single Maven task with goals 'test verify' runs both phases sequentially in the same Maven invocation, which does not satisfy the requirement to run unit tests and integration tests separately. Option D is wrong because Visual Studio Test tasks are designed for .NET test frameworks (e.g., MSTest, xUnit) and cannot directly execute Maven-based Java tests.

Full explanation →

270

Multi-Selecthard

Which THREE components are required to set up a self-hosted agent in Azure Pipelines? (Choose three.)

Select 3 answers

A.An Azure Resource Manager service connection

B.A personal access token (PAT) with Agent Pools (read, manage) scope

C.A machine (virtual or physical) to run the agent software

D.The agent software downloaded from the Azure DevOps organization

E.An Azure Active Directory account for the agent

AnswersB, C, D

A PAT scoped to Agent Pools (read, manage) is required because it is the primary authentication mechanism for registering a self-hosted agent against an Azure DevOps organization. This token grants the agent the necessary permissions to appear in the target agent pool and receive job assignments.

Why this answer

A personal access token (PAT) with Agent Pools (read, manage) scope is required because the self-hosted agent uses this token to authenticate with Azure DevOps during the configuration step. The agent registers itself into the specified agent pool, and the PAT must have the 'Agent Pools (read, manage)' scope to authorize this registration and subsequent communication.

Exam trap

The trap here is that candidates often confuse a service connection (needed for deploying to Azure) with the authentication mechanism required to register the agent itself, leading them to select Option A instead of recognizing that only the PAT with Agent Pools scope is needed.

Full explanation →

271

MCQhard

Your Azure Pipelines release pipeline deploys to multiple stages. You need to implement a manual approval gate that requires two specific users to approve before deployment proceeds to production. The approval should expire after 8 hours. Which configuration should you use?

A.Pre-deployment conditions: Add approvers (user1, user2) with 'All' policy and set timeout to 480 minutes

B.Pre-deployment conditions: Add approvers (user1, user2) with 'Any one' policy

C.Pre-deployment conditions: Add approvers (user1, user2) with 'All' policy and set 'Allow deployment without approval' to true

D.Post-deployment conditions: Add approvers (team) with 'All' policy

AnswerA

Setting pre-deployment approvers to user1 and user2 with the 'All' policy requires both users to explicitly approve the release before deployment proceeds. The 480-minute timeout ensures that if either approver does not respond within 8 hours, the approval process times out, preventing indefinite blocking of the pipeline. This satisfies the requirement that both specific individuals must approve, with an 8-hour window.

Why this answer

It configures a pre-deployment approval gate requiring both user1 and user2 to approve (the 'All' policy) before the production stage proceeds, and sets the timeout to 480 minutes (8 hours) to expire the approval request. This matches the requirement for two specific users to approve and an 8-hour expiration.

Exam trap

The trap here is confusing pre-deployment vs. post-deployment conditions and misinterpreting the 'All' vs. 'Any one' policy, leading candidates to select an option that allows a single approver or applies the gate after deployment.

How to eliminate wrong answers

Option B is wrong because the 'Any one' policy allows either user1 or user2 to approve, not both, which fails the requirement for two specific users to approve. Option C is wrong because setting 'Allow deployment without approval' to true would bypass the approval gate entirely, contradicting the requirement for manual approval. Option D is wrong because post-deployment conditions apply after the deployment runs, not before, and the requirement is for a pre-deployment gate; additionally, it specifies a team rather than two specific users.

Full explanation →

272

MCQhard

Refer to the exhibit. You run a KQL query in Microsoft Sentinel to audit Azure Container Registry login failures. The result shows 15 failed push attempts to the 'contoso/webapp' repository and 3 failed pull attempts to 'contoso/api'. What is the most likely security implication?

A.The audit logs are not enabled for the container registry.

B.The container registry is misconfigured and allowing anonymous pushes.

C.The 'contoso/api' repository has been successfully pulled by an unauthorized user.

D.An attacker is attempting to push malicious images to the 'contoso/webapp' repository.

AnswerD

Multiple consecutive failed push events targeting the 'contoso/webapp' repository strongly indicate an attacker is attempting to upload malicious images using compromised or guessed credentials; although the pushes are failing, the systematic pattern of unauthorized write attempts is a clear security threat.

Why this answer

The query shows 15 failed push attempts to 'contoso/webapp' and 3 failed pull attempts to 'contoso/api'. Repeated failed push attempts to a specific repository are a classic indicator of an attacker trying to upload malicious images, as push operations require authentication and authorization. The high number of failures suggests a brute-force or credential-stuffing attack targeting the push operation, which is the most direct path to compromising the registry with unauthorized content.

Exam trap

The trap here is that candidates may misinterpret failed pull attempts as evidence of a successful breach (Option C), but the query explicitly shows failures, not successes, and the real threat is the repeated push failures indicating an active attack.

How to eliminate wrong answers

Option A is wrong because the query itself is auditing login failures, which means audit logs are already enabled and capturing the events. Option B is wrong because anonymous pushes would not generate login failures; anonymous access would either succeed or be blocked at the registry level without authentication attempts. Option C is wrong because the query shows failed pull attempts, not successful ones, so there is no evidence that an unauthorized user successfully pulled from 'contoso/api'.

Full explanation →

273

MCQhard

You run the Azure CLI command shown in the exhibit as part of a release pipeline to deploy a ZIP package to an Azure App Service. The deployment succeeds, but the app does not start. What is the most likely cause?

A.The app's startup command is not configured

B.The resource group name is incorrect

C.The runtime stack is not specified in the command

D.The deployment slot is not specified

AnswerA

ZIP deploy does not set startup command; needs manual config.

Why this answer

The Azure CLI command `az webapp deploy` deploys the ZIP package to the App Service, but it does not configure the startup command. If the application (e.g., a Node.js or Python app) requires a specific startup file or script (like `npm start` or `gunicorn`), the App Service will fail to start because it defaults to a generic handler. The startup command must be set via the `--startup-file` parameter in `az webapp config set` or in the Azure portal.

Exam trap

The trap here is that candidates assume a successful deployment (no CLI errors) guarantees the app will run, but Azure App Service separates the deployment of artifacts from the runtime configuration, so a missing startup command is a common silent failure.

How to eliminate wrong answers

Option B is wrong because an incorrect resource group name would cause the deployment command to fail entirely (e.g., 'ResourceGroupNotFound' error), not allow a successful deployment with a subsequent startup failure. Option C is wrong because the runtime stack is specified during the App Service creation (e.g., `az webapp create --runtime`), not in the `az webapp deploy` command; the deploy command only handles the package upload and extraction. Option D is wrong because deployment slots are optional; if no slot is specified, the command deploys to the production slot by default, and the absence of a slot specification does not prevent the app from starting.

Full explanation →

274

Multi-Selecteasy

Which TWO of the following are benefits of using Infrastructure as Code (IaC) over manual infrastructure management?

Select 2 answers

A.Consistent environment provisioning

B.Reduced configuration drift

C.Removes the need for testing

D.Eliminates the need for documentation

E.Lower infrastructure costs

AnswersA, B

Infrastructure as code (IaC) encodes the entire environment definition in versioned, reviewable files, so every provisioning run produces identical infrastructure across dev, test, and production. This eliminates manual configuration steps and 'works on my machine' discrepancies, ensuring reproducible and immutable deployments.

Why this answer

Options A and B are correct. Option A is correct because IaC enables consistent and repeatable provisioning, reducing manual errors. Option B is correct because IaC helps prevent configuration drift by maintaining desired state configurations.

Option C is incorrect because IaC does not remove the need for testing; testing is still required to validate infrastructure code. Option D is incorrect because IaC still requires documentation for design and operations. Option E is incorrect because while IaC can optimize costs, it does not inherently guarantee lower costs; cost depends on resource choices.

Full explanation →

275

Multi-Selecteasy

Which TWO tools can be used to enforce branch protection policies in GitHub repositories? (Choose two.)

Select 2 answers

A.Azure Pipelines branch policies

B.Microsoft Intune compliance policies

C.GitHub branch protection rules

D.Microsoft Purview data classification

E.GitHub Actions workflows

AnswersA, C

Azure Pipelines branch policies are a correct tool because, when a repository is hosted on GitHub, Azure Pipelines can integrate directly with GitHub's branch protection system. It enables required status checks (such as successful pipeline builds) to be mandatory for pull request completion, effectively enforcing policies like 'build must pass' on protected branches.

Why this answer

Azure Pipelines branch policies allow you to enforce requirements such as requiring a minimum number of reviewers, checking for linked work items, or requiring a successful build before merging pull requests into protected branches. This integrates directly with GitHub repositories to enforce compliance and code quality standards.

Exam trap

The trap here is that candidates often confuse GitHub Actions workflows with branch protection rules, but workflows are event-driven automation and cannot enforce merge restrictions, whereas branch protection rules and Azure Pipelines branch policies are specifically designed for that purpose.

Full explanation →

276

MCQhard

A multinational company uses Azure DevOps with a single project. The project has multiple teams in different time zones. They want to customize the process to reflect different working days for each team. What is the recommended approach?

A.Create a custom process for each time zone and assign teams accordingly.

B.Use the same process but create separate areas for each team, then configure working days per area path.

C.Use the same process and configure working days in the team settings for each team.

D.Use the same process and configure capacity planning for each team to account for time off.

AnswerC

Azure DevOps allows each team in a shared project to have its own working days and non-working days under Team Settings, so teams in different time zones can use the same process while reflecting local calendars. This per-team calendar feeds backlog, sprint, and capacity views, making it the correct approach for a multinational company using a single project.

Why this answer

Azure DevOps allows each team to have its own working days configured in team settings, independent of the process template. This enables teams in different time zones to define their own non-working days without modifying the shared process, which would affect all teams using that process.

Exam trap

The trap here is that candidates confuse team-level settings (like working days) with process-level customizations, assuming that different working days require different process templates, when in fact Azure DevOps separates team configuration from process inheritance.

How to eliminate wrong answers

Option A is wrong because creating a custom process for each time zone is unnecessary and introduces administrative overhead; working days are a team-level setting, not a process-level setting. Option B is wrong because area paths are used for organizing work items by feature or component, not for configuring working days; working days are configured per team, not per area path. Option D is wrong because capacity planning accounts for individual time off and sprint capacity, not recurring weekly working days for the entire team.

Full explanation →

277

MCQmedium

Your company is a startup developing a mobile application with a small team of 5 developers. You use GitHub Free and want to implement a simple but effective branching strategy that supports continuous delivery. The team wants to release new features every week and be able to hotfix critical bugs quickly. They currently have a main branch and feature branches, but sometimes features are merged to main before they are fully tested, causing issues. You need to recommend a strategy that minimizes risk while keeping the process lightweight. The team does not want to use long-lived branches. What should you recommend?

A.Use a single main branch and create release branches for each weekly release; features are merged to release branches, then release branches are merged to main after testing.

B.Use GitHub Flow: developers create feature branches from main, open pull requests with required CI and at least one review, then merge to main. Hotfixes follow the same process.

C.Allow developers to commit directly to main but require all commits to pass CI and be reviewed by at least one other developer after the fact.

D.Adopt GitFlow with develop and release branches.

AnswerB

GitHub Flow is a lightweight, trunk-based model where main is always releasable: short-lived feature branches, mandatory CI and pull-request reviews enforce quality before integration, and hotfixes follow the identical pull-request path so fixes reach production quickly without long-lived branches or complex release processes.

Why this answer

GitHub Flow is the simplest and most effective strategy for a small team using GitHub Free that wants continuous delivery without long-lived branches. By requiring feature branches, pull requests with CI checks, and at least one review before merging to main, it ensures that all code is tested and reviewed before integration, preventing untested features from breaking main. Hotfixes follow the same lightweight process, allowing quick, safe patches without additional branch overhead.

Exam trap

The trap here is that candidates often overcomplicate branching strategies for small teams, mistakenly choosing GitFlow (Option D) or release branches (Option A) when GitHub Flow's simplicity and built-in CI/review gates perfectly address the need for risk mitigation without long-lived branches.

How to eliminate wrong answers

Option A is wrong because creating release branches for each weekly release adds unnecessary complexity and long-lived branches, contradicting the team's desire to avoid them; merging features to release branches before testing still risks untested code reaching production. Option C is wrong because allowing direct commits to main with post-hoc review violates the principle of protecting main from broken code; CI and review must happen before merge to prevent issues, not after. Option D is wrong because GitFlow introduces develop and release branches that are long-lived and overly complex for a 5-person startup doing weekly releases, adding overhead that contradicts the lightweight requirement.

Full explanation →

278

Multi-Selecteasy

Which TWO of the following are true about multi-stage pipelines in Azure Pipelines?

Select 2 answers

A.Stages can run in parallel if dependencies allow.

B.Each stage can contain only one job.

C.Each stage must run on the same agent.

D.Stages cannot have conditions.

E.They are defined in a single YAML file.

AnswersA, E

Stages in a multi-stage pipeline can execute in parallel when they have no dependencies on one another. You explicitly declare this by using `dependsOn: none` on the stage; otherwise, stages default to sequential execution based on implicit dependencies.

Why this answer

Azure Pipelines allows stages to run in parallel when their dependencies are configured appropriately. By default, stages run sequentially, but you can use the 'dependsOn' keyword to define dependencies, and if a stage has no dependencies on another, it can execute concurrently. This enables faster pipeline execution by running independent stages simultaneously.

Exam trap

The trap here is that candidates often assume stages must be sequential or share the same agent, but Azure Pipelines explicitly supports parallel execution and independent agent allocation per stage.

Full explanation →

279

MCQmedium

You receive a GitHub Dependabot alert as shown. The repository 'my-app' is internal. What is the best immediate action to mitigate the risk?

A.Dismiss the alert as it is a false positive

B.Create a private fork of the repository

C.Enable secret scanning on the repository

D.Update the lodash dependency to the latest patched version

AnswerD

Updating the lodash dependency to the latest patched version is the direct remediation, as the patched release resolves the specific vulnerability identified by the alert. This requires modifying the package manifest and lock file to reference a fixed version and then redeploying the application to ensure the vulnerable code is no longer in use.

Why this answer

The Dependabot alert indicates a known vulnerability in the lodash dependency. The best immediate action is to update lodash to the latest patched version, which directly resolves the security issue by applying the fix provided by the maintainers. This aligns with the principle of remediating vulnerabilities at the source rather than implementing workarounds.

Exam trap

The trap here is that candidates may confuse Dependabot alerts with secret scanning or think that changing repository visibility (forking) mitigates a dependency vulnerability, when the correct action is always to update the vulnerable package.

How to eliminate wrong answers

Option A is wrong because Dependabot alerts are based on GitHub's advisory database and are not false positives unless explicitly verified; dismissing without investigation ignores a real security risk. Option B is wrong because creating a private fork does not address the vulnerability; it only changes the repository's visibility and does not update the vulnerable dependency. Option C is wrong because secret scanning detects exposed secrets (e.g., tokens, keys), not vulnerable dependencies; it is unrelated to the lodash vulnerability.

Full explanation →

280

Multi-Selecteasy

Which TWO Azure DevOps features can be used to implement change management processes?

Select 2 answers

A.Test plans.

B.Release approval gates.

C.Audit logging.

D.Project wiki.

E.Code search.

AnswersB, C

Release approval gates are a change management control that require designated reviewers to explicitly approve a release before it proceeds to an environment, and can also enforce automated checks. By gating the promotion of builds across stages, they ensure only authorized changes are deployed.

Why this answer

Release approval gates (Option B) in Azure Pipelines allow you to enforce manual or automated checks before a release proceeds to a stage, implementing change management by requiring sign-offs or validation against external systems. Audit logging (Option C) captures a chronological record of changes to Azure DevOps resources, providing an immutable trail for compliance and change review processes.

Exam trap

The trap here is that candidates confuse features for documentation or testing (Test plans, Wiki) with those that enforce process controls, overlooking that change management requires approval workflows and audit trails, not just recording or searching content.

Full explanation →

281

Multi-Selecthard

Which THREE are valid strategies for managing configuration in a multi-environment CI/CD pipeline?

Select 3 answers

A.Store configuration in environment-specific YAML variable files.

B.Embed configuration values directly into the container image.

C.Hardcode configuration in pipeline scripts for each environment.

D.Use Azure Key Vault references in variable groups.

E.Use variable groups linked to Azure DevOps library.

AnswersA, D, E

Storing configuration in environment-specific YAML variable files (e.g., variables/dev.yml, variables/prod.yml) lets a single, generic pipeline definition consume the correct values per environment via template includes. This keeps your pipeline logic DRY while making each environment's settings explicit, code-reviewed, and easy to change without rebuilding images or rewriting pipelines.

Why this answer

Using variable groups, Key Vault references, and environment-specific YAML variable files are all valid. Storing config in the container image is not recommended because it couples the image to an environment. Hardcoding in scripts is bad practice.

Full explanation →

282

MCQmedium

You are designing a compliance strategy for Azure DevOps pipelines that deploy to production. The company policy requires that all production deployments must be reviewed by a security lead. Additionally, the deployment must use a specific release pipeline that has been pre-approved. How should you implement this?

A.Create a branch policy that requires the security lead to approve the pull request before merging.

B.Define a 'production' environment in Azure DevOps and configure an approval check that requires the security lead. Have the pipeline deploy to that environment.

C.Use a Classic release pipeline with a pre-deployment approval gate for the production stage.

D.Store the approved pipeline definition in a variable group and reference it in all pipelines.

AnswerB

Environment approval checks in YAML pipelines create a standardized, auditable manual gate before any deployment to the production environment. This integrates directly with pipeline runs, ensures the security lead explicitly approves each release, and provides full traceability, fulfilling the compliance requirement.

Why this answer

Azure DevOps environments allow you to define approval checks that must be satisfied before a deployment proceeds. By creating a 'production' environment and adding a pre-deployment approval check requiring the security lead, you enforce the mandatory review. The pipeline then deploys to that environment, ensuring only the pre-approved release pipeline is used.

Exam trap

The trap here is that candidates often confuse branch policies (which control code changes) with deployment approvals (which control release execution), leading them to choose Option A instead of the environment-based approval check in Option B.

How to eliminate wrong answers

Option A is wrong because a branch policy requiring pull request approval only controls code merging, not the actual deployment to production; it does not enforce a pre-approved release pipeline or a security lead review at deployment time. Option C is wrong because Classic release pipelines are legacy and do not integrate with modern YAML-based environments and their approval checks; the question implies a modern pipeline approach, and Classic pipelines lack the same granular environment-based approval controls. Option D is wrong because storing the pipeline definition in a variable group does not enforce any approval or review process; it merely centralizes configuration and does not prevent unauthorized deployments.

Full explanation →

283

MCQeasy

Your team uses Azure Pipelines to build a .NET Core application. You notice that the build takes too long because it restores NuGet packages every time. What is the best way to improve build performance?

A.Configure the build to use a self-hosted agent with previously restored packages

B.Use a private agent with a faster network connection

C.Use a Microsoft-hosted agent with a larger SKU

D.Enable the 'Cache' task to cache the NuGet packages folder

AnswerD

The Cache task (Cache@2) persists the NuGet packages folder (typically identified by the NUGET_PACKAGES environment variable) in a distributed cache such as Azure Blob Storage, keyed by a cache key like a hash of the .csproj files or packages.lock.json. On the first build the cache is populated; on subsequent builds the task downloads and unzips the folder into the agent workspace before the restore step, so NuGet finds needed packages locally and avoids network downloads. This reduces restore time significantly and works on both Microsoft-hosted and self-hosted agents, with cache recovery and invalidation handled automatically.

Why this answer

The best way to improve build performance is to cache the NuGet packages folder using the 'Cache' task in Azure Pipelines. This avoids re-downloading packages on each run. Option A (self-hosted agent) is not guaranteed to cache the packages folder across builds unless caching is explicitly configured.

Option B (faster network) may help but doesn't eliminate the restore time. Option C (larger SKU) improves CPU/memory but does not cache packages. Therefore, option D is correct.

Full explanation →

284

MCQeasy

Your team uses Microsoft Defender for Cloud to monitor Azure resources. You need to ensure that all Azure DevOps pipelines are scanned for security misconfigurations before deployment. Which integration should you enable?

A.Connect Azure DevOps to Microsoft Sentinel.

B.Enable the 'Defender for DevOps' integration in Microsoft Defender for Cloud.

C.Deploy Microsoft Intune policies to Azure DevOps agents.

D.Configure Microsoft Purview to scan Azure DevOps repositories.

AnswerB

Microsoft Defender for Cloud's Defender for DevOps integration provides actionable security recommendations for Azure DevOps and GitHub environments, scanning repositories and pipelines for misconfigurations, exposed secrets, and vulnerabilities in infrastructure-as-code templates. Enabling this integration directly addresses the need to monitor and harden Azure DevOps pipelines against security issues.

Why this answer

Microsoft Defender for Cloud includes a 'Defender for DevOps' integration that allows you to connect Azure DevOps environments and scan pipelines for security misconfigurations, such as Infrastructure as Code (IaC) template issues or exposed secrets, before deployment. This integration provides built-in security posture assessments and actionable recommendations directly within the Defender for Cloud dashboard, enabling shift-left security practices.

Exam trap

The trap here is that candidates confuse Microsoft Sentinel (a SIEM) with Defender for Cloud's DevOps scanning capabilities, or assume that a data governance tool like Purview can perform security configuration scanning, when in fact only the dedicated Defender for DevOps integration provides this specific pipeline scanning functionality.

How to eliminate wrong answers

Option A is wrong because Microsoft Sentinel is a SIEM/SOAR solution for security incident detection and response, not a tool for scanning pipeline configurations or IaC templates before deployment. Option C is wrong because Microsoft Intune is a mobile device management (MDM) and mobile application management (MAM) service for managing endpoints, not for scanning Azure DevOps pipelines for security misconfigurations. Option D is wrong because Microsoft Purview is a data governance and compliance solution focused on data classification and lineage, not on scanning DevOps pipelines for security misconfigurations.

Full explanation →

285

MCQhard

Refer to the exhibit. You have an availability set with two VMs. One VM shows a degraded availability state. What is the most likely impact on application availability?

A.The application will be fully resilient to both planned and unplanned maintenance events.

B.The application will be vulnerable to unplanned hardware failures that affect the degraded VM's host.

C.The application will experience downtime during planned maintenance events.

D.The application will continue to run without any impact because the other VM is healthy.

AnswerB

Correct. Because the degraded VM is not on fault-tolerant infrastructure, its host is not guaranteed to be isolated from hardware failures. If that host experiences an unplanned failure, the VM will shut down unexpectedly. Since the other VM cannot necessarily absorb the full workload, the application is vulnerable to downtime or degraded performance during such an event.

Why this answer

In an availability set, VMs are placed on different fault domains (separate racks with independent power, cooling, and network) to protect against unplanned hardware failures. If one VM shows a degraded availability state, it indicates that its underlying host or hardware is experiencing issues, making that VM vulnerable to failure. The other VM remains healthy, but the application is not fully resilient because the degraded VM could fail, reducing the application's capacity or causing partial downtime if the application requires both VMs to handle load.

Exam trap

The trap here is that candidates assume a single degraded VM has no impact because the other VM is healthy, but they overlook that the degraded VM is at risk of failure, which can reduce application resilience or capacity.

How to eliminate wrong answers

Option A is wrong because a degraded VM means the application is not fully resilient to unplanned maintenance events; the degraded VM's host is at risk, so the application is vulnerable to hardware failures affecting that host. Option C is wrong because planned maintenance events (e.g., host updates) are handled by Azure updating VMs in different update domains sequentially, so the application should not experience downtime during planned maintenance even with one degraded VM. Option D is wrong because while the other VM is healthy, the degraded VM may still fail, impacting application performance or causing partial downtime if the application relies on both VMs for redundancy or capacity.

Full explanation →

286

MCQeasy

Your Azure Pipelines build takes 45 minutes. You want to reduce build time by caching dependencies. Which task should you add to the pipeline?

A.PublishBuildArtifacts@1

B.CopyFiles@2

C.DownloadBuildArtifacts@0

D.Cache@2

AnswerD

Cache@2 is the dedicated Azure Pipelines task for caching dependencies. It saves a specified folder keyed by a cache key (like a hash of a lock file) and restores it on subsequent runs, which can eliminate repeated package restore operations and significantly reduce build duration, making it the correct solution for a 45-minute build.

Why this answer

Cache@2 is the correct task because it allows you to cache dependencies (e.g., npm packages, Maven artifacts) between pipeline runs, significantly reducing build time by avoiding re-downloading unchanged dependencies. This task stores and restores a cache keyed by a hash of the dependency files, enabling incremental builds.

Exam trap

The trap here is confusing artifact publishing/downloading with caching; candidates often pick PublishBuildArtifacts@1 thinking it caches dependencies, but it only stores build outputs for later use, not intermediate dependency downloads.

How to eliminate wrong answers

Option A is wrong because PublishBuildArtifacts@1 uploads build outputs (e.g., binaries) to Azure Pipelines, not caching dependencies to reduce build time. Option B is wrong because CopyFiles@2 simply copies files from source to destination within the agent, with no caching mechanism. Option C is wrong because DownloadBuildArtifacts@0 downloads previously published artifacts, which is unrelated to caching dependencies during the build process.

Full explanation →

287

MCQhard

Your company develops a microservices-based application deployed on Azure Kubernetes Service (AKS). The CI/CD pipeline uses Azure Pipelines. The development team has recently adopted a trunk-based development strategy where all feature work is done on short-lived branches that merge to main at least daily. The release pipeline must automatically deploy to a development environment on each commit to main, and to a staging environment after a manual approval. The staging environment is used for integration tests and must remain stable. You need to design the release pipeline strategy to support this workflow. What should you do?

A.Create a single release pipeline with one stage that deploys to both dev and staging simultaneously, and add a manual intervention task before staging deployment.

B.Create a single release pipeline with two stages: 'Dev' triggered automatically on successful build, and 'Staging' with a pre-deployment approval gate.

C.Create two separate release pipelines: one for dev with continuous deployment trigger, and one for staging with a manual trigger.

D.Create a single release pipeline with two stages: 'Dev' triggered automatically, and 'Staging' with a post-deployment approval gate and disable continuous deployment trigger.

AnswerB

A single release pipeline with a 'Dev' stage triggered automatically on successful build and a 'Staging' stage with a pre-deployment approval gate is the correct pattern. It promotes the same build artifact through environments, enables fast feedback in dev, and uses an approval gate to ensure staging deployments are authorized and traceable before they occur.

Why this answer

It creates a single release pipeline with two stages: 'Dev' triggered automatically on successful build, and 'Staging' with a pre-deployment approval gate. This meets the requirements: automatic deployment to dev on each commit to main, and manual approval before deploying to staging, keeping staging stable. Option A is wrong because deploying to both environments simultaneously bypasses the manual approval needed for staging.

Option C is wrong because separate pipelines add maintenance overhead and don't leverage pipeline stages for approval gates. Option D is wrong because a post-deployment approval gate would deploy to staging first, then require approval, which doesn't prevent deployment without approval. Also disabling continuous deployment trigger for staging would require manual promotion, which is not desired.

Full explanation →

288

MCQmedium

Your build pipeline uses a self-hosted agent in your on-premises network. The agent pool is configured to use the 'latest' agent version. Recently, a new version of the Azure Pipelines agent was released, and your builds started failing because the new agent requires .NET 6.0, which is not installed on the agent machine. What is the best way to prevent this issue in the future?

A.Configure the agent pool to use a specific agent version (e.g., '2.210.0') and test new versions in a separate pool before updating.

B.Switch to using Microsoft-hosted agents instead of self-hosted.

C.Disable automatic agent updates on the self-hosted agents.

D.Install .NET 6.0 on the agent machine to meet the new requirement.

AnswerA

Pinning the agent to a specific version prevents unexpected auto-updates from introducing breaking changes, ensuring consistent behavior across builds. By testing new versions in a separate pool first, you can validate compatibility with your pipelines and then control the rollout to production agents, giving you deterministic agent environments.

Why this answer

It decouples your production pipeline from automatic agent updates. By pinning the agent pool to a known-working version (e.g., '2.210.0'), you can validate new agent releases in a separate test pool before rolling them out. This prevents breaking changes—like a new .NET dependency—from impacting your builds without prior testing.

Exam trap

The trap here is that candidates confuse disabling automatic agent updates (which only prevents the agent binary from self-updating) with controlling which agent version the pipeline uses; the 'latest' pool setting overrides local update settings, so builds still fail even with updates disabled.

How to eliminate wrong answers

Option B is wrong because switching to Microsoft-hosted agents does not solve the root cause; it only moves the dependency management to Microsoft, and you would still face similar issues if Microsoft updates their agent image. Option C is wrong because disabling automatic updates only prevents the agent from updating itself, but the agent pool's 'latest' setting still forces the pipeline to download and use the newest agent version from the server, so builds would still fail. Option D is wrong because installing .NET 6.0 on the agent machine is a reactive fix that addresses only this specific version's requirement; it does not prevent future breaking changes from other new agent versions.

Full explanation →

289

MCQhard

Your organization uses GitHub and wants to enforce that all commits to the main branch are signed with a GPG key that is verified against the user's GitHub account. Additionally, you want to block unsigned commits even if the committer is a repository admin. Which configuration should you use?

A.Add a pre-receive hook that rejects unsigned commits.

B.Enable 'Require signed commits' and set 'Include administrators' to false.

C.Enable 'Require signed commits' and set 'Include administrators' to true.

D.Enable 'Require signed commits' and configure web commit signing.

AnswerC

Enabling 'Require signed commits' with 'Include administrators' set to true ensures that every commit pushed to the protected branch must have a valid signature, regardless of the pusher's role. This branch protection setting applies to all users, including repository administrators, thereby meeting the organization's goal of enforcing signed commits across the board on GitHub.com.

Why this answer

Enabling 'Require signed commits' in a GitHub branch protection rule, combined with setting 'Include administrators' to true, enforces that every commit pushed to the protected branch must be signed with a GPG key verified against the user's GitHub account, and this restriction applies even to repository administrators. This configuration blocks unsigned commits entirely, meeting the requirement to enforce signing for all users including admins.

Exam trap

The trap here is that candidates often confuse 'Include administrators' with a separate setting or assume that admins are always exempt, leading them to choose Option B, but the question explicitly requires blocking unsigned commits for all users including admins, so 'Include administrators' must be set to true.

How to eliminate wrong answers

Option A is wrong because pre-receive hooks are only available in GitHub Enterprise Server (self-hosted) and are not supported in GitHub.com (SaaS), so this option is not applicable for a standard GitHub organization. Option B is wrong because setting 'Include administrators' to false would exempt repository administrators from the signing requirement, allowing them to push unsigned commits, which violates the requirement to block unsigned commits even for admins. Option D is wrong because 'web commit signing' is a feature for automatically signing commits made via the GitHub web interface, but it does not enforce signing for commits pushed via Git CLI or other tools, and it does not block unsigned commits from being pushed.

Full explanation →

290

MCQeasy

Your team uses Git and wants to ensure that all commits follow a consistent message format. Which approach should you use?

A.Add a step in Azure Pipelines to validate commit messages

B.Use a client-side Git hook (commit-msg) to validate the message

C.Create a GitHub Actions workflow that checks commit messages on push

D.Configure a branch policy in Azure Repos to enforce commit message format

AnswerB

A client-side commit-msg hook executes on the developer's machine before the commit is finalized, allowing the message to be validated against a pattern and abort the commit if it does not conform. This is the only mechanism that prevents an invalid commit from ever existing in the local repository.

Why this answer

A client-side Git hook, specifically the commit-msg hook, runs locally on the developer's machine before the commit is finalized, allowing immediate validation of the commit message format. This ensures that every commit adheres to the team's convention at the point of creation, without relying on server-side enforcement or pipeline execution.

Exam trap

The trap here is that candidates often assume server-side enforcement (branch policies or pipeline validation) is the only way to enforce commit message standards, overlooking the fact that client-side hooks provide immediate, local validation before the commit is ever recorded.

How to eliminate wrong answers

Option A is wrong because adding a step in Azure Pipelines validates commit messages only after the code is pushed to the remote repository, which is too late to prevent non-compliant commits from being created locally and pushed. Option C is wrong because a GitHub Actions workflow that checks commit messages on push also runs after the push event, meaning non-compliant commits can still be pushed before the workflow detects the issue. Option D is wrong because branch policies in Azure Repos can enforce certain conditions (e.g., required reviewers, build validation) but do not natively support validating commit message format; they cannot inspect or reject commits based on message content.

Full explanation →

291

MCQhard

Refer to the exhibit. You have configured a Conditional Access policy in Microsoft Entra ID to require MFA for Azure DevOps. However, users report that they can still access Azure DevOps without MFA when using a PAT for authentication. What is the most likely reason?

A.The policy should include 'Require device to be marked as compliant'.

B.PATs are not subject to Conditional Access policies because they use legacy authentication.

C.The policy should be scoped to 'All cloud apps' instead of just Azure DevOps.

D.The Conditional Access policy is not enabled.

AnswerB

PATs are considered legacy authentication and do not satisfy the MFA requirement; they are not evaluated by Conditional Access.

Why this answer

B is correct because Personal Access Tokens (PATs) in Azure DevOps are considered legacy authentication tokens. Conditional Access policies in Microsoft Entra ID do not evaluate requests made using legacy authentication protocols, including PATs, OAuth device code flow, or IMAP/POP. Therefore, even if a Conditional Access policy requires MFA for Azure DevOps, users authenticating with a PAT bypass the policy entirely.

Exam trap

The trap here is that candidates may assume Conditional Access policies apply to all authentication methods equally, not realizing that legacy authentication protocols like PATs, IMAP, and POP are explicitly excluded from policy evaluation unless legacy authentication is blocked at the tenant level.

How to eliminate wrong answers

Option A is wrong because requiring a device to be marked as compliant is a separate grant control that does not address the fundamental issue of PATs bypassing Conditional Access; the policy already requires MFA but is not enforced for PAT-based requests. Option C is wrong because scoping the policy to 'All cloud apps' would not change the behavior—PATs are still legacy authentication and would continue to bypass Conditional Access regardless of the app scope. Option D is wrong because the question states the policy is configured, and if it were not enabled, users would not be prompted for MFA at all, but the specific report is that PATs allow access without MFA, which points to the legacy authentication bypass, not the policy being disabled.

Full explanation →

292

MCQmedium

Your team uses Azure Pipelines to deploy a web app. They want to automatically roll back the deployment if the post-deployment smoke tests fail. What is the recommended approach?

A.Define an approval gate that requires manual sign-off after deployment.

B.Use a deployment gate with a monitoring tool that automatically initiates a rollback if health check fails.

C.Set up a manual intervention step in the pipeline to decide rollback.

D.Configure a release variable that toggles between deployment slots.

AnswerB

Gates can evaluate health and trigger rollback.

Why this answer

Azure Pipelines supports deployment gates that can integrate with monitoring tools (e.g., Azure Monitor, Application Insights) to evaluate health metrics after deployment. If the gate detects a failure (e.g., a smoke test health check fails), it can automatically trigger a rollback to the previous stable version, ensuring zero manual intervention and faster recovery.

Exam trap

The trap here is that candidates often confuse manual approval gates or manual intervention steps with automated rollback, failing to recognize that only a deployment gate with a monitoring tool can provide the continuous health evaluation and automatic rollback required for a fully automated recovery process.

How to eliminate wrong answers

Option A is wrong because an approval gate with manual sign-off does not automate rollback; it only pauses the pipeline for human approval, which defeats the goal of automatic rollback on smoke test failure. Option C is wrong because a manual intervention step requires a human to decide and execute the rollback, which is not automated and introduces delay and potential error. Option D is wrong because a release variable that toggles between deployment slots only switches traffic between slots but does not automatically trigger a rollback based on smoke test results; it requires manual or separate logic to detect failure and toggle the variable.

Full explanation →

293

MCQhard

Your Azure DevOps release pipeline deploys to Azure Kubernetes Service (AKS). You need to ensure that the deployment is rolled back automatically if the health checks fail within 5 minutes after deployment. The AKS cluster uses a canary deployment strategy. What should you use?

A.Use an Azure CLI task to run 'kubectl rollout undo' in a post-deployment script.

B.Use a Helm upgrade task with --wait and --timeout flags.

C.Use the Kubernetes manifest task with 'canary' deployment strategy and configure 'stabilityCheck' and 'rollback' settings.

D.Use the Kubectl task with a 'rollback' subcommand condition.

AnswerC

The Kubernetes manifest task in Azure Pipelines supports a canary deployment strategy where you can specify 'stabilityCheck' to validate the canary version's health and 'rollback' settings to automatically revert to the last stable version if the canary fails the specified criteria, enabling automated rollback on health failure.

Why this answer

The Kubernetes manifest task in Azure DevOps supports a 'canary' deployment strategy with built-in 'stabilityCheck' and 'rollback' settings. This allows you to define a health check window (e.g., 5 minutes) and automatically trigger a rollback if the canary pods fail the stability checks, meeting the requirement without custom scripting.

Exam trap

The trap here is that candidates often assume any 'rollback' command or flag (like kubectl rollout undo or Helm --wait) will suffice, but they miss that the question specifically requires automatic rollback based on health checks within a 5-minute window after deployment, which only the Kubernetes manifest task's canary strategy with stabilityCheck and rollback settings provides.

How to eliminate wrong answers

Option A is wrong because using an Azure CLI task with 'kubectl rollout undo' in a post-deployment script requires manual logic to detect health check failures and does not integrate with the canary strategy's automatic stability checks. Option B is wrong because the Helm upgrade task with --wait and --timeout flags only waits for the deployment to reach a ready state during the upgrade, but does not provide a configurable post-deployment health check window or automatic rollback on failure. Option D is wrong because the Kubectl task with a 'rollback' subcommand condition is a generic command that lacks the canary-specific stability check and automatic rollback orchestration provided by the Kubernetes manifest task.

Full explanation →

294

MCQeasy

Your team uses GitHub repositories and wants to ensure that all code changes are signed by a verified contributor before merging. Which branch protection rule should you enable?

A.Require signed commits

B.Require pull request reviews before merging

C.Require linear history

D.Restrict who can push to matching branches

AnswerA

Requiring signed commits enforces a branch protection rule that every commit on the protected branch must be signed with a GPG or S/MIME key that GitHub can verify; unsigned commits are blocked, ensuring cryptographically verified authorship.

Why this answer

Requiring signed commits ensures that each commit is cryptographically verified using a GPG or S/MIME key linked to the contributor's GitHub account. This enforces non-repudiation and confirms the identity of the author, directly addressing the requirement that all code changes be signed by a verified contributor before merging.

Exam trap

The trap here is confusing identity verification (signed commits) with access control (restrict pushes) or process approval (pull request reviews), leading candidates to pick a rule that controls who can push rather than what cryptographic proof is required.

How to eliminate wrong answers

Option B is wrong because requiring pull request reviews before merging enforces code review approval, not cryptographic signing of commits. Option C is wrong because requiring a linear history enforces a clean, non-merge-commit history but does not verify the identity or signing of commits. Option D is wrong because restricting who can push to matching branches controls write access via teams or users, but does not enforce that commits are signed or verified.

Full explanation →

295

MCQeasy

You need to create a pipeline that triggers only when changes are made to files in the 'src/api' folder. Which trigger configuration should you use?

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

B.trigger: paths: exclude: - 'src/api/*'

C.trigger: tags: include: - 'v*'

D.trigger: paths: include: - 'src/api/*'

AnswerD

The `paths` filter with `include` is correct because it defines a file-path allowlist: the pipeline only triggers when a commit changes files under the `src/api/*` path. This ensures the pipeline runs exclusively when modifications occur in that directory, satisfying the requirement to trigger only on changes to `src/api`.

Why this answer

The `trigger: paths: include: - 'src/api/*'` configuration tells Azure Pipelines to only trigger the pipeline when changes are detected in files matching that path pattern. This is the standard way to scope pipeline triggers to specific folders or file patterns in YAML pipelines, ensuring that unrelated changes elsewhere in the repository do not start the pipeline.

Exam trap

The trap here is that candidates often confuse `include` with `exclude` or forget that path filters require explicit `include` statements to restrict triggers, leading them to pick option B which does the opposite of what is asked.

How to eliminate wrong answers

Option A is wrong because it only filters by branch (main) and does not restrict triggers to the 'src/api' folder, so any change on main would trigger the pipeline. Option B is wrong because it uses `exclude` with the path `src/api/*`, which explicitly prevents the pipeline from triggering when changes are made to that folder, the opposite of the requirement. Option C is wrong because it uses a tag trigger (`tags: include: - 'v*'`), which only fires when a tag matching the pattern is pushed, not when file changes occur in the 'src/api' folder.

Full explanation →

296

MCQeasy

You are designing a release pipeline for a .NET application. The pipeline must deploy to multiple environments (Dev, Test, Prod) with manual approval at each stage. Which release trigger should you configure for the production stage?

A.Pull request trigger from the main branch.

B.Continuous deployment trigger after a successful build.

C.Manual trigger with pre-deployment approvals.

D.Scheduled trigger set to run nightly.

AnswerC

A manual trigger requires a user to explicitly initiate the release, and adding pre-deployment approvals ensures that a designated approver must authorize the deployment before it proceeds. This combination gives full human control over when the release starts and enforces a review step, which directly supports the design requirement.

Why this answer

The requirement specifies manual approval at each stage, and for the production stage, a manual trigger with pre-deployment approvals ensures that deployments only occur after explicit human authorization. This aligns with the need for controlled, gated releases to production, preventing automatic or scheduled deployments that bypass approval.

Exam trap

The trap here is that candidates confuse build triggers (like PR or continuous integration) with release triggers, mistakenly applying build automation concepts to production deployment stages where manual approval is required.

How to eliminate wrong answers

Option A is wrong because a pull request trigger from the main branch is used for build validation or testing, not for release deployment triggers; it would initiate a build or test run on PR creation, not a production deployment with approvals. Option B is wrong because continuous deployment trigger after a successful build would automatically deploy to production without manual approval, violating the requirement for manual approval at each stage. Option D is wrong because a scheduled trigger set to run nightly would deploy automatically on a fixed schedule, bypassing the required manual approval and pre-deployment gates for production.

Full explanation →

297

MCQmedium

Your organization uses Azure DevOps for a multi-tier web application. The application consists of a React frontend, a Node.js API, and a SQL database. The security team has mandated the following: (1) All code changes must be scanned for secrets before merging to the main branch. (2) Infrastructure-as-code templates (ARM) must be validated for security compliance before deployment. (3) Production deployments must use a service connection with a managed identity that has only the required permissions. You have set up a CI/CD pipeline with two stages: Build and Release. The Build stage runs on pull requests and the Release stage deploys to a production environment. Recently, a developer accidentally committed a secret (API key) to a configuration file. The secret was not caught by the pipeline, and the code was merged to main. You need to prevent this in the future. What should you do?

A.Configure a branch policy to require at least two reviewers on pull requests to the main branch.

B.Implement a manual approval gate on the Release stage to review each deployment for secrets.

C.Use a pipeline decorator to inject a validation step that runs Azure Policy on the code repository.

D.Add a 'Credential Scanner' task to the Build pipeline and configure it to fail the build if any secrets are found. Also, move all secrets to Azure Key Vault and reference them via variable groups.

AnswerD

Adding a Credential Scanner task to the Build pipeline and configuring it to fail the build when secrets are found automatically blocks hardcoded credentials from being merged into the codebase. Moving secrets to Azure Key Vault and referencing them via variable groups centralizes secret management and removes the need to store sensitive values in source code.

Why this answer

It directly addresses the root cause: secrets were not being scanned before merge. The Credential Scanner task (part of Microsoft Security Code Analysis) scans for hardcoded secrets and can fail the build, preventing the merge. Moving secrets to Azure Key Vault and referencing them via variable groups (linked to the vault) ensures secrets are never stored in the repository, eliminating the risk of accidental commits.

Exam trap

The trap here is that candidates may confuse Azure Policy (which governs Azure resource compliance) with code scanning tools, or mistakenly think that manual reviews or approval gates are sufficient to catch secrets before merge, when automated scanning is required by the mandate.

How to eliminate wrong answers

Option A is wrong because requiring two reviewers does not prevent a secret from being committed; reviewers may not catch a secret in a configuration file. Option B is wrong because a manual approval gate on the Release stage only catches secrets after they have already been merged to main, which violates the mandate to scan before merging. Option C is wrong because Azure Policy is used for governance of Azure resources (e.g., ARM template compliance), not for scanning code repositories for secrets; a pipeline decorator cannot run Azure Policy on a Git repository.

Full explanation →

298

MCQhard

Your company uses GitHub and wants to implement a compliance framework that requires signed commits for all repositories. Developers use various IDEs and Git clients. What is the best way to enforce signed commits across the organization?

A.Set the repository to 'Require pull request reviews before merging' and rely on reviewers to check commit signatures.

B.Ask developers to configure GPG keys and sign commits manually.

C.Enable 'Require signed commits' in the branch protection rules for the default branch.

D.Use a GitHub Action that fails if commits are unsigned.

AnswerC

Enabling 'Require signed commits' in branch protection rules for the default branch enforces at the server level that every commit pushed to that branch must have a valid, verified signature. If a commit is unsigned or the signature cannot be verified, the push is rejected before the branch is updated. This is the correct, enforceable technical control.

Why this answer

GitHub allows repository administrators to enable 'Require signed commits' in branch protection rules. Option A is incorrect because it is not enforceable; commits can be unsigned. Option B is incorrect because it only encourages, not enforces.

Option D is incorrect because it does not enforce signing.

Full explanation →

299

MCQmedium

Your Azure Pipelines build fails intermittently due to transient network errors when downloading NuGet packages. You want to implement retry logic. What is the best approach?

A.Add a PowerShell task that wraps the NuGet restore in a retry loop

B.Increase the number of parallel jobs to average out failures

C.Use a deployment group to deploy the build to a staging environment

D.Configure a build retention policy to automatically retry failed builds

AnswerA

Wrapping the NuGet restore in a PowerShell task enables you to implement a retry loop that checks exit codes and repeats the restore operation on transient failures (e.g., HTTP timeouts or package source throttling), while allowing the build to fail after a defined number of attempts. This directly addresses the intermittent nature of the failure without requiring changes to the pipeline's parallelism or deployment topology.

Why this answer

Adding a PowerShell task that wraps the NuGet restore command in a retry loop directly addresses transient network failures by reattempting the download. This approach is lightweight, customizable (e.g., using `Start-Sleep` between retries), and does not require changing pipeline architecture or relying on external infrastructure.

Exam trap

The trap here is that candidates confuse build-level retry mechanisms (like retention policies or parallel jobs) with step-level retry logic, assuming Azure Pipelines automatically handles transient failures when it does not.

How to eliminate wrong answers

Option B is wrong because increasing parallel jobs does not retry a failed step; it only runs more builds concurrently, which may increase load on the network and exacerbate failures. Option C is wrong because deployment groups are used for deploying to target environments, not for handling transient build-time failures like NuGet restore errors. Option D is wrong because build retention policies control how long artifacts are kept, not how failed builds are retried; Azure Pipelines does not automatically retry builds based on retention settings.

Full explanation →

300

MCQeasy

Your team uses GitHub and wants to automatically detect exposed credentials in code. Which GitHub feature should you enable?

A.Code scanning.

B.Dependabot.

C.Secret scanning.

D.GitHub Actions.

AnswerC

Secret scanning is GitHub's native security feature that applies pattern recognizers—curated definitions provided by GitHub and partner organizations—to identify known credential formats such as API keys, access tokens, OAuth secrets, and private keys across the repository, including new pushes and existing history. When an Expo API key is committed, secret scanning triggers an immediate alert and, if push protection is enabled for the repository, even blocks the push itself to prevent the secret from ever being stored. This detection is format-specific and proactive, giving organizations a chance to revoke the exposed key before attackers can exploit it, which is exactly the correct mechanism for identifying an exposed Expo API key.

Why this answer

Secret scanning is the correct GitHub feature because it is specifically designed to automatically detect exposed credentials, tokens, and other secrets in code repositories. It scans for known patterns of sensitive data, such as AWS keys, GitHub tokens, and private keys, and alerts repository administrators when a match is found. This directly addresses the requirement to detect exposed credentials without needing custom workflows or additional configuration.

Exam trap

The trap here is that candidates often confuse Code scanning (which finds code vulnerabilities) with Secret scanning (which finds credentials), because both are security-related features under GitHub's Advanced Security suite, but they serve fundamentally different purposes.

How to eliminate wrong answers

Option A is wrong because Code scanning uses CodeQL to analyze code for security vulnerabilities and bugs, not specifically to detect exposed credentials or secrets. Option B is wrong because Dependabot is focused on monitoring and updating dependencies for known vulnerabilities, not scanning for hardcoded secrets in the codebase. Option D is wrong because GitHub Actions is a CI/CD automation platform that can run custom workflows, but it does not natively detect exposed credentials; you would need to integrate a third-party secret scanning tool or write custom logic to achieve this.

Full explanation →

Microsoft Azure DevOps Engineer Expert AZ-400 (AZ-400) — Questions 226–300