CCNA Design and implement build and release pipelines Questions — Page 2 of 6

MCQeasy

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

A.Add an approval gate that requires a manager to approve the release.

B.Add a deployment gate that checks the source branch.

C.Add a branch filter to the release pipeline's artifact trigger.

D.Add a branch filter to the build pipeline trigger.

AnswerC

In Azure Pipelines, a release pipeline's artifact trigger can be configured with a branch filter to specify which branches of the source repository are allowed to initiate a release. When you add a branch filter under the artifact trigger of the release pipeline, only builds from those branches (or builds that match the filter) will cause a release to be created, directly meeting the requirement to restrict which branches can trigger a release.

Why this answer

A branch filter on the release pipeline's artifact trigger allows you to specify which branches of the source artifact (e.g., a build pipeline) should automatically trigger a release. By configuring this filter to only include branches like 'main' or 'release/*', you ensure that only builds from those specific branches can initiate a release to production, providing precise control over deployment triggers.

Exam trap

The trap here is confusing branch filters on build pipeline triggers (which control when code is built) with branch filters on release pipeline artifact triggers (which control when releases are created from those builds), leading candidates to incorrectly select Option D.

How to eliminate wrong answers

Option A is wrong because an approval gate requires a manager to approve the release after it is triggered, but it does not restrict which branches can trigger the release; any branch could still initiate the release, and the gate only adds a manual approval step. Option B is wrong because a deployment gate checks conditions (like source branch) at deployment time, but it does not prevent the release from being triggered; it only evaluates whether to proceed with the deployment after the release is already created. Option D is wrong because a branch filter on the build pipeline trigger controls which branches trigger a build, not which branches trigger a release; this would affect when code is compiled, not when a release is deployed to production.

Practice this question →

MCQeasy

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

A.condition: ne(variables['Build.SourceBranch'], 'refs/heads/main')

B.condition: contains(variables['Build.SourceBranch'], 'main')

C.condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))

D.condition: eq(variables['Build.SourceBranch'], 'refs/heads/main')

AnswerD

This condition uses eq() to perform an exact string comparison against the full source ref 'refs/heads/main'. In Azure Pipelines, Build.SourceBranch contains the full ref, so this matches only the actual main branch and excludes all others, including branches that merely contain 'main' as a substring. It is the precise, minimal condition that satisfies the requirement without adding extra behavior such as succeeded() checks.

Why this answer

The `eq(variables['Build.SourceBranch'], 'refs/heads/main')` condition evaluates to true only when the pipeline is triggered by a change to the 'main' branch. In YAML pipelines, conditions are evaluated as expressions, and this simple equality check ensures the stage runs exclusively for that branch. The other options either invert the logic, use a partial match that could include other branches, or unnecessarily combine conditions.

Exam trap

The trap here is that candidates often choose option B (`contains`) thinking it is a simpler way to match the branch, but they overlook that `contains` does a substring match and will incorrectly trigger on branches like 'maintenance' or 'main-feature', whereas the exact ref comparison in option D is the precise and safe approach.

How to eliminate wrong answers

Option A is wrong because `ne(variables['Build.SourceBranch'], 'refs/heads/main')` runs the stage when the source branch is NOT 'main', which is the opposite of the requirement. Option B is wrong because `contains(variables['Build.SourceBranch'], 'main')` would match any branch containing 'main' in its ref path (e.g., 'refs/heads/main-feature' or 'refs/heads/notmain'), not just the exact 'main' branch. Option C is wrong because while it correctly checks for 'main', it adds `and(succeeded(), ...)` which is redundant since stages default to running only if the previous stage succeeded; this extra condition does not break the logic but is unnecessary and not the simplest correct answer.

Practice this question →

MCQeasy

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

A.Set the 'Continue on error' option to false for the test task.

B.Add a custom condition to the test task to only run if previous tasks succeeded.

C.Set the 'Always run' option for the test task.

D.Ensure the task control option 'Run this task' is set to 'Only when all previous tasks have succeeded'.

AnswerA

'Continue on error' true allows continuation; false stops the task but not necessarily the pipeline.

Why this answer

To stop the pipeline immediately when a test task fails, you must ensure that the task's 'Continue on error' option is false (unchecked). This is the task control option that determines whether a task failure is ignored. When 'Continue on error' is false, a failed task causes the pipeline to stop and subsequent tasks with the default run condition ('Only when all previous tasks have succeeded') will not run.

Setting 'Run this task' to 'Only when all previous tasks have succeeded' is the default and only controls whether the test task runs based on prior task results; it does not directly affect what happens after the test task fails. Therefore, option A is the correct configuration.

Exam trap

This question tests knowledge of task control options in Azure Pipelines. 'Continue on error' and 'Run this task' are separate settings. A common trap is confusing 'Run this task' (which controls when a task runs) with 'Continue on error' (which controls what happens after a task fails).

Practice this question →

MCQmedium

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

A.Define an environment with approvals required for the production stage.

B.Use deployment gates in the production stage to check for manual intervention.

C.Use a classic release pipeline with pre-deployment approvals.

D.Configure a branch policy on the main branch to require approval for pull requests.

AnswerA

Defining an environment and enabling the approval check on its production stage is the correct way to require a manual sign-off before deployment. This approval is configured on the environment itself and naturally integrates with multi-stage YAML pipelines, ensuring that only authorized users can deploy to production.

Why this answer

Azure Pipelines allows you to define environments with explicit approval checks. By adding a manual approval gate on the production environment stage, the pipeline will automatically deploy to staging after a successful build, but pause before production until an authorized user approves the release. This directly meets the requirement for automated staging deployment and manual production approval.

Exam trap

The trap here is that candidates often confuse deployment gates (which are automated checks) with manual approvals, leading them to incorrectly select Option B, even though gates cannot provide the required manual intervention step.

How to eliminate wrong answers

Option B is wrong because deployment gates are designed for automated health checks (e.g., monitoring metrics, incident status) and do not support manual intervention; they evaluate conditions automatically, not wait for human approval. Option C is wrong because classic release pipelines with pre-deployment approvals are a legacy approach that still works, but the question asks for a strategy in the context of modern YAML-based multi-stage pipelines, where environment approvals are the recommended method. Option D is wrong because branch policies on the main branch control pull request merges and code quality, not release deployment approvals; they are unrelated to the release pipeline's manual approval requirement.

Practice this question →

MCQhard

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

A.Hardcode credentials in the script and encrypt the script file

B.Store credentials as pipeline variables and reference them

C.Use Azure Key Vault task to fetch secrets during deployment

D.Use environment variables on the target machines

AnswerC

The Azure Key Vault task securely retrieves secrets from Key Vault at deployment time and injects them as variables, ensuring that credentials are not stored in the pipeline or exposed in logs while centralizing access and enabling rotation.

Why this answer

The Azure Key Vault task securely retrieves secrets (e.g., passwords) from an Azure Key Vault during deployment, avoiding hardcoded or exposed credentials. This integrates with Azure Pipelines to pass secrets to scripts without storing them in the pipeline or on target machines, adhering to least-privilege and secure secret management practices.

Exam trap

The trap here is that candidates may choose Option B (pipeline variables) thinking they are secure because they can be marked as secret, but they lack the centralized management, rotation, and access control that Azure Key Vault provides, which is the recommended approach for production secrets.

How to eliminate wrong answers

Option A is wrong because hardcoding credentials in a script, even if encrypted, violates security best practices and is difficult to rotate or audit; encryption keys can be compromised. Option B is wrong because pipeline variables, even marked as secret, are stored in the pipeline definition and can be exposed in logs or export operations, and they do not provide centralized secret management. Option D is wrong because environment variables on target machines are static, not centrally managed, and can be read by any process or user on the machine, leading to credential leakage.

Practice this question →

MCQeasy

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

A.Define pipeline stages with environment resources and pre-deployment approvals.

B.Use environment resources with 'auto' trigger and no approvals.

C.Use classic release pipelines with approval gates per environment.

D.Use a custom PowerShell script to pause and prompt for approval.

AnswerA

Defining stages with environment resources and pre-deployment approvals is the correct approach because each environment maps to a resource in Azure DevOps, and pre-deployment approvals provide a built-in, auditable manual sign-off before the deployment proceeds, making it the native and recommended YAML pipeline pattern.

Why this answer

Azure Pipelines supports multi-stage YAML pipelines where each stage can reference an environment resource. Pre-deployment approvals are configured on the environment itself, ensuring that before a stage deploys to that environment, the specified approvers must grant approval. This provides a native, auditable, and integrated approval gate without custom scripting or legacy tooling.

Exam trap

The trap here is that candidates may think classic release pipelines are still the best practice, but Microsoft has not deprecated classic releases; they are legacy and Microsoft recommends YAML pipelines with environment resources for better traceability, consistency, and integration with modern DevOps practices.

How to eliminate wrong answers

Option B is wrong because using 'auto' trigger with no approvals would automatically deploy to each environment without any manual intervention, failing the requirement for approval before deployment. Option C is wrong because classic release pipelines are a legacy approach; while they do support approval gates, the modern and recommended approach for multi-environment sequential deployments is to use YAML pipelines with environment resources and pre-deployment approvals. Option D is wrong because using a custom PowerShell script to pause and prompt for approval is brittle, non-auditable, bypasses the built-in approval workflow, and does not integrate with Azure Pipelines' environment resource tracking or deployment history.

Practice this question →

MCQmedium

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

A.Increase the number of parallel jobs in the organization.

B.Use more pipeline triggers.

C.Provision self-hosted agents.

D.Reduce the number of parallel jobs.

AnswerC

Self-hosted agents are owned and managed by your team, providing dedicated compute capacity that operates independently of Microsoft's hosted agent pool. By registering self-hosted agents in an agent pool that your pipelines target, you can scale out processing capacity and reduce or eliminate queue waiting times, especially for high-frequency builds.

Why this answer

Microsoft-hosted agents share a global pool with other Azure DevOps organizations, so queue times increase during peak usage. Provisioning self-hosted agents gives you dedicated compute resources that are always available, eliminating dependency on the shared pool and reducing queue wait times.

Exam trap

The trap here is that candidates confuse 'parallel jobs' (concurrency limit) with 'agent availability' (queue wait time), assuming that buying more parallelism will speed up agent assignment when it only affects how many builds can run at once.

How to eliminate wrong answers

Option A is wrong because increasing parallel jobs only allows more builds to run concurrently once they start, but does not reduce the time a build waits in the queue for an available agent. Option B is wrong because pipeline triggers control when a build is initiated, not how quickly an agent is assigned to run it; more triggers could actually increase queue congestion. Option D is wrong because reducing parallel jobs would decrease the number of builds that can run simultaneously, likely increasing queue times further.

Practice this question →

MCQmedium

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

A.Add a branch protection rule that requires status checks to pass.

B.Enable 'Require approval for all workflows' in the organization settings.

C.Set the workflow to be required in the 'Require status check' settings of each pull request.

D.Create a repository ruleset that requires linear history.

AnswerA

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

Why this answer

Branch protection rules in GitHub Enterprise Cloud allow you to require status checks to pass before merging a pull request. By configuring a branch protection rule on the target branch (e.g., main) and selecting the specific GitHub Actions workflow status checks that must succeed, you enforce that all required CI/CD checks pass before a merge is allowed. This directly meets the requirement to enforce workflow checks on pull requests.

Exam trap

The trap here is confusing organization-level workflow approval settings (which control workflow execution) with branch-level status check requirements (which control merge permissions), leading candidates to select option B or C instead of the correct branch protection rule.

How to eliminate wrong answers

Option B is wrong because 'Require approval for all workflows' is a setting that controls whether external contributors' workflows require approval before running, not a mechanism to enforce status checks on pull requests. Option C is wrong because there is no 'Require status check' setting on individual pull requests; status checks are configured at the branch or repository level via branch protection rules or rulesets. Option D is wrong because requiring linear history enforces a linear commit history (e.g., via rebase or squash merges) but does not enforce that workflows pass checks before merging.

Practice this question →

Multi-Selecthard

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

Select 3 answers

A.Restrict agent pool permissions to only necessary users

B.Use Microsoft Entra ID to control access to pipelines

C.Store secrets as plain text in YAML files

D.Use variable groups with Azure Key Vault integration for secrets

E.Run build agents on domain controllers

AnswersA, B, D

Least privilege principle applies to agent pools.

Why this answer

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

Exam trap

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

Practice this question →

MCQhard

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

A.Store the values in a variable group and map them to Helm values.

B.Store the values file in Azure Key Vault and use the HelmDeploy task's 'overrideValues' parameter to set values.

C.Store the values file as a secure file in Azure Pipelines library.

D.Store the values file in a separate Git repository and clone it during the pipeline.

AnswerC

Secure files in the Azure Pipelines Library are encrypted at rest and can be downloaded during a pipeline run using the DownloadSecureFile task, which yields a temporary file path. This makes it the correct choice for storing a sensitive Helm values file because the original file never resides in source control and is exposed only as an encrypted library artifact.

Why this answer

Azure Pipelines Library's Secure Files feature allows storing files like Helm values securely and referencing them in pipeline tasks (e.g., HelmDeploy with the 'filePath' parameter). Option A is incorrect because variable groups store key-value pairs, not entire files. Option B is incorrect because the HelmDeploy task's 'overrideValues' parameter expects individual key-value overrides, not a file; Azure Key Vault is for secrets, but using it for a whole values file is not straightforward.

Option D is incorrect because storing the values file in a separate Git repository still exposes it to source control, reducing security compared to Secure Files.

Practice this question →

MCQeasy

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

A.Set the pipeline trigger to 'Manual' only

B.Add a 'Manual Intervention' task in the pipeline

C.Configure branch policies on the main branch

D.Define an environment with required approvers for the production stage

AnswerD

Defining an environment with required approvers is the correct approach because Azure Pipelines environments provide pre-deployment approval checks that pause the pipeline before the production stage runs. Each deployment to that environment must be explicitly approved by the listed users or groups, creating an auditable, enforceable gate before any production release proceeds.

Why this answer

Azure DevOps environments allow you to define required approvers for a specific stage (e.g., production). When a pipeline deploys to that environment, it pauses and waits for manual approval before proceeding, ensuring that production deployments are gated by authorized personnel.

Exam trap

The trap here is that candidates confuse branch policies (which control code merging) with deployment approvals (which control release execution), leading them to select option C instead of the environment-based approval mechanism.

How to eliminate wrong answers

Option A is wrong because setting the pipeline trigger to 'Manual' only prevents automatic pipeline runs but does not enforce approvals during the deployment process; approvals are a separate gate mechanism. Option B is wrong because the 'Manual Intervention' task is a legacy feature that pauses the pipeline for manual input, but it is not designed for multi-environment approval workflows and does not integrate with Azure DevOps environment-based approval gates. Option C is wrong because branch policies on the main branch control code quality and pull request merges, not deployment approvals; they do not gate the release pipeline after code is merged.

Practice this question →

Multi-Selecteasy

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

Select 2 answers

A.Use a variable group linked to Azure Key Vault.

B.Store secrets directly in the YAML pipeline file.

C.Use the 'secret' variable type in the pipeline UI.

D.Use environment variables in the build agent.

E.Print the secret in a script to verify it is correct.

AnswersA, C

A variable group linked to Azure Key Vault enables pipelines to reference secrets stored in Key Vault without never copying them into the pipeline definition. Access is governed by Azure RBAC, and secret values are dynamically retrieved at run time, keeping them out of source control and logs.

Why this answer

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

Option D is wrong because using environment variables on the build agent is not inherently secure; they can be accessed by other processes and may be logged. Option E is wrong because printing secrets in scripts exposes them in the pipeline logs, which is a security risk.

Practice this question →

MCQeasy

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

A.Use a conditional step that runs only when the build succeeds to tag the image as 'latest'

B.Use the build ID as the tag and manually update 'latest'

C.Use the Git commit hash as the tag and push 'latest' separately

D.Always tag the image as 'latest' regardless of build status

AnswerA

This approach guarantees that the 'latest' tag is only moved after a fully successful build, using a condition such as `condition: succeeded()` to run a docker tag/push step. It ensures the image referenced by 'latest' is always a known-good artifact, avoiding the risk of tagging broken builds.

Why this answer

It ensures the 'latest' tag is applied only after a successful build, preventing broken or incomplete images from being tagged as 'latest'. In Azure Pipelines, you can use a condition like `condition: succeeded()` on a script or Docker task that runs `docker tag` and `docker push` to update the 'latest' tag only when the preceding build steps succeed. This maintains a reliable 'latest' pointer to the most recent stable image.

Exam trap

The trap here is that candidates may assume any tagging strategy that includes 'latest' is sufficient, overlooking the critical requirement that the tag must only be applied to successful builds, which is enforced by a conditional step.

How to eliminate wrong answers

Option B is wrong because manually updating the 'latest' tag introduces human error and operational overhead, and it does not automate the process to ensure only successful builds are tagged. Option C is wrong because using the Git commit hash as the tag is a valid strategy for traceability, but pushing 'latest' separately without a conditional check on build success could result in tagging a failed build as 'latest'. Option D is wrong because always tagging the image as 'latest' regardless of build status would overwrite the 'latest' tag with a broken or incomplete image, breaking downstream consumers that rely on 'latest' being a stable reference.

Practice this question →

Multi-Selectmedium

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

Select 2 answers

A.Store secrets in environment variables on the agent machine.

B.Define secrets as pipeline secret variables and reference them as $(secretName).

C.Store secrets in a YAML file and include the file in the repository.

D.Use plain text variables in the pipeline and mask them using the 'Logging Command' feature.

E.Use Azure Key Vault to store secrets and reference them via variable groups linked to Key Vault.

AnswersB, E

Pipeline secret variables are encrypted at rest by Azure DevOps and are masked in pipeline logs when referenced as $(secretName). Only tasks that explicitly reference the variable receive its value, and it is never exposed in the pipeline definition or logs, making this a secure method.

Why this answer

Azure Pipelines allows you to define secret variables in the pipeline UI or YAML, which are encrypted at rest and never exposed in logs. Referencing them as $(secretName) ensures they are securely injected at runtime without being stored in plaintext. Option E is correct because Azure Key Vault provides a centralized, audited, and encrypted store for secrets, and variable groups linked to Key Vault allow pipelines to fetch secrets dynamically without embedding them in pipeline definitions.

Exam trap

The trap here is that candidates may think masking secrets in logs (Option D) is sufficient, but masking does not protect the secret from being stored in plaintext in the pipeline definition or from being exposed in other output channels.

Practice this question →

Multi-Selecteasy

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

Select 3 answers

A.Schedule trigger

B.Pull request (PR) trigger

C.Continuous integration (CI) trigger

D.'on: push' trigger in YAML

E.Commit trigger

AnswersA, B, C

Schedule triggers are a first-class trigger mechanism in Azure Pipelines, enabling automated runs based on a cron schedule.

Why this answer

In Azure Pipelines, scheduled triggers, pull request triggers, and continuous integration (CI) triggers are all valid ways to trigger a pipeline. 'on: push' is GitHub Actions syntax, not Azure Pipelines, and 'commit trigger' is not a formal trigger type in Azure Pipelines.

Exam trap

Do not confuse Azure Pipelines trigger syntax with other CI systems. Azure Pipelines supports CI triggers, PR triggers, and scheduled triggers as first-class trigger types.

Practice this question →

MCQhard

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

A.NuGetCommand@2 with the restore command

B.CopyFiles@2

C.PowerShell@2 to manually download and cache

D.Cache@2 (CacheBeta)

AnswerD

The Cache@2 task (formerly CacheBeta) is Azure DevOps' built-in caching solution; it restores a folder from a cache key, and if there is a miss, it saves the folder after the job completes. For a .NET application, you can cache the ~/.nuget/packages directory (NuGet package cache) to speed up subsequent restores, so it is the correct answer.

Why this answer

The Cache@2 (CacheBeta) task is specifically designed to cache folders or files between pipeline runs, such as NuGet packages, to reduce restore time. By caching the NuGet packages folder (e.g., $(UserProfile)/.nuget/packages), subsequent builds can skip the full restore and reuse previously downloaded packages, significantly speeding up the pipeline.

Exam trap

The trap here is that candidates often choose NuGetCommand@2 (Option A) thinking it inherently caches packages, but it only restores from remote sources each time unless combined with a separate caching task.

How to eliminate wrong answers

Option A is wrong because NuGetCommand@2 with the restore command only restores packages from sources; it does not cache them across pipeline runs. Option B is wrong because CopyFiles@2 is used to copy files from source to destination, not to manage caching of NuGet packages. Option C is wrong because PowerShell@2 can manually download and cache packages, but it requires custom scripting and lacks the built-in cache key, restore keys, and automatic hit/miss handling that Cache@2 provides, making it error-prone and less efficient.

Practice this question →

MCQmedium

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

A.--configuration Release

B.--runtime linux-x64

C.--output $(Build.ArtifactStagingDirectory)

D.--self-contained true

AnswerB

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

Why this answer

The --runtime argument specifies the target runtime (linux-x64) and produces a self-contained deployment. Option A is wrong because --configuration specifies the build configuration, not the runtime. Option C is wrong because --output specifies the output directory, not the runtime.

Option D is wrong because while --self-contained true is a valid argument, it does not specify the target runtime; to target Linux specifically, you must use --runtime linux-x64 (which implies self-contained) or combine --runtime with --self-contained true.

Practice this question →

MCQmedium

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

A.Immutable deployment

B.Rolling deployment

C.Blue-green deployment

D.Canary deployment

AnswerB

Rolling deployment replaces instances incrementally across regions, keeping the previous version running in unaffected instances; if a region's batch fails health checks, Azure DevOps can stop that batch while other regions continue receiving updates, thereby tolerating regional failures and meeting the requirement to keep deploying.

Why this answer

Rolling deployment updates instances gradually across regions. If a deployment to one region fails, the pipeline can continue deploying to other regions because each region is updated independently. Option A (immutable deployment) replaces all instances at once, so a failure would halt the entire deployment.

Option C (blue-green) switches all traffic to a new environment; if that environment fails, the whole deployment fails. Option D (canary) routes a small percentage of traffic to a new version and rolls back if issues occur, but it does not ensure continued deployment to other regions upon failure.

Practice this question →

MCQeasy

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

A.GitHub Secrets

B.Environment variables in the workflow YAML

C.Hardcode the secrets in the workflow file

D.Azure Key Vault with Azure DevOps encrypted variables

AnswerA

GitHub Secrets are repository-level encrypted values that are never stored in the workflow file; GitHub encrypts each secret with a public key using the libsodium sealed box algorithm before storing it and exposes it to workflow runs only as the secrets context. During a run, GitHub injects the secret into the runner environment and automatically redacts its value from logs, and secrets are not available to pull requests from forks unless explicitly configured. This provides a secure, native mechanism for storing sensitive data like API tokens with per-environment scoping and rotation through the GitHub UI or API.

Why this answer

GitHub Secrets (Option A) is the correct choice because GitHub Actions provides a built-in secrets management system that encrypts sensitive values at rest and masks them in all workflow logs. When you reference a secret using ${{ secrets.MY_SECRET }}, GitHub automatically redacts the value from any log output, ensuring it is never exposed during execution.

Exam trap

The trap here is that candidates confuse Azure DevOps encrypted variables with GitHub Secrets, assuming Azure Key Vault integration works identically in GitHub Actions, when in fact GitHub Actions requires a separate action or manual API calls to fetch secrets from Azure Key Vault.

How to eliminate wrong answers

Option B is wrong because environment variables defined directly in the workflow YAML file are stored in plain text and can be printed or leaked in logs, offering no security for sensitive data. Option C is wrong because hardcoding secrets in the workflow file commits them to the repository history, making them visible to anyone with repository access and violating security best practices. Option D is wrong because Azure Key Vault with Azure DevOps encrypted variables is a valid approach for Azure Pipelines, but the question specifically asks about GitHub Actions, where Azure Key Vault integration is not natively supported without additional custom steps or third-party actions.

Practice this question →

MCQmedium

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

A.The 'checkout: internal' step should use a different syntax.

B.The 'ref' property should be set to a commit SHA, not a branch name.

C.The branch specification 'main' is case-sensitive and should be 'Main'.

D.The 'internal' repository trigger requires a pipeline trigger to be enabled in the UI.

AnswerD

For a repository resource trigger to fire, the pipeline's overall Continuous Integration trigger must be enabled in the Azure DevOps UI, not just the YAML trigger under 'resources'. When the CI trigger is turned off, Azure Pipelines ignores both the pipeline-section branch filters and the repository resource trigger configurations. Because the pipeline trigger may be disabled in the UI, this statement identifies the actual root cause and is therefore correct.

Why this answer

When using the 'internal' repository type in Azure Pipelines YAML, the pipeline must have a 'Pipeline trigger' explicitly enabled in the UI settings. The YAML 'trigger' branch specification alone is insufficient for 'internal' repositories; the UI trigger acts as a required gate. Without this UI setting, commits to 'main' will not initiate the pipeline.

Exam trap

The trap here is that candidates assume the YAML 'trigger' block alone is sufficient to enable CI for any repository type, but Azure Pipelines requires an additional UI-based trigger enablement for internal Azure Repos, which is a subtle but critical distinction.

How to eliminate wrong answers

Option A is wrong because 'checkout: internal' is a valid syntax for checking out an internal Azure Repos repository; there is no alternative syntax required. Option B is wrong because the 'ref' property in a trigger can be set to a branch name (e.g., 'refs/heads/main') and does not require a commit SHA. Option C is wrong because branch names in Azure Repos are case-insensitive by default; 'main' and 'Main' are treated as the same branch.

Practice this question →

MCQmedium

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

A.Add a step to cache the node_modules folder.

B.Add a step to minify JavaScript using Terser.

C.Add a step to run Webpack bundle analyzer and implement code splitting.

D.Add a step to run additional unit tests to catch performance issues.

AnswerC

Running Webpack Bundle Analyzer generates a visual treemap of module and dependency sizes, which helps identify large libraries or accidental duplicates that inflate the bundle. Implementing code splitting via dynamic imports or SplitChunksPlugin then breaks the single bundle into smaller lazy-loaded chunks, directly reducing the initial bundle size and improving load performance.

Why this answer

The issue is large bundle sizes causing slow load times. Running Webpack bundle analyzer identifies which modules contribute most to the bundle, and implementing code splitting (e.g., dynamic imports or React.lazy) allows splitting the bundle into smaller chunks loaded on demand, reducing initial payload size.

Exam trap

The trap here is that candidates confuse build optimization (caching, minification) with bundle size optimization, overlooking that code splitting directly addresses the symptom of slow loading due to large bundles.

How to eliminate wrong answers

Option A is wrong because caching node_modules speeds up the npm install step but does not reduce bundle size or address slow loading in the browser. Option B is wrong because minifying JavaScript with Terser reduces file size only slightly (by removing whitespace and shortening variable names) and does not address the root cause of large bundle sizes from monolithic chunks. Option D is wrong because additional unit tests do not affect bundle size or runtime performance; they only verify code correctness.

Practice this question →

MCQmedium

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

A.Use deployment gates with Azure Monitor metrics

B.Configure branch policies on the main branch

C.Add a pipeline decorator to require sign-off

D.Add an approval check on the production environment

AnswerD

Adding an approval check on the production environment in Azure Pipelines creates a manual gate that halts the deployment before it runs, requiring an authorized user to explicitly approve or reject the release. This is the proper native mechanism for enforcing human sign-off on a production deployment in a multi-stage YAML pipeline.

Why this answer

Azure Pipelines supports approval checks on environments, which allow you to require manual approval before a deployment proceeds to a specific stage. By adding an approval check on the production environment, the pipeline will pause at that stage until an authorized user grants approval, meeting the requirement for manual sign-off before production deployment.

Exam trap

The trap here is that candidates often confuse deployment gates (automated health checks) with manual approvals, or mistakenly think branch policies or pipeline decorators can enforce stage-level sign-off, when only environment-level approval checks provide the required manual approval workflow.

How to eliminate wrong answers

Option A is wrong because deployment gates with Azure Monitor metrics are used for automated health checks (e.g., monitoring error rates or latency) and do not provide manual approval functionality; they are designed for automatic validation, not human sign-off. Option B is wrong because branch policies on the main branch control code merging (e.g., requiring pull request reviews) but have no effect on pipeline deployment approvals after the code is merged; they do not gate deployment stages. Option C is wrong because a pipeline decorator is a mechanism to inject additional steps or tasks into every pipeline run (e.g., for compliance scanning) but cannot enforce manual approval; it is not a replacement for environment-level approval checks.

Practice this question →

MCQeasy

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

A.GitHub Code Scanning with a CodeQL workflow

B.Dependabot version updates

C.Secret scanning

D.Branch protection rules with required status checks

AnswerA

GitHub Code Scanning with a CodeQL workflow is the correct answer because CodeQL performs semantic analysis of your source code, identifying vulnerabilities such as SQL injection, cross-site scripting, and path traversal. When configured in a GitHub Actions workflow with an `on: pull_request` trigger, CodeQL runs on every pull request and surfaces results directly as a check run in the PR's checks interface. These check runs can then be required by branch protection rules, meaning a pull request is blocked from merging until CodeQL reports no security issues, providing a true automated code-security gate.

Why this answer

GitHub Code Scanning with a CodeQL workflow is the correct choice because it allows you to define a custom security analysis that runs on every pull request. By configuring the workflow to fail on critical-severity alerts, the pull request is automatically blocked, preventing vulnerable code from being merged. This integrates directly with GitHub's checks API to enforce the scan result as a required status check.

Exam trap

The trap here is that candidates often confuse Dependabot (which handles dependency updates) or branch protection rules (which enforce checks) with the actual scanning tool, forgetting that Code Scanning with CodeQL is the specific feature that performs the security analysis and can block PRs based on vulnerability severity.

How to eliminate wrong answers

Option B is wrong because Dependabot version updates only automate the creation of pull requests to update outdated dependencies; it does not perform security scanning or block PRs based on vulnerabilities. Option C is wrong because Secret scanning is a passive detection feature that alerts on exposed secrets (e.g., API keys) in repositories, but it does not run on every pull request or block PRs. Option D is wrong because branch protection rules with required status checks are a mechanism to enforce that certain checks pass, but they do not themselves perform any security scanning; they rely on an external check like CodeQL to provide the status.

Practice this question →

Multi-Selecteasy

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

Select 2 answers

A.Publish Build Artifacts task

B.Copy Files task

C.Visual Studio Test task

D.Publish Test Results task

E.Azure PowerShell task

AnswersC, D

The Visual Studio Test task is the correct choice because it uses vstest.console.exe to run unit tests from test assemblies (MSTest, xUnit, NUnit) and produces test result data (e.g., TRX). It is the built-in Azure Pipelines task that actually executes tests during the build.

Why this answer

The correct tasks are Visual Studio Test task (option C) which runs the tests, and Publish Test Results task (option D) which publishes the test results to Azure Pipelines. Option A (Publish Build Artifacts) publishes build outputs but not test results. Option B (Copy Files) copies files between locations and does not run tests.

Option E (Azure PowerShell) runs PowerShell scripts and is not for testing.

Practice this question →

100

Multi-Selecteasy

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

Select 2 answers

A.Continuous integration trigger

B.Scheduled release trigger

C.Continuous deployment trigger

D.Pull request trigger

E.Branch policy trigger

AnswersB, C

Scheduled trigger starts a release at a specified time.

Why this answer

B is correct because a scheduled release trigger allows you to define a recurring time (e.g., daily at 2:00 AM) to automatically start a release pipeline, which is essential for scenarios like nightly builds or periodic deployments. C is correct because a continuous deployment trigger automatically starts a release pipeline whenever a new build artifact is available from a linked build pipeline, enabling immediate deployment after a successful build. Both triggers are native to Azure Pipelines and are configured directly on the release pipeline's 'Triggers' tab.

Exam trap

The trap here is that candidates confuse 'continuous integration trigger' (which starts a build) with 'continuous deployment trigger' (which starts a release), and also mistakenly think 'pull request trigger' or 'branch policy trigger' can initiate a release pipeline when they are actually build/repository-level triggers.

Practice this question →

101

MCQmedium

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

A.Use the 'VSTest@2' task with 'retryFailedTests: true' option.

B.Create a custom script that runs each test individually and retries on failure.

C.Enable 'test retry' in the pipeline settings under 'General'.

D.Wrap the test task in a 'Retry' loop using a 'each' expression.

AnswerA

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

Why this answer

The 'VSTest@2' task in Azure DevOps includes a built-in 'retryFailedTests' property that automatically re-runs failed tests a specified number of times. This directly addresses intermittent test flakiness caused by race conditions without requiring any code changes to the tests themselves. The 'DotNetCoreCLI@2' task does not support this retry mechanism, so switching to 'VSTest@2' is the appropriate solution.

Exam trap

The trap here is that candidates may assume the 'DotNetCoreCLI@2' task has a retry option or that a generic pipeline setting exists for test retries, when in fact only the 'VSTest@2' task provides this specific capability, and the other options are either non-existent or overly complex workarounds.

How to eliminate wrong answers

Option B is wrong because creating a custom script that runs each test individually and retries on failure is unnecessarily complex, time-consuming, and error-prone; it also bypasses the built-in retry functionality provided by Azure DevOps, which is simpler and more reliable. Option C is wrong because there is no 'test retry' setting under 'General' in pipeline settings; this option is a fabrication and does not exist in Azure DevOps. Option D is wrong because wrapping the test task in a 'Retry' loop using an 'each' expression is not a valid syntax or feature in Azure DevOps YAML pipelines; the 'each' keyword is used for iterating over parameters, not for retrying tasks, and this approach would not correctly retry only failed tests.

Practice this question →

102

MCQmedium

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

A.Reference the variable as $(VariableName) but only in a script task using 'env' mapping.

B.Use the 'task.getVariable' method in a PowerShell script.

C.Reference the variable as $(VariableName) in the pipeline tasks.

D.Use the Azure Key Vault task to retrieve the secret and then reference the output variable.

AnswerC

Once an Azure Key Vault variable group is linked, its secrets are automatically surfaced as pipeline variables, so you can reference them directly in any task using the macro syntax $(VariableName). This works because Azure Pipelines resolves the macro during runtime, injecting the secret's value into the task before it executes, without needing a separate Key Vault task or explicit service connection in each task.

Why this answer

When a variable group is linked to an Azure Key Vault, secret variables are automatically available in the pipeline. You can reference them directly using the standard $(VariableName) syntax in any pipeline task. No special task or script is required.

Option A is incorrect because you do not need to restrict to script tasks or use 'env' mapping; the $(VariableName) works everywhere. Option B is incorrect because 'task.getVariable' is a scripting method used within tasks, not a YAML syntax. Option D is incorrect because the Azure Key Vault task is unnecessary; the variable group handles the retrieval automatically.

Practice this question →

103

Multi-Selecthard

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

Select 3 answers

A.Add more build steps to the pipeline.

B.Enable caching for NuGet packages.

C.Increase the number of parallel jobs in the pipeline.

D.Use multi-stage build with parallel test execution.

E.Use a self-hosted agent with pre-installed dependencies.

AnswersB, D, E

Caching NuGet packages in Azure Pipelines stores restored packages in a local cache keyed by your package lock files, so subsequent builds restore them from the cache instead of downloading from nuget.org. This dramatically reduces restore time and network latency, directly shortening the overall build duration.

Why this answer

Enabling NuGet package caching reduces build time by avoiding repeated downloads of packages. Using a self-hosted agent with pre-installed dependencies eliminates the need to install and download tools on each run, further reducing overhead. Additionally, structuring the pipeline as a multi-stage build and running tests in parallel across multiple agents can significantly shorten overall pipeline duration by executing independent test suites concurrently.

Together, these optimizations improve build performance.

Exam trap

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

Practice this question →

104

Multi-Selecthard

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

Select 1 answer

A.Enable a system-assigned managed identity on the agent VM.

B.Use the 'docker login' command in the pipeline.

C.Add a service principal connection to the pipeline.

D.Set the 'identity' field in the container resource definition.

E.Use the Azure CLI task with '–identity' flag.

AnswersA

Enabling a system-assigned managed identity on the agent VM allows the container to use the IMDS endpoint to request tokens for Azure resources without storing credentials.

Why this answer

Enabling a system-assigned managed identity on the agent VM allows the container job to use the Azure Instance Metadata Service (IMDS) endpoint to obtain tokens for authenticating to Azure resources without storing credentials. Option D is incorrect because Azure Pipelines container job resource definitions do not have an 'identity' field; the identity is inherited from the agent VM.

Exam trap

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

Why the other options are wrong

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

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

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

Practice this question →

105

Multi-Selectmedium

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

Select 2 answers

A.Set the pipeline trigger to include branches used for non-production stages.

B.Define a stage for production with an 'approvals' block.

C.Use a release pipeline instead of a YAML pipeline.

D.Set the pipeline to require manual approval for every stage.

E.Use a single-stage pipeline with conditional approval.

AnswersA, B

Setting the pipeline trigger to include branches used for non-production stages means CI will automatically run the pipeline for changes to develop/feature branches, allowing non-production stages (e.g., build, test, staging) to execute without manual intervention. This is correct in a multi-stage YAML design where automated progression is desired for non-production while production remains approval-gated.

Why this answer

Options A and B are correct. Option A: Setting the pipeline trigger to include branches used for non-production stages enables automatic CI triggers for those branches, so non-production stages run automatically. Option B: Adding an 'approvals' block to the production stage enforces manual approval before deployment to production.

Options C, D, and E are incorrect: C suggests using a release pipeline which is unnecessary; D would require manual approval for every stage, not just production; E describes a single-stage pipeline, which doesn't fit the multi-stage requirement.

Practice this question →

106

MCQmedium

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

A.Use slot-specific configuration settings (deployment slot settings) for connection strings and app settings that differ between slots.

B.Manually update the production slot settings to match staging before each swap.

C.Perform a swap with preview and then complete the swap after verifying the staging slot.

D.Write a custom PowerShell script to copy configuration from staging to production before swapping.

AnswerA

In Azure App Service, deployment slot settings are marked as 'sticky' so they remain with the slot during swap, ensuring correct connection strings and app settings are applied regardless of swap. This prevents configuration mismatches and eliminates the need for manual updates or scripts. By defining slot-specific settings, production continues to use its intended values while staging uses its own, making swap safe.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

107

MCQeasy

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

A.Keep the previous Docker image tag in ACR and update the manifest to point to it manually.

B.Rerun the previous successful pipeline run.

C.Use the Kubernetes task with the 'rollback' option, which runs 'kubectl rollout undo' on the deployment.

D.Use Helm to manage releases and rollback using 'helm rollback' command.

AnswerC

The Kubernetes task's 'rollback' option invokes 'kubectl rollout undo deployment/<name>', which instructs the Kubernetes Deployment controller to revert to the previously recorded ReplicaSet revision. This restores the exact previous pod template (image, env vars, labels, etc.) automatically and is the built-in, native rollback mechanism for Deployments.

Why this answer

'kubectl rollout undo' is a native Kubernetes feature that automatically reverts the deployment to the previous ReplicaSet, providing a simple and reliable rollback without manual intervention or additional tools. Option A is manual and not automated. Option B re-runs the entire pipeline, which may build a new image and not truly revert to the previous version.

Option D uses Helm, which adds complexity when native rollback is sufficient.

Practice this question →

108

MCQeasy

Your organization uses GitHub Actions and needs to enforce that all workflows pass required checks before a pull request can be merged. Which GitHub feature should you configure?

A.Workflow triggers

B.Branch protection rules with required status checks

C.Required reviewers

D.Environment protection rules

AnswerB

Branch protection rules with required status checks enforce that a pull request cannot be merged until the specified GitHub Actions checks (reported as commit statuses, e.g., from a job's `check_run` or `status` context) succeed. The protected branch's `required_status_checks` context verifies the list of checks, and the merge is rejected if any required check is failing, pending, or absent — this is the correct GitHub-native mechanism for CI gating.

Why this answer

Branch protection rules with required status checks enforce that all configured GitHub Actions workflows must pass before a pull request can be merged. This ensures that any workflow defined in the repository (e.g., CI, linting, security scans) produces a successful check run, and the merge is blocked if any required check fails or is pending.

Exam trap

The trap here is confusing workflow triggers (which control when automation runs) with branch protection rules (which enforce that automation results are satisfied before merging).

How to eliminate wrong answers

Option A is wrong because workflow triggers (e.g., push, pull_request) define when a workflow runs, not whether its results block a merge. Option C is wrong because required reviewers enforce manual approval from specific people, not automated workflow checks. Option D is wrong because environment protection rules control deployments to specific environments (e.g., production) and do not gate pull request merges based on workflow status.

Practice this question →

109

Multi-Selectmedium

Which TWO features in Azure Pipelines allow you to enforce separation of duties between development and operations teams? (Choose two.)

Select 2 answers

A.Pipeline decorators

B.Approvals and checks on environments

C.Service connections with different scopes

D.Environment security roles

E.Branch policies on the main branch

AnswersB, D

Approvals and checks on environments are pre-deployment gates that require designated reviewers or automated checks to approve before a release proceeds; this ensures separation of duties by allowing one group to create a release and a different group to approve it, and checks can enforce policies like branch protection.

Why this answer

Approvals and checks on environments (B) enforce separation of duties by requiring designated approvers (e.g., operations team members) to approve a deployment before it proceeds, ensuring that development cannot directly push to production. Environment security roles (D) allow you to define who can create, view, or manage environments, restricting developers from modifying production environments without operations oversight.

Exam trap

The trap here is that candidates confuse branch policies (which govern code merging) with deployment approvals (which govern release to environments), leading them to select branch policies instead of environment security roles or approvals.

Practice this question →

110

Multi-Selectmedium

You are designing a release pipeline for a microservices application. Which two strategies can you use to manage configuration across different environments? (Choose two.)

Select 2 answers

A.Use variable groups linked to Azure Key Vault.

B.Use environment-specific variable groups.

C.Use XML transformation tasks for web.config.

D.Use multi-stage YAML pipelines with stage-level variables.

AnswersA, B

Linking variable groups to Azure Key Vault is the recommended way to manage secrets and non-sensitive configuration centrally; it stores values securely in Key Vault, supports access control, auditing, and automatic rotation, and references them in pipelines without exposing secrets in source control.

Why this answer

Options A and B are correct because variable groups provide a centralized and secure way to manage configuration across multiple environments and pipelines. Option A uses Azure Key Vault for secrets, integrating with access policies and rotation, while option B stores non-sensitive environment-specific settings. Option C is incorrect because XML transformation targets web.config files, which are legacy .NET artifacts and not typical for modern microservices that use JSON, YAML, or environment variables.

Option D is incorrect because stage-level variables are scoped to a single pipeline definition and do not offer a reusable, centralized configuration mechanism across different environments or pipelines; variable groups are designed for that purpose.

Exam trap

The trap here is that candidates often confuse pipeline definition techniques (like multi-stage YAML with stage-level variables) with configuration management strategies, or incorrectly assume XML transformations are applicable to modern microservices deployments that use JSON, YAML, or environment variables instead of web.config files.

Why the other options are wrong

XML transformation is for config files, not a variable management strategy.

This is a valid approach but the question asks for 'strategies' and the two most common are variable groups and Key Vault.

Practice this question →

111

MCQmedium

Your CI pipeline includes a step that runs unit tests. You want to fail the pipeline if code coverage drops below 80%, but continue if tests pass with lower coverage. How should you configure the test step?

A.Configure a quality gate in the release pipeline to check coverage.

B.Add a script task that reads the coverage report and prints a warning.

C.Use the 'PublishCodeCoverageResults' task with a 'codeCoverageThreshold' setting.

D.Use the VSTest task with the 'codeCoverageEnabled' option set to true.

AnswerC

This task can fail the pipeline if coverage is below threshold.

Why this answer

The 'PublishCodeCoverageResults' task with a 'codeCoverageThreshold' setting is correct because it allows you to define a minimum coverage percentage (e.g., 80%) and fail the pipeline if that threshold is not met, while still allowing the pipeline to continue if tests pass but coverage is lower. This task evaluates the coverage report after tests run and enforces the threshold as a build failure condition, not a test failure.

Exam trap

The trap here is that candidates confuse enabling code coverage collection (VSTest with 'codeCoverageEnabled') with enforcing a coverage threshold, which requires a separate task like 'PublishCodeCoverageResults' that explicitly evaluates and fails the build.

How to eliminate wrong answers

Option A is wrong because a quality gate in the release pipeline checks coverage after deployment, not during the CI build, and cannot fail the CI pipeline at the test step. Option B is wrong because a script task that reads the coverage report and prints a warning does not enforce a failure condition; it only outputs a message, so the pipeline would continue regardless of coverage. Option D is wrong because the VSTest task with 'codeCoverageEnabled' set to true only enables coverage collection during test execution, but does not provide a threshold setting to fail the pipeline based on coverage percentage.

Practice this question →

112

MCQhard

Your release pipeline deploys to Azure App Service using a deployment slot strategy. After a successful deployment to the staging slot, you run smoke tests, then swap slots. Recently, a swap failed because the staging slot had an incorrect application setting. What is the BEST way to prevent this issue?

A.Use a manual approval gate before swap.

B.Configure the App Service deployment center.

C.Add a task to verify settings before swap.

D.Mark the application setting as a deployment slot setting.

AnswerD

Marking the application setting as a deployment slot setting makes it 'sticky' to the slot, meaning it will not be swapped with the app code between staging and production. This ensures the staging slot retains its own configured value and the production slot's value remains unchanged, thereby preventing the misconfiguration from being promoted during a swap.

Why this answer

Marking the application setting as a deployment slot setting ensures that the setting stays with the slot and is not swapped between staging and production. This prevents the staging slot from having an incorrect value that could cause a swap failure, as the setting is pinned to the slot and not part of the swap payload.

Exam trap

The trap here is that candidates often choose a manual or scripted verification step (like Option C) because they think it adds safety, but the native slot setting feature is the simplest, most reliable, and built-in way to prevent swap failures caused by slot-specific misconfigurations.

How to eliminate wrong answers

Option A is wrong because a manual approval gate only pauses the pipeline for human review; it does not automatically validate or correct application settings before the swap, so the same misconfiguration could still cause a failure. Option B is wrong because the App Service deployment center is a high-level configuration interface for continuous deployment, not a mechanism to validate or pin slot-specific settings before a swap. Option C is wrong because adding a task to verify settings before swap is a reactive workaround that requires custom scripting and maintenance, whereas marking the setting as a slot setting is a native, declarative, and reliable solution that prevents the issue at the configuration level.

Practice this question →

113

MCQeasy

Your team uses GitHub for source control and Azure Pipelines for CI/CD. You need to trigger a pipeline automatically when a pull request is created against the main branch. Which trigger type should you configure in the YAML pipeline?

A.pr:

B.trigger:

C.schedules:

D.resources:

AnswerA

The `pr:` keyword in an Azure Pipelines YAML file defines the branch filters that trigger a pipeline on pull requests (PRs) targeting those branches. This is the correct mechanism for PR validation, as it specifically listens to PR creation and updates, unlike other trigger types.

Why this answer

The `pr:` trigger in Azure Pipelines YAML is specifically designed to automatically start a pipeline when a pull request is created or updated against a specified branch. By default, `pr:` triggers are enabled for all branches; however, to ensure the pipeline only runs for PRs targeting `main`, you configure `pr: main`. This triggers the pipeline on PR creation/update without needing a separate branch policy.

Exam trap

The trap here is that candidates often confuse `trigger:` (CI on push) with `pr:` (PR validation), especially since both can be used for the same branch, but they serve different events and have distinct YAML syntax.

How to eliminate wrong answers

Option B is wrong because `trigger:` is used for continuous integration (CI) triggers on branch pushes, not for pull request events; it would start the pipeline when code is pushed to `main`, not when a PR is created. Option C is wrong because `schedules:` defines cron-based scheduled triggers for nightly or periodic builds, which are unrelated to PR events. Option D is wrong because `resources:` is used to define external dependencies like other pipelines, repositories, or containers, not to trigger a pipeline on PR creation.

Practice this question →

114

MCQeasy

Your pipeline uses a multi-stage YAML file. You want to conditionally run a stage only if the build originates from the 'main' branch. Which syntax should you use?

A.condition: variables['Build.SourceBranch'] == 'main'

B.condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))

C.condition: eq(variables['Build.SourceBranch'], 'refs/heads/main')

D.condition: eq(variables['Build.SourceBranch'], 'main')

AnswerC

This is the correct condition because Azure Pipelines stores the triggering branch in the `Build.SourceBranch` variable as a full ref string, such as `refs/heads/main` or `refs/pull/123/merge` for PR builds. The `eq()` function performs an exact string comparison, so it will correctly match when pipeline runs are triggered by a push to the `main` branch. This is the minimal, readable expression that achieves the intended gating without any redundant conditions.

Why this answer

The `condition` directive in a YAML pipeline stage evaluates expressions using Azure Pipelines syntax. The `eq()` function compares two values, and `Build.SourceBranch` for the 'main' branch returns `refs/heads/main`, not just `main`. This exact match ensures the stage runs only when the build originates from the 'main' branch.

Exam trap

The trap here is that candidates often forget that `Build.SourceBranch` includes the full ref path (`refs/heads/main`) and incorrectly use just the branch name (`main`), or they misuse the `==` operator instead of the `eq()` function required by Azure Pipelines expression syntax.

How to eliminate wrong answers

Option A is wrong because it uses a simple equality operator (`==`) which is not valid in Azure Pipelines YAML expressions; the correct syntax requires the `eq()` function. Option B is wrong because it adds `and(succeeded(), ...)` which is unnecessary for a stage-level condition (stages do not have a preceding task to succeed or fail) and introduces an extra check that could cause the stage to be skipped incorrectly. Option D is wrong because it compares `Build.SourceBranch` to `'main'` instead of the full ref `'refs/heads/main'`, which will never match and thus the stage will never run.

Practice this question →

115

MCQhard

You are a DevOps engineer at a large enterprise that develops a cloud-native application using microservices architecture. The application consists of 15 microservices, each stored in a separate GitHub repository. Your team uses GitHub Actions for CI/CD and Azure Kubernetes Service (AKS) for production. The current deployment process is manual and error-prone. You need to design an automated CI/CD pipeline that supports the following requirements: 1. Each microservice must have its own build and test pipeline triggered on pull requests and merges to the main branch. 2. Upon merging to main, a container image must be built, tagged with the Git commit SHA, and pushed to Azure Container Registry (ACR). 3. A separate release pipeline must deploy the updated images to AKS using a GitOps approach with Flux v2. 4. The release pipeline must support rolling back to a previous version quickly if a deployment fails. 5. The entire solution must be defined as code to ensure reproducibility. Which approach should you recommend?

A.Create a single monorepo with all microservices. Use GitHub Actions with a multi-branch pipeline that builds only changed services. Deploy to AKS using kubectl commands in the pipeline. For rollback, redeploy the previous image tag.

B.Use Azure Pipelines with a single build pipeline that triggers on any change in any repo using webhooks. Use Azure DevOps Release Pipelines to deploy to AKS using Helm. Store Helm charts in Azure Container Registry. For rollback, use Helm rollback command.

C.Use GitHub Actions for CI and deploy directly to AKS using kubectl in the same workflow. Store Kubernetes manifests in each microservice repo. Use Argo CD to monitor the repos and sync.

D.Use GitHub Actions in each microservice repo for CI to build and push images to ACR. Use a separate GitOps repository that contains Kubernetes manifests. Configure Flux v2 in AKS to sync from the GitOps repo. When a new image is pushed to ACR, update the manifest in the GitOps repo via a GitHub Action, triggering Flux to deploy. For rollback, revert the commit in the GitOps repo.

AnswerD

This pattern correctly separates CI from CD: each microservice repository has its own GitHub Actions workflow to build and push only its image to ACR, preserving independent versioning and team autonomy. Kubernetes manifests live in a dedicated GitOps repository, and Flux v2 running in AKS continuously reconciles the cluster to that repository, so updating an image tag in a commit automatically triggers the deployment. Rollback is simply a git revert of that commit, giving an immutable, auditable, declarative rollout/rollback workflow with Git as the single source of truth—fully satisfying the requirements for GitHub Actions, AKS, and GitOps-based rollback.

Why this answer

It aligns with all requirements: each microservice has its own GitHub Actions CI pipeline (requirement 1), images are built and pushed to ACR with commit SHA tags (requirement 2), a separate GitOps repo with Flux v2 handles deployment to AKS (requirement 3), rollback is achieved by reverting the Git commit (requirement 4), and everything is defined as code in repositories (requirement 5). Option A is wrong because it uses a monorepo, violating the separate repository requirement, and uses kubectl in the pipeline instead of GitOps. Option B is wrong because it uses Azure Pipelines, which is not consistent with GitHub Actions, and uses Helm rollback instead of Git-based rollback.

Option C is wrong because it deploys directly via kubectl in the same workflow, mixing CI and CD, and uses Argo CD instead of Flux v2 as specified.

Practice this question →

116

MCQhard

You are designing a release pipeline for a mission-critical application that must achieve zero-downtime deployments to Azure App Service (Web App for Containers). The application uses Azure SQL Database with schema migrations. The current deployment slot strategy uses staging and production slots. You need to ensure that during a swap, the staging slot is warmed up and the database schema is rolled back if the swap fails. Which combination of deployment slots and pre/post-swap actions should you implement?

A.Use three slots: production, staging, and a new slot for the new version. Apply schema changes in the new slot, then swap new to staging, warm up staging, then swap staging to production. On failure, swap staging back to production.

B.Use two slots (staging and production) with auto-swap enabled. The auto-swap handles warm-up automatically. If the swap fails, Azure automatically rolls back.

C.Use three slots: production, staging, and a new slot for the new version. Apply schema changes in the new slot, then swap new slot to staging, then staging to production. On failure, swap staging back to production.

D.Use two slots (staging and production). Apply schema changes in staging before swap. If swap fails, manually redeploy the old version to production.

AnswerA

This allows you to test schema changes in the new slot, warm up in staging, and swap staging to production. If the final swap fails, you swap staging back to production, which still has the old code and old schema.

Why this answer

It uses three slots to isolate schema changes in a new slot, then swaps to staging for warm-up, and finally swaps to production. If the swap fails, rolling back staging to production reverses the schema changes, ensuring zero-downtime. This approach aligns with Azure App Service slot-swap best practices for mission-critical applications requiring database rollback capability.

Exam trap

The trap here is that candidates assume auto-swap handles database rollback automatically, but Azure App Service does not manage database schema changes—only application code and configuration are swapped, so a manual rollback strategy is required.

How to eliminate wrong answers

Option B is wrong because auto-swap does not support schema rollback; if the swap fails, Azure does not automatically revert database changes, leading to potential data inconsistency. Option C is wrong because it omits explicit warm-up of the staging slot before the final swap, risking cold-start latency during the production swap. Option D is wrong because manual redeployment of the old version to production after a failed swap causes downtime and does not guarantee atomic rollback of schema changes.

Practice this question →

117

MCQmedium

A team is implementing a release pipeline for a Node.js application. They want to run integration tests against a temporary environment that is destroyed after the tests complete. Which strategy should they use?

A.Use a separate release pipeline that deploys to a production environment for testing.

B.Use a single release pipeline that deploys to a staging slot and runs tests on the slot.

C.Run integration tests in the build pipeline using a mock environment.

D.Use a release pipeline that deploys to a new Azure App Service instance, runs tests, and then removes the instance.

AnswerD

Using a release pipeline that deploys to a new Azure App Service instance, runs tests, and then removes the instance is correct because it provides an ephemeral, isolated environment that closely mirrors production, enabling realistic integration validation and automatic teardown, which avoids lingering state and reduces cost.

Why this answer

It provisions a dedicated, isolated Azure App Service instance for integration testing, runs the tests against the real environment, and then destroys the instance to avoid ongoing costs. This aligns with the ephemeral environment pattern, ensuring tests validate actual deployment behavior without contaminating shared resources.

Exam trap

The trap here is that candidates often confuse staging slots with ephemeral environments, but staging slots are persistent and not automatically destroyed after testing, whereas a new App Service instance can be fully removed to ensure cost and isolation compliance.

How to eliminate wrong answers

Option A is wrong because deploying to a production environment for testing risks corrupting live data and causing downtime, violating the principle of environment isolation. Option B is wrong because a staging slot is a permanent, shared resource that may not be destroyed after tests, and running tests on the slot does not guarantee a clean, disposable environment. Option C is wrong because running integration tests in the build pipeline with a mock environment bypasses real infrastructure validation, missing critical issues like deployment configuration, network dependencies, and service bindings.

Practice this question →

118

MCQeasy

Your company is migrating from on-premises Jenkins to Azure Pipelines. You have a Jenkins pipeline that builds a C++ application using MSBuild. The build environment requires specific Visual Studio components and SDKs. You need to set up a build agent in Azure Pipelines that matches the Jenkins environment. You want to minimize administrative overhead and ensure the agent is always up to date with the latest patches. What should you do?

A.Use a self-hosted agent on an Azure VM with a custom image that includes Visual Studio and SDKs.

B.Deploy a container-based agent using a Docker image that includes Visual Studio.

C.Use a Microsoft-hosted agent with the 'windows-2022' image that includes Visual Studio Build Tools.

D.Provision a self-hosted agent on an Azure VM and install required components manually.

AnswerC

The Microsoft-hosted 'windows-2022' agent is pre-provisioned with Visual Studio Build Tools and common SDKs, auto-patched and recycled per job, eliminating infrastructure maintenance while supporting most build scenarios—making it the simplest, most reliable choice for this migration.

Why this answer

Microsoft-hosted agents include Visual Studio Build Tools and are automatically updated, minimizing administrative overhead. Option A is incorrect because using a custom image on a self-hosted agent still requires maintaining the image and applying updates. Option B is incorrect because container-based agents require building and managing a custom Docker image that includes Visual Studio and SDKs, which adds overhead.

Option D is incorrect because a self-hosted agent on an Azure VM requires manual installation of required components and ongoing patching, increasing administrative effort.

Practice this question →

119

Multi-Selectmedium

Which THREE are valid deployment patterns for Kubernetes? (Choose three.)

Select 3 answers

A.Canary deployment

B.Rolling update

C.A/B testing deployment

D.Helm deployment

E.Blue-green deployment

AnswersA, B, E

Canary deployment is a valid Kubernetes deployment pattern that incrementally routes a small percentage of live traffic to a new version while monitoring key metrics, gradually increasing the canary's share only when the new version proves stable, thereby reducing blast radius and enabling early rollback.

Why this answer

The correct deployment patterns in Kubernetes are canary, rolling update, and blue-green. A canary deployment releases a new version to a small subset of users first, allowing monitoring and gradual traffic shifting. A rolling update incrementally replaces old pods with new ones, ensuring zero downtime.

A blue-green deployment runs two identical environments and switches traffic from the old (blue) to the new (green) environment after validation. Helm is a package manager, not a deployment pattern, and A/B testing is a traffic management technique rather than a core Kubernetes deployment strategy.

Exam trap

The trap here is that candidates confuse deployment patterns (like canary, rolling, blue-green) with deployment tools (like Helm) or traffic management techniques (like A/B testing), leading them to select options that are not actual Kubernetes rollout strategies.

Practice this question →

120

Multi-Selecthard

Which THREE are required to set up a self-hosted agent for Azure Pipelines?

Select 3 answers

A.A virtual machine running in Azure.

B.Network connectivity to Azure DevOps services.

C.A Personal Access Token (PAT) to authenticate the agent.

D.An agent pool configured in Azure DevOps and the agent configured to use that pool.

E.Docker installed on the agent machine.

AnswersB, C, D

The agent must be able to establish an HTTPS connection to Azure DevOps services over the network to poll for job assignments, download tasks, and report status. Without network connectivity, the agent cannot participate in pipelines, making this a fundamental requirement for any self-hosted agent.

Why this answer

B is correct because the self-hosted agent must communicate with Azure Pipelines to receive job assignments and report status. This requires outbound HTTPS connectivity (port 443) to Azure DevOps services (e.g., dev.azure.com). Without network connectivity, the agent cannot register, poll for jobs, or send logs, making it non-functional.

Exam trap

The trap here is that candidates assume a self-hosted agent must run on an Azure VM (Option A) or require Docker (Option E), when in fact the only infrastructure requirements are network connectivity and authentication, with the agent pool configuration tying it all together.

Practice this question →

121

MCQmedium

Your organization uses GitHub Actions for CI/CD. You have a workflow that builds and deploys a containerized application to Azure Kubernetes Service (AKS). The workflow uses the 'azure/aks-set-context' action to connect to the AKS cluster. Recently, the workflow started failing with authentication errors. The service principal used has Contributor role on the AKS cluster. What is the most likely cause?

A.The service principal must have 'Owner' role on the resource group containing the AKS cluster.

B.The service principal lacks the 'Azure Kubernetes Service Cluster Admin Role' on the AKS cluster.

C.The workflow uses an incorrect Kubernetes version.

D.The AKS cluster has RBAC disabled, causing authentication failures.

AnswerB

The Azure CLI action 'aks get-credentials --admin' requires the service principal to have the 'Azure Kubernetes Service Cluster Admin Role' on the AKS cluster. This role grants the Microsoft.ContainerService/managedClusters/listClusterAdminCredential/action permission, which is mandatory for retrieving the cluster-admin kubeconfig; without it, the workflow fails during the credential download step with an authorization error.

Why this answer

The 'azure/aks-set-context' action requires the service principal to have the 'Azure Kubernetes Service Cluster Admin Role' (or 'Azure Kubernetes Service Cluster User Role') on the AKS cluster to authenticate and set the kubectl context. The Contributor role on the AKS cluster resource does not grant the necessary Kubernetes RBAC permissions to interact with the cluster's API server. Without the specific AKS role, the action fails with authentication errors.

Exam trap

The trap here is that candidates assume the Contributor role on the AKS resource is sufficient for all operations, but Azure separates Azure RBAC (for managing the AKS resource) from Kubernetes RBAC (for interacting with the cluster), and the 'azure/aks-set-context' action specifically requires the AKS Cluster Admin or User Role.

How to eliminate wrong answers

Option A is wrong because the 'Owner' role on the resource group is not required; the service principal only needs the 'Azure Kubernetes Service Cluster Admin Role' on the AKS cluster itself, not Owner on the resource group. Option C is wrong because an incorrect Kubernetes version would cause deployment or compatibility issues, not authentication errors when setting the cluster context. Option D is wrong because disabling RBAC on the AKS cluster would actually reduce authentication requirements, not cause authentication failures; the error is due to missing role assignment, not RBAC being disabled.

Practice this question →

122

Multi-Selectmedium

Which TWO actions should you take to implement a CI/CD pipeline for a microservices application using Azure Pipelines? (Choose two.)

Select 2 answers

A.Use a classic release pipeline instead of YAML for the deployment stages.

B.Publish build artifacts and use them in the release stages.

C.Store deployment credentials directly in the YAML file.

D.Use a multi-stage YAML pipeline that includes build, test, and deploy stages.

E.Create a separate pipeline for each microservice.

AnswersB, D

Publishing build artifacts is essential because it decouples the build phase from the release phase, producing an immutable, versioned binary that can be downloaded by any downstream stage or release pipeline. The Publish Pipeline Artifact task stores files in Azure Pipelines and associates them with the run, so the exact bits that passed tests are the ones deployed, eliminating drift between environments and supporting reliable rollback because each deployment can reference a known artifact version. Without this, release stages would have to rebuild or restore packages, breaking reproducibility and atomic deployment.

Why this answer

Options B and D are correct. B: Publishing build artifacts and using them in release stages ensures consistency between build and deploy. D: Using a multi-stage YAML pipeline allows you to define build, test, and deploy stages in a single file.

Option A is wrong because classic release pipelines are not recommended; YAML is preferred for CI/CD. Option C is wrong because credentials should not be stored in YAML; use variable groups or Azure Key Vault. Option E is wrong because a single multi-stage pipeline can handle multiple microservices using matrix strategies; separate pipelines increase complexity.

Practice this question →

123

MCQeasy

Your team uses GitHub Actions to build a Docker image and push it to Azure Container Registry (ACR). The workflow fails with the error 'unauthorized: authentication required'. The workflow uses the 'azure/docker-login@v1' action. What is the most likely cause?

A.The 'azure/docker-login@v1' action does not support ACR.

B.The Dockerfile is not in the repository root.

C.The service principal used for authentication lacks the AcrPush role on the ACR.

D.The workflow uses the registry admin credentials, which are disabled.

AnswerC

To push an image to Azure Container Registry, the authenticated identity (here, the service principal) must have the AcrPush role granted on the registry. If that role is missing, docker login succeeds but docker push fails with a permissions error, making this the likeliest root cause of the push failure.

Why this answer

The 'azure/docker-login@v1' action authenticates Docker with Azure Container Registry using a service principal. If the service principal lacks the AcrPush role, Docker login succeeds but the subsequent push fails with 'unauthorized: authentication required' because the identity does not have permission to push images. The error occurs at push time, not login time, which is a key diagnostic clue.

Exam trap

The trap here is that candidates assume the error means the login itself failed, but the 'azure/docker-login@v1' action can succeed with a valid service principal that lacks push permissions, and the 'unauthorized' error surfaces only during the subsequent docker push, leading test-takers to incorrectly suspect admin credentials or Dockerfile location.

How to eliminate wrong answers

Option A is wrong because 'azure/docker-login@v1' explicitly supports ACR by accepting a username and password (from a service principal) and logging in to the ACR login server. Option B is wrong because the location of the Dockerfile does not affect authentication; it only affects the build context and is unrelated to the 'unauthorized' error. Option D is wrong because if the workflow used registry admin credentials (which are disabled), the error would be 'authentication required' at login, not at push, and the question does not indicate admin credentials are being used; the action defaults to service principal authentication.

Practice this question →

124

MCQmedium

Your build pipeline uses the 'NuGetCommand@2' task to restore NuGet packages. You want to use packages from an Azure Artifacts feed that requires authentication. How should you configure the pipeline to authenticate with the feed?

A.Store the Personal Access Token (PAT) in a variable and use it in the NuGet config.

B.Create an Azure Artifacts service connection and select it in the NuGet task.

C.Add a 'NuGetAuthenticate@1' task before the NuGet restore task.

D.Install the NuGet credential provider on the agent manually.

AnswerC

This task authenticates with Azure Artifacts.

Why this answer

The 'NuGetAuthenticate@1' task is the correct way to authenticate with Azure Artifacts feeds in a pipeline because it automatically handles credential acquisition using the built-in Azure Artifacts credential provider. It works without needing to store or manage Personal Access Tokens (PATs) manually, and it integrates seamlessly with the pipeline's identity (e.g., the project collection build service). This task must be placed before the 'NuGetCommand@2' restore task to ensure the credentials are available for package restoration.

Exam trap

The trap here is that candidates often confuse service connections (which are used for external services like GitHub or generic endpoints) with the built-in Azure Artifacts authentication, leading them to select Option B, but Azure Artifacts feeds do not require a service connection because authentication is handled automatically via the pipeline's identity and the 'NuGetAuthenticate@1' task.

How to eliminate wrong answers

Option A is wrong because storing a PAT in a variable and using it in a NuGet config is a manual, less secure approach that requires managing token expiration and rotation, whereas Azure Artifacts provides a built-in authentication mechanism via the credential provider. Option B is wrong because an Azure Artifacts service connection is not a valid connection type for the 'NuGetCommand@2' task; the task expects a NuGet service connection (e.g., external feed) or relies on the 'NuGetAuthenticate@1' task for Azure Artifacts feeds. Option D is wrong because manually installing the NuGet credential provider on the agent is unnecessary and not a pipeline configuration step; the 'NuGetAuthenticate@1' task handles this automatically on Microsoft-hosted agents and can be configured for self-hosted agents.

Practice this question →

125

MCQmedium

The pipeline fails with the error 'The resource with name 'myregistry' could not be found'. What is the most likely cause?

A.The Azure Container Registry name is incorrect

B.The build ID variable is not defined

C.The service connection does not have permission to access the registry

D.The Azure CLI is not installed on the agent

AnswerA

The error 'resource with name m' indicates Azure DevOps cannot locate the specified Azure Container Registry (ACR) resource, which means the registry name provided in the task or variable does not exist or is misspelled in the current subscription/tenant. A correct ACR name must exactly match the globally unique registry name (e.g., 'myregistry.azurecr.io' without the domain), and any typo or mismatch will result in a 'not found' exception, not an authentication or CLI failure.

Why this answer

The error 'The resource with name 'myregistry' could not be found' indicates that the Azure Container Registry name specified in the pipeline is incorrect or does not exist in the subscription. Option A is correct because the most likely cause is a misspelled or wrong registry name. Option B is incorrect because the build ID variable is unrelated to finding a registry resource.

Option C is incorrect because permission issues typically result in authorization errors, not 'not found'. Option D is incorrect because Azure CLI availability does not affect resource lookup, and the error is about resource existence, not CLI installation.

Practice this question →

126

MCQmedium

Your release pipeline deploys to Azure App Service using a deployment slot. You need to ensure that after swapping slots, the staging slot retains the previous production configuration for rollback. Which deployment strategy should you use?

A.Rolling deployment

B.Blue-green deployment

C.Swap with preview

D.Canary deployment

AnswerC

Swap with preview is correct because it deploys the new build to a staging slot, allows you to validate it before performing a manual swap, and retains the previous configuration in the staging slot for easy rollback. This is the standard Azure App Service pattern for safe, zero-downtime releases.

Why this answer

Swap with preview (multi-phase swap) is the correct strategy because it uses Azure App Service deployment slots to validate the staged version before completing the swap. When the swap is completed, the staging slot receives the previous production code and configuration, preserving a rollback state. If a problem occurs, you can swap back to the staging slot.

Note that a standard slot swap also preserves the previous production state in staging, but swap with preview adds the benefit of preview validation before finalizing the swap, which aligns with the requirement of maintaining rollback capability.

Exam trap

The trap is that candidates may confuse general deployment strategies like blue-green or canary with Azure App Service's slot swap mechanics. While blue-green deployment is conceptually similar, the specific Azure feature that uses deployment slots and supports preview validation before swap is 'swap with preview'. A common mistake is to think a standard swap does not retain the previous production configuration in the staging slot, but in reality it does; the key differentiator of swap with preview is the preview phase that allows you to validate the app before the swap is finalized.

How to eliminate wrong answers

Option A is wrong because rolling deployment gradually replaces instances of the application with the new version, but it does not use deployment slots and does not inherently retain the previous production configuration in a separate slot for immediate rollback. Option B is wrong because blue-green deployment typically involves two separate environments (e.g., two App Service slots) and a full swap, but without the 'swap with preview' feature, the previous production configuration is overwritten in the staging slot during the swap, losing the rollback state. Option D is wrong because canary deployment routes a small percentage of traffic to the new version while keeping the old version running, but it does not use Azure App Service deployment slots for a full swap and does not guarantee that the staging slot retains the previous production configuration after the canary completes.

Practice this question →

127

MCQmedium

You are designing a release pipeline for a Node.js application that deploys to Azure App Service. The pipeline must run integration tests against the deployed application. You want to use deployment slots to minimize downtime. What is the recommended approach?

A.Deploy to a staging slot, run tests against the staging slot, then swap to production.

B.Deploy to the production slot directly and run tests after deployment.

C.Deploy to a staging slot, swap, then run tests.

D.Deploy to a staging slot, run tests, then delete the staging slot.

AnswerA

Deploying to a staging slot allows the new build to run in a production-like environment, where automated and smoke tests validate functionality without affecting live users; the subsequent swap is atomic and fast, switching the production slot to the staged version with zero downtime and preserving the previous deployment for immediate rollback if needed.

Why this answer

Deploying to a staging slot first allows you to validate the application by running integration tests against the staging slot without impacting production traffic. After successful testing, swapping the staging slot with the production slot ensures zero-downtime deployment, as Azure App Service swaps the underlying virtual directories and configuration settings instantly.

Exam trap

The trap here is that candidates often confuse the order of operations, mistakenly thinking swapping before testing (Option C) is acceptable, but this would bypass the validation that slots are designed to provide.

How to eliminate wrong answers

Option B is wrong because deploying directly to the production slot and running tests after deployment risks exposing untested code to live users and can cause downtime if tests fail. Option C is wrong because swapping before running tests means the staging slot becomes production, and any issues found during testing would already be live, defeating the purpose of using slots for safe validation. Option D is wrong because deleting the staging slot after testing discards the validated deployment, requiring a redeployment to production and losing the ability to swap back if issues arise.

Practice this question →

128

MCQmedium

You have a multi-stage pipeline that deploys to multiple regions. You want to ensure that if the deployment to one region fails, the pipeline does not proceed to the next region. What is the best way to implement this?

A.Use pipeline decorators to inject error handling steps.

B.Add a manual approval between regions.

C.Configure each region deployment as a separate stage with no dependencies.

D.Define stage dependencies with 'dependsOn' and set 'condition' to 'succeeded()'.

AnswerD

Stage dependencies with conditions ensure that subsequent stages only run if previous stages succeeded.

Why this answer

Azure Pipelines allows you to define stage dependencies using 'dependsOn' and control execution flow with 'condition'. By setting each region deployment as a separate stage that depends on the previous region's stage succeeding (condition: 'succeeded()'), the pipeline will automatically halt if any region deployment fails, preventing progression to subsequent regions.

Exam trap

The trap here is that candidates often confuse manual approvals (Option B) with automatic failure handling, not realizing that approvals only pause for human input and do not inherently stop the pipeline on a deployment failure.

How to eliminate wrong answers

Option A is wrong because pipeline decorators are used to inject steps into every pipeline or stage automatically (e.g., for compliance or security checks), not to implement conditional stage execution based on previous stage success. Option B is wrong because manual approvals pause the pipeline for human intervention but do not automatically prevent progression on failure; they require manual action and do not react to deployment failures. Option C is wrong because configuring stages with no dependencies means they run in parallel or independently, which would allow deployment to other regions even if one fails, defeating the requirement to stop on failure.

Practice this question →

129

MCQmedium

You have a release pipeline that deploys to multiple environments. You need to ensure that a manual approval is required before deploying to production. What should you configure?

A.Add a manual intervention task in the production stage

B.Set a post-deployment approval on the production stage

C.Set a pre-deployment approval on the production stage

D.Set a branch policy on the release branch

AnswerC

A pre-deployment approval is a release-stage gate that pauses the pipeline immediately before the production stage starts, and it requires a designated approver or approval group to explicitly approve the deployment. This ensures the artifact is not deployed to production until manual authorization is granted, and Azure Pipelines records the approver, timestamp, and any comments for full auditability. Unlike branch policies or post-deployment hooks, this mechanism directly satisfies the requirement to approve before production deployment and provides a clean separation of duties between build and release. Additionally, you can configure policies such as re-approval if the artifact changes, making it the correct, policy-driven approach.

Why this answer

Pre-deployment approvals are configured on a stage in Azure Pipelines to require manual sign-off before any deployment to that stage begins. Since the question specifies that approval is needed before deploying to production, a pre-deployment approval on the production stage enforces that gate before the release pipeline executes any deployment tasks in that environment.

Exam trap

The trap here is confusing pre-deployment approvals with post-deployment approvals or manual intervention tasks, as candidates often think a manual task can substitute for a formal approval gate, but only pre-deployment approvals enforce the 'before deployment' requirement with proper workflow and audit trail.

Why the other options are wrong

Manual intervention task is for classic releases, but approvals are a better fit and work in YAML too.

Post-deployment approval occurs after deployment, not before.

Branch policies affect pull requests, not release pipelines.

Practice this question →

130

MCQhard

You are the DevOps lead for a large enterprise that uses GitHub for source control and Azure Pipelines for CI/CD. The organization has hundreds of repositories, each with its own pipeline. Recently, the security team mandated that all pipelines must use a centralized set of tasks for secret scanning and compliance checks before any deployment. You need to design a solution that enforces these mandatory tasks across all pipelines without modifying each pipeline individually. The solution should allow pipeline authors to add their own custom steps after the mandatory steps. The mandatory steps must be versioned and updated centrally. You also need to ensure that the mandatory steps are not bypassed by pipeline authors. What should you do?

A.Store the mandatory tasks as a YAML template in a central repository. In each pipeline, use the 'template' reference to include the mandatory steps. Use branch protection rules on the central repository to require approval for changes to the template.

B.Use a global list of tasks in the Azure DevOps organization settings that automatically get injected into every pipeline.

C.Create a single pipeline that runs across all repositories and include the mandatory tasks in that pipeline.

D.Create a custom Azure DevOps extension that adds the mandatory tasks to all pipelines using a pre-job hook.

AnswerD

Custom Azure DevOps extensions cannot reliably enforce mandatory tasks in all pipelines because extensions must be installed and are not automatically injected into every pipeline. There is no supported pre-job hook in the extension model that can force tasks to run; pipeline authors can simply omit or disable the extension, so it does not provide central enforcement.

Why this answer

D is correct. A custom Azure DevOps extension with a pre-job hook (pipeline decorator) automatically injects mandatory steps into every pipeline without requiring changes to individual pipelines. It is centrally managed and versioned, and cannot be bypassed by pipeline authors.

A is incorrect because it requires adding a template reference to each pipeline and the template inclusion is optional; branch protection only prevents tampering with the template, not its omission. B is invalid because Azure DevOps has no global task list injection. C is invalid because a single pipeline cannot run across all repositories with custom steps.

Exam trap

A YAML template with branch protection is often mistaken for an enforcement mechanism, but it does not require pipelines to include the template.

Practice this question →

131

MCQeasy

You want to trigger a pipeline automatically when a new tag is pushed to a GitHub repository. Which trigger should you configure in the pipeline YAML?

A.pr:

B.schedules:

C.trigger: tags:

D.resources: pipelines:

AnswerC

This is the correct syntax to trigger on tags.

Why this answer

The `trigger` block in Azure Pipelines YAML supports a `tags` filter that instructs the pipeline to run automatically when a Git tag matching the specified pattern is pushed. By configuring `trigger: tags: include: ['*']` or a specific tag pattern, the pipeline will start on any new tag push to the GitHub repository, which is the exact requirement.

Exam trap

The trap here is that candidates often confuse `trigger:` with `pr:` or `schedules:`, mistakenly thinking any trigger keyword can handle tag events, but only the `tags` sub-property of `trigger:` is designed for Git tag-based automation.

How to eliminate wrong answers

Option A is wrong because `pr:` configures pull request validation triggers, not tag-based triggers; it would start the pipeline on PR creation or update, not on tag push. Option B is wrong because `schedules:` defines cron-based scheduled runs (e.g., nightly builds) and has no relation to Git tag events. Option D is wrong because `resources: pipelines:` is used to trigger this pipeline from another pipeline's completion (pipeline resource trigger), not from a Git tag push event.

Practice this question →

132

MCQhard

You are designing a pipeline that deploys to an Azure Kubernetes Service (AKS) cluster. You need to securely pass the Kubernetes cluster credentials to the pipeline without hardcoding them. Which approach should you use?

A.Store credentials in a pipeline variable with 'secret' type.

B.Use a variable group linked to Azure Key Vault.

C.Hardcode the credentials in the pipeline YAML.

D.Use a secure file in the pipeline library.

AnswerB

A variable group linked to Azure Key Vault securely references secrets stored in Key Vault, so Azure DevOps fetches the current values at pipeline runtime rather than storing them in the pipeline definition. This leverages Key Vault's RBAC, versioning, and rotation, and allows the same service principal to be used across many pipelines without exposing it in YAML.

Why this answer

Azure Key Vault provides a secure, centralized store for secrets like Kubernetes cluster credentials, and linking a variable group to Key Vault allows the pipeline to dynamically retrieve those secrets at runtime without exposing them in the pipeline definition or logs. This approach follows the principle of least privilege and ensures credentials are never hardcoded or stored in plaintext within the pipeline.

Exam trap

The trap here is that candidates may think a pipeline secret variable is sufficient for security, but Azure DevOps specifically recommends using Key Vault for production-grade secret management to avoid storing secrets in the pipeline's internal database and to enable centralized lifecycle management.

Why the other options are wrong

While secure, it does not leverage Key Vault for secret management and rotation.

This is insecure and violates best practices.

Secure files are for files like certificates, not for credentials; but they can be used for kubeconfig, but variable group with Key Vault is more direct.

Practice this question →

133

MCQeasy

Your build pipeline uses a hosted agent. You need to securely pass a connection string to a deployment task. The connection string contains a password. What is the recommended approach to store and use this secret in Azure Pipelines?

A.Define the connection string as a plain variable in the YAML pipeline.

B.Hardcode the connection string in the deployment script and set the file as read-only.

C.Define the connection string as a secret variable in the pipeline's variable group or in the pipeline settings UI, and reference it as `$(connectionString)`.

D.Store the connection string in Azure Key Vault and use the 'Azure Key Vault' task to retrieve it at runtime.

AnswerC

Secret variables are encrypted and masked in logs.

Why this answer

The recommended approach is to define the connection string as a secret variable in the pipeline's variable group or in the pipeline settings UI, and reference it as $(connectionString). Secret variables are encrypted at rest and never exposed in logs or to other tasks. Option A is incorrect because plain variables are visible in logs and YAML.

Option B is incorrect because hardcoding secrets in scripts is insecure and violates best practices. Option D, while secure, is overkill for a simple secret and requires additional configuration and permissions, making it less recommended for this scenario.

Exam trap

Candidates may overthink and choose Azure Key Vault for all secrets, but for a single static secret used within a pipeline, secret variables are simpler and equally secure.

Practice this question →

134

MCQeasy

Your pipeline uses a multi-stage YAML file. You want to conditionally run a stage only when the build is triggered from the 'main' branch. Which expression should you use in the 'condition' property of the stage?

A.startsWith(variables['Build.SourceBranch'], 'main')

B.eq(variables['Build.SourceBranchName'], 'refs/heads/main')

C.eq(variables['Build.SourceBranch'], 'refs/heads/main')

D.eq(variables['Build.SourceBranch'], 'main')

AnswerC

This condition is correct because Build.SourceBranch contains the complete Git ref path, and comparing it directly to the exact string 'refs/heads/main' uniquely identifies the main branch without matching maintenance or other similarly named branches. It is the precise and recommended way to gate on the main branch in Azure Pipelines.

Why this answer

The `Build.SourceBranch` variable in Azure Pipelines contains the full Git ref path (e.g., `refs/heads/main`). The `condition` property evaluates expressions at runtime, and using `eq(variables['Build.SourceBranch'], 'refs/heads/main')` precisely matches the full ref for the main branch, ensuring the stage runs only when the trigger originates from that branch.

Exam trap

The trap here is that candidates often confuse `Build.SourceBranch` (full ref) with `Build.SourceBranchName` (short name) or assume a simple substring match like `startsWith` is sufficient, leading them to pick options that either compare the wrong variable or use an imprecise matching function.

How to eliminate wrong answers

Option A is wrong because `startsWith(variables['Build.SourceBranch'], 'main')` would incorrectly match branches like `main-feature` or `maintenance` since it only checks the prefix, not the exact ref. Option B is wrong because `Build.SourceBranchName` contains only the short branch name (e.g., `main`), not the full ref path `refs/heads/main`, so the comparison fails. Option D is wrong because `Build.SourceBranch` always includes the full ref path (e.g., `refs/heads/main`), so comparing it to just `'main'` will never evaluate to true.

Practice this question →

135

MCQmedium

Your team uses Azure Pipelines to build a .NET Core application. The build runs successfully on Windows agents, but you need to also run the build on Linux agents to validate cross-platform compatibility. The pipeline currently has a single `windows-latest` agent pool. What is the most efficient way to run the build on both platforms without duplicating the entire pipeline?

A.Create two separate pipelines, one for each platform.

B.Use a multi-job pipeline with two jobs, each specifying a different pool.

C.Use a multi-stage pipeline with a stage for each platform.

D.Add a `strategy` with a `matrix` that specifies `vmImage: ['windows-latest', 'ubuntu-latest']` in the job.

AnswerD

Adding a `strategy` with a `matrix` to a job instructs Azure Pipelines to expand that job into multiple job instances at queue time, each with the same steps but with the matrix variables assigned from a specific entry. By mapping a variable like `vmImage` to `['windows-latest', 'ubuntu-latest']` and then referencing it via `$(vmImage)` in the pool specification, the same job runs simultaneously on both Windows and Linux agents, producing a true parallel cross-platform build. This is the idiomatic Azure Pipelines pattern because it keeps the job logic in one place, eliminates duplication, and makes adding or removing a platform as simple as editing a list in the matrix.

Why this answer

Using a `strategy` with a `matrix` allows the same job to run on multiple agent pools in parallel, enabling cross-platform validation without duplicating the pipeline. Option A duplicates the entire pipeline, which is inefficient. Option B would require separate jobs, but not as concise as the matrix strategy.

Option C uses stages, which run sequentially, not in parallel for this purpose.

Practice this question →

136

Multi-Selectmedium

You are implementing a release pipeline with multiple stages. You want to automatically trigger the next stage only if the previous stage succeeds and the build is from the 'main' branch. Which TWO conditions should you configure?

Select 2 answers

A.Add a condition that checks if the source branch is 'main'.

B.Set the trigger on the stage to 'After stage' and select the previous stage.

C.Add a condition: 'eq(variables['Build.SourceBranch'], 'main')' to the stage.

D.Add a condition: 'succeeded()' to the stage.

E.Add a condition: 'eq(variables['Build.SourceBranch'], 'main')' with correct syntax.

AnswersA, B

Required to restrict to main branch.

Why this answer

The correct answers are A and B. To automatically trigger the next stage only when the previous stage succeeds and the build is from the 'main' branch, you need two configurations: first, set the stage trigger to 'After stage' and select the previous stage (option B), which ensures the stage runs after the previous stage completes successfully. Second, add a condition that checks the source branch—Option A correctly identifies this need, though the exact expression should be `eq(variables['Build.SourceBranch'], 'refs/heads/main')`.

Option D is incorrect because `succeeded()` only checks that all previous stages succeeded but does not enforce the branch condition. Option C is wrong due to incorrect syntax (missing 'refs/heads/'). Option E is also incorrect because the syntax shown is not correct; the correct syntax requires 'refs/heads/main'.

Practice this question →

137

MCQhard

You are designing a release pipeline for a critical application that must minimize downtime during deployment. The application runs on Azure Kubernetes Service (AKS) and uses Azure SQL Database. Which deployment strategy should you recommend?

A.Rolling update with health probes.

B.Canary deployment with progressive exposure.

C.Blue-green deployment with traffic manager.

D.Recreate deployment by deleting the old version first.

AnswerC

Blue-green deployment with traffic manager provisions two identical environments, with the traffic manager routing 100% of traffic to the blue environment. At switchover, it instantly shifts traffic to the green environment by updating DNS/routing rules, and rollback is equally immediate, so downtime is reduced to seconds or less.

Why this answer

Blue-green deployment with Traffic Manager is recommended because it allows you to maintain two identical environments (blue and green) and instantly switch traffic between them via Azure Traffic Manager. This minimizes downtime to the time it takes to update DNS or routing rules, and provides immediate rollback capability by switching back to the previous environment. For a critical application on AKS with Azure SQL Database, this strategy avoids the complexity of managing state during rolling updates and ensures zero-downtime cutover.

Exam trap

The trap here is that candidates often choose rolling updates (Option A) because they assume health probes guarantee zero downtime, but they overlook the fact that rolling updates still involve a gradual transition that can cause brief unavailability or require complex rollback logic, whereas blue-green provides instant, atomic cutover with Traffic Manager.

How to eliminate wrong answers

Option A is wrong because rolling updates with health probes, while reducing downtime, still involve gradual replacement of pods, which can cause brief periods of reduced capacity or partial unavailability if health probes are misconfigured; they also do not provide instant rollback. Option B is wrong because canary deployment with progressive exposure is designed for testing new versions with a small subset of users, not for minimizing downtime during a full production deployment—it introduces complexity in routing and monitoring and does not guarantee zero-downtime cutover. Option D is wrong because recreating by deleting the old version first causes full downtime until the new version is fully deployed, which violates the requirement to minimize downtime.

Practice this question →

138

MCQmedium

You are designing a build validation policy for a GitHub repository. You want to ensure that all pull requests pass a CI check before they can be merged. What should you configure?

A.Enable Dependabot alerts on the repository.

B.Configure a repository rule to require a pull request before merging.

C.Add a GitHub Actions workflow that runs on 'pull_request' and set it as a required status check in branch protection.

D.Create a webhook to trigger a build on Azure Pipelines.

AnswerC

Adding a GitHub Actions workflow with a `pull_request` trigger executes CI on each PR, and then marking the resulting status check as required in branch protection blocks merging until that workflow completes successfully. This creates a hard enforcement gate that validates the build before changes can be merged, making it the correct approach for build validation.

Why this answer

Branch protection rules in GitHub can require status checks to pass before merging. You set up a rule that requires the CI workflow to succeed.

Practice this question →

139

MCQmedium

You are designing a build pipeline for a Java application that uses Maven. The build must run unit tests and integration tests separately. You want to publish test results to Azure Pipelines. Which task configuration should you use?

A.Use two Gradle tasks, one for unit tests and one for integration tests.

B.Use a single Maven task with goals 'test verify', and configure the task to publish test results.

C.Use two Maven tasks with goals 'test' and 'verify', and configure the Publish Test Results task to publish results from both runs.

D.Use two Visual Studio Test tasks, one for unit tests and one for integration tests.

AnswerC

Correct: Maven can run tests and PublishTestResults can publish results.

Why this answer

It uses two separate Maven tasks with the 'test' and 'verify' goals, which allows unit tests and integration tests to run independently. The Publish Test Results task is then configured to consume the test result files (typically JUnit XML reports) from both runs, enabling Azure Pipelines to display a unified test summary. This approach aligns with the requirement to run unit and integration tests separately while still publishing all results.

Exam trap

The trap here is that candidates assume a single Maven task with both goals can achieve separation, but Azure Pipelines executes all goals in one run, so the tests are not isolated; the correct approach requires two distinct tasks to enforce separate execution and independent result publishing.

How to eliminate wrong answers

Option A is wrong because Gradle tasks are not applicable; the question specifies a Java application that uses Maven, not Gradle. Option B is wrong because using a single Maven task with goals 'test verify' runs both phases sequentially in the same Maven invocation, which does not satisfy the requirement to run unit tests and integration tests separately. Option D is wrong because Visual Studio Test tasks are designed for .NET test frameworks (e.g., MSTest, xUnit) and cannot directly execute Maven-based Java tests.

Practice this question →

140

Multi-Selecthard

Which THREE components are required to set up a self-hosted agent in Azure Pipelines? (Choose three.)

Select 3 answers

A.An Azure Resource Manager service connection

B.A personal access token (PAT) with Agent Pools (read, manage) scope

C.A machine (virtual or physical) to run the agent software

D.The agent software downloaded from the Azure DevOps organization

E.An Azure Active Directory account for the agent

AnswersB, C, D

A PAT scoped to Agent Pools (read, manage) is required because it is the primary authentication mechanism for registering a self-hosted agent against an Azure DevOps organization. This token grants the agent the necessary permissions to appear in the target agent pool and receive job assignments.

Why this answer

A personal access token (PAT) with Agent Pools (read, manage) scope is required because the self-hosted agent uses this token to authenticate with Azure DevOps during the configuration step. The agent registers itself into the specified agent pool, and the PAT must have the 'Agent Pools (read, manage)' scope to authorize this registration and subsequent communication.

Exam trap

The trap here is that candidates often confuse a service connection (needed for deploying to Azure) with the authentication mechanism required to register the agent itself, leading them to select Option A instead of recognizing that only the PAT with Agent Pools scope is needed.

Practice this question →

141

MCQhard

Your Azure Pipelines release pipeline deploys to multiple stages. You need to implement a manual approval gate that requires two specific users to approve before deployment proceeds to production. The approval should expire after 8 hours. Which configuration should you use?

A.Pre-deployment conditions: Add approvers (user1, user2) with 'All' policy and set timeout to 480 minutes

B.Pre-deployment conditions: Add approvers (user1, user2) with 'Any one' policy

C.Pre-deployment conditions: Add approvers (user1, user2) with 'All' policy and set 'Allow deployment without approval' to true

D.Post-deployment conditions: Add approvers (team) with 'All' policy

AnswerA

Setting pre-deployment approvers to user1 and user2 with the 'All' policy requires both users to explicitly approve the release before deployment proceeds. The 480-minute timeout ensures that if either approver does not respond within 8 hours, the approval process times out, preventing indefinite blocking of the pipeline. This satisfies the requirement that both specific individuals must approve, with an 8-hour window.

Why this answer

It configures a pre-deployment approval gate requiring both user1 and user2 to approve (the 'All' policy) before the production stage proceeds, and sets the timeout to 480 minutes (8 hours) to expire the approval request. This matches the requirement for two specific users to approve and an 8-hour expiration.

Exam trap

The trap here is confusing pre-deployment vs. post-deployment conditions and misinterpreting the 'All' vs. 'Any one' policy, leading candidates to select an option that allows a single approver or applies the gate after deployment.

How to eliminate wrong answers

Option B is wrong because the 'Any one' policy allows either user1 or user2 to approve, not both, which fails the requirement for two specific users to approve. Option C is wrong because setting 'Allow deployment without approval' to true would bypass the approval gate entirely, contradicting the requirement for manual approval. Option D is wrong because post-deployment conditions apply after the deployment runs, not before, and the requirement is for a pre-deployment gate; additionally, it specifies a team rather than two specific users.

Practice this question →

142

MCQhard

You run the Azure CLI command shown in the exhibit as part of a release pipeline to deploy a ZIP package to an Azure App Service. The deployment succeeds, but the app does not start. What is the most likely cause?

A.The app's startup command is not configured

B.The resource group name is incorrect

C.The runtime stack is not specified in the command

D.The deployment slot is not specified

AnswerA

ZIP deploy does not set startup command; needs manual config.

Why this answer

The Azure CLI command `az webapp deploy` deploys the ZIP package to the App Service, but it does not configure the startup command. If the application (e.g., a Node.js or Python app) requires a specific startup file or script (like `npm start` or `gunicorn`), the App Service will fail to start because it defaults to a generic handler. The startup command must be set via the `--startup-file` parameter in `az webapp config set` or in the Azure portal.

Exam trap

The trap here is that candidates assume a successful deployment (no CLI errors) guarantees the app will run, but Azure App Service separates the deployment of artifacts from the runtime configuration, so a missing startup command is a common silent failure.

How to eliminate wrong answers

Option B is wrong because an incorrect resource group name would cause the deployment command to fail entirely (e.g., 'ResourceGroupNotFound' error), not allow a successful deployment with a subsequent startup failure. Option C is wrong because the runtime stack is specified during the App Service creation (e.g., `az webapp create --runtime`), not in the `az webapp deploy` command; the deploy command only handles the package upload and extraction. Option D is wrong because deployment slots are optional; if no slot is specified, the command deploys to the production slot by default, and the absence of a slot specification does not prevent the app from starting.

Practice this question →

143

Multi-Selecteasy

Which TWO of the following are true about multi-stage pipelines in Azure Pipelines?

Select 2 answers

A.Stages can run in parallel if dependencies allow.

B.Each stage can contain only one job.

C.Each stage must run on the same agent.

D.Stages cannot have conditions.

E.They are defined in a single YAML file.

AnswersA, E

Stages in a multi-stage pipeline can execute in parallel when they have no dependencies on one another. You explicitly declare this by using `dependsOn: none` on the stage; otherwise, stages default to sequential execution based on implicit dependencies.

Why this answer

Azure Pipelines allows stages to run in parallel when their dependencies are configured appropriately. By default, stages run sequentially, but you can use the 'dependsOn' keyword to define dependencies, and if a stage has no dependencies on another, it can execute concurrently. This enables faster pipeline execution by running independent stages simultaneously.

Exam trap

The trap here is that candidates often assume stages must be sequential or share the same agent, but Azure Pipelines explicitly supports parallel execution and independent agent allocation per stage.

Practice this question →

144

Multi-Selecthard

Which THREE are valid strategies for managing configuration in a multi-environment CI/CD pipeline?

Select 3 answers

A.Store configuration in environment-specific YAML variable files.

B.Embed configuration values directly into the container image.

C.Hardcode configuration in pipeline scripts for each environment.

D.Use Azure Key Vault references in variable groups.

E.Use variable groups linked to Azure DevOps library.

AnswersA, D, E

Storing configuration in environment-specific YAML variable files (e.g., variables/dev.yml, variables/prod.yml) lets a single, generic pipeline definition consume the correct values per environment via template includes. This keeps your pipeline logic DRY while making each environment's settings explicit, code-reviewed, and easy to change without rebuilding images or rewriting pipelines.

Why this answer

Using variable groups, Key Vault references, and environment-specific YAML variable files are all valid. Storing config in the container image is not recommended because it couples the image to an environment. Hardcoding in scripts is bad practice.

Practice this question →

145

MCQeasy

Your team uses Azure Pipelines to build a .NET Core application. You notice that the build takes too long because it restores NuGet packages every time. What is the best way to improve build performance?

A.Configure the build to use a self-hosted agent with previously restored packages

B.Use a private agent with a faster network connection

C.Use a Microsoft-hosted agent with a larger SKU

D.Enable the 'Cache' task to cache the NuGet packages folder

AnswerD

The Cache task (Cache@2) persists the NuGet packages folder (typically identified by the NUGET_PACKAGES environment variable) in a distributed cache such as Azure Blob Storage, keyed by a cache key like a hash of the .csproj files or packages.lock.json. On the first build the cache is populated; on subsequent builds the task downloads and unzips the folder into the agent workspace before the restore step, so NuGet finds needed packages locally and avoids network downloads. This reduces restore time significantly and works on both Microsoft-hosted and self-hosted agents, with cache recovery and invalidation handled automatically.

Why this answer

The best way to improve build performance is to cache the NuGet packages folder using the 'Cache' task in Azure Pipelines. This avoids re-downloading packages on each run. Option A (self-hosted agent) is not guaranteed to cache the packages folder across builds unless caching is explicitly configured.

Option B (faster network) may help but doesn't eliminate the restore time. Option C (larger SKU) improves CPU/memory but does not cache packages. Therefore, option D is correct.

Practice this question →

146

MCQeasy

Your Azure Pipelines build takes 45 minutes. You want to reduce build time by caching dependencies. Which task should you add to the pipeline?

A.PublishBuildArtifacts@1

B.CopyFiles@2

C.DownloadBuildArtifacts@0

D.Cache@2

AnswerD

Cache@2 is the dedicated Azure Pipelines task for caching dependencies. It saves a specified folder keyed by a cache key (like a hash of a lock file) and restores it on subsequent runs, which can eliminate repeated package restore operations and significantly reduce build duration, making it the correct solution for a 45-minute build.

Why this answer

Cache@2 is the correct task because it allows you to cache dependencies (e.g., npm packages, Maven artifacts) between pipeline runs, significantly reducing build time by avoiding re-downloading unchanged dependencies. This task stores and restores a cache keyed by a hash of the dependency files, enabling incremental builds.

Exam trap

The trap here is confusing artifact publishing/downloading with caching; candidates often pick PublishBuildArtifacts@1 thinking it caches dependencies, but it only stores build outputs for later use, not intermediate dependency downloads.

How to eliminate wrong answers

Option A is wrong because PublishBuildArtifacts@1 uploads build outputs (e.g., binaries) to Azure Pipelines, not caching dependencies to reduce build time. Option B is wrong because CopyFiles@2 simply copies files from source to destination within the agent, with no caching mechanism. Option C is wrong because DownloadBuildArtifacts@0 downloads previously published artifacts, which is unrelated to caching dependencies during the build process.

Practice this question →

147

MCQhard

Your company develops a microservices-based application deployed on Azure Kubernetes Service (AKS). The CI/CD pipeline uses Azure Pipelines. The development team has recently adopted a trunk-based development strategy where all feature work is done on short-lived branches that merge to main at least daily. The release pipeline must automatically deploy to a development environment on each commit to main, and to a staging environment after a manual approval. The staging environment is used for integration tests and must remain stable. You need to design the release pipeline strategy to support this workflow. What should you do?

A.Create a single release pipeline with one stage that deploys to both dev and staging simultaneously, and add a manual intervention task before staging deployment.

B.Create a single release pipeline with two stages: 'Dev' triggered automatically on successful build, and 'Staging' with a pre-deployment approval gate.

C.Create two separate release pipelines: one for dev with continuous deployment trigger, and one for staging with a manual trigger.

D.Create a single release pipeline with two stages: 'Dev' triggered automatically, and 'Staging' with a post-deployment approval gate and disable continuous deployment trigger.

AnswerB

A single release pipeline with a 'Dev' stage triggered automatically on successful build and a 'Staging' stage with a pre-deployment approval gate is the correct pattern. It promotes the same build artifact through environments, enables fast feedback in dev, and uses an approval gate to ensure staging deployments are authorized and traceable before they occur.

Why this answer

It creates a single release pipeline with two stages: 'Dev' triggered automatically on successful build, and 'Staging' with a pre-deployment approval gate. This meets the requirements: automatic deployment to dev on each commit to main, and manual approval before deploying to staging, keeping staging stable. Option A is wrong because deploying to both environments simultaneously bypasses the manual approval needed for staging.

Option C is wrong because separate pipelines add maintenance overhead and don't leverage pipeline stages for approval gates. Option D is wrong because a post-deployment approval gate would deploy to staging first, then require approval, which doesn't prevent deployment without approval. Also disabling continuous deployment trigger for staging would require manual promotion, which is not desired.

Practice this question →

148

MCQmedium

Your build pipeline uses a self-hosted agent in your on-premises network. The agent pool is configured to use the 'latest' agent version. Recently, a new version of the Azure Pipelines agent was released, and your builds started failing because the new agent requires .NET 6.0, which is not installed on the agent machine. What is the best way to prevent this issue in the future?

A.Configure the agent pool to use a specific agent version (e.g., '2.210.0') and test new versions in a separate pool before updating.

B.Switch to using Microsoft-hosted agents instead of self-hosted.

C.Disable automatic agent updates on the self-hosted agents.

D.Install .NET 6.0 on the agent machine to meet the new requirement.

AnswerA

Pinning the agent to a specific version prevents unexpected auto-updates from introducing breaking changes, ensuring consistent behavior across builds. By testing new versions in a separate pool first, you can validate compatibility with your pipelines and then control the rollout to production agents, giving you deterministic agent environments.

Why this answer

It decouples your production pipeline from automatic agent updates. By pinning the agent pool to a known-working version (e.g., '2.210.0'), you can validate new agent releases in a separate test pool before rolling them out. This prevents breaking changes—like a new .NET dependency—from impacting your builds without prior testing.

Exam trap

The trap here is that candidates confuse disabling automatic agent updates (which only prevents the agent binary from self-updating) with controlling which agent version the pipeline uses; the 'latest' pool setting overrides local update settings, so builds still fail even with updates disabled.

How to eliminate wrong answers

Option B is wrong because switching to Microsoft-hosted agents does not solve the root cause; it only moves the dependency management to Microsoft, and you would still face similar issues if Microsoft updates their agent image. Option C is wrong because disabling automatic updates only prevents the agent from updating itself, but the agent pool's 'latest' setting still forces the pipeline to download and use the newest agent version from the server, so builds would still fail. Option D is wrong because installing .NET 6.0 on the agent machine is a reactive fix that addresses only this specific version's requirement; it does not prevent future breaking changes from other new agent versions.

Practice this question →

149

MCQhard

Your Azure DevOps release pipeline deploys to Azure Kubernetes Service (AKS). You need to ensure that the deployment is rolled back automatically if the health checks fail within 5 minutes after deployment. The AKS cluster uses a canary deployment strategy. What should you use?

A.Use an Azure CLI task to run 'kubectl rollout undo' in a post-deployment script.

B.Use a Helm upgrade task with --wait and --timeout flags.

C.Use the Kubernetes manifest task with 'canary' deployment strategy and configure 'stabilityCheck' and 'rollback' settings.

D.Use the Kubectl task with a 'rollback' subcommand condition.

AnswerC

The Kubernetes manifest task in Azure Pipelines supports a canary deployment strategy where you can specify 'stabilityCheck' to validate the canary version's health and 'rollback' settings to automatically revert to the last stable version if the canary fails the specified criteria, enabling automated rollback on health failure.

Why this answer

The Kubernetes manifest task in Azure DevOps supports a 'canary' deployment strategy with built-in 'stabilityCheck' and 'rollback' settings. This allows you to define a health check window (e.g., 5 minutes) and automatically trigger a rollback if the canary pods fail the stability checks, meeting the requirement without custom scripting.

Exam trap

The trap here is that candidates often assume any 'rollback' command or flag (like kubectl rollout undo or Helm --wait) will suffice, but they miss that the question specifically requires automatic rollback based on health checks within a 5-minute window after deployment, which only the Kubernetes manifest task's canary strategy with stabilityCheck and rollback settings provides.

How to eliminate wrong answers

Option A is wrong because using an Azure CLI task with 'kubectl rollout undo' in a post-deployment script requires manual logic to detect health check failures and does not integrate with the canary strategy's automatic stability checks. Option B is wrong because the Helm upgrade task with --wait and --timeout flags only waits for the deployment to reach a ready state during the upgrade, but does not provide a configurable post-deployment health check window or automatic rollback on failure. Option D is wrong because the Kubectl task with a 'rollback' subcommand condition is a generic command that lacks the canary-specific stability check and automatic rollback orchestration provided by the Kubernetes manifest task.

Practice this question →

150

MCQeasy

You need to create a pipeline that triggers only when changes are made to files in the 'src/api' folder. Which trigger configuration should you use?

A.trigger: branches: include: - 'main'

B.trigger: paths: exclude: - 'src/api/*'

C.trigger: tags: include: - 'v*'

D.trigger: paths: include: - 'src/api/*'

AnswerD

The `paths` filter with `include` is correct because it defines a file-path allowlist: the pipeline only triggers when a commit changes files under the `src/api/*` path. This ensures the pipeline runs exclusively when modifications occur in that directory, satisfying the requirement to trigger only on changes to `src/api`.

Why this answer

The `trigger: paths: include: - 'src/api/*'` configuration tells Azure Pipelines to only trigger the pipeline when changes are detected in files matching that path pattern. This is the standard way to scope pipeline triggers to specific folders or file patterns in YAML pipelines, ensuring that unrelated changes elsewhere in the repository do not start the pipeline.

Exam trap

The trap here is that candidates often confuse `include` with `exclude` or forget that path filters require explicit `include` statements to restrict triggers, leading them to pick option B which does the opposite of what is asked.

How to eliminate wrong answers

Option A is wrong because it only filters by branch (main) and does not restrict triggers to the 'src/api' folder, so any change on main would trigger the pipeline. Option B is wrong because it uses `exclude` with the path `src/api/*`, which explicitly prevents the pipeline from triggering when changes are made to that folder, the opposite of the requirement. Option C is wrong because it uses a tag trigger (`tags: include: - 'v*'`), which only fires when a tag matching the pattern is pushed, not when file changes occur in the 'src/api' folder.

Practice this question →