Courseiva

Microsoft Azure DevOps Engineer Expert AZ-400 (AZ-400) — Questions 601–675

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

Take a mock examExam hub
Page 8

Page 9 of 13

Page 10
601
MCQmedium

Your organization uses Azure Repos and has multiple Git repositories that share common code. You want to enable code reuse across these repositories without duplicating code. Which strategy should you use?

A.Use Git subtrees to merge the shared code into each repository
B.Publish the shared code as a NuGet package
C.Reference the shared repository as a Git submodule
D.Add the shared repository as an upstream source in Azure Artifacts
AnswerC

Submodules reference a specific commit.

Why this answer

Git submodules allow you to include a specific commit of a shared repository as a subdirectory within multiple parent repositories, enabling code reuse without duplication. When the shared code is updated, you can pull the latest commit into each parent repository, maintaining a clear link between the parent and the shared codebase. This is the native Git mechanism for referencing external repositories while preserving version control history.

Exam trap

The trap here is confusing package management (NuGet, Azure Artifacts) with source control strategies, leading candidates to choose options that distribute compiled artifacts rather than shared source code.

How to eliminate wrong answers

Option A is wrong because Git subtrees merge the entire history of the shared repository into the parent repository, duplicating the code and history, which defeats the goal of avoiding duplication. Option B is wrong because publishing shared code as a NuGet package is a binary distribution mechanism for .NET libraries, not a source control strategy for sharing live Git repository code across multiple repos. Option D is wrong because adding a shared repository as an upstream source in Azure Artifacts is used for package management (e.g., NuGet, npm), not for direct source code sharing via Git.

Full explanation →
602
Multi-Selecthard

Which THREE of the following are valid methods to securely store and use secrets in Azure DevOps pipelines?

Select 3 answers
A.Azure Key Vault task in the pipeline
B.Variable Group linked to Azure Key Vault
C.Azure App Configuration with Key Vault references
D.Storing secrets in a pipeline YAML file with encryption
E.Pipeline variables marked as 'secret'
AnswersA, B, E

The Azure Key Vault task can fetch secrets during pipeline execution.

Why this answer

Option A is correct because the Azure Key Vault task in a pipeline allows you to fetch secrets directly from an Azure Key Vault instance during pipeline execution. This task retrieves secret values as pipeline variables, ensuring they are never exposed in logs or YAML files, and it supports both Azure Resource Manager and service principal authentication for secure access.

Exam trap

The trap here is that candidates may think Azure App Configuration with Key Vault references is a direct pipeline secret storage method, but it is designed for application configuration at runtime, not for pipeline variable management, and it requires additional configuration to resolve references during pipeline execution.

Full explanation →
603
MCQmedium

Your organization uses Azure Pipelines to build and deploy a .NET Core application to Azure App Service. The build pipeline takes 15 minutes. You want to implement continuous integration (CI) triggers but only for changes to the 'src' folder. The repository is in Azure Repos. How should you configure the trigger?

A.Set trigger: paths: include: - 'src/*'
B.Set trigger: paths: exclude: - 'src/*'
C.Set trigger: branches: include: - main
D.Set trigger: batch: true
AnswerA

This triggers CI only when files in src folder change.

Why this answer

Option C is correct because specifying paths in the trigger filters CI builds to only that path. Option A is incorrect because it excludes a path. Option B is incorrect because the branch filter is not needed and path is not specified.

Option D is incorrect because batch changes are not relevant.

Full explanation →
604
MCQmedium

Your team uses Azure Boards and wants to automatically update the work item state when a pull request is merged. The policy should require a successful build before merging and update the work item to 'Resolved' on merge. Which branch policy should you configure?

A.Automatically update work items
B.Require a minimum number of reviewers
C.Comment resolution
D.Check for linked work items
AnswerA

This policy updates work item state on merge.

Why this answer

The 'Automatically update work items' branch policy in Azure Repos is specifically designed to update the state of linked work items when a pull request is completed (merged). By configuring this policy, you can set the work item to transition to 'Resolved' upon merge, and you can also require a successful build as a prerequisite for merging. This directly meets the requirement to automatically update the work item state on merge while enforcing a build validation.

Exam trap

The trap here is that candidates may confuse 'Check for linked work items' (which only verifies a link exists) with 'Automatically update work items' (which actually changes the work item state), or they may think that a reviewer requirement or comment resolution can trigger work item updates.

How to eliminate wrong answers

Option B is wrong because 'Require a minimum number of reviewers' only enforces that a certain number of people approve the pull request; it does not update work items or require a build. Option C is wrong because 'Comment resolution' requires that all comments on the pull request are resolved before merging, but it has no effect on work item state transitions or build validation. Option D is wrong because 'Check for linked work items' ensures that the pull request is linked to at least one work item, but it does not automatically update the work item state or enforce a build requirement.

Full explanation →
605
MCQmedium

You have a release pipeline that deploys to multiple stages. You want to ensure that a manual approval is required before deploying to the production stage. Which approach should you use?

A.Add a pre-deployment approval on the production stage.
B.Add a post-deployment approval on the staging stage.
C.Configure a deployment gate with a manual intervention task.
D.Use a pipeline decorator to inject approval step.
AnswerA

Why this answer

Pre-deployment approvals in Azure Pipelines allow you to require manual sign-off before a release proceeds to a specific stage. By adding a pre-deployment approval on the production stage, the pipeline will pause and wait for designated approvers to approve the deployment, ensuring that no code reaches production without explicit authorization.

Exam trap

The trap here is that candidates often confuse post-deployment approvals (which occur after a stage completes) with pre-deployment approvals (which occur before a stage starts), or they mistakenly think a manual intervention task inside a deployment gate can replace the native stage-level approval feature.

Why the other options are wrong

B

Post-deployment happens after deployment, not before.

C

Gates evaluate conditions, but manual approval is simpler and more direct.

D

Decorators are for injecting steps, not for approvals.

Full explanation →
606
MCQeasy

Your team uses Azure Repos Git and wants to enforce a policy that all pushes to the main branch must pass a build validation pipeline. The pipeline runs unit tests and code analysis. You need to configure this in the branch policy. Which setting should you enable?

A.Require comment resolution
B.Linked work items
C.Limit merge types
D.Build validation
AnswerD

This enforces a successful build on each push.

Why this answer

Azure Repos branch policies allow requiring a successful build for each push. The 'Require a minimum number of reviewers' is for pull request approvals, not pushes. Option C is correct.

Option A is for comments, not builds. Option B is for merge strategies. Option D is for work item linking.

Full explanation →
607
Multi-Selectmedium

Your organization is adopting GitHub Advanced Security. Which THREE features should you enable to improve security?

Select 3 answers
A.GitHub Pages
B.Branch protection rules
C.Secret scanning
D.Dependabot alerts and security updates
E.Code scanning (CodeQL)
AnswersC, D, E

Secret scanning detects credentials.

Why this answer

Options A, B, and D are correct because code scanning, secret scanning, and Dependabot alerts are core features of GitHub Advanced Security. Option C is wrong because branch protection rules are not part of Advanced Security. Option E is wrong because GitHub Pages is for hosting static sites.

Full explanation →
608
MCQeasy

You need to enforce that every commit in your repository is associated with a work item in Azure Boards. Which mechanism should you use?

A.Use commit messages with work item IDs
B.Deploy a custom Git hook on the server
C.Configure a branch policy to require linked work items
D.Use the 'Require status checks' policy
AnswerC

Enforced in pull requests.

Why this answer

Option C is correct because Azure Repos branch policies include a setting to 'Require linked work items', which enforces that every pull request (and by extension, every commit merged through that PR) is associated with a work item in Azure Boards. This policy is enforced server-side at merge time, ensuring no commit can be merged without a linked work item, regardless of how the commit message is formatted.

Exam trap

The trap here is that candidates confuse a voluntary convention (commit message IDs) with an enforced policy, or they incorrectly assume that custom Git hooks are available in Azure Repos as they are in self-hosted Git servers.

How to eliminate wrong answers

Option A is wrong because commit messages with work item IDs are a convention, not an enforcement mechanism; they can be omitted or faked, and Azure Repos does not natively validate commit message content to block commits. Option B is wrong because custom Git hooks on the server are not supported in Azure Repos (which uses a managed Git service); hooks would need to be implemented via Azure DevOps service hooks or policies, not arbitrary server-side scripts. Option D is wrong because 'Require status checks' policy validates external CI/CD pipeline results (e.g., build validation), not work item association; it does not inspect commit-to-work-item links.

Full explanation →
609
Multi-Selecthard

Your team uses Azure Pipelines to build a Java application. The build must produce a JAR file and publish it as a pipeline artifact. Which THREE steps should be included in the build pipeline?

Select 3 answers
A.Use a Maven or Gradle task to compile and package the application.
B.Use the DotNetCoreCLI task to build the application.
C.Use the Publish Build Artifacts task to upload the staging directory.
D.Use the Copy Files task to copy the JAR to $(Build.ArtifactStagingDirectory).
E.Use the NuGetCommand task to pack the JAR.
AnswersA, C, D

These tasks compile and create the JAR.

Why this answer

Option A is correct because Maven or Gradle builds the JAR. Option C is correct because Copy Files task moves the JAR to a staging directory. Option E is correct because Publish Build Artifacts uploads the artifact.

Options B and D are not required.

Full explanation →
610
MCQhard

Your team uses Azure Pipelines to deploy a microservices application to Azure Kubernetes Service (AKS). Each microservice has its own pipeline that builds a Docker image and deploys it to a shared AKS cluster. The deployment must support rolling updates with zero downtime. You need to ensure that if a deployment fails (e.g., health check fails), the pipeline automatically rolls back to the previous version. Which deployment strategy should you implement in the pipeline?

A.Use a canary deployment strategy with a pipeline task that gradually shifts traffic to the new version and monitors error rates. If errors exceed a threshold, the task stops the canary.
B.Use a rolling update strategy with the 'kubectl apply' command, and include a post-deployment step that checks the rollout status. If the rollout fails, run 'kubectl rollout undo' to roll back.
C.Use the 'KubernetesManifest' task with the 'rollout status' option, which automatically rolls back if the rollout status indicates failure.
D.Use a blue-green deployment strategy with two separate AKS clusters. Deploy the new version to the green cluster, run health checks, and then update the load balancer to point to green. If health checks fail, keep pointing to blue.
AnswerB

This leverages Kubernetes native rolling updates and automates rollback on failure.

Why this answer

Option D is correct because Kubernetes supports rolling updates natively, and with proper readiness probes, it can automatically roll back if the update fails. Combined with a pipeline task that monitors the rollout and triggers rollback on failure, this meets the requirement. Option A is wrong because canary deployments require manual or automated traffic shifting and do not automatically roll back the entire deployment.

Option B is wrong because blue-green deployments require an additional AKS cluster or namespace and manual rollback steps. Option C is wrong because the KubernetesManifest task with rollout status does not automatically roll back; it only monitors.

Full explanation →
611
MCQmedium

You are reviewing an Azure DevOps permissions JSON. What access does the user 'user@contoso.com' have?

A.Contributor access to the build pipeline named 'Build-1'
B.Reader access to the build pipeline
C.Contributor access to all build pipelines
D.Reader access to the project
AnswerA

The user has Contributor scope to that build.

Why this answer

Option B is correct because the user has Contributor role scoped to the build pipeline 'Build-1'. Option A is wrong because Reader is a group, not the user. Option C is wrong because scope is specific to build, not all pipelines.

Option D is wrong because the user has Contributor, not Reader.

Full explanation →
612
MCQmedium

A company uses Azure DevOps for CI/CD. The security team requires that all pipeline runs must use a specific service connection (ServiceConnection-Prod) that has been approved for production deployments. However, developers are accidentally using unapproved connections. You need to enforce that only the approved service connection can be used in any pipeline that deploys to the production environment. What should you do?

A.Define a required template for all pipelines that includes the service connection, and instruct developers to use it.
B.Set up a manual approval gate on the production environment stage in the pipeline.
C.Configure a branch policy on the main branch to require a successful build before merging.
D.Create an Azure Pipeline decorator that validates the service connection used in each task and fails the pipeline if it is not the approved one.
AnswerD

A decorator can inject validation tasks into every pipeline to enforce the use of a specific service connection.

Why this answer

Option D is correct because Azure Pipeline decorators inject custom validation logic at runtime, allowing you to inspect each task's service connection and fail the pipeline if it does not match the approved one. This enforces the security requirement centrally without relying on developer compliance or manual gates.

Exam trap

The trap here is that candidates confuse process-based controls (templates, approvals, branch policies) with runtime enforcement, overlooking that only a decorator can programmatically validate and block unauthorized service connections at execution time.

How to eliminate wrong answers

Option A is wrong because a required template is a guideline that developers can bypass or modify, not an enforceable control. Option B is wrong because a manual approval gate only pauses the pipeline for human approval; it does not validate which service connection was used in the tasks. Option C is wrong because a branch policy on the main branch ensures code quality before merging but does not inspect or restrict the service connection used during pipeline execution.

Full explanation →
613
Multi-Selecthard

Your GitHub organization has multiple repositories that share common CI/CD workflows. You want to centralize these workflows to reduce duplication. Which TWO approaches are valid?

Select 2 answers
A.Create reusable workflows in a central repository and use the 'uses' keyword in each repository's workflow to reference them.
B.Store the workflows in a central repository and use Git submodules to include them in each repository.
C.Create a template repository containing the workflows and use it as a template for new repositories.
D.Use branch protection rules to enforce that all workflows must be reviewed by a central team.
E.Publish the workflows as a GitHub Actions workflow library and install it in each repository.
AnswersA, C

Reusable workflows allow centralized maintenance.

Why this answer

Option A is correct because GitHub Actions supports reusable workflows that can be stored in a central repository and referenced from other repositories using the 'uses' keyword with the syntax 'owner/repo/.github/workflows/workflow.yml@ref'. This allows teams to define common CI/CD logic once and invoke it across multiple repositories, reducing duplication and simplifying maintenance.

Exam trap

The trap here is that candidates may confuse Git submodules or template repositories as valid methods for sharing live, updatable workflows, when in fact only reusable workflows (Option A) and template repositories (Option C, for initial setup) are officially supported approaches for centralizing CI/CD workflows in GitHub Actions.

Full explanation →
614
MCQhard

Your team uses GitHub and wants to enforce a policy that all commits to the main branch must be signed with a GPG key that is associated with the author's GitHub account. Which method should you use to enforce this?

A.Create a GitHub Actions workflow that runs a signature check after push
B.Use a commit status check to verify signatures
C.Add a branch protection rule that requires signed commits
D.Configure a repository ruleset that requires signed commits
AnswerC

Branch protection rules can enforce signed commits.

Why this answer

Option C is correct because branch protection rules in GitHub include a 'Require signed commits' setting that enforces GPG or S/MIME signature verification on all commits pushed to the protected branch. This policy is enforced server-side before the commit is accepted, ensuring that only commits signed with a key associated with the author's GitHub account are allowed into the main branch.

Exam trap

The trap here is that candidates confuse post-push checks (like Actions workflows or status checks) with pre-push enforcement, or they overcomplicate the solution by choosing repository rulesets when a simple branch protection rule is the intended answer for a standard GitHub team scenario.

How to eliminate wrong answers

Option A is wrong because a GitHub Actions workflow triggered after push cannot prevent the commit from being accepted; it can only react to the commit, not enforce a pre-commit policy. Option B is wrong because a commit status check is a post-push validation that reports a status (e.g., success/failure) but does not block the push itself; it can be used with branch protection, but the question asks for the method to enforce the policy, and the status check alone does not enforce it. Option D is wrong because repository rulesets are a feature for enterprise-managed repositories and are not the standard method for enforcing signed commits in a typical GitHub team workflow; the correct and simplest approach is a branch protection rule.

Full explanation →
615
MCQeasy

Your team uses Azure Boards with a Kanban board. You want to limit the number of work items in the 'In Progress' column to prevent bottlenecks. What should you configure?

A.Column limits on the Kanban board
B.Branch policies
C.Backlog level settings
D.Work item rules
AnswerA

Column limits restrict the number of items in a column, preventing bottlenecks.

Why this answer

Column limits on the Kanban board directly enforce work-in-progress (WIP) constraints by capping the number of work items allowed in a specific column, such as 'In Progress'. This prevents bottlenecks by signaling the team to complete existing work before pulling new items, aligning with Lean and Kanban principles. Azure Boards supports this configuration through the board settings, where you can set a maximum limit per column.

Exam trap

The trap here is confusing process configuration (column limits) with code governance (branch policies) or automation (work item rules), leading candidates to select options that manage code or workflows rather than direct board constraints.

How to eliminate wrong answers

Option B is wrong because branch policies are used to enforce code quality and review requirements on pull requests in Azure Repos, not to limit work items on a Kanban board. Option C is wrong because backlog level settings define the hierarchy of work item types (e.g., Epics, Features, User Stories) and their visibility, but do not control column-level WIP limits. Option D is wrong because work item rules automate field updates or state transitions based on conditions (e.g., when a field changes), but they cannot enforce a numeric cap on items in a column.

Full explanation →
616
MCQmedium

Your company uses Azure DevOps and must enforce that all pipelines use approved agent pools. The security team wants to prevent the use of the default agent pool. What should you do?

A.Use pipeline settings to require authorization for the default pool
B.Set agent pool permissions to deny the default pool for all projects
C.Remove the default agent pool from the organization
D.Disable the default agent pool in project settings
AnswerB

This explicitly denies access to the default pool.

Why this answer

Option A is correct because you can set agent pool permissions to 'Deny' for all projects except those using approved pools. Option B is wrong because removing the default pool from the organization does not prevent its use in existing pipelines. Option C is wrong because disabling the default pool requires manual intervention.

Option D is wrong because the 'Authorize' setting is for YAML pipelines, not for restricting pool usage.

Full explanation →
617
Multi-Selecteasy

Which TWO actions should you take to proactively protect your repository from accidentally committing secrets? (Choose two.)

Select 2 answers
A.Enable branch protection rules
B.Use pre-commit hooks with tools like detect-secrets
C.Enable push protection in secret scanning
D.Use signed commits
E.Configure secret scanning alerts
AnswersB, C

Prevents committing secrets.

Why this answer

Option B is correct because pre-commit hooks, such as those using the detect-secrets tool, scan staged changes before a commit is finalized. This prevents secrets from ever entering the repository history, providing a proactive, client-side guard. Option C is correct because push protection in secret scanning blocks pushes that contain known secret patterns at the server side, preventing the secret from being stored in the remote repository.

Exam trap

The trap here is confusing reactive security measures (like alerts or branch policies) with proactive, blocking controls (like pre-commit hooks and push protection) that prevent secrets from being stored in the first place.

Full explanation →
618
Multi-Selecteasy

Which TWO actions are recommended practices for improving communication within a DevOps team?

Select 2 answers
A.Create a shared team charter with communication norms.
B.Hold daily stand-up meetings.
C.Use separate documentation repositories for each team.
D.Send monthly status reports via email.
E.Remove team chat channels to reduce noise.
AnswersA, B

A charter sets expectations for communication.

Why this answer

A shared team charter with communication norms establishes explicit expectations for how the team interacts, reducing ambiguity and fostering a culture of transparency and accountability. This practice aligns with DevOps principles of collaboration and shared ownership, ensuring all members understand preferred channels, response times, and escalation paths.

Exam trap

The trap here is that candidates may dismiss daily stand-ups as 'agile-only' or think monthly reports are sufficient, but the AZ-400 exam emphasizes that DevOps teams need frequent, synchronous communication (like stand-ups) and a shared charter to align on norms, not just asynchronous reports or channel removal.

Full explanation →
619
MCQmedium

Your Azure DevOps pipeline deploys a web app to Azure App Service using a YAML pipeline. The deployment fails intermittently with the error 'Conflict' when updating deployment slots. What is the most likely cause?

A.Another deployment or swap operation is already in progress on the slot.
B.The service connection is using expired credentials.
C.The slot name is misspelled in the pipeline configuration.
D.The web app is locked by a file handle from a previous deployment.
AnswerA

Concurrent operations on the same slot cause conflict errors.

Why this answer

Option B is correct because swapping slots while a deployment is in progress can cause a conflict error. Option A is wrong because Resource Manager connections use service principals, not user credentials. Option C is wrong because slot names are case-insensitive.

Option D is wrong because file locks would cause different errors.

Full explanation →
620
MCQeasy

Your organization uses GitHub Actions for CI/CD. You want to ensure that the workflow runs only when a pull request is labeled 'safe-to-deploy'. Which trigger should you use?

A.on: workflow_run: workflows: ["Build"] types: [completed]
B.on: issue_comment: types: [created]
C.on: pull_request: types: [labeled] branches: [main]
D.on: pull_request_target: types: [opened, synchronize] branches: [main]
AnswerC

Correctly triggers on pull request labeled event on main branch.

Why this answer

GitHub Actions supports 'pull_request' triggers with 'types' to filter on specific actions, but labeling is not a pull_request type event; it's an 'issues' or 'pull_request' event with 'labeled' type. Option A is correct. Option B is wrong because 'pull_request_target' is similar but has different security implications; it still requires correct event types.

Option C is wrong because 'issue_comment' triggers on comments, not labels. Option D is wrong because 'workflow_run' triggers on completion of another workflow.

Full explanation →
621
MCQmedium

A company's Azure DevOps project uses a custom agent pool with self-hosted agents. The security team discovers that pipeline runs can access secrets stored in Azure Key Vault, but the team wants to ensure that secrets are only accessible to approved pipelines. Which configuration should the team implement?

A.Use a library variable group linked to Key Vault and enable 'Approval checks' on the variable group with branch control.
B.Store secrets directly in pipeline variables and use 'Make secrets available to all pipelines' setting.
C.Assign pipeline-level permissions to the Key Vault using Azure RBAC.
D.Limit the number of agents in the custom agent pool.
AnswerA

Approval checks and branch filters restrict which pipelines and branches can access secrets.

Why this answer

Option A is correct because linking a library variable group to Azure Key Vault and enabling 'Approval checks' on that variable group with branch control ensures that only approved pipelines (and specific branches) can access the secrets. This provides a granular, pipeline-scoped approval gate that prevents unauthorized pipeline runs from retrieving secrets from Key Vault, directly addressing the security requirement.

Exam trap

The trap here is that candidates often confuse Azure RBAC with pipeline-level permissions, not realizing that Key Vault access must be configured at the vault level (via access policies or RBAC) for the service principal, not at the pipeline scope, and that approval checks on variable groups are the correct way to gate secret access per pipeline run.

How to eliminate wrong answers

Option B is wrong because storing secrets directly in pipeline variables and enabling 'Make secrets available to all pipelines' would expose secrets to every pipeline in the project, violating the requirement to restrict access to approved pipelines only. Option C is wrong because assigning pipeline-level permissions to Key Vault using Azure RBAC is not a supported configuration; Key Vault access is managed via access policies or RBAC at the vault level for service principals or managed identities, not at the pipeline level. Option D is wrong because limiting the number of agents in the custom agent pool does not control which pipelines can access secrets; it only affects concurrency and resource availability, not secret authorization.

Full explanation →
622
MCQmedium

A company uses Azure DevOps for CI/CD. They have multiple pipelines that deploy to different environments. They want to ensure that secrets like API keys are not exposed in pipeline logs. What is the best approach?

A.Use Azure App Configuration with Key Vault references
B.Create a Variable Group linked to Azure Key Vault
C.Use Azure Kubernetes Service secrets
D.Use pipeline variables marked as 'secret'
AnswerB

Variable Groups linked to Key Vault ensure secrets are never stored in the pipeline and are fetched at runtime.

Why this answer

Option C is correct because Variable Groups linked to Azure Key Vault securely store secrets and can be referenced in pipelines without exposing values. Option A is wrong because pipeline variables can be set as secret but still need secure storage. Option B is wrong because Azure App Configuration can store secrets but is less integrated for secret management.

Option D is wrong because environment secrets are for Kubernetes, not general pipeline secrets.

Full explanation →
623
Multi-Selectmedium

Your team uses Azure Pipelines to build a .NET application. You need to implement a secure build pipeline that meets the following requirements: - Secrets must be injected at build time without being exposed in logs or YAML files. - The build must use Microsoft-hosted agents. - All builds must be auditable. Which TWO actions should you take? (Choose two.)

Select 2 answers
A.Enable 'Allow scripts to access the OAuth token' on the agent job and use the token in scripts.
B.Use a variable group linked to Azure Key Vault to store secrets, and reference the variable group in the pipeline.
C.Store secrets as plain-text environment variables in the pipeline YAML file.
D.Use the 'Replace Tokens' task to substitute secrets from pipeline variables into configuration files.
E.Deploy a self-hosted agent on-premises to keep secrets within the corporate network.
AnswersA, B

This allows scripts to authenticate without storing secrets, and access is audited.

Why this answer

Option A is correct because variable groups linked to an Azure Key Vault provide secure, auditable secret injection. Option D is correct because the 'Allow scripts to access the OAuth token' setting enables scripts to use the token for authenticated operations without storing secrets. Option B is incorrect because environment variables in YAML are exposed in logs.

Option C is incorrect because secrets in variables cannot be used directly in file transforms; they must be mapped or accessed via scripts. Option E is incorrect because self-hosted agents are not required and may not meet the Microsoft-hosted agent requirement.

Full explanation →
624
MCQmedium

Your team uses GitHub Flow and wants to enforce that all pull requests require at least one approval before merging to the main branch. Which branch protection rule should you configure?

A.Require status checks to pass before merging
B.Restrict who can push to matching branches
C.Require a pull request before merging with at least 1 approval
D.Require linear history
AnswerC

This directly enforces the approval requirement before merge.

Why this answer

Option B is correct because 'Require a pull request before merging' with 'Required approvals' set to 1 enforces the policy. Option A is wrong because it only changes the name, not approvals. Option C is wrong because it restricts who can push, not the approval requirement.

Option D is wrong because it requires status checks, not approvals.

Full explanation →
625
MCQeasy

A team uses Azure Pipelines to build a .NET Core application. The build pipeline runs successfully, but the release pipeline fails when deploying to Azure App Service with the error: 'ERROR_FILE_IN_USE'. What is the most likely cause?

A.The deployment slot is not configured correctly.
B.The 'Take App Offline' setting is not enabled in the deployment task.
C.The Azure App Service plan is not scaled appropriately.
D.The build configuration is set to Release instead of Debug.
AnswerB

Taking the app offline releases file locks.

Why this answer

The 'ERROR_FILE_IN_USE' error occurs when the deployment process tries to overwrite files that are currently locked by the running application. Enabling the 'Take App Offline' setting in the Azure App Service deploy task places an app_offline.htm file in the wwwroot directory, which gracefully shuts down the application and releases all file locks before the new binaries are copied. Without this setting, the running process holds locks on the DLLs, causing the deployment to fail.

Exam trap

The trap here is that candidates often confuse 'ERROR_FILE_IN_USE' with a slot configuration or scaling issue, but the root cause is always the running process holding file locks, which is directly resolved by the 'Take App Offline' setting in the deployment task.

How to eliminate wrong answers

Option A is wrong because an incorrectly configured deployment slot would cause routing or swapping issues, not a file-lock error during deployment. Option C is wrong because scaling the App Service plan affects performance and resource allocation, not the ability to overwrite locked files. Option D is wrong because the build configuration (Release vs.

Debug) affects optimization and debugging symbols, not file-locking behavior during deployment.

Full explanation →
626
Multi-Selectmedium

Which two of the following are valid strategies to implement conditional deployment in a YAML pipeline? (Choose 2)

Select 2 answers
A.Use the 'condition' property on a stage
B.Use template expressions with parameters
C.Configure stage filters in the triggers section
D.Use dependency conditions like 'succeededOrFailed'
E.Add a PowerShell script to check environment
AnswersA, B

Why this answer

Option A is correct because the 'condition' property in Azure DevOps YAML pipelines allows you to specify custom conditions (e.g., `eq(variables['Build.SourceBranch'], 'refs/heads/main')`) that control whether a stage, job, or step runs. This is a native, declarative way to implement conditional deployment without scripting, evaluating the condition at runtime based on variables or expressions.

Exam trap

The trap here is that candidates confuse dependency conditions (like `succeededOrFailed`) with custom conditional logic, not realizing that dependency conditions are predefined and not a general-purpose strategy for implementing conditional deployment based on arbitrary criteria like branch names or variables.

Why the other options are wrong

C

Stage filters are for triggers, not conditions within a pipeline.

D

Dependency conditions are built-in for run order, not for custom conditional logic.

E

While possible, it's not a pipeline-native strategy; the question asks for valid strategies in YAML.

Full explanation →
627
MCQeasy

Your team manages a large monorepo in Azure Repos containing multiple projects. Developers frequently complain that cloning the entire repository takes too long and that they only need a subset of the code. The team uses Git LFS for large binary files. The repository currently has 50,000 commits and is 5 GB in size. You want to improve clone performance without sacrificing the ability to contribute to any part of the repo. What should you do?

A.Configure sparse checkout so developers can clone only the directories they need.
B.Instruct developers to use a shallow clone with depth 1 to reduce clone time.
C.Move all large binary files to Git LFS to reduce repository size.
D.Split the monorepo into multiple repositories and use submodules to aggregate them.
AnswerA

Sparse checkout allows cloning a subset of files, dramatically reducing clone time and disk usage.

Why this answer

Sparse checkout allows developers to clone only the specific directories they need from the monorepo, significantly reducing the amount of data transferred and stored locally. Since the team already uses Git LFS for large binaries, the primary bottleneck is the sheer size of the full commit history and working tree. Sparse checkout, combined with a shallow clone if needed, directly addresses the complaint without breaking the ability to contribute to any part of the repo.

Exam trap

The trap here is that candidates often confuse sparse checkout with shallow clone, thinking that reducing commit history alone solves the problem, when in fact the working tree size is the primary bottleneck for developers who only need a subset of code.

How to eliminate wrong answers

Option B is wrong because a shallow clone with depth 1 reduces the commit history but still downloads the full working tree for all projects, which is 5 GB; it does not solve the problem of needing only a subset of code. Option C is wrong because the team already uses Git LFS for large binary files, so moving files to LFS again would not further reduce repository size or improve clone performance. Option D is wrong because splitting the monorepo into multiple repositories with submodules introduces significant overhead in managing cross-repo dependencies, breaks the monorepo workflow, and does not guarantee faster clones for developers who still need multiple submodules.

Full explanation →
628
Multi-Selectmedium

Which TWO actions should you take to ensure that only approved pipelines can deploy to production in Azure DevOps? (Choose two.)

Select 2 answers
A.Disable parallel jobs for the project.
B.Configure a pipeline approval gate on the production environment.
C.Set branch policies to require a pull request before merging to the main branch.
D.Limit the number of pipelines that can deploy from the main branch.
E.Use a single agent pool for all pipelines.
AnswersB, C

Approval gates require manual approval before deployment.

Why this answer

Options A and D are correct: Use pipeline approvals to require manual approval before deployment, and use branch policies to enforce that only code from protected branches can be deployed. Option B is incorrect because disabling parallel jobs does not enforce approvals. Option C is incorrect because using a single agent pool does not enforce security.

Option E is incorrect because the main branch can have many pipelines.

Full explanation →
629
Multi-Selectmedium

Your team uses Azure DevOps and wants to enforce that all work items must be linked to a pull request before merging. Additionally, the pull request must be approved by at least two reviewers. Which two branch policies should you enable?

Select 2 answers
A.Automatically update work items
B.Require a minimum number of reviewers
C.Check for linked work items
D.Build validation
E.Comment resolution
AnswersB, C

Enforces at least two approvals.

Why this answer

Option B is correct because the 'Require a minimum number of reviewers' policy enforces that a pull request must be approved by at least two reviewers before it can be completed. Option C is correct because the 'Check for linked work items' policy ensures that every pull request is associated with a work item, which satisfies the requirement that all work items must be linked to a pull request before merging.

Exam trap

The trap here is that candidates often confuse 'Automatically update work items' with 'Check for linked work items,' but the former only updates status after merge, while the latter enforces the link before merge.

Full explanation →
630
MCQmedium

Your organization uses Microsoft Defender XDR for security monitoring. You need to configure an alert that fires whenever a user with high privileges (e.g., Project Collection Administrators) is added to an Azure DevOps group. What is the most efficient approach?

A.Set up a Microsoft Purview compliance policy for Azure DevOps
B.Run a weekly Azure DevOps audit log query manually
C.Create a custom detection rule in Microsoft Defender XDR using the Azure DevOps identity provider logs
D.Configure a Log Analytics workspace with Azure Activity Logs
AnswerC

Defender XDR can ingest Azure DevOps audit logs and trigger alerts on specific events.

Why this answer

Option C (Create a custom detection rule in Microsoft Defender XDR using the Azure DevOps identity provider logs) is correct because Defender XDR can ingest Azure DevOps audit logs and create custom detections for specific activities. Option A is not efficient for real-time alerting. Option B is for Azure, not Azure DevOps.

Option D is for compliance, not real-time alerting.

Full explanation →
631
Multi-Selecthard

Which TWO are best practices for securing Azure Pipelines? (Choose two.)

Select 2 answers
A.Use variable groups linked to Azure Key Vault for secrets.
B.Scope service connections to specific resource groups with 'Contributor' role.
C.Grant 'Administrator' role to all service connections for ease of management.
D.Store all pipeline variables in the YAML file as plain text.
E.Disable pipeline logging for all jobs.
AnswersA, B

Key Vault integration securely stores and retrieves secrets.

Why this answer

Options B and D are correct. Option B: Using variable groups with secret variables from Azure Key Vault ensures secrets are not stored in YAML. Option D: Service connections with 'Contributor' role scoped to a resource group limit blast radius.

Option A is unnecessary and insecure. Option C is not a security best practice. Option E is not a security practice.

Full explanation →
632
MCQeasy

Your team uses GitHub Actions for CI/CD. You want to automatically deploy to Azure App Service whenever a pull request is merged to the main branch. Which event trigger should you use in the GitHub Actions workflow?

A.pull_request: branches: [main]
B.pull_request: types: [closed] branches: [main]
C.push: branches: [main]
D.release: types: [published]
AnswerB

Triggers only when a PR is closed (merged) to main.

Why this answer

Option C is correct because the 'pull_request' event with type 'closed' and branch filter 'main' triggers when a PR is merged (closed) to main. Option A is wrong because 'push' triggers on every push, not just PR merges. Option B is wrong because 'pull_request' without type triggers on all PR events, including opened, synchronize, etc.

Option D is wrong because 'release' triggers on release creation, not PR merge.

Full explanation →
633
MCQmedium

Your organization uses Azure DevOps Services. The development team uses feature branches and pull requests to merge changes into the main branch. You need to implement a policy that ensures every pull request has at least two approvals from the 'Senior Developers' group, and the build must succeed before merging. Additionally, any comment on the pull request must be resolved before merging. The policy should apply to the main branch only. You have already created the 'Senior Developers' group in Azure DevOps. What should you do?

A.Configure the team's settings to require approvals for all pull requests.
B.Add a branch policy on the main branch that requires a minimum of two reviewers from 'Senior Developers', a successful build, and that all comments are resolved.
C.Set up a build validation policy on the main branch that runs the pipeline and fails if comments are unresolved.
D.Configure the repository's pull request settings to require approvals and comment resolution.
AnswerB

Branch policies provide all required enforcement.

Why this answer

Option B is correct because Azure DevOps branch policies allow you to enforce specific requirements on pull requests targeting a branch. By configuring a branch policy on the main branch, you can require a minimum number of reviewers from a specific group (e.g., 'Senior Developers'), a successful build, and that all comments are resolved before merging. This directly meets all the stated requirements.

Exam trap

The trap here is that candidates often confuse repository-level settings (which are global) with branch-specific policies, leading them to choose options that cannot enforce group-based reviewer requirements or comment resolution on a single branch.

How to eliminate wrong answers

Option A is wrong because team settings for pull request approvals apply globally to all branches and cannot enforce a minimum number of reviewers from a specific group or require comment resolution. Option C is wrong because build validation policies only run a pipeline and check for build success; they cannot evaluate whether comments are resolved, as comment resolution is a separate policy setting. Option D is wrong because repository pull request settings are not branch-specific and cannot enforce a minimum number of reviewers from a specific group or require comment resolution; those are branch policy features.

Full explanation →
634
MCQmedium

Your organization uses GitHub Copilot for pull request summaries. A developer notices that the AI-generated summary is inaccurate. Which step should the developer take to improve the quality of future summaries?

A.Disable Copilot for pull requests
B.Provide a detailed pull request description
C.Edit the description after generation
D.Ignore the inaccuracy
AnswerB

Better input leads to better AI output.

Why this answer

Providing a detailed pull request description helps Copilot generate more accurate summaries. Disabling Copilot is not necessary. Editing the summary once is a workaround but does not improve future generations.

Ignoring the issue does not help.

Full explanation →
635
MCQmedium

You are designing a build pipeline for a Java application hosted in Azure Repos. The pipeline needs to run unit tests, package the application as a JAR file, and publish the build artifact. Which task should you use to publish the JAR file as a pipeline artifact?

A.Publish Build Artifacts task
B.Copy Files task
C.Archive Files task
D.Publish Pipeline Artifact task
AnswerD

Publish Pipeline Artifact publishes files as pipeline artifacts that can be used in subsequent stages.

Why this answer

Option B is correct because the Publish Build Artifacts task is designed to publish files as build artifacts from a pipeline. Option A is wrong because Copy Files task only copies files to a staging directory. Option C is wrong because the Archive Files task creates a ZIP archive.

Option D is wrong because the Publish Pipeline Artifact task is the correct one, but the scenario asks for build artifacts specifically, and Publish Build Artifacts is the classic task; however, Publish Pipeline Artifact is also valid but the question expects the classic task. Actually, both are used, but Publish Build Artifacts is the older task name; the question is designed to test knowledge of the task names. In modern Azure DevOps, Publish Pipeline Artifact is preferred.

To avoid confusion, we'll adjust: Option B is Publish Pipeline Artifact. Explanation: Option B is correct because Publish Pipeline Artifact publishes files as pipeline artifacts. Option A is wrong because it only copies files.

Option C is wrong because it archives files. Option D is wrong because it's not a valid task name.

Full explanation →
636
Multi-Selectmedium

A development team uses Git for source control. They want to enforce a branching strategy where all feature work is done in short-lived branches that are merged to main via pull requests. The team also requires that every commit on main builds successfully. Which TWO practices should the team implement?

Select 2 answers
A.Configure a branch policy on main that requires a successful build before merging.
B.Use squash merge when completing pull requests to main.
C.Require at least one approver on all pull requests targeting main.
D.Create feature branches from main and keep them long-lived for stability.
E.Allow developers to commit directly to main for urgent fixes.
AnswersA, C

Ensures every commit to main has passed build validation.

Why this answer

Option A is correct because configuring a branch policy on main that requires a successful build before merging ensures that every commit merged into main has passed a validation build. This enforces the team's requirement that every commit on main builds successfully, as the pull request cannot be completed until the build pipeline reports success.

Exam trap

The trap here is that candidates often confuse squash merge (which simplifies history) with a practice that ensures build success, or they mistakenly think allowing direct commits for urgent fixes is acceptable when the requirement explicitly demands every commit on main builds successfully.

Full explanation →
637
MCQhard

Your Azure DevOps organization has multiple projects. You need to ensure that only approved extension versions are installed across all projects. What is the most efficient way to enforce this?

A.Restrict extension usage to specific pipelines via YAML.
B.Use the Azure DevOps extension management settings to mark approved extensions and block others.
C.Create an Azure Policy that audits extension installations.
D.Uninstall all extensions and only install them per project as needed.
AnswerB

Organization-level extension management allows you to control which extensions are available.

Why this answer

Option A is correct because Azure DevOps allows you to manage extensions at the organization level and restrict installation to approved ones. Option B is wrong because uninstalling extensions in each project is not efficient. Option C is wrong because Azure Policy does not manage Azure DevOps extensions.

Option D is wrong because extensions cannot be restricted to specific pipelines.

Full explanation →
638
MCQhard

You are designing a release pipeline that deploys to multiple environments (dev, test, prod) sequentially. You need to require manual approval before deploying to prod. The approver should be able to review the changes and approve or reject. Which feature should you use?

A.Pre-deployment conditions.
B.Environment checks.
C.Approval gates.
D.Manual intervention task.
AnswerC

Approval gates provide manual approval with review and reject.

Why this answer

Option B is correct because approval gates allow manual approval with review. Option A is wrong because pre-deployment conditions include approvals but the gate is the feature. Option C is wrong because it only requires a manual step, not a proper approval with rejection capability.

Option D is wrong because checks are for Azure environments.

Full explanation →
639
MCQmedium

Your Azure Pipelines build uses a self-hosted agent that runs on a Windows VM. The build fails with the error 'Access to the path 'C:\agent\_work\1\s\bin' is denied.' What is the most likely cause?

A.The agent service account does not have write permissions on the working directory
B.The agent is not configured to use the correct agent pool
C.The build is trying to overwrite a file that is locked by another process
D.The source code checkout failed due to incorrect credentials
AnswerA

The agent runs under a service account that needs write access to the working directory.

Why this answer

Option A is correct because the agent runs as a service with a specific account that may not have write permissions. Option B is wrong because the issue is not about checkout. Option C is wrong because the error is about access, not file in use.

Option D is wrong because the agent is registered and working.

Full explanation →
640
MCQmedium

You are setting up a release pipeline for an ASP.NET Core application that is deployed to Azure App Service (Windows). The application uses Entity Framework Core for database migrations. You need to automate the execution of database migrations during deployment, ensuring that the migrations run only once and that the application is not started until the migration completes. You also need to handle rollback in case the migration fails. The pipeline should deploy to staging slot, run migrations, swap to production, and then run post-swap migrations if needed. Currently, the pipeline deploys the code and then runs a script to execute 'dotnet ef database update'. However, during swap, the staging slot's migrations may conflict with production. What is the recommended architecture for handling database migrations with zero-downtime deployment?

A.Use Idempotent migrations and run them in the staging slot before swap. Then, after swap, run migrations again in the production slot to ensure any remaining changes are applied.
B.Run migrations only in the staging slot before swap. After swap, the production slot will use the new schema automatically.
C.Run migrations only after the swap is complete, in the production slot. The application is stopped during migration to avoid errors.
D.Disable automatic migration execution in the pipeline. Instead, have a separate manual process to run migrations using a dedicated tool.
AnswerA

Idempotent migrations can be run multiple times safely, and running them before and after swap ensures both slots have the correct schema without downtime.

Why this answer

Option C is correct because using Idempotent migrations allows you to run them before swap without affecting production, and running them again after swap ensures any additional changes are applied. Running migrations before swap ensures the staging slot has the updated schema, and after swap, the production slot also gets the updates. Idempotent migrations ensure that running them multiple times is safe.

Option A is wrong because running migrations only in staging before swap does not update production's database unless you run migrations after swap. Option B is wrong because running migrations only after swap causes downtime during migration. Option D is wrong because disabling automatic migration and using manual scripts adds risk and does not ensure zero-downtime.

Full explanation →
641
MCQeasy

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

A.Dependabot alerts
B.GitHub Copilot
C.Code scanning
D.Secret scanning
AnswerD

Secret scanning detects tokens, keys, and other secrets.

Why this answer

Secret scanning is the correct answer because it is the GitHub feature specifically designed to automatically detect exposed credentials, such as API keys, tokens, and passwords, in code repositories. It scans for known patterns of secrets and can alert both the repository owner and the partner service (e.g., AWS, Azure) to revoke the compromised credential. This directly addresses the requirement to automatically detect exposed credentials in code.

Exam trap

The trap here is that candidates often confuse Code scanning (which finds code vulnerabilities) with Secret scanning (which finds credentials), but Azure and GitHub treat them as separate features with distinct purposes and detection mechanisms.

How to eliminate wrong answers

Option A is wrong because Dependabot alerts focus on vulnerable dependencies and outdated packages, not on detecting exposed credentials or secrets in code. Option B is wrong because GitHub Copilot is an AI-powered code completion tool that suggests code snippets, not a security scanning feature for detecting credentials. Option C is wrong because Code scanning (powered by CodeQL) identifies code quality issues and security vulnerabilities like SQL injection or cross-site scripting, but it does not natively scan for hardcoded secrets or credentials; secret scanning is a separate, dedicated feature.

Full explanation →
642
MCQhard

Your release pipeline deploys a .NET Core web app to Azure App Service using a slot swap strategy. The pipeline runs acceptance tests on the staging slot before swapping. After a recent change, the acceptance tests pass but the production site becomes unresponsive after the swap. What is the most likely cause?

A.The staging slot had different app settings that were swapped into production, causing the site to fail.
B.The acceptance tests are not comprehensive enough and missed a regression.
C.The acceptance tests should have been run after the swap.
D.The slot swap was not 'warm-up' and caused downtime.
AnswerA

Slot swap swaps all settings, so if staging settings are not suited for production, the site can become unresponsive.

Why this answer

Option C is correct because slot swap swaps the entire configuration including connection strings and app settings. If the staging slot had different configuration values that are incompatible with production, the swap can cause issues. Option A is wrong because the tests passed on staging.

Option B is wrong because slot swap is designed to be zero-downtime. Option D is wrong because the issue is not related to test failure but to configuration after swap.

Full explanation →
643
Multi-Selecteasy

Which TWO features of Azure Pipelines help you manage build artifacts across stages? (Choose two.)

Select 2 answers
A.Pipeline variables
B.Release gates
C.Build tags
D.Download Pipeline Artifact task
E.Publish Pipeline Artifact task
AnswersD, E

This task downloads artifacts.

Why this answer

Options A and D are correct. A allows sharing artifacts between stages. D allows downloading artifacts from a previous stage.

B is wrong because variables are not artifacts. C is wrong because build tags are for filtering, not artifact management.

Full explanation →
644
Multi-Selecthard

A company uses Azure DevOps and requires that all pipeline runs are audited and that sensitive information (e.g., passwords, keys) is never exposed in logs. Which THREE actions should you take? (Choose THREE.)

Select 3 answers
A.In tasks that run scripts, set the 'Logging command' option to 'ignore' to prevent script output from being captured in the log.
B.Store all sensitive information in a variable group and reference it in the pipeline.
C.Configure the service connection to use 'Read-only' scope.
D.Use secret pipeline variables and ensure the 'Log secret values in the pipeline' checkbox is unchecked.
E.Enable Azure DevOps audit logging and send logs to a security information and event management (SIEM) system.
AnswersA, D, E

This prevents any output from the script from appearing in logs.

Why this answer

Option A is correct because setting the 'Logging command' option to 'ignore' in script tasks prevents the script's standard output from being captured in the Azure DevOps pipeline logs. This is a direct way to avoid leaking sensitive information that might be printed by the script, such as passwords or keys, ensuring they are not exposed in the audit trail.

Exam trap

The trap here is that candidates often confuse variable groups with secret variables, thinking that storing sensitive data in a variable group automatically masks it in logs, when in fact only secret pipeline variables with the logging checkbox unchecked provide that protection.

Full explanation →
645
MCQmedium

Refer to the exhibit. You run an ARM template deployment and get the error shown. What is the most likely cause?

A.The template references a resource that already exists and conflicts with the deployment.
B.The deployment name already exists in the resource group.
C.The resource group location does not match the template location.
D.The template has a syntax error in the JSON.
AnswerA

Correct. The inner error indicates a user 'adminuser' already exists in the resource group, causing a conflict.

Why this answer

The error details show a Conflict with message 'User 'adminuser' already exists in this resource group.' This indicates the template tries to create a resource that already exists, causing a conflict.

Full explanation →
646
MCQmedium

You work for a multinational company that uses Azure Repos. The compliance team requires that all code changes include a work item reference in the commit message. What is the most effective way to enforce this?

A.Create a script in the build pipeline that checks the commit message
B.Configure a client-side commit hook that validates the commit message
C.Set a branch policy that requires a linked work item for pull requests
D.Use a custom build task to automatically add the work item ID to the commit message
AnswerC

Branch policies enforce the requirement server-side before merge.

Why this answer

Option C is correct because a branch policy in Azure Repos that requires linked work items for pull requests enforces the compliance requirement at the server side, ensuring that every pull request merge includes a work item reference. This policy is enforced before the merge completes, making it a reliable and auditable method that cannot be bypassed by individual developers. It directly integrates with Azure Boards to validate the link, providing a centralized enforcement mechanism.

Exam trap

The trap here is that candidates often confuse client-side hooks (Option B) with server-side enforcement, not realizing that client-side hooks are optional and can be easily bypassed, whereas branch policies in Azure Repos provide mandatory, centralized enforcement that cannot be overridden by individual developers.

How to eliminate wrong answers

Option A is wrong because a build pipeline script that checks the commit message runs after the code is already pushed, meaning it can only fail the build but cannot prevent non-compliant commits from entering the repository; it also adds overhead and can be bypassed if the build is skipped. Option B is wrong because a client-side commit hook is only enforced locally on the developer's machine and can be easily disabled or bypassed by the developer, providing no centralized or reliable enforcement for the team. Option D is wrong because a custom build task that automatically adds a work item ID to the commit message does not enforce the requirement; it modifies the commit after the fact, which is not a valid approach for commit messages (which are immutable once created), and it does not ensure that the developer actually references a work item.

Full explanation →
647
Multi-Selecthard

Which TWO of the following are valid strategies to reduce the build time of a container image in Azure Pipelines?

Select 2 answers
A.Combine multiple RUN commands into a single RUN instruction to reduce layers.
B.Build multiple images in parallel using matrix strategy.
C.Use Docker layer caching with a registry cache.
D.Disable security scanning for the image.
E.Use a larger build agent with more CPU cores.
AnswersB, C

Parallel builds can reduce overall time.

Why this answer

Options A and D are correct. Option A reduces build time by reusing cached layers. Option D reduces build time by parallelizing image builds.

Option B is wrong because using a larger agent may not reduce build time if the bottleneck is network or I/O. Option C is wrong because running all commands in a single layer reduces layers but does not significantly reduce build time. Option E is wrong because skipping security scanning does not reduce build time.

Full explanation →
648
Multi-Selectmedium

Which TWO options are valid ways to communicate build status from Azure Pipelines to external stakeholders?

Select 2 answers
A.Create a work item in Azure Boards for each build.
B.Export pipeline logs to Power BI for reporting.
C.Configure a Service Hook to post to a Slack channel.
D.Set up an email notification for specific events.
E.Use a release pipeline to send SMS via Twilio.
AnswersC, D

Service Hooks support Slack.

Why this answer

Service Hooks in Azure Pipelines allow you to integrate with external services like Slack by triggering HTTP POST requests containing build status payloads. This enables real-time notifications to stakeholders without requiring custom scripting or additional infrastructure, making it a valid and direct communication method.

Exam trap

The trap here is that candidates may think any integration is valid if it's technically possible (like using a release pipeline to call Twilio), but the question asks for 'valid ways' meaning standard, built-in, or officially supported methods within Azure Pipelines.

Full explanation →
649
MCQhard

You are designing an instrumentation strategy for a microservices application deployed to Azure Kubernetes Service (AKS) using Azure Pipelines. The application emits custom metrics using OpenTelemetry. You need to ensure that all pipeline-related events (build, release, and test results) are correlated with application telemetry to enable end-to-end traceability. What should you do?

A.Configure Application Insights to ingest pipeline telemetry via a custom exporter.
B.Store pipeline logs in an Azure Log Analytics workspace and query them together with application metrics.
C.Use Azure Pipelines' Checks feature to enforce deployment gates based on application metrics.
D.Set a unique Correlation ID in the pipeline variables and pass it to the application's OpenTelemetry instrumentation as a span attribute.
AnswerD

Correlation ID enables linking pipeline and application telemetry.

Why this answer

Option C is correct because using the Correlation ID in both pipeline variables and OpenTelemetry spans enables correlation. Option A is wrong because Azure Monitor logs don't correlate with pipeline data. Option B is wrong because Application Insights alone doesn't pull pipeline data.

Option D is wrong because pipeline artifacts don't include telemetry.

Full explanation →
650
MCQhard

You have a classic release pipeline that deploys to Azure App Service. You need to implement a canary deployment strategy where 10% of traffic is routed to the new version for 30 minutes before full rollout. What should you use?

A.Configure multiple deployment slots and use Traffic Manager to distribute traffic.
B.Use the 'Azure App Service deploy' task with the 'Deploy to Slot' option, then manually adjust routing rules.
C.Deploy to a staging slot and then use Azure CLI to update routing rules after deployment.
D.Use slot swap with 'Swap with preview' and set traffic percentage in the swap settings.
AnswerD

Swap with preview allows you to validate and gradually increase traffic before full swap.

Why this answer

Azure App Service deployment slots with slot swap with preview allow you to route a percentage of traffic to the new version before swapping fully.

Full explanation →
651
MCQmedium

Your team uses Azure Pipelines with GitHub for source control. You need to ensure that whenever a pull request is created against the main branch, a validation build runs automatically. Which YAML trigger should you configure in the pipeline?

A.pr: branches: include: - main
B.pr: main
C.trigger: branches: exclude: - main
D.trigger: main
AnswerB

Correct: PR trigger on main runs validation builds for PRs targeting main.

Why this answer

Option A is correct because the pr trigger on main runs a validation build on pull requests targeting main. Option B is wrong because branches spec limits PR trigger to branches when PR source is from that branch. Option C is wrong because trigger is for CI builds, not PR validation.

Option D is wrong because exclude removes branches from CI trigger.

Full explanation →
652
MCQeasy

Your organization uses Azure DevOps and GitHub. You need to ensure that secrets such as API keys are not exposed in pipeline logs. What should you do?

A.Store the API key in a plain text variable and reference it as $(apiKey)
B.Store the API key in Azure Key Vault and use a variable group linked to the vault
C.Store the API key in a secret variable
D.Use the Logging Command to suppress output
AnswerC

Secret variables are masked in logs.

Why this answer

Azure Pipelines allows marking variables as secret, which hides them in logs. Option A is wrong because environment variables still appear in logs. Option C is wrong because Azure Key Vault stores secrets but you need to map them to secret variables.

Option D is wrong because logging warnings still expose the secret.

Full explanation →
653
MCQeasy

You are setting up a build pipeline for a Node.js application that uses npm for package management. The pipeline should restore npm packages on every build, but you want to leverage caching to speed up the process. The pipeline runs on a Microsoft-hosted agent. You also need to ensure that the build fails if any npm audit vulnerabilities are found. Which tasks and configuration should you use?

A.Use the 'npm' task with 'custom' command to run 'npm ci'. Use the 'Cache' task to cache 'node_modules' with a key based on 'package.json'.
B.Use the 'npm' task with 'install' command without caching. After install, run a PowerShell script to run 'npm audit --audit-level=high' and parse the output.
C.Use the 'npm' task with 'ci' command and set 'ignoreScripts' to true. Add a 'npm audit' task but set 'failOnVulnerabilities' to 'false' to avoid build failures.
D.Use the 'npm' task with 'install' command and enable caching by setting the 'workingDirectory' variable. Run a separate 'npm' task with 'audit' command and set 'failOnVulnerabilities' to 'true'.
AnswerD

This is the correct approach: restore, cache, and audit with fail on vulnerabilities.

Why this answer

The npm task with 'install' restores packages, and the 'npm audit' command checks for vulnerabilities. Caching is done with the Cache task using a key based on package-lock.json.

Full explanation →
654
MCQhard

Your organization uses GitHub for source control and GitHub Actions for CI/CD. You need to implement a branching strategy where every commit to the main branch triggers a build and deployment to a staging environment, but only after a successful pull request review. Which GitHub Actions trigger should you use?

A.pull_request_target with branches: [main] and types: [closed]
B.push with branches: [main]
C.pull_request with branches: [main]
D.workflow_dispatch
AnswerA

This trigger fires when a PR is closed (merged) into main, ensuring review was completed.

Why this answer

Option A is correct because the `pull_request_target` trigger with `types: [closed]` and `branches: [main]` ensures the workflow runs only after a pull request targeting the main branch is closed (merged). This satisfies the requirement of deploying to staging only after a successful pull request review and merge, not on every push. The `pull_request_target` event runs in the context of the base repository, providing access to secrets, which is appropriate for deployment workflows.

Exam trap

The trap here is confusing `pull_request` (which triggers on PR events like opened or synchronized) with `pull_request_target` (which triggers on PR events but runs in the base repo context), and forgetting that `types: [closed]` is needed to run after merge, not during the PR lifecycle.

How to eliminate wrong answers

Option B is wrong because a `push` trigger on `main` would run the workflow on every commit to main, including direct pushes that bypass pull request review, which violates the requirement for a successful review before deployment. Option C is wrong because `pull_request` triggers on pull request creation or updates (e.g., opened, synchronized), not specifically after the PR is closed/merged; it would run during the review process, not after approval. Option D is wrong because `workflow_dispatch` is a manual trigger that requires someone to manually run the workflow, which does not automate the deployment after a pull request merge.

Full explanation →
655
MCQhard

You are designing a security compliance plan for Azure Pipelines. The plan must ensure that all pipelines: (1) run on Microsoft-hosted agents in a specific geo-region, (2) use approved Docker images from a private Azure Container Registry, and (3) enforce that pipeline variables containing secrets are never logged. Which combination of Azure DevOps features should you use?

A.Compliance gates in release pipelines, service connections, and audit logs
B.Agent pools with geo-filtering, Azure Policy for Repos to restrict image sources, and secret variables with 'Logging command' disabled
C.Entra ID Conditional Access, Azure Container Registry firewall, and pipeline decorators
D.Azure Policy for Pipelines, secret variables, and geo-restricted agent pools
AnswerB

This combination addresses all three requirements.

Why this answer

Option D (Agent pools with geo-filtering, Azure Policy for Repos to restrict image sources, and secret variables with 'Logging command' disabled) is correct. Agent pools can be scoped to a specific geography. Azure Policy for Repos can enforce that pipelines only use approved container registries.

Secret variables in Azure Pipelines have an option to 'Allow at runtime' and can be marked as secret to prevent logging. Option A uses Azure Policy for Pipelines (not a real feature). Option B's compliance gates are for release pipelines, not build.

Option C's Access reviews are for user permissions, not image sources.

Full explanation →
656
MCQhard

Refer to the exhibit. You deploy this Bicep template to create an Azure App Service with a custom container. The deployment succeeds, but the container fails to start with an error 'Container didn't respond to HTTP pings'. What is the most likely missing configuration?

A.The template is missing the 'healthCheckPath' property in siteConfig.
B.The container image is not publicly accessible.
C.The WEBSITES_ENABLE_APP_SERVICE_STORAGE should be set to 'true'.
D.The template is missing the app setting 'WEBSITES_PORT'.
AnswerA

The health check path should be configured to match the container's endpoint.

Why this answer

Option D is correct because the container needs a health check path; the default is '/', but the container may expect a different path. Option A is wrong because the docker image is specified. Option B is wrong because the storage setting is not critical.

Option C is wrong because the app setting is present.

Full explanation →
657
MCQeasy

Your team is using GitHub Enterprise and wants to ensure that every pull request includes a link to a work item in Azure Boards. Which GitHub Apps or Azure DevOps Services integration should you configure?

A.GitHub-Azure Boards integration
B.Azure Repos branch policy
C.Azure DevOps OAuth app
D.Azure Pipelines GitHub App
AnswerA

This integration can require work item linking in GitHub PRs.

Why this answer

Option B (GitHub-Azure Boards integration) is correct because this official integration enforces linking work items to PRs. Option A is for Azure Repos. Option C is for Azure Pipelines.

Option D is a generic term, not a specific integration.

Full explanation →
658
MCQhard

Your team is adopting Infrastructure as Code (IaC) using Bicep. You have a multi-stage YAML pipeline that deploys Azure resources to dev, test, and prod environments. You need to ensure that the Bicep files are validated and deployed consistently, and that any changes to the infrastructure are approved for production. You also want to use the latest version of the Azure CLI task. What is the recommended approach?

A.Use the Azure Resource Manager Template Deployment task with the 'templateLocation' parameter pointing to the compiled ARM JSON.
B.Create three separate pipelines for each environment, each using the ARM Template Deployment task.
C.Use the AzureCLI task with inline script to run 'az deployment group validate' and 'az deployment group create'. Add environments with approval gates for production.
D.Use a PowerShell task with the 'New-AzResourceGroupDeployment' cmdlet.
AnswerC

AzureCLI supports latest Bicep and validation.

Why this answer

Option A is correct because it uses AzureCLI task with Bicep commands and environments for approvals. Option B is incorrect because ARM template deployment task may not support latest Bicep features. Option C is incorrect because PowerShell task lacks native Bicep support.

Option D is incorrect because separate pipeline per environment duplicates.

Full explanation →
659
MCQhard

Your organization uses GitHub Actions and needs to enforce that only approved actions from the GitHub Marketplace can be used in workflows. Developers have been using custom actions from third-party repositories. What is the most effective way to control which actions are allowed?

A.Create a manual approval process for each new action.
B.Set the organization to disallow all third-party actions.
C.Configure the organization to allow only actions created by GitHub.
D.Use the 'Allow actions created by GitHub and verified partners' policy and add specific actions to the allow list.
AnswerD

This provides granular control over allowed actions.

Why this answer

Option D is correct because GitHub allows organization owners to set a policy to allow only specific actions, including those from the marketplace. Option A is incorrect because it does not restrict third-party actions. Option B is incorrect because disabling third-party actions entirely may block legitimate needs.

Option C is incorrect because manual review is not scalable.

Full explanation →
660
Multi-Selecthard

Which THREE options are valid strategies to reduce build times in Azure Pipelines? (Choose three.)

Select 3 answers
A.Enable incremental builds by using the 'Clean: false' option.
B.Use a self-hosted agent with a local cache of dependencies.
C.Break the pipeline into multiple stages running sequentially.
D.Increase the number of parallel jobs in the pipeline.
E.Use the 'Cache' task to cache folders like node_modules or .m2.
AnswersA, B, E

Incremental builds only rebuild changed code.

Why this answer

Valid strategies: using a self-hosted agent with caching (A), using incremental builds (B), and using pipeline caching (D). Option C is wrong because increasing parallel jobs does not reduce build time for a single pipeline; it allows more builds to run concurrently but each build takes the same time. Option E is wrong because using multiple stages does not reduce build time; it adds sequential dependencies.

Full explanation →
661
Drag & Dropmedium

Drag and drop the steps to set up a self-hosted Azure DevOps agent on a Windows VM 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

Agent setup requires PAT creation, download, configuration, registration, and service start.

Full explanation →
662
MCQmedium

Your team uses Azure Pipelines for CI/CD. You need to ensure that a secret variable stored in Azure Key Vault is available to a build pipeline without exposing it in logs. What should you do?

A.Store the secret in a variable group linked to Key Vault and reference it without marking it secret.
B.Add the secret as a plain text variable in the pipeline YAML.
C.Use a Key Vault task to fetch the secret and map it to a pipeline variable marked 'secret'.
D.Add the secret to the repository's .env file and use a script to read it.
AnswerC

Key Vault task with secret mapping prevents logging.

Why this answer

Option C is correct because mapping a Key Vault secret to a pipeline variable and marking it as 'secret' ensures it is not logged. Option A is wrong because inline secrets are logged. Option B is wrong because variable groups don't automatically mask secrets.

Option D is wrong because secret variables are not available in checkout tasks.

Full explanation →
663
MCQhard

Your team is adopting GitFlow with a main and develop branch. You need to ensure that hotfix branches are merged into both main and develop, but feature branches only into develop. What branch policy configuration should you implement?

A.Set the main branch to require all merges to come from pull requests, and for develop, allow direct pushes.
B.Use branch policies on main and develop that allow only certain source branches to merge, using branch naming conventions.
C.Configure a global policy that requires all branches to have a minimum number of reviewers.
D.Use a build validation policy to check the branch name and reject merges that do not follow the pattern.
AnswerB

Branch policies can restrict source branches via naming patterns.

Why this answer

Option B is correct because Azure Repos branch policies allow you to restrict which source branches can merge into a target branch using branch naming conventions. By configuring policies on `main` and `develop` that only permit merges from specific source patterns (e.g., `hotfix/*` for `main` and `develop`, and `feature/*` only for `develop`), you enforce the GitFlow workflow without relying on manual oversight or build validation logic.

Exam trap

The trap here is that candidates confuse build validation policies (which run after PR creation) with branch-level source branch restrictions (which prevent PR creation entirely), leading them to choose Option D despite it being a reactive rather than proactive control.

How to eliminate wrong answers

Option A is wrong because allowing direct pushes to `develop` bypasses pull request validation, which is required to enforce merge source restrictions and review requirements; it does not prevent feature branches from merging into `main`. Option C is wrong because a global policy requiring a minimum number of reviewers does not control which source branches can merge into specific target branches; it only adds review overhead without enforcing GitFlow merge rules. Option D is wrong because build validation policies run after a pull request is created and can reject based on branch name, but they cannot prevent the pull request from being created in the first place and are not a native branch policy for restricting source branches; they are more suitable for code quality checks.

Full explanation →
664
MCQhard

Your company uses GitHub Advanced Security. You need to ensure that all code in the main branch is free of high-severity secrets before deployment. What is the most efficient way to enforce this?

A.Require manual review of all pull requests for secrets
B.Enable secret scanning push protection
C.Configure Dependabot to flag secrets in dependencies
D.Enable code scanning alerts for secrets
AnswerB

Push protection prevents commits that contain secrets from being pushed.

Why this answer

Option B is correct because secret scanning push protection blocks commits containing secrets. Option A is wrong because code scanning alerts are not blocked at push time. Option C is wrong because Dependabot alerts are for dependencies, not secrets.

Option D is wrong because manual review is not efficient.

Full explanation →
665
MCQhard

A company uses Microsoft Defender for Cloud to assess the security posture of Azure Pipelines agents. They notice that self-hosted agents are flagged as having high-severity vulnerabilities. What is the recommended action to remediate these findings while minimizing downtime?

A.Disable Microsoft Defender for Cloud for the agent pool.
B.Uninstall the self-hosted agents and use only Microsoft-hosted agents.
C.Apply the security updates recommended by Microsoft Defender for Cloud to the agent VMs.
D.Replace all self-hosted agents with Microsoft-hosted agents.
AnswerC

This directly remediates the vulnerabilities on the self-hosted agents.

Why this answer

Option B is correct because using Microsoft Defender for Cloud's recommendation to update the agent VM with the latest security patches is the standard remediation. Option A is wrong because switching to Microsoft-hosted agents may not meet compliance requirements and does not remediate existing vulnerabilities. Option C is wrong because disabling Defender for Cloud would remove visibility.

Option D is wrong because uninstalling agents is not a remediation.

Full explanation →
666
MCQhard

Your YAML pipeline uses a self-hosted agent pool. You need to ensure that only the pipeline can trigger builds on that pool, preventing other projects from using it. What should you do?

A.Set the agent pool to 'Disabled' for other projects
B.Configure pipeline permissions in the agent pool security settings
C.Use a deployment group instead of an agent pool
D.Create a separate agent pool for each project
AnswerB

Why this answer

Option B is correct because Azure DevOps agent pool security settings allow you to restrict which pipelines or projects can use a specific agent pool. By configuring pipeline permissions, you can grant the 'Use' permission only to the intended pipeline, preventing other projects from triggering builds on that pool. This ensures exclusive access without disabling the pool for all other uses.

Exam trap

The trap here is that candidates often confuse disabling the pool for other projects (Option A) with permission-based restrictions, not realizing that disabling removes all access, including the intended pipeline's ability to use it.

Why the other options are wrong

A

Disabling the pool prevents all usage, including the intended pipeline.

C

Deployment groups are for targeting specific servers, not for access control.

D

That would work but is not necessary; you can secure a single pool with permissions.

Full explanation →
667
Multi-Selecteasy

You are configuring a continuous integration (CI) trigger for your YAML pipeline. The trigger should run the pipeline when changes are pushed to the 'main' branch or any release branch matching 'release/*'. Which TWO trigger configurations are valid? (Choose two.)

Select 2 answers
A.trigger: branches: exclude: - main
B.trigger: branches: include: - main
C.branches: include: - main
D.trigger: branches: main
E.trigger: branches: include: - release/*
AnswersB, E

Correct: includes main branch.

Why this answer

Options A and B are correct. Option A uses exact branch name. Option B uses wildcard for release branches.

Option C is wrong because 'include' should be a list. Option D is wrong because 'branches' is nested under 'trigger'. Option E is wrong because 'exclude' is not needed.

Full explanation →
668
Matchingmedium

Match each Azure Artifacts feed type to its description.

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

Concepts
Matches

Accessible to all projects in the organization

Accessible only within a specific project

Caches packages from external sources like NuGet.org

Filters packages by release status (e.g., prerelease)

Why these pairings

Feed types and features in Azure Artifacts.

Full explanation →
669
MCQmedium

A company uses Azure Pipelines to deploy microservices to Azure Kubernetes Service (AKS). They want to implement a canary deployment strategy. What should they use?

A.Use Kubernetes native deployment strategies with multiple replica sets and traffic splitting
B.Use Azure Front Door to route traffic between clusters
C.Use deployment slots in Azure App Service
D.Use Azure Container Instances as a staging environment
AnswerA

Kubernetes supports canary deployments via service mesh, multiple deployments, and traffic routing.

Why this answer

Option A is correct because Kubernetes natively supports canary deployments by running multiple replica sets of the same application and using a service mesh or ingress controller (e.g., Istio, NGINX Ingress) to split traffic between the stable and canary versions. Azure Pipelines can orchestrate this by updating the canary deployment and adjusting traffic weights gradually, enabling controlled rollouts and rollbacks without external routing services.

Exam trap

The trap here is that candidates confuse Azure Front Door’s global traffic routing with Kubernetes-native traffic splitting, assuming a PaaS-level service can replace the granular, service-mesh-based canary logic required within a single AKS cluster.

How to eliminate wrong answers

Option B is wrong because Azure Front Door is a global load balancer and application delivery network that routes traffic between entire clusters or regions, not between microservice versions within the same AKS cluster; it cannot perform fine-grained canary traffic splitting at the pod or replica set level. Option C is wrong because deployment slots are a feature of Azure App Service, not AKS; they apply to web apps running on Windows or Linux App Service plans, not to containerized microservices orchestrated by Kubernetes. Option D is wrong because Azure Container Instances (ACI) is a serverless container runtime for running individual containers, not a staging environment for canary deployments; it lacks the orchestration, service discovery, and traffic management capabilities needed to split traffic between versions of a microservice.

Full explanation →
670
MCQmedium

A development team is transitioning from a centralized version control system to Git in Azure Repos. The team lead wants to ensure that the branch structure supports both feature development and hotfix releases, with the ability to stabilize a release candidate before final deployment. Which branch strategy should the team implement?

A.Use trunk-based development with short-lived feature branches that merge directly to main.
B.Use a forking workflow where each developer forks the repository and creates pull requests.
C.Use Git Flow with feature, develop, release, and main branches.
D.Use GitHub Flow with feature branches and pull requests directly to main.
AnswerC

Git Flow provides release branches for stabilization before merging to main.

Why this answer

Git Flow is the correct choice because it explicitly supports feature development, release stabilization, and hotfix releases through its structured branch hierarchy. The release branch allows the team to stabilize a release candidate before merging to main, while hotfix branches can be created from main for urgent fixes. This aligns perfectly with the requirement for both feature development and hotfix releases with release candidate stabilization.

Exam trap

The trap here is that candidates often confuse GitHub Flow (option D) with Git Flow, but GitHub Flow lacks the dedicated release and hotfix branches needed for the described release stabilization and hotfix requirements.

How to eliminate wrong answers

Option A is wrong because trunk-based development with short-lived feature branches merging directly to main does not provide a dedicated release branch for stabilizing a release candidate before final deployment, nor does it inherently support hotfix releases without disrupting ongoing development. Option B is wrong because a forking workflow is designed for open-source collaboration where contributors do not have direct write access, not for managing a structured branch strategy with release and hotfix branches within a single team's repository. Option D is wrong because GitHub Flow uses feature branches and pull requests directly to main, which lacks a separate release branch for stabilization and a dedicated hotfix workflow, making it unsuitable for scenarios requiring release candidate stabilization.

Full explanation →
671
MCQmedium

Your company uses Microsoft Purview to manage data governance. You need to classify a new dataset containing personally identifiable information (PII) and apply a data loss prevention (DLP) policy. What should you do first?

A.Create a sensitivity label in Microsoft Purview
B.Add the data source to an Azure service tag
C.Define a DLP policy in Microsoft Purview
D.Register and scan the data source in Microsoft Purview
AnswerD

Scanning classifies data automatically based on built-in classifiers.

Why this answer

Option A is correct because scanning the data source in Purview automatically classifies sensitive data. Option B is wrong without scanning first. Option C is wrong because DLP policies require classification.

Option D is wrong because service tags do not classify data.

Full explanation →
672
MCQmedium

You are implementing a CI pipeline for a Node.js application. The pipeline must run unit tests and generate code coverage reports. You want to publish the coverage results to Azure DevOps and enforce a minimum coverage threshold of 80%. Which tasks should you use?

A.Use the Publish Test Results task to publish coverage data.
B.Use the Publish Build Artifacts task with coverage files.
C.Use the Copy Files task to copy coverage files and then the Publish Build Artifacts task.
D.Use the Publish Code Coverage Results task and configure the threshold in the task settings.
AnswerD

This task publishes coverage and can enforce thresholds.

Why this answer

PublishCodeCoverageResults publishes coverage reports, and the threshold can be enforced via a script or gate. Option A is wrong because CopyFiles copies files, not coverage. Option C is wrong because PublishTestResults publishes test results, not coverage.

Option D is wrong because PublishBuildArtifacts publishes build artifacts, not coverage.

Full explanation →
673
MCQeasy

You need to deploy a web app to Azure App Service using Azure Pipelines. The deployment slot should be 'staging' first, and after smoke tests, swap to production. Which deployment strategy should you use?

A.Slot swap
B.Canary deployment
C.Rolling update
D.Blue-green deployment
AnswerA

Azure App Service slots allow deploying to staging and swapping to production.

Why this answer

Option B is correct because slot swap allows deploying to staging and swapping to production. Option A is wrong because rolling update updates instances gradually without slots. Option C is wrong because blue-green requires separate environments.

Option D is wrong because canary routes a small percentage of traffic.

Full explanation →
674
MCQhard

Refer to the exhibit. A developer runs 'git log --oneline --graph --decorate' and sees the output. Which Git workflow does this history most closely represent?

A.GitLab Flow
B.Trunk-based development
C.GitHub Flow
D.Git Flow
AnswerD

Git Flow uses feature branches with merge commits.

Why this answer

The output of `git log --oneline --graph --decorate` shows multiple long-lived branches (e.g., `develop`, `feature/*`, `release/*`, `hotfix/*`) with periodic merges back to `develop` and `main`. This branching structure with dedicated branches for features, releases, and hotfixes is the hallmark of Git Flow, which uses a strict branching model to manage releases and maintenance in parallel.

Exam trap

The trap here is that candidates see a graph with multiple branches and assume it represents GitHub Flow or trunk-based development, but the presence of both `develop` and `release` branches specifically indicates Git Flow, not simpler workflows.

How to eliminate wrong answers

Option A is wrong because GitLab Flow typically uses environment branches (e.g., `staging`, `production`) and feature branches that merge directly into `main`, not the multi-tiered `develop`/`release`/`hotfix` structure shown. Option B is wrong because trunk-based development keeps branches extremely short-lived (hours to a day) and merges directly to a single trunk (e.g., `main`), without long-lived `develop` or `release` branches. Option C is wrong because GitHub Flow uses a single `main` branch with short-lived feature branches that are merged via pull requests, lacking the `develop`, `release`, and `hotfix` branches visible in the graph.

Full explanation →
675
MCQeasy

You need to configure a release pipeline that deploys to Azure App Service. The deployment should use the 'slot swap' strategy to minimize downtime. Which deployment slot should you initially deploy to?

A.Production slot
B.Warmup slot
C.Staging slot
D.All slots simultaneously
AnswerC

Deploy to staging, then swap to production for zero-downtime.

Why this answer

Option B is correct because you should deploy to a non-production slot (e.g., staging), then swap it with the production slot. Option A is wrong because deploying directly to production defeats the purpose of slot swap. Option C is wrong because Azure DevOps does not have a 'warmup' slot.

Option D is wrong because you should deploy to a specific slot, not all slots.

Full explanation →
Page 8

Page 9 of 13

Page 10

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 →