Courseiva

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

913 questions total · 13pages · All types, answers revealed

Take a mock examExam hub
Page 1

Page 2 of 13

Page 3
76
MCQmedium

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

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

Caching avoids re-downloading the SDK each run, reducing build time.

Why this answer

Option B is correct because using a Microsoft-hosted agent with caching for the .NET SDK avoids downloading it each time, significantly reducing build time. Option A is wrong because more agents won't speed a single job. Option C is wrong because moving to Linux doesn't address SDK download overhead.

Option D is wrong because self-hosted agents require maintenance and may not reduce time if SDK still downloads.

Full explanation →
77
Multi-Selectmedium

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

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

Needs to communicate with Azure Pipelines service.

Why this answer

Options A and C are correct. A: The agent must be registered with the agent pool. C: The agent must have network access to Azure Pipelines.

Option B is wrong because the agent can run on any OS. Option D is wrong because the agent can be registered to any pool. Option E is wrong because the agent can be on any machine.

Full explanation →
78
MCQhard

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

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

Canary gradually shifts traffic to the new version and promotes if health checks pass.

Why this answer

Option B is correct because the 'canary' deployment strategy in GitHub Actions gradually shifts traffic to the new version and promotes if health checks pass. Option A is wrong because 'blue-green' switches all traffic at once. Option C is wrong because 'rolling' updates instances in batches but doesn't use canary traffic shifting.

Option D is wrong because 'recreate' replaces all instances at once.

Full explanation →
79
MCQmedium

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

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

git-tfs preserves history and is designed for TFVC to Git migration.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
80
MCQmedium

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

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

Correct: MAVEN_OPTS sets JVM options for Maven, increasing heap space.

Why this answer

Option D is correct because you can set JAVA_OPTS to increase heap size for the Maven build. Option A is wrong because using a self-hosted agent doesn't directly increase heap; you would still set JAVA_OPTS. Option B is wrong because parallel jobs would increase resource usage, not fix memory.

Option C is wrong because the variable is for Gradle, not Maven.

Full explanation →
81
MCQmedium

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

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

Allows reuse of tasks and phased rollout with tags.

Why this answer

Option A is correct because a deployment group job with deployment group tags allows targeting regions and reusing tasks. Option B is incorrect because each region would need separate stages. Option C is incorrect because environment-based strategy requires separate environments.

Option D is incorrect because parallel deployment does not support phased rollout with approvals.

Full explanation →
82
Multi-Selecthard

Your release pipeline uses a deployment group to deploy to multiple on-premises servers. You need to ensure that only healthy servers receive the deployment and that deployment history is retained. Which THREE actions should you include?

Select 3 answers
A.Set a retention policy to keep deployment history for a specified number of days.
B.Tag each server with its role (e.g., web, API).
C.Configure health checks in the deployment group to verify server status before deployment.
D.Use a single deployment group for all servers.
E.Disable parallel deployment to avoid conflicts.
AnswersA, B, C

Retention policy preserves deployment history.

Why this answer

Option A is correct because tagging servers by role enables targeted deployments. Option C is correct because deployment groups include health checks. Option E is correct because retention policies preserve history.

Options B and D are not needed.

Full explanation →
83
MCQhard

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

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

Only the dist folder is published; node_modules are missing.

Why this answer

Option B is correct because the App Service on Linux runs the app directly from the `dist` folder, but the `node_modules` folder is not included in the published artifact since only the `dist` folder is published. Hence, modules outside `dist` are missing. Option A is wrong because the task does not modify `package.json`.

Option C is wrong because Kudu syncs all files, but the root issue is missing modules. Option D is wrong because the task does not run `npm install` by default.

Full explanation →
84
MCQeasy

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

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

Scans open-source dependencies for vulnerabilities.

Why this answer

Option A is correct because WhiteSource Bolt (Mend) is a popular extension for open-source vulnerability scanning. Option B is wrong because SonarQube is for code quality, not dependency scanning. Option C is wrong because Azure Policy is for compliance of Azure resources.

Option D is wrong because GitHub Advanced Security is for GitHub repos, not Azure Repos.

Full explanation →
85
MCQhard

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

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

Rulesets can enforce file presence and content.

Why this answer

Repository rulesets in GitHub Enterprise allow you to centrally enforce policies across all repositories in an organization, including requiring that a CODEOWNERS file exists and matches a specific pattern. This ensures consistency without manual intervention or per-repo configuration, leveraging GitHub's native repository management capabilities.

Exam trap

The trap here is that candidates confuse organization-level CODEOWNERS (which doesn't exist) with repository rulesets, or assume a post-push check (like a workflow) is equivalent to a pre-push enforcement mechanism.

How to eliminate wrong answers

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

Full explanation →
86
Multi-Selectmedium

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

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

Shallow clones fetch only recent history, reducing clone time.

Why this answer

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

Exam trap

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

Full explanation →
87
MCQhard

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

A.Enable 'Secret scanning' and 'Push protection' for the repository.
B.Add the secret to the 'Secret scanning' exclusion list.
C.Instruct developers to avoid using 'echo' and use '::set-output' instead.
D.Use the 'actions/secrets' action to mask secrets automatically.
AnswerA

These features detect and block secrets in code and logs.

Why this answer

Option D is correct because enabling 'Secret scanning' and 'Push protection' in the repository automatically blocks secrets from being committed or printed in logs. Option A would mask the secret but only after it's already been printed. Option B is impractical and error-prone.

Option C is not a built-in feature.

Full explanation →
88
MCQeasy

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

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

This is the correct interpretation of the command.

Why this answer

Option D is correct because the command runs the pipeline named 'MyPipeline' on the 'main' branch, with a variable 'myVar' set to 'value1'. Option A is wrong because it runs the pipeline, does not create one. Option B is wrong because it runs on the 'main' branch, not all branches.

Option C is wrong because it sets a variable, not a secret.

Full explanation →
89
MCQmedium

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

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

Automatically collects JVM metrics.

Why this answer

Option A is correct because Application Insights Java agent automatically collects JVM metrics and can be correlated with deployment markers. Option B is wrong because App Service logs don't include JVM metrics. Option C is wrong because diagnostic settings are for Azure resource logs, not JVM.

Option D is wrong because Visual Studio profiler is not a production monitoring tool.

Full explanation →
90
MCQhard

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

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

This enforces both requirements efficiently: the scan runs in CI, and branch policies ensure reviews. Using Copilot for commit messages improves traceability without overhead.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
91
Multi-Selecthard

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

Select 3 answers
A.Enable soft-delete and purge protection on the Key Vault.
B.Use a resource lock on the Key Vault to prevent deletion.
C.Use a Key Vault access policy to grant developers full access.
D.Use Managed Identity to authenticate Azure Pipelines to Key Vault.
E.Configure Key Vault certificate auto-rotation with a specified lifetime.
AnswersA, D, E

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

Why this answer

Key Vault supports automatic certificate rotation with expiration dates. Soft-delete and purge protection prevent permanent deletion. Managed identities allow pipelines to access Key Vault without secrets in code.

Resource locks prevent accidental deletion but not rotation or auditing. Access policies or RBAC control access but don't enable rotation.

Full explanation →
92
MCQmedium

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

A.Code scanning alerts in GitHub
B.Azure Policy for Pipelines
C.Branch protection rule with required status check
D.Pipeline security gate
AnswerC

Branch protection rules can enforce that a security scan pipeline passes before merging.

Why this answer

Option B (Branch protection rule with status check) is correct because you can add a required status check that runs a security scan pipeline, and the PR cannot be merged if the check fails. Option A is for Azure resources, not pipelines. Option C is for code scanning in GitHub, not Azure Pipelines.

Option D is not a real feature.

Full explanation →
93
MCQhard

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

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

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

Why this answer

Option C is correct because GitHub Actions supports environment protection rules, including required reviewers, and environment variables can control deployment steps. Option A is incorrect because matrix builds are for parallel builds, not sequential approvals. Option B is incorrect because workflow run is not a step.

Option D is incorrect because manual triggers don't enforce sequential deployment.

Full explanation →
94
MCQmedium

Your team uses a monorepo in Azure Repos. You want to enforce that every PR to the main branch includes a work item link and a specific label. Which branch policy should you configure?

A.Comment requirements
B.Check for linked work items
C.Required status check (using a custom build pipeline)
D.Build validation
AnswerC

A custom build pipeline can verify work item links and labels, and the required status check enforces it.

Why this answer

Option C is correct because Azure Repos branch policies allow you to enforce 'Required status checks' that can invoke a custom build pipeline. This pipeline can run a script to verify that the PR contains a work item link and a specific label, and fail the check if those conditions are not met. The other options either lack the ability to enforce both conditions or are not designed for custom validation logic.

Exam trap

The trap here is that candidates often confuse 'Build validation' with 'Required status check', not realizing that 'Build validation' only ensures the code compiles and tests pass, while 'Required status check' is the policy type that allows you to enforce a custom pipeline that can validate arbitrary PR metadata like work item links and labels.

How to eliminate wrong answers

Option A is wrong because 'Comment requirements' only enforce that a minimum number of comments are posted on the PR, not that specific metadata like work item links or labels are present. Option B is wrong because 'Check for linked work items' only verifies that at least one work item is linked to the PR, but it cannot enforce the presence of a specific label. Option D is wrong because 'Build validation' triggers a build pipeline to run and pass, but it does not inherently check for work item links or labels unless you explicitly code that logic into the pipeline; however, the question asks for the branch policy to configure, and 'Required status check' is the policy type that allows you to require a custom pipeline check, whereas 'Build validation' is a separate policy that only ensures the build succeeds without the ability to enforce metadata conditions by itself.

Full explanation →
95
MCQmedium

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

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

Playbook can disable the service connection and notify.

Why this answer

Option C is correct because Sentinel playbooks (based on Logic Apps) can automate responses, including disabling service connections via Azure DevOps REST API. Option A is wrong because alerts alone don't run actions. Option B is wrong because service hooks trigger on events, not Sentinel alerts.

Option D is wrong because Azure Policy can't disable service connections.

Full explanation →
96
MCQeasy

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

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

Shows agent status and last contact time.

Why this answer

Option B is correct because the Agent Health dashboard shows agent status and last communication time. Option A is wrong because Pipeline Run Analytics focuses on runs, not agents. Option C is wrong because Test Analytics is for test results.

Option D is wrong because Release Analytics is for release pipelines.

Full explanation →
97
MCQhard

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

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

The policy audits for allowed file extensions.

Why this answer

Option A is correct because the policy audits that only specific secure file types are allowed. Option B is wrong because it does not restrict number of files. Option C is wrong because it does not require encryption.

Option D is wrong because it does not restrict pipeline use.

Full explanation →
98
MCQhard

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

A.Use a pre-commit hook to detect secrets and allow developers to bypass it.
B.Implement a GitHub Actions workflow that scans for secrets and fails the push.
C.Enable secret scanning for all repositories, then manually disable it for test repositories.
D.Configure secret scanning with custom patterns and use the 'secret_scanning_push_protection' setting with an allow-list for test repositories.
AnswerD

This allows exceptions while blocking real secrets.

Why this answer

Option B is correct because GitHub secret scanning can be configured with custom patterns and allow-listed repositories. Option A is incorrect because disabling for test repos would be manual and not scalable. Option C is incorrect because pre-commit hooks are client-side and not enforceable server-side.

Option D is incorrect because GitHub Actions cannot directly block pushes; secret scanning is a separate feature.

Full explanation →
99
MCQhard

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

A.Set the deployment queue to 'Deploy one at a time' with 'Exclusive lock'.
B.Configure a pre-deployment condition that checks the current deployment status.
C.Add a manual approval step before each deployment.
D.Set the deployment queue to 'Deploy all in parallel' with 'Number of parallel deployments' set to 1.
AnswerA

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

Why this answer

Option A is correct because deployment groups support 'Exclusive lock' deployment queue settings to prevent concurrent deployments to the same target. Option B is wrong because parallel deployment settings control the overall number of parallel deployments, not per-target locking. Option C is wrong because stage-level pre-deployment conditions do not enforce per-target locking.

Option D is wrong because environment-level approvals are for manual intervention, not concurrency control.

Full explanation →
100
MCQmedium

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

A.Set the environment's 'Exclusive lock' check to enabled.
B.Set the pipeline's 'Maximum number of parallel deployments' to 1.
C.Configure a required template check on the environment.
D.Add a manual approval check on the environment.
AnswerA

Exclusive lock prevents other pipeline runs from deploying to the same environment simultaneously.

Why this answer

Option C is correct because exclusive lock check ensures only one pipeline runs at a time for a given environment. Option A is incorrect because manual approval does not prevent concurrency. Option B is incorrect because environment checks only evaluate conditions, not concurrency.

Option D is incorrect because deployment queue settings with 'Number of parallel deployments' set to 1 provide exclusive lock, but the correct answer is exclusive lock resourced by environment.

Full explanation →
101
Multi-Selecthard

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

Select 3 answers
A.Configure branch protection rules requiring status checks to pass
B.Store secrets in a .env file committed to the repository
C.Require commit signing using GPG keys
D.Enable GitHub secret scanning for the repository
E.Use pre-commit hooks to scan for secrets before commits
AnswersA, D, E

Status checks enforce code quality gates.

Why this answer

Option A is correct because branch protection rules enforce required status checks (e.g., CI builds, code reviews) before merging, which prevents code that fails quality gates from entering protected branches. This directly supports code quality by ensuring only validated changes are merged.

Exam trap

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

Full explanation →
102
MCQmedium

Your team uses GitHub Actions for CI/CD. You have a workflow that builds and deploys a Node.js application to Azure App Service. The workflow uses the 'azure/webapps-deploy@v2' action. You notice that the deployment often fails with a 403 error during the 'Deploy to Azure' step. The error message indicates that the publish profile credentials are invalid. You have stored the publish profile as a secret in the repository. The secret name is AZURE_WEBAPP_PUBLISH_PROFILE. The workflow step uses the secret correctly. However, the secret value might have been rotated. You need to ensure that the deployment works reliably. What should you do?

A.Use OpenID Connect with a service principal instead of publish profile.
B.Check the workflow run log for the exact error and update the secret accordingly.
C.Replace the 'azure/webapps-deploy' action with 'Azure/cli' action and run az webapp deployment source config-zip.
D.Recreate the secret in GitHub by deleting and adding it again with the same value.
AnswerA

OIDC provides token-based authentication that does not rely on static secrets.

Why this answer

Option C is correct because using a service principal with a managed identity or Azure AD application is more secure and reliable than publish profile. Option A is wrong because checking the log does not fix the issue. Option B is wrong because using a different action still relies on the same secret.

Option D is wrong because the secret is already defined; recreating it does not guarantee it will work if the underlying credentials are rotated.

Full explanation →
103
MCQhard

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

A.Use the 'Azure App Service manage' task to swap slots after deployment.
B.Set the 'Slot' parameter to 'staging' and enable 'Swap with production' in the task.
C.Use the 'Azure CLI' task to run 'az webapp deployment slot swap' after deployment.
D.Configure the deployment task to deploy to staging and then use a separate task to swap.
AnswerB

This automatically swaps after deployment with warmup.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
104
MCQmedium

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

A.Apply a label to PRs that touch certain files and require review
B.Add a task in the CI pipeline that checks if the README was modified
C.Use a repository template with a mandatory README file structure
D.Require a pull request comment that confirms README update
AnswerC

Templates provide a starting point and can include a README that developers must fill.

Why this answer

Option C is correct because using a repository template with a mandatory README file structure enforces a consistent baseline for all new repositories, ensuring that a README is always present and follows a predefined format. This approach addresses the root cause—developers forgetting to update the README—by making the README an integral part of the repository creation process, rather than relying on post-hoc checks or manual reviews. In Azure Repos, repository templates can include required files and folder structures, which are automatically applied when a new repository is created from the template, thereby preventing the omission of the README from the start.

Exam trap

The trap here is that candidates often overestimate the effectiveness of CI pipeline checks or PR requirements, failing to recognize that only a structural enforcement mechanism (like a template) can guarantee the presence of a file, whereas content accuracy requires human review or advanced automation that is not implied in the options.

How to eliminate wrong answers

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

Full explanation →
105
Multi-Selectmedium

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

Select 3 answers
A.Avoid customizing work item types to maintain consistency.
B.Link work items to code changes and pull requests.
C.Keep work items small and granular.
D.Regularly update work item fields (e.g., Remaining Work).
E.Create large work items that cover multiple features.
AnswersB, C, D

Links provide traceability.

Why this answer

Linking work items to code changes and pull requests creates a traceable path from requirements to implementation, enabling teams to understand the context of changes and automatically update work item status (e.g., via GitHub integration or Azure Repos). This practice ensures that tracking is effective by providing visibility into which code delivered a specific feature or fix, which is essential for auditability and impact analysis.

Exam trap

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

Full explanation →
106
Multi-Selecthard

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

Select 3 answers
A.An Azure Resource Manager service connection.
B.A YAML pipeline definition.
C.The Azure Pipelines agent software installed on the machine.
D.A virtual machine or physical server to host the agent.
E.A personal access token (PAT) with agent pool management permissions.
AnswersC, D, E

The agent software is necessary.

Why this answer

Options A, B, and C are correct. A self-hosted agent requires a virtual machine to run the agent, the agent software installed, and a personal access token (PAT) to register the agent with Azure DevOps. Option D is wrong because a service connection is not needed for the agent registration.

Option E is wrong because a YAML pipeline is not required to set up the agent.

Full explanation →
107
MCQhard

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

A.No pipeline runs
B.Only a PR build
C.Only a CI build on the feature branch
D.Both a CI build on the feature branch and a PR build
AnswerB

PR trigger matches main branch.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
108
MCQmedium

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

A.Enable the 'Automatically update work item status' setting in the repository's pull request configuration.
B.Instruct developers to manually update the work item after merging.
C.Set up a branch policy that requires linked work items.
D.Create a service hook to call Azure DevOps REST API on pull request merge.
AnswerA

This built-in feature updates work item status on merge.

Why this answer

Option C is correct because Azure Boards supports automatically linking work items to pull requests and updating their status based on merge events. Option A is incorrect because branch policies do not update work items. Option B is incorrect because service hooks can trigger actions but are not the built-in mechanism for this scenario.

Option D is incorrect because manual linking does not automate status updates.

Full explanation →
109
MCQhard

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

A.Turn off direct push permissions for all users and force all changes through pull requests
B.Delete the main branch and recreate it as a protected branch
C.Set a branch policy on main that requires a build validation with the security scan
D.Use a service hook to run the scan on every push to main
AnswerC

Branch policies enforce the scan on every push; protecting main prevents bypasses.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
110
MCQeasy

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

A.Configure branch policies in Azure Repos to require a security scan.
B.Enable GitHub Advanced Security for Azure DevOps in Microsoft Defender for Cloud.
C.Configure deployment gates in Azure Pipelines to require a security scan.
D.Use Azure Policy to enforce scanning on Azure DevOps pipelines.
AnswerB

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

Why this answer

Microsoft Defender for Cloud can integrate with Azure DevOps via the GitHub Advanced Security for Azure DevOps feature (now part of Defender for Cloud), which enables code scanning, secret scanning, and dependency scanning in Azure Repos and pipelines. Defender for Cloud does not directly manage branch policies, service connections, or deployment gates.

Full explanation →
111
MCQhard

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

A.Create a GitHub Actions workflow that validates the PR description contains a closing keyword.
B.Configure an issue template with a closing keyword prompt.
C.Add a branch protection rule requiring a linked issue.
D.Use a required status check from a third-party app.
AnswerA

This workflow can run on pull_request and fail if no keyword found.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
112
MCQeasy

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

A.Web Deploy
B.Container
C.RunFromPackage
D.Zip Deploy
AnswerC

This method deploys a zip package and sets the app to run from it.

Why this answer

The 'Run from package' feature is enabled by selecting 'Web Deploy' with 'Package' or 'RunFromPackage' option. The correct option is to select 'RunFromPackage' as the deployment method. Option A is wrong because 'Zip Deploy' is a different method.

Option B is wrong because 'Web Deploy' alone does not enable run from package. Option D is wrong because 'Container' is for containerized apps.

Full explanation →
113
MCQmedium

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

A.Azure Update Management to schedule patching
B.Azure VM Image Builder to create patched images
C.Azure Policy to enforce that agents must be patched
D.Azure Automation State Configuration to enforce desired state
AnswerA

Azure Update Management can schedule patching for VMs.

Why this answer

Option C is correct because Azure Update Management can patch VMs used as build agents. Option A is wrong because VM image builder creates images but doesn't patch running agents. Option B is wrong because Azure Policy evaluates compliance but doesn't apply patches.

Option D is wrong because Azure Automation State Configuration applies desired state configuration but is not primarily for patching.

Full explanation →
114
MCQmedium

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

A.The service principal used for OIDC does not have the 'Storage Blob Data Contributor' role on the storage account.
B.The storage account firewall is blocking the GitHub Actions IP range.
C.The OIDC configuration in GitHub is missing the 'client secret' field.
D.The 'azure/webapps-deploy' action does not support static websites.
AnswerA

Role assignment is required for OIDC to access the resource.

Why this answer

Option A is correct because OIDC authentication requires the Azure AD application (service principal) to have the appropriate role assignment on the target resource (storage account). If the role assignment is missing, the OIDC token exchange fails. Option B is wrong because OIDC does not require client secret.

Option C is wrong because the action works with static websites. Option D is wrong because the issue is not network-related.

Full explanation →
115
Multi-Selecthard

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

Select 3 answers
A.Allocate time for refactoring in each iteration
B.Defer unit tests until after deployment
C.Automate unit and integration tests
D.Integrate static code analysis into the CI pipeline
E.Ignore low-priority code smells
AnswersA, C, D

Regular refactoring helps manage and reduce technical debt.

Why this answer

Option A is correct because allocating time for refactoring in each iteration is a core practice of managing technical debt in a DevOps environment. This ensures that code quality issues are addressed incrementally, preventing debt from accumulating and reducing future maintenance costs. In Agile and DevOps workflows, this is often implemented as a 'refactoring budget' within sprint planning, directly aligning with continuous improvement principles.

Exam trap

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

Full explanation →
116
MCQhard

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

A.Configure repository to require commit signature verification via SSH keys.
B.Enable 'Require signed commits' in branch protection rules and use a pre-receive hook to validate email domain.
C.Use a GitHub Actions workflow that checks commit signatures and email and rejects if invalid.
D.Enable 'Require signed commits' in branch protection and use a required status check that runs a custom action to verify commit author email.
AnswerD

Branch protection can require signed commits; a status check can validate email.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
117
Multi-Selectmedium

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

Select 2 answers
A.Use a manual intervention task in the pipeline.
B.Set environment permissions to allow only specific users to create releases.
C.Configure deployment gates to check for user approval.
D.Add a 'Approval' check on the production environment.
E.Add a pre-deployment approval to the production stage.
AnswersD, E

Checks can require approval from specific users or groups.

Why this answer

Option A is correct because pre-deployment approvals enforce approval before deployment. Option D is correct because checks can restrict based on user or group. Option B is wrong because gates are for health checks, not approvals.

Option C is wrong because environment permissions control who can create releases, not deploy to production. Option E is wrong because manual validation task is for interactive validation, not approval control.

Full explanation →
118
Multi-Selectmedium

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

Select 2 answers
A.Automatically compresses all files in the repository
B.Prevents large files from being stored in the Git history
C.Replaces .gitignore for excluding large files
D.Speeds up diff operations for binary files
E.Reduces the size of Git repositories by storing large files as pointers
AnswersB, E

Large files are stored on the LFS server, not in history.

Why this answer

Git LFS (Large File Storage) prevents large files from being stored directly in the Git repository history. Instead, it replaces the large file in the working tree with a small text pointer file, while the actual binary content is stored on a remote LFS server. This keeps the repository lightweight and avoids bloating the Git object database with large blobs.

Exam trap

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

Full explanation →
119
MCQhard

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

A.Use git filter-repo to remove the file from the branch's history, then force push the branch.
B.Use BFG Repo-Cleaner to delete the file from the branch's history, then force push.
C.Delete the feature branch and have the developer recreate the branch without the secret file.
D.Revert the commit that added the file, then push the revert.
AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
120
MCQmedium

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

A.Deployment Frequency
B.Application Dashboard
C.Time to Restore Service
D.Azure DevOps Pipeline Telemetry
AnswerA

It provides the requested metrics.

Why this answer

The Deployment Frequency analytics view in Application Insights is specifically designed to track how often deployments occur and the rate at which they fail, directly aligning with the goal of capturing deployment frequency and change failure rate. This view leverages data from Azure DevOps pipelines to provide these metrics without requiring custom queries or additional instrumentation.

Exam trap

The trap here is that candidates may confuse the Deployment Frequency view with the Application Dashboard, assuming the dashboard can be configured to show these metrics, but the question specifically asks for a built-in analytics view, which only the Deployment Frequency view provides.

How to eliminate wrong answers

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

Full explanation →
121
Multi-Selectmedium

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

Select 3 answers
A.Automated rollback or remediation capabilities.
B.A blame-free culture that identifies the person at fault.
C.Post-incident reviews with actionable improvements.
D.Manual approval gates for every change.
E.A clear escalation path and on-call rotation.
AnswersA, C, E

Enables quick recovery without manual intervention.

Why this answer

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

Exam trap

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

Full explanation →
122
MCQhard

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

A.Terraform with Kubernetes provider.
B.Helm package manager with Helm deploy task.
C.Azure Pipelines Kubernetes manifest task with kubectl apply.
D.Kubectl task with rolling update strategy.
AnswerB

Correct: Helm supports rollback and canary deployments.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
123
Multi-Selectmedium

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

Select 2 answers
A.AzureWebApp
B.CopyFilesOverSSH
C.AzureRmWebAppDeployment
D.AzureFunctionApp
E.AzureVMAppDeployment
AnswersA, C

This task deploys to Azure Web Apps.

Why this answer

Options A and B are correct. The AzureWebApp task and the AzureRmWebAppDeployment task are standard for deploying web apps. Option C is for Azure Functions, D is for VM applications, and E is a generic file copy task that does not perform deployment.

Full explanation →
124
MCQeasy

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

A.Build.Repository.Name
B.Build.BuildId
C.Build.SourceVersion
D.Build.SourceBranch
AnswerC

Correct: Build.SourceVersion contains the commit ID.

Why this answer

Option C is correct because Build.SourceVersion returns the commit ID. Option A is wrong because Build.BuildId is the pipeline build number. Option B is wrong because Build.SourceBranch is the branch name.

Option D is wrong because Build.Repository.Name is the repo name.

Full explanation →
125
MCQmedium

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

A.Enable Azure DevOps audit logs
B.Store pipeline YAML in a repository with branch policies
C.Use release approval gates
D.Set pipeline retention policies
AnswerB

Branch policies require approvals for changes to the pipeline definition.

Why this answer

Option D is correct because Azure DevOps audit logs track changes, but to prevent unauthorized reverts, you need branch policies on the pipeline definition branch. Option A is wrong because audit logs only record events, they don't prevent reverts. Option B is wrong because approval gates are for releases, not pipeline changes.

Option C is wrong because pipeline settings don't prevent reverts.

Full explanation →
126
MCQeasy

Your team uses GitHub and wants to automate the creation of a new release branch (e.g., release/v1.2.3) whenever a tag starting with 'v' is pushed. Which GitHub Actions trigger should you use?

A.on: release: types: [published]
B.on: create: tags: ['v*']
C.on: push: branches: ['v*']
D.on: workflow_dispatch: inputs: tag
AnswerB

Fires when a tag matching the pattern is created.

Why this answer

Option B is correct because the `on: create` trigger fires when a Git tag or branch is created, and the `tags: ['v*']` filter ensures it only activates for tags starting with 'v'. This directly matches the requirement to automate branch creation upon pushing a version tag, without relying on a GitHub Release event or a branch push.

Exam trap

The trap here is that candidates confuse the `release` trigger (which requires a GitHub Release object) with a simple Git tag push, or mistakenly use `branches` instead of `tags` under the `push` event, not realizing that tags are matched via the `tags` key, not `branches`.

How to eliminate wrong answers

Option A is wrong because the `release` trigger only fires when a GitHub Release is published via the UI or API, not when a Git tag is pushed; it requires an explicit release object, not just a tag. Option C is wrong because `on: push: branches: ['v*']` triggers on pushes to branches matching 'v*', not tags; tags are matched using `tags` under `push`, not `branches`. Option D is wrong because `workflow_dispatch` requires manual triggering via the GitHub UI or API with an input parameter, not an automatic trigger on tag push.

Full explanation →
127
Multi-Selecthard

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

Select 2 answers
A.Deployment protection rules that require approval.
B.The 'deployment' event trigger in a workflow.
C.Environments with required reviewers.
D.Branch protection rules that require pull request reviews.
E.OpenID Connect (OIDC) for cloud provider authentication.
AnswersA, C

Protection rules can require manual approval.

Why this answer

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

Exam trap

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

Full explanation →
128
MCQmedium

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

A.Set up an email subscription to the DevOps team
B.Create a service hook to call a custom API
C.Publish a Wiki page with deployment status
D.Configure a notification subscription in Azure DevOps to send a Teams webhook
AnswerD

Azure DevOps can send notifications to Teams via webhook when a release fails.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
129
MCQhard

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

A.Use a condition to check if a previous deployment is in progress.
B.Add a pre-deployment approval gate.
C.Set the 'parallel' deployment option to 1.
D.Configure an exclusive lock policy on the production environment.
AnswerD

Correct: Exclusive lock ensures only one deployment runs at a time.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
130
MCQhard

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

A.and(succeeded(), startsWith(variables['Build.SourceBranch'], 'refs/tags/v'))
B.and(succeeded(), startsWith(variables['Build.SourceBranchName'], 'v'))
C.and(succeeded(), startsWith(variables['Build.SourceVersion'], 'v'))
D.and(succeeded(), eq(variables['Build.Reason'], 'IndividualCI'))
AnswerA

Why this answer

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

Exam trap

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

Why the other options are wrong

B

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

C

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

D

Build.Reason checks for CI trigger, not tag.

Full explanation →
131
MCQmedium

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

A.The repository name in the workflow is incorrect.
B.The Dockerfile is missing a required LABEL instruction.
C.The ACR allows anonymous pull access.
D.The workflow does not include an 'azure/login' step to authenticate with Azure.
AnswerD

Azure login action is required to get credentials for ACR.

Why this answer

Option A is correct because the most common cause is that the Azure login action is missing or misconfigured. Option B is wrong because Docker login is handled by the Azure login action. Option C is wrong because ACR allows anonymous pull but not push.

Option D is wrong because the issue is authentication, not repository name.

Full explanation →
132
Multi-Selectmedium

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

Select 2 answers
A.Status check
B.Comment requirements
C.Build validation
D.Work item linking
E.Merge strategy
AnswersA, C

Requires external services (e.g., SonarQube) to pass.

Why this answer

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

Exam trap

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

Full explanation →
133
MCQmedium

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

A.The resource group name is incorrect.
B.The pipeline does not have an Azure service connection configured for authentication.
C.The DEPLOYMENT_SLOT setting name is invalid.
D.The script syntax is invalid.
AnswerB

The Azure CLI task requires authentication via a service connection.

Why this answer

The Azure CLI script requires authentication to Azure. Without an Azure CLI task or service connection, it fails. Option A is wrong because the resource group name is correct.

Option B is wrong because the script syntax is valid. Option D is wrong because the script is not missing any parameters; it lacks authentication.

Full explanation →
134
MCQhard

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

A.Keep separate repositories but create a meta-repo that references them as submodules
B.Create a single monorepo with a build pipeline that uses path filters to trigger builds only for changed services
C.Keep separate repositories but use Git submodules to share code
D.Create a single monorepo with all services and a single build pipeline that builds everything
AnswerB

Allows atomic commits across services while maintaining independent builds.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
135
MCQhard

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

A.Use manual approval gates between stages.
B.Use deployment gates with evaluation of health metrics (e.g., error rate) before proceeding to the next stage.
C.Configure a rolling deployment strategy on each cluster.
D.Use a manual validation step in the pipeline.
AnswerB

Gates automatically evaluate metrics and can halt progression if thresholds are exceeded.

Why this answer

Option B is correct because deployment gates with metrics evaluation allow progressive exposure and automated halt. Option A is incorrect because approvals are manual. Option C is incorrect because manual validation steps require human intervention.

Option D is incorrect because rolling deployment strategy is not about progressive exposure across clusters.

Full explanation →
136
MCQhard

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

A.The service principal client secret has expired.
B.The user who created the service connection has been removed from Azure DevOps.
C.The Azure DevOps organization is behind a firewall that blocks outbound requests to Azure Resource Manager.
D.The service principal lacks the required role on the target resource group.
AnswerA

Expired secrets cause intermittent token failures; re-creating the connection generates a new secret.

Why this answer

Option A is correct because service principal credentials (client secret) can expire, causing intermittent token fetch failures. Re-creating the service connection generates a new secret, temporarily resolving the issue until it expires again. Option B is wrong because RBAC permissions do not affect token acquisition from Entra ID.

Option C is wrong because network restrictions would cause consistent failure, not intermittent. Option D is wrong because the service connection is specific to the service principal, not user credentials.

Full explanation →
137
MCQeasy

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

A.trigger: pr: branches: include: - main
B.trigger: branches: include: - main
C.pr: branches: include: - main
D.pr: autoCancel: false branches: include: - '*'
AnswerC

Correctly sets PR trigger for changes targeting main.

Why this answer

Option C is correct because 'pr: branches: include: - main' triggers the pipeline on PRs targeting main. Option A is wrong because it uses 'trigger' for CI, not PR triggers. Option B is wrong because it uses 'trigger' for PRs, but the syntax is incorrect.

Option D is wrong because it includes all branches, which is too broad.

Full explanation →
138
Multi-Selecthard

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

Select 3 answers
A.Rolling update.
B.Ring-based deployment.
C.Canary deployment.
D.Immutable infrastructure.
E.Blue-green deployment.
AnswersB, C, E

Ring-based deployment releases to increasing user groups.

Why this answer

Options A, C, and D are correct. Canary, blue-green, and ring-based deployments are all progressive exposure strategies. Option B is not progressive exposure; it's a deployment method.

Option E is a deployment strategy but not typically progressive exposure.

Full explanation →
139
MCQhard

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

A.Add an Azure Key Vault task in the pipeline to download secrets
B.Store secrets in pipeline variables and mark them as secret
C.Use Variable Groups linked to Key Vault
D.Reference Key Vault secrets directly in App Service configuration
AnswerA

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

Why this answer

Option C is correct because using a Key Vault task in the pipeline retrieves secrets and makes them available as variables. Option A is wrong because it does not integrate with Key Vault. Option B is wrong because it stores secrets in the pipeline library, not Key Vault.

Option D is wrong because it relies on App Service configuration, not pipeline retrieval.

Full explanation →
140
MCQmedium

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

A.Service principal with client secret
B.Managed identity
C.OAuth 2.0 authorization code grant
D.Personal access token (PAT)
AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
141
Multi-Selectmedium

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

Select 2 answers
A.Store secrets in plain text in a variable group.
B.Use a variable group linked to Azure Key Vault and mark variables as secret.
C.Store secrets in a Git repository and read them during build.
D.Embed secrets directly in the pipeline YAML file.
E.Use the Azure Key Vault task to fetch secrets and map them to pipeline variables.
AnswersB, E

Variable groups can reference Key Vault secrets securely.

Why this answer

Option B is correct because linking a variable group to Azure Key Vault allows secrets to be securely referenced in pipelines without exposing them in plaintext. When variables are marked as secret, Azure Pipelines automatically masks their values in logs and output, ensuring sensitive data remains protected throughout the build and release process.

Exam trap

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

Full explanation →
142
MCQmedium

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

A.The tag v1.0-rc is removed, but the commit it pointed to is also deleted from the repository.
B.The tag v1.0-rc is removed, and the branch feature/new-feature is also deleted because it was the same object.
C.The tag v1.0-rc is removed, and the repository now contains only one tag (v1.0) and three branches.
D.The command fails because the tag does not exist.
AnswerC

The delete command removes the tag v1.0-rc. The other refs remain, so there is one tag and three branches.

Why this answer

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

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

Full explanation →
143
Multi-Selectmedium

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

Select 2 answers
A.Link a variable group to Azure Key Vault and reference variables in the pipeline.
B.Use the 'AzureKeyVault' task to download secrets during the pipeline run.
C.Use the 'secret' variable type in YAML and hardcode the value.
D.Store secrets in a text file in the repository and use a script to read them.
E.Use encrypted environment variables in GitHub Actions.
AnswersA, B

This securely stores secrets in Key Vault.

Why this answer

Variable groups can be linked to Azure Key Vault to store secrets securely. The 'AzureKeyVault@1' task can retrieve secrets from Key Vault at runtime. Option A is correct because variable groups support Key Vault integration.

Option D is correct because the task can download secrets. Option B is not secure; Option C is not secure; Option E is not a pipeline feature.

Full explanation →
144
MCQhard

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

A.Configure a branch policy requiring CAB member approval on pull requests.
B.Add a manual intervention task in the YAML pipeline.
C.Set up a service hook to send an email to the CAB and wait for a reply.
D.Create a release pipeline with a pre-deployment approval gate for the production stage.
AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
145
MCQmedium

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

A.Use Slack huddles for quick sync-ups.
B.Maintain a wiki in Azure DevOps with status and decisions.
C.Use email threads for status updates.
D.Schedule daily standup meetings at a fixed time.
E.Record all team meetings and share links.
AnswerB

Wiki provides persistent, searchable documentation.

Why this answer

Option C is correct because Azure DevOps Wiki provides a persistent, searchable record of decisions and status. Option A is wrong because daily standups require synchronous attendance. Option B is wrong because email threads are hard to search and not integrated.

Option D is wrong because Slack huddles are real-time. Option E is wrong because meeting recordings are passive and not searchable.

Full explanation →
146
MCQhard

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

A.The secrets are not automatically mapped to environment variables; you must reference them using $(secretName).
B.The SecretsFilter is set to '*' which is invalid.
C.The service principal does not have 'Get' permission on the key vault.
D.The key vault name 'mykv' does not exist.
AnswerA

With RunAsPreJob: false, secrets are not injected as environment variables; they must be explicitly referenced.

Why this answer

Option B is correct because when RunAsPreJob is false, secrets are fetched during the job but may not be available as environment variables automatically; they need to be referenced as $(secretName). Option A is wrong because the service connection likely has permissions. Option C is wrong because the filter '*' fetches all secrets.

Option D is wrong because Key Vault exists.

Full explanation →
147
MCQmedium

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

A.The service principal is not registered for the 'Microsoft.Storage' resource provider.
B.The storage account name is already taken.
C.The ARM template is using an unsupported API version.
D.The service principal does not have 'Contributor' role at the subscription scope.
AnswerD

If the deployment is at subscription scope, subscription-level permissions are needed.

Why this answer

Option B is correct because ARM template deployments require 'Microsoft.Resources/deployments/write' permission, which is included in Contributor. However, if the deployment is at subscription scope, the service principal needs Contributor on the subscription. Option A is incorrect because the error is authorization, not conflict.

Option C is not required. Option D is incorrect because ARM templates don't require a specific provider registration for deployment itself.

Full explanation →
148
MCQhard

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

A.The condition syntax is wrong; it should use 'eq(variables.publishEnabled, true)'.
B.The Publish stage is missing 'dependsOn: Build'.
C.The variable 'publishEnabled' is not settable at queue time; it is a compile-time variable.
D.The 'dependsOn' syntax is incorrect; it should be 'dependsOn: Build'.
AnswerC

Variables in the 'variables' section are compile-time unless explicitly allowed.

Why this answer

In YAML pipelines, variables defined in the 'variables' section are compile-time and cannot be overridden at queue time unless they are marked as 'queue-time' settable. The condition 'eq(variables['publishEnabled'], true)' evaluates at runtime, but the variable value is fixed at compile time. Option C is correct.

Option A is incorrect because 'dependsOn' is correct. Option B is incorrect because the condition syntax is valid. Option D is incorrect because the variable is not runtime-settable.

Full explanation →
149
Multi-Selecthard

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

Select 2 answers
A.Pipeline task 'Update work item' from the Azure DevOps extension.
B.Service hooks to trigger an Azure function.
C.Release gates with work item update actions.
D.Work item query charts.
E.Branch policy with required reviewers.
AnswersA, C

This task directly updates work item fields.

Why this answer

Options B and D are correct. Release gates can update work items based on release status, and the 'Update work item' task can set field values. Option A is wrong because service hooks are for external integrations.

Option C is wrong because branch policies are for PRs, not builds. Option E is wrong because work item queries are read-only.

Full explanation →
150
MCQeasy

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

A.Delete the file and commit the deletion
B.Ignore the file using .gitignore
C.Revert the commit using 'git revert'
D.Use 'git filter-branch' to remove the file from history
AnswerD

This rewrites history to remove the file entirely.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
Page 1

Page 2 of 13

Page 3

All pages

12345678910111213

Practice AZ-400 by domain

Target a specific domain to shore up weak areas.

Configure processes and communicationsDesign and implement source controlDesign and implement build and release pipelinesDevelop a security and compliance planImplement an instrumentation strategyDesign and implement a DevOps infrastructureDesign and implement a source control strategy
See all domains with question counts →