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

301

MCQeasy

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

A.Production slot

B.Warmup slot

C.Staging slot

D.All slots simultaneously

AnswerC

Deploying to a Staging slot is the correct approach because it lets you validate the build and perform pre-production checks without impacting live traffic. Once verified, you perform a swap between the Staging and Production slots, which is an atomic operation that keeps the app continuously available and enables quick rollback by swapping again if needed.

Why this answer

The slot swap strategy in Azure App Service deploys to a non-production slot (typically 'staging') first, allowing validation before swapping with the production slot. This eliminates downtime by warming up the staging slot and then routing traffic to it via a zero-downtime swap operation. Deploying directly to production would cause downtime or require manual traffic management.

Exam trap

The trap here is that candidates may think 'Warmup slot' is a real Azure slot name due to the term 'warmup' being used in Azure App Service settings (like application initialization), but Azure only provides 'production' and 'staging' as default slots, and custom slots must be explicitly created.

How to eliminate wrong answers

Option A is wrong because deploying directly to the Production slot would cause downtime during the deployment process, as the app would be restarted or updated in-place, defeating the purpose of a slot swap strategy. Option B is wrong because 'Warmup slot' is not a standard Azure App Service slot name; Azure uses 'staging' as the default non-production slot, and warmup is a process (e.g., application initialization) not a slot. Option D is wrong because deploying to all slots simultaneously would overwrite production and staging at the same time, eliminating the ability to validate changes before swapping and potentially causing downtime or failed rollbacks.

Practice this question →

302

Multi-Selectmedium

Which TWO conditions should you configure in a release pipeline to ensure that a deployment to production only happens when both the staging deployment succeeded and a manual approval is granted? (Choose two.)

Select 2 answers

A.Add a post-deployment approval on the staging stage.

B.Add a pre-deployment approval on the production stage.

C.Set the trigger to 'After release' and filter by artifact.

D.Set the deployment queue setting to 'After previous deployment' for the production stage.

E.Add a gate that checks if the staging deployment succeeded.

AnswersB, E

A pre-deployment approval on the production stage forces a designated user or group to explicitly approve the release before any production deployment is attempted. This acts as a manual gate that, because the production stage only triggers after staging completes, ensures production is deployed only after staging has succeeded and been reviewed.

Why this answer

To ensure release to production only after staging success and manual approval, you need a pre-deployment approval on the production stage (B) for the manual approval, and a pre-deployment gate on production that checks that the staging deployment succeeded (E). A gate is a valid condition that verifies the required state before deployment. Option D, the deployment queue setting 'After previous deployment', only controls concurrency of the same stage and does not create a dependency on the staging stage, so it does not ensure staging succeeded.

Exam trap

Deployment queue settings do not define stage dependencies; they only control how deployments of the same stage are queued. Stage dependencies are defined via triggers (e.g., 'After stage') or through gates that check external conditions.

Practice this question →

303

MCQhard

Refer to the exhibit. You are creating an ARM template to deploy an App Service and its Application Insights configuration. The template fails to deploy with error: 'The resource 'Microsoft.Insights/components/...' is not defined in the template.' What is the most likely cause?

A.The reference function cannot be used in a properties object.

B.The reference function syntax is incorrect.

C.The Application Insights component is not defined as a resource in the template.

D.The apiVersion for the config resource is outdated.

AnswerC

Correct: reference() can only refer to resources deployed in the same template or existing resources if using 'full' reference.

Why this answer

The error 'The resource 'Microsoft.Insights/components/...' is not defined in the template' indicates that the ARM template references an Application Insights component (e.g., via the `reference()` function or a `dependsOn` property) that is not declared as a resource within the template's `resources` array. In ARM templates, every resource you reference must be explicitly defined; otherwise, the deployment engine cannot resolve it, causing this validation error.

Exam trap

The trap here is that candidates often confuse a missing resource definition with a syntax error in the `reference()` function or an API version issue, but the error message explicitly says 'not defined', which points directly to the resource not being declared in the template's `resources` section.

How to eliminate wrong answers

Option A is wrong because the `reference()` function can be used in a `properties` object to retrieve runtime values from other resources, as long as those resources are defined in the template. Option B is wrong because the error message specifically states the resource is 'not defined', not that the syntax of `reference()` is incorrect; a syntax error would produce a different parsing error. Option D is wrong because an outdated `apiVersion` would cause a different error (e.g., 'The apiVersion parameter ... is not supported'), not a 'not defined' error for the resource itself.

Practice this question →

304

Multi-Selectmedium

Which TWO actions should you take to implement a secure build pipeline that uses Azure Key Vault to store secrets? (Choose two.)

Select 2 answers

A.Store the Key Vault name and secret names in a secure file in the repository.

B.Define secrets as pipeline variables and mark them as secret.

C.Grant the Azure DevOps service principal 'Get' and 'List' permissions on the Key Vault.

D.Use the 'Azure CLI' task to run 'az keyvault secret show' for each secret.

E.Use the 'Azure Key Vault' task to download secrets as pipeline variables.

AnswersC, E

Granting the Azure DevOps service principal 'Get' and 'List' permissions on the Key Vault is a mandatory prerequisite for the pipeline to retrieve secret names and values; without these permissions, the Azure Key Vault task fails, so you must configure an access policy or RBAC role assignment for the service principal.

Why this answer

The Azure DevOps service principal (the identity used by Azure Pipelines) must be granted 'Get' and 'List' permissions on the Key Vault's access policy. This allows the pipeline to retrieve secret values securely without storing credentials in the repository or pipeline configuration. Without these permissions, any attempt to read secrets from the vault will fail with an authorization error.

Exam trap

The trap here is that candidates often think storing secrets as pipeline variables (Option B) is sufficient, but the question specifically requires using Azure Key Vault, so the correct approach is to retrieve secrets from Key Vault at runtime using the dedicated task, not to hardcode them as pipeline variables.

Practice this question →

305

MCQmedium

Refer to the exhibit. You have this Azure Pipeline YAML. When you run the pipeline, it fails because the resource group name is not correctly resolved. What is the likely cause?

A.The script type 'pscore' is not supported on Ubuntu.

B.The variable 'resourceGroupName' uses $(environment) which cannot reference a parameter.

C.Parameters cannot be used in YAML pipelines; they must be defined in a template.

D.The 'trigger: none' prevents the pipeline from running.

AnswerB

The macro syntax `$(environment)` in a variable resolves to a runtime variable named 'environment', not to a pipeline parameter. Parameters are expanded at compile time via `${{ parameters.environment }}`, so this use would produce a null/empty value and cause the resource group name to be incorrect or undefined.

Why this answer

In Azure DevOps YAML pipelines, the `$()` syntax is used to reference runtime variables, not parameters. Parameters are defined using `parameters:` and are referenced with `${{ parameters.parameterName }}`. Using `$(environment)` attempts to resolve a variable named 'environment', but since 'environment' is defined as a parameter, it is not available as a variable at runtime, causing the resource group name to remain unresolved and the pipeline to fail.

Exam trap

The trap here is that candidates confuse the syntax for referencing parameters (`${{ }}`) with the syntax for referencing variables (`$()`), assuming both are interchangeable in YAML pipelines.

How to eliminate wrong answers

Option A is wrong because the script type 'pscore' (PowerShell Core) is fully supported on Ubuntu agents in Azure Pipelines; it runs pwsh, which is cross-platform. Option C is wrong because parameters are fully supported in YAML pipelines directly, not only in templates; they can be defined at the pipeline level using the `parameters:` keyword. Option D is wrong because `trigger: none` only disables CI triggers, but the pipeline can still be run manually or via other triggers; it does not cause a failure due to unresolved variables.

Practice this question →

306

MCQhard

You manage a release pipeline that deploys to multiple environments. The pipeline uses variables that differ per environment. You want to avoid duplicating variable definitions. Which strategy should you use?

A.Use variable groups linked to environments

B.Use the 'variables' section in the pipeline YAML with conditions

C.Define variables in each stage of the YAML pipeline

D.Store all variables in Azure Key Vault and reference them in the pipeline

AnswerA

Variable groups can be scoped to environments.

Why this answer

Variable groups linked to environments allow you to define variables once and have different values per environment without duplication. Option A is correct because variable groups can be scoped to specific environments, allowing you to reuse the same variable names with different values across environments. Option B is incorrect because using conditions in the 'variables' section still requires you to define each variable for each condition, leading to duplication.

Option C is incorrect because defining variables in each stage duplicates the variable definitions across stages. Option D is incorrect because while Azure Key Vault is useful for secrets, it is not designed for all types of variables, and you still need to reference the secrets per environment, which does not avoid duplication of variable references.

Practice this question →

307

MCQeasy

You need to run a set of tasks only when the build pipeline runs for the main branch. Which condition should you add to the job or step?

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

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

C.condition: and(succeeded(), eq(variables['System.PullRequest.TargetBranch'], 'main'))

D.condition: ne(variables['Build.Reason'], 'PullRequest')

AnswerA

This condition is correct because the Build.SourceBranch variable returns the full ref path, such as 'refs/heads/main', so the equality check accurately triggers only when the build originates from the main branch, ignoring other branches or tags.

Why this answer

The `Build.SourceBranch` variable in Azure Pipelines contains the full Git ref (e.g., `refs/heads/main`). Using `eq(variables['Build.SourceBranch'], 'refs/heads/main')` ensures the condition evaluates to true only when the pipeline runs on the main branch. This is the standard way to filter by branch in YAML pipeline conditions.

Exam trap

The trap here is that candidates often assume `Build.SourceBranch` contains only the short branch name (like `main`) rather than the full Git ref path (`refs/heads/main`), leading them to choose Option B.

Why the other options are wrong

Missing 'refs/heads/' prefix, so it won't match.

This checks PR target branch, not the source branch.

This excludes PRs but does not limit to main branch.

Practice this question →

308

MCQhard

Your YAML pipeline uses the 'AzureResourceManagerTemplateDeployment' task to deploy ARM templates. You need to handle incremental deployments and ensure that the task fails if any resource already exists and cannot be updated. Which deployment mode should you specify?

A.Incremental

B.Complete

C.Validate

D.CreateOrUpdate

AnswerA

Incremental mode is the default ARM deployment mode that only adds, updates, or deletes resources that are specified in the template, leaving all other resources in the resource group untouched. This allows users to perform partial updates by modifying only the relevant resources without affecting the entire resource group's existing configuration.

Why this answer

The 'Incremental' deployment mode in the AzureResourceManagerTemplateDeployment task handles only changes specified in the template, leaving existing resources unchanged. If a resource already exists and cannot be updated (e.g., due to a property conflict or immutable resource), the deployment fails, meeting the requirement to fail on such conflicts. This mode is the standard for additive, non-destructive ARM template deployments.

Exam trap

The trap here is that candidates confuse 'Incremental' with 'Complete' mode, mistakenly thinking 'Complete' is safer for incremental updates, when in fact 'Complete' can delete resources not in the template, leading to data loss.

Why the other options are wrong

Complete mode deletes resources not in the template; it does not fail on existing resources that cannot be updated.

Validate mode only validates the template without actually deploying resources.

There is no deployment mode named 'CreateOrUpdate'; it is a behavior of Incremental mode.

Practice this question →

309

MCQeasy

Your development team uses GitHub Actions for CI/CD. You need to ensure that secrets stored in GitHub repository secrets are not exposed in build logs. What is the best practice?

A.Use a custom action to manually mask secrets in the logs.

B.Define secrets as environment variables directly in the workflow YAML.

C.Store secrets in GitHub repository secrets and reference them in workflows using ${{ secrets.SECRET_NAME }}. GitHub automatically masks secrets in logs.

D.After the workflow runs, delete the logs from GitHub.

AnswerC

This is the recommended approach because GitHub encrypts secrets at rest, restricts access to authorized users/actions, and automatically detects the exact secret value used in the workflow to redact it from all log output. Referencing secrets via ${{ secrets.SECRET_NAME }} keeps the actual value out of the YAML source and ensures that any accidental printing of that value is masked in real time.

Why this answer

GitHub automatically masks secrets referenced via the ${{ secrets.SECRET_NAME }} syntax in workflow logs. When a secret is used in a workflow, GitHub Actions scans the log output and replaces any occurrence of the secret value with '***', preventing exposure. This built-in mechanism is the recommended best practice as it requires no additional configuration and works across all steps and actions.

Exam trap

The trap here is that candidates may think manual masking or log deletion is necessary, overlooking GitHub's built-in automatic secret masking that works seamlessly when secrets are properly referenced via the ${{ secrets.SECRET_NAME }} syntax.

How to eliminate wrong answers

Option A is wrong because using a custom action to manually mask secrets is error-prone and unnecessary; GitHub already provides automatic masking for secrets referenced in the standard way. Option B is wrong because defining secrets as environment variables directly in the workflow YAML file would expose the secret values in plain text within the repository, defeating the purpose of secure storage. Option D is wrong because deleting logs after a run does not prevent exposure during the run or before deletion, and it also removes valuable debugging information; the correct approach is to prevent exposure proactively.

Practice this question →

310

Multi-Selectmedium

Your release pipeline deploys to multiple environments sequentially: Dev, QA, Staging, Production. You need to implement manual approval gates before Staging and Production deployments. Which TWO configurations should you use? (Choose two.)

Select 2 answers

A.Add a post-deployment approval gate to the Dev and QA stages.

B.Use the 'Approvals and gates' settings in the release pipeline stage.

C.Configure branch policy on the release branch to require approvals.

D.Add a 'Manual Validation' task in the YAML pipeline.

E.Add a pre-deployment approval gate to the Staging and Production stages.

AnswersB, E

In classic release pipelines, the 'Approvals and gates' settings are configured per stage and allow you to add pre-deployment and post-deployment approvals, as well as gates such as query-based checks or Azure Monitor alerts. Pre-deployment approvals are the built-in mechanism to pause the pipeline before a stage runs, ensuring authorized reviewers approve the release before it reaches environments like Staging and Production.

Why this answer

The 'Approvals and gates' settings in a release pipeline stage allow you to configure pre-deployment approvals, which require designated users to approve the deployment before it proceeds. This is the standard mechanism in Azure DevOps for implementing manual approval gates. Option E is correct because adding a pre-deployment approval gate specifically to the Staging and Production stages ensures that deployments to these environments are blocked until the required approvals are granted, meeting the requirement for manual approval before Staging and Production.

Exam trap

The trap here is that candidates often confuse post-deployment approvals (which happen after deployment) with pre-deployment approvals (which gate the deployment), or they incorrectly think branch policies or manual validation tasks are the correct way to add manual approval gates in a release pipeline.

Practice this question →

311

MCQeasy

Your Azure DevOps pipeline uses a YAML template to avoid duplication. The template defines common build steps. You need to override one of the steps in a specific pipeline without modifying the template. Which approach should you use?

A.Use the 'overrides' keyword in the pipeline YAML to specify which steps to replace.

B.Create a copy of the template and modify the step directly.

C.Use a conditional 'if' statement in the template to skip steps based on a parameter.

D.Use template parameters with a 'steps' object that can be injected to override the step.

AnswerD

This is the supported pattern: declare a template parameter of type 'steps' and pass it through to the steps section of a job or stage. For example, define `parameters: - name: stepsOverride type: steps default: []` and then use `steps: ${{ parameters.stepsOverride }}` in the template; the caller can supply a list of steps as an argument to replace the default behavior. Because the parameter is a full steps object, the calling pipeline can inject any arbitrary step definitions without modifying the template file itself. This approach keeps the template reusable while allowing per-pipeline overrides.

Why this answer

Azure DevOps YAML templates support parameterized steps objects. By defining a template parameter of type 'steps' with a default value, the calling pipeline can pass a custom steps object as an argument to that parameter, effectively overriding the default steps without modifying the template. No 'replace' keyword is used; the override is achieved by directly injecting the steps object via the parameter.

Exam trap

The trap here is that candidates may confuse the fictional 'overrides' keyword (Option A) with a real feature, or incorrectly assume that conditional logic in the template (Option C) is the only way to control step execution, when in fact Azure DevOps provides a dedicated parameter injection pattern for step replacement using a steps object parameter.

How to eliminate wrong answers

Option A is wrong because Azure DevOps YAML does not support an `overrides` keyword; this is a fictional construct. Option B is wrong because creating a copy of the template defeats the purpose of reuse and introduces maintenance overhead, which is not the intended solution for overriding steps without modifying the template. Option C is wrong because using a conditional `if` statement in the template requires modifying the template itself, which violates the requirement to avoid modifying the template.

Practice this question →

312

MCQhard

Refer to the exhibit. You have a YAML pipeline definition that builds a .NET application. You notice that the revision number is always 0. What is the most likely cause?

A.The 'DotNetCoreCLI@2' task does not support the counter expression.

B.The counter expression uses a variable that is not defined as a counter, causing it to reset.

C.The counter expression resets every time the pipeline runs because of the 'minorVersion' variable.

D.The counter expression is evaluated after the build steps, so it always returns 0.

AnswerB

The seed should be a static value or a counter itself; using a non-counter variable as seed resets the counter each run.

Why this answer

The counter expression in Azure DevOps YAML pipelines requires a named counter variable to persist its value across pipeline runs. If the variable used as the first parameter of the `counter` function (e.g., `minorVersion`) is not defined as a counter variable, the counter resets to the seed value (0) on each run. Option B correctly identifies that the variable is not defined as a counter, causing the revision number to always be 0.

Exam trap

The trap here is that candidates assume the counter expression automatically increments without needing the first argument to be a persistent counter variable, leading them to overlook the requirement that the variable used as the counter name must be defined as a counter in the pipeline.

How to eliminate wrong answers

Option A is wrong because the `DotNetCoreCLI@2` task fully supports the counter expression; the issue is not with the task but with how the counter variable is defined. Option C is wrong because the counter expression does not reset due to the `minorVersion` variable itself; it resets because that variable is not defined as a counter variable in the pipeline. Option D is wrong because the counter expression is evaluated at compile time, before any build steps run, so evaluation order is not the cause of the always-0 result.

Practice this question →

313

MCQhard

Your organization uses GitHub Actions for CI/CD. You need to ensure that secrets stored in GitHub are not exposed in build logs. A developer accidentally printed a secret to the console in a workflow step. What built-in feature of GitHub Actions automatically prevents this?

A.Audit log monitoring

B.Secret scanning alerts

C.Required reviewers on workflows

D.Automatic log redaction

AnswerD

Automatic log redaction is the correct answer because GitHub Actions detects values of configured secrets in a job's output and replaces them with '***' in real time across all workflow run logs, effectively preventing secrets from appearing.

Why this answer

GitHub Actions includes a built-in feature that automatically redacts secrets from workflow run logs. When a secret is printed to the console, GitHub detects the secret value and replaces it with '***' in the log output, preventing accidental exposure. This redaction happens at the log rendering layer, not in the workflow execution, so the secret is never visible to users viewing the logs.

Exam trap

The trap here is that candidates often confuse secret scanning (which detects secrets in source code) with log redaction (which prevents secrets from appearing in CI/CD output), leading them to choose Option B instead of D.

How to eliminate wrong answers

Option A is wrong because audit log monitoring records administrative actions and events in the organization, but it does not prevent secrets from appearing in build logs—it only provides a historical record after the fact. Option B is wrong because secret scanning alerts detect secrets committed to repositories (e.g., in code or configuration files), not secrets printed during workflow execution in logs. Option C is wrong because required reviewers on workflows enforce approval for pull request workflows, but they do not inspect or redact log output for secrets.

Practice this question →

314

MCQmedium

Your team uses Azure Pipelines for CI/CD. You need to enforce that all builds produce a signed artifact. Which approach should you use?

A.Add a YAML template that includes the signing task and require all pipelines to extend it.

B.Set a branch policy requiring a signed build status.

C.Configure a manual approval gate on the build pipeline.

D.Use a Pipeline decorator to inject the signing task into every build pipeline.

AnswerD

Pipeline decorators are extension-based components that automatically inject a set of tasks into every pipeline (or a filtered subset) at either the start or end of a job, at the organization level. Because the decorator runs outside the individual pipeline definition, it cannot be bypassed by pipeline authors and does not require changes to existing YAML or classic builds. This provides the required guarantee that the signing task is applied to every build pipeline.

Why this answer

Pipeline decorators allow injecting tasks (like signing) into every pipeline globally without modifying individual pipeline definitions. Option A is wrong because YAML templates require each pipeline to explicitly extend them; they do not enforce automatic inclusion. Option B is wrong because branch policies control pull request merge conditions, not build steps.

Option C is wrong because manual approval gates are used in release pipelines to control promotion, not to enforce signing during build.

Practice this question →

315

MCQeasy

You are designing a build pipeline for a Node.js application. The team wants to ensure that the pipeline runs unit tests and publishes test results to Azure DevOps. Which task should you add to the pipeline?

A.Publish Test Results task

B.Copy Files task

C.npm test

D.Publish Build Artifacts task

AnswerA

The Publish Test Results task is correct because it explicitly consumes test result files (e.g., JUnit, NUnit, VSTest) and uploads them to Azure Pipelines, enabling test analytics, failure reporting, and trend dashboards in the build summary.

Why this answer

The Publish Test Results task (A) is correct because it specifically ingests test result files (e.g., JUnit, NUnit, xUnit, or TRX formats) and publishes them to Azure DevOps, enabling test analytics, trend charts, and pass/fail reporting in the pipeline summary. For a Node.js application, after running unit tests with a framework like Jest or Mocha, the test results are typically output as JUnit XML files, and this task is required to make those results visible in the DevOps portal.

Exam trap

The trap here is that candidates confuse running tests (npm test) with publishing test results, not realizing that Azure DevOps requires a separate task to ingest and display test outcomes in the pipeline UI.

How to eliminate wrong answers

Option B (Copy Files task) is wrong because it only copies files from source to a destination folder; it does not parse or publish test results. Option C (npm test) is wrong because it is a script step that runs the test command defined in package.json, but it does not publish test results to Azure DevOps—it only executes the tests locally in the pipeline. Option D (Publish Build Artifacts task) is wrong because it publishes build outputs (e.g., compiled code, binaries) as artifacts for deployment, not test result files for reporting.

Practice this question →

316

MCQhard

Refer to the exhibit. A developer queues a build manually but notices the build status remains 'notStarted' for an extended period. The pipeline has no demands and priority is normal. Which is the most likely cause?

A.The variable 'BuildConfiguration' is misspelled.

B.The branch 'main' does not exist.

C.All agents in the pool are currently busy.

D.The pipeline definition ID is incorrect.

AnswerC

When a build is queued without explicit agent demands, Azure Pipelines can run it on any agent in the specified pool. If all agents in that pool are currently executing other jobs, the build will remain in a queued state until an agent becomes available—this is a common cause of a build appearing stuck. The queue shows the build as 'Queued' or 'Waiting for agent' without raising an immediate error, which matches the exhibit behavior.

Why this answer

When a build remains in 'notStarted' status for an extended period, it typically means the pipeline is waiting for an available agent. Since the pipeline has no demands and priority is normal, the most likely cause is that all agents in the specified agent pool are currently busy executing other jobs, so the build is queued until an agent becomes free.

Exam trap

The trap here is that candidates often assume a 'notStarted' status is caused by a configuration error (like a missing branch or misspelled variable) rather than recognizing it as a classic symptom of agent pool exhaustion or queue saturation.

How to eliminate wrong answers

Option A is wrong because a misspelled variable like 'BuildConfiguration' would cause a build-time error or unexpected behavior during the build process, not prevent the build from starting; the build would still be assigned to an agent and run. Option B is wrong because if the branch 'main' does not exist, the build would fail at the source fetch step or trigger a 'not found' error, but the build would still be assigned to an agent and attempt to run, not remain 'notStarted'. Option D is wrong because the pipeline definition ID is used internally by Azure DevOps to identify the pipeline; an incorrect ID would prevent the build from being queued at all, resulting in an error when triggering the build, not a 'notStarted' status.

Practice this question →

317

MCQmedium

Your team is designing a build pipeline for a Java application that uses Maven. The pipeline must run unit tests and integration tests separately, and fail the build if integration tests fail. However, integration tests require a running database container. Which approach should you use to ensure the database is available for the integration tests?

A.Use a Docker Compose task in the pipeline to start the database container before running integration tests.

B.Configure the pipeline to use a self-hosted agent that has the database already installed and running.

C.Install the database as a service in the pipeline using the Service Fabric task.

D.Use a PowerShell script in the pipeline to install and start the database on the build agent.

AnswerA

Docker Compose provides a declarative way to run dependent services as containers.

Why this answer

Docker Compose allows you to define and start a database container as a dependency before running integration tests in a build pipeline. By using a Docker Compose task, you can ensure the database container is running in a clean, isolated environment, and the pipeline can fail the build if the integration tests fail. This approach is ideal for CI/CD pipelines where ephemeral, disposable infrastructure is needed for testing.

Exam trap

The trap here is that candidates may confuse the Docker Compose task with other Azure DevOps tasks like Service Fabric or generic scripting, failing to recognize that Docker Compose is the standard, built-in method for managing container dependencies in a pipeline.

How to eliminate wrong answers

Option B is wrong because using a self-hosted agent with a pre-installed database introduces statefulness and environment drift, making builds non-reproducible and harder to maintain across agents. Option C is wrong because the Service Fabric task is designed for deploying and managing microservices on Azure Service Fabric, not for starting a database container as a service in a build pipeline. Option D is wrong because using a PowerShell script to install and start a database on the build agent is error-prone, slow, and pollutes the agent's environment, whereas Docker Compose provides a cleaner, containerized solution.

Practice this question →

318

MCQmedium

Your organization uses GitHub for source control and Azure Pipelines for CI/CD. You need to implement a policy that requires all pull requests to pass a status check before merging. The status check should be provided by a pipeline that runs when a pull request is created. Which type of trigger should you configure in the pipeline YAML?

A.Push trigger

B.Manual trigger

C.PR trigger

D.Scheduled trigger

AnswerC

A PR trigger in Azure Pipelines automatically starts a pipeline whenever a pull request is created or gets new commits, enabling validation of code changes before merging. This is the correct trigger type for validating pull requests, as it directly responds to PR events.

Why this answer

A PR trigger (pr:) in Azure Pipelines YAML automatically runs the pipeline when a pull request is created or updated against a specified branch. This allows the pipeline to produce a status check that GitHub enforces as a required check before merging, fulfilling the policy requirement.

Exam trap

The trap here is that candidates often confuse push triggers with PR triggers, thinking a push to the target branch will suffice, but the status check must be tied to the PR's merge commit or head branch, which only a PR trigger can automate.

How to eliminate wrong answers

Option A is wrong because a push trigger runs the pipeline on commits to a branch, not on pull request creation, so it cannot provide a status check tied to the PR lifecycle. Option B is wrong because a manual trigger requires a user to explicitly start the pipeline, which is not automated and cannot enforce a required status check without human intervention. Option D is wrong because a scheduled trigger runs the pipeline at specified times (e.g., nightly), independent of pull request events, so it cannot provide a real-time status check for PRs.

Practice this question →

319

MCQhard

You have a multi-stage YAML pipeline in Azure DevOps that deploys to multiple environments. The pipeline uses a deployment job with environment approvals. You need to ensure that the deployment to the production environment is only triggered after a manual approval is granted. However, you also want the deployment to automatically roll back if the post-deployment health check fails. Which configuration should you implement?

A.Use a release pipeline with a pre-deployment approval and a post-deployment automatic rollback trigger.

B.Configure pre-deployment approvals on the production environment and use a post-deployment gate that fails the deployment.

C.Configure pre-deployment approvals and add a manual intervention task to roll back if health check fails.

D.Enable 'Auto-revert' on the production environment and set post-deployment conditions.

AnswerD

Auto-revert is a native environment setting that, when enabled, automatically redeploys the previously successful version (the last known good deployment) whenever post-deployment conditions, such as health-check gates, mark the current deployment as failed. This provides the automatic rollback behavior required without human intervention or a classic release pipeline, and it is fully integrated with YAML multi-stage pipelines. Setting post-deployment conditions ensures that the health check is evaluated before the revert trigger fires.

Why this answer

Azure DevOps environments support an 'Auto-revert' setting that automatically triggers a rollback to the previous successful deployment when a post-deployment health check (defined via post-deployment conditions) fails. This combines manual approval (pre-deployment approvals on the environment) with automatic rollback, meeting both requirements without additional tasks or release pipelines.

Exam trap

The trap here is that candidates confuse 'Auto-revert' with classic release pipeline features or assume manual intervention tasks are needed for rollback, overlooking the environment-level automatic rollback capability in YAML pipelines.

How to eliminate wrong answers

Option A is wrong because it suggests using a release pipeline with pre-deployment approvals and a post-deployment automatic rollback trigger, but the question specifies a multi-stage YAML pipeline, not a classic release pipeline; the 'Auto-revert' feature is environment-specific and not a release pipeline trigger. Option B is wrong because configuring a post-deployment gate that fails the deployment does not automatically roll back; it only marks the deployment as failed, requiring manual intervention to revert. Option C is wrong because adding a manual intervention task to roll back contradicts the requirement for automatic rollback; manual intervention tasks require human action, not automation.

Practice this question →

320

MCQmedium

Your release pipeline deploys to multiple environments sequentially. The deployment to production fails intermittently due to a database schema migration issue. You need to implement a strategy that automatically rolls back the deployment if the migration fails. What should you do?

A.Enable 'Auto-rollback' in the release pipeline settings.

B.Use a multi-stage YAML pipeline with manual intervention.

C.Configure pre-deployment approval gates.

D.Add a post-deployment script that runs a rollback script on failure.

AnswerD

A rollback script can be triggered on failure to revert changes.

Why this answer

It directly addresses the requirement to automatically roll back the deployment when a database schema migration fails. By adding a post-deployment script that runs a rollback script on failure, you can execute custom logic (e.g., reverting schema changes using SQL scripts or tools like Entity Framework migrations) immediately after the deployment step detects an error. This approach provides fine-grained control over the rollback process, which is essential for database migrations that cannot be handled by Azure Pipelines' built-in auto-rollback feature, which only reverts the application deployment (e.g., swapping slots or restoring files) and does not execute custom rollback scripts.

Exam trap

The trap here is that candidates often confuse the built-in 'Auto-rollback' feature (Option A) with a comprehensive rollback solution, not realizing that it only reverts application artifacts and cannot handle stateful changes like database schema migrations, which require custom rollback scripts.

How to eliminate wrong answers

Option A is wrong because 'Auto-rollback' in release pipeline settings only reverts the application deployment (e.g., by swapping back deployment slots or restoring previous artifacts) and does not execute custom scripts to undo database schema changes, which are stateful and require specific rollback logic. Option B is wrong because a multi-stage YAML pipeline with manual intervention introduces a human approval step, which does not provide automatic rollback on failure; it only pauses the pipeline for manual decision-making, contradicting the requirement for an automated strategy. Option C is wrong because pre-deployment approval gates are used to validate conditions (e.g., checking monitoring metrics or work items) before allowing a deployment to proceed, and they do not trigger any rollback actions after a deployment has already failed.

Practice this question →

321

Multi-Selectmedium

You manage a release pipeline for a Java application that is deployed to Azure App Service. The pipeline currently uses manual approval gates. You need to implement automated quality gates to reduce manual intervention. Which THREE conditions can you use in the 'Post-deployment approvals' settings of a release pipeline? (Choose three.)

Select 3 answers

A.Azure Policy

B.Manual approval

C.Invoke Azure Functions

D.REST API

E.Query Azure Monitor alerts

AnswersC, D, E

Invoke Azure Functions is a native release gate that executes an Azure Function with the release context, using the function's response (e.g., success/failure, custom payload) to determine if the deployment should proceed. This enables robust, custom quality logic to be hosted serverlessly and automatically evaluated.

Why this answer

'Invoke Azure Functions' is a valid gate type in Azure DevOps release pipelines. It allows you to call an Azure Function as a quality gate, enabling custom automated checks (e.g., validating deployment health or running custom logic) without manual intervention. This directly supports the goal of reducing manual approvals by automating post-deployment validation.

Exam trap

The trap here is that candidates may confuse Azure Policy (a governance tool) with a pipeline gate, or think that manual approval can be automated, when in fact the question explicitly asks for automated quality gates that reduce manual intervention.

Practice this question →

322

Multi-Selectmedium

Which TWO practices should you adopt to improve the security of your Azure DevOps pipeline? (Choose two.)

Select 2 answers

A.Grant the least privilege to service connections

B.Use Azure Key Vault to store secrets and fetch them at runtime

C.Use the default hosted agent for all builds

D.Store secrets as plain text in pipeline variables

E.Allow contributors to bypass the required reviewer policy

AnswersA, B

Granting least privilege to service connections means configuring each Azure Pipelines service connection with only the minimum permissions required for its intended tasks, limiting the blast radius if credentials are compromised and preventing accidental or malicious overreach to unrelated Azure resources.

Why this answer

Granting the least privilege to service connections (Option A) is a core security principle that limits the permissions of automated processes to only what is strictly necessary, reducing the blast radius of a compromised connection. Using Azure Key Vault to store secrets and fetch them at runtime (Option B) ensures that sensitive values like API keys and passwords are never exposed in pipeline definitions or logs, and are securely retrieved via managed identities or service principals at execution time.

Exam trap

The trap here is that candidates may think using default hosted agents is secure because Microsoft manages them, but they overlook the risk of unpatched vulnerabilities or unnecessary software in the default image, and they may also mistakenly believe that storing secrets as pipeline variables is acceptable if they are marked as 'secret' in the UI, when in fact they are still stored in the pipeline's metadata and can be exposed in logs.

Practice this question →

323

MCQeasy

You have an Azure DevOps Pipeline that builds a Node.js application. The pipeline uses template expressions to conditionally run certain jobs based on the branch name. You notice that the condition 'eq(variables['Build.SourceBranch'], 'refs/heads/main')' is not evaluating as expected. What is the most likely cause?

A.The variable 'Build.SourceBranch' is misspelled; it should be 'Build.SourceBranchName'.

B.The condition syntax is correct but the branch name should not include 'refs/heads/'.

C.The variable 'Build.SourceBranch' is not available in the condition context.

D.The condition should be in a template expression instead of a runtime condition.

AnswerC

Correct. Template expressions are evaluated at compile time, where runtime variables like 'Build.SourceBranch' are not available. Therefore, the condition cannot evaluate correctly. Use a runtime condition instead, or pass the branch as a parameter.

Why this answer

The condition 'eq(variables['Build.SourceBranch'], 'refs/heads/main')' is used in a template expression, which is evaluated at compile time. However, 'Build.SourceBranch' is a runtime variable that is not available during compile time, causing the condition to fail. Template expressions can only reference parameters or variables defined within the template itself, not runtime pipeline variables.

To conditionally run jobs based on the branch, use a runtime condition (e.g., in the 'condition' property of a job or stage) instead of a template expression.

Exam trap

Candidates may assume that all predefined variables are available in template expressions, but runtime variables like Build.SourceBranch are only available at runtime. The correct approach is to use a runtime condition (e.g., in the job's condition field) instead of a template expression for branch-based conditions.

How to eliminate wrong answers

Option B is wrong because the condition syntax is correct, but the branch name should include 'refs/heads/' when using 'Build.SourceBranch' (if it were valid), but the real issue is the variable name is incorrect. Option C is wrong because 'Build.SourceBranch' is not a predefined variable in Azure DevOps; the correct variable is 'Build.SourceBranchName', which is available in the condition context. Option D is wrong because the condition is already a runtime condition (using 'eq'), and template expressions are used for compile-time evaluation, not for runtime conditions like this.

Practice this question →

324

MCQmedium

You maintain a classic release pipeline that deploys to multiple environments. You need to ensure that a deployment to the Production environment only proceeds after a manual approval from a specific group of users. Which feature should you configure?

A.Post-deployment approvals on the Production environment

B.Deployment queue settings on the Production environment

C.Deployment gates on the Production environment

D.Pre-deployment approvals on the Production environment

AnswerD

Pre-deployment approvals are explicitly designed to pause the release pipeline before a deployment to an environment begins, requiring a designated approver to review and approve the release. For a Production environment, this ensures that a human sign-off is obtained before any code is deployed to Production.

Why this answer

Pre-deployment approvals are configured on an environment to require manual sign-off before a release is deployed to that environment. In a classic release pipeline, this ensures that the deployment to Production only proceeds after a specific group of users has approved it, meeting the requirement for manual approval before deployment.

Exam trap

The trap here is confusing pre-deployment approvals with deployment gates, as both can pause a deployment, but gates are automated checks (e.g., monitoring metrics) while approvals require explicit human action from a designated group.

How to eliminate wrong answers

Option A is wrong because post-deployment approvals occur after the deployment has already completed, not before, so they cannot gate the deployment to Production. Option B is wrong because deployment queue settings control how releases are queued and parallel execution, not manual approval requirements for a specific environment. Option C is wrong because deployment gates evaluate health metrics or external conditions automatically (e.g., via Azure Monitor or REST APIs) and do not provide manual approval from a specific group of users.

Practice this question →

325

MCQmedium

Your build pipeline uses a YAML template to define steps. You want to pass a parameter to the template to conditionally run a task. What syntax should you use in the template?

A.parameters:

B.arguments:

C.inputs:

D.variables:

AnswerA

Template parameters are defined under the `parameters:` key at the top of a YAML template file, allowing values to be passed from the calling pipeline via `${{ parameters.paramName }}` syntax. This makes templates reusable and configurable at compile time, before the pipeline runs.

Why this answer

The 'parameters' key in a YAML template is used to define parameters that can be passed to the template, allowing conditional execution based on the parameter value. Option B is incorrect: 'arguments' is not a standard YAML key for passing parameters to templates; it is used for specifying script arguments. Option C is incorrect: 'inputs' is used for task inputs within a step, not for template parameters.

Option D is incorrect: 'variables' are used to define pipeline variables, not for passing parameters to templates.

Practice this question →

326

MCQmedium

Refer to the exhibit. A developer commits code to the 'develop' branch. The pipeline does not trigger. What is the most likely reason?

A.The trigger is configured to only run on the 'main' branch.

B.The pipeline requires a manual trigger.

C.The pipeline has a CI trigger disabled.

D.The pool 'ubuntu-latest' is not available.

AnswerA

The YAML pipeline defines a CI trigger using `trigger: - main`, which instructs Azure Pipelines to start a run only for pushes that land on the `main` branch. A commit pushed to `devel` does not match that branch filter, so no pipeline run is created. Therefore the reason for the missing run is scope, not a bad agent pool or manual mode.

Why this answer

The trigger is set to 'main' branch only. Commits to 'develop' will not trigger the pipeline.

Practice this question →

327

MCQhard

Your company has a large monorepo with multiple microservices. You have a single YAML-based Azure Pipeline that builds the entire solution on every commit to the main branch. The pipeline takes over an hour to complete, causing long feedback loops. Developers often submit changes to only one service, but the whole pipeline runs. You need to reduce build time while maintaining quality. You are considering splitting the pipeline into multiple pipelines, each for a service, and using path triggers. However, some services have dependencies on shared libraries that are updated infrequently. You also need to ensure that integration tests that span multiple services still run when necessary. What should you do?

A.Create separate pipelines for each service with path triggers, and create an additional comprehensive pipeline that triggers only when shared libraries change.

B.Keep the single pipeline but add caching for dependencies.

C.Use a single pipeline but add conditional stages to skip unchanged services.

D.Create separate pipelines for each service with path triggers, and disable the comprehensive pipeline.

AnswerA

This approach uses path-based triggers to run individual service pipelines only when their source changes, reducing build time and resource usage. The additional comprehensive pipeline, triggered only by modifications to shared libraries, ensures cross-service integration tests still run when dependencies change, preserving integration testing without unnecessary builds.

Why this answer

It uses path triggers to run only the pipeline for the changed service, drastically reducing build time. The additional comprehensive pipeline, triggered only when shared libraries change, ensures that integration tests spanning multiple services still run when dependencies are updated, maintaining quality.

Exam trap

The trap here is that candidates may think caching (Option B) or conditional stages (Option C) are sufficient, but they fail to address the need for integration tests across services when shared libraries change, which requires a separate comprehensive pipeline with path triggers.

How to eliminate wrong answers

Option B is wrong because caching dependencies reduces build time for repeated steps but does not address the core issue of running the entire pipeline for every commit, including unchanged services. Option C is wrong because conditional stages to skip unchanged services still require evaluating the entire pipeline, and Azure Pipelines does not natively support skipping stages based on changed paths without complex scripting; it also does not solve the integration test problem for shared library changes. Option D is wrong because disabling the comprehensive pipeline means integration tests that span multiple services will not run when shared libraries change, breaking the requirement to maintain quality.

Practice this question →

328

MCQmedium

Your Azure DevOps project uses Git for source control. You want to enforce that all code changes are reviewed before merging into the main branch. Which branch policy should you enable?

A.Allow only comment resolution.

B.Require a successful build before merging.

C.Limit merge types to squash merge.

D.Require a minimum number of reviewers.

AnswerD

Setting a minimum number of reviewers is the branch policy that directly enforces code review: a pull request cannot be completed until the specified number of distinct users have explicitly approved it. This ensures that changes receive independent human verification before they are merged into the target branch.

Why this answer

The 'Require a minimum number of reviewers' branch policy ensures that a specified number of reviewers must approve a pull request before it can be merged, directly enforcing code review. Option A is incorrect because 'Allow only comment resolution' pertains to how comments are resolved, not requiring approvals. Option B is incorrect because 'Require a successful build before merging' validates build status but does not enforce review.

Option C is incorrect because 'Limit merge types to squash merge' controls the merge strategy, not the review process.

Practice this question →

329

MCQmedium

Refer to the exhibit. A release is created with the above command. The Dev environment starts deploying, but the Prod environment does not. Which is the most likely reason?

A.The Prod environment requires manual approval before deployment.

B.The release definition ID 5 is incorrect.

C.The Prod environment has a pre-deployment condition that waits for the Dev environment to succeed.

D.The build artifact with ID 123 is not accessible.

AnswerC

The Prod environment's pre-deployment condition is configured to trigger only after a successful deployment to the Dev environment. In Azure DevOps release pipelines, environment-level pre-deployment gates can be set to 'After environment' and specify a dependency on a prior environment's completion. If that condition is set to require Dev to succeed, the Prod deployment will remain in a 'Waiting' state until Dev finishes, which precisely matches the observed behavior. This is the default dependency model when you add environments sequentially, and it explains why Prod is delayed even though the artifact is valid and no approvals are configured.

Why this answer

The exhibit shows a release pipeline with a sequential deployment strategy where the Prod environment has a pre-deployment condition configured to wait for the Dev environment to succeed. In Azure DevOps, pre-deployment conditions can be set to trigger only after a specific environment (like Dev) completes successfully. Since the Dev environment is still deploying, the Prod environment remains in a waiting state and does not start.

Exam trap

The AZ-400 exam often tests the distinction between manual approval and sequential environment dependencies, where candidates mistakenly assume a missing approval gate when the real issue is a pre-deployment condition waiting for a prior environment to succeed.

How to eliminate wrong answers

Option A is wrong because while manual approval is a common pre-deployment condition, the exhibit does not show any approval gates configured; the most likely reason based on the default behavior is the sequential dependency. Option B is wrong because the release definition ID 5 is used to create the release, and if it were incorrect, the release creation itself would fail, not just the Prod deployment. Option D is wrong because if the build artifact with ID 123 were not accessible, the release creation or Dev deployment would fail first, not specifically block Prod while Dev is deploying.

Practice this question →

330

Multi-Selecteasy

Your organization uses GitHub Actions for CI/CD. You need to ensure that workflows are only triggered when changes are pushed to the main branch or when a pull request is opened against main. Which two trigger types should you specify in the workflow?

Select 2 answers

A.pull_request: branches: [ main ]

B.push: branches: [ main ]

C.release

D.workflow_dispatch

E.schedule

AnswersA, B

The `pull_request` event triggers the workflow when a pull request is opened, synchronized, or reopened, and the `branches: [ main ]` filter ensures it only runs for PRs whose base branch is `main`. This is the correct choice because it enables CI on proposed changes before merging, catching issues early in the review process while avoiding runs for PRs targeting other branches.

Why this answer

The `pull_request` trigger with `branches: [ main ]` ensures the workflow runs when a pull request is opened (or updated) targeting the main branch. Option B is correct because the `push` trigger with `branches: [ main ]` ensures the workflow runs when commits are pushed directly to the main branch. Together, these two triggers cover the exact requirement: changes pushed to main and pull requests opened against main.

Exam trap

The trap here is that candidates often confuse `pull_request` with `pull_request_target` or forget that `push` and `pull_request` are separate events, leading them to select only one trigger or add irrelevant triggers like `release` or `schedule`.

Practice this question →

331

MCQeasy

Your team is using GitHub Actions to deploy a containerized application to Azure Kubernetes Service (AKS). You need to securely authenticate the workflow to AKS without storing credentials in the repository. What should you use?

A.Use OpenID Connect (OIDC) with a federated identity credential.

B.Use the GITHUB_TOKEN to authenticate to Azure.

C.Use an SSH deploy key to authenticate to AKS.

D.Store an Azure service principal password as a GitHub secret.

AnswerA

OpenID Connect (OIDC) with a federated identity credential is the recommended approach because it eliminates static secrets: GitHub Actions exchanges a short-lived token with Azure AD, and Azure trusts the federated identity without requiring you to store any passwords or client secrets. This provides passwordless, rotation-free authentication that is more secure and easier to manage.

Why this answer

OpenID Connect (OIDC) allows GitHub Actions to exchange a short-lived token for Azure credentials using a federated identity credential, eliminating the need to store any long-lived secrets in the repository. This is the recommended approach for secure, passwordless authentication to Azure services, including AKS, because it uses token-based authentication that automatically rotates and is scoped to specific workflows.

Exam trap

The trap here is that candidates often confuse the GITHUB_TOKEN (which is for GitHub API calls) with an Azure authentication token, or they assume that storing a service principal password as a secret is acceptable, missing the security and compliance benefits of OIDC-based federated identity.

How to eliminate wrong answers

Option B is wrong because the GITHUB_TOKEN is scoped to the GitHub repository and cannot authenticate to Azure resources; it is used for GitHub API operations only. Option C is wrong because SSH deploy keys are used for Git repository access (e.g., cloning private repos), not for authenticating to Azure Kubernetes Service or any Azure resource. Option D is wrong because storing an Azure service principal password as a GitHub secret still requires managing a long-lived credential, which violates the requirement to avoid storing credentials in the repository and introduces security risks such as secret rotation and exposure.

Practice this question →

332

MCQeasy

You are configuring a release pipeline to deploy to Azure App Service. You want to use the 'Deploy Azure App Service' task. Which authentication method should you use to securely connect Azure DevOps to the Azure subscription?

A.Azure CLI authentication with a user account.

B.Azure Resource Manager service connection using a service principal.

C.Use a SAS token for the App Service.

D.Managed Identity assigned to the Azure DevOps agent.

AnswerB

An Azure Resource Manager service connection using a service principal is the recommended secure, automated authentication method for CI/CD pipelines; it uses an app registration with a secret or certificate, enables fine-grained role-based access control, and avoids interactive login requirements.

Why this answer

The 'Deploy Azure App Service' task requires a secure, non-interactive connection between Azure DevOps and Azure. An Azure Resource Manager service connection using a service principal is the recommended and supported method because it uses Azure AD authentication with a client secret or certificate, enabling automated, credential-free deployments without user interaction or token expiry issues.

Exam trap

The trap here is that candidates confuse SAS tokens (used for storage-level access) with service principal authentication, or mistakenly think Managed Identity can be directly assigned to a non-Azure-hosted DevOps agent, when in fact service connections require a service principal for secure, automated subscription access.

How to eliminate wrong answers

Option A is wrong because Azure CLI authentication with a user account requires interactive login and is not suitable for automated pipelines; it also lacks the necessary service principal permissions for headless deployment. Option C is wrong because a SAS token is used for granting delegated access to Azure Storage resources (like blobs or files), not for authenticating Azure DevOps to the Azure subscription or App Service management plane. Option D is wrong because Managed Identity cannot be assigned directly to an Azure DevOps agent; it is a feature for Azure resources (e.g., VMs, App Services) and is not supported as an authentication method for Azure DevOps service connections.

Practice this question →

333

MCQmedium

Your organization uses Azure Pipelines and wants to enforce that all builds must pass a security scan before being deployed to production. The security scan is performed by a third-party tool that is not available as a built-in task. You have installed the tool on a self-hosted agent. What is the best way to integrate the security scan into the pipeline?

A.Add the tool as a capability of the agent pool and use the 'Install Tool' task.

B.Add the 'Run Security Scan' task from the Azure DevOps marketplace.

C.Create a custom service hook to trigger the scan externally and wait for results.

D.Use a command-line task (e.g., Bash, PowerShell) to execute the security scan tool.

AnswerD

A Command-Line, Bash, or PowerShell task can directly invoke any installed security scanning executable (e.g., Trivy, OWASP ZAP, a custom CLI, or a vendor's command-line tool) with the appropriate arguments, run it against the repository workspace, and fail the pipeline based on the tool's exit code. This is the standard, supported way to integrate command-line-based security scanning into an Azure Pipeline because it runs inside the agent job and can produce actionable results.

Why this answer

The security scan tool is installed on a self-hosted agent but not available as a built-in task or marketplace extension. Using a command-line task (Bash or PowerShell) allows you to directly invoke the tool's executable from the agent's file system, passing necessary parameters and capturing exit codes to determine success or failure. This approach integrates seamlessly with Azure Pipelines' standard task execution model without requiring custom extensions or external service hooks.

Exam trap

The trap here is that candidates may assume a marketplace task or service hook is required for any third-party tool, overlooking the simplicity and directness of using a command-line task when the tool is already installed on a self-hosted agent.

How to eliminate wrong answers

Option A is wrong because the 'Install Tool' task is designed to download and install tools from a specified URL or Azure storage, not to execute a tool already installed on the agent; adding the tool as a capability only labels the agent for targeting, it does not run the scan. Option B is wrong because the 'Run Security Scan' task from the marketplace does not exist for this specific third-party tool; marketplace tasks are pre-built integrations, and if the tool is not available there, you cannot use a generic marketplace task to execute it. Option C is wrong because creating a custom service hook to trigger the scan externally and wait for results introduces unnecessary complexity, latency, and potential failure points; service hooks are for event-driven notifications, not for synchronous execution of a local tool within a pipeline job.

Practice this question →

334

MCQhard

You are setting up a GitHub Actions workflow to deploy a containerized application to Azure Kubernetes Service (AKS). You need to securely authenticate to the AKS cluster using a service principal. What is the recommended way to store and use the service principal credentials?

A.Use managed identity for GitHub Actions and assign it to the AKS cluster

B.Store the service principal credentials in a Kubernetes secret in the AKS cluster

C.Store the service principal credentials as GitHub Actions secrets and reference them in the 'azure/login' action

D.Store the service principal credentials as environment variables in the workflow file

AnswerC

GitHub Actions secrets are encrypted at rest, masked in logs, and injected into the workflow runtime only when explicitly referenced, making them the secure, supported way to pass service principal credentials. The 'azure/login' action accepts these credentials via secret inputs (e.g., 'client-id', 'client-secret', 'subscription-id', 'tenant-id') and uses them to establish an authenticated session with Azure, so storing them as GitHub Actions secrets and referencing them in that action is the correct, best-practice approach.

Why this answer

GitHub Actions secrets are the recommended secure mechanism for storing sensitive credentials like a service principal's client ID and secret. The 'azure/login' action can directly reference these secrets (e.g., `${{ secrets.AZURE_CREDENTIALS }}`) to authenticate to Azure, and then the 'azure/aks-set-context' action uses that authenticated session to connect to the AKS cluster. This approach avoids hardcoding credentials in the workflow file and leverages GitHub's encrypted storage.

Exam trap

The trap here is that candidates may confuse storing credentials in Kubernetes secrets (which is valid for in-cluster applications) with the initial authentication needed from an external CI/CD system, or they may think managed identities can be directly assigned to GitHub Actions runners, which is not supported.

How to eliminate wrong answers

Option A is wrong because managed identity for GitHub Actions is not directly supported for authenticating to AKS; managed identities are Azure resources that cannot be assigned to GitHub Actions runners, and the AKS cluster would need to trust the GitHub runner's identity, which is not a standard authentication flow. Option B is wrong because storing service principal credentials in a Kubernetes secret within the AKS cluster does not help the GitHub Actions workflow authenticate to the cluster initially; the workflow needs credentials to access the cluster before it can read any Kubernetes secrets. Option D is wrong because storing credentials as environment variables in the workflow file exposes them in plain text in the workflow logs and repository, violating security best practices and potentially leaking secrets.

Practice this question →

335

MCQhard

You are deploying a multi-container application to Azure Kubernetes Service (AKS) using Azure Pipelines. You need to ensure that the deployment rollback automatically if the health checks fail. Which strategy should you implement?

A.Configure a rolling update with readiness and liveness probes

B.Use a blue-green deployment strategy

C.Use Helm charts with pre-upgrade hooks

D.Implement a canary deployment with manual verification

AnswerA

Configure a rolling update with readiness and liveness probes: This approach leverages Kubernetes' native deployment controller to gradually replace pods while continuously checking health signals. If a readiness probe fails on new pods, the rollout immediately stops and Kubernetes automatically rolls back to the last healthy replica set, ensuring zero manual intervention and no downtime.

Why this answer

A rolling update with readiness and liveness probes is the correct strategy because Kubernetes automatically monitors pod health via these probes. If a new pod fails its readiness probe, the rolling update pauses; if the liveness probe fails, the pod is restarted. Azure Pipelines can be configured to detect probe failures and trigger a rollback to the previous stable ReplicaSet, ensuring automated recovery without manual intervention.

Exam trap

The trap here is that candidates often confuse deployment strategies (blue-green, canary) with the mechanism for automated health-check-based rollback, overlooking that Kubernetes native probes combined with rolling updates provide the simplest and most automatic solution.

How to eliminate wrong answers

Option B is wrong because blue-green deployment requires manual or scripted traffic switching and does not inherently provide automatic rollback based on health checks; it typically relies on external verification. Option C is wrong because Helm pre-upgrade hooks run before the upgrade and are used for tasks like database migrations, not for monitoring health after deployment or triggering rollbacks. Option D is wrong because canary deployment with manual verification depends on human approval to proceed or roll back, which contradicts the requirement for automatic rollback based on health checks.

Practice this question →

336

Multi-Selecthard

Which THREE features are available in GitHub Actions for managing secrets across environments?

Select 3 answers

A.Encrypted variables in workflows

B.Organization-level secrets

C.Secret scanning alerts

D.Environment-specific secrets

E.Repository-level secrets

AnswersB, D, E

Organization-level secrets are a core GitHub Actions feature that lets administrators define secrets once at the organization level so they are available to all repositories within that organization, enabling centralized management and consistent access across multiple workflows without duplicating sensitive values.

Why this answer

GitHub Actions supports three types of secrets for managing sensitive data: organization-level secrets, which are encrypted and shared across multiple repositories within an organization; repository-level secrets, which are available to all workflows in a single repository; and environment-specific secrets, which are scoped to a particular environment (e.g., production) within a repository. Together these allow centralized and scoped management of secrets across different environments and repositories. Options A and C are incorrect: 'encrypted variables in workflows' is not the official GitHub Actions secret feature, and secret scanning alerts is a reactive security service, not a secret management feature.

Exam trap

The trap here is that candidates confuse 'secret scanning alerts' (a reactive security feature) with proactive secret management features, or assume 'encrypted variables' is a valid term when GitHub Actions officially uses 'secrets' for encrypted sensitive data.

Practice this question →

337

MCQeasy

You need to configure a build pipeline that triggers only when changes are pushed to the 'release/*' branch. Which trigger configuration should you use?

A.Set 'trigger: none' in YAML

B.Set 'trigger: branches: include: - release/*'

C.Set 'trigger: branches: include: - main'

D.Set 'trigger: tags: include: - v*'

AnswerB

Setting 'trigger: branches: include: - release/*' configures the pipeline to automatically run on every push to any branch matching the release/* wildcard. This precisely matches the requirement to trigger only for release branches, making it the correct choice.

Why this answer

The YAML trigger configuration 'trigger: branches: include: - release/*' explicitly specifies that the pipeline should run only when changes are pushed to any branch matching the 'release/*' wildcard pattern. This is the standard way to define branch-based triggers in Azure Pipelines YAML, ensuring that only pushes to release branches initiate the build.

Exam trap

The trap here is that candidates often confuse branch triggers with tag triggers or forget that omitting a trigger defaults to 'include all branches', leading them to incorrectly select a tag-based option or a branch that doesn't match the required pattern.

How to eliminate wrong answers

Option A is wrong because 'trigger: none' disables all CI triggers, meaning the pipeline will never run automatically on any branch push, which contradicts the requirement to trigger on 'release/*' branches. Option C is wrong because it includes only the 'main' branch, which does not match the 'release/*' pattern and would ignore pushes to release branches. Option D is wrong because it configures a tag-based trigger (tags starting with 'v'), not a branch-based trigger; tags are separate from branches and do not respond to branch pushes.

Practice this question →

338

MCQmedium

The exhibit shows a deployment job in an Azure Pipelines YAML file. The deployment fails with the error 'No package found with pattern: $(Pipeline.Workspace)/drop/*.zip'. What is the most likely cause?

A.The artifact is not downloaded to the expected path; the artifact name must be included in the path.

B.The wildcard pattern '*.zip' is not supported.

C.The Azure service connection has expired.

D.The pipeline is using a Microsoft-hosted agent that does not support the download task.

AnswerA

The downloaded artifact is placed under '$(Pipeline.Workspace)/<artifact name>/'. If the artifact is named 'drop', the correct path is '$(Pipeline.Workspace)/drop'.

Why this answer

The error indicates the deployment job is looking for a .zip file in a folder named 'drop' directly under the pipeline workspace. However, in Azure Pipelines, artifacts are downloaded to a folder named after the artifact, and the published artifact contains a 'drop' folder inside it (or 'drop' is merely a folder, not the artifact name). The correct path must include the artifact name first, e.g., '$(Pipeline.Workspace)/<artifact-name>/drop/*.zip'.

Option A correctly identifies that the artifact name is missing from the path.

Exam trap

The trap is that candidates often assume 'drop' is the artifact name or a workspace root folder, but in this case it is a subfolder inside the artifact. They overlook that the artifact name itself must be included in the package path.

How to eliminate wrong answers

Option B is wrong because wildcard patterns like '*.zip' are fully supported in Azure Pipelines file matching; the issue is the path, not the pattern. Option C is wrong because an expired Azure service connection would cause authentication failures (e.g., 401 or 403 errors) when connecting to Azure resources, not a 'no package found' error during artifact download. Option D is wrong because Microsoft-hosted agents fully support the Download Pipeline Artifact task and can download artifacts from the current pipeline; the error is unrelated to agent type.

Practice this question →

339

MCQhard

You need to implement a strategy to manage secrets for your multi-stage YAML pipeline. The pipeline runs on Microsoft-hosted agents. Which approach should you use to securely pass secrets to pipeline tasks?

A.Define the secrets as environment variables in the pipeline YAML directly.

B.Use the Azure Key Vault task to download secrets and then pass them as parameters.

C.Use pipeline variables with 'secret: true' and reference them as $(variableName).

D.Store secrets in a file in the repository and read it during the build.

AnswerC

Secret variables are encrypted and masked in logs.

Why this answer

Azure Pipelines supports secret pipeline variables that are encrypted at rest and never exposed in logs or output. By defining a variable with `secret: true` in the YAML or via the UI, you can reference it securely as `$(variableName)` in tasks, ensuring the secret value is masked during execution.

Exam trap

The trap here is that candidates often confuse secret variables with environment variables or assume that Azure Key Vault integration requires a separate task to pass secrets as parameters, when in fact secrets are automatically mapped as pipeline variables and referenced with `$(variableName)`.

How to eliminate wrong answers

Option A is wrong because defining secrets as environment variables directly in the YAML file would expose them in plaintext in the repository and pipeline logs, violating security best practices. Option B is wrong because the Azure Key Vault task downloads secrets as pipeline variables (not parameters), and you should reference them directly via `$(variableName)` rather than passing them as parameters, which could inadvertently expose them. Option D is wrong because storing secrets in a file in the repository makes them part of the source code, defeating the purpose of secret management and risking exposure in version control history.

Practice this question →

340

Multi-Selecthard

Which THREE factors should you consider when designing a strategy for managing secrets in Azure Pipelines? (Choose three.)

Select 3 answers

A.Hardcode secrets in the pipeline YAML for simplicity.

B.Store secrets as plain text variables in YAML pipelines.

C.Use Azure Key Vault to store secrets.

D.Use a library variable group linked to Azure Key Vault.

E.Reference secrets as secret variables in pipeline tasks.

AnswersC, D, E

Use Azure Key Vault to store secrets because it is a centralized, cloud-based secret management service that provides strong encryption, granular access policies with Azure AD authentication, audit logging, and automated secret rotation, ensuring secrets are never exposed in code or logs.

Why this answer

Azure Key Vault is the recommended service for securely storing and managing secrets, keys, and certificates. By integrating Key Vault with Azure Pipelines, you can avoid exposing sensitive information in YAML files or pipeline logs. This approach ensures secrets are never hardcoded and are dynamically retrieved at runtime.

Exam trap

The trap here is that candidates may think storing secrets as plain text variables is acceptable if they are marked as 'secret' in the pipeline UI, but those values are still stored in the pipeline definition and can be exposed in logs or exports, whereas Key Vault provides centralized, audited secret management.

Practice this question →

341

MCQhard

The exhibit shows a parameters file for an ARM template deployment. During a release pipeline, the deployment fails with the error 'The provided value for the template parameter 'sku' is not valid'. The ARM template defines the 'sku' parameter as an allowed value set of ['F1', 'D1', 'B1', 'S1']. What could be the issue?

A.The parameter file contains an extra space or hidden character in the 'sku' value.

B.The parameter file is missing the '$schema' property.

C.The 'sku' parameter is defined in the 'variables' section instead of 'parameters'.

D.The ARM template expects a different API version for the resource.

AnswerA

Even though 'S1' appears correct, hidden characters can cause the value to not match the allowed values.

Why this answer

The error indicates that the value provided for the 'sku' parameter is not within the allowed set ['F1','D1','B1','S1']. Even if the exhibit appears to show 'S1', the actual value might contain invisible characters (e.g., leading/trailing spaces, newline, tab, or a BOM) or a typographical variation (like a different dash or letter), causing it to not exactly match 'S1'. Option B is incorrect because a missing '$schema' property would produce a different error about the parameter file schema, not about parameter value validation.

Option C is incorrect because defining 'sku' in the variables section would be a template error (or a different parameter-related error), and the error explicitly mentions the parameter 'sku', so it exists as a parameter. Option D is incorrect because an API version mismatch would cause a resource-manager-specific error about the API or resource, not the parameter value.

Practice this question →

342

MCQhard

You are designing a release pipeline for a critical production application. The pipeline must ensure that changes are deployed to a staging environment first, and if integration tests pass, they are automatically deployed to production. However, if the tests fail, the deployment to production must be blocked. What is the best approach?

A.Create a single stage in the pipeline with conditional tasks to deploy to staging and then to production based on test results.

B.Create a multi-stage YAML pipeline with a gate on the production stage that evaluates test results from the staging stage.

C.Create two separate pipelines: one for staging and one for production. Use a pipeline trigger to run the production pipeline after staging completes.

D.Use a classic release pipeline with pre-deployment approvals on the production stage.

AnswerB

This approach leverages a single YAML pipeline with multiple stages, where the staging stage deploys and runs tests, publishing results as artifacts. A pre-deployment gate on the production stage uses those published test results (e.g., pass rate or coverage) to automatically block or allow the promotion, ensuring the exact same build that passed staging is deployed. Because gates are evaluated automatically before the stage starts, no manual approval is required, yet the release is safely gated by objective quality signals.

Why this answer

A multi-stage YAML pipeline with a gate on the production stage allows you to evaluate the results of integration tests run in the staging stage before proceeding to production. The gate can be configured to check for test pass/fail status from the staging stage, blocking the production deployment if tests fail. This approach provides a clear, automated approval flow within a single pipeline definition, aligning with the requirement for conditional promotion based on test results.

Exam trap

The trap here is that candidates often confuse stage-level gates with task-level conditions, assuming a single stage with conditional tasks can achieve the same result, but gates operate at the stage boundary and can evaluate aggregated results from the entire previous stage, not just individual task outcomes.

How to eliminate wrong answers

Option A is wrong because using a single stage with conditional tasks does not provide a true stage-level gate; tasks within a stage run sequentially and cannot block the entire stage based on results from a previous stage, leading to potential deployment to production even if tests fail. Option C is wrong because using two separate pipelines with a pipeline trigger does not allow the production pipeline to evaluate test results from the staging pipeline; triggers only start the next pipeline upon completion, not based on test outcomes. Option D is wrong because pre-deployment approvals are manual and not automated based on test results; they require human intervention and do not evaluate integration test pass/fail status.

Practice this question →

343

MCQeasy

You are configuring a continuous integration trigger in Azure Pipelines for a repository in Azure Repos. You want to trigger a build for all branches except the 'release' branch. How should you configure the trigger?

A.Set trigger: branches: include: - main

B.Set trigger: branches: include: - '*' exclude: - '*'

C.Set trigger: branches: include: - '*' exclude: - release

D.Set trigger: branches: exclude: - release

AnswerD

Providing only an exclude list without an explicit include list means no branch is implicitly included, so the trigger will not be enabled for any branch; an include list must specify which branches are eligible for triggering.

Why this answer

In Azure Pipelines YAML triggers, the 'include' list is optional. If no include is specified, all branches are considered for triggering, and the 'exclude' list removes the specified branches. Therefore, 'trigger: branches: exclude: - release' correctly triggers on all branches except 'release'.

The marked answer C also works, but D is the simpler and standard configuration.

Exam trap

The trap is that candidates may think they need to explicitly include '*' to match all branches, but Azure Pipelines triggers on all branches by default unless an include list restricts it. A single exclude clause is sufficient.

How to eliminate wrong answers

Option A is wrong because setting 'include: - main' would only trigger builds for the 'main' branch, not all branches except 'release'. Option B is wrong because 'include: - *' and 'exclude: - *' would exclude all branches, resulting in no triggers at all. Option D is wrong because setting only 'exclude: - release' without an 'include' filter defaults to no branches being included, so no triggers would fire.

Practice this question →

344

MCQhard

You are a DevOps engineer for a large e-commerce company. The development team uses GitHub for source control and GitHub Actions for CI/CD. The application is a microservices architecture with 15 services, each in its own repository. You need to implement a continuous delivery pipeline that builds and deploys each service to a Kubernetes cluster in Azure (AKS). The pipeline must meet the following requirements: - Each service must have its own pipeline that triggers on pushes to the main branch. - Deployment to AKS must use Helm charts. - The pipeline must automatically increment the Helm chart version and update the deployment manifest in the repository. - Security scanning must be performed on container images before deployment. - The pipeline must support manual approval for production deployment. - All secrets (e.g., AKS credentials, registry credentials) must be stored securely and not exposed in logs. You need to design the workflow. What is the best course of action?

A.Use Azure Pipelines instead of GitHub Actions because it has better integration with AKS. Store secrets in Azure Key Vault and use variable groups.

B.Create a reusable workflow with OIDC authentication to Azure. Use Helm to deploy, increment chart version, and commit back. Use GitHub environments for approval gates. Integrate container scanning with Docker Scout or Trivy.

C.Create a workflow per service with direct deployment. Use kubectl commands to deploy. Store all secrets in a single GitHub secret. Skip security scanning to save time.

D.Create a single reusable workflow that each service calls. Use Azure CLI to deploy Helm charts. Store AKS credentials as GitHub secrets. Use a manual approval step via environment protection rules.

AnswerB

Using OIDC eliminates long-lived Azure credentials by exchanging short-lived tokens from GitHub Actions, satisfying secure auth without storing secrets. Helm manages releases with chart version increments and rollback capabilities, and committing the bumped chart back maintains GitOps traceability. GitHub environments provide protected branches and approval gates per stage, while Trivy or Docker Scout scans container images for vulnerabilities before deployment.

Why this answer

Using GitHub Actions with OIDC to authenticate to Azure avoids storing long-lived secrets. Helm chart version bumping can be done with a script. The workflow uses environments for approval gates.

Container scanning using tools like Trivy can be added as a step.

Practice this question →

345

MCQhard

Refer to the exhibit. You have a YAML pipeline with the above steps. The pipeline publishes a web app and deploys to Azure App Service. The deployment fails with error: 'Could not find the package in the specified path.' What is the most likely cause?

A.The package path is wrong; the zip file is in $(Build.ArtifactStagingDirectory).

B.The AzureWebApp task input 'appType' is incorrect.

C.The dotnet publish command did not generate a zip file.

D.The service connection 'MyServiceConnection' is not authorized.

AnswerA

The AzureWebApp task's `package` input is configured with an incorrect file path. The `dotnet publish` command, when run in a YAML pipeline, defaults to publishing the zip package into `$(Build.ArtifactStagingDirectory)`, not into a subfolder like `$(System.DefaultWorkingDirectory)/published` unless explicitly redirected. Because the package path does not point to that staging directory, the task fails with a 'file not found' or 'no package found' error before deployment can begin. Setting `package: '$(Build.ArtifactStagingDirectory)/**/*.zip'` resolves the issue by correctly referencing the output location.

Why this answer

The error 'Could not find the package in the specified path' indicates that the AzureWebApp task is looking for a deployment package (typically a .zip file) at a path that does not exist. In the exhibit, the `dotnet publish` command outputs to `$(Build.ArtifactStagingDirectory)`, but the subsequent AzureWebApp task likely references a different path (e.g., `$(System.DefaultWorkingDirectory)` or a hardcoded path). The correct path should be `$(Build.ArtifactStagingDirectory)/**/*.zip` to match the published artifact.

Option A correctly identifies this path mismatch as the root cause.

Exam trap

The trap here is that candidates often assume the error is due to a missing zip file (Option C) or a misconfigured service connection (Option D), but the actual cause is a path variable mismatch between the publish output and the deployment task input.

How to eliminate wrong answers

Option B is wrong because the `appType` input (e.g., 'webApp' or 'webAppLinux') affects runtime stack selection but does not cause a 'package not found' error; it would instead cause a deployment failure related to incorrect app settings or runtime. Option C is wrong because the `dotnet publish` command with `--output $(Build.ArtifactStagingDirectory)` does generate a zip file (if configured) or at least the published output; the error is about the path, not the absence of a zip. Option D is wrong because an unauthorized service connection would result in an authentication/authorization error (e.g., 401 or 403), not a 'package not found' error, which is a file system issue.

Practice this question →

346

MCQhard

Refer to the exhibit. A build pipeline produces the above logs. Which change would resolve the build failure?

A.Change the build configuration from Release to Debug.

B.Add a definition for 'MyMethod' in the 'MyClass' class.

C.Remove the '--no-build' flag from the test step.

D.Add the '--no-restore' flag to the build step.

AnswerB

The build error is a CS1061 compilation error: the C# compiler cannot find a member named 'MyMethod' on the type 'MyClass'. This means the calling code references a method that is not declared anywhere in the class definition. Adding a method with the exact name 'MyMethod' and a compatible signature (parameter list and return type) to the 'MyClass' class is the only way to satisfy the compiler. Without this addition, any downstream steps (like tests) will have no valid assembly to run.

Why this answer

The build failure is caused by a missing method definition. The logs indicate that the test step is attempting to invoke 'MyMethod' on an instance of 'MyClass', but the compiler cannot find it. Adding the missing method to the class resolves the compilation error, which is the root cause of the pipeline failure.

Exam trap

The trap here is that candidates may focus on build flags like '--no-build' or configuration settings, overlooking the actual compilation error message that clearly indicates a missing method definition.

How to eliminate wrong answers

Option A is wrong because switching from Release to Debug configuration does not fix a missing method; it only changes optimization and debug symbols. Option C is wrong because removing the '--no-build' flag would force a rebuild before tests, but the failure is a compilation error in the test project itself, not a stale build artifact. Option D is wrong because adding '--no-restore' skips NuGet package restore, which would likely cause additional dependency errors and does not address the missing method definition.

Practice this question →

347

MCQmedium

Refer to the exhibit. You have a YAML pipeline that references a repository resource with a tag. When will this pipeline trigger?

A.When a new tag v1.0 is pushed to the referenced repository.

B.When changes are pushed to any branch of the referenced repository.

C.When changes are pushed to the main branch of the current repository.

D.The pipeline will never trigger because no trigger is defined.

AnswerC

The YAML pipeline defines a branch trigger with `branches.include: main` for the current repository, so any push to the main branch of that repository will automatically start the pipeline. This is the standard CI trigger behavior in Azure Pipelines.

Why this answer

By default, a YAML pipeline triggers on changes to the main branch of the repository where the pipeline definition resides, even when a repository resource with a tag is referenced. The tag in the repository resource only controls which version of the resource is used at runtime, not the trigger behavior. Without an explicit trigger section, the pipeline uses the default CI trigger on the main branch of the self-repo.

Exam trap

The trap here is that candidates assume a referenced repository resource with a tag will automatically trigger the pipeline on tag pushes, but Azure Pipelines does not trigger on resource changes unless a pipeline resource trigger is explicitly configured.

How to eliminate wrong answers

Option A is wrong because a tag push to the referenced repository does not trigger the pipeline unless a trigger is explicitly defined for tags (e.g., using `trigger: tags: include: ['v1.0']`). Option B is wrong because changes to any branch of the referenced repository do not trigger the pipeline; only changes to the main branch of the current repository trigger it by default. Option D is wrong because a default CI trigger exists for the main branch of the current repository when no trigger is defined, so the pipeline will trigger on pushes to that branch.

Practice this question →

348

MCQeasy

Your Azure DevOps pipeline uses a YAML template that defines variables. You want to override a variable value when running the pipeline manually. What is the best approach?

A.Create a variable group and link it to the pipeline.

B.Edit the template YAML file to hardcode the desired value.

C.Use the 'Variables' tab in the pipeline run UI to set a new value for the variable.

D.Define a parameter in the template and pass the value via the 'Override' parameter in the pipeline.

AnswerC

The pipeline run UI's Variables tab provides a runtime override mechanism specifically designed for this scenario: when you start a manual run, you can expand the 'Variables' section and enter a new value for a YAML-defined variable, and that value is used for that run only without modifying the repository. This works because YAML variables are evaluated at runtime (after the pipeline is triggered), so the override seamlessly replaces the default value defined in the template or pipeline. Crucially, this approach requires zero changes to version-controlled files and leaves the pipeline definition untouched, making it the intended, non-invasive method for ad-hoc manual overrides.

Why this answer

Azure Pipelines allows you to override the value of a YAML-defined variable directly in the pipeline run UI via the 'Variables' tab when manually triggering a run. This approach is the simplest and most flexible way to change a variable's value without modifying the YAML template or pipeline definition, and it supports runtime parameterization for manual runs.

Exam trap

The trap here is that candidates often confuse variables with parameters, assuming that parameters are the only way to pass values at runtime, but Azure Pipelines explicitly supports overriding YAML-defined variables via the UI without needing to convert them to parameters.

How to eliminate wrong answers

Option A is wrong because variable groups are used to manage sets of variables across pipelines, but they cannot override a variable already defined in a YAML template at runtime; they are linked at queue time and have lower precedence than variables set in the UI. Option B is wrong because hardcoding a value in the template YAML file defeats the purpose of dynamic override and requires a commit to the repository, which is not a runtime override mechanism. Option D is wrong because while parameters can be used to pass values into templates, there is no 'Override' parameter in Azure Pipelines; the correct way to pass a parameter value is via the pipeline run UI's 'Parameters' section (if defined as a parameter), but the question specifically asks about overriding a variable, not a parameter.

Practice this question →

349

Multi-Selecthard

Which THREE of the following are best practices for managing secrets in Azure Pipelines? (Select THREE.)

Select 3 answers

A.Hardcode secrets directly in the YAML file and use variable substitution at runtime.

B.Use Azure Key Vault to store secrets and link them to variable groups.

C.Enable 'Allow scripts to access the OAuth token' for all build pipelines.

D.Restrict access to variable groups by using pipeline permissions.

E.Map secret variables as environment variables with a mapping to prevent exposure in logs.

AnswersB, D, E

Key Vault provides secure storage and access control.

Why this answer

Azure Key Vault is the recommended service for securely storing and managing secrets, keys, and certificates. By linking a Key Vault to a variable group in Azure Pipelines, you can reference secrets without exposing them in YAML or logs, and the pipeline retrieves them at runtime using a managed identity or service principal. This approach ensures secrets are never hardcoded and access can be audited and controlled centrally.

Exam trap

The trap here is that candidates may think hardcoding secrets with variable substitution (Option A) is acceptable because it avoids storing secrets in plain text in the YAML, but they overlook that the secret value is still exposed in the pipeline logs and source control history, which is a critical security flaw.

Practice this question →

350

MCQeasy

You have a YAML pipeline that builds a .NET application. You need to ensure that the pipeline uses the .NET SDK version 6.0.x. Which task should you add to the pipeline?

A.UseDotNet@2

B.NuGetToolInstaller@1

C.DotNetCoreCLI@2

D.PowerShell@2

AnswerA

UseDotNet@2 is the correct task because it explicitly installs a specified .NET Core/.NET SDK version on the build agent, making that SDK available for subsequent pipeline steps. It can also read a global.json to select the exact SDK version, ensuring the pipeline uses the intended toolset.

Why this answer

The UseDotNet@2 task is the correct choice because it explicitly installs a specific .NET SDK version (6.0.x) on the build agent, ensuring the pipeline uses the required SDK for building the .NET application. This task downloads and caches the SDK, making it available for subsequent tasks like DotNetCoreCLI@2.

Exam trap

The trap here is that candidates often confuse DotNetCoreCLI@2 (which runs .NET commands) with UseDotNet@2 (which installs the SDK), assuming the build task itself can set the SDK version, but DotNetCoreCLI@2 only uses whatever SDK is already available.

Why the other options are wrong

This installs NuGet, not the .NET SDK.

This runs .NET commands but does not install a specific SDK version.

PowerShell can install SDK but it's not the built-in task for this purpose.

Practice this question →

351

MCQmedium

Your organization uses Azure DevOps Server (on-premises) and is planning to migrate to Azure DevOps Services. You have hundreds of build and release pipelines. The migration must be done with minimal downtime and with validation that each pipeline works after migration. You have a test collection of 20 critical pipelines that must be validated first. What is the best approach?

A.Export all pipelines as JSON from the server and import them into Azure DevOps Services. Skip validation to save time.

B.Manually recreate the 20 critical pipelines in Azure DevOps Services and test them. Then recreate the rest manually.

C.Use the Azure DevOps Migration Tools to replicate the test pipelines to a new Azure DevOps Services organization. Validate, fix issues, then migrate the remaining pipelines in batches.

D.Perform an in-place upgrade of Azure DevOps Server to the latest version, then migrate to Azure DevOps Services using the Data Migration Tool.

AnswerC

The Azure DevOps Migration Tools (the community-supported VSTS/Azure DevOps Migration Tools) are specifically designed to programmatically migrate build and release pipelines, service endpoints, and certain metadata between Azure DevOps organizations, allowing you to run trials against a test organization first. By replicating test pipelines first, you can validate variable resolution, service connection authentication, agent pool references, and task extension compatibility; fixing issues early prevents them from appearing later. Afterward, migrating the remaining pipelines in batches gives you controlled rollout, checkpointing, and the ability to fix issues before going live, which matches the requirement for minimal downtime and reduced risk.

Why this answer

Using the Azure DevOps Migration Tools to perform a trial migration to a test organization allows you to validate and fix issues before migrating the full collection. Direct upgrade is not supported. Manual recreation is error-prone and not minimal downtime.

Skipping validation risks breaking pipelines.

Practice this question →

352

MCQmedium

Refer to the exhibit. You have this Azure Pipelines YAML definition. The pipeline runs manually, but you want it to automatically trigger on every push to the main branch and also build pull requests targeting main. Which change should you make?

A.Remove the 'triggers' and 'pr' sections entirely.

B.Replace 'triggers: ["none"]' with 'triggers: ["main"]' and 'pr: ["none"]' with 'pr: ["main"]'.

C.Set 'triggers' to '["main"]' and 'pr' to '["none"]'.

D.Set 'triggers' to 'none' and 'pr' to 'none'.

AnswerB

This enables CI on push to main and PR triggers for PRs targeting main.

Why this answer

In Azure Pipelines YAML, setting `triggers: ['none']` explicitly disables CI triggers, and `pr: ['none']` disables PR triggers. To enable automatic builds on every push to main and on pull requests targeting main, you must replace these with `triggers: ['main']` and `pr: ['main']`, which configures both CI and PR triggers for the main branch.

Exam trap

The trap here is that candidates may think removing the trigger sections (Option A) will enable automatic triggers, but in Azure Pipelines YAML, removing them actually enables triggers on all branches, not just main, which is too broad and does not meet the specific requirement.

How to eliminate wrong answers

Option A is wrong because removing the `triggers` and `pr` sections entirely would cause the pipeline to inherit default behavior (CI triggers on all branches and PR triggers on all branches), which does not match the requirement to trigger only on main and PRs targeting main. Option C is wrong because setting `pr: ['none']` disables PR triggers, so pull requests targeting main would not trigger the pipeline, failing the requirement. Option D is wrong because setting both `triggers` and `pr` to `none` (as strings, not arrays) is invalid syntax and would disable all triggers, preventing any automatic builds.

Practice this question →

353

MCQeasy

You run the above Azure CLI command to deploy a Bicep template. The deployment fails with 'The resource 'Microsoft.Storage/storageAccounts/mystgaccount' already exists'. What is the most likely cause?

A.The storage account 'mystgaccount' already exists in the resource group.

B.The command should use 'az deployment group validate' instead.

C.The Bicep file uses 'complete' mode.

D.The resource group 'MyRG' does not exist.

AnswerA

The deployment fails because Azure Resource Manager's default 'create' mode (used by 'az deployment group create' when no mode is specified) issues a conflict error if a resource with the same name and type already exists in the target resource group, even if the template's properties match the existing resource. The storage account 'mystgaccount' already occupies that name in 'MyRG', so the deployment cannot proceed.

Why this answer

The error message 'The resource 'Microsoft.Storage/storageAccounts/mystgaccount' already exists' indicates that the storage account 'mystgaccount' already exists in the target resource group, which prevents the deployment from creating it again. This directly supports option A as the correct answer. Option B is incorrect because 'az deployment group validate' only validates the template and does not perform a deployment; the error occurs during the actual deployment, not validation.

Option C is incorrect because Bicep defaults to incremental mode, not complete mode, and even if complete mode were used, the error would be about a resource existing in the template but not in the resource group, which is not the case here. Option D is incorrect because if the resource group did not exist, the error would be something like 'ResourceGroupNotFound', not an already-exists error.

Practice this question →

354

MCQmedium

You are designing a release pipeline for a microservices application. Each service must be deployed independently with zero downtime. Which deployment strategy should you recommend?

A.Rolling update

B.Feature flags

C.Canary release

D.Blue-green deployment

AnswerD

Blue-green maintains two full environments for instant switch.

Why this answer

Blue-green deployment is the correct strategy because it maintains two identical environments (blue and green) and allows instant traffic switch to the new version while keeping the old version running, enabling zero-downtime deployment and immediate rollback if issues arise. This aligns with the requirement of independent deployment for each microservice. Option A (rolling update) is incorrect because it replaces instances gradually, which can cause version skew and does not provide instant rollback.

Option B (feature flags) is a technique for feature toggling, not a deployment strategy; it does not handle traffic shifting or environment isolation. Option C (canary release) is incorrect because it routes a small subset of users to the new version, which does not guarantee immediate full zero-downtime deployment and requires gradual rollout and monitoring.

Exam trap

Candidates often confuse canary releases and blue-green deployments. While both can achieve zero downtime, blue-green provides an instant full switch and simpler rollback, whereas canary is gradual and requires traffic routing logic.

Practice this question →

355

MCQhard

You are designing a build pipeline that must run on Microsoft-hosted agents. The pipeline has a dependency on a native library that is not pre-installed. You want to minimize pipeline duration. Which approach should you use?

A.Use a container job with a custom Docker image that includes the library

B.Use a self-hosted agent with the library pre-installed

C.Add a script step to install the library using a package manager

D.Download the library from Azure Blob Storage in each build

AnswerA

Using a container job with a custom Docker image that includes the library allows the pipeline to run on Microsoft-hosted agents while avoiding the time needed to install the library in each run. This minimizes pipeline duration and meets the requirement.

Why this answer

Using a container job with a custom Docker image that includes the native library allows the pipeline to run on Microsoft-hosted agents while eliminating installation overhead, thus minimizing pipeline duration. This approach meets the requirement of using Microsoft-hosted agents and avoids the time cost of installing the library in each run.

Exam trap

Candidates may think self-hosted agents are required for pre-installed dependencies, but container jobs on Microsoft-hosted agents achieve the same benefit with less management overhead and still meet the requirement.

How to eliminate wrong answers

Option A is wrong because container jobs with custom Docker images still require pulling the image on each run, which adds significant time and does not leverage the pre-installed nature of a self-hosted agent. Option C is wrong because adding a script step to install the library using a package manager incurs runtime installation overhead, increasing pipeline duration. Option D is wrong because downloading the library from Azure Blob Storage in each build adds network transfer time and does not avoid the installation step, thus not minimizing duration.

Practice this question →

356

MCQeasy

You have a YAML pipeline that builds a Docker image and pushes it to Azure Container Registry (ACR). You need to dynamically set the image tag based on the build number. Which predefined variable should you use?

A.$(System.JobId)

B.$(System.TeamProject)

C.$(Build.BuildNumber)

D.$(Build.BuildId)

AnswerC

Build.BuildNumber is a human-readable, configurable build name that often includes non-alphanumeric characters like colons, dashes, or custom text. Docker tags must be lowercase alphanumeric and may contain only periods, underscores, and hyphens, so directly using BuildNumber risks invalid tags that fail the build unless the value is sanitized.

Why this answer

The `$(Build.BuildNumber)` variable represents the build number, which is the name of the completed build. It's often customized to include versioning information, and it's the appropriate variable to use when tagging Docker images based on the build number. `$(Build.BuildId)` is a unique numeric ID for the build record, but it is not the build number.

Exam trap

Candidates may confuse `Build.BuildNumber` (the human-readable build name) with `Build.BuildId` (the internal numeric ID). The stem explicitly says 'based on the build number', so `Build.BuildNumber` is the correct choice.

How to eliminate wrong answers

Option A is wrong because `$(System.JobId)` is a unique identifier for a specific job run within a pipeline, not the overall build number, and is not intended for image tagging. Option B is wrong because `$(System.TeamProject)` contains the name of the Azure DevOps project, which is static and does not provide a unique or incrementing value for tagging. Option C is wrong because `$(Build.BuildNumber)` is a user-defined or default formatted string (e.g., '20250401.1') that can contain non-numeric characters and is not guaranteed to be strictly incrementing or unique across parallel builds, making it less reliable for Docker tags than the integer `$(Build.BuildId)`.

Practice this question →

357

MCQmedium

Your team uses Azure Pipelines for CI/CD. You need to enforce that all builds sign the assemblies with a code signing certificate stored in Azure Key Vault. What is the recommended approach?

A.Store the certificate as a secure file in the pipeline library and use the 'Download Secure File' task.

B.Embed the certificate in the repository and use a script to sign.

C.Use the 'Azure Key Vault' task to download secrets and then a 'PowerShell' task to sign.

D.Use the 'Azure CLI' task to retrieve the certificate and then sign.

AnswerC

The Key Vault task downloads secrets (including certificates) and makes them available as pipeline variables.

Why this answer

Use the Azure Key Vault task to download the certificate as a secure secret, then use a PowerShell task to sign the assemblies with that certificate.

Practice this question →

358

MCQmedium

You are designing a pipeline to build a .NET Core application. The build must run unit tests and publish code coverage results. Which task should you use to publish the code coverage results to Azure DevOps?

A.Use the 'PublishCodeCoverageResults@1' task.

B.Use the 'PublishTestResults@2' task.

C.Use the 'DotNetCoreCLI@2' task with the 'test' command.

D.Use the 'VSTest@2' task with the 'codeCoverageEnabled' option.

AnswerA

The PublishCodeCoverageResults@1 task is the dedicated Azure DevOps task for publishing code coverage data generated by test runs to the pipeline UI and build summary. It accepts coverage files in formats like Cobertura or JaCoCo, making it the correct choice for publishing .NET Core coverage reports.

Why this answer

The 'PublishCodeCoverageResults@1' task is the correct choice because it is specifically designed to publish code coverage results (e.g., Cobertura or JaCoCo XML reports) to Azure DevOps, making them visible in the build summary and pipeline artifacts. This task consumes the coverage data file generated by a previous test run (e.g., via 'DotNetCoreCLI@2' with '--collect "Code Coverage"') and uploads it to the Azure DevOps service for reporting.

Exam trap

The trap here is that candidates confuse the task that runs tests with coverage collection (e.g., VSTest@2 or DotNetCoreCLI@2) for the task that publishes the coverage results, forgetting that publishing is a separate, explicit step required to surface the data in Azure DevOps.

How to eliminate wrong answers

Option B is wrong because 'PublishTestResults@2' publishes test pass/fail results (e.g., TRX, JUnit XML) to the Tests tab, not code coverage data. Option C is wrong because 'DotNetCoreCLI@2' with the 'test' command runs tests and can collect coverage data (e.g., via Coverlet), but it does not publish the coverage results to Azure DevOps; a separate publish task is required. Option D is wrong because 'VSTest@2' with 'codeCoverageEnabled' runs tests with coverage instrumentation (using the Visual Studio coverage engine), but it does not publish the results; the coverage data must still be published using a dedicated task like 'PublishCodeCoverageResults@1'.

Practice this question →

359

MCQmedium

Your company uses Azure DevOps for CI/CD. You have a build pipeline that compiles a C++ application and runs unit tests. The pipeline uses a Microsoft-hosted agent. The build takes approximately 45 minutes to complete. You want to reduce the build time. You notice that the pipeline downloads dependencies from a NuGet feed every time. You have a private NuGet feed in Azure Artifacts. The pipeline restores packages using 'nuget restore'. You want to cache the NuGet packages on the agent to avoid downloading them on every build. What should you do?

A.Use a self-hosted agent with persistent storage.

B.Use a hosted Azure Artifacts feed with upstream sources.

C.Increase the agent's compute resources by selecting a higher SKU.

D.Add a CacheBeta task before the restore step to cache the packages folder.

AnswerD

Adding a CacheBeta task (or the newer Cache task) with a key based on the packages file (e.g., packages.lock.json or .csproj) and a path like $(UserProfile)/.nuget/packages stores the restored packages in Azure DevOps' external cache. On subsequent builds, the restore step pulls packages from that cache instead of hitting the network, which directly eliminates repeated downloads and is the correct quick fix.

Why this answer

The CacheBeta task enables caching of the NuGet packages folder between pipeline runs, avoiding repeated downloads from the feed. This directly reduces build time. Option A is wrong because while self-hosted agents can have persistent storage, the question specifies using a Microsoft-hosted agent, and the CacheBeta task works even with Microsoft-hosted agents.

Option B is wrong because using upstream sources in Azure Artifacts does not cache packages locally on the agent; it still requires downloading them each time. Option C is wrong because increasing compute resources does not affect the time spent downloading dependencies; caching addresses the root cause.

Practice this question →

360

MCQhard

Your organization uses GitHub Actions for CI/CD. You have a workflow that builds a .NET application and runs tests. The workflow uses a self-hosted runner on an on-premises Windows server. Recently, builds started failing with 'Access to the path is denied' errors when the runner tries to restore NuGet packages. The runner has been working for months. What is the most likely cause?

A.The runner's authentication token to GitHub has expired.

B.The runner service account's permissions have changed, and it no longer has write access to the working directory or cache.

C.The NuGet cache directory on the runner has been deleted.

D.The runner has been updated to a newer version that no longer supports NuGet restore.

AnswerB

If the Windows service or daemon account that runs the runner no longer has write permissions on the workspace, _work, or the NuGet cache directory, the restore step fails with an access denied (UnauthorizedAccessException) error. This exactly matches the symptom, as permission changes on the runner service account directly affect local file access.

Why this answer

The 'Access to the path is denied' error during NuGet restore on a self-hosted runner typically indicates a file system permission issue. Since the runner has been working for months, the most likely cause is that the service account under which the runner runs no longer has write access to the working directory or the NuGet cache folder, often due to a group policy change, account modification, or folder permission drift.

Exam trap

The trap here is that candidates confuse authentication failures (token expiry) with local file system permission errors, assuming any 'access denied' relates to GitHub connectivity rather than the runner's service account permissions on the on-premises machine.

How to eliminate wrong answers

Option A is wrong because an expired runner authentication token would cause authentication failures when connecting to GitHub, not file access errors during NuGet restore. Option C is wrong because deleting the NuGet cache directory would cause cache misses and re-downloads, not 'Access to the path is denied' errors; the runner would still have permission to create a new cache folder. Option D is wrong because newer runner versions maintain full backward compatibility with NuGet restore; the runner does not 'support' or 'not support' NuGet restore as a feature.

Practice this question →

361

MCQeasy

Your team uses GitHub for source control and wants to set up continuous integration using GitHub Actions. Which file should you create in the repository to define the workflow?

A.Jenkinsfile

B..github/workflows/ci.yml

C.Dockerfile

D.azure-pipelines.yml

AnswerB

The file .github/workflows/ci.yml is the standard and expected location for a GitHub Actions workflow. Any YAML file in the .github/workflows directory defines an automated workflow that GitHub Actions will parse and run based on configured event triggers, such as push or pull_request, making it the correct choice for setting up CI with GitHub.

Why this answer

GitHub Actions workflows are defined in YAML files stored in the .github/workflows directory. Option A is wrong because a Jenkinsfile is used with Jenkins, not GitHub Actions. Option C is wrong because a Dockerfile is used to build Docker images, not to define CI workflows.

Option D is wrong because azure-pipelines.yml is for Azure Pipelines, not GitHub Actions.

Practice this question →

362

MCQeasy

Your organization uses Azure Pipelines and wants to implement a continuous feedback loop by collecting user analytics from the production environment and automatically creating work items in Azure Boards for critical issues. You need to design a solution that integrates monitoring data with the pipeline. What should you do?

A.Use Power BI to visualize Application Insights data and set up data-driven alerts that send emails to the team.

B.Set up Azure Monitor alerts based on Application Insights data, and configure the alerts to invoke a webhook that calls the Azure Boards REST API to create a work item.

C.Configure the release pipeline to output logs to Azure Monitor and use Log Analytics to create work items.

D.Use Azure Application Insights to collect user analytics, and manually review dashboards to create work items.

AnswerB

Azure Monitor alerts can be configured from Application Insights metrics or logs, and by setting an action group that invokes a webhook, you can call the Azure Boards REST API to automatically create a work item. This closes the loop by transforming telemetry-driven alerts into actionable backlog items without manual intervention.

Why this answer

Azure Monitor alerts based on Application Insights data can trigger a webhook that calls the Azure Boards REST API to automatically create a work item. This integrates monitoring data with the pipeline to establish a continuous feedback loop. Option A is incorrect because Power BI visualization and email alerts do not automate work item creation.

Option C is incorrect because release pipeline logs are not for collecting user analytics; Application Insights is needed. Option D is incorrect because manually reviewing dashboards is not automated.

Practice this question →

363

MCQhard

Your organization is adopting GitHub Actions for CI/CD. You need to enforce that all workflows must pass required status checks before merging pull requests to the main branch. The repository is in an organization. What should you configure?

A.Add an environment protection rule requiring approval from specific reviewers.

B.Set the workflow to have 'contents: write' permission.

C.Define a CODEOWNERS file that requires team review for main branch changes.

D.Create a branch protection rule for the main branch with required status checks.

AnswerD

Creating a branch protection rule for the main branch with required status checks is the correct solution because it prevents merging until the specified GitHub Actions workflow checks succeed. This enforces CI/CD validation as a hard gate for all pull requests targeting main, ensuring only verified changes are merged.

Why this answer

Branch protection rules in GitHub allow you to enforce required status checks on pull requests before merging. By configuring a branch protection rule for the main branch, you can specify that certain GitHub Actions workflow runs must pass (e.g., CI checks) before a pull request can be merged. This directly enforces the policy that all workflows must pass required status checks.

Exam trap

The trap here is confusing branch protection rules (which enforce merge requirements) with environment protection rules (which control deployment approvals) or CODEOWNERS (which mandate file-level reviews), leading candidates to pick options that address review or permissions rather than status checks.

How to eliminate wrong answers

Option A is wrong because environment protection rules control deployments to specific environments (e.g., production), not pull request merge requirements on a branch. Option B is wrong because setting 'contents: write' permission in a workflow grants write access to repository contents, which is unrelated to enforcing status checks on pull requests. Option C is wrong because a CODEOWNERS file defines who must review changes to specific files, but it does not enforce that workflows must pass before merging; it only requires approval from designated teams or individuals.

Practice this question →

364

MCQmedium

Your organization uses GitHub for source control and Azure Pipelines for CI/CD. You need to implement a policy that requires all pull requests to be built and pass tests before merging. What should you do?

A.Add a branch protection rule in the GitHub repository requiring status checks.

B.Set the pipeline trigger to run on pull request.

C.Configure pipeline permissions to require approval.

D.Add a pre-deployment check on the environment.

AnswerA

Branch protection rules in GitHub allow requiring status checks to pass before a pull request can be merged. When you require status checks, the pipeline's validation becomes a mandatory gate: any PR that doesn't have a successful status check from the configured pipeline is blocked from merging, directly enforcing the quality gate at the repository level. This is the only option that enforces the requirement at the merge point.

Why this answer

GitHub branch protection rules allow you to require status checks to pass before merging a pull request. By configuring a rule that requires the Azure Pipelines build and test status check to succeed, you enforce that all pull requests are validated before they can be merged into the protected branch.

Exam trap

The trap here is confusing pipeline triggers (which only initiate runs) with merge gating (which enforces that those runs must succeed before merging), leading candidates to select option B instead of A.

How to eliminate wrong answers

Option B is wrong because setting the pipeline trigger to run on pull request only ensures the pipeline runs when a PR is created, but does not enforce that the pipeline must succeed before the PR can be merged. Option C is wrong because pipeline permissions requiring approval control who can run or modify the pipeline, not whether a PR can be merged based on test results. Option D is wrong because a pre-deployment check on an environment gates deployment to that environment, not the merging of a pull request in GitHub.

Practice this question →

365

Multi-Selecthard

Which TWO actions should you take to implement a secure CI/CD pipeline that uses Azure Pipelines and prevents unauthorized access to production? (Choose two.)

Select 2 answers

A.Store production secrets as pipeline variables marked as 'Secret'.

B.Configure deployment approvals and checks on the production stage.

C.Enable PR triggers for the production stage to validate changes.

D.Use a service connection with a managed identity for Azure resources.

E.Use self-hosted agents running on-premises for all pipelines.

AnswersB, D

Configuring deployment approvals and checks on the production stage is correct because it enforces manual authorization and integrates with Azure Policy or other gates, ensuring that only authorized personnel can approve and promote builds to production, reducing risk of unauthorized deployments.

Why this answer

Deployment approvals and checks in Azure Pipelines require manual sign-off or automated policy validation before a release proceeds to production, preventing unauthorized or unverified changes. Option D is correct because using a service connection with a managed identity eliminates the need to store static credentials, reducing the risk of credential exposure and unauthorized access to Azure resources during deployment.

Exam trap

The trap here is that candidates often confuse secret management (Option A) with access control, or think that PR triggers (Option C) or self-hosted agents (Option E) directly prevent unauthorized production access, when in fact they address different security concerns (secret protection, code validation, and agent isolation) rather than deployment authorization.

Practice this question →

366

MCQhard

You have a YAML pipeline that uses a self-hosted agent. The agent runs on a VM in Azure. The pipeline fails intermittently with the error: '##[error]The job running on agent MyAgent has been cancelled because the agent was idle for more than the maximum idle time.' You need to resolve this issue. What should you do?

A.Configure the agent's idle timeout setting to a higher value or disable it.

B.Add more agents to the agent pool.

C.Increase the job's timeout in minutes.

D.Reduce the number of parallel jobs to avoid overloading the agent.

AnswerA

The idle timeout cancels the job if the agent is idle too long; increasing it prevents premature cancellation.

Why this answer

The error indicates that the self-hosted agent was idle for longer than the configured maximum idle time, causing Azure Pipelines to cancel the job. Option A is correct because increasing or disabling the idle timeout setting on the agent (via the agent's configuration file or environment variable) directly addresses this issue by allowing longer periods of inactivity before cancellation.

Exam trap

The trap here is confusing the job-level timeout (pipeline job timeout) with the agent-level idle timeout, leading candidates to incorrectly choose option C instead of recognizing that the error specifically references agent idle time, not job execution duration.

How to eliminate wrong answers

Option B is wrong because adding more agents to the pool does not change the idle timeout setting on any individual agent; it only increases parallelism, which does not prevent a specific agent from being cancelled due to idle time. Option C is wrong because increasing the job's timeout in minutes (pipeline job timeout) controls how long the entire job can run before being cancelled, not the agent's idle timeout, which is a separate agent-level setting. Option D is wrong because reducing parallel jobs may reduce load but does not affect the agent's idle timeout; the agent can still be idle for too long and be cancelled regardless of the number of concurrent jobs.

Practice this question →

367

MCQhard

Refer to the exhibit. A developer pushes a commit to the main branch. Which stages will run?

A.Only the Test stage.

B.Only the Build stage.

C.Neither stage.

D.Both Build and Test stages.

AnswerB

The Build stage runs because main is included in the pipeline trigger, and the Test stage is skipped because its condition (e.g., checking for a non-main branch) is false for refs/heads/main. Therefore, only the Build stage executes.

Why this answer

The exhibit shows that the Build stage has a trigger condition that matches the 'main' branch, and the Test stage does not have a trigger condition that is satisfied by the push (e.g., it is set to a different branch condition or to manual). Therefore, when a commit is pushed to main, only the Build stage is triggered automatically; the Test stage does not run.

Exam trap

Candidates often assume all stages in a pipeline run automatically after a commit, but stages can have independent trigger conditions or manual triggers that control whether they run in a given scenario.

How to eliminate wrong answers

Option A is wrong because the Test stage has no trigger condition defined, so it will not run when a commit is pushed to main; only the Build stage runs. Option C is wrong because the Build stage has a trigger condition set to 'main', so it will run when a commit is pushed to main. Option D is wrong because the Test stage does not have a trigger condition, so it will not run alongside the Build stage.

Practice this question →

368

MCQeasy

Your team uses Azure Pipelines for CI/CD. You need to ensure that only approved branches can trigger production deployments. Which feature should you use?

A.YAML template expressions

B.Branch control for environments

C.Deployment gates

D.Pipeline decorators

AnswerB

Branch control for environments is the correct answer because Azure Pipelines environment checks allow you to restrict which branches or branch types can deploy to that environment. This is done by configuring an approval or branch control check that references an allowed branch list or a required template, thereby enforcing that only authorized branches trigger releases.

Why this answer

Branch control for environments in Azure Pipelines allows you to restrict which branches can trigger deployments to specific environments, such as production. By configuring branch filters on an environment, you ensure that only approved branches (e.g., main or release branches) can initiate a production deployment, providing a security and governance boundary.

Exam trap

The trap here is that candidates often confuse deployment gates (approval checks) with branch-level access control, but gates evaluate conditions during deployment, not which branches are allowed to trigger the deployment in the first place.

How to eliminate wrong answers

Option A is wrong because YAML template expressions are used for parameterization and conditional logic within pipeline definitions, not for restricting which branches can trigger deployments to environments. Option C is wrong because deployment gates are approval checks (e.g., monitoring, manual intervention) that evaluate conditions before or during a deployment, but they do not control which branches can initiate the deployment. Option D is wrong because pipeline decorators inject additional steps or tasks into every pipeline run at the organization or project level, but they cannot enforce branch-based restrictions on environment deployments.

Practice this question →

369

MCQeasy

Your organization uses Azure Repos for source control and Azure Pipelines for CI/CD. You need to implement a policy that ensures every commit to the main branch is built and passes all tests before it can be merged. The team uses feature branches for development. What is the most efficient way to enforce this?

A.Require developers to manually run the pipeline before merging.

B.Use a pre-merge validation pipeline that runs on pull requests but does not block merging.

C.Configure a branch policy on the main branch that requires a successful build from a pull request trigger.

D.Set up a CI trigger on the main branch to run the pipeline on every commit.

AnswerC

A build validation branch policy on main requires a pull request trigger build to complete successfully before merging; if the build fails or has not yet finished, the merge is blocked by server-side enforcement, providing a true quality gate.

Why this answer

Configuring a branch policy on the main branch that requires a successful build from a pull request trigger ensures that every commit to main must be built and pass tests before merging. This is the most efficient automated enforcement. Option A is incorrect because relying on manual builds does not enforce the policy automatically.

Option B is incorrect because a pre-merge validation that does not block merging fails to prevent unvalidated commits. Option D is incorrect because a CI trigger on main runs after merge, not before, so it does not enforce pre-merge validation.

Practice this question →

370

Multi-Selectmedium

Which TWO actions can you take to improve the security of secrets in Azure Pipelines? (Choose two.)

Select 2 answers

A.Log secret values for debugging purposes

B.Limit variable group permissions to specific pipelines

C.Allow pipeline users to override secret values at queue time

D.Use Azure Key Vault to store secrets and map them as secret variables

E.Store secrets as plain text variables in the pipeline

AnswersB, D

Scoping variable group access to only the specific pipelines that require those secrets reduces the attack surface and enforces least privilege. Azure DevOps pipeline permissions on variable groups ensure unauthorized pipelines cannot consume or expose the linked secrets.

Why this answer

Limiting variable group permissions to specific pipelines ensures that only authorized pipelines can access sensitive secrets, reducing the risk of unauthorized exposure. Option D is correct because Azure Key Vault provides a centralized, auditable, and encrypted store for secrets, and mapping them as secret variables in Azure Pipelines prevents the secret values from being exposed in logs or output.

Exam trap

The trap here is that candidates may think overriding secrets at queue time (Option C) is a valid security feature, but it actually undermines security by allowing users to bypass the approved secret store and inject arbitrary values.

Practice this question →

371

MCQmedium

Your team uses Azure Pipelines for CI/CD. You need to enforce that all pipeline runs use approved agents from a specific agent pool with the latest security patches. The agents are self-hosted on Azure VMs. What should you implement?

A.Configure pipeline permissions for the agent pool

B.Create a deployment pool and assign the agents to it

C.Set the agent pool to use a specific agent queue with an isolation scope

D.Add a demand on the agent for a custom capability that only approved agents have

AnswerD

Correct. By adding a demand for a custom capability that only approved agents have (e.g., 'SecurityPatchLevel = latest'), the pipeline will only run on agents meeting that requirement.

Why this answer

By adding a demand for a custom capability (e.g., 'SecurityPatchLevel = latest') on the pipeline, only agents that possess that capability can run the pipeline. This allows you to enforce that only approved, patched agents are used. Option C is incorrect because 'setting an agent pool to use a specific agent queue with an isolation scope' is not a recognized Azure Pipelines feature; agent pools use demands, not isolation scopes, to filter agents.

Options A and B are also incorrect because configuring pool permissions or creating a deployment pool does not enforce that only agents with specific patches are used; they only control access or assignment but not the selection logic based on capabilities.

Exam trap

The trap is that candidates may think that using a dedicated agent queue or deployment pool will automatically limit which agents can run the pipeline. However, without a custom capability demand, any agent in the pool could be matched to the job. The correct approach is to define a custom capability for 'SecurityPatchLevel' or similar and add a demand to the pipeline.

How to eliminate wrong answers

Option A is wrong because configuring pipeline permissions for the agent pool controls who can use the pool, but does not enforce that only agents with the latest security patches are selected; it manages access, not agent eligibility. Option B is wrong because a deployment pool is designed for managing deployment targets (e.g., VMs for releases), not for controlling which build agents are used in pipeline runs; it does not enforce agent patching or approval. Option D is wrong because adding a demand for a custom capability only filters agents based on that capability label, but it does not inherently ensure the agent has the latest security patches unless the capability is manually and reliably updated, which is error-prone and not a built-in enforcement mechanism.

Practice this question →

372

MCQhard

Your team uses GitHub Actions to deploy a microservices application to a Kubernetes cluster. The workflow builds Docker images and pushes them to a container registry, then updates the Kubernetes deployment. The deployment often fails due to image pull errors, specifically 'ErrImagePull' and 'ImagePullBackOff'. You investigate and find that the image tag in the Kubernetes manifest is the commit SHA. The workflow uses the 'azure/k8s-deploy@v1' action. You suspect that the image is not being pulled because the registry credentials are not properly configured. You have stored the registry credentials as secrets. What is the most likely cause and solution?

A.The commit SHA tag is not valid; use 'latest' tag instead.

B.The image name is incorrect; verify the registry URL.

C.The 'azure/k8s-deploy' action does not support private registries; use a different action.

D.The action does not automatically create imagePullSecrets; you need to add a step to create the secret in the cluster and reference it in the deployment.

AnswerD

The 'azure/k8s-deploy' action only applies Kubernetes manifests, treating them as static YAML; it does not create or inject imagePullSecrets into the cluster. When pulling images from a private registry like ACR, Kubernetes requires a docker-registry secret (type kubernetes.io/dockerconfigjson) containing credentials, and your deployment spec must explicitly reference that secret under `imagePullSecrets`. Because the action simply runs `kubectl apply`, it cannot authenticate the kubelet on the cluster's behalf, so you must add a prior step to create the secret (e.g., using `kubectl create secret docker-registry`) and ensure it is referenced in the deployment manifest.

Why this answer

The 'azure/k8s-deploy@v1' action deploys to Kubernetes but does not automatically create imagePullSecrets for private container registries. Even if the registry credentials are stored as secrets in GitHub, they are not automatically applied to the cluster. You must explicitly create a Kubernetes secret of type docker-registry and add an imagePullSecrets entry to the deployment manifest.

Option A is wrong because using 'latest' tag is not a best practice and does not address authentication. Option B is wrong because the image name is likely correct; the issue is pulling due to lack of credentials. Option C is wrong because the action does support private registries when credentials are properly configured.

Practice this question →

373

MCQmedium

You have a YAML pipeline that builds a .NET application. You want to cache the NuGet packages to speed up subsequent builds. Which task should you use?

A.CopyFiles task to copy packages to a staging directory.

B.NuGet restore task with 'cacheRestore' option.

C.Cache task with a key based on the packages.lock.json hash.

D.PublishBuildArtifacts task to upload packages.

AnswerC

This is correct because the Cache task supports a key derived from the hash of packages.lock.json, which uniquely identifies the exact set of dependencies. When the key matches a previously saved cache, the packages folder is restored immediately, and after the build it is saved again, significantly improving restore time.

Why this answer

The Cache task in Azure Pipelines allows you to cache NuGet packages by specifying a key derived from the hash of `packages.lock.json`. This ensures that the cache is invalidated only when the lock file changes, which accurately reflects changes in package dependencies. The cached `~/.nuget/packages` folder is then restored on subsequent runs, significantly reducing restore time.

Exam trap

The trap here is that candidates confuse the NuGet restore task's built-in caching (which is not a parameter) with the separate Cache task, or they mistakenly believe that copying or publishing artifacts achieves caching for subsequent builds.

How to eliminate wrong answers

Option A is wrong because the CopyFiles task merely copies files to a staging directory; it does not implement caching logic or persist packages across pipeline runs. Option B is wrong because the NuGet restore task does not have a 'cacheRestore' option; caching is handled by a separate Cache task, not by a parameter on the restore task. Option D is wrong because the PublishBuildArtifacts task uploads artifacts to Azure Pipelines or a file share, but it does not cache packages for reuse in future builds; it is intended for sharing build outputs, not for dependency caching.

Practice this question →

374

MCQmedium

A development team is designing a build pipeline for a microservices application. They want to ensure that each service is built and tested independently, but they also need to run integration tests that span multiple services. What is the recommended approach?

A.Use a single release pipeline that triggers manual deployment for each service.

B.Create a single build pipeline that builds all services together to ensure consistency.

C.Create individual build pipelines for each service, and a separate release pipeline that deploys all services to an integration environment for testing.

D.Build each service separately, but skip integration tests to avoid complexity.

AnswerC

Individual build pipelines per service enable each team to build, version, and test independently, while a dedicated release pipeline that deploys all services to an integration environment validates cross-service contracts and interactions in a realistic environment, combining independence with necessary integration assurance.

Why this answer

It aligns with microservices best practices: each service has its own build pipeline for independent compilation, unit testing, and artifact generation, while a separate release pipeline orchestrates deployment of all services to a shared integration environment for cross-service testing. This decouples build concerns from deployment concerns, enabling parallel development and faster feedback loops.

Exam trap

The trap here is that candidates confuse 'building independently' with 'testing independently' and assume integration tests must be run within the build pipeline, when in fact they should be run in a separate release pipeline after deployment to a shared environment.

How to eliminate wrong answers

Option A is wrong because using a single release pipeline with manual deployment for each service introduces human delay and inconsistency, and it does not address independent building or automated integration testing. Option B is wrong because a single build pipeline that builds all services together violates the microservices principle of independent deployability, creating tight coupling and longer build times. Option D is wrong because skipping integration tests entirely defeats the purpose of verifying inter-service communication and data consistency, which is critical in a microservices architecture.

Practice this question →

375

MCQmedium

Your team uses Azure Pipelines and wants to automatically create a release every time a build succeeds on the main branch. Which trigger should you configure?

A.Pull request trigger in the build pipeline

B.Continuous integration (CI) trigger in the release pipeline

C.Build completion trigger in the release pipeline

D.Scheduled trigger in the release pipeline

AnswerC

A build completion trigger in a release pipeline is the correct choice because it automatically starts a release as soon as a specified build pipeline finishes successfully. This is the standard mechanism to deploy the artifacts produced by a CI build, enabling a fully automated build-and-release workflow.

Why this answer

A build completion trigger in the release pipeline allows you to automatically create a release whenever a specific build pipeline succeeds on the main branch. This trigger monitors the build pipeline for successful completions and initiates the release process, which directly matches the requirement of creating a release after every successful build on main.

Exam trap

The trap here is that candidates often confuse CI triggers (which apply to build pipelines) with release triggers, leading them to incorrectly select option B, not realizing that release pipelines use build completion triggers instead of CI triggers.

How to eliminate wrong answers

Option A is wrong because a pull request trigger in the build pipeline is used to automatically run a build when a PR is created or updated, not to create a release after a build succeeds. Option B is wrong because continuous integration (CI) triggers in release pipelines are not a valid concept; CI triggers exist in build pipelines to trigger builds on code changes, not to trigger releases. Option D is wrong because a scheduled trigger in the release pipeline runs releases on a fixed time schedule, not in response to a successful build on the main branch.

Practice this question →