Microsoft Azure DevOps Engineer Expert AZ-400 AZ-400 Questions 301–375 | Page 5/11

301

MCQhard

You are troubleshooting an intermittent performance issue in a web application. Application Insights shows a high number of failed dependency calls to Azure SQL Database. The errors are SqlException with error code -2 (timeout). What is the most likely cause and recommended fix?

A.The application is exhausting the connection pool; increase Max Pool Size in the connection string.

B.The SQL Server firewall is blocking the application IP; add a firewall rule.

C.The database is experiencing deadlocks; enable read committed snapshot isolation.

D.The database DTU limit is being exceeded; scale up the service tier.

AnswerA

Connection pool exhaustion occurs when the application requests more connections than the configured Max Pool Size, forcing new requests to wait for a free connection until the connection timeout threshold is reached, which manifests as intermittent timeouts under load; increasing Max Pool Size or ensuring connections are properly disposed can resolve this.

Why this answer

A is correct because SqlException with error code -2 indicates a connection timeout, which in a high-traffic scenario is most commonly caused by the application exhausting the connection pool. When all connections in the pool are in use and the wait time for a free connection exceeds the Connect Timeout (default 15 seconds), new requests fail with this error. Increasing Max Pool Size in the connection string (e.g., Max Pool Size=200) allows more concurrent connections, reducing contention.

Exam trap

The trap here is that candidates confuse a connection timeout (error -2) with a query timeout or resource throttling, leading them to choose DTU scaling or deadlock solutions instead of recognizing the connection pool exhaustion pattern.

How to eliminate wrong answers

Option B is wrong because a firewall block would produce a different error (e.g., SqlException with error 53 or 18456, not -2) and would affect all requests consistently, not intermittently. Option C is wrong because deadlocks generate error code 1205, not -2, and are resolved by retry logic or snapshot isolation, not by adjusting pool size. Option D is wrong because exceeding DTU limits causes throttling with error codes like 10928 or 40501, not a timeout error -2, and scaling up would not fix connection pool exhaustion.

Full explanation →

302

MCQmedium

Your team is using GitHub Flow for a web application. Developers create feature branches from main, make changes, and open pull requests. Recently, several pull requests were merged without required reviews because the branch protection rules were not enforced on the main branch. What should you do to ensure all pull requests to main require at least one reviewer?

A.Enable the 'Require a pull request before merging' rule in branch protection for main, and set 'Required approvals' to 1.

B.Configure the repository to automatically delete head branches after pull requests are merged.

C.Enable the 'Require branches to be up to date' rule in branch protection for main.

D.Add a CODEOWNERS file and configure it so that every file has at least one owner.

AnswerA

Enabling 'Require a pull request before merging' in branch protection forces every commit to main to be introduced via a pull request, which is the foundational mechanism for mandatory code review. When combined with 'Required approvals' set to 1, the merge is blocked until at least one reviewer has explicitly approved the changes, providing a hard enforcement of the team's review policy.

Why this answer

Branch protection rules in GitHub can enforce required pull request reviews before merging. By enabling 'Require a pull request before merging' and setting 'Required approvals' to 1, any pull request to main must have at least one reviewer approve before merging. Option B is incorrect because deleting head branches after merge does not enforce reviews.

Option C is incorrect because requiring branches to be up to date is about ensuring the branch is current with the base branch, not about requiring reviews. Option D is incorrect because CODEOWNERS are optional and do not enforce mandatory reviews unless branch protection rules are set accordingly.

Full explanation →

303

MCQhard

A financial services company uses Azure DevOps and requires that all secrets (e.g., API keys, connection strings) be stored in Azure Key Vault. They have a pipeline that runs automated tests and deploys to staging. The pipeline uses a variable group linked to Key Vault to retrieve secrets. Recently, the pipeline failed with the error: 'Secret 'DbPassword' not found in Key Vault 'kv-prod'. Ensure the secret exists and the service principal has List permission.' The secret exists in the vault. What is the most likely cause?

A.The variable group is linked to the wrong Key Vault instance.

B.The variable name in the variable group does not exactly match the secret name in Key Vault (case-sensitive).

C.The service principal does not have Get permission on the secret.

D.The Key Vault is in a different Azure region than the Azure DevOps organization.

AnswerB

Azure DevOps maps variable names to secret names, and the match is case-sensitive.

Why this answer

Variable groups linked to Azure Key Vault in Azure DevOps require an exact case-sensitive match between the variable name in the variable group and the secret name in Key Vault. Even though the secret 'DbPassword' exists in the vault, if the variable group defines the variable as 'dbpassword' or 'DBPassword', the lookup will fail with the 'not found' error. The error message explicitly states the secret was not found, which is the typical symptom of a case mismatch, not a permissions or connectivity issue.

Exam trap

The trap here is that candidates assume the error 'secret not found' always means the secret is missing or permissions are wrong, but Azure DevOps specifically tests the case-sensitive mapping between variable group variable names and Key Vault secret names, which is a subtle but critical detail.

How to eliminate wrong answers

Option A is wrong because the error message specifically names Key Vault 'kv-prod', indicating the pipeline is targeting that vault; if the variable group were linked to a different vault, the error would reference that other vault's name. Option C is wrong because the error message mentions 'List permission', not 'Get permission'; the service principal must have both Get and List permissions on secrets, but the error explicitly says 'List permission' is required, and the secret exists, so the issue is not a missing Get permission. Option D is wrong because Azure Key Vault and Azure DevOps can operate across different Azure regions without any impact on secret retrieval; region mismatch does not cause 'secret not found' errors.

Full explanation →

304

Matchingmedium

Match each Azure Pipeline concept to its definition.

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

Concepts

Matches

Compute resource to run jobs

Logical boundary for pipeline phases

Sequence of steps on a single agent

Atomic build or deployment action

Why these pairings

The correct matches are: A: Pipeline → 'A collection of stages that defines the CI/CD process' (correct); B: Stage → 'A logical boundary in the pipeline used to group jobs' (correct); C: Job → 'A unit of work that runs on an agent' (correct); D: Task → 'A single operation to perform in a job' (correct). E is incorrect because Pipeline is not a logical boundary; that definition belongs to Stage. F is incorrect because Stage is not a collection of stages; that definition belongs to Pipeline.

The most common confusion is swapping the definitions of Pipeline and Stage.

Full explanation →

305

MCQhard

Your organization uses GitHub and wants to implement a monorepo strategy for multiple related projects. Which approach best optimizes CI/CD pipeline performance by only building projects that have changed?

A.Use a single workflow that builds all projects on every push

B.Use submodules to separate projects

C.Use workflow templates and composite actions

D.Use path filters in GitHub Actions workflows

AnswerD

Path filters in GitHub Actions, using `on.push.paths` or `pull_request.paths`, allow workflows to trigger only when specific files or directories change, so only the affected projects are built and tested. This is a best practice for monorepos because it reduces CI resource usage and provides faster, targeted feedback.

Why this answer

GitHub Actions path filters (using `on.push.paths` or `on.pull_request.paths`) allow you to trigger workflows only when changes are made to specific directories or files. In a monorepo, this ensures that CI/CD pipelines run exclusively for the projects that have been modified, avoiding unnecessary builds and significantly improving performance.

Exam trap

The trap here is that candidates confuse workflow reuse mechanisms (templates, composite actions) with conditional execution, or assume submodules are the standard monorepo approach, when in fact path filters are the native and efficient way to achieve selective builds in GitHub Actions.

How to eliminate wrong answers

Option A is wrong because a single workflow that builds all projects on every push ignores the monorepo optimization goal—it would rebuild unchanged projects, wasting compute time and slowing feedback loops. Option B is wrong because submodules are designed for managing external dependencies or separate repositories, not for optimizing CI/CD within a monorepo; they add complexity and do not inherently provide path-based build skipping. Option C is wrong because workflow templates and composite actions are reuse and abstraction mechanisms, not a solution for conditional execution based on changed paths; they help reduce duplication but do not control which projects are built.

Full explanation →

306

MCQeasy

You are creating a release pipeline that uses Azure Pipelines to deploy to multiple virtual machines. You need to ensure that the deployment runs on each machine in parallel. Which deployment strategy should you use?

A.Blue-green deployment

B.Canary deployment

C.Rolling deployment

D.Run once deployment with parallel execution

AnswerD

Run once deployment with parallel execution is correct because it configures the deployment job to run on all targets in the deployment group at the same time, executing the tasks concurrently across every machine. This approach directly fulfills the requirement of running the job on all targets simultaneously, ensuring consistent and synchronized deployment.

Why this answer

The requirement is to deploy to multiple virtual machines in parallel, which is achieved by configuring a 'run once' deployment strategy with parallel execution in Azure Pipelines. This strategy uses the deployment group's parallel execution settings to run the deployment job simultaneously on all target machines, ensuring each machine receives the deployment at the same time.

Exam trap

The trap here is that candidates often confuse 'rolling deployment' with parallel execution, but rolling is inherently sequential (batched), while the question explicitly requires parallel execution across all machines, which is only achieved by the 'run once' strategy with parallel execution enabled.

How to eliminate wrong answers

Option A is wrong because blue-green deployment is a strategy that maintains two identical environments (blue and green) and switches traffic between them, not a method for parallel deployment to multiple VMs within the same environment. Option B is wrong because canary deployment gradually rolls out changes to a subset of users or servers before expanding, which is inherently sequential and not parallel across all machines. Option C is wrong because rolling deployment updates machines one by one or in batches (e.g., 20% at a time) to minimize downtime, which is sequential, not parallel.

Full explanation →

307

MCQmedium

Your team uses feature flags to manage feature releases. You need to ensure that a feature flag is automatically turned off for all users except the development team after a production incident. What is the best approach?

A.Create a separate branch with the feature disabled and deploy it.

B.Use a feature management system like Azure App Configuration with a targeting filter to enable only for the dev team.

C.Set an environment variable in the production environment to disable the feature.

D.Manually toggle the feature flag off in the app configuration.

AnswerB

Azure App Configuration's feature management with a targeting filter evaluates flags at runtime, allowing you to define a dynamic rule that enables the feature only for members of the dev team while all other users see the old behavior. This approach provides instant, per-audience control without code changes or redeployment, and you can modify the filter or turn the flag off immediately via the configuration service, making it the correct solution for safe feature releases.

Why this answer

Azure App Configuration's feature management system provides a built-in targeting filter that allows you to dynamically enable a feature flag for specific users or groups (e.g., the development team) while disabling it for all others. This approach supports real-time, no-deployment changes, which is essential for quickly responding to a production incident without modifying code or redeploying.

Exam trap

The trap here is that candidates may choose manual toggling (Option D) because it seems simplest, but they overlook the requirement to keep the feature enabled for the development team, which requires a targeting filter rather than a global off switch.

How to eliminate wrong answers

Option A is wrong because creating a separate branch and redeploying introduces unnecessary delay and risk, and it contradicts the purpose of feature flags, which are designed to toggle features without code changes or deployments. Option C is wrong because environment variables require a restart or redeployment to take effect, and they lack the granular user/group targeting needed to enable the feature only for the development team. Option D is wrong because manually toggling the flag off in the app configuration would disable it for all users, including the development team, which does not meet the requirement of keeping it enabled for the dev team.

Full explanation →

308

Multi-Selectmedium

Which TWO are valid strategies for managing secrets in a GitHub Actions workflow?

Select 2 answers

A.Use OpenID Connect to authenticate to Azure without storing any credentials.

B.Hardcode the secret in the YAML file.

C.Set the secret as an environment variable in the runner's shell profile.

D.Base64-encode the secret and include it directly in the workflow file.

E.Store the secret as an encrypted GitHub secret and reference it using ${{ secrets.SECRET_NAME }}.

AnswersA, E

OpenID Connect (OIDC) allows GitHub Actions workflows to request short-lived tokens from Azure AD by exchanging a signed JWT from GitHub's OIDC provider, eliminating the need to store static credentials like client secrets or service principal passwords. This is a valid strategy because it reduces secret exposure and enables automatic credential rotation.

Why this answer

OpenID Connect (OIDC) allows GitHub Actions to exchange a short-lived token directly with Azure without storing any long-lived credentials as secrets. This eliminates the need to manage and rotate client secrets or service principal passwords, reducing the risk of credential leakage. The workflow uses the `azure/login` action with `client-id`, `tenant-id`, and `subscription-id` parameters, and Azure trusts the OIDC token issued by GitHub.

Alternatively, storing the secret as an encrypted GitHub secret is also a valid strategy: GitHub encrypts secrets at rest and injects them into the workflow runtime only when referenced via `${{ secrets.SECRET_NAME }}`. This prevents hardcoding secrets in the YAML and keeps them out of logs, though it still requires managing the secret value and rotation.

Exam trap

The trap here is that candidates often confuse Base64 encoding with encryption, mistakenly believing it provides security, or they think environment variables on the runner are isolated per job, when in fact they can leak across steps or be read by other processes on the same runner.

Full explanation →

309

MCQmedium

Your team uses Azure Repos for source control. You need to enforce that all builds must pass unit tests before code can be merged into the main branch. Which branch policy should you configure?

A.Add a build validation policy that triggers the CI pipeline and requires it to succeed.

B.Require a linked work item.

C.Require a minimum number of reviewers.

D.Require comment resolution.

AnswerA

A build validation policy in Azure Repos branch policies attaches an automated pipeline to the PR as a required gate. When a PR is created or updated, Azure Pipelines runs the specified CI pipeline and posts a status back to the PR; the merge is blocked unless the policy reports a successful pipeline run. This directly enforces build integrity at the merge point, making it the correct way to ensure that code compiles and tests pass before it enters the target branch.

Why this answer

Azure Repos branch policies allow you to add a build validation policy that triggers a CI pipeline (e.g., a YAML or classic build pipeline) and requires it to succeed before a pull request can be completed. This ensures that all code merged into the main branch has passed unit tests, enforcing quality gates directly in the PR workflow.

Exam trap

The trap here is that candidates may confuse build validation policies with other branch policies like required reviewers or work item linking, thinking they indirectly enforce quality, but only build validation directly enforces that unit tests pass before merge.

How to eliminate wrong answers

Option B is wrong because requiring a linked work item ensures traceability to a work item (e.g., a user story or bug), but it does not enforce that builds pass unit tests. Option C is wrong because requiring a minimum number of reviewers enforces code review but does not validate build or test success. Option D is wrong because requiring comment resolution ensures that PR comments are addressed, but it does not enforce any build or test validation.

Full explanation →

310

MCQmedium

You run the PowerShell command shown in the exhibit. The virtual network already exists. What is the outcome?

A.The virtual network's tags are updated to the specified tags.

B.The virtual network is deleted and recreated.

C.An error occurs because the virtual network already exists.

D.A new virtual network with a different name is created.

AnswerA

The New-AzResource cmdlet with the -Force switch and a fully qualified ResourceId performs an in-place update of the existing virtual network's properties. Since the command specifies the existing resource's ID and the -Force parameter overrides the default error for existing resources, only the tags are applied, leaving the virtual network itself untouched.

Why this answer

The `New-AzResource` cmdlet can create a new resource or update an existing resource. If the virtual network already exists, the cmdlet updates it, including applying the specified tags. The `-Force` parameter suppresses confirmation prompts and does not determine create vs. update behavior.

Exam trap

Candidates may assume `New-Az*` cmdlets always create new resources and error if the resource exists, but `New-AzResource` supports both create and update, so it updates the existing resource.

How to eliminate wrong answers

Option B is wrong because `New-AzVirtualNetwork -Force` does not delete and recreate the virtual network; it updates the existing resource in place. Option C is wrong because the `-Force` parameter suppresses the 'resource already exists' error, allowing the command to proceed with an update. Option D is wrong because the command uses the same name (from the `-Name` parameter) and does not create a new virtual network with a different name.

Full explanation →

311

MCQmedium

You have deployed an Azure Resource Manager (ARM) template for a scheduled query rule as shown. The rule is enabled and targets an Application Insights resource. However, no alerts are firing despite HTTP 500 errors occurring. What is the most likely cause?

A.The severity is set to 2, which suppresses the alert.

B.The threshold of 100 is too high; the rule should use a percentage-based condition on error rate.

C.The metric name 'requests/count' is misspelled; it should be 'requests/count' (correct).

D.The dimension filter for 'request/resultCode' includes '500' but should also include '5xx' wildcard.

AnswerB

The rule should use a percentage-based condition on the failed request rate rather than an absolute count of 100. In low-traffic applications, 100 failed requests may represent a very high error percentage and go undetected, while a percentage threshold would trigger alerts based on the rate of failures relative to total requests.

Why this answer

The threshold of 100 is an absolute count, not a percentage. HTTP 500 errors may occur sporadically, but unless they reach 100 within the evaluation window, the alert will not fire. For error-rate monitoring, a percentage-based condition (e.g., >5% of total requests) is more appropriate to detect anomalies even with lower traffic volumes.

Exam trap

The trap here is that candidates often assume an absolute count threshold is fine for error monitoring, but Azure's alerting logic requires careful consideration of traffic patterns—percentage-based conditions are essential for detecting error rate spikes in variable-load environments.

How to eliminate wrong answers

Option A is wrong because severity level 2 does not suppress alerts; severity levels (0-4) only affect the alert's classification in Azure Monitor, not its firing behavior. Option C is wrong because 'requests/count' is a valid metric name in Application Insights; there is no misspelling. Option D is wrong because the dimension filter for 'request/resultCode' with value '500' is correct; Azure Monitor does not support wildcards like '5xx' in dimension filters—you must specify exact values.

Full explanation →

312

MCQmedium

Your organization uses Azure Pipelines and requires that all builds be run on Microsoft-hosted agents to reduce maintenance overhead. However, you need to ensure that the build agent has a specific version of Node.js installed that is not available on the standard Microsoft-hosted agents. What should you do?

A.Use a container job that runs a custom Docker image with the required Node.js version.

B.Deploy a self-hosted agent with the required Node.js version.

C.Use a script task to install the specific Node.js version at the start of the pipeline.

D.Request Microsoft to add the Node.js version to their hosted agents.

AnswerA, C

Container jobs are supported on Microsoft-hosted agents that have Docker capability (e.g., ubuntu-latest). Using a custom Docker image with the required Node.js version is a valid approach because the container runs on the agent and can be configured with any tools.

Why this answer

Azure Pipelines supports container jobs on Microsoft-hosted agents with Docker (e.g., ubuntu-latest, windows-2019 with Docker enabled). By using a custom Docker image that includes the required Node.js version, you can run builds in a container while still using a Microsoft-hosted agent. Option C is also correct because you can use a script task at the start of the pipeline to install the specific Node.js version dynamically; Microsoft-hosted agents allow runtime installation of software via scripts.

Options B and D are incorrect: B would require a self-hosted agent, violating the Microsoft-hosted agent requirement; D is not practical and not a guaranteed solution.

Exam trap

The trap is that candidates often assume container jobs are not compatible with Microsoft-hosted agents, but many Microsoft-hosted agents (e.g., ubuntu-latest) have Docker installed and can run container jobs. Additionally, some might think installing Node.js via script is not allowed, but it is a supported practice.

How to eliminate wrong answers

Option A is wrong because container jobs require a self-hosted agent or a specific agent pool that supports Docker, and the question explicitly mandates using Microsoft-hosted agents, which do not support custom container jobs by default. Option B is wrong because deploying a self-hosted agent contradicts the requirement to reduce maintenance overhead by using Microsoft-hosted agents. Option D is wrong because Microsoft does not accept requests to add specific Node.js versions to their hosted agent images; they only update images periodically based on broad community demand.

Full explanation →

313

MCQhard

The pipeline fails because the artifact is empty. What is the most likely cause?

A.The build output is not copied to the staging directory

B.The projects pattern '**/*.csproj' does not match any files

C.The task 'PublishBuildArtifacts@1' is misspelled

D.The artifact name 'drop' is invalid

AnswerA

The PublishBuildArtifacts task publishes files from a staging directory (e.g., $(Build.ArtifactStagingDirectory)). If your build tasks only compile but never copy the compiled output (DLLs, EXEs) to that staging path, Azure DevOps uploads an empty folder, so the artifact contains no files despite the build succeeding.

Why this answer

The most common reason for an empty artifact in Azure Pipelines is that the build output files were not copied to the staging directory (typically $(Build.ArtifactStagingDirectory)) before the PublishBuildArtifacts task runs. The PublishBuildArtifacts task publishes whatever is in the staging directory; if no files are copied there, the artifact will be empty. This is a standard pattern where a Copy Files task or similar step must explicitly place the build outputs into the staging directory.

Exam trap

The trap here is that candidates often focus on file matching patterns or task names, but the core issue is the missing copy step to the staging directory, which is a fundamental pipeline design concept.

How to eliminate wrong answers

Option B is wrong because if the projects pattern '**/*.csproj' does not match any files, the build itself would fail or produce no output, but the artifact would still be empty only if no files were copied to staging; this pattern mismatch would cause a build error, not an empty artifact. Option C is wrong because the task 'PublishBuildArtifacts@1' is correctly spelled and is a valid task identifier; a misspelling would cause a task not found error, not an empty artifact. Option D is wrong because the artifact name 'drop' is a valid and commonly used default name; an invalid name would cause a validation error, not an empty artifact.

Full explanation →

314

Multi-Selecteasy

Which TWO compliance frameworks are directly supported by Microsoft Purview Compliance Manager for Azure DevOps?

Select 2 answers

A.ISO 27001

B.HIPAA

C.PCI DSS

D.FedRAMP High

E.SOC 2

AnswersA, E

ISO 27001 is a widely adopted information security management standard, and Purview Compliance Manager includes a template that maps Azure DevOps controls to it. You can use this template to assess and manage your DevOps compliance posture against ISO 27001 requirements.

Why this answer

Microsoft Purview Compliance Manager directly supports ISO 27001 and SOC 2 as built-in compliance templates for Azure DevOps. These frameworks are pre-configured with control mappings, assessment templates, and automated testing actions that align with Azure DevOps security and audit capabilities. This allows organizations to continuously monitor and manage compliance posture against these standards without manual configuration.

Exam trap

The trap here is that candidates often assume any major compliance framework (like HIPAA or PCI DSS) is directly supported, but Microsoft Purview Compliance Manager for Azure DevOps only provides pre-built templates for a specific subset of frameworks, including ISO 27001 and SOC 2, while others require custom assessments or are covered at the Azure platform level rather than the Azure DevOps service level.

Full explanation →

315

MCQhard

You are designing a build pipeline that uses Microsoft-hosted agents. The pipeline must build a .NET Framework 4.8 application and run on a Windows agent. Due to compliance, the build must use a specific version of Visual Studio that is not pre-installed on the Microsoft-hosted agents. What should you do?

A.Use a self-hosted agent that has the required version of Visual Studio installed.

B.Build the application inside a Docker container that includes the required Visual Studio version.

C.Specify the 'vsVersion' parameter in the MSBuild task to target the required version.

D.Use the 'Visual Studio Test Platform Installer' task to install the required version at build time.

AnswerA, B

Microsoft-hosted agents provide only a fixed set of pre-installed Visual Studio versions, so if the required version is absent, the build cannot run on them. A self-hosted agent can be explicitly provisioned with the exact Visual Studio version needed, and registered with an agent pool so pipeline jobs are matched to it via capabilities.

Why this answer

To use a specific version of Visual Studio not pre-installed on Microsoft-hosted agents, you can either use a self-hosted agent with that version installed, or run the build in a Docker container that includes the required Visual Studio/Build Tools version. Microsoft-hosted agents have Docker installed and can run Windows containers, so option B is viable. Options C and D do not install a full Visual Studio version.

Full explanation →

316

MCQmedium

You are a DevOps consultant for a financial services company that is migrating from TFVC to Git. The existing TFVC repository has several branches: main, dev, feature branches, and release branches. The history is linear with no branching. The company requires that all future Git commits follow a strict naming convention: 'type(scope): description' (e.g., 'feat(api): add new endpoint'). They also want to prevent direct commits to the main branch; all changes must go through pull requests with at least one reviewer. Additionally, they want to ensure that each commit message is validated before it is merged. The team is small (5 developers) and they want a simple setup without complex tooling. Which approach should you recommend?

A.Create a build pipeline that validates commit messages and fails the build if invalid

B.Use a server-side pre-receive hook in the Git repository

C.Install a client-side pre-commit hook on each developer's machine to validate messages

D.Configure branch policies on the main branch: require a minimum of one reviewer, and add a status check that runs a script to validate the commit message format

AnswerD

Branch policies in Azure Repos provide server-side enforcement: requiring a minimum number of reviewers and adding a build validation status check that runs a script to validate commit message format ensures that every pull request to main must pass both human review and automated message validation before merging, which fully satisfies the requirement.

Why this answer

Azure Repos branch policies allow you to enforce pull request requirements (e.g., minimum number of reviewers) and require a status check that runs a custom script to validate commit message format. This ensures all commits merged into main comply with the naming convention and review policy without complex tooling, fitting the small team's need for a simple, server-side enforcement mechanism.

Exam trap

The trap here is that candidates often confuse client-side hooks (option C) with server-side enforcement, not realizing that client-side hooks are optional and easily bypassed, whereas Azure Repos branch policies (option D) provide mandatory, centralized enforcement without requiring custom server-side hook infrastructure.

How to eliminate wrong answers

Option A is wrong because a build pipeline that validates commit messages runs after the code is already merged (or during a PR build), but it does not prevent direct commits to main or enforce the review requirement; it only fails the build, not the merge. Option B is wrong because server-side pre-receive hooks are not natively supported in Azure Repos (they are available in on-premises Git servers like GitHub Enterprise or self-hosted GitLab); Azure Repos uses branch policies instead. Option C is wrong because client-side pre-commit hooks are not enforceable; developers can bypass them by using --no-verify or by not installing the hook, so they do not guarantee compliance across the team.

Full explanation →

317

MCQeasy

Your build pipeline uses a self-hosted agent that runs on a Windows machine. The pipeline fails with the error: 'The task 'DotNetCoreCLI' is not supported on this agent.' What is the most likely cause?

A.The agent's execution policy is restricted.

B.The agent does not have the required capabilities (e.g., .NET Core SDK installed).

C.The agent is not authorized to run the pipeline.

D.The agent cannot connect to the internet to download the task.

AnswerB

Each task in an Azure DevOps pipeline declares required capabilities such as a specific SDK, tool, or platform version. When a self-hosted agent lacks a declared capability, such as the .NET Core SDK, the agent cannot execute the task and reports that the task is not supported, because the agent's available capabilities do not match the task's demands.

Why this answer

The error 'The task 'DotNetCoreCLI' is not supported on this agent' indicates that the agent lacks the required capabilities to execute the task. In Azure Pipelines, self-hosted agents must have the necessary software (e.g., .NET Core SDK) installed and declared as capabilities for the task to be considered supported. Option B correctly identifies this missing capability as the root cause.

Exam trap

The trap here is that candidates confuse a missing capability (which causes a 'not supported' error) with an authorization or connectivity issue, leading them to pick options C or D, when the real problem is the agent's software prerequisites.

How to eliminate wrong answers

Option A is wrong because the execution policy (e.g., PowerShell execution policy) affects script execution, not the agent's ability to support a specific task like DotNetCoreCLI. Option C is wrong because authorization issues (e.g., agent pool permissions) would result in a different error, such as 'Agent is not authorized' or 'Access denied', not a task support error. Option D is wrong because the DotNetCoreCLI task is a built-in task that does not require internet download; it runs locally on the agent, and connectivity issues would cause a different error (e.g., 'Unable to download task') or a timeout.

Full explanation →

318

MCQhard

A company uses Azure Pipelines with YAML-based pipelines stored in a Git repository. The pipeline triggers on every push to the main branch, but the team wants to reduce unnecessary builds when only documentation files are changed. What is the best way to achieve this?

A.Use path filters in the trigger section to exclude 'docs/*' and '*.md' files.

B.Configure branch policy to require a pull request for documentation changes.

C.Add a 'condition' to the pipeline that checks if changed files are documentation.

D.Disable CI trigger and rely on scheduled builds.

AnswerA

Path filters in the trigger section use `trigger.paths.exclude` to prevent pipeline execution when only files under `docs/*` or matching `*.md` are changed; any other changed file will still trigger the pipeline, making this the correct, event-driven way to avoid documentation commits.

Why this answer

Path filters in the trigger section allow you to specify include and exclude patterns. By using exclude patterns for 'docs/*' and '*.md', the pipeline will not trigger when only documentation files are changed. Option B is incorrect because branch policies do not affect the pipeline trigger; they govern pull request requirements.

Option C is incorrect because conditions are evaluated at runtime, whereas we want to avoid triggering the pipeline altogether. Option D is incorrect because disabling CI trigger would require manual or scheduled builds, which is less efficient than using path filters.

Full explanation →

319

MCQeasy

A company uses Azure DevOps to manage code. They want to enforce that all changes to the main branch must go through a pull request with at least two reviewers. What should they configure?

A.Branch policy on the main branch

B.Add a tag to the main branch

C.Repository permissions

D.Configure a service hook

AnswerA

Branch policies on the main branch can enforce a minimum number of reviewers and require successful pull request reviews before merging, making them the standard mechanism to ensure code review compliance. They also block direct pushes, forcing all changes through the review process.

Why this answer

Branch policies in Azure DevOps allow you to enforce requirements on pull requests targeting a specific branch. By configuring a branch policy on the main branch, you can require a minimum number of reviewers (e.g., two) and mandate that all changes must go through a pull request. This ensures that no direct commits bypass the review process.

Exam trap

The trap here is that candidates may confuse repository permissions (which control access) with branch policies (which control workflow and quality gates), leading them to select Option C instead of the correct branch policy configuration.

How to eliminate wrong answers

Option B is wrong because adding a tag to the main branch is a labeling mechanism for marking releases or milestones; it does not enforce any workflow or review requirements. Option C is wrong because repository permissions control who can read, write, or administer the repository, but they do not enforce pull request review requirements on specific branches. Option D is wrong because a service hook is used to integrate with external systems (e.g., sending notifications or triggering builds) and cannot enforce branch-level policies like requiring reviewers.

Full explanation →

320

MCQeasy

Your organization is adopting Azure DevOps to manage a new project for a client. The client requires that all work items be linked to Git commits and pull requests. Additionally, they want a dashboard that shows the team's velocity and work item trends. You are responsible for setting up the project and configuring the necessary integrations. The team uses a Scrum process with Sprints. You have already created the project and imported the work items. What should you do next to meet the client's requirements?

A.Create a custom tool using Azure Functions to parse commit messages and link work items. Use the built-in Charts feature in Azure Boards to create velocity charts.

B.Configure branch policies on the main branch to require linking work items. Set up the repository to automatically link commits to work items. Then create an Analytics view in Azure Boards to track velocity and work item trends.

C.Instruct developers to manually add work item IDs in commit messages and pull request descriptions. Create a custom dashboard using Power BI connected to Azure Boards.

D.Enable the setting 'Automatically link work items' in the repository settings. Configure a service hook to post commit details to a Teams channel for visibility.

AnswerB

This is the correct approach because Azure DevOps branch policies on the main branch can enforce that every pull request links to at least one work item, ensuring traceability at merge time. Enabling the repository setting to automatically link commits to work items (under Project Settings > Repositories > your repo > Policies > Automatically link work items) further links commits made directly to branches, covering both commit and PR scenarios. Creating an Analytics view in Azure Boards (via the Analytics tab or Power BI) provides customizable, trend-capable data on velocity and work item flow, which is more robust than built-in charts for tracking trends over time.

Why this answer

Configuring branch policies on the main branch to require linking work items ensures that all pull requests are linked to work items, and enabling automatic linking of commits to work items covers commits. Creating an Analytics view in Azure Boards provides the necessary velocity and work item trend dashboards. Option A is incorrect because Azure Functions are unnecessary—Azure DevOps provides built-in linking and Analytics.

Option C is incorrect because manual linking is inefficient and error-prone, and Power BI is not required. Option D is incorrect because it does not enforce linking on commits/PRs and does not address the dashboard requirement.

Full explanation →

321

MCQmedium

You have a YAML pipeline that builds a Java project using Maven. The pipeline uses a private artifact feed in Azure Artifacts. You need to authenticate to the feed from the pipeline. Which authentication method should you use?

A.Use the 'PipAuthenticate' task with a pip.conf file.

B.Use the 'npmAuthenticate' task with a .npmrc file.

C.Use the 'MavenAuthenticate' task with a settings.xml file.

D.Use the 'NuGetAuthenticate' task with a nuget.config file.

AnswerC

The MavenAuthenticate task is the correct choice because it directly configures Maven's settings.xml with the appropriate credentials for Azure Artifacts. This enables the Java project to authenticate when downloading dependencies or publishing artifacts to a Maven feed, which is exactly what this pipeline requires.

Why this answer

The 'MavenAuthenticate' task is specifically designed to authenticate Maven builds against Azure Artifacts feeds. It injects credentials into a settings.xml file, which Maven uses to resolve dependencies from the private feed. This task handles the OAuth token exchange required for Azure DevOps authentication.

Exam trap

The trap here is that candidates may confuse the authentication task with the package type (e.g., choosing 'npmAuthenticate' for a Java project because they think 'npm' is generic), but Azure Artifacts requires a task specific to the client tool (Maven) and its configuration file (settings.xml).

How to eliminate wrong answers

Option A is wrong because 'PipAuthenticate' is for Python package feeds (PyPI), not Maven; it uses a pip.conf file for authentication. Option B is wrong because 'npmAuthenticate' is for npm package feeds and uses a .npmrc file, which is irrelevant to Maven builds. Option D is wrong because 'NuGetAuthenticate' is for NuGet package feeds and uses a nuget.config file, which does not apply to Maven's settings.xml-based authentication.

Full explanation →

322

MCQhard

Your company, Contoso Ltd., is a financial services firm that must comply with PCI DSS. You manage a Azure DevOps organization with over 200 projects. Each project uses a service principal to deploy to Azure using service connections stored in library variable groups. Recently, an auditor flagged that a developer used a service principal with Contributor rights on a production subscription to accidentally delete a storage account. The developer had been granted access to the variable group containing that service principal's credentials. You are tasked with implementing a security and compliance plan to prevent this from recurring. The solution must minimize administrative overhead and follow the principle of least privilege. Current environment: All service principals are created in Azure AD and assigned to variable groups. Developers are granted 'User' access level in Azure DevOps and are members of various teams. You have the ability to create Azure AD groups and custom roles. Which course of action should you take?

A.Remove all variable groups and require developers to use their own Azure AD accounts for deployments, granting them Contributor rights only on non-production environments.

B.Require all pipeline runs that use production service connections to be approved by a security team via Azure Pipelines approval gates.

C.Implement Azure DevOps pipeline decorators to inject a security task that checks the service connection's role before each deployment, and fail the pipeline if the role is Contributor or higher.

D.Create custom Azure RBAC roles with minimal required permissions for each service principal, restrict service connections to specific pipelines using Azure DevOps security settings (e.g., 'Use' permission), and assign developers only the 'Use' permission to the service connections they need, not the variable groups containing credentials.

AnswerD

This approach aligns with least privilege by creating custom Azure RBAC roles that include only the exact actions required for each deployment, rather than using broad built-in roles like Contributor. Restricting service connections to specific pipelines via Azure DevOps security settings (e.g., the 'Use' permission) ensures that a compromised pipeline can only use its designated connection, and developers are not granted access to variable groups containing credentials, reducing the risk of secret leakage.

Why this answer

It enforces the principle of least privilege by creating custom Azure RBAC roles with minimal permissions, restricting service connections to specific pipelines via Azure DevOps security settings (e.g., 'Use' permission), and assigning developers only the 'Use' permission to the service connections rather than the variable groups containing credentials. This prevents developers from directly accessing or modifying the service principal credentials, eliminating the risk of accidental or malicious use of high-privilege roles like Contributor.

Exam trap

The trap here is that candidates often confuse approval gates (Option B) as a sufficient security control, but they fail to address the root cause—excessive permissions on the service principal itself—and overlook the need to restrict access to the service connection credentials at the Azure DevOps permission level.

How to eliminate wrong answers

Option A is wrong because removing variable groups and granting developers Contributor rights on non-production environments still violates least privilege—developers should not have Contributor rights on any environment if they only need to deploy, and using their own Azure AD accounts for deployments introduces security risks like credential exposure and lack of audit separation. Option B is wrong because requiring approval gates for all pipeline runs using production service connections adds administrative overhead and does not prevent a developer from accidentally using a Contributor role in a pipeline that has been approved; it only adds a manual check, not a technical control. Option C is wrong because pipeline decorators that check the service connection's role before each deployment can be bypassed if the developer modifies the pipeline YAML or if the decorator is not applied to all pipelines; also, failing the pipeline after the role check does not prevent the service principal from having excessive permissions in the first place.

Full explanation →

323

MCQmedium

You are reviewing a pipeline YAML file. The variable 'prod-db-password' is stored in a variable group linked to Azure Key Vault. However, the pipeline fails with an error that the secret cannot be accessed. What is the most likely cause?

A.The YAML syntax for referencing the variable is incorrect.

B.The pipeline's authorized service principal lacks 'Get' permission on the Key Vault.

C.The variable group 'prod-variables' does not exist.

D.The secret name in Key Vault does not match 'prod-db-password'.

AnswerB

When a variable group is linked to an Azure Key Vault, the Azure DevOps task attempts to retrieve secrets using the service principal associated with the pipeline's service connection. If that service principal lacks the 'Get' permission in the Key Vault's access policy for the secret, the task will fail specifically with an authorization error, making this the likely root cause.

Why this answer

The most likely cause is that the pipeline's authorized service principal lacks 'Get' permission on the Key Vault. When a variable group is linked to Azure Key Vault, Azure Pipelines uses a service principal (the pipeline's identity) to retrieve secrets. Even if the variable group and secret name are correct, the pipeline will fail if the service principal does not have the 'Get' secret permission in the Key Vault access policy.

This is a common misconfiguration because the variable group link only establishes the mapping, not the actual access rights.

Exam trap

The trap here is that candidates often assume the variable group link automatically grants access to Key Vault secrets, overlooking the separate requirement to configure Key Vault access policies for the pipeline's service principal.

How to eliminate wrong answers

Option A is wrong because the YAML syntax for referencing a variable from a linked variable group is simply $(variableName) or ${{ variables.variableName }}, and the error message about 'cannot be accessed' indicates a permissions issue, not a syntax error. Option C is wrong because the question states the variable 'prod-db-password' is stored in a variable group linked to Azure Key Vault, implying the variable group exists; if it did not, the error would be about the group not being found, not about secret access. Option D is wrong because if the secret name in Key Vault did not match, the pipeline would typically fail with a 'secret not found' error, not a 'cannot be accessed' error, and the variable group mapping would have been validated at creation time.

Full explanation →

324

Multi-Selecteasy

Which TWO are valid types of triggers for a YAML pipeline in Azure Pipelines? (Choose two.)

Select 2 answers

A.Push trigger

B.Scheduled trigger

C.Release trigger

D.PR trigger

E.Pipeline trigger

AnswersA, B

Correct. Push triggers are defined using the `trigger:` keyword and are the most common CI trigger.

Why this answer

A is correct because a push trigger in a YAML pipeline automatically starts a pipeline run when a push is made to a specified branch or tag. B is correct because scheduled triggers are also valid in YAML pipelines, allowing you to run a pipeline on a schedule defined using cron syntax. D (PR trigger) is also a valid YAML trigger, but the question asks for exactly two valid types; the intended correct pair is push and scheduled triggers.

Options C and E are not standard YAML trigger types in Azure Pipelines; release triggers are used in classic releases, and pipeline triggers are for triggering a pipeline from another pipeline, which is not a direct trigger type defined in the YAML file.

Exam trap

The trap is that candidates might think scheduled triggers cannot be configured in YAML (they can, using the `schedules:` keyword), or they might include PR triggers (which are valid but not one of the two expected correct answers in this question).

Full explanation →

325

MCQeasy

Your organization is adopting a trunk-based development strategy with short-lived feature branches. Which branch policy should you enforce to ensure that code is integrated frequently and conflicts are minimized?

A.Allow direct pushes to main branch for senior developers

B.Require a minimum number of reviewers and enforce a squash merge strategy

C.Create release branches for each production deployment

D.Require all merges to be fast-forward only

AnswerB

Requiring a minimum number of reviewers ensures every change is verified before merging to main, while squash merging compresses the feature branch's commit history into a single linear commit on the trunk. This maintains a coherent, reversible history and avoids merge noise, making main always deployable.

Why this answer

In a trunk-based development strategy with short-lived feature branches, the goal is to integrate code frequently and minimize merge conflicts. Requiring a minimum number of reviewers ensures code quality and team awareness, while enforcing a squash merge strategy collapses all feature branch commits into a single commit on the main branch, keeping the history linear and clean. This approach reduces the risk of complex merge conflicts and supports continuous integration by encouraging small, frequent merges.

Exam trap

The trap here is that candidates often confuse trunk-based development with GitFlow and choose option C (release branches), or they mistakenly think fast-forward-only merges (option D) are required for trunk-based strategies, when in fact squash merges are the recommended approach to maintain a clean, linear history.

How to eliminate wrong answers

Option A is wrong because allowing direct pushes to the main branch bypasses pull request reviews and branch policies, which undermines the trunk-based strategy's need for controlled, frequent integration and can lead to untested code and conflicts. Option C is wrong because creating release branches for each production deployment is a practice for GitFlow or release-based strategies, not trunk-based development, which focuses on keeping the main branch always deployable and avoids long-lived branches. Option D is wrong because requiring all merges to be fast-forward only would prevent merge commits entirely, making it impossible to enforce squash merges or maintain a clear history of feature integration; fast-forward merges are typically used with rebase strategies, not trunk-based development with short-lived branches.

Full explanation →

326

Multi-Selectmedium

Which TWO tools can be used to manage feature flags in Azure DevOps pipelines?

Select 2 answers

A.Azure Policy.

B.LaunchDarkly.

C.Azure App Configuration.

D.Azure Monitor.

E.Azure Key Vault.

AnswersB, C

LaunchDarkly is a widely adopted third-party feature management platform that supports feature flags, gradual rollouts, A/B testing, and real-time targeting across applications. It integrates with Azure DevOps for release pipelines, making it a valid tool for managing feature flags in Azure-hosted applications.

Why this answer

LaunchDarkly is a third-party feature management platform that integrates with Azure DevOps pipelines to control feature flag rollouts, targeting, and experimentation. It allows teams to toggle features on/off without redeploying code, making it a valid tool for managing feature flags in pipeline-driven deployments.

Exam trap

The trap here is that candidates may confuse Azure App Configuration's feature flag capability with Azure Policy or Azure Monitor, assuming any Azure service with 'configuration' or 'monitoring' in its name can manage feature flags, but only App Configuration and third-party tools like LaunchDarkly are designed for this purpose.

Full explanation →

327

MCQmedium

You are using GitHub Advanced Security. The security team wants to prevent developers from introducing code with high-severity vulnerabilities. What is the best way to enforce this?

A.Enable Dependabot and require pull request reviews for dependency updates

B.Enable code scanning and configure a quality gate to fail PRs with high-severity alerts

C.Enable push protection for all repositories

D.Enable secret scanning and block pushes with high-confidence secrets

AnswerB

This blocks PRs with high-severity code vulnerabilities.

Why this answer

Enabling code scanning with a quality gate that fails pull requests (PRs) on high-severity alerts directly prevents vulnerable code from being merged. This enforces security policy at the PR merge point, using GitHub's CodeQL analysis to detect vulnerabilities before they reach the main branch. Dependabot and secret scanning address different risks (outdated dependencies and leaked secrets) and do not block code with high-severity vulnerabilities.

Exam trap

The trap here is that candidates confuse Dependabot or secret scanning with code vulnerability prevention, but only code scanning with a quality gate directly blocks high-severity code vulnerabilities at the PR level.

How to eliminate wrong answers

Option A is wrong because Dependabot only automates dependency updates and requires PR reviews for those updates, but it does not scan custom code for vulnerabilities or block PRs based on severity. Option C is wrong because push protection prevents secrets from being pushed to repositories, not code vulnerabilities; it is a secret scanning feature, not a code quality gate. Option D is wrong because secret scanning blocks pushes with high-confidence secrets, which addresses credential leaks, not code vulnerabilities; it does not analyze code for security flaws.

Full explanation →

328

MCQeasy

You see the above YAML pipeline trigger configuration in an Azure Pipeline. The repository uses Git Flow with branches: feature/new-feature, develop, release/v1.0, and main. A developer pushes a commit to the branch feature/new-feature. Which action will trigger the pipeline?

A.A CI trigger will start because the branch name starts with 'feature/'.

B.No trigger will start.

C.A PR trigger will start because the branch name contains 'feature'.

D.A CI trigger will start for all branches because batch is set to true.

AnswerB

The push to feature/new-feature does not match any branch in the trigger include list, and the PR trigger only applies to PRs.

Why this answer

The YAML trigger configuration (shown) explicitly lists the branches that trigger CI. Since feature/new-feature is not included in the branch filter, a push to that branch does not start a CI run. PR triggers are separate and require an actual PR to be created, not a push.

Exam trap

Azure Pipelines triggers on all branches by default when no trigger block is specified. However, when a trigger block is present, only the listed branches trigger. Do not assume that a branch name containing 'feature' automatically triggers CI or PR.

In this question, the branch filter excludes feature/*, so no trigger starts.

How to eliminate wrong answers

Option A is wrong because a CI trigger only starts if the YAML pipeline explicitly includes a trigger section with 'feature/*' or the branch name matches a configured pattern; simply having a branch name starting with 'feature/' does not automatically trigger a pipeline. Option C is wrong because a PR trigger requires a configured 'pr' block in the YAML pipeline or a branch policy on the target branch; a push to a feature branch does not create a pull request, so no PR trigger fires. Option D is wrong because setting 'batch: true' only affects how multiple pending CI runs are batched when a trigger is already configured; it does not enable CI triggers for all branches.

Full explanation →

329

Multi-Selecthard

You are designing a YAML pipeline that builds a .NET application and publishes it as a NuGet package to Azure Artifacts. Which three tasks should you include in the build stage?

Select 3 answers

A.DotNetCoreCLI@2 with command 'build'

B.NuGetCommand@2 with command 'install'

C.DotNetCoreCLI@2 with command 'restore'

D.DotNetCoreCLI@2 with command 'push'

E.DotNetCoreCLI@2 with command 'pack'

AnswersA, C, E

DotNetCoreCLI@2 with command 'build' compiles the source code and produces assembly outputs, forming the foundational step in any .NET pipeline. It validates that code compiles successfully and generates the binary artifacts that subsequent tasks such as testing or packing will consume.

Why this answer

The DotNetCoreCLI@2 task with the 'build' command compiles the .NET application source code into intermediate language (IL) assemblies. This is a mandatory step after restoring dependencies and before packing the project into a NuGet package. Without a successful build, the subsequent pack and push operations would fail.

Exam trap

The trap here is that candidates often confuse the 'push' command as part of the build stage, but in Azure Pipelines, pushing to a feed is typically done in a separate stage or job to separate build artifacts from deployment actions.

Full explanation →

330

Multi-Selectmedium

Which THREE are valid ways to trigger a pipeline in Azure Pipelines using GitHub integration? (Choose three.)

Select 3 answers

A.GitHub App webhooks

B.Polling GitHub on a schedule

C.GitHub pull request events

D.GitHub branch push events

E.Azure Pipelines schedule trigger

AnswersA, C, D

Azure Pipelines uses a GitHub App to receive webhooks from GitHub; when the app is installed on a repository, GitHub sends an HTTP POST to Azure Pipelines for events such as push or pull request, automatically triggering the pipeline without any polling.

Why this answer

GitHub App webhooks are the primary integration mechanism for Azure Pipelines with GitHub. When you configure a GitHub App connection in Azure Pipelines, it registers webhooks that listen for specific GitHub events (like push and pull request) and automatically triggers pipeline runs in real-time without polling.

Exam trap

The trap here is that candidates may confuse general pipeline triggers (like scheduled triggers) with GitHub-specific integration triggers, or assume that polling is a fallback method when webhooks fail, but Azure Pipelines does not support polling for GitHub repositories.

Full explanation →

331

MCQhard

Refer to the exhibit. You apply this Azure Policy to a subscription. A developer attempts to deploy a VM with SKU Standard_D2s_v3. What is the result?

A.The deployment is denied only if the VM is in a specific resource group.

B.The deployment is denied because the SKU matches the pattern.

C.The deployment is allowed because the SKU matches the pattern.

D.The deployment is allowed and a non-compliance event is logged.

AnswerC

Under a policy with the 'deny' effect, any deployment that satisfies the condition—VM type 'Microsoft.Compute/virtualMachines' and SKU name starting with 'Standard_D'—is blocked at deployment time. Matching the pattern triggers the deny action, not approval or allowance.

Why this answer

The policy uses a deny effect with a notMatch condition on the VM SKU field, matching the pattern 'Standard_D*'. Since the attempted SKU 'Standard_D2s_v3' matches the pattern, the condition evaluates to false, so the deny effect does NOT apply. The deployment is allowed.

The 'deny' effect only blocks when the condition is true, which would be for SKUs that do NOT match the pattern.

Exam trap

Candidates often confuse the 'match' and 'notMatch' conditions. A 'notMatch' condition denies only when the field does NOT match the pattern, while a 'match' condition denies when it DOES match. Here, the SKU matches, so the deployment is allowed.

How to eliminate wrong answers

Option A is wrong because the policy applies to the entire subscription scope, not a specific resource group, and the 'deny' effect is unconditional based on the SKU pattern match. Option C is wrong because the policy uses a 'deny' effect, not 'audit' or 'append', so matching the pattern results in denial, not allowance. Option D is wrong because the 'deny' effect blocks the deployment and does not allow it with a non-compliance log; only 'audit' or 'disabled' effects would log without blocking.

Full explanation →

332

Matchingmedium

Match each Azure Monitor feature to its use case.

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

Concepts

Matches

Application performance monitoring and diagnostics

Query and analyze log data from various sources

Visualize performance metrics from Azure resources

Proactive notifications based on conditions

Why these pairings

The correct matches are Log Analytics for log collection and querying, Application Insights for live web application monitoring, and Azure Monitor Metrics for numeric performance data. The distractors swap the definitions of Log Analytics and Application Insights.

Full explanation →

333

MCQmedium

You are designing a release pipeline for a containerized application deployed to Azure Kubernetes Service (AKS). You want to implement a strategy where the new version is deployed to a small subset of pods first, and if healthy, gradually rolled out to all pods. Which Kubernetes deployment strategy should you use?

A.Canary deployment

B.Rolling update

C.Blue-green deployment

D.Recreate deployment

AnswerA

Canary deployment is the correct choice because it deploys the new containerized app version to a small subset of users or servers first, then gradually shifts traffic based on health checks and metrics. This allows you to validate the new version in production with minimal risk, automatically rolling back if errors or performance degradation are detected, before exposing it to the full user base.

Why this answer

A canary deployment is the correct strategy because it allows you to route a small percentage of traffic (e.g., 5%) to the new version of the application running on a subset of pods in AKS. If the canary is healthy (e.g., passes liveness and readiness probes), you can gradually increase the traffic percentage until 100% of pods run the new version, providing controlled rollout and rollback capabilities.

Exam trap

The trap here is confusing a rolling update with a canary deployment; while both are gradual, a rolling update does not provide traffic splitting or controlled subset exposure, which is the key requirement for a canary strategy.

How to eliminate wrong answers

Option B (Rolling update) is wrong because it replaces pods incrementally without the ability to route a controlled subset of traffic to the new version; it updates all pods over time but does not support fine-grained traffic splitting or canary analysis. Option C (Blue-green deployment) is wrong because it involves running two full environments (blue and green) and switching all traffic at once via a service selector update, not a gradual subset rollout. Option D (Recreate deployment) is wrong because it terminates all existing pods before creating new ones, causing downtime and no gradual rollout.

Full explanation →

334

Multi-Selecthard

Your organization is implementing a security compliance plan for Azure DevOps. Which TWO actions should you take to ensure that only authorized users can modify build pipelines?

Select 2 answers

A.Require all users to use Personal Access Tokens (PATs)

B.Configure branch policies to require reviews for changes to pipeline YAML files

C.Set pipeline permissions to restrict editing to specific security groups

D.Enable audit logging for all pipeline changes

E.Enable OpenID Connect (OIDC) for pipeline authentication

AnswersB, C

Configuring branch policies on the repository that contains your pipeline YAML files requires pull request reviews, successful builds, and approved changes before merging, directly enforcing mandatory peer review. This is a preventive control that ensures any change to pipeline definitions is vetted, making it the correct answer for a security compliance plan.

Why this answer

Branch policies in Azure Repos enforce required reviews for changes to YAML pipeline files stored in the repository. This ensures that any modification to the pipeline definition must be approved by authorized reviewers before merging, preventing unauthorized or accidental changes. Option C is correct because pipeline permissions in Azure DevOps allow you to restrict editing of a pipeline to specific security groups (e.g., 'Build Administrators'), directly controlling who can modify the pipeline through the web interface or API.

Exam trap

The trap here is that candidates often confuse authentication mechanisms (PATs, OIDC) with authorization controls, or mistake auditing (detective) for prevention, leading them to select options that do not actually restrict who can modify pipelines.

Full explanation →

335

Multi-Selecteasy

Which TWO practices help improve the efficiency of code reviews? (Choose two.)

Select 2 answers

A.Keep pull requests small and focused on a single change.

B.Include multiple unrelated changes in a single pull request to reduce the number of PRs.

C.Assign as many reviewers as possible to ensure thoroughness.

D.Require that all team members review every pull request.

E.Use a code review checklist to ensure common issues are checked.

AnswersA, E

Small, single-purpose pull requests reduce cognitive load for reviewers, allowing them to understand context quickly and catch defects more effectively. They also simplify rollbacks, bisecting regressions, and reducing merge conflicts, which shortens cycle time and accelerates feedback.

Why this answer

Keeping pull requests small and focused on a single change (Option A) improves code review efficiency because it reduces cognitive load on reviewers, allowing them to understand and evaluate the change quickly without context-switching. Smaller PRs also enable faster feedback loops and easier rollback if issues are found, which aligns with DevOps principles of continuous integration and delivery.

Exam trap

The trap here is that candidates may think more reviewers or requiring all team members to review ensures quality, but in practice, it reduces efficiency and accountability, while small, focused PRs and checklists are proven to improve both speed and accuracy.

Full explanation →

336

MCQhard

Your team uses GitHub Actions for CI/CD. You need to ensure that secrets used in workflows are automatically rotated every 90 days. What is the best approach?

A.Use OpenID Connect (OIDC) to authenticate.

B.Use a script that calls the GitHub API to update the secret and run it in a scheduled workflow.

C.Manually update the secrets every 90 days.

D.Store secrets as environment secrets and configure expiration.

AnswerB

Automating rotation with a scheduled GitHub Actions workflow that calls the GitHub API is the correct approach: the workflow can generate a new secret value, call the Secrets API (for repository or environment secrets), and update the secret on a defined cadence. This ensures secrets are rotated programmatically without manual intervention, aligning with the requirement for automated periodic rotation.

Why this answer

It uses the GitHub API within a scheduled workflow to programmatically rotate secrets, ensuring automation without manual intervention. This approach directly addresses the requirement for automatic rotation every 90 days by generating new secret values and updating the repository or organization secrets via the API.

Exam trap

The trap here is that candidates may confuse OIDC with secret management, assuming it provides rotation capabilities, when in fact OIDC only handles authentication without any secret lifecycle management.

How to eliminate wrong answers

Option A is wrong because OpenID Connect (OIDC) is used for authentication between GitHub Actions and cloud providers, not for rotating secrets stored in GitHub; it does not provide a mechanism to update or rotate secrets. Option C is wrong because manually updating secrets every 90 days is error-prone, not automated, and violates the requirement for automatic rotation. Option D is wrong because GitHub does not support environment secrets with a configurable expiration date; secrets do not have a built-in expiration feature, and this option misrepresents the platform's capabilities.

Full explanation →

337

MCQhard

You have the YAML pipeline exhibit above. The pipeline fails with: 'The pipeline is not valid. Could not find the template file shared-templates/build-steps.yml.' What is the most likely cause?

A.The checkout step for 'shared-templates' must be before the template reference, which it is.

B.The template file is missing from the shared-templates repository.

C.The template path is incorrect because it should be relative to the repository root; the repository name is 'myorg/shared-templates', so the path should be 'build-steps.yml'.

D.The ref 'refs/heads/main' does not exist in the shared-templates repository.

AnswerC

The path 'shared-templates/build-steps.yml' suggests that the template is in a subfolder, but the repository root is already 'shared-templates'.

Why this answer

When referencing a template from another repository in Azure Pipelines, the `repository` property specifies the repository name (e.g., `myorg/shared-templates`), and the template path must be relative to the root of that repository. The error indicates the pipeline cannot find the file, meaning the path `shared-templates/build-steps.yml` is incorrect; it should be just `build-steps.yml` since the repository name is already declared in the `repository` field. The path should not include the repository name again.

Exam trap

The trap here is that candidates often assume the template path must include the repository name or folder structure, when in fact the path is relative to the root of the repository specified in the `repository` field, leading to a common mistake of over-specifying the path.

How to eliminate wrong answers

Option A is wrong because the checkout step for 'shared-templates' is not required before the template reference; Azure Pipelines automatically fetches the referenced repository when the template is resolved, so the order of checkout steps does not affect template resolution. Option B is wrong because the error message specifically says 'Could not find the template file', which implies the file exists but the path is incorrect; if the file were missing, the error would be different (e.g., 'File not found' or a similar message). Option D is wrong because the error message does not mention a ref issue; if the ref 'refs/heads/main' did not exist, the error would indicate a failure to resolve the branch or commit, not a missing template file.

Full explanation →

338

MCQmedium

You have a release pipeline that deploys to multiple stages (Dev, QA, Prod). You want to automatically deploy to Dev and QA after a successful build, but require a manual approval for Prod. Which deployment strategy should you use?

A.Set pre-deployment approvals on the Dev and QA stages.

B.Set pre-deployment approvals on the Prod stage.

C.Use a post-deployment approval on the QA stage.

D.Disable the automatic trigger for all stages.

AnswerB

Pre-deployment approvals on the Prod stage create a manual authorization checkpoint before the production deployment begins. This satisfies the requirement for a human approval step prior to releasing to production while still allowing dev and QA deployments to run automatically, matching the specified workflow.

Why this answer

Pre-deployment approvals control whether a release can start deploying to a stage. By setting a pre-deployment approval on the Prod stage only, Dev and QA will deploy automatically (since they have no approval requirement), while Prod requires manual sign-off before deployment begins. This matches the requirement exactly.

Exam trap

The trap here is confusing pre-deployment approvals with post-deployment approvals, leading candidates to think a post-deployment approval on QA can gate Prod, when in fact only pre-deployment approvals on the target stage (Prod) can prevent its deployment from starting.

Why the other options are wrong

That would require approval for Dev and QA, not Prod.

Post-deployment approvals occur after deployment, not before.

That would stop all automatic deployments.

Full explanation →

339

Multi-Selectmedium

Your team is implementing a security and compliance plan for Azure DevOps. Which TWO actions should you take to meet regulatory requirements for audit logging and access control?

Select 2 answers

A.Enable anonymous access to project boards for external stakeholders.

B.Enable Azure DevOps audit log to track changes to security policies and user permissions.

C.Configure Azure AD Conditional Access policy to require multi-factor authentication for Azure DevOps.

D.Grant all users Project Collection Administrator role to simplify access management.

E.Disable auditing for the project to reduce log volume.

AnswersB, C

Audit logs are essential for compliance tracking.

Why this answer

Enabling the Azure DevOps audit log (option B) is essential for regulatory compliance because it records changes to security policies, user permissions, and other critical events, providing an immutable trail for forensic analysis and reporting. This directly meets audit logging requirements by capturing who did what and when, which is necessary for standards like SOC 2, ISO 27001, or GDPR.

Exam trap

Microsoft often tests the misconception that enabling anonymous access or simplifying permissions (like granting admin roles to all users) is acceptable for compliance, when in fact these actions directly violate audit logging and access control requirements.

Full explanation →

340

Multi-Selectmedium

Your team uses Azure DevOps and needs to ensure that secrets are not exposed in pipeline logs. Which THREE practices should you implement?

Select 3 answers

A.Use logging commands to mask secrets in scripts

B.Enable pipeline log encryption

C.Mark variables as 'secret' in pipeline variables

D.Store secrets in YAML variable files

E.Use Azure Key Vault to store secrets

AnswersA, C, E

Logging commands like '##vso[task.setvariable]' can mask output.

Why this answer

Azure DevOps provides a logging command, `##vso[task.setvariable variable=mySecret;isSecret=true]value`, which masks the variable's value in pipeline logs. This ensures that even if a script echoes the secret, it is replaced with asterisks, preventing accidental exposure during execution.

Exam trap

The trap here is that candidates confuse log masking with encryption, assuming that enabling 'pipeline log encryption' is a real Azure DevOps feature, when in fact the platform relies on secret variable masking and Azure Key Vault integration for secret management.

Full explanation →

341

MCQhard

You are designing a release strategy for a critical application that must maintain high availability. You decide to use Azure Traffic Manager to route traffic between deployments in two Azure regions. Your release pipeline deploys the application to the secondary region first, then switches Traffic Manager priority to route traffic to the secondary region while the primary region is updated. This strategy is known as:

A.Blue-green deployment

B.Canary deployment

C.Red/Black deployment

D.Rolling deployment across regions

AnswerA

Blue-green deployment uses two identical environments (blue and green) with only one serving production traffic at a time, and a router instantly switches between them. This is a single-region or same-site technique that does not provide cross-region failover or disaster recovery, so it does not meet the cross-region requirement.

Why this answer

This strategy is a blue-green deployment because it uses two complete environments (primary and secondary regions). The new version is deployed to the secondary (green) environment first, then Traffic Manager priority routing switches all traffic from the primary (blue) to the secondary (green). The primary is then updated while idle.

This is the classic blue-green pattern applied across regions, not a rolling deployment.

Exam trap

The trap is that candidates may confuse this with rolling deployment because updates happen in stages. However, rolling deployment updates instances incrementally and gradually shifts traffic, whereas blue-green deployment performs an immediate all-or-nothing traffic switch between two pre-deployed environments. Traffic Manager priority routing is a failover/blue-green switch, not a gradual rolling shift.

How to eliminate wrong answers

Option A is wrong because blue-green deployment involves maintaining two identical environments (blue and green) and switching traffic between them instantly, not sequentially updating one region while the other serves traffic. Option B is wrong because canary deployment routes a small percentage of traffic to a new version to validate it before a full rollout, not a full region switch with priority routing. Option C is wrong because red/black deployment is another term for blue-green deployment, where the old version (red) is replaced entirely by the new version (black) after validation, not a rolling update across regions.

Full explanation →

342

MCQmedium

A team uses a monorepo in Azure Repos. They want to implement a build validation policy that only triggers builds for code changes in specific folders to reduce build times. Which approach should they use?

A.Use a manual trigger and have developers specify which folder to build.

B.Create separate YAML pipelines for each folder and configure branch policies to require all pipelines.

C.Configure the build policy in Azure Repos with a path filter to limit which folders trigger the policy.

D.Configure path filters in the pipeline trigger to include only the changed folder.

AnswerC

Path filters in build validation policies affect only PR validation builds and do not control CI triggers. Additionally, the policy's path filter only determines whether the build is required for the PR; it does not prevent the pipeline from being triggered by other means. To limit builds to specific folders for all triggers, path filters should be configured in the pipeline trigger itself (as in option D).

Why this answer

Azure Repos build validation policies allow you to specify path filters when configuring the policy. These path filters restrict when the policy requires a build, based on the files changed in the pull request. By setting the path filter to the specific folders of interest, the build validation only triggers for changes in those folders, directly reducing build times for unrelated changes.

Pipeline trigger path filters (Option D) control CI builds on push, not the build validation policy for pull requests.

Exam trap

Candidates often confuse branch policy path filters with pipeline trigger path filters. Build validation policies are configured in Azure Repos branch policies and support path filters that apply specifically to pull request validations. Pipeline trigger path filters (in YAML) control when a pipeline runs on push CI, but they do not configure the build validation policy itself.

How to eliminate wrong answers

Option A is wrong because a manual trigger defeats the purpose of an automated build validation policy; it relies on developers remembering to trigger builds, which is error-prone and not scalable. Option B is wrong because requiring all separate pipelines via branch policies would cause every pipeline to run on any change, negating the goal of reducing build times and creating unnecessary overhead. Option C is wrong because Azure Repos branch policies do not support path filters for build validation; path filters are a feature of pipeline triggers, not branch policy configuration.

Full explanation →

343

Multi-Selecteasy

Which TWO practices should you follow to ensure compliance with regulatory requirements (e.g., PCI DSS) when using Azure DevOps? (Choose two.)

Select 2 answers

A.Manually track changes to pipelines in a spreadsheet.

B.Allow all users to create and modify pipelines without restrictions.

C.Enable Azure DevOps audit logging to track changes to pipelines and policies.

D.Disable audit logging to reduce storage costs.

E.Use branch policies to enforce code reviews and approvals for all changes.

AnswersC, E

Enabling Azure DevOps audit logging captures an immutable, timestamped record of pipeline and policy changes, which is essential evidence for compliance audits, enables detection of unauthorized modifications, and supports security investigations.

Why this answer

Azure DevOps audit logging captures a detailed, immutable record of changes to pipelines, policies, and other critical resources, which is essential for demonstrating compliance with frameworks like PCI DSS that require evidence of who made what change and when. Audit logs can be exported to SIEM tools or retained for forensic analysis, satisfying the 'audit trail' requirement without manual intervention. Additionally, using branch policies enforces mandatory code reviews and approvals for changes, ensuring that all modifications go through a controlled, auditable process.

Together, these practices provide both the immutable audit trail and the controlled change management required for regulatory compliance.

Exam trap

The trap here is that candidates may confuse 'audit logging' with a cost-saving measure (Option D) or think manual tracking (Option A) is acceptable, while the exam expects you to recognize that automated, immutable audit trails and enforced branch policies are the only reliable ways to meet regulatory compliance in a DevOps context.

Full explanation →

344

Multi-Selectmedium

Your organization uses GitHub and wants to ensure that all commits to the main branch are associated with a GitHub issue. Which three settings should you configure?

Select 2 answers

A.Require conversation resolution before merging

B.Require status checks to pass before merging

C.Allow force pushes

D.Require pull request reviews before merging

E.Allow deletions

AnswersB, D

Requiring status checks to pass before merging is correct because you can configure a custom status check that verifies a pull request references an issue, directly ensuring association.

Why this answer

Requiring status checks to pass before merging can include a custom status check that validates that a pull request is linked to a GitHub issue, directly enforcing association. Option D is correct because requiring pull request reviews before merging forces all changes to go through a pull request, which must be linked to a GitHub issue to satisfy the review process, ensuring traceability. Option A is incorrect because requiring conversation resolution only ensures comments are resolved, not that commits are associated with an issue.

Options C and E are irrelevant to issue association.

Exam trap

The trap here is that candidates may think 'Require conversation resolution before merging' ensures issue association, but it only resolves PR discussions. The correct combination involves status checks (custom) and pull request reviews to enforce linking.

Full explanation →

345

MCQhard

You have a multi-stage YAML pipeline that builds and deploys a containerized application to Azure Kubernetes Service (AKS). The build stage runs successfully, but the deploy stage fails with an error: 'Error: failed to get credentials: context deadline exceeded'. You verify that the AKS cluster is running and that the service connection is valid. What is the most likely cause?

A.The Azure service connection has expired.

B.The service principal used by the pipeline does not have RBAC permissions on the cluster.

C.The container registry is not accessible from the build agent.

D.The build agent's IP address is not allowed by the AKS cluster's network policies.

AnswerD

If the build agent's public IP address is not included in the AKS cluster's authorized IP ranges (a feature of the API server access profile), the API server will silently drop packets, causing the pipeline to hang until the connection times out. This matches the symptom precisely, making it the correct cause among the given options.

Why this answer

The error 'context deadline exceeded' when running `az aks get-credentials` indicates a network timeout, not an authentication or permission failure. Since the AKS cluster is running and the service connection is valid, the most likely cause is that the build agent's IP address is blocked by AKS network policies (e.g., authorized IP ranges or a firewall), preventing the agent from reaching the cluster's API server within the default timeout.

Exam trap

The trap here is that candidates confuse network-level connectivity errors (timeout) with authentication or authorization errors, leading them to incorrectly select options about expired service connections or RBAC permissions.

How to eliminate wrong answers

Option A is wrong because the error 'context deadline exceeded' is a network timeout, not an authentication error; an expired service connection would produce a different error (e.g., '401 Unauthorized' or 'credentials not found'). Option B is wrong because insufficient RBAC permissions would result in a '403 Forbidden' error when attempting to access cluster resources, not a timeout. Option C is wrong because the build stage (which builds and pushes the container image) already succeeded, proving the container registry is accessible from the build agent.

Full explanation →

346

Multi-Selecteasy

Which THREE are common Git branching strategies used by development teams? (Select THREE.)

Select 3 answers

A.GitFlow

B.Trunk-based development

C.Feature branching

D.Monorepo

E.Centralized version control

AnswersA, B, C

GitFlow is a branching model that maintains a long-lived develop branch alongside main, with feature branches for new work, release branches for staging, and hotfix branches for urgent fixes, providing strict release management and clear role separation.

Why this answer

GitFlow is a common branching strategy that uses a main branch (master/main) alongside develop, feature, release, and hotfix branches. It provides a structured model for managing releases, hotfixes, and parallel development, making it suitable for projects with scheduled release cycles.

Exam trap

The trap here is confusing repository management strategies (like monorepo) or version control system types (like centralized VCS) with actual Git branching strategies, leading candidates to select options that describe storage or system architecture rather than branch workflows.

Full explanation →

347

MCQhard

Your team is migrating from TFVC to Git in Azure Repos. Developers frequently work on the same files simultaneously. Which Git workflow should you recommend to minimize merge conflicts?

A.GitFlow

B.Forking workflow

C.Feature branch workflow

D.Centralized workflow

AnswerC

Short-lived feature branches merged frequently reduce conflicts.

Why this answer

The feature branch workflow is ideal for minimizing merge conflicts when developers work on the same files simultaneously because each developer creates a short-lived branch off the main branch for their specific feature or fix, commits frequently, and merges back via pull requests. This isolates changes until they are ready, reducing the surface area for conflicts compared to long-lived branches. Git's merge or rebase strategies within this workflow allow for incremental conflict resolution, which is more manageable than resolving large conflicts from divergent histories.

Exam trap

The trap here is that candidates often confuse GitFlow's structured branching model with being conflict-minimizing, when in fact its long-lived branches increase conflict risk, while the simpler feature branch workflow with frequent integration is more effective for simultaneous edits.

How to eliminate wrong answers

Option A is wrong because GitFlow introduces long-lived branches (develop, release, hotfix) that can diverge significantly, increasing the likelihood of merge conflicts when multiple developers work on the same files simultaneously. Option B is wrong because the forking workflow is designed for open-source contributions where contributors don't have direct repository access; it adds overhead of managing forks and cross-repo synchronization, which doesn't inherently minimize merge conflicts for a team with direct access. Option D is wrong because the centralized workflow mimics TFVC by having all developers commit directly to a single branch (e.g., main), which maximizes the chance of merge conflicts when multiple people edit the same files concurrently, as there is no isolation of changes.

Full explanation →

348

MCQhard

Refer to the exhibit. You are reviewing an Azure DevOps YAML pipeline. The pipeline is configured with a webhook trigger from GitHub for pull request opened events. However, the pipeline does not trigger when a PR is opened. What is the most likely cause?

A.The webhook subscription is not configured in GitHub.

B.The webhook name does not match the service connection.

C.The pipeline lacks an agent pool specification.

D.The webhook filter is incorrect; 'opened' should be 'created'.

AnswerA

The YAML defines the webhook, but GitHub needs to be configured to send events to Azure DevOps.

Why this answer

The most likely cause is that the webhook subscription is not configured in GitHub. Azure DevOps YAML pipelines with webhook triggers require an explicit webhook to be set up in the GitHub repository to send events (like pull request opened) to Azure DevOps. Without this subscription, Azure DevOps never receives the event, so the pipeline cannot trigger.

Exam trap

The trap here is that candidates assume the YAML webhook trigger definition alone is sufficient, but Azure DevOps requires the external webhook subscription to be manually configured in GitHub, which is a common misconfiguration in real-world scenarios.

How to eliminate wrong answers

Option B is wrong because the webhook name is not a required field for GitHub webhooks; Azure DevOps identifies the webhook via the service connection and the payload URL, not a name. Option C is wrong because the absence of an agent pool specification would cause a pipeline failure at runtime (e.g., 'No agent found'), not prevent the pipeline from triggering on a webhook event. Option D is wrong because 'opened' is the correct event type for a pull request being opened in GitHub's webhook payload; 'created' is not a valid pull request event type (it is used for branches or tags).

Full explanation →

349

MCQmedium

Your team uses GitHub. You need to automatically remove a user's access to all repositories when they leave the company. What is the most efficient approach?

A.Assign the user to a 'Leaver' team and remove all repository permissions

B.Manually remove the user from each repository

C.Configure SAML single sign-on (SSO) with Microsoft Entra ID

D.Enable SCIM provisioning from Microsoft Entra ID to GitHub

AnswerD

Enabling SCIM provisioning from Microsoft Entra ID to GitHub is the correct solution because SCIM automatically creates, updates, and deactivates GitHub user accounts based on Entra ID group membership, so when a user is removed from the source group or disabled in Entra ID, GitHub automatically revokes their access without manual intervention.

Why this answer

SCIM (System for Cross-domain Identity Management) provisioning from Microsoft Entra ID to GitHub automates user lifecycle management. When a user is disabled or removed from Entra ID, SCIM automatically deprovisions their access across all GitHub resources, including repositories, without manual intervention. This is the most efficient approach because it is event-driven and scales to thousands of users.

Exam trap

The trap here is that candidates confuse SAML SSO (which only handles authentication) with SCIM (which handles provisioning), leading them to choose SAML as the solution for deprovisioning access.

How to eliminate wrong answers

Option A is wrong because assigning a user to a 'Leaver' team and removing repository permissions is a manual, error-prone process that does not scale and does not leverage automated identity lifecycle management. Option B is wrong because manually removing the user from each repository is inefficient, time-consuming, and prone to human error, especially in large organizations with many repositories. Option C is wrong because SAML SSO only controls authentication (who can sign in) but does not automatically deprovision access to repositories when a user is removed from the identity provider; it requires additional SCIM provisioning to synchronize group membership and access rights.

Full explanation →

350

MCQhard

A company uses Azure Pipelines to build a .NET Core application. The build takes 45 minutes due to dependency restoration. They want to reduce build time. What is the most effective strategy?

A.Cache the NuGet packages and enable caching in the pipeline

B.Use parallel jobs in the pipeline

C.Use a self-hosted agent with more CPU

D.Enable incremental builds

AnswerA

The `DotNetCoreCLI`/`NuGetCommand` task with caching uses a cache key derived from the NuGet.config and the project files (or the packages.lock.json), and stores the global packages folder (`~/.nuget/packages`) on the Azure DevOps server. On a cache hit, `dotnet restore` can satisfy package references from the local cache rather than downloading them, cutting restore time from tens of seconds to near zero. The cache is restored to the agent workspace at job startup, so it works across pipeline runs even on hosted agents, which are ephemeral. This directly addresses the network bottleneck that caused the slow builds.

Why this answer

Caching NuGet packages in Azure Pipelines is the most effective strategy because dependency restoration is the primary bottleneck, often downloading hundreds of packages from nuget.org. By caching the ~/.nuget/packages folder, subsequent builds skip the network download entirely, reducing the 45-minute build time to minutes. This directly addresses the root cause—repetitive package restoration—without requiring additional infrastructure or parallelism.

Exam trap

The trap here is that candidates confuse 'parallel jobs' or 'faster agents' with solving a network-bound dependency restoration problem, when caching is the only strategy that eliminates the repeated download of unchanged packages.

How to eliminate wrong answers

Option B is wrong because parallel jobs distribute work across multiple agents but do not eliminate the redundant dependency restoration step; each parallel job would still spend 45 minutes restoring packages independently. Option C is wrong because a self-hosted agent with more CPU does not address the network-bound dependency restoration; the bottleneck is I/O and network latency, not CPU. Option D is wrong because incremental builds only skip recompiling unchanged code, but dependency restoration is a separate step that runs before compilation; incremental builds do not cache NuGet packages.

Full explanation →

351

MCQhard

You are reviewing a branch protection rule JSON for a GitHub repository. Developers complain that they cannot merge pull requests. What is the most likely cause?

A.The signed commit requirement is enforced but developers are not signing commits.

B.The required approving review count is set to 1.

C.Rebase merging is disabled.

D.Squash merge is the only allowed method.

AnswerA

The branch protection rule enforces signed commits, meaning any push containing unsigned commits will be rejected by GitHub. Because developers are not signing their commits, every push fails the signing requirement, which explains the blocked merges despite other settings being valid.

Why this answer

When a branch protection rule requires signed commits, any pull request containing unsigned commits will be blocked from merging. GitHub verifies commit signatures using GPG or S/MIME, and if developers are not signing their commits, the merge will fail regardless of other settings.

Exam trap

The trap here is that candidates often confuse branch protection rules that block merging (like required signed commits or required status checks) with settings that merely affect merge options (like disabling rebase or restricting merge methods), leading them to incorrectly choose options that do not actually prevent merging.

How to eliminate wrong answers

Option B is wrong because a required approving review count of 1 is a common and valid setting that allows merging once at least one reviewer approves; it does not block merging by itself. Option C is wrong because disabling rebase merging only removes one merge method option but does not prevent merging via other allowed methods like merge commit or squash merge. Option D is wrong because restricting to squash merge only limits the merge strategy but still allows pull requests to be merged as long as other conditions (like reviews or status checks) are met.

Full explanation →

352

MCQeasy

You are implementing a CI pipeline for a Node.js application. The pipeline must run linting, unit tests, and build the application. Which YAML structure is most appropriate?

A.Define three separate stages: lint, test, build.

B.Define one job with parallel steps using 'parallel' keyword.

C.Define multiple jobs without dependencies.

D.Define one job with multiple steps: lint, test, build.

AnswerD

A single job with multiple sequential steps is the simplest and fastest CI approach for a Node.js application, as it runs in one workspace with no inter-job communication overhead. Each step executes in order, automatically stopping the pipeline on the first failure, and step outputs are directly available to subsequent steps.

Why this answer

A CI pipeline for a Node.js application typically runs linting, unit tests, and build sequentially within a single job using multiple steps. This ensures that each step executes in order, sharing the same workspace and environment, which is efficient for a simple CI workflow. Defining separate stages (Option A) or multiple jobs (Option C) adds unnecessary overhead and complexity for tasks that are inherently sequential and do not require independent environments.

Exam trap

The trap here is that candidates often confuse the need for separate stages or jobs with the concept of modularity, not realizing that for a simple sequential CI workflow, a single job with multiple steps is the most efficient and appropriate structure.

How to eliminate wrong answers

Option A is wrong because defining three separate stages (lint, test, build) introduces unnecessary pipeline orchestration overhead and potential delays due to stage-level artifact passing, which is not needed for a simple CI workflow where all steps can run sequentially in the same job. Option B is wrong because the 'parallel' keyword in Azure DevOps YAML runs steps concurrently, which would cause linting, tests, and build to execute simultaneously, leading to race conditions and potential failures (e.g., build starting before linting completes). Option C is wrong because defining multiple jobs without dependencies allows them to run in parallel by default, which again breaks the required sequential order (lint → test → build) and may cause build to run before linting or tests pass.

Full explanation →

353

MCQhard

Your Azure Pipeline builds a Docker image and pushes it to Azure Container Registry (ACR). You need to ensure that the image is scanned for vulnerabilities before being pushed. Which task should you add to the pipeline?

A.Azure CLI task to run 'az acr scan'

B.Docker task with the 'push' action

C.Container scanning task from Microsoft Defender for Cloud

D.PublishBuildArtifacts task

AnswerC

The Container scanning task from Microsoft Defender for Cloud is a dedicated Azure DevOps task that integrates with Microsoft Defender for Cloud to scan container images for vulnerabilities, including OS packages and language-specific dependencies. It can be configured to run after a successful push to Azure Container Registry, providing actionable security findings and can fail the pipeline if critical vulnerabilities are detected.

Why this answer

Microsoft Defender for Cloud provides a dedicated container scanning task that integrates directly into Azure Pipelines to scan Docker images for vulnerabilities before they are pushed to ACR. This task leverages the same vulnerability assessment engine used by Microsoft Defender for Cloud to identify CVEs in OS packages and application dependencies, ensuring only compliant images are pushed.

Exam trap

The trap here is that candidates may confuse the Azure CLI task with a hypothetical 'az acr scan' command, or assume the Docker push action inherently includes security scanning, when in fact Microsoft Defender for Cloud provides a dedicated task for that purpose.

How to eliminate wrong answers

Option A is wrong because 'az acr scan' is not a valid Azure CLI command; ACR uses the 'az acr task' or 'az acr run' commands for scanning, but vulnerability scanning is performed by Defender for Cloud, not a direct CLI command. Option B is wrong because the Docker task with the 'push' action only pushes the image to ACR without any built-in vulnerability scanning; it does not invoke any security assessment. Option D is wrong because the PublishBuildArtifacts task publishes build artifacts to Azure Pipelines or a file share, and has no capability to scan container images for vulnerabilities.

Full explanation →

354

MCQhard

Your organization uses GitHub for code and GitHub Actions for CI/CD. You want to enforce that all workflows include a 'codeql-analysis' job for security scanning. What is the best approach?

A.Create a workflow template and add it to the organization's workflow templates directory

B.Use branch protection rules to require a status check named 'codeql-analysis'

C.Create a custom GitHub Action that runs CodeQL and require it in all workflows

D.Use GitHub's required workflows feature to mandate specific workflows

AnswerD

GitHub's required workflows feature (in public beta for organizations) lets administrators designate a workflow file in a central repository that is automatically created in all repositories and cannot be removed or modified by users; this ensures CodeQL scanning runs consistently across every repository in the organization.

Why this answer

GitHub's required workflows feature allows organization owners to enforce that specific workflows (like a CodeQL analysis) run on all repositories in the organization, ensuring consistent security scanning without relying on templates or manual setup. This is the only approach that centrally mandates the workflow's presence and execution across all repositories, even if developers create new workflows or modify existing ones.

Exam trap

The trap here is that candidates often confuse 'workflow templates' (which are optional) with 'required workflows' (which are mandatory), or they mistakenly believe that branch protection rules can enforce the existence of a workflow job, when in fact they only enforce the outcome of a status check that may not even be configured.

How to eliminate wrong answers

Option A is wrong because workflow templates are optional starting points that developers can choose to use or ignore; they do not enforce that every repository includes the 'codeql-analysis' job. Option B is wrong because branch protection rules require a status check to pass on pull requests, but they do not ensure the workflow itself exists in the repository—developers could omit the CodeQL job entirely and the branch protection would have no effect. Option C is wrong because creating a custom GitHub Action does not enforce its inclusion in all workflows; developers would still need to manually add it to each workflow file, and there is no mechanism to require its use across the organization.

Full explanation →

355

MCQmedium

Your team uses GitFlow with Azure Repos. You need to ensure that every commit to the 'main' branch is built and deployed to production automatically. Which trigger should you configure in your YAML pipeline?

A.Trigger: none

B.trigger: branches: include: - main

C.schedules: - cron: "0 0 * * *" branches: include: - main

D.pr: branches: include: - main

AnswerB

This YAML defines a continuous integration trigger on the `main` branch, causing Azure Pipelines to automatically queue a new run whenever a commit is pushed to `main`. Because GitFlow's main branch is the integration branch for releases and hotfixes, this ensures every commit that lands on main is validated by the pipeline.

Why this answer

A branch-specific trigger defined with `trigger: branches: include: - main` will automatically run the pipeline on every commit to the 'main' branch. Option A is wrong because `trigger: none` disables CI triggers entirely, so the pipeline will not start on any commits. Option C is wrong because a scheduled trigger (`schedules:`) runs the pipeline at specific times, not in response to commits.

Option D is wrong because a PR trigger (`pr:`) runs the pipeline when a pull request is created or updated, not on direct commits to 'main'.

Full explanation →

356

MCQhard

Your release pipeline deploys to Azure App Service using deployment slots. You need to ensure that traffic is gradually shifted to the new slot over 30 minutes, and if performance issues occur, it should automatically roll back. Which deployment strategy should you implement?

A.Use the 'Deploy to Azure App Service' task with the 'Deploy to Slot' option and configure auto-swap with monitoring.

B.Use two separate deployment slots (blue/green) and manually swap after validation.

C.Use a canary deployment with multiple slots and manual approval gate.

D.Use an A/B testing deployment by deploying to two different App Services and routing traffic via Traffic Manager.

AnswerA

Correct: Deployment slots support gradual traffic shift and auto-rollback via monitoring.

Why this answer

The 'Deploy to Azure App Service' task with 'Deploy to Slot' and auto-swap with monitoring enables a gradual traffic shift over a specified duration (e.g., 30 minutes) using Azure's swap-with-preview and auto-rollback capabilities. When performance issues are detected via Application Insights or health checks, the swap is automatically aborted, rolling back to the previous slot. This meets the requirement for gradual shifting and automatic rollback without manual intervention.

Exam trap

The trap here is that candidates confuse 'canary deployment' (which often requires manual approval or external traffic routing) with Azure's built-in auto-swap with monitoring, which provides automatic gradual shifting and rollback without additional components.

How to eliminate wrong answers

Option B is wrong because manually swapping after validation does not provide gradual traffic shifting over 30 minutes; it is an instant swap, not a gradual rollout. Option C is wrong because a canary deployment with multiple slots and a manual approval gate requires human decision to proceed or roll back, not automatic rollback based on performance issues. Option D is wrong because using two separate App Services with Traffic Manager is not a slot-based deployment; it introduces additional cost and complexity, and Traffic Manager does not natively support automatic rollback based on application performance metrics.

Full explanation →

357

MCQhard

Your organization has a multi-stage YAML pipeline that builds and deploys a containerized application to Azure Kubernetes Service (AKS). The pipeline uses environment approvals for the production stage. You need to ensure that the container image deployed to production is the same as the one that passed all previous stages. Which strategy should you implement?

A.Publish the container image as a pipeline artifact and reference it from each stage.

B.Use the same image tag in all stages, updating the tag as needed.

C.Enable immutable tags on the container registry to prevent overwrites.

D.Rebuild the container image in each stage to ensure freshness.

AnswerA

Pipeline artifacts are immutable and can be passed between stages as dependencies, ensuring that the container image built once at the initial stage is exactly the same binary consumed by subsequent stages. This prevents any drift or accidental variation from rebuilding or republishing the image, which is crucial for reproducible deployments.

Why this answer

Publishing the container image as a pipeline artifact ensures that the exact same image (by digest, not just tag) is available to all stages. By referencing the artifact in each stage, you guarantee that the image deployed to production is identical to the one that passed testing, avoiding any risk of tag mutation or rebuild inconsistencies.

Exam trap

The trap here is that candidates often confuse tag-based strategies (like using the same tag or immutable tags) with the artifact-based approach, failing to realize that only publishing the image as a pipeline artifact guarantees the exact same image digest is used across all stages.

How to eliminate wrong answers

Option B is wrong because using the same image tag across stages is unreliable; tags can be overwritten or point to different images over time, breaking the guarantee of image consistency. Option C is wrong because enabling immutable tags only prevents tag deletion or overwrite in the registry, but does not ensure that the same image is used across stages—stages could still pull different images if tags are reused or if the pipeline rebuilds. Option D is wrong because rebuilding the container image in each stage introduces variability (e.g., different base image updates, build timestamps) and defeats the purpose of promoting a verified artifact through the pipeline.

Full explanation →

358

MCQhard

Refer to the exhibit. You queue a build in Azure Pipelines. The build status remains 'notStarted' for an extended period. What is the most likely reason?

A.The build priority is set to normal, causing delay.

B.The build is waiting for an available agent that meets the demands.

C.The build definition has a syntax error in the YAML file.

D.The build definition is not authorized to use the Azure Pipelines pool.

AnswerB

Correct. The demands require a Linux agent with Agent.Version > 2.170.1. If no hosted agent matches, the build waits indefinitely.

Why this answer

The 'notStarted' status indicates the build has been queued but no agent has picked it up yet. In Azure Pipelines, a build waits for an available agent that matches the demands specified in the pipeline (e.g., capabilities like 'Agent.OS' or custom demands). If all agents in the pool are busy or none meet the demands, the build remains in a 'notStarted' state until a suitable agent becomes free.

Exam trap

The trap here is that candidates often confuse 'notStarted' with a configuration or authorization error, but the key is recognizing that 'notStarted' specifically means the build is queued and waiting for an agent, not that it has been rejected or failed.

How to eliminate wrong answers

Option A is wrong because Azure Pipelines does not use a 'build priority' setting that causes delays; all queued builds are processed in FIFO order within the same pool, and priority is not a configurable factor for standard builds. Option C is wrong because a syntax error in the YAML file would cause the pipeline to fail at the validation stage, not remain in 'notStarted'—the build would show a 'Failed' or 'Error' status immediately. Option D is wrong because if the build definition were not authorized to use the pool, the build would fail with an authorization error, not remain indefinitely in 'notStarted'.

Full explanation →

359

Multi-Selecthard

Which THREE practices are recommended when implementing a Git branching strategy for a team using Azure Repos?

Select 3 answers

A.Delete branches after they are merged.

B.Allow force pushes to shared branches to clean up history.

C.Use short-lived feature branches that are merged within a day.

D.Keep feature branches alive for the entire sprint.

E.Require build validation on pull requests to the main branch.

AnswersA, C, E

Deleting feature branches immediately after their merge keeps the repository's branch list focused on active work and prevents stale refs from persisting indefinitely. Stale branches can drift from the latest main, causing confusion about which code is still in use and potentially leading to accidental reverts or conflicting fixes.

Why this answer

The three recommended practices are: A) Delete branches after they are merged to keep the repository clean; C) Use short-lived feature branches that are merged within a day to reduce merge conflicts and promote continuous integration; E) Require build validation on pull requests to the main branch to ensure code quality. B is incorrect because force pushes should be avoided on shared branches as they can rewrite history and disrupt collaboration. D is incorrect because keeping feature branches alive for the entire sprint increases complexity and delays integration.

Full explanation →

360

MCQmedium

Your organization uses GitHub Copilot for pull request summaries. However, some developers report that the summaries are inaccurate. What should you do to improve the quality of Copilot-generated pull request summaries?

A.Encourage developers to write more detailed commit messages.

B.Ask developers to write clear, structured PR titles and descriptions.

C.Disable Copilot for pull requests and use manual summaries.

D.Provide a link to a documentation wiki in the PR description.

AnswerB

Copilot's PR summary generation directly leverages the pull request title and description as key context. Clear, structured descriptions—such as separate sections for motivation, changes, and testing—help the model produce more accurate, well-organized summaries, so better input directly yields better output.

Why this answer

GitHub Copilot for pull request summaries relies on the PR title and description as primary input to generate accurate summaries. Clear, structured titles and descriptions provide better context for the AI model, reducing ambiguity and improving summary quality. Detailed commit messages (Option A) are not directly used by Copilot for PR summaries, as it focuses on the PR-level metadata.

Exam trap

The trap here is that candidates may overestimate the role of commit messages (Option A) in Copilot's PR summary generation, when in fact the model primarily uses the PR title and description, not the commit history, to produce the summary.

How to eliminate wrong answers

Option A is wrong because commit messages are not the primary input for Copilot's PR summary generation; the model uses the PR title and description, not individual commit messages, to synthesize a summary. Option C is wrong because disabling Copilot is a reactive measure that avoids the problem rather than addressing the root cause of inaccurate summaries, and manual summaries are less efficient. Option D is wrong because providing a documentation wiki link in the PR description does not directly improve the quality of Copilot-generated summaries; the model does not parse external links for content, and the summary is based on the text within the PR title and description itself.

Full explanation →

361

Multi-Selectmedium

Which THREE of the following are valid deployment strategies that can be implemented using Azure DevOps release pipelines? (Select THREE.)

Select 3 answers

A.Red-black deployment.

B.Rolling deployment.

C.Blue-green deployment.

D.Canary deployment.

E.Linear deployment.

AnswersB, C, D

Rolling deployment replaces instances incrementally, typically across batches or availability zones, ensuring that some capacity remains available during the update. It minimizes downtime and supports progressive exposure, with automated health checks deciding whether to continue or roll back.

Why this answer

Rolling deployment is a valid strategy in Azure DevOps release pipelines, where instances of the previous version are gradually replaced with the new version, typically by updating a subset of instances (e.g., in a virtual machine scale set or Kubernetes cluster) while the rest continue serving traffic. Blue-green deployment is also valid, maintaining two identical environments and switching all traffic from the blue (old) to the green (new) environment after validation, often implemented using deployment slots or Kubernetes namespaces. Canary deployment is a third valid strategy, where a small percentage of traffic is routed to the new version initially, gradually increasing it while monitoring health, commonly implemented with deployment slots or progressive exposure in Kubernetes.

Red-black, while sometimes used as a synonym for blue-green, is not a distinct deployment strategy recognized in Azure DevOps documentation, and linear deployment is not a recognized industry-standard pattern.

Exam trap

The trap is that candidates may confuse 'red-black' with 'blue-green' because of similar color-based naming, but 'red-black' is not a formally defined strategy in Azure DevOps, and 'linear deployment' is not a recognized pattern. However, note that red-black is essentially the same as blue-green in many contexts, so this trap is misleading; the key differentiator is that Azure DevOps does not use this terminology or provide specific support for it.

Full explanation →

362

MCQeasy

Your release pipeline includes a 'Deploy to App Service' task for a Linux web app. The deployment fails with 'Error: Failed to deploy web package to App Service'. What should you check first?

A.Verify that the deployment slot is correctly configured.

B.Check the Kudu console for errors.

C.Ensure the web.config file is present.

D.Review the App Service diagnostic logs.

AnswerD

App Service diagnostic logs are the authoritative source for troubleshooting deployment failures, as they capture detailed information about the deployment process, container startup, and runtime exceptions. Reviewing these logs is the correct first step to identify the underlying error and resolve the issue.

Why this answer

App Service diagnostic logs provide the most comprehensive and direct source of error details when a deployment fails. The 'Deploy to App Service' task uses Kudu (for Windows) or Oryx (for Linux) to process the deployment; reviewing the diagnostic logs (e.g., via the Azure portal under 'App Service logs' or the 'Log stream') will surface the exact failure reason, such as a missing startup command, incorrect runtime stack, or permission issues.

Exam trap

The trap here is that candidates mistakenly associate 'Kudu console' (Option B) with all App Service debugging, but Kudu is not available on Linux web apps, making diagnostic logs the correct first check.

How to eliminate wrong answers

Option A is wrong because deployment slot configuration is unrelated to the core deployment failure; slots are used for staging and swapping, not for diagnosing why a web package failed to deploy. Option B is wrong because the Kudu console is not available for Linux web apps (Kudu is Windows-only; Linux apps use Oryx and SSH-based debugging). Option C is wrong because web.config is an IIS-specific configuration file and is not used by Linux web apps, which rely on startup commands or app settings.

Full explanation →

363

MCQeasy

You need to run unit tests in your build pipeline and publish the test results to Azure Pipelines. Which task should you use?

A.DotNetCoreCLI task with test command

B.Npm task

C.Publish Test Results task

D.Visual Studio Test task

AnswerD

The Visual Studio Test task runs unit tests using the VSTest console and can produce a TRX file, but it does not directly publish the results to the pipeline. After execution, you still need a 'Publish Test Results' task to upload the TRX file so that the test results appear in the Azure DevOps UI.

Why this answer

To run unit tests and publish the results in Azure Pipelines, use the Visual Studio Test task. It executes the tests and automatically publishes the test results to the pipeline, providing rich reporting and pass/fail analysis. The Publish Test Results task is only used when you already have test result files (e.g., JUnit, TRX) from a previous step and need to import them; it does not run any tests itself.

The DotNetCoreCLI test command can also run and publish results, but the Visual Studio Test task is the standard framework-agnostic choice.

Exam trap

The trap is that candidates might think the Publish Test Results task is required for all test reporting, but in fact the Visual Studio Test task already includes built-in publishing. You only need a separate Publish Test Results task when using custom test runners that do not publish natively.

How to eliminate wrong answers

Option A is wrong because the DotNetCoreCLI task with the test command runs .NET Core tests but does not inherently publish results to Azure Pipelines; you must add a separate Publish Test Results task. Option B is wrong because the Npm task is for running npm scripts (e.g., test), but it does not publish test results to Azure Pipelines; it only runs the command. Option D is wrong because the Visual Studio Test task runs tests and can publish results, but it is specific to Visual Studio test frameworks (e.g., MSTest, xUnit) and not a generic solution for all unit test types; the question asks for a task to publish results, and the Publish Test Results task is the dedicated, framework-agnostic choice.

Full explanation →

364

MCQmedium

You receive a webhook notification from Azure Pipelines with the above payload. The build for the 'feature/logging' branch failed. You want to automatically create a work item to track the fix. What should you configure in Azure DevOps?

A.Add a branch policy on 'feature/logging' to require a successful build before merging.

B.Enable the 'Create work item on failure' option in the pipeline settings.

C.Use a GitHub Actions workflow to create an issue on failure.

D.Create a service hook subscription to listen for build failures and call Azure Boards API.

AnswerB

Automatically creates a work item when a build fails.

Why this answer

Azure Pipelines provides a built-in setting called 'Create work item on failure' that automatically generates a work item (e.g., a bug or task) in Azure Boards whenever a pipeline run fails. This directly meets the requirement to track the fix for the failed build on the 'feature/logging' branch without requiring external integrations or manual steps.

Exam trap

The trap here is that candidates may overcomplicate the solution by choosing a manual or external integration (like service hooks or GitHub Actions) when Azure Pipelines already provides a simple, built-in configuration option for automatic work item creation on failure.

How to eliminate wrong answers

Option A is wrong because adding a branch policy to require a successful build before merging is a preventative measure that blocks merging if the build fails, but it does not automatically create a work item to track the fix. Option C is wrong because the scenario uses Azure Pipelines, not GitHub Actions; while a GitHub Actions workflow could create an issue, it is not applicable to an Azure Pipelines webhook notification. Option D is wrong because creating a service hook subscription to listen for build failures and call the Azure Boards API is a valid but unnecessarily complex approach; the built-in 'Create work item on failure' option achieves the same result with less configuration and is the recommended method.

Full explanation →

365

MCQmedium

Your team uses GitHub Enterprise and GitHub Actions for CI/CD. You need to implement a security compliance plan. The organization has the following requirements: 1) All code pushed to the main branch must be scanned for secrets and vulnerabilities. 2) Developers must use signed commits. 3) Only approved GitHub Actions can be used. 4) Dependencies must be scanned for vulnerabilities. You have enabled secret scanning and code scanning (CodeQL) on all repositories. You have configured branch protection rules to require signed commits using GPG keys. To restrict actions, you have set an allowed list of actions in the organization settings. You have enabled Dependabot alerts. However, during an audit, a reviewer notes that secret scanning alerts are not being reviewed within 30 days. You need to ensure that secret scanning alerts are triaged within 30 days. What should you do?

A.Assign secret scanning alerts to the security team using the 'Assign to' feature in the alerts view.

B.Set up a webhook to send secret scanning alerts to a security team's email.

C.Disable secret scanning on repositories that do not contain secrets.

D.Configure secret scanning to automatically close alerts after 30 days.

AnswerA

Assignment ensures ownership and tracking of triage.

Why this answer

GitHub secret scanning allows you to assign alerts to specific team members using the 'Assign to' feature in the alerts view. This ensures that alerts are explicitly owned and triaged within the 30-day requirement. Option B is incorrect because webhooks merely send notifications; they do not guarantee that someone will review and triage the alert.

Option C is incorrect because disabling secret scanning on any repository would violate the requirement to scan all code pushed to main branch. Option D is incorrect because automatically closing alerts after 30 days could hide legitimate secrets that require investigation, which fails the security compliance goal.

Full explanation →

366

MCQmedium

A team uses Azure Repos with a Git branching strategy that includes feature branches. They want to ensure that all feature branches are deleted automatically after the pull request is completed. What should they do?

A.Enable 'Automatically delete source branch' in the branch policy.

B.Enable 'Create a merge commit' option in the branch policy.

C.Configure branch retention policy in the pipeline to delete branches after build.

D.Create a work item to remind developers to delete branches after merge.

AnswerA

This deletes the source branch after the PR is completed.

Why this answer

Azure Repos branch policies include an 'Automatically delete source branch' checkbox. When enabled, the source branch (e.g., a feature branch) is automatically deleted once the pull request is completed (merged or abandoned). This enforces cleanup without manual intervention, directly meeting the requirement.

Exam trap

The trap here is that candidates may confuse pipeline retention policies (which manage build artifacts) with Git branch management, or assume that a manual work item is sufficient for automation, when Azure Repos provides a direct built-in setting for automatic branch deletion.

How to eliminate wrong answers

Option B is wrong because 'Create a merge commit' is a merge type setting that controls how commits are integrated, not a branch deletion mechanism. Option C is wrong because branch retention policies in Azure Pipelines control how long pipeline runs and artifacts are kept, not the deletion of Git branches in Azure Repos. Option D is wrong because creating a work item is a manual process that relies on developer discipline, not an automated enforcement mechanism.

Full explanation →

367

MCQhard

Your pipeline has the following YAML trigger configuration: trigger: paths: include: - src/app/** A developer pushes changes to a file in 'src/app/config.json' on a branch named 'release/v1'. Which statement is true about the build trigger?

A.The build will be triggered but only if no other builds are running.

B.The build will be triggered.

C.The build will not be triggered because the path filter is too restrictive.

D.The build will not be triggered because the branch is not 'main'.

AnswerB

The pipeline's trigger configuration matches the pushed branch via the 'release/*' wildcard and the modified files satisfy the include path filter, so the build is correctly triggered as soon as the change is pushed.

Why this answer

The provided YAML trigger includes a path filter that matches 'src/app/**'. The push to 'src/app/config.json' matches that include pattern, so the build triggers. No branch filter is specified, so the trigger applies to all branches including 'release/v1'.

Therefore, option B is correct.

Exam trap

Candidates often think that path filters implicitly restrict branches, but without an explicit branch filter, the trigger applies to all branches.

How to eliminate wrong answers

Option A is wrong because there is no concurrency limit or batch setting in the trigger configuration that would cause the build to wait for other builds; the trigger fires immediately on matching changes. Option C is wrong because the path filter 'src/app/*' is not too restrictive; it explicitly includes the file 'src/app/config.json', so the change matches the filter. Option D is wrong because the trigger does not specify a branch filter; without a branch filter, the trigger applies to all branches, including 'release/v1'.

Full explanation →

368

Multi-Selectmedium

A development team is configuring a YAML-based pipeline in Azure Pipelines. The pipeline must meet the following requirements: - Build only the main branch. - Run integration tests after a successful build. - Deploy to a staging environment only if tests pass. - Handle failures gracefully by sending a notification to the team. You need to define the pipeline structure. Which TWO configurations should you include?

Select 2 answers

A.Use a `deployment: Staging` job with `displayName: Deploy to staging`.

B.Define a stage for 'Deploy' with `dependsOn: Test` and `condition: succeeded('Test')`.

C.Set `trigger: main` at the pipeline root.

D.Add `condition: succeeded()` to the build job.

E.Define the trigger in the `resources` section using `pipelines`.

AnswersB, C

The `dependsOn: Test` and `condition: succeeded('Test')` pair explicitly creates a stage dependency, ensuring the Deploy stage only executes if the Test stage completed with a success status. Without this condition, the default stage behavior would run stages sequentially only if previous stages succeeded, but this explicit syntax makes the gate unambiguous and allows for complex dependency graphs. This directly satisfies the requirement to deploy only after passing tests, as the condition checks the status of the Test stage before the Deploy stage starts.

Why this answer

It defines a 'Deploy' stage that depends on the 'Test' stage and uses `condition: succeeded('Test')` to ensure deployment only occurs after tests pass. This satisfies the requirement to deploy to staging only if tests succeed. Option C is correct because `trigger: main` at the pipeline root configures the pipeline to build only the main branch, meeting the first requirement.

Exam trap

The trap here is that candidates may confuse the `deployment` job keyword (which defines a deployment job but does not enforce stage dependencies) with the stage-level `dependsOn` and `condition` needed to gate deployment on test success, or they may mistakenly place the branch trigger in the `resources` section instead of the root `trigger`.

Full explanation →

369

MCQeasy

You need to integrate Azure Pipelines with GitHub to trigger a build when a release is published in GitHub. Which trigger type should you use in the pipeline?

A.pr:

B.trigger:

C.resources: repositories: - repository: self type: github trigger: release: true

D.schedules:

AnswerC

Defining a `resources.repositories` entry with `type: github` and `repository: self` references the GitHub repository, and adding `trigger: release: true` under that repository enables the pipeline to start automatically when a GitHub release is published. This is the correct event-driven trigger for GitHub releases, as it explicitly subscribes to release activity from the connected repository.

Why this answer

Azure Pipelines supports a GitHub release trigger through the `resources` definition, where you specify a `trigger` with `release: true` under the repository configuration. This tells the pipeline to automatically start a build whenever a new release is published in the linked GitHub repository, which directly matches the requirement.

Exam trap

The trap here is that candidates often confuse the `trigger:` keyword (which handles CI branch triggers) with the release trigger syntax, or mistakenly think a simple `trigger:` can be configured to listen for GitHub release events, when in fact it requires the nested `resources` structure with `release: true`.

How to eliminate wrong answers

Option A is wrong because `pr:` is used to trigger builds on pull request events, not on release publications. Option B is wrong because `trigger:` at the pipeline root configures CI triggers for branch pushes or path filters, not for GitHub release events. Option D is wrong because `schedules:` defines cron-based scheduled triggers, which are time-driven and unrelated to GitHub release events.

Full explanation →

370

MCQhard

Your organization uses GitHub Enterprise and requires that all commits to the main branch are signed with a GPG key verified by your organization. Developers are getting errors when pushing signed commits. What is the most likely cause?

A.The branch protection rule requires a linear history.

B.The developer's GPG key is not uploaded to their GitHub account or not verified.

C.The developer's email in the commit does not match any email on their GitHub account.

D.The developer's SSH key is not added to their GitHub account.

AnswerB

GitHub marks a commit as verified only when the signature was made by a GPG key that is uploaded to the user's GitHub account and associated with a verified email matching the commit's author. If the key is missing or not yet verified (e.g., the email is unconfirmed), GitHub cannot confirm the signature's authenticity, resulting in an unverified status.

Why this answer

GitHub requires that the GPG key used to sign a commit be uploaded to the user's GitHub account and marked as verified. If the key is missing or unverified, GitHub cannot confirm the signature's authenticity, causing the push to be rejected when branch protection rules enforce signed commits.

Exam trap

The trap here is that candidates often confuse authentication (SSH keys) with signing (GPG keys) or assume email mismatch is the primary cause, when in fact the core issue is the absence or unverified status of the GPG key itself.

How to eliminate wrong answers

Option A is wrong because a linear history requirement (e.g., via squash merging or rebase-only) does not affect GPG signature verification; it controls commit topology, not signing. Option C is wrong because while the commit email must match a verified email on the GitHub account for the signature to be associated, the error described is specifically about GPG key verification, not email mismatch—GitHub will still accept the signed commit if the key is valid, but the commit may show as 'unverified' if the email doesn't match. Option D is wrong because SSH keys are used for authentication (proving identity to GitHub), not for signing commits; GPG keys are used for signing, and SSH keys have no role in commit signature verification.

Full explanation →

371

MCQhard

Your release pipeline deploys to Azure App Service using slots. You need to ensure that after swapping, the warmup request is sent to the production slot before traffic is fully routed. What should you configure?

A.Enable auto swap for the deployment slot and configure a custom warmup path.

B.Add a health check to the App Service.

C.Perform a manual swap and then send a warmup request via a script.

D.Configure slot-specific app settings to enable warmup.

AnswerA

Enabling auto swap with a custom warmup path ensures the Azure App Service performs a request against the staging slot's specified path before the swap completes, loading application caches and verifying readiness so end users never hit uninitialized code during the swap operation.

Why this answer

Enabling auto swap with a custom warmup path sends a warmup request to the target slot before the swap completes, ensuring the production slot is warmed up. Option B is incorrect because a health check is used for monitoring instance health, not for warmup before swap. Option C is incorrect because a manual swap does not include automatic warmup; you would need to implement custom logic.

Option D is incorrect because slot-specific app settings are sticky and not swapped; they do not enable warmup.

Full explanation →

372

Multi-Selectmedium

Your organization uses Azure Pipelines to deploy a web application to multiple Azure App Service instances across regions. You need to implement a deployment strategy that allows rolling back to the previous version quickly if issues are detected. Which TWO strategies should you recommend?

Select 2 answers

A.Use a rolling update with incremental deployment.

B.Implement a canary deployment with traffic splitting.

C.Store previous deployment artifacts in Azure Blob Storage.

D.Use blue-green deployment with a traffic manager endpoint.

E.Deploy to a staging slot and then swap with production.

AnswersD, E

Blue-green allows switching traffic back to the previous environment.

Why this answer

The correct answers are D and E. Blue-green deployment with a traffic manager endpoint allows you to quickly route traffic back to the previous version if issues are detected. Deploying to a staging slot and then swapping with production (slot swap) enables instant rollback by swapping back to the previous slot.

Option A (rolling update) does not provide instant rollback because it requires redeployment. Option B (canary deployment) is designed for gradual traffic shifting, not immediate rollback. Option C (storing artifacts) is a good practice but does not itself constitute a deployment strategy for rollback.

Full explanation →

373

Multi-Selecthard

A company is designing an Azure DevOps strategy for a microservices application. They need to ensure that each microservice can be built, tested, and deployed independently. They also want to reuse pipeline components across services. Which TWO practices should they implement?

Select 2 answers

A.Publish all microservice artifacts to the same Azure Artifacts feed.

B.Store all pipeline variables in a single variable group.

C.Create a single pipeline that handles all microservices.

D.Use pipeline templates to define common build and test steps.

E.Use multi-stage YAML pipelines with separate pipeline definitions per microservice.

AnswersD, E

Templates promote reuse and consistency.

Why this answer

Pipeline templates in Azure DevOps allow you to define reusable YAML snippets for common build and test steps, enabling consistency across microservices without duplicating code. Option E is correct because multi-stage YAML pipelines with separate definitions per microservice ensure each service can be built, tested, and deployed independently, aligning with microservices architecture principles.

Exam trap

The trap here is that candidates often confuse reusing pipeline components (templates) with centralizing everything (single pipeline or single variable group), missing that independent deployment requires separate pipeline definitions per microservice.

Full explanation →

374

MCQeasy

Refer to the exhibit. The pipeline uses a variable group 'ReleaseVariables' that contains a variable named 'EnvironmentName' with value 'Staging'. What environment will the deployment target?

A.Staging

B.VirtualMachine

C.Production

D.DeployWeb

AnswerC

Production is the correct environment because the pipeline defines EnvironmentName: Production at the root level, and in YAML pipelines, variables defined at the pipeline level take precedence over variables in variable groups when the same key exists. The variable group provides EnvironmentName=Staging, but the pipeline variable overrides it, causing the deployment job's environment reference $(EnvironmentName) to evaluate to Production. Therefore the deployment is targeted to the Production environment, not Staging.

Why this answer

The pipeline uses a variable group 'ReleaseVariables' with a variable 'EnvironmentName' set to 'Staging', but the deployment job's environment field is explicitly set to 'Production' (as shown in the exhibit). Variable groups are used for sharing values across pipelines, but they do not override the environment specified directly in the YAML job definition. Therefore, the deployment target is 'Production'.

Exam trap

The trap here is that candidates assume a variable group's variable named 'EnvironmentName' automatically sets the deployment environment, but the environment field in the YAML is a static value unless explicitly parameterized, so the explicit 'Production' value takes precedence.

How to eliminate wrong answers

Option A is wrong because 'Staging' is the value of the variable 'EnvironmentName' in the variable group, but the deployment job's environment is explicitly set to 'Production' in the YAML, and variable groups do not override the environment field. Option B is wrong because 'VirtualMachine' is a resource type, not an environment name; the environment field expects a logical environment name like 'Production' or 'Staging', not a resource type. Option D is wrong because 'DeployWeb' is the name of the deployment job, not the environment target; the environment is specified separately in the 'environment' property of the job.

Full explanation →

375

MCQhard

You are designing a multi-stage YAML pipeline in Azure DevOps that builds, tests, and deploys a .NET Core application. The pipeline must use a self-hosted agent pool for compliance. You need to minimize agent idle time while ensuring that the agent is always available for builds. What should you do?

A.Provision a virtual machine scale set with a fixed number of agents

B.Install multiple agents on a single VM to maximize utilization

C.Deploy a scale set agent pool with autoscaling enabled

D.Use a single persistent agent and queue builds when idle

AnswerC

Deploying a scale set agent pool with autoscaling enabled is the correct approach because it dynamically adds or removes agent VMs based on job queue length, ensuring sufficient capacity during build bursts while minimizing idle compute costs during quiet periods.

Why this answer

A scale set agent pool with autoscaling enabled dynamically provisions and deprovisions Azure virtual machines based on the pipeline's demand, minimizing idle time while ensuring agents are available when builds are triggered. This approach aligns with the requirement for a self-hosted agent pool for compliance and optimizes cost by scaling down when no jobs are pending.

Exam trap

The trap here is that candidates may confuse 'minimizing idle time' with 'maximizing utilization' and choose Option B (multiple agents on one VM), not realizing that resource contention and lack of horizontal scaling make it unsuitable for concurrent builds and compliance-driven self-hosted pools.

How to eliminate wrong answers

Option A is wrong because provisioning a virtual machine scale set with a fixed number of agents does not minimize idle time; it keeps a constant number of VMs running regardless of demand, leading to wasted resources when no builds are queued. Option B is wrong because installing multiple agents on a single VM can cause resource contention (CPU, memory, disk I/O) and does not scale horizontally to handle concurrent builds efficiently, violating the goal of minimizing idle time while ensuring availability. Option D is wrong because using a single persistent agent and queuing builds when idle results in builds waiting if the agent is busy, increasing pipeline latency and not minimizing idle time—it also fails to scale for multiple concurrent builds.

Full explanation →

Microsoft Azure DevOps Engineer Expert AZ-400 (AZ-400) — Questions 301–375