823 questions total · 11pages · All types, answers revealed
Drag and drop the steps to perform a blue-green deployment in Azure using App Service slots into the correct order.
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Why this order
Blue-green deployment involves creating a slot, deploying to it, validating, swapping, and monitoring.
You are the DevOps lead for a financial services company. The company uses Azure DevOps Services with a single project containing multiple teams. The compliance team requires that all production deployments be approved by a change advisory board (CAB) member. Additionally, any deployment that changes a configuration value stored in Azure App Configuration must be audited. You have set up a release pipeline with a manual approval gate and a pre-deployment condition that runs a PowerShell script to validate configuration changes. However, the compliance team reports that some deployments bypassed the approval gate. Upon investigation, you find that developers with 'Edit release pipeline' permissions can modify the pipeline and remove the approval gate. You need to ensure that the approval gate cannot be bypassed by developers. You also need to ensure that any change to a configuration key is logged to Azure Monitor. What should you do?
Protected variable groups allow you to store critical configuration like approval gate settings and restrict access through pipeline permissions, ensuring only authorized users can modify those gates, and referencing the variable group in the pipeline makes the approval logic itself subject to governance. Restricting edit permissions on the release pipeline to a security group that excludes developers prevents developers from altering the pipeline definition to remove or bypass the required approvals, which is essential for compliance. Using an Azure Resource Manager template with a deployment script that sends logs to Azure Monitor provides an auditable, infrastructure-as-code approach for configuration changes, capturing exactly what was changed and who deployed it, and seamlessly integrating with Azure Monitor for centralized log retention and alerting. This layered defense enforces mandatory approval gates and provides complete change auditability, satisfying financial services compliance requirements.
Why this answer
It addresses both requirements: restricting pipeline edit permissions to a security group that excludes developers prevents them from removing the approval gate, and using an ARM template with a deployment script that sends logs to Azure Monitor ensures configuration changes are audited. Protected variable groups secure sensitive configuration, but the key is permission separation and audit logging via ARM deployment scripts.
Exam trap
The trap here is that candidates assume environment-level approvals or branch policies alone are sufficient, but they overlook that users with 'Edit release pipeline' permissions can bypass these controls by modifying the pipeline definition.
How to eliminate wrong answers
Option A is wrong because creating a new service connection with limited permissions does not prevent developers with 'Edit release pipeline' permissions from modifying the pipeline to bypass the approval gate; Azure Policy audits Azure resources but does not enforce pipeline-level approval gates. Option B is wrong because environment-level approvals in a release pipeline can still be bypassed if developers have 'Edit release pipeline' permissions to remove the environment or its approvals; Azure Policy does not enforce pipeline deployment flows. Option C is wrong because a branch policy on the YAML file only protects changes to the pipeline definition, not runtime bypass of the approval gate, and webhooks for configuration change events do not replace the need for audit logging to Azure Monitor via diagnostic settings or deployment scripts.
You are designing a plan to protect Azure DevOps pipelines from supply chain attacks. Which TWO measures should you implement?
Approvals on pipeline runs that consume external resources (e.g., packages from public feeds, or services outside the organization) prevent unauthorized or malicious use of those resources. By adding an approval gate, you ensure that every run touching external dependencies is explicitly authorized, reducing the risk of supply chain attacks like typosquatting or compromised upstream packages.
Why this answer
Options A and B are correct. Option A requires approval for pipeline runs that use external resources, which helps prevent unauthorized or malicious external dependencies from being used in builds, directly reducing supply chain attack risk. Option B uses Dependabot to automatically update vulnerable dependencies, ensuring known vulnerabilities are patched promptly.
Option C is incorrect because code coverage thresholds are a code quality measure, not a supply chain security control. Option D is incorrect because secret scanning detects secrets in repositories but does not prevent supply chain attacks. Option E is incorrect because release gates validate deployment health, not supply chain integrity.
Your team uses Azure Pipelines to deploy to production. You need to ensure that deployment only proceeds if a security scan passes and a manual approval is obtained. What is the best approach?
Release gates in Azure Pipelines run automated checks (e.g., querying work items, monitoring KPIs, or invoking Azure Monitor alerts) at a specified point in a release, and can pause the deployment until a condition is met. Combined with manual approval steps, release gates provide the necessary control to enforce compliance and quality before a production rollout begins.
Why this answer
Release gates in Azure Pipelines allow you to define automated checks (like security scans) and manual approvals before a deployment proceeds. Option A is incorrect because pipeline variables are used to store values, not to enforce deployment conditions. Option B is incorrect because service connections manage authentication to external services, not approval workflows.
Option C is incorrect because branch policies apply to pull requests in repositories, not to release pipelines.
You are designing a release pipeline for a critical production application. The pipeline must ensure that changes are deployed to a staging environment first, and if integration tests pass, they are automatically deployed to production. However, if the tests fail, the deployment to production must be blocked. What is the best approach?
This approach leverages a single YAML pipeline with multiple stages, where the staging stage deploys and runs tests, publishing results as artifacts. A pre-deployment gate on the production stage uses those published test results (e.g., pass rate or coverage) to automatically block or allow the promotion, ensuring the exact same build that passed staging is deployed. Because gates are evaluated automatically before the stage starts, no manual approval is required, yet the release is safely gated by objective quality signals.
Why this answer
A multi-stage YAML pipeline with a gate on the production stage allows you to evaluate the results of integration tests run in the staging stage before proceeding to production. The gate can be configured to check for test pass/fail status from the staging stage, blocking the production deployment if tests fail. This approach provides a clear, automated approval flow within a single pipeline definition, aligning with the requirement for conditional promotion based on test results.
Exam trap
The trap here is that candidates often confuse stage-level gates with task-level conditions, assuming a single stage with conditional tasks can achieve the same result, but gates operate at the stage boundary and can evaluate aggregated results from the entire previous stage, not just individual task outcomes.
How to eliminate wrong answers
Option A is wrong because using a single stage with conditional tasks does not provide a true stage-level gate; tasks within a stage run sequentially and cannot block the entire stage based on results from a previous stage, leading to potential deployment to production even if tests fail. Option C is wrong because using two separate pipelines with a pipeline trigger does not allow the production pipeline to evaluate test results from the staging pipeline; triggers only start the next pipeline upon completion, not based on test outcomes. Option D is wrong because pre-deployment approvals are manual and not automated based on test results; they require human intervention and do not evaluate integration test pass/fail status.
The exhibit shows a draft Azure Monitor alert rule for Key Vault secret expiry. However, the query fails to return results for secrets that have already expired. What is the most likely reason?
Expired secrets have a DaysToExpiry value that is negative because their expiry date is in the past. Using the condition DaysToExpiry > 0 filters out those negative values, so the alert rule excludes already expired secrets and only reports on those expiring in the future.
Why this answer
The query filters on `DaysToExpiry > 0`, which only returns secrets with a positive number of days remaining until expiry. Once a secret has expired, its `DaysToExpiry` becomes zero or negative, so it is excluded from the results. This is a logical filter error: the condition should be `DaysToExpiry <= 0` or remove the filter entirely to include expired secrets.
Exam trap
The trap here is that candidates focus on the syntax or limits of the query (like `limit 10`) rather than recognizing that the logical filter `DaysToExpiry > 0` inherently excludes the very data the alert is supposed to detect—expired secrets.
How to eliminate wrong answers
Option A is wrong because the query does not filter on whether a secret has an expiry date set; the issue is specifically about expired secrets, not those without an expiry date. Option C is wrong because the query does not include any condition that checks the enabled status of secrets; the problem is purely with the `DaysToExpiry` filter. Option D is wrong because the `limit 10` clause only affects the number of results returned, not the logical inclusion of expired secrets; even if more secrets were returned, expired ones would still be excluded by the `DaysToExpiry > 0` condition.
You are configuring a continuous integration trigger in Azure Pipelines for a repository in Azure Repos. You want to trigger a build for all branches except the 'release' branch. How should you configure the trigger?
Providing only an exclude list without an explicit include list means no branch is implicitly included, so the trigger will not be enabled for any branch; an include list must specify which branches are eligible for triggering.
Why this answer
In Azure Pipelines YAML triggers, the 'include' list is optional. If no include is specified, all branches are considered for triggering, and the 'exclude' list removes the specified branches. Therefore, 'trigger: branches: exclude: - release' correctly triggers on all branches except 'release'.
The marked answer C also works, but D is the simpler and standard configuration.
Exam trap
The trap is that candidates may think they need to explicitly include '*' to match all branches, but Azure Pipelines triggers on all branches by default unless an include list restricts it. A single exclude clause is sufficient.
How to eliminate wrong answers
Option A is wrong because setting 'include: - main' would only trigger builds for the 'main' branch, not all branches except 'release'. Option B is wrong because 'include: - *' and 'exclude: - *' would exclude all branches, resulting in no triggers at all. Option D is wrong because setting only 'exclude: - release' without an 'include' filter defaults to no branches being included, so no triggers would fire.
You are a DevOps engineer for a large e-commerce company. The development team uses GitHub for source control and GitHub Actions for CI/CD. The application is a microservices architecture with 15 services, each in its own repository. You need to implement a continuous delivery pipeline that builds and deploys each service to a Kubernetes cluster in Azure (AKS). The pipeline must meet the following requirements: - Each service must have its own pipeline that triggers on pushes to the main branch. - Deployment to AKS must use Helm charts. - The pipeline must automatically increment the Helm chart version and update the deployment manifest in the repository. - Security scanning must be performed on container images before deployment. - The pipeline must support manual approval for production deployment. - All secrets (e.g., AKS credentials, registry credentials) must be stored securely and not exposed in logs. You need to design the workflow. What is the best course of action?
Using OIDC eliminates long-lived Azure credentials by exchanging short-lived tokens from GitHub Actions, satisfying secure auth without storing secrets. Helm manages releases with chart version increments and rollback capabilities, and committing the bumped chart back maintains GitOps traceability. GitHub environments provide protected branches and approval gates per stage, while Trivy or Docker Scout scans container images for vulnerabilities before deployment.
Why this answer
Using GitHub Actions with OIDC to authenticate to Azure avoids storing long-lived secrets. Helm chart version bumping can be done with a script. The workflow uses environments for approval gates.
Container scanning using tools like Trivy can be added as a step.
You are a security engineer for a large financial institution. The organization uses Azure DevOps with multiple projects, each containing hundreds of pipelines. The security team recently discovered that several pipeline variables marked as 'Secret' were inadvertently printed to logs due to a custom script task that echoed the variable. Consequently, the compliance officer requires that all secrets used in pipelines must be centrally managed in Azure Key Vault, and any pipeline that references a variable not from Key Vault must be blocked from running. Additionally, the solution must minimize administrative overhead and provide real-time enforcement across all projects in the organization. You have the following options: Option A: Develop a custom pipeline task that checks at runtime whether all secret variables originate from Key Vault, and add it to every pipeline YAML file manually. Option B: Create an Azure Policy definition that audits pipelines for the use of non-Key Vault variables and attach it to the management group containing the Azure DevOps resources. Option C: Use Azure DevOps Audit Logs to periodically review pipeline runs and manually identify pipelines that use non-Key Vault secrets. Option D: Configure a pipeline decorator in the organization settings that injects a task at the beginning of every pipeline to validate that all secret variables are linked to Key Vault, and fail the pipeline if any are not. Which option meets the requirements most effectively?
Pipeline decorators automatically apply to all pipelines and can enforce compliance in real time.
Why this answer
Configure a pipeline decorator is correct because it provides real-time enforcement at the organization level with minimal overhead. Option A is wrong because manual addition to each pipeline is high overhead and error-prone. Option B is wrong because Azure Policy does not apply to Azure DevOps pipeline configurations.
Option C is wrong because it is reactive and does not block non-compliant runs.
Refer to the exhibit. You have a YAML pipeline with the above steps. The pipeline publishes a web app and deploys to Azure App Service. The deployment fails with error: 'Could not find the package in the specified path.' What is the most likely cause?
The AzureWebApp task's `package` input is configured with an incorrect file path. The `dotnet publish` command, when run in a YAML pipeline, defaults to publishing the zip package into `$(Build.ArtifactStagingDirectory)`, not into a subfolder like `$(System.DefaultWorkingDirectory)/published` unless explicitly redirected. Because the package path does not point to that staging directory, the task fails with a 'file not found' or 'no package found' error before deployment can begin. Setting `package: '$(Build.ArtifactStagingDirectory)/**/*.zip'` resolves the issue by correctly referencing the output location.
Why this answer
The error 'Could not find the package in the specified path' indicates that the AzureWebApp task is looking for a deployment package (typically a .zip file) at a path that does not exist. In the exhibit, the `dotnet publish` command outputs to `$(Build.ArtifactStagingDirectory)`, but the subsequent AzureWebApp task likely references a different path (e.g., `$(System.DefaultWorkingDirectory)` or a hardcoded path). The correct path should be `$(Build.ArtifactStagingDirectory)/**/*.zip` to match the published artifact.
Option A correctly identifies this path mismatch as the root cause.
Exam trap
The trap here is that candidates often assume the error is due to a missing zip file (Option C) or a misconfigured service connection (Option D), but the actual cause is a path variable mismatch between the publish output and the deployment task input.
How to eliminate wrong answers
Option B is wrong because the `appType` input (e.g., 'webApp' or 'webAppLinux') affects runtime stack selection but does not cause a 'package not found' error; it would instead cause a deployment failure related to incorrect app settings or runtime. Option C is wrong because the `dotnet publish` command with `--output $(Build.ArtifactStagingDirectory)` does generate a zip file (if configured) or at least the published output; the error is about the path, not the absence of a zip. Option D is wrong because an unauthorized service connection would result in an authentication/authorization error (e.g., 401 or 403), not a 'package not found' error, which is a file system issue.
Refer to the exhibit. You executed the Azure CLI command to list variable groups. A security audit requires that all variable groups containing secrets are configured to be authorized for all pipelines. Which statement is true based on the output?
The `az pipelines variable-group show` command returns the variable group's metadata and variable definitions. For a secret variable, the value is returned as null (or an empty string depending on the CLI version), which confirms the variable is secret. However, the output does not include an authorization flag such as `isAuthorized` or `authorizedForAllPipelines`; that is a separate property managed at the pipeline/library level. Therefore, while the output clearly indicates the presence of a secret variable, it provides no information about whether the variable group has been authorized for use in all pipelines.
Why this answer
The JSON output shows that 'ProdVars' has an 'ApiKey' variable with a null value, indicating it is a secret variable (values are masked). The output does not include any authorization properties, so we cannot determine if it is authorized for all pipelines. Option B is incorrect because the property 'authorized' may exist but is not shown in the list command; you need to use 'az pipelines variable-group show' or check the settings separately.
Option C is incorrect because the secret value is masked (null), not exposed. Option D is incorrect because having secret variables does not automatically authorize the group for all pipelines; authorization must be explicitly configured.
During a sprint review, stakeholders complain that they don't receive notifications about completed work items. The team uses Azure Boards with a custom notification subscription. What is the most likely cause?
The 'Deliver to' filter in an Azure DevOps notification subscription controls exactly which roles, groups, or individuals receive the alert. If stakeholders are omitted from that filter, they will not get any notifications from this subscription even though the subscription itself is active and functioning, which directly explains the symptom.
Why this answer
The most likely cause is that the custom notification subscription's 'Deliver to' filter is configured to exclude stakeholders. In Azure Boards, notification subscriptions can have filters that restrict delivery to specific groups or roles, and if stakeholders are not included in the filter, they will not receive notifications even if the subscription is active. This directly addresses the complaint that stakeholders are not getting notified about completed work items.
Exam trap
The trap here is that candidates might assume the issue is a global email disable or an automatic subscription expiry, rather than understanding that Azure Boards notification subscriptions rely on explicit filter configurations that can exclude specific roles like stakeholders.
How to eliminate wrong answers
Option A is wrong because if email notifications were disabled at the organization level, no one would receive any notifications, not just stakeholders, and the team would likely be aware of a global setting change. Option B is wrong because the subscription being set to deliver only to team members would explain why stakeholders don't receive notifications, but the question specifies a custom subscription with a 'Deliver to' filter, and the correct filter-based exclusion is more precise; however, the 'Deliver to' filter is the mechanism that controls who receives the notification, and excluding stakeholders is the direct cause. Option D is wrong because Azure Boards notification subscriptions are not automatically disabled after the first notification; they remain active until manually disabled or deleted, and there is no built-in behavior that disables subscriptions after a single delivery.
Refer to the exhibit. A build pipeline produces the above logs. Which change would resolve the build failure?
The build error is a CS1061 compilation error: the C# compiler cannot find a member named 'MyMethod' on the type 'MyClass'. This means the calling code references a method that is not declared anywhere in the class definition. Adding a method with the exact name 'MyMethod' and a compatible signature (parameter list and return type) to the 'MyClass' class is the only way to satisfy the compiler. Without this addition, any downstream steps (like tests) will have no valid assembly to run.
Why this answer
The build failure is caused by a missing method definition. The logs indicate that the test step is attempting to invoke 'MyMethod' on an instance of 'MyClass', but the compiler cannot find it. Adding the missing method to the class resolves the compilation error, which is the root cause of the pipeline failure.
Exam trap
The trap here is that candidates may focus on build flags like '--no-build' or configuration settings, overlooking the actual compilation error message that clearly indicates a missing method definition.
How to eliminate wrong answers
Option A is wrong because switching from Release to Debug configuration does not fix a missing method; it only changes optimization and debug symbols. Option C is wrong because removing the '--no-build' flag would force a rebuild before tests, but the failure is a compilation error in the test project itself, not a stale build artifact. Option D is wrong because adding '--no-restore' skips NuGet package restore, which would likely cause additional dependency errors and does not address the missing method definition.
Your company is migrating to Microsoft Entra ID and needs to manage secrets used in Azure Pipelines. Which service should you use to securely store and rotate secrets?
Azure Key Vault is the Azure-native service for securely storing and managing secrets, keys, and certificates. It integrates directly with Azure Pipelines through service connections or variable groups, providing centralized access control, auditing, and rotation of secrets used in pipeline tasks.
Why this answer
Azure Key Vault is the correct service to securely store and rotate secrets used in Azure Pipelines. It is natively integrated with Azure Pipelines via library variable groups, allowing secrets to be referenced in pipelines without exposing them. Option B, GitHub Secrets, is designed for GitHub Actions, not Azure Pipelines.
Option C, Azure App Configuration, manages feature flags and configuration settings, not secrets. Option D, Microsoft Purview, is for data governance and compliance, not secret management.
Your organization uses GitHub Actions and has a repository containing sensitive infrastructure code. You need to ensure that only approved actions are used in workflows. Which two settings should you configure? (Select two.)
This is correct because it restricts the set of actions available in your workflows to only those published by GitHub itself (e.g., `actions/checkout`, `actions/setup-dotnet`). This significantly reduces supply-chain risk by excluding third-party actions, while still allowing all workflows to run with trusted, officially maintained actions.
Why this answer
This is a select-two question. The correct answers are A and C. Option A is correct because enabling 'Allow actions created by GitHub' restricts workflows to only use first-party actions published by GitHub, establishing a baseline security posture.
Option C is correct because further limiting actions to only those from specific approved repositories provides granular control over third-party actions that have been vetted by the organization. Together, these settings ensure that only approved actions can be used in workflows, meeting the compliance requirement.
Exam trap
The trap here is that candidates often confuse environment protection rules (which manage deployment approvals) with action source restrictions, or mistakenly think disabling actions entirely is a valid security measure when the repository still needs to run workflows.
How to eliminate wrong answers
Option B is wrong because disabling actions entirely would prevent all workflows from running, which is too restrictive for a repository that needs to execute CI/CD pipelines. Option D is wrong because environment protection rules control deployment approvals and gates, not which actions can be used in workflows; they are unrelated to action source restrictions. Option E is wrong because storing actions in encrypted secrets is not a valid concept—secrets are for sensitive data like tokens or passwords, not for storing action code or references.
Refer to the exhibit. You have a YAML pipeline that references a repository resource with a tag. When will this pipeline trigger?
The YAML pipeline defines a branch trigger with `branches.include: main` for the current repository, so any push to the main branch of that repository will automatically start the pipeline. This is the standard CI trigger behavior in Azure Pipelines.
Why this answer
By default, a YAML pipeline triggers on changes to the main branch of the repository where the pipeline definition resides, even when a repository resource with a tag is referenced. The tag in the repository resource only controls which version of the resource is used at runtime, not the trigger behavior. Without an explicit trigger section, the pipeline uses the default CI trigger on the main branch of the self-repo.
Exam trap
The trap here is that candidates assume a referenced repository resource with a tag will automatically trigger the pipeline on tag pushes, but Azure Pipelines does not trigger on resource changes unless a pipeline resource trigger is explicitly configured.
How to eliminate wrong answers
Option A is wrong because a tag push to the referenced repository does not trigger the pipeline unless a trigger is explicitly defined for tags (e.g., using `trigger: tags: include: ['v1.0']`). Option B is wrong because changes to any branch of the referenced repository do not trigger the pipeline; only changes to the main branch of the current repository trigger it by default. Option D is wrong because a default CI trigger exists for the main branch of the current repository when no trigger is defined, so the pipeline will trigger on pushes to that branch.
Your Azure DevOps pipeline uses a YAML template that defines variables. You want to override a variable value when running the pipeline manually. What is the best approach?
The pipeline run UI's Variables tab provides a runtime override mechanism specifically designed for this scenario: when you start a manual run, you can expand the 'Variables' section and enter a new value for a YAML-defined variable, and that value is used for that run only without modifying the repository. This works because YAML variables are evaluated at runtime (after the pipeline is triggered), so the override seamlessly replaces the default value defined in the template or pipeline. Crucially, this approach requires zero changes to version-controlled files and leaves the pipeline definition untouched, making it the intended, non-invasive method for ad-hoc manual overrides.
Why this answer
Azure Pipelines allows you to override the value of a YAML-defined variable directly in the pipeline run UI via the 'Variables' tab when manually triggering a run. This approach is the simplest and most flexible way to change a variable's value without modifying the YAML template or pipeline definition, and it supports runtime parameterization for manual runs.
Exam trap
The trap here is that candidates often confuse variables with parameters, assuming that parameters are the only way to pass values at runtime, but Azure Pipelines explicitly supports overriding YAML-defined variables via the UI without needing to convert them to parameters.
How to eliminate wrong answers
Option A is wrong because variable groups are used to manage sets of variables across pipelines, but they cannot override a variable already defined in a YAML template at runtime; they are linked at queue time and have lower precedence than variables set in the UI. Option B is wrong because hardcoding a value in the template YAML file defeats the purpose of dynamic override and requires a commit to the repository, which is not a runtime override mechanism. Option D is wrong because while parameters can be used to pass values into templates, there is no 'Override' parameter in Azure Pipelines; the correct way to pass a parameter value is via the pipeline run UI's 'Parameters' section (if defined as a parameter), but the question specifically asks about overriding a variable, not a parameter.
Your organization uses GitHub Enterprise and wants to prevent secrets (e.g., API keys) from being pushed to any repository. Which GitHub feature should you enable?
Push protection prevents commits with secrets from being pushed.
Why this answer
Push protection for secret scanning (Option C) is the correct answer because it actively blocks pushes that contain known secrets (e.g., API keys, tokens) at the client side, preventing them from ever reaching the remote repository. This is a dedicated feature of GitHub Advanced Security that integrates with pre-receive hooks to scan commits in real time, rejecting the push if a secret pattern is detected. It is specifically designed to prevent secrets from being pushed, unlike passive scanning which only alerts after the fact.
Exam trap
The trap here is that candidates confuse 'secret scanning' (passive detection) with 'push protection' (active prevention), assuming that enabling GitHub Advanced Security secret scanning alone will block pushes, when in fact push protection is a separate toggle that must be explicitly enabled.
How to eliminate wrong answers
Option A is wrong because repository rulesets are used to enforce branch policies (e.g., required status checks, merge restrictions) but do not scan or block secrets in commits. Option B is wrong because GitHub Advanced Security secret scanning alone only detects secrets after they have been pushed (via alerts or pull request comments) and does not prevent the push from succeeding. Option D is wrong because branch protection rules requiring signed commits enforce commit integrity via GPG or S/MIME signatures but have no mechanism to inspect commit content for secrets.
Which THREE of the following are best practices for managing secrets in Azure Pipelines? (Select THREE.)
Key Vault provides secure storage and access control.
Why this answer
Azure Key Vault is the recommended service for securely storing and managing secrets, keys, and certificates. By linking a Key Vault to a variable group in Azure Pipelines, you can reference secrets without exposing them in YAML or logs, and the pipeline retrieves them at runtime using a managed identity or service principal. This approach ensures secrets are never hardcoded and access can be audited and controlled centrally.
Exam trap
The trap here is that candidates may think hardcoding secrets with variable substitution (Option A) is acceptable because it avoids storing secrets in plain text in the YAML, but they overlook that the secret value is still exposed in the pipeline logs and source control history, which is a critical security flaw.
You have a YAML pipeline that builds a .NET application. You need to ensure that the pipeline uses the .NET SDK version 6.0.x. Which task should you add to the pipeline?
UseDotNet@2 is the correct task because it explicitly installs a specified .NET Core/.NET SDK version on the build agent, making that SDK available for subsequent pipeline steps. It can also read a global.json to select the exact SDK version, ensuring the pipeline uses the intended toolset.
Why this answer
The UseDotNet@2 task is the correct choice because it explicitly installs a specific .NET SDK version (6.0.x) on the build agent, ensuring the pipeline uses the required SDK for building the .NET application. This task downloads and caches the SDK, making it available for subsequent tasks like DotNetCoreCLI@2.
Exam trap
The trap here is that candidates often confuse DotNetCoreCLI@2 (which runs .NET commands) with UseDotNet@2 (which installs the SDK), assuming the build task itself can set the SDK version, but DotNetCoreCLI@2 only uses whatever SDK is already available.
Why the other options are wrong
This installs NuGet, not the .NET SDK.
This runs .NET commands but does not install a specific SDK version.
PowerShell can install SDK but it's not the built-in task for this purpose.
Your organization uses Azure DevOps Server (on-premises) and is planning to migrate to Azure DevOps Services. You have hundreds of build and release pipelines. The migration must be done with minimal downtime and with validation that each pipeline works after migration. You have a test collection of 20 critical pipelines that must be validated first. What is the best approach?
The Azure DevOps Migration Tools (the community-supported VSTS/Azure DevOps Migration Tools) are specifically designed to programmatically migrate build and release pipelines, service endpoints, and certain metadata between Azure DevOps organizations, allowing you to run trials against a test organization first. By replicating test pipelines first, you can validate variable resolution, service connection authentication, agent pool references, and task extension compatibility; fixing issues early prevents them from appearing later. Afterward, migrating the remaining pipelines in batches gives you controlled rollout, checkpointing, and the ability to fix issues before going live, which matches the requirement for minimal downtime and reduced risk.
Why this answer
Using the Azure DevOps Migration Tools to perform a trial migration to a test organization allows you to validate and fix issues before migrating the full collection. Direct upgrade is not supported. Manual recreation is error-prone and not minimal downtime.
Skipping validation risks breaking pipelines.
Refer to the exhibit. You have this Azure Pipelines YAML definition. The pipeline runs manually, but you want it to automatically trigger on every push to the main branch and also build pull requests targeting main. Which change should you make?
This enables CI on push to main and PR triggers for PRs targeting main.
Why this answer
In Azure Pipelines YAML, setting `triggers: ['none']` explicitly disables CI triggers, and `pr: ['none']` disables PR triggers. To enable automatic builds on every push to main and on pull requests targeting main, you must replace these with `triggers: ['main']` and `pr: ['main']`, which configures both CI and PR triggers for the main branch.
Exam trap
The trap here is that candidates may think removing the trigger sections (Option A) will enable automatic triggers, but in Azure Pipelines YAML, removing them actually enables triggers on all branches, not just main, which is too broad and does not meet the specific requirement.
How to eliminate wrong answers
Option A is wrong because removing the `triggers` and `pr` sections entirely would cause the pipeline to inherit default behavior (CI triggers on all branches and PR triggers on all branches), which does not match the requirement to trigger only on main and PRs targeting main. Option C is wrong because setting `pr: ['none']` disables PR triggers, so pull requests targeting main would not trigger the pipeline, failing the requirement. Option D is wrong because setting both `triggers` and `pr` to `none` (as strings, not arrays) is invalid syntax and would disable all triggers, preventing any automatic builds.
An organization uses Azure Repos with multiple Git repositories. They want to enforce that all commits to the main branch are signed using GPG keys. Which combination of actions is required to enforce commit signing?
Azure Repos branch policies can enforce that every commit in a protected branch is signed, and developers must configure their local Git client to sign commits with a GPG key (e.g., set user.signingkey and commit.gpgsign=true). When a developer pushes a signed commit, Azure Repos verifies the GPG signature against the developer's configured public key, while the private key remains securely on the developer's machine.
Why this answer
Azure Repos supports a branch policy that requires commits to be signed, and developers must configure Git to sign commits with their GPG key using `git config --global user.signingkey` and `git commit -S`. This ensures that only signed commits are accepted into the main branch, enforcing non-repudiation and integrity.
Exam trap
The trap here is confusing authentication methods (SSH keys, PATs) with commit signing (GPG keys), leading candidates to select options that address access control rather than cryptographic integrity.
How to eliminate wrong answers
Option A is wrong because SSH public keys are used for authentication, not for signing commits; commit signing requires GPG keys, not SSH keys. Option B is wrong because a personal access token (PAT) is used for authentication to Azure Repos, not for signing commits; it does not enforce cryptographic signing. Option D is wrong because Azure Key Vault can store keys but Azure Repos does not automatically sign commits; signing must be performed client-side by the developer using Git.
Match each YAML pipeline trigger to its behavior.
Drag a concept onto its matching description — or click a concept then click the description.
Runs pipeline on code push
Runs pipeline on pull request creation
Runs pipeline at specified times
Runs pipeline after another pipeline completes
Why these pairings
In Azure Pipelines YAML, each trigger type has a distinct purpose: CI for push events, PR for pull requests, Schedules for cron-based runs, and Pipeline for cross-pipeline dependencies. Common confusions mix the behaviors of CI/PR or PR/Pipeline triggers.
Your team uses Azure DevOps and wants to automatically scan pull requests for secrets before they are merged. Which Azure DevOps feature should you use?
GitHub Advanced Security (GHAS) is a suite of security tools—including secret scanning, code scanning, and dependency review—that is tightly integrated with GitHub repositories, not with Azure Repos in Azure DevOps. Because GHAS secret scanning only works within the GitHub ecosystem and cannot be configured to scan Azure Repos, it is not applicable to this Azure DevOps pipeline scenario.
Why this answer
GitHub Advanced Security (GHAS) for Azure DevOps provides secret scanning that automatically detects secrets (e.g., API keys, passwords, connection strings) in pull requests before they are merged. This feature is integrated into Azure Repos when Advanced Security is enabled and triggers on PR creation, blocking the merge if secrets are found. Therefore, the correct choice is GitHub Advanced Security, not a separate 'Secret scanning in Azure DevOps' feature, which does not exist as a native built-in feature.
Exam trap
Candidates may confuse the built-in secret scanning with a standalone feature, but in Azure DevOps, secret scanning is only available through GitHub Advanced Security (which requires appropriate licensing).
How to eliminate wrong answers
Option A is wrong because Azure Policy is a governance tool for enforcing compliance rules on Azure resources (e.g., VM SKUs, resource locations), not for scanning code or pull requests for secrets. Option C is wrong because GitHub Advanced Security is a feature set for GitHub repositories (including secret scanning), but the question specifies Azure DevOps, which uses its own secret scanning feature, not GitHub Advanced Security. Option D is wrong because a branch policy with a required reviewer only mandates manual approval from a designated user; it does not perform automated secret scanning or content analysis.
You are setting up a new GitHub repository for a project that requires strict access control. Only specific team members should be able to push to the main branch, but all team members should be able to create branches and open pull requests. What is the best way to achieve this?
A branch protection rule on the main branch can restrict direct pushes to specific users or teams, while still allowing branch creation and pull requests. This ensures that only authorized personnel can push to main, and all other changes must go through PR reviews, which directly addresses your requirement.
Why this answer
Branch protection rules in GitHub allow you to enforce restrictions on specific branches, such as requiring pull request reviews or restricting who can push directly. By configuring a rule for the main branch that limits push access to only designated users or teams, you ensure that all team members can create branches and open PRs, but only authorized members can merge into main. This directly meets the requirement without over-provisioning permissions or blocking collaboration.
Exam trap
The trap here is that candidates often confuse restricting push access with removing write permissions entirely, not realizing that branch protection rules allow granular control over specific branches while preserving write-level collaboration on other branches.
How to eliminate wrong answers
Option A is wrong because adding all team members as administrators grants them full control over the repository, including the ability to bypass any restrictions and push directly to main, which violates the strict access control requirement. Option B is wrong because removing write permissions for non-core members and giving them read-only access prevents them from creating branches or opening pull requests, which contradicts the requirement that all team members should be able to do so. Option D is wrong because setting the repository to private and inviting only core team members excludes non-core members entirely, preventing them from creating branches or opening pull requests, which is not the desired outcome.
You run the above Azure CLI command to deploy a Bicep template. The deployment fails with 'The resource 'Microsoft.Storage/storageAccounts/mystgaccount' already exists'. What is the most likely cause?
The deployment fails because Azure Resource Manager's default 'create' mode (used by 'az deployment group create' when no mode is specified) issues a conflict error if a resource with the same name and type already exists in the target resource group, even if the template's properties match the existing resource. The storage account 'mystgaccount' already occupies that name in 'MyRG', so the deployment cannot proceed.
Why this answer
The error message 'The resource 'Microsoft.Storage/storageAccounts/mystgaccount' already exists' indicates that the storage account 'mystgaccount' already exists in the target resource group, which prevents the deployment from creating it again. This directly supports option A as the correct answer. Option B is incorrect because 'az deployment group validate' only validates the template and does not perform a deployment; the error occurs during the actual deployment, not validation.
Option C is incorrect because Bicep defaults to incremental mode, not complete mode, and even if complete mode were used, the error would be about a resource existing in the template but not in the resource group, which is not the case here. Option D is incorrect because if the resource group did not exist, the error would be something like 'ResourceGroupNotFound', not an already-exists error.
You are designing a release pipeline for a microservices application. Each service must be deployed independently with zero downtime. Which deployment strategy should you recommend?
Blue-green maintains two full environments for instant switch.
Why this answer
Blue-green deployment is the correct strategy because it maintains two identical environments (blue and green) and allows instant traffic switch to the new version while keeping the old version running, enabling zero-downtime deployment and immediate rollback if issues arise. This aligns with the requirement of independent deployment for each microservice. Option A (rolling update) is incorrect because it replaces instances gradually, which can cause version skew and does not provide instant rollback.
Option B (feature flags) is a technique for feature toggling, not a deployment strategy; it does not handle traffic shifting or environment isolation. Option C (canary release) is incorrect because it routes a small subset of users to the new version, which does not guarantee immediate full zero-downtime deployment and requires gradual rollout and monitoring.
Exam trap
Candidates often confuse canary releases and blue-green deployments. While both can achieve zero downtime, blue-green provides an instant full switch and simpler rollback, whereas canary is gradual and requires traffic routing logic.
Drag and drop the steps to troubleshoot a failed Azure DevOps release pipeline into the correct order.
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Why this order
Troubleshooting starts with logs, then task identification, variable check, debug run, and fix.
You are configuring Application Insights for a .NET Core web application deployed to Azure App Service. The application must capture telemetry for all HTTP requests, exceptions, and dependency calls with minimal code changes. What should you do?
The Application Insights site extension in the App Service 'Application Insights' blade is the correct choice because it attaches the Application Insights agent directly to the App Service runtime, automatically collecting server-side telemetry such as requests, dependencies, exceptions, and performance counters without requiring any code changes, recompilation, or redeployment.
Why this answer
Enabling the Application Insights site extension via the App Service 'Application Insights' blade automatically instruments the .NET Core application without requiring any code changes. This extension injects the necessary telemetry modules to capture HTTP requests, exceptions, and dependency calls at the runtime level, leveraging the Azure App Service integration for zero-code instrumentation.
Exam trap
The trap here is that candidates often assume the NuGet package (Option C) is always required for .NET Core instrumentation, overlooking the zero-code site extension option that meets the 'minimal code changes' requirement more directly.
How to eliminate wrong answers
Option B is wrong because configuring diagnostics logging and streaming logs to Application Insights captures only platform-level logs (e.g., IIS logs, failed request tracing) and does not automatically capture application-level telemetry like dependency calls or exceptions without additional custom code. Option C is wrong because while installing the NuGet package and adding services.AddApplicationInsightsTelemetry() is a valid code-based approach, the question explicitly requires 'minimal code changes,' making the site extension (zero-code) the better choice. Option D is wrong because the JavaScript SDK is for client-side browser telemetry (page views, client exceptions), not for server-side HTTP requests, exceptions, or dependency calls in a .NET Core web application.
You are designing a build pipeline that must run on Microsoft-hosted agents. The pipeline has a dependency on a native library that is not pre-installed. You want to minimize pipeline duration. Which approach should you use?
Using a container job with a custom Docker image that includes the library allows the pipeline to run on Microsoft-hosted agents while avoiding the time needed to install the library in each run. This minimizes pipeline duration and meets the requirement.
Why this answer
Using a container job with a custom Docker image that includes the native library allows the pipeline to run on Microsoft-hosted agents while eliminating installation overhead, thus minimizing pipeline duration. This approach meets the requirement of using Microsoft-hosted agents and avoids the time cost of installing the library in each run.
Exam trap
Candidates may think self-hosted agents are required for pre-installed dependencies, but container jobs on Microsoft-hosted agents achieve the same benefit with less management overhead and still meet the requirement.
How to eliminate wrong answers
Option A is wrong because container jobs with custom Docker images still require pulling the image on each run, which adds significant time and does not leverage the pre-installed nature of a self-hosted agent. Option C is wrong because adding a script step to install the library using a package manager incurs runtime installation overhead, increasing pipeline duration. Option D is wrong because downloading the library from Azure Blob Storage in each build adds network transfer time and does not avoid the installation step, thus not minimizing duration.
An organization uses Azure DevOps and wants to implement a change management process where all changes to the main branch require approval from a change advisory board (CAB). The CAB members are not part of the development team. How should they configure this?
A branch policy on main can require a minimum number of reviewers from a specific Azure DevOps group, such as a separate CAB. This ensures automated enforcement of the approval requirement, so pull requests cannot be completed without the mandated CAB reviews.
Why this answer
Azure DevOps branch policies allow you to enforce a minimum number of reviewers from a specific security group (e.g., a CAB group) on pull requests targeting the main branch. This ensures that every change to main requires explicit approval from CAB members, who are separate from the development team, without relying on manual processes or altering team membership.
Exam trap
The trap here is that candidates often confuse branch permissions (which control who can push) with branch policies (which control the review process), leading them to choose Option A instead of the correct policy-based solution.
How to eliminate wrong answers
Option A is wrong because restricting push permissions to main would block all direct pushes, but it does not enforce a review process; it would require a manual, non-auditable workflow outside Azure DevOps. Option C is wrong because a service hook only sends a notification when a PR is created; it does not enforce approval as a required gate, so changes could still be completed without CAB sign-off. Option D is wrong because adding CAB members to the development team would grant them unnecessary permissions and violate the requirement that CAB is separate from the development team; the team review policy would also apply to all team members, not specifically to CAB.
You have a YAML pipeline that builds a Docker image and pushes it to Azure Container Registry (ACR). You need to dynamically set the image tag based on the build number. Which predefined variable should you use?
Build.BuildNumber is a human-readable, configurable build name that often includes non-alphanumeric characters like colons, dashes, or custom text. Docker tags must be lowercase alphanumeric and may contain only periods, underscores, and hyphens, so directly using BuildNumber risks invalid tags that fail the build unless the value is sanitized.
Why this answer
The `$(Build.BuildNumber)` variable represents the build number, which is the name of the completed build. It's often customized to include versioning information, and it's the appropriate variable to use when tagging Docker images based on the build number. `$(Build.BuildId)` is a unique numeric ID for the build record, but it is not the build number.
Exam trap
Candidates may confuse `Build.BuildNumber` (the human-readable build name) with `Build.BuildId` (the internal numeric ID). The stem explicitly says 'based on the build number', so `Build.BuildNumber` is the correct choice.
How to eliminate wrong answers
Option A is wrong because `$(System.JobId)` is a unique identifier for a specific job run within a pipeline, not the overall build number, and is not intended for image tagging. Option B is wrong because `$(System.TeamProject)` contains the name of the Azure DevOps project, which is static and does not provide a unique or incrementing value for tagging. Option C is wrong because `$(Build.BuildNumber)` is a user-defined or default formatted string (e.g., '20250401.1') that can contain non-numeric characters and is not guaranteed to be strictly incrementing or unique across parallel builds, making it less reliable for Docker tags than the integer `$(Build.BuildId)`.
A team uses a monorepo with multiple projects in one Git repository. They want to enforce that each commit message must reference a work item from Azure Boards. Which branch policy should they configure?
A build validation policy runs a configured pipeline (e.g., a script that greps commit messages) and can fail the build if a message lacks a work item ID, but this is an indirect, custom workaround. It does not natively enforce work item linking in the pull request metadata, is prone to bypass via malformed commit messages, and is not the designated Azure DevOps policy for this requirement.
Why this answer
The 'Require a work item linking policy' in Azure Repos ensures each pull request is linked to a work item, but it does not validate that each commit message contains a reference. To enforce that commit messages themselves reference an Azure Boards work item, a build validation policy can run a script to verify the commit message format. Therefore, option D is the correct choice.
Exam trap
Candidates may confuse the native work item linking policy with actual commit message validation. The work item linking policy only requires a PR-level link, not per-commit message references.
How to eliminate wrong answers
Option A is wrong because automatically including work items in pull request descriptions only adds work item links to the description text, but does not enforce that every commit message must reference a work item. Option C is wrong because a minimum number of reviewers policy controls who must approve the pull request, not the content of commit messages or work item references. Option D is wrong because a build validation policy runs a build pipeline to validate code quality or tests, but it cannot inspect or enforce commit message content for work item references without custom scripting, and it is not the native policy designed for this purpose.
Your team uses Azure Pipelines for CI/CD. You need to enforce that all builds sign the assemblies with a code signing certificate stored in Azure Key Vault. What is the recommended approach?
The Key Vault task downloads secrets (including certificates) and makes them available as pipeline variables.
Why this answer
Use the Azure Key Vault task to download the certificate as a secure secret, then use a PowerShell task to sign the assemblies with that certificate.
You are designing a pipeline to build a .NET Core application. The build must run unit tests and publish code coverage results. Which task should you use to publish the code coverage results to Azure DevOps?
The PublishCodeCoverageResults@1 task is the dedicated Azure DevOps task for publishing code coverage data generated by test runs to the pipeline UI and build summary. It accepts coverage files in formats like Cobertura or JaCoCo, making it the correct choice for publishing .NET Core coverage reports.
Why this answer
The 'PublishCodeCoverageResults@1' task is the correct choice because it is specifically designed to publish code coverage results (e.g., Cobertura or JaCoCo XML reports) to Azure DevOps, making them visible in the build summary and pipeline artifacts. This task consumes the coverage data file generated by a previous test run (e.g., via 'DotNetCoreCLI@2' with '--collect "Code Coverage"') and uploads it to the Azure DevOps service for reporting.
Exam trap
The trap here is that candidates confuse the task that runs tests with coverage collection (e.g., VSTest@2 or DotNetCoreCLI@2) for the task that publishes the coverage results, forgetting that publishing is a separate, explicit step required to surface the data in Azure DevOps.
How to eliminate wrong answers
Option B is wrong because 'PublishTestResults@2' publishes test pass/fail results (e.g., TRX, JUnit XML) to the Tests tab, not code coverage data. Option C is wrong because 'DotNetCoreCLI@2' with the 'test' command runs tests and can collect coverage data (e.g., via Coverlet), but it does not publish the coverage results to Azure DevOps; a separate publish task is required. Option D is wrong because 'VSTest@2' with 'codeCoverageEnabled' runs tests with coverage instrumentation (using the Visual Studio coverage engine), but it does not publish the results; the coverage data must still be published using a dedicated task like 'PublishCodeCoverageResults@1'.
Your company uses Azure DevOps for CI/CD. You have a build pipeline that compiles a C++ application and runs unit tests. The pipeline uses a Microsoft-hosted agent. The build takes approximately 45 minutes to complete. You want to reduce the build time. You notice that the pipeline downloads dependencies from a NuGet feed every time. You have a private NuGet feed in Azure Artifacts. The pipeline restores packages using 'nuget restore'. You want to cache the NuGet packages on the agent to avoid downloading them on every build. What should you do?
Adding a CacheBeta task (or the newer Cache task) with a key based on the packages file (e.g., packages.lock.json or .csproj) and a path like $(UserProfile)/.nuget/packages stores the restored packages in Azure DevOps' external cache. On subsequent builds, the restore step pulls packages from that cache instead of hitting the network, which directly eliminates repeated downloads and is the correct quick fix.
Why this answer
The CacheBeta task enables caching of the NuGet packages folder between pipeline runs, avoiding repeated downloads from the feed. This directly reduces build time. Option A is wrong because while self-hosted agents can have persistent storage, the question specifies using a Microsoft-hosted agent, and the CacheBeta task works even with Microsoft-hosted agents.
Option B is wrong because using upstream sources in Azure Artifacts does not cache packages locally on the agent; it still requires downloading them each time. Option C is wrong because increasing compute resources does not affect the time spent downloading dependencies; caching addresses the root cause.
You are designing a source control strategy for a team that uses GitHub Copilot. The team wants to ensure that code suggestions do not include sensitive data. Which approach should you recommend?
Prevents suggestions with secrets.
Why this answer
GitHub Copilot's content exclusions allow you to define patterns (e.g., regex for API keys, tokens, or PII) that Copilot will block from being used as context for code suggestions. This directly prevents sensitive data from appearing in suggestions without disabling the tool entirely. It is the most targeted and least disruptive approach to meet the team's goal.
Exam trap
The trap here is confusing reactive scanning (secret scanning or pre-commit hooks) with proactive prevention (content exclusions), leading candidates to choose a post-commit detection method instead of a real-time suggestion filter.
How to eliminate wrong answers
Option A is wrong because pre-commit hooks scan code after it is staged, not during the suggestion phase; they cannot prevent Copilot from generating suggestions containing sensitive data in real time. Option B is wrong because disabling Copilot for the organization is an overreaction that eliminates all productivity benefits, whereas the team only needs to block sensitive data patterns. Option C is wrong because secret scanning detects secrets already committed to the repository (post-commit), not during the suggestion phase; it does not prevent Copilot from suggesting sensitive data.
Your organization uses GitHub Actions for CI/CD. You have a workflow that builds a .NET application and runs tests. The workflow uses a self-hosted runner on an on-premises Windows server. Recently, builds started failing with 'Access to the path is denied' errors when the runner tries to restore NuGet packages. The runner has been working for months. What is the most likely cause?
If the Windows service or daemon account that runs the runner no longer has write permissions on the workspace, _work, or the NuGet cache directory, the restore step fails with an access denied (UnauthorizedAccessException) error. This exactly matches the symptom, as permission changes on the runner service account directly affect local file access.
Why this answer
The 'Access to the path is denied' error during NuGet restore on a self-hosted runner typically indicates a file system permission issue. Since the runner has been working for months, the most likely cause is that the service account under which the runner runs no longer has write access to the working directory or the NuGet cache folder, often due to a group policy change, account modification, or folder permission drift.
Exam trap
The trap here is that candidates confuse authentication failures (token expiry) with local file system permission errors, assuming any 'access denied' relates to GitHub connectivity rather than the runner's service account permissions on the on-premises machine.
How to eliminate wrong answers
Option A is wrong because an expired runner authentication token would cause authentication failures when connecting to GitHub, not file access errors during NuGet restore. Option C is wrong because deleting the NuGet cache directory would cause cache misses and re-downloads, not 'Access to the path is denied' errors; the runner would still have permission to create a new cache folder. Option D is wrong because newer runner versions maintain full backward compatibility with NuGet restore; the runner does not 'support' or 'not support' NuGet restore as a feature.
Your team uses GitHub for source control and wants to set up continuous integration using GitHub Actions. Which file should you create in the repository to define the workflow?
The file .github/workflows/ci.yml is the standard and expected location for a GitHub Actions workflow. Any YAML file in the .github/workflows directory defines an automated workflow that GitHub Actions will parse and run based on configured event triggers, such as push or pull_request, making it the correct choice for setting up CI with GitHub.
Why this answer
GitHub Actions workflows are defined in YAML files stored in the .github/workflows directory. Option A is wrong because a Jenkinsfile is used with Jenkins, not GitHub Actions. Option C is wrong because a Dockerfile is used to build Docker images, not to define CI workflows.
Option D is wrong because azure-pipelines.yml is for Azure Pipelines, not GitHub Actions.
Your organization uses Azure Pipelines and wants to implement a continuous feedback loop by collecting user analytics from the production environment and automatically creating work items in Azure Boards for critical issues. You need to design a solution that integrates monitoring data with the pipeline. What should you do?
Azure Monitor alerts can be configured from Application Insights metrics or logs, and by setting an action group that invokes a webhook, you can call the Azure Boards REST API to automatically create a work item. This closes the loop by transforming telemetry-driven alerts into actionable backlog items without manual intervention.
Why this answer
Azure Monitor alerts based on Application Insights data can trigger a webhook that calls the Azure Boards REST API to automatically create a work item. This integrates monitoring data with the pipeline to establish a continuous feedback loop. Option A is incorrect because Power BI visualization and email alerts do not automate work item creation.
Option C is incorrect because release pipeline logs are not for collecting user analytics; Application Insights is needed. Option D is incorrect because manually reviewing dashboards is not automated.
Your organization is adopting GitHub Actions for CI/CD. You need to enforce that all workflows must pass required status checks before merging pull requests to the main branch. The repository is in an organization. What should you configure?
Creating a branch protection rule for the main branch with required status checks is the correct solution because it prevents merging until the specified GitHub Actions workflow checks succeed. This enforces CI/CD validation as a hard gate for all pull requests targeting main, ensuring only verified changes are merged.
Why this answer
Branch protection rules in GitHub allow you to enforce required status checks on pull requests before merging. By configuring a branch protection rule for the main branch, you can specify that certain GitHub Actions workflow runs must pass (e.g., CI checks) before a pull request can be merged. This directly enforces the policy that all workflows must pass required status checks.
Exam trap
The trap here is confusing branch protection rules (which enforce merge requirements) with environment protection rules (which control deployment approvals) or CODEOWNERS (which mandate file-level reviews), leading candidates to pick options that address review or permissions rather than status checks.
How to eliminate wrong answers
Option A is wrong because environment protection rules control deployments to specific environments (e.g., production), not pull request merge requirements on a branch. Option B is wrong because setting 'contents: write' permission in a workflow grants write access to repository contents, which is unrelated to enforcing status checks on pull requests. Option C is wrong because a CODEOWNERS file defines who must review changes to specific files, but it does not enforce that workflows must pass before merging; it only requires approval from designated teams or individuals.
Your organization uses Azure DevOps and Azure Key Vault to manage secrets. You have a pipeline that deploys a web app to Azure App Service. The pipeline uses a variable group linked to Key Vault to retrieve the database connection string. Recently, the build started failing with the error: 'Access to Key Vault is denied. Please ensure the service connection has Get and List permissions on secrets.' The service connection uses a service principal. You have verified that the service principal has the correct Key Vault access policy with Get and List permissions. What is the most likely cause of the failure?
The build service identity (project collection or project level) must be granted access to Key Vault for variable group resolution.
Why this answer
The error message indicates that the identity attempting to access Key Vault lacks the required permissions. Even though the service principal has the correct access policy, the pipeline may be using a different identity—the build service identity—to authenticate with Key Vault. In Azure DevOps, when a variable group is linked to Key Vault, the pipeline's build service identity (not the service connection's service principal) must have Get and List permissions on the Key Vault secrets.
This is a common misconfiguration where the service principal is granted permissions but the build service identity is not.
Exam trap
The trap here is that candidates assume the service principal configured in the service connection is the identity used to access Key Vault, but in reality, Azure DevOps uses the build service identity for variable group secret retrieval, leading to a permissions mismatch.
How to eliminate wrong answers
Option A is wrong because the Azure subscription configured in the service connection determines the scope for resource management, but Key Vault access is governed by its own access policies, not subscription-level settings. Option B is wrong because a mismatch between secret names would cause a different error (e.g., 'Secret not found') rather than an access denied error. Option C is wrong because the Contributor role on Key Vault is an Azure RBAC role that grants management-plane permissions (e.g., creating/deleting vaults), not data-plane permissions (e.g., reading secrets); Key Vault access policies or Azure RBAC data-plane roles are required for secret access.
Your organization uses GitHub for source control and Azure Pipelines for CI/CD. You need to implement a policy that requires all pull requests to be built and pass tests before merging. What should you do?
Branch protection rules in GitHub allow requiring status checks to pass before a pull request can be merged. When you require status checks, the pipeline's validation becomes a mandatory gate: any PR that doesn't have a successful status check from the configured pipeline is blocked from merging, directly enforcing the quality gate at the repository level. This is the only option that enforces the requirement at the merge point.
Why this answer
GitHub branch protection rules allow you to require status checks to pass before merging a pull request. By configuring a rule that requires the Azure Pipelines build and test status check to succeed, you enforce that all pull requests are validated before they can be merged into the protected branch.
Exam trap
The trap here is confusing pipeline triggers (which only initiate runs) with merge gating (which enforces that those runs must succeed before merging), leading candidates to select option B instead of A.
How to eliminate wrong answers
Option B is wrong because setting the pipeline trigger to run on pull request only ensures the pipeline runs when a PR is created, but does not enforce that the pipeline must succeed before the PR can be merged. Option C is wrong because pipeline permissions requiring approval control who can run or modify the pipeline, not whether a PR can be merged based on test results. Option D is wrong because a pre-deployment check on an environment gates deployment to that environment, not the merging of a pull request in GitHub.
Match each Azure DevOps security concept to its purpose.
Drag a concept onto its matching description — or click a concept then click the description.
Personal access token for API authentication
Securely stores credentials for external services
Shared variables with optional secret protection
Centralized secure files and variable groups
Why these pairings
Azure AD manages user identities; PATs authenticate scripts; Service Principals authenticate automated services; Security Groups manage user permissions. Common confusions include mixing the roles of Azure AD and Service Principals, or PATs with Security Groups.
Which TWO actions should you take to implement a secure CI/CD pipeline that uses Azure Pipelines and prevents unauthorized access to production? (Choose two.)
Configuring deployment approvals and checks on the production stage is correct because it enforces manual authorization and integrates with Azure Policy or other gates, ensuring that only authorized personnel can approve and promote builds to production, reducing risk of unauthorized deployments.
Why this answer
Deployment approvals and checks in Azure Pipelines require manual sign-off or automated policy validation before a release proceeds to production, preventing unauthorized or unverified changes. Option D is correct because using a service connection with a managed identity eliminates the need to store static credentials, reducing the risk of credential exposure and unauthorized access to Azure resources during deployment.
Exam trap
The trap here is that candidates often confuse secret management (Option A) with access control, or think that PR triggers (Option C) or self-hosted agents (Option E) directly prevent unauthorized production access, when in fact they address different security concerns (secret protection, code validation, and agent isolation) rather than deployment authorization.
You see the above git log output. The team has a policy requiring linear history on the main branch. Which command should be used next time to integrate the feature branch?
Rebase creates linear history; fast-forward merge preserves it.
Why this answer
The team requires a linear history on the main branch. By first rebasing the feature branch onto main (`git rebase main feature/login`), you reapply the feature commits on top of the latest main commit, creating a clean, linear sequence. Then `git merge --ff-only` performs a fast-forward merge, which simply moves the main branch pointer forward without creating a merge commit, preserving the linear history policy.
Exam trap
The trap here is that candidates often confuse `--no-ff` (which preserves history but creates a merge commit) with the requirement for linear history, or they incorrectly think `git cherry-pick` is a valid way to integrate an entire feature branch.
How to eliminate wrong answers
Option A is wrong because `git merge --squash` collapses all feature commits into a single commit, which violates the requirement to integrate the feature branch while preserving its individual commits (the log shows multiple commits). Option B is wrong because `git cherry-pick f4e5d6c a7b8c9d` only applies two specific commits, not the entire feature branch, and it does not integrate the branch in a way that maintains a clean linear history. Option C is wrong because `git merge --no-ff` forces a merge commit even when a fast-forward is possible, which creates a non-linear history (a merge bubble) that violates the linear history policy.
You have a YAML pipeline that uses a self-hosted agent. The agent runs on a VM in Azure. The pipeline fails intermittently with the error: '##[error]The job running on agent MyAgent has been cancelled because the agent was idle for more than the maximum idle time.' You need to resolve this issue. What should you do?
The idle timeout cancels the job if the agent is idle too long; increasing it prevents premature cancellation.
Why this answer
The error indicates that the self-hosted agent was idle for longer than the configured maximum idle time, causing Azure Pipelines to cancel the job. Option A is correct because increasing or disabling the idle timeout setting on the agent (via the agent's configuration file or environment variable) directly addresses this issue by allowing longer periods of inactivity before cancellation.
Exam trap
The trap here is confusing the job-level timeout (pipeline job timeout) with the agent-level idle timeout, leading candidates to incorrectly choose option C instead of recognizing that the error specifically references agent idle time, not job execution duration.
How to eliminate wrong answers
Option B is wrong because adding more agents to the pool does not change the idle timeout setting on any individual agent; it only increases parallelism, which does not prevent a specific agent from being cancelled due to idle time. Option C is wrong because increasing the job's timeout in minutes (pipeline job timeout) controls how long the entire job can run before being cancelled, not the agent's idle timeout, which is a separate agent-level setting. Option D is wrong because reducing parallel jobs may reduce load but does not affect the agent's idle timeout; the agent can still be idle for too long and be cancelled regardless of the number of concurrent jobs.
Your team uses GitHub Actions for CI/CD. You need to collect and analyze build and deployment logs centrally to identify recurring failures. Which service should you use to ingest and query these logs?
Azure Log Analytics is the log ingestion, storage, and query service within Azure Monitor; it can collect GitHub Actions workflow run logs via diagnostic settings or integrations, enabling you to centralize CI/CD logs and analyze them with KQL queries.
Why this answer
Azure Log Analytics is the correct service for centralizing and querying logs from GitHub Actions. It can ingest logs via connectors or API, enabling analysis of build and deployment logs to identify recurring failures. Azure Monitor Alerts (A) is for setting up alerts, not for storing or querying logs.
GitHub Insights (C) provides reporting and analytics for GitHub repositories but is not designed for custom log querying from CI/CD pipelines. Application Insights (D) focuses on application performance monitoring and telemetry, not CI/CD pipeline logs.
Refer to the exhibit. A developer pushes a commit to the main branch. Which stages will run?
The Build stage runs because main is included in the pipeline trigger, and the Test stage is skipped because its condition (e.g., checking for a non-main branch) is false for refs/heads/main. Therefore, only the Build stage executes.
Why this answer
The exhibit shows that the Build stage has a trigger condition that matches the 'main' branch, and the Test stage does not have a trigger condition that is satisfied by the push (e.g., it is set to a different branch condition or to manual). Therefore, when a commit is pushed to main, only the Build stage is triggered automatically; the Test stage does not run.
Exam trap
Candidates often assume all stages in a pipeline run automatically after a commit, but stages can have independent trigger conditions or manual triggers that control whether they run in a given scenario.
How to eliminate wrong answers
Option A is wrong because the Test stage has no trigger condition defined, so it will not run when a commit is pushed to main; only the Build stage runs. Option C is wrong because the Build stage has a trigger condition set to 'main', so it will run when a commit is pushed to main. Option D is wrong because the Test stage does not have a trigger condition, so it will not run alongside the Build stage.
Your team uses Azure Pipelines for CI/CD. You need to ensure that only approved branches can trigger production deployments. Which feature should you use?
Branch control for environments is the correct answer because Azure Pipelines environment checks allow you to restrict which branches or branch types can deploy to that environment. This is done by configuring an approval or branch control check that references an allowed branch list or a required template, thereby enforcing that only authorized branches trigger releases.
Why this answer
Branch control for environments in Azure Pipelines allows you to restrict which branches can trigger deployments to specific environments, such as production. By configuring branch filters on an environment, you ensure that only approved branches (e.g., main or release branches) can initiate a production deployment, providing a security and governance boundary.
Exam trap
The trap here is that candidates often confuse deployment gates (approval checks) with branch-level access control, but gates evaluate conditions during deployment, not which branches are allowed to trigger the deployment in the first place.
How to eliminate wrong answers
Option A is wrong because YAML template expressions are used for parameterization and conditional logic within pipeline definitions, not for restricting which branches can trigger deployments to environments. Option C is wrong because deployment gates are approval checks (e.g., monitoring, manual intervention) that evaluate conditions before or during a deployment, but they do not control which branches can initiate the deployment. Option D is wrong because pipeline decorators inject additional steps or tasks into every pipeline run at the organization or project level, but they cannot enforce branch-based restrictions on environment deployments.
Your organization uses Azure Repos for source control and Azure Pipelines for CI/CD. You need to implement a policy that ensures every commit to the main branch is built and passes all tests before it can be merged. The team uses feature branches for development. What is the most efficient way to enforce this?
A build validation branch policy on main requires a pull request trigger build to complete successfully before merging; if the build fails or has not yet finished, the merge is blocked by server-side enforcement, providing a true quality gate.
Why this answer
Configuring a branch policy on the main branch that requires a successful build from a pull request trigger ensures that every commit to main must be built and pass tests before merging. This is the most efficient automated enforcement. Option A is incorrect because relying on manual builds does not enforce the policy automatically.
Option B is incorrect because a pre-merge validation that does not block merging fails to prevent unvalidated commits. Option D is incorrect because a CI trigger on main runs after merge, not before, so it does not enforce pre-merge validation.
Your organization uses Microsoft Teams for communication. You want to send a notification to a Teams channel when a release pipeline fails. Which action should you configure?
This task sends customizable messages to Teams.
Why this answer
The 'Microsoft Teams Notification' task is a built-in Azure DevOps pipeline task that directly sends customizable notifications to a specified Teams channel when a pipeline event (such as failure) occurs. It requires no external configuration or additional services, making it the simplest and most appropriate choice for sending failure notifications from a release pipeline to Teams.
Exam trap
The trap here is that candidates confuse the 'Microsoft Teams Notification' task (a pipeline task) with a Service Hook subscription (a project-level integration), leading them to choose Option D even though it is not an action configured within the pipeline itself.
How to eliminate wrong answers
Option A is wrong because email notifications target individual or group email addresses, not a Teams channel, and require SMTP configuration; they do not integrate with Teams' messaging infrastructure. Option C is wrong because Azure Monitor alerts are designed for monitoring Azure resources and services, not for reacting to Azure DevOps pipeline events; they would require additional logic and webhook configuration to forward to Teams. Option D is wrong because a Service Hook endpoint for Teams is used to subscribe to Azure DevOps events (like release completion) and send them to a Teams channel via a connector, but it is not a pipeline task; it is configured at the project or collection level, not within the pipeline itself, and requires manual setup of a Teams incoming webhook.
A company has a multi-region application deployed on Azure App Service (Windows) across three regions: West US, East US, and West Europe. The operations team uses Azure Monitor to collect application logs and metrics. Recently, they noticed that the application in West US is experiencing high CPU usage (sustained above 90%) during peak hours, while the other regions remain below 60%. The team has set up an autoscale rule on the App Service plan to scale out when CPU exceeds 80% for 10 minutes. However, autoscale is not triggering, and the application in West US is becoming slow. The team has verified that the autoscale rule is correctly configured, the instance count is below the maximum, and there are no scale-in rules interfering. The metric data appears in Azure Monitor. You suspect that the metric alert that triggers autoscale is not firing. What is the most likely cause?
Azure autoscale requires the rule to reference the correct resource-specific metric namespace (e.g., Microsoft.Compute/virtualMachineScaleSets for VMSS) and metric name such as 'Percentage CPU' with an aggregation of Average over the evaluated time window; specifying a low-level counter like 'CpuTime' or the wrong namespace prevents the metric signal from being recognized, so the scale-out condition never evaluates to true and no scale operation occurs.
Why this answer
The autoscale rule must use the correct metric name and aggregation to evaluate scaling conditions. If the rule is configured with 'CpuTime' instead of 'Percentage CPU', it will not match the actual CPU utilization metric emitted by the Azure App Service plan. 'Percentage CPU' is the standard platform metric for CPU load, while 'CpuTime' measures total CPU time consumed, which does not trigger the same threshold logic. Since the team verified the rule is correctly configured but autoscale is not firing, the most likely cause is a mismatch in the metric name or namespace.
Exam trap
The trap here is that candidates may assume autoscale is failing due to a learning period or data delay, but the real issue is a subtle metric name mismatch that prevents the rule from evaluating the correct data stream.
How to eliminate wrong answers
Option B is wrong because autoscale rules do not require a 24-hour learning period; the 'learning period' applies to predictive autoscale or certain metric-based rules that need historical data, but standard threshold-based autoscale rules evaluate immediately after creation. Option C is wrong because the metric collection interval for CPU on Azure App Service is typically 1 minute, not 30 minutes; a 30-minute interval would be unusual and would cause significant delays, but the question states metric data appears in Azure Monitor, implying normal collection. Option D is wrong because autoscale rules can only use platform metrics or custom metrics from Azure Monitor, not Log Analytics queries directly; Log Analytics queries are used for alert rules, not autoscale conditions.
Your organization must comply with SOC 2 requirements. You are using Azure DevOps and need to ensure that all pipeline runs are logged and that logs are retained for at least one year. Which configuration should you implement?
Audit streaming allows long-term retention and compliance.
Why this answer
SOC 2 requires audit logging and retention of pipeline execution history for at least one year. Azure DevOps audit streaming sends all audit events (including pipeline runs) to a Log Analytics workspace, where you can set a retention policy of 365 days. This satisfies both the logging and retention requirements without relying on pipeline-level retention settings that only cover build artifacts and logs, not audit events.
Exam trap
The trap here is that candidates confuse pipeline log retention (Option A) with audit log retention, not realizing that SOC 2 compliance requires immutable audit trails of all pipeline executions, not just the output logs of a build.
How to eliminate wrong answers
Option A is wrong because increasing the retention period of pipeline logs in the Azure DevOps UI only affects build and release logs, not the audit trail of who ran the pipeline or when; SOC 2 requires audit-level logging, not just pipeline log retention. Option B is wrong because configuring diagnostic settings for the Azure DevOps organization is not a valid action—Azure DevOps does not expose diagnostic settings at the organization level; audit streaming is the correct mechanism to send audit data to Log Analytics. Option C is wrong because disabling the option to delete pipelines does not create or retain audit logs; it only prevents manual deletion of pipeline definitions, which has no impact on logging or retention requirements.
Which TWO actions can you take to improve the security of secrets in Azure Pipelines? (Choose two.)
Scoping variable group access to only the specific pipelines that require those secrets reduces the attack surface and enforces least privilege. Azure DevOps pipeline permissions on variable groups ensure unauthorized pipelines cannot consume or expose the linked secrets.
Why this answer
Limiting variable group permissions to specific pipelines ensures that only authorized pipelines can access sensitive secrets, reducing the risk of unauthorized exposure. Option D is correct because Azure Key Vault provides a centralized, auditable, and encrypted store for secrets, and mapping them as secret variables in Azure Pipelines prevents the secret values from being exposed in logs or output.
Exam trap
The trap here is that candidates may think overriding secrets at queue time (Option C) is a valid security feature, but it actually undermines security by allowing users to bypass the approved secret store and inject arbitrary values.
Your team uses Azure Pipelines for CI/CD. You need to enforce that all pipeline runs use approved agents from a specific agent pool with the latest security patches. The agents are self-hosted on Azure VMs. What should you implement?
Correct. By adding a demand for a custom capability that only approved agents have (e.g., 'SecurityPatchLevel = latest'), the pipeline will only run on agents meeting that requirement.
Why this answer
By adding a demand for a custom capability (e.g., 'SecurityPatchLevel = latest') on the pipeline, only agents that possess that capability can run the pipeline. This allows you to enforce that only approved, patched agents are used. Option C is incorrect because 'setting an agent pool to use a specific agent queue with an isolation scope' is not a recognized Azure Pipelines feature; agent pools use demands, not isolation scopes, to filter agents.
Options A and B are also incorrect because configuring pool permissions or creating a deployment pool does not enforce that only agents with specific patches are used; they only control access or assignment but not the selection logic based on capabilities.
Exam trap
The trap is that candidates may think that using a dedicated agent queue or deployment pool will automatically limit which agents can run the pipeline. However, without a custom capability demand, any agent in the pool could be matched to the job. The correct approach is to define a custom capability for 'SecurityPatchLevel' or similar and add a demand to the pipeline.
How to eliminate wrong answers
Option A is wrong because configuring pipeline permissions for the agent pool controls who can use the pool, but does not enforce that only agents with the latest security patches are selected; it manages access, not agent eligibility. Option B is wrong because a deployment pool is designed for managing deployment targets (e.g., VMs for releases), not for controlling which build agents are used in pipeline runs; it does not enforce agent patching or approval. Option D is wrong because adding a demand for a custom capability only filters agents based on that capability label, but it does not inherently ensure the agent has the latest security patches unless the capability is manually and reliably updated, which is error-prone and not a built-in enforcement mechanism.
Which TWO practices are recommended for managing secrets in Azure Pipelines?
This keeps secrets out of the repository.
Why this answer
Azure Pipelines allows you to define secret variables in the pipeline UI (or via the Azure DevOps CLI) and mark them as secret. When marked as secret, the value is encrypted at rest, masked in logs, and never exposed to the pipeline YAML or output. This is the recommended practice for managing sensitive data like API keys or passwords directly within the pipeline.
Exam trap
The trap here is that candidates often confuse the ability to define variables in YAML with the ability to define secret variables in YAML, not realizing that Azure Pipelines explicitly prohibits storing secret values in YAML files to prevent repository exposure.
Your organization uses Azure DevOps for a large-scale e-commerce platform. The source code is stored in a single Azure Repos Git repository with over 100 contributors. The current branching strategy is a modified GitFlow with main, develop, release, and hotfix branches. However, the team is experiencing frequent merge conflicts and long integration periods. You have been asked to redesign the branching strategy to support continuous integration and deployment (CI/CD) while ensuring high-quality releases. The new strategy must reduce merge conflicts, enable fast feedback, and support hotfixes. The team uses feature flags to manage incomplete features. Which branching strategy should you recommend?
Trunk-based development (TBD) with short-lived feature branches merged multiple times per day minimizes merge conflicts because branches diverge for hours, not weeks; feature flags decouple deployment from release, letting incomplete work ship safely behind toggles, and hotfix branches cut from main can be merged and deployed immediately, keeping main always in a releasable state and enabling continuous integration and continuous delivery.
Why this answer
Trunk-based development with short-lived feature branches (less than a day) and frequent merging to main directly addresses the team's merge conflicts and long integration periods. Feature flags allow incomplete features to be merged safely, enabling continuous integration and fast feedback. Hotfixes from main are simple and quick.
Option B is wrong because committing directly to main without branches increases risk of breaking the main branch, even with CI, and does not provide isolation for work-in-progress. Option C is wrong because using release branches introduces long-lived branches and delays integration, contrary to the need for fast feedback and continuous deployment. Option D is wrong because GitFlow's long-lived feature and release branches are the root cause of the frequent merge conflicts and integration delays.
Your team uses GitHub Actions to deploy a microservices application to a Kubernetes cluster. The workflow builds Docker images and pushes them to a container registry, then updates the Kubernetes deployment. The deployment often fails due to image pull errors, specifically 'ErrImagePull' and 'ImagePullBackOff'. You investigate and find that the image tag in the Kubernetes manifest is the commit SHA. The workflow uses the 'azure/k8s-deploy@v1' action. You suspect that the image is not being pulled because the registry credentials are not properly configured. You have stored the registry credentials as secrets. What is the most likely cause and solution?
The 'azure/k8s-deploy' action only applies Kubernetes manifests, treating them as static YAML; it does not create or inject imagePullSecrets into the cluster. When pulling images from a private registry like ACR, Kubernetes requires a docker-registry secret (type kubernetes.io/dockerconfigjson) containing credentials, and your deployment spec must explicitly reference that secret under `imagePullSecrets`. Because the action simply runs `kubectl apply`, it cannot authenticate the kubelet on the cluster's behalf, so you must add a prior step to create the secret (e.g., using `kubectl create secret docker-registry`) and ensure it is referenced in the deployment manifest.
Why this answer
The 'azure/k8s-deploy@v1' action deploys to Kubernetes but does not automatically create imagePullSecrets for private container registries. Even if the registry credentials are stored as secrets in GitHub, they are not automatically applied to the cluster. You must explicitly create a Kubernetes secret of type docker-registry and add an imagePullSecrets entry to the deployment manifest.
Option A is wrong because using 'latest' tag is not a best practice and does not address authentication. Option B is wrong because the image name is likely correct; the issue is pulling due to lack of credentials. Option C is wrong because the action does support private registries when credentials are properly configured.
Your organization requires that all code changes be signed using a valid code signing certificate before they can be merged. Which feature in GitHub should you enable to enforce this?
Commit signature verification requires each commit to be cryptographically signed with a verified key (e.g., GPG, SSH, or S/MIME) and the signature to be verified by the repository host. Enabling this in Azure Repos or GitHub protects the integrity and authenticity of every change, directly ensuring that all code changes are signed.
Why this answer
Commit signature verification in GitHub enforces that commits are signed with a verified GPG or S/MIME key, which meets the requirement of signing code changes. Option A is wrong because Dependabot handles dependency updates, not signature enforcement. Option C is wrong because code scanning analyzes code for vulnerabilities, not for commit signatures.
Option D is wrong because secret scanning detects secrets in repositories, not signature enforcement.
Your organization uses GitHub Advanced Security. A developer reports that a secret scanning alert for an Azure DevOps Personal Access Token (PAT) is a false positive. What should you do to handle this?
Marking the alert as false positive in the GitHub UI correctly dismisses the alert for that specific detected secret and provides feedback that helps reduce future false positives. This is the intended workflow when you determine the secret is not a real credential, such as a test value or sample string.
Why this answer
Marking the alert as a false positive in the GitHub UI closes the alert and helps train the detection algorithm for future scans. Option A is incorrect because disabling secret scanning entirely would stop detection for all secrets, which is not appropriate for a single false positive. Option B is incorrect because deleting the PAT might be necessary if it were real, but since it's a false positive, it is unnecessary and could break functionality.
Option D is incorrect because ignoring the alert leaves it open and does not resolve the false positive.
You have a YAML pipeline that builds a .NET application. You want to cache the NuGet packages to speed up subsequent builds. Which task should you use?
This is correct because the Cache task supports a key derived from the hash of packages.lock.json, which uniquely identifies the exact set of dependencies. When the key matches a previously saved cache, the packages folder is restored immediately, and after the build it is saved again, significantly improving restore time.
Why this answer
The Cache task in Azure Pipelines allows you to cache NuGet packages by specifying a key derived from the hash of `packages.lock.json`. This ensures that the cache is invalidated only when the lock file changes, which accurately reflects changes in package dependencies. The cached `~/.nuget/packages` folder is then restored on subsequent runs, significantly reducing restore time.
Exam trap
The trap here is that candidates confuse the NuGet restore task's built-in caching (which is not a parameter) with the separate Cache task, or they mistakenly believe that copying or publishing artifacts achieves caching for subsequent builds.
How to eliminate wrong answers
Option A is wrong because the CopyFiles task merely copies files to a staging directory; it does not implement caching logic or persist packages across pipeline runs. Option B is wrong because the NuGet restore task does not have a 'cacheRestore' option; caching is handled by a separate Cache task, not by a parameter on the restore task. Option D is wrong because the PublishBuildArtifacts task uploads artifacts to Azure Pipelines or a file share, but it does not cache packages for reuse in future builds; it is intended for sharing build outputs, not for dependency caching.
A development team is designing a build pipeline for a microservices application. They want to ensure that each service is built and tested independently, but they also need to run integration tests that span multiple services. What is the recommended approach?
Individual build pipelines per service enable each team to build, version, and test independently, while a dedicated release pipeline that deploys all services to an integration environment validates cross-service contracts and interactions in a realistic environment, combining independence with necessary integration assurance.
Why this answer
It aligns with microservices best practices: each service has its own build pipeline for independent compilation, unit testing, and artifact generation, while a separate release pipeline orchestrates deployment of all services to a shared integration environment for cross-service testing. This decouples build concerns from deployment concerns, enabling parallel development and faster feedback loops.
Exam trap
The trap here is that candidates confuse 'building independently' with 'testing independently' and assume integration tests must be run within the build pipeline, when in fact they should be run in a separate release pipeline after deployment to a shared environment.
How to eliminate wrong answers
Option A is wrong because using a single release pipeline with manual deployment for each service introduces human delay and inconsistency, and it does not address independent building or automated integration testing. Option B is wrong because a single build pipeline that builds all services together violates the microservices principle of independent deployability, creating tight coupling and longer build times. Option D is wrong because skipping integration tests entirely defeats the purpose of verifying inter-service communication and data consistency, which is critical in a microservices architecture.
Your team uses Azure Pipelines and wants to automatically create a release every time a build succeeds on the main branch. Which trigger should you configure?
A build completion trigger in a release pipeline is the correct choice because it automatically starts a release as soon as a specified build pipeline finishes successfully. This is the standard mechanism to deploy the artifacts produced by a CI build, enabling a fully automated build-and-release workflow.
Why this answer
A build completion trigger in the release pipeline allows you to automatically create a release whenever a specific build pipeline succeeds on the main branch. This trigger monitors the build pipeline for successful completions and initiates the release process, which directly matches the requirement of creating a release after every successful build on main.
Exam trap
The trap here is that candidates often confuse CI triggers (which apply to build pipelines) with release triggers, leading them to incorrectly select option B, not realizing that release pipelines use build completion triggers instead of CI triggers.
How to eliminate wrong answers
Option A is wrong because a pull request trigger in the build pipeline is used to automatically run a build when a PR is created or updated, not to create a release after a build succeeds. Option B is wrong because continuous integration (CI) triggers in release pipelines are not a valid concept; CI triggers exist in build pipelines to trigger builds on code changes, not to trigger releases. Option D is wrong because a scheduled trigger in the release pipeline runs releases on a fixed time schedule, not in response to a successful build on the main branch.
Your team uses GitHub Actions to build a multi-container application. The build must produce container images that are scanned for vulnerabilities and signed. Which THREE actions are required in the workflow?
Adding a step to run Trivy scans the container image for known vulnerabilities in OS packages and application dependencies. Trivy integrates into GitHub Actions via aquasecurity/trivy-action, can fail the build based on severity thresholds, and generates a SARIF report for GitHub code scanning, making it the correct step for a security scanning requirement.
Why this answer
To produce container images that are scanned for vulnerabilities and signed, the workflow must include steps to scan the image (e.g., using Trivy), sign the image (e.g., using cosign), and build and push the image (e.g., using docker/build-push-action). Option A is not required because authenticating to Docker Hub specifically is not necessary if the target registry is not Docker Hub. Option D is not strictly required; checking out the code is a common first step but could be done differently or may already be available.
Your team uses a YAML-based build pipeline in Azure Pipelines. You need to ensure that the pipeline runs automatically when a pull request is created against the main branch, but only if the changes include modifications to the 'src/' directory. Which trigger configuration should you use?
This is the correct configuration because it disables CI triggers entirely (trigger: none) and defines a PR trigger that runs only for pull requests targeting the main branch and only when changes occur under the src/ path. This filters out irrelevant PRs, ensuring the pipeline runs precisely when code in src/ is modified, saving resources and providing focused validation.
Why this answer
It sets `trigger: none` to disable CI triggers on commits, and uses a PR trigger with `branches: include: - main` and `paths: include: - src/*` to ensure the pipeline only runs automatically when a pull request targets the main branch and the changes include modifications to the 'src/' directory. This configuration meets the requirement of conditional PR-triggered builds based on file paths.
Exam trap
The trap here is that candidates often confuse CI triggers (`trigger`) with PR triggers (`pr`) and forget that path filtering must be explicitly specified under the PR trigger to restrict which file changes initiate the pipeline.
How to eliminate wrong answers
Option A is wrong because it sets a CI trigger on main (trigger: - main) and disables PR triggers (pr: none), so the pipeline would run on every commit to main, not only on pull requests. Option C is wrong because it sets `trigger: none` and `pr: - main` without a `paths` filter, so the pipeline would run on any pull request to main, regardless of whether changes are in 'src/'. Option D is wrong because it sets both CI and PR triggers on main without a `paths` filter, causing the pipeline to run on every commit to main and on every pull request to main, not only when 'src/' changes.
A team uses Git for source control. They want to automatically squash all commits in a feature branch into a single commit when merging to the main branch. Which merge type should they use?
Squash commit is correct because it merges the feature branch by combining all of its changes into a single new commit on the target branch. This collapses the entire commit history of the feature into one commit, exactly matching the requirement to combine all changes into a single commit.
Why this answer
B is correct because the squash commit merge type collapses all commits in a feature branch into a single new commit on the target branch. This satisfies the requirement to automatically squash all commits when merging to main, as it creates a clean, linear history with one combined commit that contains all changes from the feature branch.
Exam trap
The trap here is that candidates often confuse 'squash commit' with 'rebase and fast-forward' because both can produce a linear history, but only squash commit collapses multiple commits into one.
How to eliminate wrong answers
Option A is wrong because rebase and fast-forward replays each individual commit from the feature branch onto the tip of main, preserving the full commit history rather than squashing them into one. Option C is wrong because merge commit (no fast-forward) creates a merge commit that preserves all individual commits from the feature branch, resulting in a non-linear history with multiple commits. Option D is wrong because semi-linear merge (also called rebase merge) first rebases the feature branch onto main and then creates a merge commit, but still retains all original commits from the feature branch instead of squashing them.
Refer to the exhibit. A developer runs the pipeline on a branch called 'feature/abc'. What will happen?
Only the Build stage will execute because the Build stage has no condition (or an unconditional condition), so it runs on every branch. The Deploy stage has a condition that restricts it to the main branch (e.g., eq(variables['Build.SourceBranch'], 'refs/heads/main')), which evaluates to false on the o50p branch, causing the entire Deploy stage to be skipped.
Why this answer
The 'Deploy' stage has a condition that checks if the source branch is 'refs/heads/main'. Since the branch is 'feature/abc', the condition evaluates to false, so the Deploy stage will be skipped. The Build stage runs regardless.
The pipeline above fails with: 'The deployment job 'DeployToProd' references environment 'Production' which does not exist.' What should you do to resolve this error?
The deployment job fails because it references an environment named 'Production' that does not yet exist in the Azure DevOps project. You must create the environment in Project Settings > Pipelines > Environments before running the pipeline; this provides the required resource for deployment job execution and enables tracking, approvals, and security on that environment.
Why this answer
The error indicates that the Azure DevOps pipeline references an environment named 'Production' that does not exist in the project. Environments must be explicitly created in Azure DevOps project settings before they can be used in deployment jobs. Option D resolves this by creating the required environment, allowing the deployment job to target it correctly.
Exam trap
The trap here is that candidates may think a script step can dynamically create the environment before the deployment job runs, but Azure DevOps validates environment references at pipeline compile time, not runtime, so the environment must already exist.
How to eliminate wrong answers
Option A is wrong because removing the 'environment' property would eliminate the deployment target, which is likely required for approvals, checks, and traceability; the pipeline would then fail to deploy to the intended stage. Option B is wrong because changing the deployment strategy from 'runOnce' to 'rolling' does not address the missing environment; it only alters how resources are updated during deployment, not the existence of the environment itself. Option C is wrong because environments cannot be created dynamically via a script step in a pipeline; they must be pre-created in Azure DevOps project settings or via the REST API, and a script step cannot create an environment that the deployment job references at parse time.
Your team is using Azure Pipelines to deploy a web application to Azure App Service. The application uses a configuration file (appsettings.json) that contains environment-specific settings. You need to manage these settings across development, staging, and production environments without exposing secrets in the source code. The pipeline should automatically replace the settings during deployment. What should you configure?
The File Transform task is the correct choice because it directly performs token replacement in configuration files like appsettings.json, using variable values from pipeline variable groups. It supports both standard and secret variables, so connection strings and API keys can be injected at release time without exposing them in the repository.
Why this answer
Use the 'File Transform' task to substitute variables from pipeline variables or variable groups. Option B is incorrect because build configuration transforms are for .NET projects and require specific setup. Option C is incorrect because environment variables are not directly used for file transforms.
Option D is incorrect because Azure App Service application settings are for the runtime, not for transforming configuration files during deployment.
Refer to the exhibit. You have an Azure Pipelines YAML file for a .NET Core application. The pipeline is triggered on changes to the main branch, but only for files under src/. After a push to main that modifies a file in src/, the pipeline does not start. What is the most likely reason?
Path filters in Azure Pipelines follow minimatch semantics, where a single asterisk (*) matches characters within a path segment but not directory separators. Consequently, 'src/*' only matches files directly inside 'src' and does not match files in subdirectories like 'src/WebApplication/Program.cs', so the trigger will not fire for changes in subdirectories.
Why this answer
The path filter `src/*` uses a single asterisk, which only matches files directly within the `src/` directory, not files in subdirectories (e.g., `src/app/main.cs`). Azure Pipelines path filters require a double asterisk `src/**` to recursively match all files under `src/`. Since the modified file is in a subdirectory, the trigger condition is not met, and the pipeline does not start.
Exam trap
The trap here is that candidates confuse the single asterisk `*` with the recursive double asterisk `**`, assuming `src/*` matches all files under `src/` including subdirectories, which is incorrect in Azure Pipelines path filters.
How to eliminate wrong answers
Option A is wrong because branch filters in Azure Pipelines YAML triggers do not require the 'refs/heads/' prefix; the branch name alone (e.g., 'main') is sufficient. Option B is wrong because the correct keyword is 'include' (not 'includes'), and 'include' is valid syntax for path filters in YAML triggers. Option C is wrong because the variable 'buildConfiguration' is defined later in the YAML (under variables) and does not need to be at the top level; its absence does not prevent the trigger from firing.
Your team wants to implement a policy that requires all pull requests to have at least one approval from a member of the 'Senior Developers' group before merging. Which mechanism should you use?
A branch policy on the target branch that requires a minimum number of reviewers from the Senior Developers group enforces that at least that many senior devs must approve before the PR can be completed, and you can also set it to block merge until their approvals are obtained.
Why this answer
Azure Repos branch policies allow you to enforce required reviewers on pull requests. By creating a branch policy on the target branch that requires a minimum number of reviewers from the 'Senior Developers' group, you ensure that no pull request can be completed without at least one approval from that group. This directly meets the requirement without relying on file-level ownership or external scripts.
Exam trap
The trap here is that candidates confuse CODEOWNERS (which only requests reviews) with a branch policy that enforces required approvals, leading them to choose option A even though it does not block merging without the required approval.
How to eliminate wrong answers
Option A is wrong because a CODEOWNERS file designates owners for specific files and automatically requests their review, but it does not enforce a minimum number of approvals from a group before merging; it only notifies them. Option C is wrong because configuring the pull request dashboard to display required reviewers is a UI customization that does not enforce any policy or block merging. Option D is wrong because a build validation policy runs a script to validate code quality or compliance, but it cannot enforce a specific number of human approvals from a group; it is meant for automated checks, not reviewer requirements.
Your team uses Azure Repos and wants to enforce that all commits to the release branch must be signed using GPG. Which branch policy should you enable?
Requiring signed commits is the policy that enforces each commit to be cryptographically signed with GPG or S/MIME, thereby verifying the identity of the committer and ensuring the commit content has not been tampered with. This directly fulfills the goal of enforcing that all commits are signed.
Why this answer
Azure Repos branch policies include a 'Require signed commits' setting that enforces GPG signature verification on all commits pushed to the branch. When enabled, any commit without a valid GPG signature is rejected, ensuring the integrity and authenticity of the commit author.
Exam trap
The trap here is that candidates may confuse 'Require signed commits' with other authentication or authorization policies, such as requiring reviewers or limiting merge types, because all are listed under branch policy settings but serve entirely different security purposes.
How to eliminate wrong answers
Option A is wrong because 'Limit merge types' controls the merge strategies (e.g., squash, rebase, or no-fast-forward) allowed on the branch, not commit signing. Option B is wrong because 'Check for linked work items' enforces that pull requests reference Azure Boards work items, which is unrelated to cryptographic commit signing. Option C is wrong because 'Require a minimum number of reviewers' mandates a certain count of reviewers approve a pull request before merging, but does not enforce that individual commits are signed with GPG.
You are designing a branching strategy for a microservices application with independent deployment cadences. The team wants to support continuous deployment to production from the main branch while allowing feature work to be isolated and tested. Which branching strategy best meets these requirements?
Trunk-based development with short-lived feature branches (typically less than a day) ensures that all developers integrate into main frequently, which minimizes merge conflicts, enables continuous integration, and supports rapid, automated deployment of microservices while still isolating work in progress via feature branches that are merged and deleted quickly.
Why this answer
Trunk-based development with short-lived feature branches (C) is correct because it enables continuous deployment from the main branch while isolating feature work in branches that are merged back to main within hours or a day. This approach minimizes merge conflicts and supports independent deployment cadences for microservices, as each service can be deployed from main independently without waiting for release branches.
Exam trap
The trap here is that candidates confuse GitHub Flow with trunk-based development, but GitHub Flow lacks the strict short-lived branch discipline and feature toggle support required for true continuous deployment from main in a microservices context.
How to eliminate wrong answers
Option A is wrong because one branch per environment (dev, test, prod) creates long-lived branches that diverge over time, leading to merge hell and preventing continuous deployment from a single source of truth. Option B is wrong because GitHub Flow with feature branches merging to main does not inherently support independent deployment cadences for microservices; it assumes a single deployment pipeline and can cause blocking if multiple features are merged before validation. Option D is wrong because Git Flow with develop, release, and hotfix branches introduces long-lived branches and release cycles that conflict with continuous deployment to production from main, as releases are staged through develop and release branches rather than directly from main.
Practice AZ-400 by domain
Target a specific domain to shore up weak areas.