Courseiva

Microsoft Azure DevOps Engineer Expert AZ-400 (AZ-400) — Questions 151–225

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

Take a mock examExam hub
Page 2

Page 3 of 13

Page 4
151
MCQeasy

Your team uses GitHub Actions for CI/CD. You want to securely store a database connection string used in a workflow. Where should you store it?

A.GitHub Secrets.
B.Workflow environment variables.
C.Directly in the workflow YAML.
D.In a configuration file committed to repo.
AnswerA

Secrets are encrypted and secure for sensitive values.

Why this answer

Option A is correct because GitHub Secrets are encrypted and designed for sensitive data. Option B is wrong because environment variables are not encrypted. Option C is wrong because hardcoding is insecure.

Option D is wrong because configuration file in repo is not secure.

Full explanation →
152
Multi-Selectmedium

Which TWO options are benefits of using Git LFS (Large File Storage) in a team environment? (Select TWO.)

Select 2 answers
A.Prevents large files from being stored in the Git history
B.Automatically detects and tracks all binary files in the repository
C.Reduces the size of Git repository clones and fetches for team members
D.Works only with GitHub and Azure Repos
E.Eliminates the need for Git when working with large binary files
AnswersA, C

LFS stores large files separately.

Why this answer

Option A is correct because Git LFS replaces large files in the repository with text pointer files, while the actual file content is stored in a separate remote store. This prevents the large files from bloating the Git history, which would otherwise permanently increase repository size for all clones and fetches.

Exam trap

The trap here is that candidates may assume Git LFS automatically handles all binary files (Option B) or that it works only with specific platforms (Option D), when in fact it requires explicit configuration and is widely supported across providers.

Full explanation →
153
MCQhard

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

A.The policy blocks the pipeline from running if fewer than two reviewers approve.
B.The policy requires two reviewers and blocks the pipeline if not met.
C.The policy audits the pipeline but does not enforce any mandatory reviewers.
D.The policy does not apply to build pipelines because the field type is teamProjects.
AnswerC

The audit effect logs compliance without blocking.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
154
Multi-Selectmedium

Which THREE measures should you implement to protect secrets (e.g., API keys, passwords) used in Azure Pipelines?

Select 3 answers
A.Store secrets as plain text in a secure Git repo with restricted access
B.Mark variables as 'Secret' in pipeline YAML or UI definitions
C.Use environment variables in the pipeline to pass secrets at runtime
D.Use service connections with managed identity instead of personal access tokens
E.Store secrets in Azure Key Vault and reference them via a Key Vault task
AnswersB, D, E

Secret variables are masked in logs and output.

Why this answer

Option A, Option C, and Option D are correct. Option A (Use Azure Key Vault to store secrets) is a best practice. Option C (Mark variables as 'Secret' in pipeline definitions) prevents secrets from being exposed in logs.

Option D (Use service connections with managed identity instead of personal access tokens) reduces secret exposure. Option B is wrong because storing secrets in Git is insecure. Option E is wrong because environment variables are not encrypted by default.

Full explanation →
155
MCQmedium

Your organization uses GitHub Actions for CI/CD. The security team requires that all workflows are stored in a central repository and that only approved actions can be used. What should you implement?

A.Configure the repository to use only self-hosted runners.
B.Store all workflows in a central repository and use branch protection rules.
C.In the organization settings, configure the 'Actions permissions' to 'Allow specified actions' and add the approved actions to the allow list.
D.Enable 'Allow GitHub Actions to create and approve pull requests' in the repository settings.
AnswerC

This restricts workflows to only use actions from the allow list, enforcing security.

Why this answer

GitHub Actions allow you to restrict actions to only those in a specific organization or marketplace list via the 'Allow specified actions' policy. Setting 'Allow GitHub Actions to create and approve pull requests' is not relevant. Using reusable workflows in a central repository ensures standardization, but to restrict actions, you need the allow list policy.

Self-hosted runners do not enforce which actions are used.

Full explanation →
156
MCQhard

Your organization uses GitHub for source control and Azure Pipelines for CI/CD. You have a monorepo with multiple projects. You need to design a pipeline that only builds and tests the projects that have changed in each commit. You want to minimize build time and avoid unnecessary runs. The pipeline should also handle dependencies between projects. Which approach should you use?

A.Create a single pipeline that builds all projects on every commit
B.Configure path filters in the pipeline trigger, and use a custom script to detect dependencies and build only affected projects plus their dependents
C.Use a single pipeline with a condition that checks which files changed and runs only the corresponding job
D.Create separate pipelines for each project and trigger them manually
AnswerB

Path filters limit triggers and dependency detection ensures build correctness.

Why this answer

Using path filters with dependency detection is efficient. Option B builds all projects, wasting time. Option C builds changed projects but ignores dependencies.

Option D uses manual triggers, which is not automated.

Full explanation →
157
MCQeasy

Refer to the exhibit. You have a YAML pipeline that deploys an ARM template. The pipeline runs successfully on the first commit to main, but subsequent commits fail with 'The resource group myResourceGroup already exists'. How should you modify the pipeline to avoid this error?

A.Change the location to a different region.
B.Add a condition to check if the resource group exists before creating it.
C.Use a different service connection for each deployment.
D.Rename the pipeline to trigger a clean build.
AnswerB

Using an Azure CLI condition (e.g., 'az group exists') before creating avoids the error.

Why this answer

Option C is correct because adding a condition to check if the resource group exists before creating it will prevent the error. Option A is wrong because changing the location does not solve the existence issue. Option B is wrong because using a different pipeline name is irrelevant.

Option D is wrong because the error is not about credentials.

Full explanation →
158
Matchingmedium

Match each Git branching strategy to its description.

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

Concepts
Matches

Uses develop and feature branches with release branches

Feature branches merged to main with pull requests

Short-lived branches merged frequently to main

Main branch with release branches for production

Why these pairings

Common branching strategies used in Azure Repos.

Full explanation →
159
MCQhard

Refer to the exhibit. You are reviewing a branch protection rule for the main branch of a GitHub repository. A developer complains that after pushing new commits to an existing pull request, the existing approvals from two reviewers are dismissed, and the pull request cannot be merged even though the CI checks pass. What is the most likely cause?

A.The 'dismiss_stale_reviews' setting is enabled, which dismisses approvals when new commits are pushed.
B.The 'strict' setting requires the branch to be up to date with the base branch, which is not the case.
C.The code owner review is required but no code owner has reviewed.
D.The CI check 'continuous-integration/jenkins/pr-merge' failed.
AnswerA

This is the direct cause of the behavior described.

Why this answer

Option A is correct because the 'dismiss_stale_reviews' setting in GitHub branch protection rules automatically dismisses existing pull request approvals when new commits are pushed to the branch. This explains why the developer sees approvals removed after pushing new commits, even though CI checks pass. The setting is designed to ensure that reviewers re-evaluate changes after updates.

Exam trap

The trap here is that candidates may confuse the 'dismiss_stale_reviews' behavior with the 'strict' branch requirement, thinking that being out of date causes approval dismissal, when in fact 'strict' only blocks the merge button without affecting existing approvals.

How to eliminate wrong answers

Option B is wrong because the 'strict' setting (require branches to be up to date) would block merging if the branch is behind the base branch, but it does not dismiss existing approvals; it only prevents merge until the branch is updated. Option C is wrong because code owner review requirement would block merging if no code owner has approved, but it does not dismiss existing approvals from other reviewers; the complaint specifically mentions existing approvals being dismissed. Option D is wrong because the CI check 'continuous-integration/jenkins/pr-merge' passing is stated in the scenario, so a failed check is not the cause of dismissed approvals.

Full explanation →
160
MCQeasy

You want to ensure that every commit message in your repository follows a specific format. Which GitHub feature can enforce this?

A.Webhooks to validate and reject pushes
B.Branch protection rules
C.GitHub Actions workflow with push trigger
D.Required status checks with a commit lint action
AnswerD

A status check can validate commit messages and be required.

Why this answer

Option D is correct because required status checks, when combined with a commit lint action in a GitHub Actions workflow, can enforce commit message formatting. The workflow runs on push or pull request events, and the status check must pass before a pull request can be merged, effectively rejecting commits that do not conform to the specified format.

Exam trap

The trap here is that candidates confuse a GitHub Actions workflow that runs a commit lint action (which alone does not enforce anything) with the combination of that workflow and a required status check in branch protection rules, which is what actually enforces the commit message format.

How to eliminate wrong answers

Option A is wrong because webhooks can trigger external services to validate pushes, but they cannot directly reject pushes; they only send event payloads. Option B is wrong because branch protection rules can require status checks, code reviews, or prevent force pushes, but they cannot enforce commit message formatting on their own. Option C is wrong because a GitHub Actions workflow with a push trigger can run a commit lint action, but without a required status check configured in branch protection rules, the workflow result does not block non-conforming commits from being merged.

Full explanation →
161
MCQhard

Your organization has multiple GitHub repositories that use shared workflows. You want to centrally manage these workflows and ensure they are always up to date. What is the recommended approach?

A.Create a central repository with reusable workflows and reference them using the 'uses' keyword in your workflows.
B.Use the GitHub API to push workflow files to each repository on a schedule.
C.Download the workflows from a central blob storage and include them as inline scripts.
D.Store the workflows in a separate repository and use Git submodules to include them.
AnswerA

Reusable workflows are the official pattern.

Why this answer

Option B is correct because GitHub Actions allows you to reference workflows from other repositories using the 'uses' keyword with a path to a workflow file in another repo. Option A is wrong because submodules are for code, not workflows. Option C is wrong because you cannot directly reference a zip file.

Option D is wrong because there is no 'workflow templates' API in GitHub.

Full explanation →
162
MCQhard

Your company is deploying Azure DevOps pipelines for a critical financial application. Compliance requires that all pipeline runs are immutable and auditable. You must ensure that once a pipeline completes, its logs, artifacts, and test results cannot be modified or deleted by anyone, including administrators, for 7 years. You also need to prevent any pipeline runs from being deleted. Azure DevOps retention policies are currently set to 30 days. What should you do?

A.Use Azure Policy to enforce immutability on the storage account backing Azure DevOps artifacts, and set pipeline retention policy to 9999 days.
B.Assign the 'Project Collection Administrators' group a custom role that denies delete permissions.
C.Set branch policies to require approval before any deletion.
D.Configure Azure DevOps to export all logs to Azure Log Analytics with a 7-year retention.
AnswerA

Azure Policy enforces immutability; long retention prevents deletion.

Why this answer

Option C is correct because Azure Policy can enforce retention locks on storage containers used by Azure DevOps pipelines, making logs immutable. Additionally, setting the retention policy to 'maximum' (9999 days) ensures runs are not deleted. Option A is wrong because export to Log Analytics doesn't prevent deletion.

Option B is wrong because branch policies don't affect retention. Option D is wrong because manual deletion is still possible with short retention.

Full explanation →
163
MCQhard

You are debugging a recent issue introduced in the main branch. Based on the exhibit, which command would you run to revert the 'Fix login bug' commit while preserving the merge commit?

A.git revert -m 1 HEAD
B.git reset --hard HEAD~1
C.git revert HEAD
D.git revert c3a2b1e -m 2
AnswerC

Creates a new commit reverting the top commit.

Why this answer

Option C is correct because `git revert HEAD` creates a new commit that undoes the changes introduced by the most recent commit (the merge commit), without altering the existing commit history. This preserves the merge commit and its parent relationships, which is essential when reverting a merge commit while keeping the branch structure intact.

Exam trap

The trap here is that candidates often confuse `git revert` with `git reset`, assuming a revert removes history, or they incorrectly apply the `-m` flag without understanding that the default behavior already handles merge commits by reverting the entire merge's changes.

How to eliminate wrong answers

Option A is wrong because `git revert -m 1 HEAD` reverts the merge commit but keeps the changes from the first parent (the main branch), effectively undoing the entire merge and discarding the 'Fix login bug' commit's changes from the merged branch, which is not a simple revert of the commit itself. Option B is wrong because `git reset --hard HEAD~1` removes the merge commit and all its changes from history, which is destructive and does not preserve the merge commit as required. Option D is wrong because `git revert c3a2b1e -m 2` reverts the merge commit while keeping the changes from the second parent (the feature branch), which would undo the merge but retain the 'Fix login bug' commit's changes, contrary to the goal of reverting that specific commit.

Full explanation →
164
MCQmedium

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

A.Use the 'canary' strategy with manual intervention
B.Use the 'rolling' strategy and configure 'on:failure: always'
C.Use the 'blueGreen' strategy and configure automatic swap
D.Use the 'runOnce' strategy with a rollback task
AnswerB

Why this answer

Option B is correct because the 'rolling' strategy in Azure DevOps deployment jobs supports an 'on:failure' hook that can be configured to run actions like 'always', which can trigger a rollback to the previous successful version. This ensures automatic redeployment of the last stable release upon failure, meeting the requirement without manual intervention.

Exam trap

The trap here is that candidates often confuse the 'rolling' strategy's 'on:failure' hook with the 'blueGreen' strategy's swap capability, assuming automatic swap implies rollback, but swap only shifts traffic and does not revert the deployment on failure.

Why the other options are wrong

A

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

C

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

D

runOnce does not support automatic rollback; you would need custom scripting.

Full explanation →
165
MCQmedium

You are reviewing a webhook payload from Azure Repos. The payload indicates that a new branch named 'feature-123' was created. Which event type triggered this webhook?

A.A new branch creation.
B.A push to an existing branch.
C.A branch deletion.
D.A pull request update.
AnswerA

All zeros in 'before' indicates a new branch.

Why this answer

The webhook payload explicitly indicates that a new branch named 'feature-123' was created. In Azure Repos, the event type that corresponds to this action is 'New branch creation' (also known as 'Push' with a new ref). This event fires when a new branch reference is pushed to the remote repository, which is exactly what happened here.

Exam trap

The trap here is that candidates often confuse the 'Push' event type with 'New branch creation', not realizing that Azure Repos uses the same 'Push' event for both, but the payload's 'refUpdates' array contains a 'created' flag that distinguishes them.

How to eliminate wrong answers

Option B is wrong because a push to an existing branch would trigger a 'Push' event with an update to an existing ref, not a new ref creation. Option C is wrong because a branch deletion would trigger a 'Delete' event, which removes a ref entirely. Option D is wrong because a pull request update triggers a 'Pull request updated' event, which is unrelated to branch creation.

Full explanation →
166
Multi-Selectmedium

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

Select 2 answers
A.Configure gates on the staging environment to check health metrics.
B.Add a manual intervention task in the pipeline.
C.Set a post-deployment approval on the staging stage.
D.Use a pull request to validate the deployment.
E.Run a load test as part of the pipeline.
AnswersA, C

Why this answer

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

Exam trap

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

Why the other options are wrong

B

Manual intervention tasks are deprecated; use approvals instead.

D

Pull requests validate code changes, not deployments.

E

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

Full explanation →
167
MCQeasy

You are designing a build pipeline for a Python application that uses multiple third-party packages from the public PyPI repository. Your organization has security policies that require all build dependencies to be scanned for known vulnerabilities before being used. The build pipeline runs on Microsoft-hosted agents. You need to integrate vulnerability scanning into the build pipeline with minimal overhead and without storing credentials in the pipeline. What should you do?

A.Configure a service connection to a private vulnerability database and use a script to scan.
B.Write a custom script that uses pip audit to scan the requirements.txt file.
C.Use a pre-build validation step in the pipeline to manually review dependencies.
D.Add a dependency scanning task from the Azure DevOps marketplace to the build pipeline.
AnswerD

Marketplace tasks are easy to add and often support credential-free scanning for public packages.

Why this answer

Option A is correct: Dependency scanning task (e.g., WhiteSource Bolt or GitHub Dependabot) integrates easily without credentials. Option B is incorrect because storing credentials in variables is not recommended. Option C is incorrect because custom scripts require maintenance and may not integrate well.

Option D is incorrect because manual scanning defeats automation.

Full explanation →
168
MCQhard

You are designing a release pipeline for a critical business application that must adhere to strict compliance requirements. The pipeline must deploy to multiple environments (dev, test, staging, prod) with manual approvals required for staging and prod. Additionally, the pipeline must automatically run integration tests after deployment to dev and test, and only proceed to the next environment if tests pass. You need to implement this using Azure Pipelines YAML. What should you do?

A.Use a single multi-stage YAML pipeline with a stage per environment. Add approvals on staging and prod stages. Ensure stages run sequentially by default.
B.Create separate YAML pipelines for each environment and use pipeline completion triggers to chain them together.
C.Use a classic release pipeline with environments and pre-deployment approvals on staging and prod. Add a post-deployment task to run integration tests in dev and test environments.
D.Use a single multi-stage YAML pipeline with a stage per environment. Add a job after deployment to dev that runs integration tests, and use a condition on the next stage to run only if tests passed. Add approvals on staging and prod stages.
AnswerD

Stages with conditions and approvals fulfill all requirements.

Why this answer

Option C is correct because it uses stages with dependencies and conditions to run tests after deployment, and approvals on staging and prod. Option A is incorrect because release pipelines with environments can't easily run tests conditionally. Option B is incorrect because separate pipelines lack coordination.

Option D is incorrect because stages run sequentially by default but approvals are per environment, not stage.

Full explanation →
169
Multi-Selecthard

Which THREE practices are recommended for managing secrets in a Git repository? (Select THREE.)

Select 3 answers
A.Use tools like GitLeaks to scan for accidentally committed secrets
B.Store secrets in a separate encrypted file committed to the repository
C.Use GitHub Secrets or Azure Pipelines secret variables
D.Use Azure Key Vault to store and retrieve secrets at build/release time
E.Commit a .env file with default values to the repository
AnswersA, C, D

Scanning helps detect leaks early.

Why this answer

Options B, D, and E are correct. Using Azure Key Vault (B), GitHub Secrets (D), and scanning with tools (E) are best practices. Option A is wrong because storing encrypted secrets in Git is risky.

Option C is wrong because committing .env files is dangerous.

Full explanation →
170
Multi-Selecteasy

Your team uses Git for source control. You want to maintain a clean commit history on the main branch by avoiding merge commits. Which TWO merge strategies in a pull request achieve this?

Select 2 answers
A.Rebase merge
B.Merge commit
C.Squash merge
D.Three-way merge
E.Fast-forward merge
AnswersA, C

Rebase merge applies commits linearly without a merge commit.

Why this answer

A rebase merge (option A) rewrites the commit history of the feature branch onto the tip of the target branch, creating a linear sequence of commits without any merge commits. This maintains a clean, linear history on the main branch. A squash merge (option C) combines all commits from the feature branch into a single new commit on the target branch, also avoiding merge commits and keeping the history clean.

Exam trap

The trap here is that candidates often confuse 'fast-forward merge' with a clean history strategy, but fast-forward merges only avoid merge commits when the branches haven't diverged; they do not rewrite or consolidate commits, so they fail to maintain a clean history in the general case.

Full explanation →
171
MCQhard

An Azure Policy is defined as shown in the exhibit. You attempt to create a storage account with HTTPS traffic only set to false. What will happen?

A.The policy will only apply if the storage account is in a specific resource group
B.The storage account will be created but HTTPS will be enforced
C.The storage account will be created and an audit event will be logged
D.The creation will be denied with an error message
AnswerD

The policy denies creation when the condition is met.

Why this answer

The Azure Policy in the exhibit uses a 'Deny' effect for the condition that storage accounts must have HTTPS traffic enabled. When you attempt to create a storage account with 'HTTPS traffic only' set to false, the policy evaluation detects a non-compliant resource and denies the creation request, returning an error message. This is because the 'Deny' effect blocks the resource deployment entirely, preventing the non-compliant configuration from being provisioned.

Exam trap

The trap here is that candidates often confuse the 'Deny' effect with 'Audit' or 'Modify', mistakenly thinking the policy will either log the violation or auto-correct the setting, rather than understanding that 'Deny' blocks the operation entirely.

How to eliminate wrong answers

Option A is wrong because the policy definition does not include a scope restriction to a specific resource group; Azure Policies apply at the assigned scope (e.g., subscription or management group) unless a parameter or condition explicitly filters by resource group. Option B is wrong because the 'Deny' effect prevents the storage account from being created at all; it does not allow creation and then enforce HTTPS after the fact—enforcement would require a 'Modify' or 'DeployIfNotExists' effect. Option C is wrong because the 'Deny' effect blocks creation and logs a denial event, but it does not allow creation with an audit event; an 'Audit' effect would log the non-compliance without blocking.

Full explanation →
172
Multi-Selecthard

Your organization uses GitHub Actions for CI/CD. You need to enforce branch protection rules and ensure that all pull requests to the main branch require a successful status check from a specific workflow. Which TWO actions should you take? (Choose two.)

Select 2 answers
A.Configure a GitHub environment with required reviewers.
B.Add a workflow to the repository that runs tests and reports a conclusion status.
C.Use a repository ruleset to require status checks.
D.Set up branch policies in Azure Repos for the main branch.
E.In the repository settings, enable 'Require status checks to pass before merging' under branch protection rules.
AnswersB, E

The workflow provides the status check that can be required.

Why this answer

Option A is correct: Add a workflow that runs tests and reports a status. Option D is correct: Configure branch protection rules to require status checks. Option B is incorrect: GitHub environments are for deployment protection, not branch protection.

Option C is incorrect: Branch policies are an Azure Repos feature, not GitHub. Option E is incorrect: Repository rulesets are an alternative but 'require status checks' is a branch protection setting.

Full explanation →
173
MCQeasy

You need to ensure that only specific branches can trigger a release to production in Azure Pipelines. What should you configure?

A.Add an approval gate that requires a manager to approve the release.
B.Add a deployment gate that checks the source branch.
C.Add a branch filter to the release pipeline's artifact trigger.
D.Add a branch filter to the build pipeline trigger.
AnswerC

The artifact trigger's branch filter controls which builds trigger a release.

Why this answer

Option C is correct because branch filters in the release trigger control which branches can start a release. Option A is wrong because it restricts build triggers, not releases. Option B is wrong because deployment gates do not filter branches.

Option D is wrong because approval gates are for manual approval, not branch restriction.

Full explanation →
174
MCQmedium

Your team uses Azure DevOps and wants to enforce branch protection policies for all repositories in a GitHub Advanced Security-enabled organization. Which approach should you use to ensure that pull requests require a successful status check from a required workflow?

A.Use GitHub Actions secrets to store the required status check name.
B.Define a repository rule in GitHub that requires a successful status check from a required workflow.
C.Create a branch protection rule in each repository's settings.
D.Configure branch policies in Azure DevOps project settings.
AnswerB

GitHub repository rules can enforce branch protection policies across repositories in an organization.

Why this answer

Option C is correct because GitHub repository rules allow you to define branch protection policies that require status checks, including required workflows. Option A is wrong because Azure DevOps branch policies are for Azure Repos, not GitHub. Option B is wrong because GitHub Actions secrets are for storing sensitive data, not for branch policies.

Option D is wrong because branch protection rules in GitHub are per-repository, but repository rules allow organization-wide enforcement.

Full explanation →
175
MCQhard

Your team uses GitHub and wants to automatically label pull requests based on the content of the changes (e.g., 'frontend' for changes in /frontend folder, 'backend' for /backend). Which approach should you use?

A.Use branch protection rules to require specific labels based on branch name patterns.
B.Set up a webhook that triggers an Azure Function to parse the pull request diff and add labels.
C.Create a GitHub Actions workflow that runs on pull_request events and uses an action like 'actions/labeler' to add labels based on path patterns.
D.Use a CODEOWNERS file to assign labels based on file paths.
AnswerC

The labeler action is designed for this purpose and is easy to configure.

Why this answer

Option C is correct because GitHub Actions provides a native, event-driven way to automate labeling based on pull request changes. The 'actions/labeler' action specifically inspects file paths in the diff and applies labels defined in a configuration file, making it the simplest and most maintainable solution for path-based labeling.

Exam trap

The trap here is confusing CODEOWNERS (which assigns reviewers) with label automation, leading candidates to pick option D despite it having no labeling functionality.

How to eliminate wrong answers

Option A is wrong because branch protection rules enforce policies on merging (e.g., required status checks, number of reviewers) but cannot automatically add labels based on branch name patterns. Option B is wrong because while a webhook plus Azure Function could technically work, it introduces unnecessary complexity and external dependencies when a built-in GitHub Actions workflow is available and simpler. Option D is wrong because CODEOWNERS files define who is responsible for code reviews based on file paths, not for automatically applying labels to pull requests.

Full explanation →
176
Multi-Selecthard

Which TWO actions should you take to ensure that Azure Pipelines artifacts are securely stored and access is audited?

Select 2 answers
A.Configure the storage account firewall to only allow access from Azure Pipelines IP ranges
B.Use Azure Policy to enforce that artifacts are only deployed to production storage accounts
C.Enable Azure Artifacts retention policies to automatically delete old artifact versions
D.Enable customer-managed keys (CMK) for artifact encryption
E.Configure audit logging for artifact downloads via Azure DevOps audit logs
AnswersC, E

Retention policies minimize the risk of old artifacts being compromised.

Why this answer

Option B and Option E are correct. Option B (Enable Azure Artifacts retention policies) ensures old artifacts are removed, reducing attack surface. Option E (Configure audit logging for artifact downloads) provides audit trail.

Option A is wrong because Azure Pipelines does not support storage account firewall for artifacts. Option C is wrong because artifacts are already encrypted at rest. Option D is wrong because artifacts are not deployed to production via storage accounts.

Full explanation →
177
MCQmedium

Your team uses Azure Pipelines to deploy a web app to Azure App Service. You need to ensure that secrets (e.g., connection strings) are not exposed in the pipeline logs. What is the recommended approach?

A.Remove all logging from the pipeline.
B.Use secret pipeline variables and reference them in the pipeline.
C.Store secrets in Azure Key Vault and retrieve them in the pipeline, then log them for debugging.
D.Store secrets as environment variables in the pipeline.
AnswerB

Secret variables are masked in logs.

Why this answer

Option B is correct because Azure Pipelines allows you to mark variables as 'secret' to mask them in logs. Option A is incorrect because environment variables can still be logged. Option C is incorrect because Key Vault is for storing secrets, but if logged they can be exposed.

Option D is incorrect because removing logging is not practical.

Full explanation →
178
MCQeasy

Your team is using YAML pipelines in Azure DevOps and wants to ensure that a specific stage runs only for changes to the 'main' branch. Which condition should you add to the stage?

A.condition: ne(variables['Build.SourceBranch'], 'refs/heads/main')
B.condition: contains(variables['Build.SourceBranch'], 'main')
C.condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
D.condition: eq(variables['Build.SourceBranch'], 'refs/heads/main')
AnswerD

This correctly ensures the stage runs only when the source branch is main.

Why this answer

Option B is correct because the 'condition' property with 'eq(variables['Build.SourceBranch'], 'refs/heads/main')' ensures the stage runs only for the main branch. Option A is wrong because 'and(succeeded(), eq(...))' would also require previous stages to succeed, which is not specified. Option C is wrong because 'ne(variables['Build.SourceBranch'], 'refs/heads/main')' would run for all branches except main.

Option D is wrong because 'contains(variables['Build.SourceBranch'], 'main')' could match branch names containing 'main' like 'feature/maintenance'.

Full explanation →
179
Multi-Selectmedium

Your organization is implementing a security compliance plan for Azure DevOps. Which TWO actions help enforce the principle of least privilege?

Select 2 answers
A.Allow all team members to edit security permissions
B.Use Azure DevOps security groups to grant minimal permissions
C.Use built-in roles without customizing
D.Restrict who can create new agent pools to a small admin team
E.Grant Project Collection Administrators group to all developers
AnswersB, D

This follows least privilege by granting only necessary permissions.

Why this answer

Options A and C are correct. Option A limits access to only what is needed. Option C restricts administrative roles.

Option B is wrong because it grants more permissions. Option D is wrong because it broadens access. Option E is wrong because it does not enforce least privilege.

Full explanation →
180
MCQeasy

Your build pipeline includes a task that runs unit tests. You want to ensure that if any test fails, the pipeline stops immediately and does not proceed to the next tasks. What should you configure in the pipeline?

A.Set the 'Continue on error' option to false for the test task.
B.Add a custom condition to the test task to only run if previous tasks succeeded.
C.Set the 'Always run' option for the test task.
D.Ensure the task control option 'Run this task' is set to 'Only when all previous tasks have succeeded'.
AnswerD

This setting prevents the pipeline from running subsequent tasks if a previous task fails.

Why this answer

Setting the task control option 'Run this task' to 'Only when all previous tasks have succeeded' ensures that the pipeline stops on failure. Option A is wrong because 'Continue on error' allows the pipeline to continue even if the task fails. Option C is wrong because 'Always run' runs the task regardless of previous failures.

Option D is wrong because 'Custom conditions' can be used but are not the simplest way to stop on failure.

Full explanation →
181
MCQmedium

You are configuring a release pipeline that deploys to multiple environments. You want to automate the deployment to the staging environment only if the build succeeds, and then require manual approval before deploying to production. Which strategy should you use?

A.Define an environment with approvals required for the production stage.
B.Use deployment gates in the production stage to check for manual intervention.
C.Use a classic release pipeline with pre-deployment approvals.
D.Configure a branch policy on the main branch to require approval for pull requests.
AnswerA

Environment approvals provide manual sign-off before deployment.

Why this answer

Option B is correct because environment approvals in a multistage YAML pipeline allow you to specify approvals before a stage runs. Option A is wrong because gates are for health checks, not approvals. Option C is wrong because release pipelines are legacy and not recommended for new projects.

Option D is wrong because branch policies control code quality, not deployment approvals.

Full explanation →
182
Multi-Selecthard

Which TWO actions should you take to ensure that Azure Pipelines artifacts are scanned for vulnerabilities before production deployment? (Choose two.)

Select 2 answers
A.Run dependency scanning on the artifact manifest
B.Sign the artifacts with a code signing certificate
C.Use Microsoft Defender for Cloud to scan the artifact during the pipeline
D.Scan the infrastructure as code templates
E.Run static code analysis on the source code
AnswersA, C

Dependency scanning detects known vulnerabilities in dependencies.

Why this answer

Options B and C are correct. Option B: Dependency scanning identifies vulnerabilities in dependencies. Option C: Incorporating Microsoft Defender for Cloud scanning into the pipeline scans container images and other artifacts.

Option A is wrong because code signing ensures integrity but not vulnerability scanning. Option D is wrong because static analysis finds code issues, not artifacts. Option E is wrong because infrastructure scanning is for IaC, not artifacts.

Full explanation →
183
MCQmedium

Your team manages a large monorepo in Azure Repos containing multiple microservices. The repository has grown to over 10,000 files and 500 MB. Developers report that cloning and fetching operations are slow, often taking more than 10 minutes. Additionally, the CI pipeline triggers on every push to any branch, causing long queue times. You need to improve the developer experience and CI efficiency without splitting the repository. What should you do?

A.Configure shallow clone (depth=1) for all operations and disable CI triggers on feature branches.
B.Break the monorepo into multiple smaller repositories and use Git submodules to manage dependencies.
C.Implement Git Virtual File System (GVFS) for the repository and use CI triggers only on the main branch.
D.Use Git sparse checkout to clone only the folders needed for each microservice, and configure path-based CI triggers to run only when files in specific directories change.
AnswerD

Sparse checkout reduces download size, and path-based triggers reduce unnecessary CI runs.

Why this answer

Option D is correct because Git sparse checkout allows developers to clone only the specific directories they need for their microservice, reducing the amount of data transferred and stored locally, which directly addresses the slow clone/fetch issue. Additionally, path-based CI triggers in Azure Pipelines ensure that the CI pipeline only runs when files in the relevant directories change, reducing unnecessary builds and queue times. This approach improves both developer experience and CI efficiency without splitting the monorepo.

Exam trap

The trap here is that candidates may confuse sparse checkout with shallow clone or GVFS, or incorrectly assume that disabling CI triggers on feature branches is acceptable, when the real goal is to optimize both cloning and CI triggering without breaking the monorepo structure.

How to eliminate wrong answers

Option A is wrong because while shallow clone (depth=1) reduces clone time, disabling CI triggers on feature branches would prevent developers from getting early feedback on their changes, which is a core CI practice; it does not address the root cause of slow operations for existing clones or the need for selective CI execution. Option B is wrong because the question explicitly states 'without splitting the repository,' and using Git submodules would introduce additional complexity and management overhead, potentially breaking the monorepo structure. Option C is wrong because Git Virtual File System (GVFS) is designed for extremely large repositories (e.g., >10 GB) and is specific to Windows and Visual Studio; it is not a standard Git feature and would not be appropriate for a 500 MB repo, nor does it address path-based CI triggers.

Full explanation →
184
MCQhard

Your release pipeline uses deployment groups to deploy to Windows servers. You need to securely pass credentials to a script that runs on target machines. What is the recommended approach?

A.Hardcode credentials in the script and encrypt the script file
B.Store credentials as pipeline variables and reference them
C.Use Azure Key Vault task to fetch secrets during deployment
D.Use environment variables on the target machines
AnswerC

Key Vault securely stores and injects secrets.

Why this answer

Option A is correct because Azure Key Vault integration provides secure secret storage and retrieval. Option B is wrong because storing in pipeline variables exposes secrets. Option C is wrong because environment variables can be logged.

Option D is wrong because plaintext in scripts is insecure.

Full explanation →
185
MCQhard

Your Azure DevOps project uses a self-hosted agent pool. Users report that builds are randomly failing with a 'disk full' error. The agents have 50 GB of disk space. What is the most effective way to mitigate this issue?

A.Add more agents to the pool
B.Use the 'Clean all build directories' option in the agent configuration
C.Enable the 'Clean after build' option on the build pipeline
D.Set 'Maximum number of parallel jobs' to 1
AnswerC

This removes workspace artifacts after each build, freeing space.

Why this answer

Option C is correct because enabling 'Clean after build' ensures workspace cleanup after each run. Option A is wrong because adding more agents doesn't free disk space. Option B is wrong as it only prevents concurrent builds, but the issue is disk space, not concurrency.

Option D is wrong because it cleans only at the beginning, not after.

Full explanation →
186
MCQmedium

Your team uses GitHub and wants to automatically close stale branches that have not been updated in 90 days. Which GitHub feature should you configure?

A.Create a scheduled GitHub Actions workflow that deletes branches older than 90 days
B.Auto-merge feature
C.Stale bot (GitHub Actions)
D.GitHub Discussions
AnswerA

Automates branch cleanup.

Why this answer

A is correct because GitHub Actions can be scheduled using cron syntax to run a workflow that identifies branches with no commits in the last 90 days and deletes them via the GitHub API. This gives you full control over the deletion logic, logging, and notifications, unlike a simple bot. The workflow can use actions like `actions/github-script` or `stale` to enumerate branches and filter by `committer.date`.

Exam trap

The trap here is that candidates confuse the Stale bot (which handles issues/PRs) with branch management, assuming it can also delete branches, but it has no branch deletion capability.

How to eliminate wrong answers

Option B is wrong because the auto-merge feature automatically merges a pull request when required checks pass, but it does not delete stale branches. Option C is wrong because the Stale bot (GitHub Actions) is designed to mark issues and pull requests as stale and close them, not to delete branches. Option D is wrong because GitHub Discussions is a forum for conversations and does not provide any branch management or deletion capabilities.

Full explanation →
187
MCQeasy

You are setting up a release pipeline that deploys to multiple environments (dev, test, prod) sequentially. Each environment requires approval before deployment. What is the best way to implement this in Azure Pipelines?

A.Define pipeline stages with environment resources and pre-deployment approvals.
B.Use environment resources with 'auto' trigger and no approvals.
C.Use classic release pipelines with approval gates per environment.
D.Use a custom PowerShell script to pause and prompt for approval.
AnswerA

YAML pipelines support environments with approvals directly.

Why this answer

Option C is correct because environments in Azure Pipelines support approvals and gates, and can be used in a multi-stage pipeline with manual triggers. Option A is outdated; releases are the classic approach. Option B is insufficient for approvals.

Option D requires custom scripting.

Full explanation →
188
MCQmedium

Your organization requires compliance with SOC 2 and needs to audit all changes to Azure Pipelines. What should you enable?

A.Azure Policy
B.Microsoft Purview
C.Azure Blueprints
D.Azure DevOps audit logs
AnswerD

Audit logs track changes to pipelines and other resources.

Why this answer

Option A is correct because Azure DevOps audit logs capture pipeline changes and can be exported for compliance. Option B is wrong because Azure Policy enforces governance, not auditing. Option C is wrong because Microsoft Purview is for data governance.

Option D is wrong because Azure Blueprints are deprecated.

Full explanation →
189
MCQhard

Your team uses GitHub Actions for CI/CD and must ensure that only approved contributors can merge code to the main branch. You need to enforce a policy where every pull request must be reviewed by at least two members of the security team. Which branch protection rule should you configure?

A.Require pull request reviews before merging
B.Require status checks to pass before merging
C.Dismiss stale pull request approvals
D.Require a minimum number of reviewers
AnswerD

This enforces at least two reviewers from the security team.

Why this answer

Option C is correct because 'Require a minimum number of reviewers' enforces that at least two reviewers approve before merging. Option A is wrong because 'Require pull request reviews before merging' alone doesn't specify the number of reviewers. Option B is wrong because 'Dismiss stale pull request approvals' deals with re-review when new commits are pushed.

Option D is wrong because 'Require status checks' requires CI checks, not reviews.

Full explanation →
190
MCQmedium

Your team uses Microsoft-hosted agents for builds. Recently, builds are taking longer to start. What is the best way to reduce queue times?

A.Increase the number of parallel jobs in the organization.
B.Use more pipeline triggers.
C.Provision self-hosted agents.
D.Reduce the number of parallel jobs.
AnswerC

Self-hosted agents are dedicated and reduce queue times.

Why this answer

Option A is correct because using self-hosted agents provides dedicated capacity. Option B is wrong because reducing parallel jobs doesn't help queue time. Option C is wrong because it increases parallelism but doesn't reduce queue time per job.

Option D is wrong because more jobs would increase queue time.

Full explanation →
191
MCQmedium

Your organization uses GitHub Actions for CI/CD. You want to enforce that all workflows pass required checks before a pull request can be merged. The repository is in an organization that uses GitHub Enterprise Cloud. What should you configure?

A.Add a branch protection rule that requires status checks to pass.
B.Enable 'Require approval for all workflows' in the organization settings.
C.Set the workflow to be required in the 'Require status check' settings of each pull request.
D.Create a repository ruleset that requires linear history.
AnswerA

Branch protection rules can enforce that all required checks pass before merging.

Why this answer

Branch protection rules can require status checks to pass before merging. In GitHub, you can set up a branch protection rule that requires status checks, including GitHub Actions workflows. Option A is correct.

Option B is wrong because rulesets are for repository rules, not for requiring checks. Option C is wrong because the required status check can be set at the branch level, not per workflow file. Option D is wrong because GitHub Actions does not have a built-in 'Approval' feature for workflow runs; approval is for deployments.

Full explanation →
192
Multi-Selecthard

Which THREE are valid security best practices for Azure Pipelines? (Choose three.)

Select 3 answers
A.Restrict agent pool permissions to only necessary users
B.Use Microsoft Entra ID to control access to pipelines
C.Store secrets as plain text in YAML files
D.Use variable groups with Azure Key Vault integration for secrets
E.Run build agents on domain controllers
AnswersA, B, D

Least privilege principle applies to agent pools.

Why this answer

Option A is correct because restricting agent pool permissions to only necessary users follows the principle of least privilege, reducing the attack surface by ensuring only authorized personnel can register, manage, or use build agents. This prevents unauthorized access that could lead to code injection or credential theft.

Exam trap

The trap here is that candidates may think storing secrets in YAML files is acceptable if the repository is private, but Azure Pipelines explicitly warns against this because secrets can be exposed in pipeline logs, build artifacts, or through source control history.

Full explanation →
193
MCQhard

Your Azure DevOps pipeline deploys a microservice to a Kubernetes cluster using Helm. The Helm chart requires a values file that contains environment-specific configurations. You want to store the values file securely and use it during deployment. What is the recommended approach?

A.Store the values in a variable group and map them to Helm values.
B.Store the values file in Azure Key Vault and use the HelmDeploy task's 'overrideValues' parameter to set values.
C.Store the values file as a secure file in Azure Pipelines library.
D.Store the values file in a separate Git repository and clone it during the pipeline.
AnswerC

Secure files are encrypted and can be downloaded only during the pipeline run.

Why this answer

Option C is correct because Azure Key Vault can securely store secrets and configuration files, and the HelmDeploy task can reference them. Option A is incorrect because storing values files in a separate branch is not secure. Option B is incorrect because checking secrets into the repo is a security risk.

Option D is incorrect because variable groups are for simple key-value pairs, not files.

Full explanation →
194
MCQeasy

You have an Azure DevOps pipeline that deploys to multiple environments. You need to ensure that approvals are required before production deployment. Which pipeline configuration should you use?

A.Set the pipeline trigger to 'Manual' only
B.Add a 'Manual Intervention' task in the pipeline
C.Configure branch policies on the main branch
D.Define an environment with required approvers for the production stage
AnswerD

Environment approvals require explicit approval before deployment.

Why this answer

Option C is correct because environment-level approvals gate the deployment. Option A is wrong because branch policies do not control approvals. Option B is wrong because stage-level approvals can be used but environment approvals are more granular.

Option D is wrong because manual triggers do not enforce approvals.

Full explanation →
195
MCQhard

Your company uses Azure DevOps and must comply with SOC 2. The auditor requires proof that all production deployments went through a change management process with approval. What should you implement?

A.Use branch policies to require pull request approvals
B.Set pipeline retention policies to keep deployment records
C.Enable audit logging for all pipelines
D.Configure release approval gates in Azure Pipelines
AnswerD

Approval gates enforce a formal approval step before deployment.

Why this answer

Option B is correct because release approval gates provide a formal approval process before deployment. Option A is wrong because audit logs record events but don't enforce approval. Option C is wrong because branch policies control code changes, not deployments.

Option D is wrong because pipeline retention policies control artifact storage.

Full explanation →
196
Multi-Selecteasy

Which TWO strategies can you use to manage secrets in Azure Pipelines securely?

Select 2 answers
A.Use a variable group linked to Azure Key Vault.
B.Store secrets directly in the YAML pipeline file.
C.Use the 'secret' variable type in the pipeline UI.
D.Use environment variables in the build agent.
E.Print the secret in a script to verify it is correct.
AnswersA, C

Key Vault provides secure secret storage.

Why this answer

Options A and C are correct. Variable groups can be linked to Azure Key Vault to fetch secrets, and you can mark variables as secret in the pipeline UI. Option B is wrong because storing secrets in YAML files exposes them in source control.

Option D is wrong because logging secrets is not secure. Option E is wrong because environment variables are not inherently secure.

Full explanation →
197
MCQeasy

Your organization uses Microsoft Entra ID. You want to ensure that only users from specific countries can access Azure DevOps. Which security feature should you configure?

A.Microsoft Entra ID Conditional Access policies
B.Azure Network Security Group (NSG) rules
C.Azure DevOps security groups with allowed IP ranges
D.Microsoft Intune compliance policies
AnswerA

Conditional Access can restrict access based on location.

Why this answer

Option D is correct because Conditional Access policies in Microsoft Entra ID can restrict access based on location. Option A is wrong because Azure DevOps permissions are not geo-aware. Option B is wrong because network security groups are for network traffic, not user access.

Option C is wrong because Microsoft Intune manages devices, not user location access.

Full explanation →
198
MCQeasy

Your team uses Azure Test Plans. You need to ensure that testers can easily see which test cases are blocked by a known bug. What should you do?

A.Configure the test plan to show only failed tests.
B.Create a test suite for each bug.
C.Link test cases to the bug and create a query for linked items.
D.Copy the test case and mark it as blocked.
AnswerC

Linking provides traceability.

Why this answer

Option C is correct because Azure Test Plans allows test cases to be linked directly to bugs via work item linking. By creating a query for linked items (e.g., a shared query that returns all test cases linked to a specific bug), testers can instantly see which test cases are blocked by that known bug. This provides a dynamic, filterable view without duplicating or reorganizing test artifacts.

Exam trap

The trap here is that candidates often confuse 'marking a test as blocked' (a manual status change) with the proper traceability approach of linking work items, leading them to choose Option D or B instead of leveraging Azure DevOps' built-in query and linking capabilities.

How to eliminate wrong answers

Option A is wrong because configuring the test plan to show only failed tests does not indicate which failures are caused by a known bug; it simply filters out passed tests, leaving all failures regardless of root cause. Option B is wrong because creating a test suite for each bug would require manual duplication and maintenance of test cases, leading to redundancy and confusion when bugs are fixed or closed. Option D is wrong because copying a test case and marking it as blocked creates an unnecessary duplicate that must be manually tracked and updated, breaking the traceability between the original test case and the bug.

Full explanation →
199
MCQeasy

You have a pipeline that builds a Docker image and pushes it to Azure Container Registry. You need to ensure that only the latest successful build image is tagged as 'latest'. Which tagging strategy should you use?

A.Use a conditional step that runs only when the build succeeds to tag the image as 'latest'
B.Use the build ID as the tag and manually update 'latest'
C.Use the Git commit hash as the tag and push 'latest' separately
D.Always tag the image as 'latest' regardless of build status
AnswerA

Conditional tagging ensures only successful builds are tagged.

Why this answer

Option A is correct because tagging only on successful builds ensures 'latest' reflects the last successful image. Option B is wrong because tagging all images with 'latest' would overwrite even failed builds. Option C is wrong because it does not ensure success.

Option D is wrong because it tags all images, not just successful ones.

Full explanation →
200
Multi-Selecthard

A company uses Azure Monitor and Application Insights to monitor a microservices application deployed on Azure Kubernetes Service (AKS). The development team wants to implement distributed tracing to correlate requests across services. They currently have Application Insights SDKs instrumented in each service. Which TWO configurations are required to enable end-to-end distributed tracing?

Select 2 answers
A.Enable the Live Metrics Stream feature in Application Insights.
B.Ensure all services use the same Application Insights instrumentation key or connection string.
C.Configure adaptive sampling in the Application Insights SDK.
D.Ensure the SDKs are configured to propagate correlation headers (e.g., W3C Trace-Context).
E.Enable Application Map in the Azure portal for each service.
AnswersB, D

Same key allows correlation across services.

Why this answer

Option B is correct because all services must share the same Application Insights instrumentation key or connection string to ensure that telemetry from different microservices is correlated into a single application map and trace. Without a common instrumentation key, the distributed trace data would be siloed across separate Application Insights resources, preventing end-to-end correlation.

Exam trap

The trap here is that candidates often confuse enabling Application Map (a visualization) with the actual configuration needed for correlation, or they think adaptive sampling is required for tracing, when in fact the key requirements are a shared instrumentation key and header propagation.

Full explanation →
201
Multi-Selectmedium

Which TWO actions should you take to protect sensitive information (e.g., API keys, passwords) in Azure Pipelines? (Choose two.)

Select 2 answers
A.Store secrets in environment variables on the agent machine.
B.Define secrets as pipeline secret variables and reference them as $(secretName).
C.Store secrets in a YAML file and include the file in the repository.
D.Use plain text variables in the pipeline and mask them using the 'Logging Command' feature.
E.Use Azure Key Vault to store secrets and reference them via variable groups linked to Key Vault.
AnswersB, E

Secret variables are encrypted and masked in logs.

Why this answer

Options B and D are correct. Option B: Using Azure Key Vault to store secrets and linking them to pipeline variables ensures secure access. Option D: Using secret variables prevents exposure in logs.

Option A is wrong because storing secrets in YAML files is insecure. Option C is wrong because using plain text variables exposes them. Option E is wrong because using environment variables in the agent is not secure as they can be read by other processes.

Full explanation →
202
Multi-Selecteasy

Which TWO are valid ways to trigger a pipeline in Azure Pipelines? (Choose two.)

Select 2 answers
A.Schedule trigger
B.Pull request (PR) trigger
C.Continuous integration (CI) trigger
D.'on: push' trigger in YAML
E.Commit trigger
AnswersB, C

PR trigger runs on pull request creation or updates.

Why this answer

Options A and B are correct. A: CI trigger runs when changes are pushed to a branch. B: PR trigger runs when a pull request is created.

Option C is wrong because there is no 'on: push' in Azure Pipelines YAML; that's GitHub Actions syntax. Option D is wrong because 'commit' trigger is not a term; it's CI trigger. Option E is wrong because 'schedule' trigger is valid but it's not a basic trigger; CI and PR are the primary triggers.

Full explanation →
203
MCQhard

Your pipeline builds a .NET application and runs unit tests. You notice that the pipeline takes too long because it restores NuGet packages on every run. You want to cache the NuGet packages to speed up subsequent builds. Which task should you use?

A.NuGetCommand@2 with the restore command
B.CopyFiles@2
C.PowerShell@2 to manually download and cache
D.Cache@2 (CacheBeta)
AnswerD

Cache task caches folders like the NuGet packages directory.

Why this answer

Option C is correct because the Cache task (CacheBeta@2) is designed to cache dependencies like NuGet packages. Option A is wrong because the NuGet task has a restore command but no caching. Option B is wrong because the Copy Files task is for copying files.

Option D is wrong because the PowerShell task can be used but is not the built-in caching solution.

Full explanation →
204
MCQmedium

Your pipeline uses the DotNetCoreCLI task to build a .NET Core application. You need to ensure that the build produces a self-contained deployment (SCD) for a Linux target. Which argument should you pass to the 'arguments' input of the task?

A.--configuration Release
B.--runtime linux-x64
C.--output $(Build.ArtifactStagingDirectory)
D.--self-contained true
AnswerB

The --runtime flag, along with --self-contained true in the project file, produces a self-contained deployment for the specified runtime.

Why this answer

Option D is correct because the --runtime flag specifies the target runtime for a self-contained deployment. Option A is wrong because --configuration specifies build configuration. Option B is wrong because --output specifies output path.

Option C is wrong because --self-contained is a property in the project file, not a CLI argument.

Full explanation →
205
Multi-Selecthard

Your company uses GitHub and must comply with data residency requirements. Which THREE actions should you take to ensure data stays within a specific geographic region?

Select 3 answers
A.Use self-hosted runners in the desired region
B.Use GitHub Enterprise Cloud with data residency add-on
C.Enable GitHub Actions for all repositories
D.Enable push protection for secrets
E.Configure repository visibility and storage location in GitHub settings
AnswersA, B, E

Self-hosted runners keep data within the region.

Why this answer

Options B, C, and D are correct. Option B uses GitHub Enterprise Cloud with data residency. Option C configures the repository to a specific region.

Option D uses a region-specific runner. Option A is wrong because GitHub Actions does not restrict data storage by region. Option E is wrong because push protection does not affect data residency.

Full explanation →
206
MCQmedium

Match each Azure DevOps concept to its correct description.

A.Build pipeline
B.Release pipeline
C.Task
D.Variable
E.Trigger

Why this answer

Each concept matches a specific functionality: Build pipeline compiles code, Release pipeline deploys, Task is a single action, Variable holds values, Trigger starts pipeline.

Exam trap

Candidates may confuse Build and Release pipelines, or Task vs Variable.

Why the other options are wrong

A

Matches 'Compiles source code and runs tests'

B

Matches 'Deploys artifacts to target environments'

C

Matches 'A single action in a pipeline, such as a script or build step'

D

Matches 'A name-value pair used to store configuration or secrets'

E

Matches 'An event that starts a pipeline run'

Full explanation →
207
MCQmedium

Your release pipeline deploys to multiple Azure regions. You need to ensure that if a deployment to one region fails, the pipeline continues deploying to other regions. Which deployment strategy should you use?

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

Rolling updates instances gradually and can tolerate failures in one region.

Why this answer

A rolling deployment updates instances gradually and can continue if one region fails. Option A is wrong because blue-green would switch all traffic at once. Option B is wrong because canary targets a small subset.

Option D is wrong because immutable replaces all instances.

Full explanation →
208
MCQeasy

Your organization uses GitHub Actions for CI/CD. You need to ensure that secrets are securely passed to workflows without being exposed in logs. What should you use?

A.GitHub Secrets
B.Environment variables in the workflow YAML
C.Hardcode the secrets in the workflow file
D.Azure Key Vault with Azure DevOps encrypted variables
AnswerA

Correct: GitHub Secrets are encrypted and masked in logs.

Why this answer

Option A is correct because GitHub secrets are encrypted and automatically masked in logs. Option B is wrong because environment variables are not encrypted and may be logged. Option C is wrong because encrypted variables in Azure DevOps are not a GitHub feature.

Option D is wrong because hardcoding secrets is insecure.

Full explanation →
209
MCQmedium

Refer to the exhibit. A developer creates a pipeline with this YAML. When a commit is pushed to the 'main' branch of the repository 'MyProject/MyRepo', the pipeline does NOT trigger. Which is the most likely cause?

A.The 'checkout: internal' step should use a different syntax.
B.The 'ref' property should be set to a commit SHA, not a branch name.
C.The branch specification 'main' is case-sensitive and should be 'Main'.
D.The 'internal' repository trigger requires a pipeline trigger to be enabled in the UI.
AnswerD

For repository resource triggers to work, the 'Trigger' setting for the pipeline must be enabled, and the repository trigger must be explicitly configured. In this case, the pipeline trigger might be disabled.

Why this answer

The pipeline's own repository (self) triggers only when its own default branch receives commits. The repository resource 'internal' is configured with a trigger, but the pipeline itself may not have CI triggers enabled, or the trigger for the repository resource might be disabled by default unless explicitly enabled.

Full explanation →
210
MCQmedium

Your team uses Azure Pipelines to build a React application. The build process runs npm install, npm test, and npm run build. The build succeeds, but the application loads slowly in the browser due to large bundle sizes. What should you add to the pipeline to optimize the build?

A.Add a step to cache the node_modules folder.
B.Add a step to minify JavaScript using Terser.
C.Add a step to run Webpack bundle analyzer and implement code splitting.
D.Add a step to run additional unit tests to catch performance issues.
AnswerC

Code splitting reduces initial bundle size.

Why this answer

Option C is correct because the Webpack task can be configured to analyze bundle size and split code. Option A is wrong because caching dependencies does not reduce bundle size. Option B is wrong because minification is likely already done.

Option D is wrong because unit tests do not affect bundle size.

Full explanation →
211
MCQmedium

You have a multi-stage YAML pipeline that deploys to Azure App Service. The deployment to the production stage should only proceed if a manual approval is granted. How should you configure this?

A.Use deployment gates with Azure Monitor metrics
B.Configure branch policies on the main branch
C.Add a pipeline decorator to require sign-off
D.Add an approval check on the production environment
AnswerD

Approval checks require manual sign-off.

Why this answer

Environment approvals are the native way to require manual sign-off before deployment. Option B is wrong because deployment gates are automatic checks. Option C is wrong because branch policies restrict source branches.

Option D is wrong because pipeline decorators add steps but don't enforce approvals.

Full explanation →
212
MCQeasy

You need to automatically run a security scan on every pull request in GitHub. The scan should block the PR if critical vulnerabilities are found. Which GitHub feature should you use?

A.GitHub Code Scanning with a CodeQL workflow
B.Dependabot version updates
C.Secret scanning
D.Branch protection rules with required status checks
AnswerA

CodeQL analysis can run on PRs and report results as check runs that block merging.

Why this answer

GitHub Code Scanning with a workflow can run security scans and block PRs via check runs. Option B is wrong because Dependabot only updates dependencies. Option C is wrong because secret scanning detects secrets, not vulnerabilities.

Option D is wrong because branch protection rules enforce checks, but the scan itself is Code Scanning.

Full explanation →
213
Multi-Selecteasy

Your team wants to implement automated testing in the build pipeline. You need to ensure that tests run and results are published. Which TWO tasks should you include?

Select 2 answers
A.Publish Build Artifacts task
B.Copy Files task
C.Visual Studio Test task
D.Publish Test Results task
E.Azure PowerShell task
AnswersC, D

Runs unit tests and produces results.

Why this answer

Option A is correct because the VSTest task runs tests. Option C is correct because the Publish Test Results task publishes results. Option B is wrong because the Copy Files task copies files, not runs tests.

Option D is wrong because the Publish Build Artifacts task publishes artifacts, not test results. Option E is wrong because the Azure PowerShell task runs scripts, not tests.

Full explanation →
214
Matchingmedium

Match each Azure Repos policy to its enforcement.

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

Concepts
Matches

Ensures at least N reviewers approve

Requires PR to be associated with a work item

Requires all comments to be resolved before merge

Requires a successful pipeline run before merge

Why these pairings

Branch policies in Azure Repos to protect branches.

Full explanation →
215
Multi-Selecteasy

Which TWO triggers can be used to start a release pipeline in Azure DevOps?

Select 2 answers
A.Continuous integration trigger
B.Scheduled release trigger
C.Continuous deployment trigger
D.Pull request trigger
E.Branch policy trigger
AnswersB, C

Scheduled trigger starts a release at a specified time.

Why this answer

Options A and D are correct. Continuous deployment trigger starts a release when a build artifact is ready, and scheduled release trigger starts at a defined time. Options B and C are build triggers, not release triggers.

Option E is for build validation, not release.

Full explanation →
216
MCQhard

A team uses Terraform to manage Azure infrastructure. They want to store the Terraform state file securely and enable collaboration. What is the recommended approach?

A.Store the state file in an Azure Storage account with state locking enabled
B.Store the state file in a local folder and commit to Git
C.Store the state file in Terraform Cloud
D.Store the state file in a Git repository with manual locking
AnswerA

Azure Storage provides remote state with leasing for locking, ensuring consistency.

Why this answer

Storing the Terraform state file in an Azure Storage account with state locking enabled is the recommended approach because it provides a centralized, durable backend that supports native state locking via Azure Blob Storage leases. This prevents concurrent modifications and state corruption, enabling safe collaboration among team members. Azure Storage also offers encryption at rest and access control via RBAC, aligning with security best practices for infrastructure-as-code.

Exam trap

The trap here is that candidates often assume Terraform Cloud is always the best remote backend, but the question specifies Azure infrastructure, and the recommended approach for Azure is the native Azure Storage backend due to its tight integration, lower latency, and no additional licensing cost.

How to eliminate wrong answers

Option B is wrong because storing the state file in a local folder and committing it to Git exposes sensitive data (e.g., plaintext secrets, resource IDs) in version control and lacks state locking, leading to corruption if multiple team members run Terraform simultaneously. Option C is wrong because while Terraform Cloud is a valid remote backend, the question specifically asks for the recommended approach for Azure infrastructure, and the Azure Storage backend is the native, cost-effective, and fully integrated solution within Azure; Terraform Cloud introduces an external dependency and additional cost. Option D is wrong because storing the state file in a Git repository with manual locking does not prevent concurrent writes—Git does not provide distributed locking, and manual coordination is error-prone and unscalable, risking state conflicts.

Full explanation →
217
MCQmedium

Your Azure DevOps pipeline uses the 'DotNetCoreCLI@2' task to run unit tests. Some tests are failing intermittently. You suspect test flakiness due to race conditions. What should you do to automatically retry failed tests without rewriting the tests?

A.Use the 'VSTest@2' task with 'retryFailedTests: true' option.
B.Create a custom script that runs each test individually and retries on failure.
C.Enable 'test retry' in the pipeline settings under 'General'.
D.Wrap the test task in a 'Retry' loop using a 'each' expression.
AnswerA

The VSTest@2 task supports automatic retry of failed tests.

Why this answer

Option B is correct because the 'retryFailedTests' option in the VSTest task automatically retries failed tests. Option A is a workaround but not a built-in feature. Option C requires custom scripting.

Option D is not available in Azure DevOps.

Full explanation →
218
MCQmedium

Your Azure DevOps pipeline uses a variable group to store secrets. The variable group is linked to a Key Vault. You need to use a secret variable in a pipeline task. How should you reference the secret in the YAML pipeline?

A.Reference the variable as $(VariableName) but only in a script task using 'env' mapping.
B.Use the 'task.getVariable' method in a PowerShell script.
C.Reference the variable as $(VariableName) in the pipeline tasks.
D.Use the Azure Key Vault task to retrieve the secret and then reference the output variable.
AnswerC

Azure Pipelines automatically maps Key Vault secrets as pipeline variables accessible with $(VariableName).

Why this answer

Option A is correct because Key Vault-backed variables are automatically mapped as secret variables, and you reference them using the variable name. Option B is incorrect because $(variable) syntax is for non-secret variables; secrets require $(). Option C is incorrect because the task name is not part of the reference.

Option D is incorrect because task.getVariable is a scripting method, not YAML.

Full explanation →
219
Multi-Selecthard

Your organization uses Azure Pipelines with Microsoft-hosted agents. The pipeline runs a .NET Core application build. You notice that the build takes longer than expected. Which THREE actions can you take to improve build performance? (Choose three.)

Select 3 answers
A.Add more build steps to the pipeline.
B.Enable caching for NuGet packages.
C.Increase the number of parallel jobs in the pipeline.
D.Use multi-stage build with parallel test execution.
E.Use a self-hosted agent with pre-installed dependencies.
AnswersB, D, E

Caching reduces download time for packages.

Why this answer

Option B is correct because enabling NuGet package caching in Azure Pipelines stores downloaded packages on the agent, avoiding repeated downloads from the NuGet feed on subsequent builds. This significantly reduces build time, especially when the same packages are used across multiple pipeline runs, as network latency and package restore operations are minimized.

Exam trap

The trap here is that candidates often confuse increasing parallel jobs (which affects concurrency) with optimizing a single pipeline's execution time, leading them to incorrectly select option C.

Full explanation →
220
MCQmedium

Refer to the exhibit. You have a branch policy JSON for Azure Repos. Which statement about this policy is correct?

A.The last person who pushed can approve the pull request.
B.At least two reviewers must approve the pull request.
C.Pull requests to main are automatically squash-merged.
D.Approvals are reset when the source branch is updated.
AnswerB

requireApprovalCount is 2.

Why this answer

The branch policy JSON specifies `minimumApproverCount: 2`, which enforces that at least two distinct reviewers must approve the pull request before it can be completed. This is a standard Azure Repos branch policy setting that controls the required number of approvals, not the identity of the approvers or the merge strategy.

Exam trap

The trap here is that candidates assume the last person who pushed can always approve, but Azure Repos defaults to blocking that unless explicitly overridden, and the policy JSON shown does not include the override setting.

How to eliminate wrong answers

Option A is wrong because Azure Repos branch policies do not automatically allow the last pusher to approve; unless explicitly allowed via the 'Allow approvers to approve their own changes' setting, the last person who pushed is typically blocked from approving. Option C is wrong because the JSON does not set a merge strategy; squash-merge is a separate policy option not shown here. Option D is wrong because the policy does not include `resetOnSourcePush: true`; without that setting, approvals are not automatically reset when the source branch is updated.

Full explanation →
221
Multi-Selecthard

You are designing a pipeline that must run tasks in a container. The container needs access to Azure resources using a managed identity. Which two configurations are required? (Choose two.)

Select 2 answers
A.Enable a system-assigned managed identity on the agent VM.
B.Use the 'docker login' command in the pipeline.
C.Add a service principal connection to the pipeline.
D.Set the 'identity' field in the container resource definition.
E.Use the Azure CLI task with '–identity' flag.
AnswersA, D

Why this answer

Option A is correct because a system-assigned managed identity on the agent VM allows the container to authenticate to Azure resources without storing credentials. Option D is correct because setting the 'identity' field in the container resource definition explicitly assigns that managed identity to the container, enabling it to request tokens from Azure AD for resource access.

Exam trap

The trap here is that candidates confuse pipeline-level authentication (service principal connections) with container-level identity assignment, or think that a Docker login or Azure CLI flag can substitute for the explicit identity configuration on the container resource.

Why the other options are wrong

B

docker login is for authentication to a container registry, not for Azure resources.

C

Service principal connection is for non-managed identity authentication; managed identity avoids storing credentials.

E

The Azure CLI task can use managed identity, but the configuration requires the identity to be assigned and the task to run inside the container.

Full explanation →
222
Multi-Selectmedium

You are designing a multi-stage YAML pipeline for an application that requires approval for production deployment. The pipeline must run automatically for non-production stages. Which TWO configurations should you use?

Select 2 answers
A.Set the pipeline trigger to include branches used for non-production stages.
B.Define a stage for production with an 'approvals' block.
C.Use a release pipeline instead of a YAML pipeline.
D.Set the pipeline to require manual approval for every stage.
E.Use a single-stage pipeline with conditional approval.
AnswersA, B

CI trigger runs automatically for non-production.

Why this answer

Option B is correct because approval gates can be added to the production stage. Option D is correct because the trigger should be set for CI triggers on non-production branches. Options A, C, and E are not correct.

Full explanation →
223
MCQmedium

Your release pipeline deploys a .NET Core web app to Azure App Service using a deployment slot for staging. The pipeline runs integration tests against the staging slot. After tests pass, you want to swap the staging slot with production. However, the swap fails sometimes because the staging slot has different configuration settings. What is the best practice to ensure swapping succeeds?

A.Use slot-specific configuration settings (deployment slot settings) for connection strings and app settings that differ between slots.
B.Manually update the production slot settings to match staging before each swap.
C.Perform a swap with preview and then complete the swap after verifying the staging slot.
D.Write a custom PowerShell script to copy configuration from staging to production before swapping.
AnswerA

Slot-specific settings stay with the slot during swap, preventing conflicts.

Why this answer

Option A is correct because Azure App Service allows you to mark specific configuration settings (like connection strings and app settings) as 'deployment slot settings.' When a setting is marked as slot-specific, it stays with the slot during a swap, preventing failures caused by mismatched configurations. This ensures that the staging slot retains its test-specific settings (e.g., a test database connection string) while the production slot keeps its own settings, making the swap predictable and reliable.

Exam trap

The trap here is that candidates often confuse 'swap with preview' (which is about validation and rollback) with the root cause of swap failures, not realizing that slot-sticky settings are the proper mechanism to prevent configuration conflicts during a swap.

How to eliminate wrong answers

Option B is wrong because manually updating production slot settings before each swap is error-prone, violates infrastructure-as-code principles, and introduces downtime or misconfiguration risks. Option C is wrong because swap with preview is a technique to validate the swap outcome, not a solution for configuration mismatches; it does not prevent swap failures caused by slot-specific settings. Option D is wrong because writing a custom PowerShell script to copy configuration is unnecessary complexity and defeats the purpose of Azure's built-in slot-sticky settings; it also risks overwriting production settings unintentionally.

Full explanation →
224
MCQeasy

You are responsible for a release pipeline that deploys a containerized application to Azure Kubernetes Service (AKS). The pipeline currently builds and pushes a Docker image to Azure Container Registry (ACR) and then updates the Kubernetes manifest. You need to implement a rollback strategy in case the deployment fails. The rollback should revert to the previous known good version of the application. Which approach should you use?

A.Keep the previous Docker image tag in ACR and update the manifest to point to it manually.
B.Rerun the previous successful pipeline run.
C.Use the Kubernetes task with the 'rollback' option, which runs 'kubectl rollout undo' on the deployment.
D.Use Helm to manage releases and rollback using 'helm rollback' command.
AnswerC

Kubernetes built-in rollback reverts to the previous revision.

Why this answer

Using Kubernetes native rollback with 'kubectl rollout undo' is the simplest. Option B uses Helm rollback, which is similar but adds complexity. Option C relies on ACR tags, which is not immediate.

Option D requires manual re-run.

Full explanation →
225
MCQeasy

Your team uses Azure DevOps and wants to enforce that all changes to the main branch go through a pull request process with at least two approvals. They also want to prevent contributors from approving their own pull requests. Which branch policy settings should they use?

A.Enable 'Check for linked work items' and 'Require a minimum number of reviewers' set to 2, and enable 'Reset code reviewer votes when new changes are pushed'.
B.Add the 'main' branch to the 'Required reviewers' list and add all developers as required reviewers.
C.Enable 'Require a minimum number of reviewers' set to 2, and enable 'Build validation' with a required build.
D.Enable 'Require a minimum number of reviewers' set to 2, and enable 'Allow users to approve their own changes' unchecked (or set to false).
AnswerD

This enforces two approvals and prevents self-approval.

Why this answer

Option D is correct because it directly addresses both requirements: setting 'Require a minimum number of reviewers' to 2 enforces at least two approvals, and unchecking 'Allow users to approve their own changes' prevents contributors from approving their own pull requests. These are branch policy settings within Azure Repos that control the pull request workflow on the main branch.

Exam trap

The trap here is that candidates often confuse 'Require a minimum number of reviewers' with 'Required reviewers' (a static list) or think that build validation alone satisfies the approval requirement, missing the need to explicitly disable self-approval.

How to eliminate wrong answers

Option A is wrong because 'Check for linked work items' ensures traceability but does not enforce the number of approvals or prevent self-approval; 'Reset code reviewer votes when new changes are pushed' is unrelated to the approval count or self-approval restriction. Option B is wrong because adding the 'main' branch to 'Required reviewers' and listing all developers as required reviewers would force every developer to be a reviewer on every PR, which is impractical and does not enforce a minimum of two approvals or prevent self-approval. Option C is wrong because 'Build validation' ensures code quality via automated builds but does not control the number of human approvals or self-approval behavior.

Full explanation →
Page 2

Page 3 of 13

Page 4

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 →