Courseiva

Microsoft Azure DevOps Engineer Expert AZ-400 (AZ-400) — Questions 451–525

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

Take a mock examExam hub
Page 6

Page 7 of 13

Page 8
451
MCQmedium

Your team uses a monorepo in Azure Repos. Developers frequently commit directly to the main branch, causing build failures. You need to enforce a policy that requires all changes to go through pull requests with at least one reviewer. What should you configure?

A.Configure a repository policy to require a pull request for all branches.
B.Create a service hook to reject commits to main that are not from pull requests.
C.Configure a branch policy on the main branch to require a minimum number of reviewers.
D.Enable the 'Require a minimum number of reviewers' setting in the project settings.
AnswerC

Branch policies on main can enforce pull request requirements and reviewer count.

Why this answer

Option C is correct because Azure Repos allows you to configure branch policies on specific branches (like main) to enforce that all changes must come through pull requests and require a minimum number of reviewers. This directly addresses the need to prevent direct commits to main and ensure code review before merging.

Exam trap

The trap here is that candidates often confuse project-level settings with branch-level policies, or mistakenly think service hooks can enforce commit restrictions, when in fact Azure Repos requires explicit branch policy configuration on the target branch to enforce pull request requirements and reviewer counts.

How to eliminate wrong answers

Option A is wrong because configuring a repository policy to require a pull request for all branches would apply the restriction to every branch, including feature branches, which is overly broad and not the specific requirement to protect only the main branch. Option B is wrong because service hooks are used to trigger external events (e.g., webhooks) based on repository actions, not to reject commits; they cannot enforce branch policies or block direct commits. Option D is wrong because the 'Require a minimum number of reviewers' setting is not available in project settings; it is a branch policy configuration that must be applied at the branch level within the repository settings.

Full explanation →
452
MCQeasy

A team wants to enforce that all Azure resource groups in a subscription are tagged with 'CostCenter' and 'Environment'. They need a solution that automatically applies these tags to any new resource group and ensures compliance without manual intervention. What should they use?

A.Azure Policy
B.Azure RBAC
C.Azure Blueprints
D.Azure Resource Graph
AnswerA

Azure Policy can enforce tagging rules via 'deny' or 'append' effects on resource groups.

Why this answer

Azure Policy is the correct choice because it allows you to define and enforce tagging rules at scale. By creating a policy that requires 'CostCenter' and 'Environment' tags on resource groups, and setting the policy effect to 'deny' or 'append' (to automatically add missing tags), any new resource group creation that violates the policy is blocked or automatically remediated, ensuring compliance without manual intervention.

Exam trap

The trap here is that candidates confuse Azure Blueprints (which can include policies) with Azure Policy itself, but Blueprints are for deploying entire environments, not for continuous, automatic enforcement on all new resource groups across a subscription.

How to eliminate wrong answers

Option B (Azure RBAC) is wrong because Role-Based Access Control manages permissions (who can do what) on Azure resources, not the enforcement of resource metadata like tags. Option C (Azure Blueprints) is wrong because while Blueprints can include policies and assign tags during deployment, they are designed for orchestrating repeatable environments (e.g., a full subscription setup) and do not automatically enforce tagging on all new resource groups outside the blueprint's scope. Option D (Azure Resource Graph) is wrong because it is a query service for exploring and auditing resources, not a mechanism to enforce or automatically apply tags.

Full explanation →
453
MCQeasy

You have a pipeline with the above JSON definition. The build fails with 'The specified configuration 'Release' is not valid'. What is the most likely cause?

A.The configuration value should be 'debug' instead.
B.The buildConfiguration variable is not set.
C.The pipeline definition is in JSON format, which is not supported by Azure Pipelines.
D.The DotNetCoreCLI task requires a specific version.
AnswerC

Azure Pipelines uses YAML, not JSON, for pipeline definitions.

Why this answer

Option C is correct because the variable syntax in YAML is '$(variableName)' but in JSON pipeline (classic) it's '$(variableName)' as well, but the issue is that the variable 'buildConfiguration' might not be defined correctly or the JSON pipeline does not support variable substitution like YAML. However, the exhibit is JSON (classic pipeline). In classic pipelines, variables are referenced as '$(buildConfiguration)' but the JSON snippet is from a YAML pipeline? Actually, the exhibit is JSON but Azure Pipelines uses YAML.

In classic editor, variables are set in UI, not in JSON. The most likely cause is that the JSON format is not valid for Azure Pipelines; Azure Pipelines uses YAML. Option C is correct because Azure Pipelines does not support JSON format for pipeline definitions; it must be YAML.

Full explanation →
454
MCQhard

During a release pipeline, you notice that the deployment to staging fails intermittently due to a timeout waiting for the health check endpoint to return 200. The health check typically passes within 30 seconds, but occasionally takes up to 2 minutes. You need to make the deployment more reliable without affecting the overall release time. What should you do?

A.Remove the health check from the pipeline and rely on monitoring.
B.Add a retry task that runs the health check again after a failure.
C.Increase the health check timeout in the pipeline task to 3 minutes.
D.Reduce the health check timeout to 10 seconds to fail fast and trigger a rollback.
AnswerC

Allowing up to 3 minutes accommodates the occasional delay without causing failure.

Why this answer

Option A is correct because increasing the health check timeout to 3 minutes accommodates the occasional 2-minute delay without failing the deployment. Option B is wrong because retrying the task would restart the entire deployment, increasing total time. Option C is wrong because removing the health check removes validation.

Option D is wrong because reducing the timeout would cause more failures.

Full explanation →
455
MCQhard

You are designing a release pipeline for a microservices application deployed to Azure Kubernetes Service (AKS). You need to implement a strategy that minimizes downtime during updates by gradually shifting traffic to the new version while monitoring for errors. Which deployment strategy should you use?

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

Correct: Canary releases a small subset of new version and gradually increases traffic with monitoring.

Why this answer

Option C is correct because canary deployment gradually shifts traffic and allows monitoring. Option A is wrong because rolling replacement updates pods incrementally but doesn't shift traffic gradually. Option B is wrong because blue-green deploys a full new environment and switches all traffic, not gradual.

Option D is wrong because recreate replaces all pods at once, causing downtime.

Full explanation →
456
MCQeasy

Your organization needs to ensure that all containers built in Azure Pipelines are scanned for vulnerabilities before being pushed to a container registry. Which step should you add to the pipeline?

A.Add a step to use 'Microsoft Defender for Cloud' container image scanning.
B.Add a step to create an Azure Container Registry task for scanning.
C.Add a step to push the image to Docker Hub for scanning.
D.Add a step to run Trivy to scan the image.
AnswerA

Microsoft Defender for Cloud provides vulnerability scanning for container images in Azure Pipelines.

Why this answer

Microsoft Defender for Cloud's vulnerability scanner can be integrated into Azure Pipelines to scan container images for vulnerabilities before push. Trivy is a third-party tool, not native. Docker Hub scanning is external.

Azure Container Registry tasks are for post-push scanning.

Full explanation →
457
MCQeasy

A developer accidentally committed a sensitive password to a Git repository. The commit has already been pushed to the remote. What is the first step to remediate the situation?

A.Delete the file from the repository and commit the deletion
B.Remove the password from the file, amend the commit, and force push
C.Revert the commit that introduced the password
D.Immediately notify the security team and rotate the password
AnswerB

Amending removes the password from the commit and force push updates the remote.

Why this answer

Option B is correct because the password has already been pushed to the remote, meaning it exists in the commit history. Simply deleting the file or reverting the commit does not remove the password from the Git history; anyone with access to the repository can still retrieve it. The proper first step is to remove the password from the file, amend the commit (using `git commit --amend`), and force push (`git push --force`) to overwrite the remote history, effectively erasing the sensitive data from the branch.

Exam trap

The trap here is that candidates confuse 'reverting' (which adds a new commit) with 'removing from history' (which requires amending or interactive rebase and force push), leading them to choose Option C as a safe alternative.

How to eliminate wrong answers

Option A is wrong because deleting the file and committing the deletion leaves the password in the previous commit history, which is still accessible via `git log` and `git checkout`. Option C is wrong because reverting the commit creates a new commit that undoes the changes but does not remove the original commit from history; the password remains in the reverted commit. Option D is wrong because while notifying the security team and rotating the password is a critical follow-up step, it is not the first technical step to remediate the Git history; the immediate priority is to remove the password from the remote repository to prevent further exposure.

Full explanation →
458
MCQeasy

Your Azure DevOps project has multiple teams. You need to ensure that each team's board only shows work items assigned to that team. What should you configure?

A.Create a shared query for each team and pin it to the dashboard.
B.Assign each team a unique iteration path.
C.Set permissions on area paths to restrict access.
D.Configure team settings to set default area paths for each team.
AnswerD

This filters the board to show only work items in the team's area paths.

Why this answer

Option B is correct because team configurations define which area paths and work items appear on the team board. Option A is wrong because work item queries are for custom views, not default board filtering. Option C is wrong because area paths are used in team configuration, not a separate setting.

Option D is wrong because iteration paths control sprints, not board visibility.

Full explanation →
459
Multi-Selecteasy

Which TWO Git operations are considered dangerous and should be used with caution because they rewrite history? (Select TWO.)

Select 2 answers
A.git fetch
B.git push --force
C.git merge
D.git rebase
E.git revert
AnswersB, D

Force push can overwrite remote history.

Why this answer

Option B is correct because `git push --force` overwrites the remote branch history with the local branch, discarding any commits on the remote that are not in the local history. This can cause other collaborators to lose work if they have based changes on the overwritten commits, making it a history-rewriting operation that must be used with caution.

Exam trap

The trap here is that candidates often confuse `git revert` with `git reset` or think `git merge` rewrites history, but the key distinction is that only operations that change existing commit SHAs (like rebase and force push) are considered history-rewriting and dangerous.

Full explanation →
460
Multi-Selectmedium

Which TWO of the following are valid ways to trigger a release pipeline in Azure DevOps? (Select TWO.)

Select 2 answers
A.Continuous deployment trigger after a build completes.
B.Source version trigger.
C.Manual trigger via the 'Create release' button.
D.Pull request trigger.
E.Scheduled release trigger.
AnswersA, E

This triggers a release automatically when a build artifact is available.

Why this answer

Option A is correct because Azure DevOps release pipelines can be configured with a continuous deployment trigger that automatically creates a release whenever a build artifact is successfully produced. This is a core feature for enabling automated delivery pipelines, where the release is triggered immediately after the build pipeline completes, ensuring rapid feedback and deployment.

Exam trap

The trap here is that candidates confuse manual release creation (an action) with a configured trigger (an automated event), and they may incorrectly assume that pull request triggers apply to release pipelines when they are only valid for build pipelines.

Full explanation →
461
MCQmedium

You are designing a release pipeline for a microservices application deployed to Azure Kubernetes Service (AKS). Each microservice has its own build pipeline that produces a container image. You need a single release pipeline that can deploy multiple microservices in a coordinated manner, but you want to avoid rebuilding the deployment pipeline for each microservice. The deployment should use Helm charts. What should you do?

A.Create a separate release pipeline for each microservice and trigger them in sequence using pipeline completion triggers.
B.Create a single build pipeline that produces all container images, then a release pipeline that deploys the single artifact.
C.Create a single release pipeline that consumes multiple build artifacts (one per microservice) and uses a Helm chart per microservice, deploying them in stages.
D.Create a single multi-stage YAML pipeline that builds and deploys all microservices together.
AnswerC

Single pipeline coordinates deployments.

Why this answer

Option B is correct because a single release pipeline can use multiple artifacts and deploy them sequentially or in parallel. Option A is incorrect because separate pipelines for each microservice lack coordination. Option C is incorrect because a multi-stage pipeline per microservice still duplicates.

Option D is incorrect because a single build pipeline would couple all builds.

Full explanation →
462
Multi-Selecteasy

Your team uses Azure Boards with a custom process. Which two features allow you to customize the work item types? (Choose two.)

Select 2 answers
A.Create an inherited process from the default process.
B.Add custom work item types to an inherited process.
C.Configure rules to create new work item types.
D.Use team settings to define new work item types.
E.Modify the default process directly.
AnswersA, B

Inherited processes allow customization.

Why this answer

Option A is correct because in Azure Boards, customization of work item types is only possible through an inherited process. You must create an inherited process from a default process (e.g., Agile, Scrum, CMMI) to enable any modifications. This ensures the default process remains unaltered and supports upgrade compatibility.

Exam trap

The trap here is that candidates often confuse team settings (which manage visibility and defaults) with process-level customization, or mistakenly believe the default process can be directly edited, but Azure Boards enforces that only inherited processes are customizable.

Full explanation →
463
MCQmedium

You have a YAML pipeline with multiple jobs that need to run in parallel. However, one job depends on artifacts produced by a previous job. How should you configure the dependency?

A.Set dependsOn on the dependent job and use PublishBuildArtifacts and DownloadBuildArtifacts tasks.
B.Use the 'dependsOn' keyword only, artifacts are automatically shared.
C.Set the 'condition' to 'eq(variables['Agent.JobStatus'], 'Succeeded')' on the dependent job.
D.Use the 'pool' keyword to ensure both jobs run on the same agent.
AnswerA

Why this answer

Option A is correct because in Azure DevOps YAML pipelines, job dependencies are explicitly declared using the `dependsOn` keyword, and artifacts must be published and downloaded using `PublishBuildArtifacts` and `DownloadBuildArtifacts` tasks (or the `publish` and `download` pipeline decorators). Without explicit artifact sharing, outputs from one job are not automatically available to another job, even if `dependsOn` is set.

Exam trap

The trap here is that candidates assume `dependsOn` alone handles artifact sharing, but Azure DevOps requires explicit publish/download tasks because jobs may run on different agents with no shared file system.

Why the other options are wrong

B

Artifacts must be explicitly published and downloaded.

C

Condition controls execution but does not handle artifact sharing.

D

Same agent is not guaranteed and doesn't handle dependencies.

Full explanation →
464
Multi-Selectmedium

Which THREE components are essential for implementing a canary deployment strategy using Azure Kubernetes Service (AKS) and Azure Pipelines? (Choose three.)

Select 3 answers
A.Azure Traffic Manager for global load balancing.
B.A service mesh like Istio or Linkerd for traffic splitting.
C.A health check endpoint to validate the canary deployment.
D.Multiple Kubernetes namespaces to separate canary and stable deployments.
E.Azure Front Door for routing traffic to the canary.
AnswersB, C, D

Service mesh enables fine-grained traffic routing between versions.

Why this answer

Options A, C, and D are correct. Option A: A service mesh (e.g., Istio, Linkerd) enables traffic splitting between canary and stable versions. Option C: Multiple Kubernetes namespaces help isolate environments.

Option D: A health check endpoint is necessary to validate the canary before routing more traffic. Option B is wrong because Azure Traffic Manager is for global traffic routing, not within a cluster. Option E is wrong because Azure Front Door is for HTTP(S) load balancing at the edge, not for in-cluster traffic splitting.

Full explanation →
465
Multi-Selectmedium

Your team is adopting Azure Pipelines for a new project. You need to ensure that only authorized users can approve releases to production. Which two methods can you use to implement approval checks?

Select 2 answers
A.Configure pre-deployment approvals on the Production environment.
B.Use Deployment Gates with a manual approval gate.
C.Set the 'Required approvers' field on the environment to a specific user or group.
D.Add a Manual Intervention task in the release pipeline.
E.Add an Approval Check to the agent pool.
AnswersA, C

Correct: Pre-deployment approvals require manual approval before deployment to that environment.

Why this answer

Options B and E are correct. Pre-deployment approvals can be added to a specific environment, and a single required approver can be designated. Options A and C are not valid for classic release pipelines; manual intervention is a task, not an approval.

Option D is wrong because there is no 'Approval Gates' feature; gates are automated.

Full explanation →
466
MCQhard

Refer to the exhibit. A developer attempts to push a commit directly to the main branch of FabrikamWeb repository but receives a push rejection. What is the most likely reason?

A.The developer tried to push to the wrong remote URL.
B.The FabrikamWeb repository has a minimum number of reviewers policy set to 1, which blocks direct pushes.
C.The developer does not have permission to push to the main branch due to branch policies requiring pull requests.
D.The main branch does not exist in the FabrikamWeb repository.
AnswerC

Branch policies on main typically enforce that all changes must go through pull requests and be reviewed.

Why this answer

The repository FabrikamWeb has a default branch 'develop', and the merge strategy policy may require that all changes be made via pull requests. Also, the absence of a policy on main branch suggests that main is protected by branch policies that are not listed because the query was for the develop branch. However, the question is about pushing to main.

Given the exhibit shows policies for the repository, but not specifically for main branch, the most likely cause is that the branch policies are set on the default branch (develop) and maybe also on main, but the push rejection could be due to a branch policy requiring pull requests. However, the correct answer is that the main branch is protected by a branch policy that requires pull requests, which is a common setting.

Full explanation →
467
Multi-Selecthard

You are designing a release pipeline that must deploy to Azure App Service across multiple regions. Which two practices should you implement to minimize downtime during deployments? (Choose 2)

Select 2 answers
A.Use Azure App Service deployment slots and perform a swap
B.Stop the web app before deploying, then start it after
C.Implement a rolling deployment strategy across regions
D.Deploy to all regions simultaneously
E.Use a single deployment slot for all regions
AnswersA, C

Why this answer

Option A is correct because Azure App Service deployment slots allow you to deploy a new version of your application to a staging slot, perform validation, and then swap it into production with zero downtime. The swap operation warms up the target slot and smoothly transitions traffic, ensuring no requests are dropped during the update.

Exam trap

The trap here is that candidates often confuse 'minimizing downtime' with 'eliminating all risk' and may incorrectly choose to stop the app (Option B) or deploy simultaneously (Option D), not realizing that deployment slots and rolling updates are the standard Azure patterns for zero-downtime deployments.

Why the other options are wrong

B

Stopping the app causes downtime.

D

Simultaneous deployment can cause full outage if something goes wrong.

E

A single slot doesn't allow zero-downtime swap.

Full explanation →
468
Multi-Selecthard

You have a YAML pipeline that builds a Docker image and pushes it to Azure Container Registry (ACR). You need to ensure the pipeline uses the latest version of Docker and that the build is cached for faster subsequent runs. Which two tasks should you include? (Choose two.)

Select 2 answers
A.DockerInstaller@0
B.Docker@2 with arguments: --cache-from
C.DockerCompose@0
D.HelmDeploy@0
AnswersA, B

Why this answer

Option A (DockerInstaller@0) is correct because it ensures the pipeline uses the latest version of Docker by installing or upgrading the Docker engine on the build agent. Option B (Docker@2 with --cache-from) is correct because it enables layer caching by pulling the previously built image from ACR as a cache source, which speeds up subsequent builds by reusing unchanged layers.

Exam trap

The trap here is that candidates often confuse DockerCompose@0 (used for orchestrating multiple containers) with Docker@2 (used for building and pushing single images), or assume HelmDeploy@0 is relevant because it involves containers, but it is strictly for Kubernetes deployments.

Why the other options are wrong

C

Docker Compose is not needed for a single image build.

D

Helm is for package management, not Docker build.

Full explanation →
469
MCQeasy

You need to automatically run a pipeline when a new tag is pushed to the repository. Which trigger configuration should you use?

A.Tags trigger
B.Schedule trigger
C.PR trigger
D.CI trigger with branch filters
AnswerA

Tags trigger runs the pipeline when tags are pushed.

Why this answer

Tags trigger allows running pipelines on tag creation or update. Option B is wrong because CI trigger is for branches. Option C is wrong because PR trigger is for pull requests.

Option D is wrong because schedule trigger is time-based.

Full explanation →
470
Multi-Selecthard

Which THREE steps should you take to implement a secure CI/CD pipeline that uses secrets from Azure Key Vault?

Select 3 answers
A.Use the Azure Key Vault task to download secrets as variables
B.Use secret variables in the pipeline that reference Key Vault secrets
C.Store secrets as plain text variables in the pipeline library
D.Hardcode secrets in the YAML file and use variables to mask them
E.Grant the build agent managed identity access to the Key Vault
AnswersA, B, E

Task retrieves secrets at runtime.

Why this answer

Granting agent access to Key Vault, using secret variables, and leveraging the Key Vault task are all correct. Option D (plain text) is insecure. Option E (hardcoded) is also insecure.

Full explanation →
471
MCQeasy

You run the Azure CLI command shown in the exhibit. What is the output?

A.An error because the query syntax is incorrect
B.A table showing VM names and resource groups for VMs in eastus
C.A list of all VMs in the subscription
D.A list of all VMs in the westus location
AnswerB

The command filters by eastus and projects name and resource group.

Why this answer

The Azure CLI command `az vm list --query "[?location=='eastus'].{Name:name, ResourceGroup:resourceGroup}" --output table` filters virtual machines to only those in the 'eastus' location, then projects the 'name' and 'resourceGroup' properties into a table. The `--query` parameter uses JMESPath syntax, which is correct here, and the `--output table` formats the result as a table. Therefore, the output is a table showing VM names and resource groups for VMs in eastus.

Exam trap

The trap here is that candidates might think the query syntax is invalid (Option A) due to unfamiliarity with JMESPath, or they might overlook the location filter and assume the command returns all VMs (Option C) or VMs in a different location (Option D).

How to eliminate wrong answers

Option A is wrong because the query syntax is valid JMESPath; the filter `[?location=='eastus']` and projection `{Name:name, ResourceGroup:resourceGroup}` are correctly formed, so no error occurs. Option C is wrong because the query explicitly filters by location 'eastus', so it does not list all VMs in the subscription. Option D is wrong because the filter specifies 'eastus', not 'westus'; the command will only return VMs in the eastus location.

Full explanation →
472
MCQhard

You are the DevOps lead for a fintech company. The organization uses a multi-tenant Azure DevOps environment with hundreds of pipelines. The compliance team requires that every pipeline run must be auditable with the following attributes captured: who triggered the run, what code changes were included, which artifacts were produced, and whether any secrets (e.g., Azure Key Vault references) were accessed during the run. Additionally, all audit data must be retained for 7 years and be queryable within 5 minutes of a pipeline completion. Current state: pipelines use Azure Key Vault for secrets, and YAML pipelines are defined with variables referencing Key Vault. You need to design an instrumentation strategy to meet these requirements. What should you do?

A.Enable Azure DevOps Audit Streams to send audit events to a Log Analytics workspace. Configure a Log Analytics workspace with 7-year retention. Create a dashboard and alert rules for compliance.
B.Use Azure Event Grid to subscribe to pipeline run events and store them in Azure Cosmos DB with TTL for 7 years.
C.Add a step at the end of each pipeline to upload pipeline logs as pipeline artifacts with a retention policy of 7 years.
D.Instrument each pipeline with custom tasks that send telemetry to Application Insights. Set Application Insights to 7-year retention.
AnswerA

Audit Streams captures all required events and Log Analytics provides long-term retention and near real-time querying.

Why this answer

Option A is correct because using Azure DevOps Audit Streams to send events to a Log Analytics workspace provides long-term retention and near real-time querying. Azure DevOps Audit logs capture all required attributes including pipeline runs, secret access, and user identity. Application Insights (B) is for application telemetry, not pipeline audit.

Event Grid (C) is event-driven but doesn't store historical data for 7 years query. Pipeline artifacts (D) don't include audit trail of who triggered or secret access.

Full explanation →
473
MCQeasy

Your team uses Git with a trunk-based development strategy. They want to ensure that all code changes are integrated into the main branch at least once a day, and that branch lifetimes are short. Which practice best supports this?

A.Developers use GitFlow with develop and feature branches, merging to develop daily and to main at release.
B.Developers commit directly to a release branch, and then the release branch is merged to main at the end of the sprint.
C.Developers work on long-lived feature branches and merge to main only after all features are complete.
D.Developers work on short-lived feature branches (less than a day) and merge to main via pull requests after successful CI.
AnswerD

Short-lived branches and frequent merges align with trunk-based development.

Why this answer

Option D is correct because trunk-based development emphasizes short-lived feature branches (typically less than a day) that are merged into the main branch via pull requests after passing continuous integration (CI) checks. This ensures all code changes are integrated at least daily, keeping branch lifetimes short and reducing merge conflicts.

Exam trap

The trap here is that candidates may confuse GitFlow (option A) with trunk-based development, but GitFlow's long-lived develop and feature branches directly contradict the requirement for daily integration into main and short branch lifetimes.

How to eliminate wrong answers

Option A is wrong because GitFlow uses long-lived develop and feature branches, with merges to main only at release, which violates the trunk-based requirement of daily integration into main. Option B is wrong because committing directly to a release branch and merging only at sprint end creates long-lived branches and delays integration, contradicting the need for daily main branch updates. Option C is wrong because long-lived feature branches delay integration until all features are complete, which is the opposite of trunk-based development's short-lived branch and frequent merge strategy.

Full explanation →
474
MCQhard

Your organization uses GitHub Actions for CI/CD. You need to ensure that secrets stored in GitHub Actions are not exposed in logs. A developer accidentally logs a secret using 'echo ${{ secrets.API_KEY }}' in a workflow step. What is the default behavior?

A.The secret value is replaced with an empty string in the log
B.The workflow run fails with an error about secret exposure
C.The secret is redacted before the step runs, and the step fails if it tries to use the secret
D.The secret value is masked with asterisks in the log output
AnswerD

GitHub Actions automatically masks secrets in log output.

Why this answer

Option D is correct because GitHub Actions automatically masks secrets in workflow logs. When a secret is used in a step (e.g., via `${{ secrets.API_KEY }}`), GitHub replaces any occurrence of the secret's value in the log output with `***`. This redaction happens at runtime, so even if a developer accidentally echoes the secret, the log will show asterisks instead of the actual value.

Exam trap

The trap here is that candidates may confuse GitHub Actions' automatic log masking with a workflow failure or pre-execution redaction, but the key is that masking happens at runtime in the log output without stopping the workflow.

How to eliminate wrong answers

Option A is wrong because secrets are not replaced with an empty string; they are masked with asterisks (`***`) to preserve log readability while hiding the value. Option B is wrong because the workflow does not fail due to secret exposure; GitHub Actions does not automatically fail a run when a secret is logged—it only masks the output. Option C is wrong because the secret is not redacted before the step runs; it is available for use, and the step does not fail if it tries to use the secret—the masking occurs in the log output after execution.

Full explanation →
475
MCQhard

Your team uses Azure Pipelines with Microsoft-hosted agents. You need to ensure that sensitive variables like API keys are securely passed to build tasks, but not exposed in logs. Which approach should you use?

A.Retrieve the API key from Azure Key Vault at runtime using the Azure Key Vault task, but do not mark the output as secret
B.Store the API key as a secret variable in the pipeline library or variable group
C.Define the API key in a variable template with 'isSecret: false'
D.Store the API key as a plain text variable in the pipeline and use it as an environment variable
AnswerB

Secret variables are masked in logs and encrypted at rest.

Why this answer

Option B is correct because marking variables as 'secret' in Azure Pipelines ensures they are masked in logs and encrypted. Option A is wrong because environment variables are still visible in logs unless masked. Option C is wrong because Azure Key Vault can store secrets, but you still need to map them as secret variables to mask them.

Option D is wrong because pipeline variables with 'isSecret: false' are visible.

Full explanation →
476
MCQhard

Refer to the exhibit. This is a deployment job definition in a multi-stage YAML pipeline. The deployment fails because the Kubernetes service connection 'aks-prod' cannot be found. What is the most likely cause?

A.The approval for production environment is blocking the deployment.
B.The agent pool does not have access to the AKS cluster.
C.The service connection 'aks-prod' does not exist in the Azure DevOps project.
D.The namespace 'prod' does not exist in the AKS cluster.
AnswerC

The YAML references a service connection that must be created in the project.

Why this answer

The service connection name in YAML must match the name defined in Azure DevOps project settings. Option A is wrong because agent pool configuration does not affect service connection resolution. Option C is wrong because the approval only affects gate, not service connection existence.

Option D is wrong because namespace is a Kubernetes concept, not related to service connection.

Full explanation →
477
Multi-Selectmedium

Which TWO benefits does using deployment groups provide in Azure Pipelines? (Choose two.)

Select 2 answers
A.You can deploy to a specific set of target servers (e.g., all web servers in a farm).
B.They enable rolling deployments with health validation.
C.You can assign multiple deployment groups to a single agent.
D.Each target server must have its own agent.
E.Deployment groups can only be used with classic release pipelines.
AnswersA, B

Deployment groups are collections of target servers for parallel deployments.

Why this answer

Options A and D are correct. A: Deployment groups allow targeting specific sets of servers for deployments. D: They support rolling deployments with health checks.

Option B is wrong because you can have multiple agents per deployment group. Option C is wrong because deployment groups are not limited to classic releases; they work with YAML pipelines too. Option E is wrong because agents in deployment groups are registered to the group, not individual machines.

Full explanation →
478
MCQeasy

Your organization uses Azure DevOps. You have a classic release pipeline that deploys to multiple stages: Dev, QA, and Prod. Each stage has a pre-deployment approval gate. Recently, the QA team complained that they are not receiving approval notifications. You have verified that the approval configuration is correct and the approvers are members of the 'QA Approvers' group. The release pipeline is set to send email notifications to the approvers. However, the QA approvers report they do not receive any emails when a release is pending their approval. What should you check first?

A.Ask the QA team to check their spam folder.
B.Verify that the organization-level notification settings allow email notifications for approvals.
C.Add a 'Send email' task in the pipeline before the approval gate.
D.Check the 'Release Pipeline' logs for a warning about email delivery failure.
AnswerB

If email notifications are disabled at the organization level, approvers won't receive emails.

Why this answer

Option A is correct because the most common cause of missing notifications is incorrect email settings in the Azure DevOps organization. Option B is wrong because the notification is sent by Azure DevOps, not via a separate pipeline. Option C is wrong because the pipeline does not have a separate notification step.

Option D is wrong because the approval step is already on the stage; the issue is notification delivery.

Full explanation →
479
Matchingmedium

Match each Azure DevOps extension type to its example.

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

Concepts
Matches

SonarQube analysis

Burnup chart

Slack integration on work item update

Terraform task for Azure Pipelines

Why these pairings

Extension categories in Azure DevOps Marketplace.

Full explanation →
480
Multi-Selectmedium

Your team uses Azure Repos with a Git branching strategy. You need to ensure that all changes to the release branch are reviewed by at least two approvers and that builds succeed before merging. Which TWO branch policy settings should you enable?

Select 2 answers
A.Build validation
B.Work item linking
C.Minimum number of reviewers (set to 2)
D.Require a clean fast-forward merge
E.Require a merge commit
AnswersA, C

Ensures builds succeed before merging.

Why this answer

Option B (minimum number of reviewers) and Option C (build validation) are correct. Option A is wrong because it's not a standard policy. Option D is wrong because it's for linear history.

Option E is wrong because it's not a policy setting.

Full explanation →
481
MCQmedium

Refer to the exhibit. You run an Azure CLI command during a pipeline to get the state of a web app. The output shows the state as 'Running'. You want to ensure the pipeline only proceeds if the state is 'Running'. Which task should you use to evaluate the condition?

A.A Download Build Artifacts task that verifies the state.
B.A Bash task that runs 'az webapp show' and checks the state.
C.A PowerShell task that checks the state variable and exits with code 1 if not 'Running'.
D.A Publish Test Results task configured to check the state.
AnswerB, C

A Bash task can run the CLI and check the state using jq or grep.

Why this answer

The Bash task can run a script to check the state and set a variable or fail. Option A is wrong because PowerShell task is also valid but Bash is shown. Option B is wrong because PublishTestResults is for test results.

Option D is wrong because DownloadBuildArtifacts downloads artifacts.

Full explanation →
482
Drag & Dropmedium

Drag and drop the steps to implement a disaster recovery plan for Azure App Service into the correct order.

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

Steps
Order

Why this order

Disaster recovery begins with identification, then backup, geo-replication, failover configuration, and testing.

Full explanation →
483
Multi-Selecteasy

Which TWO are valid Git merge strategies available in Azure Repos pull requests?

Select 2 answers
A.Semi-linear merge
B.Merge commit (no fast-forward)
C.Fast-forward only
D.Squash merge
E.Rebase only
AnswersA, B

Rebases commits onto target then creates a merge commit.

Why this answer

Azure Repos pull requests offer three merge strategies: 'Merge commit (no fast-forward)', 'Semi-linear merge', and 'Squash merge'. 'Semi-linear merge' (Option A) creates a merge commit but ensures the source branch is rebased onto the target branch first, resulting in a linear history with a merge commit. 'Merge commit (no fast-forward)' (Option B) creates a merge commit that preserves the full history of both branches without any rebasing.

Exam trap

The trap here is that candidates often confuse the available merge strategies in Azure Repos with those in other Git hosting platforms (like GitHub or GitLab), or they mistakenly think 'Fast-forward only' and 'Rebase only' are separate strategies when they are actually sub-behaviors or not offered at all.

Full explanation →
484
MCQmedium

Your organization is adopting GitHub Actions for CI/CD. You need to ensure that only approved actions from your enterprise can be used in workflows. What should you configure?

A.Use a third-party tool to scan workflows for disallowed actions after each commit.
B.Set the enterprise policy to 'Allow all actions' and rely on code review.
C.Configure repository permissions to restrict actions to only those created by your organization.
D.Set the enterprise policy to 'Allow only specific actions' and add approved actions.
AnswerD

This enforces that only approved actions can be used across the enterprise.

Why this answer

Option C is correct because GitHub's 'Allow only specific actions' policy lets you restrict actions to a list of approved actions or marketplaces. Option A is wrong because the 'Allow all actions' policy does not restrict. Option B is wrong because GitHub Actions permissions are per repository, not enterprise-wide restriction.

Option D is wrong because using third-party actions without restriction is against the requirement.

Full explanation →
485
MCQmedium

You are designing a multi-stage YAML pipeline for a .NET Core application. The pipeline must build, test, and deploy to a staging environment. You want to ensure that the deployment stage only runs if the build and test stages succeed, and that the staging deployment uses the exact same bits that were built. Which strategy should you use?

A.Set up a release pipeline that uses the same build artifact and requires manual approval.
B.Create separate stages for build, test, and deploy. Use the 'dependsOn' keyword and publish artifact in build stage, download in deploy stage.
C.Use a build trigger on the staging branch to deploy after each commit, ignoring test results.
D.Define the pipeline with a single stage and use a condition to skip test on failure.
AnswerB

DependsOn ensures sequential execution, and artifacts preserve build output.

Why this answer

Option B is correct because using pipeline artifacts with dependency on build stage ensures the deployment uses the exact build output from the previous successful stage. Option A is wrong because the standard YAML template doesn't automatically share artifacts. Option C is wrong because triggers would not enforce stage dependency.

Option D is wrong because manual intervention requires human approval, not automatic dependency.

Full explanation →
486
Multi-Selectmedium

Which TWO actions should you take to ensure that a build pipeline fails if code coverage drops below 80%?

Select 2 answers
A.Use the PublishTestResults@2 task with the 'codeCoverage' option.
B.Add a script task that parses the coverage file and exits with non-zero if below threshold.
C.Use the PublishCodeCoverageResults@1 task to publish coverage data.
D.Use the ReportGenerator@5 task to create a coverage report.
E.Use the CopyFiles@2 task to move coverage files to a shared location.
AnswersB, C

A script can enforce the threshold by failing the step.

Why this answer

Options A and C are correct. The Publish Code Coverage Results task can publish coverage data, and a script can check the coverage and fail the build if below threshold. Option B is wrong because the Publish Test Results task is for test results, not coverage.

Option D is wrong because the Report Generator task generates reports but does not enforce thresholds. Option E is wrong because the Copy Files task does not analyze coverage.

Full explanation →
487
MCQhard

You are implementing a build pipeline for a .NET application that uses GitHub Advanced Security (GHAS) for code scanning. The pipeline must run CodeQL analysis on every pull request to the main branch. You have added the CodeQL task to the pipeline. However, the analysis results are not appearing in the 'Security' tab of the repository on GitHub. What is the most likely cause?

A.The pipeline is missing the 'Publish Security Analysis Logs' step to upload SARIF results to GitHub.
B.The GitHub repository is private, so security alerts are disabled.
C.The .NET project is not supported by CodeQL.
D.CodeQL analysis is not supported on pull request triggers.
AnswerA

Results need to be uploaded to appear in Security tab.

Why this answer

Option D is correct because CodeQL results are uploaded as SARIF files, and the 'CodeQL Analysis' task includes an option to upload results to GitHub. If that step is omitted or fails, results won't appear. Option A is wrong because CodeQL supports pull request analysis.

Option B is wrong because CodeQL works with .NET. Option C is wrong because GitHub Advanced Security is available even in private repos.

Full explanation →
488
MCQmedium

Your team uses GitHub Actions for CI/CD and needs to ensure that secrets such as Azure service principal credentials are not exposed in logs. What is the best practice to prevent secret exposure?

A.Store secrets as GitHub Actions secrets and reference them in workflows
B.Store secrets in the workflow YAML file
C.Use environment protection rules to mask secrets
D.Encrypt workflow logs after the run completes
AnswerA

GitHub automatically redacts secrets in logs when referenced correctly.

Why this answer

Option C is correct because GitHub automatically redacts secrets in workflow logs. Option A is wrong because storing secrets in YAML files is insecure. Option B is wrong because environment protection rules are for approvals, not redaction.

Option D is wrong because encrypting logs does not prevent exposure in transit.

Full explanation →
489
Multi-Selecteasy

Which TWO triggers can start a release in Azure Pipelines?

Select 2 answers
A.Continuous integration
B.Schedule
C.Build completion
D.Work item state change
E.Pull request
AnswersB, C

A schedule trigger starts a release at a specified time.

Why this answer

In Azure Pipelines, a release can be triggered by a schedule, which allows you to define a cron-based trigger to deploy at specific times (e.g., nightly builds). The 'Build completion' trigger starts a release when a specific build pipeline completes, enabling chained deployments. Both are native release triggers in classic release pipelines.

Exam trap

The trap here is that candidates confuse triggers that apply to build pipelines (CI, PR) with those that apply to release pipelines, leading them to select 'Continuous integration' or 'Pull request' as valid release triggers.

Full explanation →
490
MCQeasy

Your team uses GitHub Actions for CI/CD. You need to ensure that only specific branches can trigger the deployment workflow to production. Which workflow trigger should you configure?

A.on: push: branches: [main]
B.on: pull_request: branches: [main]
C.on: workflow_dispatch: inputs: branch: description: 'Select branch'
D.on: schedule: cron: '0 0 * * *'
AnswerA

Push trigger with branch filter limits to main.

Why this answer

Option C is correct because the 'on: push: branches: [main]' trigger restricts workflow to pushes on main. Option A is wrong because pull_request triggers on PRs, not branches. Option B is wrong because schedule triggers on cron.

Option D is wrong because workflow_dispatch is manual.

Full explanation →
491
MCQhard

You are configuring a branch policy for the main branch using the Azure DevOps REST API. The JSON above is the policy configuration. A developer pushes a new commit to an existing pull request. What happens to the existing approvals?

A.The existing approvals remain valid.
B.The policy blocks the push until re-reviewed.
C.The pull request is automatically rejected.
D.All existing approvals are reset.
AnswerA

Correct: resetOnPush: false means approvals are not reset.

Why this answer

Option A is correct because, by default, Azure DevOps branch policies do not automatically reset approvals when a new commit is pushed to a pull request. The policy configuration shown does not include the 'resetOnPush' property (or its equivalent in the REST API), which is required to invalidate existing approvals. Without that setting, approvals remain valid even after new commits are pushed.

Exam trap

The trap here is that candidates often assume any new commit to a pull request automatically resets approvals, but Azure DevOps requires explicit configuration (the 'resetOnPush' property) to enable that behavior.

How to eliminate wrong answers

Option B is wrong because the policy does not block the push; Azure DevOps allows pushes to pull requests by default, and only blocks them if a 'Require a minimum number of reviewers' policy with 'Reset on push' is enabled. Option C is wrong because the pull request is not automatically rejected; rejection only occurs if the policy explicitly requires re-approval after a push, which is not configured here. Option D is wrong because approvals are not reset unless the policy configuration includes the 'resetOnPush' property set to true; without it, existing approvals persist.

Full explanation →
492
MCQmedium

Your team uses a multi-stage YAML pipeline to build and deploy a .NET Core application. The build stage runs successfully, but the deployment to a Linux web app fails with an error indicating that the Kudu service cannot start because the startup command is missing. What is the most likely cause?

A.The pipeline is missing the 'AzureWebApp@1' task with a 'StartupCommand' parameter.
B.The service connection lacks permission to access the web app.
C.The web app is configured with a Windows runtime stack.
D.The build output does not include the web.config file.
AnswerA

For Linux web apps, the startup command must be provided in the task or in the app settings.

Why this answer

The Azure Web App task for Linux web apps requires a startup command to be specified if the container image does not have a default entry point. Without it, Kudu cannot start.

Full explanation →
493
MCQeasy

Your team wants to include a manual validation step before deploying to production. Which Azure Pipelines feature should they use?

A.Pipeline decorators.
B.Environment checks.
C.Pre-deployment conditions with approval gates.
D.Post-deployment gates.
AnswerC

Approval gates require manual approval before deployment.

Why this answer

Pre-deployment conditions with approval gates allow you to require manual approval before a release is deployed to a specific stage, such as production. This is the correct feature because it explicitly pauses the pipeline before deployment and waits for designated approvers to validate the build, meeting the requirement for a manual validation step.

Exam trap

The trap here is confusing environment checks (automated) with approval gates (manual), leading candidates to select option B because they think 'checks' include manual validation, but environment checks are strictly automated and cannot require human intervention.

How to eliminate wrong answers

Option A is wrong because pipeline decorators are used to automatically inject additional steps (e.g., security scans) into every pipeline run, not to pause for manual validation. Option B is wrong because environment checks are automated evaluations (e.g., resource availability, compliance) that run before deployment, but they do not provide a manual approval mechanism. Option D is wrong because post-deployment gates run after the deployment to production has already occurred, so they cannot serve as a manual validation step before deployment.

Full explanation →
494
Multi-Selectmedium

Your team uses GitHub Advanced Security to identify vulnerabilities in code. Which TWO actions can you take to ensure that critical security alerts are addressed before code is merged?

Select 2 answers
A.Enable secret scanning push protection.
B.Create a repository rule that allows bypassing pull request requirements.
C.Configure branch protection rules to require status checks from code scanning.
D.Enable Dependabot auto-merge for pull requests.
E.Use pull request annotations to display code scanning alerts.
AnswersC, E

Status checks from code scanning can block merges if critical alerts are found.

Why this answer

Branch protection rules can require passing status checks from code scanning and secret scanning. Pull request annotations show alerts directly in the PR. Dependabot auto-merge and repository rules for bypassing are not relevant for blocking merges based on security alerts.

Full explanation →
495
Multi-Selecthard

You are building a comprehensive instrumentation strategy for a large-scale Azure DevOps environment. You need to ensure that all pipeline events (build, release, test) are automatically tracked and correlated with application performance data. Which THREE components should you include?

Select 3 answers
A.A shared Correlation ID that flows from pipeline to application.
B.Azure Monitor Workbooks to visualize pipeline data.
C.Custom pipeline tasks that send telemetry to Application Insights.
D.Azure Boards to track pipeline run metadata.
E.OpenTelemetry SDK in the application to emit trace context.
AnswersA, C, E

Enables end-to-end correlation.

Why this answer

Options A, D, and E are correct. Option A: OpenTelemetry SDK in the application collects performance data with correlation IDs. Option D: Custom pipeline tasks emit telemetry to Application Insights.

Option E: Using the same Correlation ID across pipeline and application enables correlation. Option B is wrong because Azure Boards does not track pipeline events. Option C is wrong because Azure Monitor Workbooks are visualization tools, not data collection.

Full explanation →
496
MCQhard

Your organization uses a monorepo in Azure Repos containing multiple microservices. You need to design a build pipeline that only builds and tests the services that have changed in a given commit, to optimize build times. The pipeline must trigger on any push to any branch, but only the affected services should be built. You also need to ensure that dependent services are rebuilt if their dependencies change. The services are located in subdirectories: /services/serviceA, /services/serviceB, etc. Each service has a Dockerfile and a unit test project. You plan to use a script to determine which services changed. Which approach should you use to implement this pipeline?

A.Use a script step to determine which services changed, then output variables to dynamically create a job matrix or use the 'each' keyword to iterate over changed services.
B.Create a multi-stage pipeline where each stage represents a service, and use a 'dependsOn' condition to run stages only if the corresponding service changed.
C.Create a single job that runs all unit tests for all services on every commit. Use caching to speed up the build.
D.Create a job for each service that runs in parallel on every commit. Use conditions to skip jobs if the service has not changed, but the conditions would need to check every service, which is complex.
AnswerA

This allows the pipeline to dynamically build only the affected services.

Why this answer

Option D is correct because the pipeline can use a script to detect changed files in the commit, map them to services, and then dynamically create jobs or stages for each affected service. This is efficient and flexible. Option A is wrong because using a single job that runs all tests ignores the requirement to only build changed services.

Option B is wrong because using multiple jobs for all services would build everything every time, not optimizing. Option C is wrong because using a multi-stage pipeline with stages for each service would also build all services every time.

Full explanation →
497
MCQmedium

Your organization needs to enforce that every commit to the main branch in Azure Repos is associated with a work item from Azure Boards. What should you configure?

A.Add a branch policy on main that requires a linked work item for all pushes.
B.Create a pre-receive hook in the repository to reject commits without a work item.
C.Enable the 'Gated check-in' option in the branch policy for main.
D.Configure a pull request policy that requires a linked work item, and enforce that all merges to main are via pull request.
AnswerA

Azure Repos branch policies can require linked work items for any push to the branch.

Why this answer

Option A is correct because Azure Repos branch policies include a specific policy to 'Require a linked work item' for all pushes to a branch. This policy enforces that every commit pushed directly to the main branch must be associated with a work item from Azure Boards, ensuring traceability and compliance with your organization's requirements.

Exam trap

The trap here is that candidates often confuse 'Require a linked work item' branch policy with pull request policies, but the question explicitly asks for enforcement on 'every commit to the main branch,' which includes direct pushes, so the correct answer is the branch policy that applies to all pushes, not just pull request merges.

How to eliminate wrong answers

Option B is wrong because Azure Repos does not support pre-receive hooks; that feature is specific to GitHub or on-premises Git servers. Option C is wrong because 'Gated check-in' (also known as 'Build validation') is a branch policy that triggers a build before accepting a push, but it does not enforce work item association. Option D is wrong because while a pull request policy requiring a linked work item can enforce work item association for PR merges, it does not cover direct pushes to main; to enforce the requirement for all commits, you must also restrict direct pushes by requiring pull requests, which is not stated in the option.

Full explanation →
498
MCQeasy

You need to create a build pipeline that runs on a Microsoft-hosted agent. You want to use the latest Ubuntu image. Which YAML snippet should you use?

A.pool: vmImage: 'ubuntu-latest'
B.pool: name: 'ubuntu-latest'
C.agent: vmImage: 'ubuntu-latest'
D.resources: vmImage: 'ubuntu-latest'
AnswerA

Why this answer

Option A is correct because in Azure Pipelines YAML, the `pool` keyword is used to specify the agent pool, and `vmImage` is a sub-property that defines the virtual machine image for Microsoft-hosted agents. Setting `vmImage: 'ubuntu-latest'` within the `pool` section selects the latest Ubuntu LTS image provided by Microsoft, ensuring the build runs on a current, maintained environment.

Exam trap

The trap here is that candidates confuse the `pool.name` property (used for self-hosted agents) with `pool.vmImage` (used for Microsoft-hosted agents), leading them to select option B, or they mistakenly use `agent` or `resources` as top-level keys for specifying the VM image.

Why the other options are wrong

B

The 'name' property is for agent pools, not VM images.

C

'agent' is not a valid top-level key; use 'pool'.

D

Resources are for external resources, not agent specification.

Full explanation →
499
Multi-Selectmedium

Which TWO are valid ways to pass build artifacts from one stage to another in a multi-stage YAML pipeline in Azure Pipelines?

Select 2 answers
A.Use the Pipeline Artifact task to publish artifacts, which are automatically available to subsequent stages without download.
B.Use the Publish Pipeline Artifact task in the first stage and Download Pipeline Artifact task in the second stage.
C.Use the Publish Build Artifacts task and then the Download Build Artifacts task.
D.Use the Copy Files task to copy artifacts to a shared network drive.
E.Define variables in the first stage and reference them in the second stage.
AnswersB, D

This is the standard method to share artifacts between stages.

Why this answer

Publishing and downloading artifacts is the standard way. Option C is misleading because pipeline artifacts are a type of artifact. Option D is wrong because stages run sequentially? Actually stages can run in parallel, but publishing/downloading is still needed.

Option E is wrong because variables are not for artifacts.

Full explanation →
500
MCQmedium

Your team uses a multi-stage YAML pipeline. The 'Build' stage compiles the code and runs unit tests. The 'Deploy' stage deploys to a staging environment. You notice that if the 'Build' stage fails, the 'Deploy' stage still starts because it depends on a condition that always evaluates to true. How should you modify the pipeline to prevent the 'Deploy' stage from running if the 'Build' stage fails?

A.Add 'condition: succeeded()' to the Deploy stage.
B.Add 'condition: eq(variables['Build.Succeeded'], 'true')' to the Deploy stage.
C.Add 'condition: and(succeeded(), eq(variables['Build.Succeeded'], 'true'))' to the Deploy stage.
D.Add 'dependsOn: Build' to the Deploy stage.
AnswerA

succeeded() checks that all previous stages succeeded.

Why this answer

Option B is correct because using 'condition: succeeded()' ensures that the stage only runs if all previous stages succeeded. Option A is wrong because 'dependsOn: Build' alone does not enforce success. Option C is wrong because 'condition: eq(variables['Build.Succeeded'], 'true')' is not the recommended way.

Option D is wrong because 'condition: and(succeeded(), eq(variables['Build.Succeeded'], 'true'))' is redundant.

Full explanation →
501
MCQhard

You are deploying an ARM template using the parameters file shown. The deployment fails with an error that the referenced secret cannot be found. What is the most likely cause?

A.The secret name in the parameters file does not match the actual secret name in Key Vault.
B.The Key Vault does not have an access policy granting the deployment user 'Get' secret permission.
C.The resource group 'rg-kv' does not exist.
D.The Key Vault is in a different region than the deployment.
AnswerA

Typo or mismatch causes not found.

Why this answer

Option A is correct because the error 'referenced secret cannot be found' directly indicates that the secret name specified in the parameters file does not match the actual secret name stored in Azure Key Vault. ARM template deployment uses the `reference()` function to retrieve the secret value at deployment time, and if the secret name is misspelled or incorrect, the deployment fails with this specific error.

Exam trap

The trap here is that candidates often confuse the 'secret not found' error with permission issues (Option B), but the error message specifically indicates the secret name mismatch, not an access policy problem.

How to eliminate wrong answers

Option B is wrong because an incorrect access policy would produce a different error, such as 'Access denied' or 'Forbidden', not 'secret cannot be found'. Option C is wrong because if the resource group 'rg-kv' did not exist, the deployment would fail with a resource group not found error, not a secret not found error. Option D is wrong because Key Vault region does not affect secret retrieval; ARM templates can reference Key Vaults in any region as long as the deployment user has appropriate permissions.

Full explanation →
502
Multi-Selectmedium

Which TWO actions should you take to implement a gated check-in policy in Azure Repos that triggers a build before changes are merged?

Select 2 answers
A.Configure a build validation policy on the branch
B.Create a branch policy that requires a successful build to complete
C.Enable continuous integration (CI) trigger on the build pipeline
D.Set the build to run a 'pre-merge' validation
E.Require a manual build before merging
AnswersA, B

A build validation policy triggers a build when a pull request is created.

Why this answer

Option A is correct because a build validation policy triggers a build on pull request. Option C is correct because a branch policy is required to enforce the build. Option B is wrong because a pre-merge build is part of build validation, not a separate policy.

Option D is wrong because manual builds are not automatic. Option E is wrong because a CI trigger is for commits, not pull requests.

Full explanation →
503
Multi-Selecthard

Which THREE are valid approaches to securely store secrets used in Azure Pipelines? (Choose three.)

Select 3 answers
A.Inline secret variables defined in the YAML file
B.Secret variables defined in the pipeline UI
C.Azure Key Vault task to fetch secrets at runtime
D.Variable groups linked to Azure Key Vault
E.Environment variables set on the build agent
AnswersB, C, D

Secret variables in the UI are encrypted and masked in logs.

Why this answer

Variable groups with Azure Key Vault integration, Azure Key Vault tasks, and Azure Pipelines secret variables are all secure ways to store secrets. Option B is wrong because storing secrets in YAML files is insecure. Option D is wrong because environment variables in build agents are not encrypted.

Full explanation →
504
Matchingmedium

Match each Azure DevOps service to its primary function.

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

Concepts
Matches

Agile planning and work tracking

Source control with Git or TFVC

CI/CD build and release automation

Manual and exploratory testing

Package management and sharing

Why these pairings

These are the five main Azure DevOps services.

Full explanation →
505
MCQmedium

Your build pipeline uses a Microsoft-hosted agent. The pipeline fails intermittently with 'Error: No space left on device'. What is the most effective solution?

A.Increase the agent's temporary storage by setting the TMP variable.
B.Switch to a self-hosted agent with more disk space.
C.Add a step to clean up temporary files before the build completes.
D.Configure the pipeline to use more parallel jobs.
AnswerC

Removing unnecessary files reduces disk usage and prevents space issues.

Why this answer

Option C is correct because the best approach is to reduce the build artifacts footprint by cleaning up unnecessary files before the build completes. Option A is wrong because using a self-hosted agent might not address the disk space issue if the same amount of data is produced. Option B is wrong because increasing the agent's disk space is not possible with Microsoft-hosted agents.

Option D is wrong because parallel jobs do not affect disk space on a single agent.

Full explanation →
506
MCQhard

A development team uses a forking workflow in Azure Repos. They want to ensure that only specific users can create forks of the main repository. How can they achieve this?

A.Use branch security to restrict who can create forks
B.Set branch policies on the main branch to prevent forks
C.Configure the repository to disable forks globally
D.Remove the 'Create Fork' permission from all users except the required group
AnswerA

Under repository settings, you can set security by group for 'Create Fork' permission.

Why this answer

In Azure Repos, the ability to create forks is controlled by a specific permission called 'Create Fork' at the repository level. By default, all contributors have this permission. To restrict fork creation to only specific users, you must remove the 'Create Fork' permission from all users and groups, then explicitly grant it only to the desired group or individuals.

This is a permission-based security model, not a branch policy or global toggle.

Exam trap

The trap here is that candidates often confuse branch policies (which control branch-specific actions like pull requests) with repository-level permissions (which control actions like creating forks), leading them to incorrectly select branch security or branch policies as the solution.

How to eliminate wrong answers

Option A is correct because it directly addresses the permission control needed. Option B is wrong because branch policies on the main branch (e.g., requiring pull request reviews) do not control who can create forks; they only enforce rules on commits and merges to that branch. Option C is wrong because Azure Repos does not have a global 'disable forks' setting; fork creation is controlled per-repository via permissions.

Option D is wrong because 'Create Fork' is not a permission that can be removed from users; it is a permission that must be explicitly denied or granted, and the correct approach is to remove the permission from all users and grant it only to the required group.

Full explanation →
507
MCQhard

Your organization uses GitHub Actions for CI/CD. A workflow that deploys to production uses a secret stored in GitHub Actions secrets. The secret is exposed in the logs due to a debug step. What is the most effective way to prevent future exposure?

A.Remove the debug step from the workflow.
B.Use the ::add-mask:: command in the workflow to mask the secret in logs.
C.Delete the compromised secret and create a new one.
D.Enable secret scanning and push protection for the repository.
AnswerD

Secret scanning detects and blocks secrets from being exposed in logs or commits.

Why this answer

Option D is correct because enabling secret scanning and push protection for the repository proactively detects and blocks secrets (including GitHub Actions secrets) from being exposed in logs or commits. This is the most effective long-term solution as it prevents future exposure at the platform level, rather than relying on manual remediation or masking that can be bypassed.

Exam trap

The trap here is that candidates often focus on immediate remediation (deleting the secret or masking logs) rather than the preventive, platform-level control that secret scanning and push protection provide, which is the most effective way to prevent future exposure.

How to eliminate wrong answers

Option A is wrong because simply removing the debug step does not prevent future exposure if other steps or workflows inadvertently log secrets; it is a reactive, not preventive, measure. Option B is wrong because the ::add-mask:: command only masks the secret in the current workflow run's logs after it has already been used, and it does not prevent the secret from being exposed in other runs or if the secret value changes; it also requires manual addition to every workflow. Option C is wrong because deleting and recreating the secret only addresses the immediate compromise but does not prevent the same mistake from happening again with the new secret; it lacks a preventive control.

Full explanation →
508
Multi-Selecthard

Which THREE conditions must be met for you to use the 'Approvals' feature in Azure Pipelines to control deployments to a production environment? (Choose three.)

Select 3 answers
A.The approver must be an individual user, not a group.
B.The approval must be configured in the release pipeline's pre-deployment conditions.
C.The approver must have the 'Approve pipeline permissions' permission for the environment.
D.The pipeline must be a Release Pipeline or a YAML pipeline that uses the 'environment' resource.
E.You must create an environment in Azure Pipelines and add an approval check to it.
AnswersC, D, E

Only users with this permission can approve.

Why this answer

Options A, B, and D are correct. Option A: The pipeline must be a release pipeline or a YAML pipeline with environment resource checks. Option B: You must define an environment and add an approval check to it.

Option D: The user approving must have the 'Approve pipeline permissions' permission (or be a member of the Approvers group). Option C is wrong because approvers can be groups, not just individuals. Option E is wrong because approvals can be set on environments, not just stages.

Full explanation →
509
MCQeasy

Your team uses Azure Pipelines for CI/CD. The pipeline builds a Docker image and pushes it to Azure Container Registry (ACR). You need to ensure that only the main branch triggers a build of the Docker image. What should you configure in the pipeline YAML?

A.Set 'pr: branches: include: - main'
B.Add a condition: 'eq(variables['Build.SourceBranch'], 'refs/heads/main')' to the job.
C.Set 'trigger: branches: include: - *'
D.Set 'trigger: branches: include: - main'
AnswerD

This ensures the pipeline only triggers on commits to main.

Why this answer

Option A is correct because the 'trigger' section with branch inclusion filters which branches trigger the pipeline. Option B is incorrect because it triggers on any branch. Option C is incorrect because the 'pr' trigger is for pull requests.

Option D is incorrect because the condition evaluates at runtime, not at trigger time.

Full explanation →
510
MCQmedium

You are configuring a multi-stage YAML pipeline that builds a .NET Core application and deploys it to Azure Kubernetes Service (AKS). The build stage produces a container image that is pushed to Azure Container Registry (ACR). The deploy stage needs to use the image from ACR. How should you pass the image tag from the build stage to the deploy stage?

A.Write the image tag to a file and publish it as a build artifact, then read it in the deploy stage.
B.Define a pipeline variable at the top level and set it in the build stage.
C.Use the 'stageDependencies' syntax to retrieve the output variable of a job in the build stage.
D.Use the 'Azure CLI' task in the deploy stage to query the ACR for the latest image tag.
AnswerC

Output variables from one stage can be consumed in another using dependencies.

Why this answer

The recommended way to pass variables between stages is to use 'stageDependencies' to access the output of a previous job. Option A is correct. Option B is wrong because pipeline variables defined at the top scope are not automatically available to subsequent stages unless explicitly output.

Option C is wrong because build artifacts are for files, not variables. Option D is wrong because the ACR task does not automatically set a variable for the image tag.

Full explanation →
511
MCQhard

Your organization uses GitHub Actions with self-hosted runners on Azure virtual machines. You notice that some workflows are taking longer than expected because runners are busy. You need to improve the performance without adding more permanent runners. Which solution should you implement?

A.Migrate all workflows to GitHub-hosted runners.
B.Reduce the number of concurrent jobs in each workflow.
C.Implement auto-scaling for self-hosted runners using a scale set or Kubernetes-based runner controller.
D.Increase the size of the existing self-hosted runner VMs to handle more jobs.
AnswerC

Auto-scaling adds runners during peak demand and removes when idle.

Why this answer

GitHub Actions supports auto-scaling for self-hosted runners using scaling applications like 'actions-runner-controller' for Kubernetes or custom scripts. Option A is correct because it dynamically adds/removes runners based on demand. Option B increases cost and maintenance.

Option C is for GitHub-hosted runners. Option D reduces wait but doesn't address root cause.

Full explanation →
512
Multi-Selecthard

Your team uses Azure Boards and has several work item types (Epic, Feature, User Story, Bug, Issue). They want to enforce a rule that bugs can only be linked to Features, not directly to Epics. Which TWO actions should you perform?

Select 2 answers
A.Customize the Epic work item type to remove the 'Child' link to Bug.
B.Configure the Epic work item type to require a link to a Bug.
C.Use a work item rule to set the parent type to Feature when a Bug is created.
D.Add a rule to the Bug work item type that prohibits linking to Epics.
E.Customize the Bug work item type to remove the 'Parent' link to Epic.
AnswersA, E

This prevents users from linking an Epic to a Bug as a child.

Why this answer

Option A is correct because by customizing the Epic work item type to remove the 'Child' link type to Bug, you prevent any Bug from being linked as a child of an Epic. This enforces the rule that Bugs can only be linked to Features. Option E is correct because by customizing the Bug work item type to remove the 'Parent' link type to Epic, you prevent a Bug from having an Epic as its parent, which directly enforces the desired linking restriction.

Exam trap

The trap here is that candidates often assume work item rules can enforce link restrictions, but Azure Boards rules only control field values and state transitions, not link types, so the correct approach is to customize the work item type definitions to remove the unwanted link relationships.

Full explanation →
513
MCQeasy

Your build pipeline fails intermittently with the error: 'The job running on agent 'Azure Pipelines' exceeded the maximum execution time of 60 minutes.' How can you resolve this issue?

A.Increase the 'timeoutInMinutes' property in the pipeline YAML for the job.
B.Split the pipeline into multiple stages to reduce job duration.
C.Enable parallel jobs to run the pipeline faster.
D.Use a self-hosted agent with more CPU cores.
AnswerA

Increasing timeout prevents premature termination.

Why this answer

Option A is correct because increasing the timeout allows the job to run longer. Option B is wrong because using a self-hosted agent does not change timeout limits. Option C is wrong because parallel jobs affect concurrency, not duration.

Option D is wrong because reducing stages may not address the timeout.

Full explanation →
514
MCQhard

Refer to the exhibit. A developer is working on the feature/login branch and wants to ensure that the latest changes from main are incorporated before creating a pull request. Which command should the developer run next?

A.git rebase --abort
B.git merge main
C.git push origin feature/login
D.git pull --rebase origin main
AnswerD

This fetches the latest main and rebases the feature branch onto it, incorporating the latest changes and keeping history linear.

Why this answer

The exhibit shows that the feature/login branch has a merge commit from main (3a1b2c3) which means main was already merged into feature/login. However, the local branch is ahead of origin by 1 commit (the merge commit). The developer wants to incorporate the latest changes from main.

Since main has advanced (d4e5f6a is the latest on origin/main), the developer should pull the latest main and rebase or merge again. The best practice is to rebase onto the latest main to maintain a linear history. Therefore, the developer should run 'git pull --rebase origin main' to fetch and rebase.

Full explanation →
515
Multi-Selectmedium

Which TWO are valid strategies for reducing build times in Azure Pipelines? (Choose two.)

Select 2 answers
A.Reduce the number of parallel jobs and increase the number of steps in a single job.
B.Remove unit tests from the build pipeline and run them only in the release pipeline.
C.Implement caching for package dependencies (e.g., npm, NuGet, Maven) to avoid restoring on every build.
D.Configure incremental builds by enabling 'Build in parallel' and using 'msbuild' or 'dotnet' build with appropriate flags to skip unchanged projects.
E.Increase the number of agents in the pool and run all jobs on the same agent.
AnswersC, D

Caching reduces time spent downloading dependencies.

Why this answer

Options A and D are correct. Option A: Using incremental builds (e.g., with the 'dotnet build' incremental feature) reduces build time by only rebuilding changed files. Option D: Using a build cache (e.g., for NuGet packages, npm, or Maven) avoids downloading and restoring dependencies on every build.

Option B is wrong because using multiple agents without parallelization does not reduce build time. Option C is wrong because using a single agent with more steps increases build time. Option E is wrong because disabling tests is not a valid strategy as it compromises quality.

Full explanation →
516
Multi-Selectmedium

Your team uses Azure DevOps with a Git repository. You want to enforce that all pull requests to main must have at least one reviewer from the 'security' group. Which two configurations are required? (Choose two.)

Select 2 answers
A.Configure automatic reviewers for the security group.
B.Add the security group as a required reviewer for the main branch policy.
C.Create a repository policy for the main branch.
D.Set the minimum number of reviewers to 1 in the branch policy.
E.Configure a branch protection rule in GitHub.
AnswersB, D

Required reviewers enforce specific groups.

Why this answer

Option B is correct because you can add the security group as a required reviewer. Option D is correct because you need to set the minimum number of reviewers to 1. Option A is wrong because a branch policy is needed, not a repository policy.

Option C is wrong because automatic reviewers are separate from required reviewers. Option E is wrong because a branch protection rule is a GitHub concept, not Azure Repos.

Full explanation →
517
MCQmedium

Your team uses GitHub and wants to automatically link pull requests to work items in Azure Boards. What should you configure?

A.Add a repository secret with Azure Boards connection string
B.Install the Azure Boards app for GitHub and configure the integration
C.Configure branch protection rules to require a linked work item
D.Create a GitHub Actions workflow that posts comments to Azure Boards
AnswerB

This integration provides automatic linking.

Why this answer

The Azure Boards app for GitHub is the official integration that synchronizes work items with GitHub commits, branches, and pull requests. Once installed and configured, it automatically links pull requests to Azure Boards work items based on mention patterns (e.g., 'AB#123') in the PR description or commit messages, enabling traceability without custom scripting.

Exam trap

The trap here is that candidates confuse 'requiring a linked work item' (a branch protection rule) with 'automatically linking work items' (the integration), leading them to pick Option C, which enforces a precondition rather than establishing the actual linking mechanism.

How to eliminate wrong answers

Option A is wrong because repository secrets are used for storing sensitive tokens or credentials (e.g., for GitHub Actions), not for establishing a cross-service integration like Azure Boards; there is no 'Azure Boards connection string' concept. Option C is wrong because branch protection rules can require a linked work item for PRs, but they do not automatically link PRs to work items—they only enforce that a link already exists, which requires the integration from Option B to be in place first. Option D is wrong because while a GitHub Actions workflow could theoretically post comments to Azure Boards, this is a brittle, custom workaround that duplicates the purpose-built Azure Boards app, which handles bidirectional linking, status updates, and automation natively.

Full explanation →
518
MCQeasy

Your DevOps team is using Microsoft Defender for Cloud to monitor Azure resources. Which of the following is a security recommendation that Defender for Cloud might provide?

A.Allow all inbound traffic on port 22 for SSH
B.Enable Transparent Data Encryption (TDE) on SQL databases
C.Disable auditing on storage accounts to reduce overhead
D.Configure web apps to use HTTP instead of HTTPS
AnswerB

TDE is a security best practice recommended by Defender for Cloud.

Why this answer

Option A is correct because Defender for Cloud includes recommendations such as enabling encryption on Azure SQL databases. Option B is wrong because Defender for Cloud does not recommend disabling logging. Option C is wrong because using HTTP instead of HTTPS is insecure.

Option D is wrong because allowing all inbound traffic is a security risk.

Full explanation →
519
Multi-Selecthard

You are configuring a release pipeline in Azure Pipelines for a Java application. The pipeline must run integration tests after deployment to a test environment and only proceed to production if tests pass. Which THREE should you configure?

Select 3 answers
A.Use a pipeline condition on the production stage to run only if the test stage succeeded.
B.Set the agent job to run on the environment itself.
C.Set the integration test step to run only if the previous build succeeded.
D.Add a post-deployment gate that queries Azure Monitor for test failure signals.
E.Configure a post-deployment approval for the production stage.
AnswersA, D, E

Conditions control stage execution based on previous stage outcome.

Why this answer

Option A, Option C, and Option D are correct. A gate with Azure Monitor or Application Insights checks test results. A post-deployment approval ensures manual sign-off.

A condition on the production stage evaluates the test outcome. Option B is wrong because the task should not be skipped. Option E is wrong because the agent job runs on the agent, not in the environment.

Full explanation →
520
Drag & Dropmedium

Drag and drop the steps to set up a continuous integration pipeline in Azure Pipelines into the correct order.

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

Steps
Order

Why this order

The pipeline setup starts with creation, then source selection, trigger configuration, task addition, and finally validation.

Full explanation →
521
MCQeasy

Refer to the exhibit. You run the Azure CLI command to trigger a pipeline run. The pipeline fails because tests were skipped but should have run. What is the most likely issue?

A.The JSON value for skipTests must be a boolean without quotes.
B.The pipeline name is incorrect.
C.The command uses a flag '--variables-parameters' which is not a valid Azure DevOps CLI option.
D.The branch 'feature/new-feature' does not exist.
AnswerC

The correct flag is '--variables'.

Why this answer

Option B is correct because the parameter name should be 'skipTests' but the command uses '-parameters' which passes parameters, not variables. The correct parameter for variables is '--variables'. The exhibit uses '--variables-parameters' which is incorrect.

Option A is wrong because the pipeline name is correct. Option C is wrong because the branch exists. Option D is wrong because the command syntax is invalid.

Full explanation →
522
Multi-Selecteasy

Which TWO practices help you manage build artifacts efficiently in Azure Pipelines?

Select 2 answers
A.Set retention policies to automatically delete old artifacts
B.Copy artifacts to each agent's local storage
C.Download all artifacts manually after each build
D.Publish build artifacts using the Publish Build Artifacts task
E.Store artifacts as large single files to reduce number of files
AnswersA, D

Controls storage usage.

Why this answer

Publishing artifacts and using retention policies are efficient practices. Option A (manual download) is not efficient. Option D (large files) is inefficient.

Option E (copying to each agent) is wasteful.

Full explanation →
523
MCQmedium

Your team uses a monorepo in Azure Repos with multiple microservices. Developers frequently report merge conflicts due to long-lived feature branches. Which branching strategy minimizes merge conflicts while supporting continuous integration?

A.Use release branches for all development work and merge to main only at release time
B.Use GitFlow with separate develop and main branches, and long-lived feature branches
C.Use a forking workflow where each developer works in a personal fork and submits pull requests
D.Use trunk-based development with short-lived feature branches and frequent merges to main
AnswerD

Trunk-based development minimizes conflicts by integrating small changes often.

Why this answer

Trunk-based development with short-lived feature branches (typically lasting less than a day) minimizes merge conflicts by ensuring that changes are integrated into the main branch frequently, often multiple times per day. This approach reduces the divergence between branches, making conflicts less likely and easier to resolve. It also supports continuous integration by triggering automated builds and tests on every merge to main, aligning with the team's need for rapid feedback and reduced integration overhead.

Exam trap

The trap here is that candidates often associate GitFlow (Option B) with structured branching and mistakenly believe it reduces conflicts, but in reality, its long-lived feature branches increase conflict frequency and hinder continuous integration, making trunk-based development (Option D) the correct choice for minimizing conflicts and supporting CI.

How to eliminate wrong answers

Option A is wrong because using release branches for all development work and merging only at release time creates long-lived branches that accumulate significant divergence, leading to frequent and complex merge conflicts, and it violates CI principles by delaying integration. Option B is wrong because GitFlow with separate develop and main branches and long-lived feature branches encourages prolonged branch lifetimes, increasing the risk of merge conflicts and making continuous integration difficult due to infrequent merges to the main integration branch. Option C is wrong because a forking workflow, while useful for open-source projects with external contributors, introduces additional overhead in synchronizing forks and does not inherently reduce merge conflicts; it can actually increase them if forks diverge significantly before submitting pull requests.

Full explanation →
524
MCQmedium

Your team uses GitHub Issues to track work. You want to enforce that all new issues include a specific set of labels based on the issue type (bug, feature, task). What is the most efficient way to achieve this?

A.Configure branch protection rules to require label assignments.
B.Use a CODEOWNERS file to auto-assign labels.
C.Create YAML-based issue forms in the .github/ISSUE_TEMPLATE folder.
D.Set up a repository ruleset to restrict label modifications.
AnswerC

Issue forms enforce structure and labels at creation time.

Why this answer

Option C is correct because GitHub issue forms, defined as YAML files in the .github/ISSUE_TEMPLATE folder, allow you to create structured templates that can enforce required fields, including mandatory label assignments. When a user submits an issue via a form, the labels specified in the template are automatically applied, ensuring consistency without manual intervention or additional automation.

Exam trap

The trap here is that candidates confuse branch protection rules or repository rulesets (which manage code changes) with issue management features, or mistakenly think CODEOWNERS can assign labels instead of reviewers.

How to eliminate wrong answers

Option A is wrong because branch protection rules apply to pull requests and branches, not to issue creation; they cannot enforce label assignments on new issues. Option B is wrong because CODEOWNERS is designed to automatically request reviews from specific teams or individuals based on file paths in a repository, not to assign labels to issues. Option D is wrong because repository rulesets control permissions and restrictions on branches and tags, not on issue metadata like labels; they cannot enforce label assignments on new issues.

Full explanation →
525
MCQmedium

Your build pipeline runs on a self-hosted agent pool. You need to ensure that only authorized pipelines can use these agents. Which security measure should you implement?

A.Set permissions on the agent pool
B.Use agent tokens
C.Use variable groups
D.Configure agent queues
AnswerA

Restricts which pipelines can use the pool.

Why this answer

Option C is correct because agent pools can have permissions set to restrict which pipelines can use them. Option A is wrong because agent queues are deprecated and don't provide granular pipeline permissions. Option B is wrong because agent tokens are for agent registration, not pipeline authorization.

Option D is wrong because variable groups are for variables, not agent access.

Full explanation →
Page 6

Page 7 of 13

Page 8

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 →