Courseiva

CCNA Design and implement build and release pipelines Questions

75 of 348 questions · Page 2/5 · Design and implement build and release pipelines · Answers revealed

Practice these questionsDomain overviewAll questions
76
MCQeasy

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
77
MCQmedium

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
78
MCQmedium

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
79
MCQmedium

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
80
MCQeasy

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
81
Multi-Selecteasy

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

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

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

Why this answer

The Visual Studio Test task (C) is correct because it is the Azure Pipelines task that discovers and executes tests using the VSTest runner, which is exactly what is needed to run automated tests in the build pipeline. The Publish Test Results task (D) is correct because it takes the test result files produced by the test run and publishes them to the pipeline so results are surfaced in the build summary and reports, satisfying the requirement to publish results. The Publish Build Artifacts task (A) only uploads build outputs for later use and does not run or publish test results.

The Copy Files task (B) merely copies files between directories and has no testing capability. The Azure PowerShell task (E) runs PowerShell scripts against Azure resources and is unrelated to executing or publishing test results.

Exam trap

The trap is selecting tasks that seem related to testing but do not actually run or publish test results, such as Publish Build Artifacts or Azure PowerShell.

Practice this question →
82
MCQmedium

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

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

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

Why this answer

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

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

Practice this question →
83
Multi-Selecthard

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

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

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

Why this answer

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

Together, these optimizations improve build performance.

Exam trap

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

Practice this question →
84
Multi-Selectmedium

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

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

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

Why this answer

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

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

Practice this question →
85
MCQmedium

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
86
MCQeasy

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

A.Workflow triggers
B.Branch protection rules with required status checks
C.Required reviewers
D.Environment protection rules
AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
87
Multi-Selectmedium

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

Select 2 answers
A.Pipeline decorators
B.Approvals and checks on environments
C.Service connections with different scopes
D.Environment security roles
E.Branch policies on the main branch
AnswersB, D

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

Why this answer

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

Exam trap

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

Practice this question →
88
Multi-Selectmedium

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

Select 2 answers
A.Use variable groups linked to Azure Key Vault.
B.Use environment-specific variable groups.
C.Use XML transformation tasks for web.config.
D.Use multi-stage YAML pipelines with stage-level variables.
AnswersA, B

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

Why this answer

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

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

Exam trap

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

Why the other options are wrong

C

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

D

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

Practice this question →
89
Multi-Selecthard

Which THREE are benefits of using 'Environment' resources in YAML pipelines compared to classic release pipelines? (Choose three.)

Select 3 answers
A.Environments provide a dashboard showing the deployment history and resource health.
B.Environments can only be used in classic release pipelines.
C.Environments support checks like approval gates and manual intervention.
D.Environments allow you to define pre-deployment and post-deployment gates using the classic release pipeline interface.
E.Environments can represent Kubernetes namespaces and track deployed versions.
AnswersA, C, E

In Azure DevOps, an environment provides a centralized dashboard that consolidates the deployment history from every pipeline that targets that environment, displaying each run's status, artifact version, and timestamp. It also shows resource health, such as whether a VM agent is online or the current state of a Kubernetes namespace, giving teams immediate visibility into both past deployments and the live readiness of infrastructure. This combined view is essential for quickly diagnosing failed deployments, identifying drift, and ensuring auditability across multi-pipeline release processes.

Why this answer

Option A is correct because Azure DevOps Environments provide a dedicated dashboard that surfaces deployment history and the health/status of the associated resources (VMs, Kubernetes, etc.), giving visibility that classic release pipelines lack in a unified view. Option C is correct because Environments support configurable checks such as approvals, business hours, and manual intervention, which gate pipeline stages before deployment proceeds. Option E is correct because an Environment can be backed by a Kubernetes resource, where the target can be a namespace, and the environment tracks the deployed versions/artifacts to that namespace.

Option B is incorrect because Environments are designed for YAML pipelines, not classic release pipelines. Option D is incorrect because pre-deployment and post-deployment gates are a classic release pipeline feature, not a benefit of Environments in YAML pipelines.

Exam trap

The trap here is that candidates may confuse the classic release pipeline's gate mechanism (Option D) with the YAML pipeline's check system, or incorrectly assume Environments are only for classic pipelines (Option B), when in fact Environments are a cross-pipeline resource that enhances YAML pipelines with deployment tracking and approval workflows.

Practice this question →
90
MCQhard

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

A.Use a manual approval gate before swap.
B.Configure the App Service deployment center.
C.Add a task to verify settings before swap.
D.Mark the application setting as a deployment slot setting.
AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
91
MCQeasy

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
92
MCQhard

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

A.Create a single monorepo with all microservices. Use GitHub Actions with a multi-branch pipeline that builds only changed services. Deploy to AKS using kubectl commands in the pipeline. For rollback, redeploy the previous image tag.
B.Use Azure Pipelines with a single build pipeline that triggers on any change in any repo using webhooks. Use Azure DevOps Release Pipelines to deploy to AKS using Helm. Store Helm charts in Azure Container Registry. For rollback, use Helm rollback command.
C.Use GitHub Actions for CI and deploy directly to AKS using kubectl in the same workflow. Store Kubernetes manifests in each microservice repo. Use Argo CD to monitor the repos and sync.
D.Use GitHub Actions in each microservice repo for CI to build and push images to ACR. Use a separate GitOps repository that contains Kubernetes manifests. Configure Flux v2 in AKS to sync from the GitOps repo. When a new image is pushed to ACR, update the manifest in the GitOps repo via a GitHub Action, triggering Flux to deploy. For rollback, revert the commit in the GitOps repo.
AnswerD

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

Why this answer

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

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

Practice this question →
93
MCQmedium

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

A.Use a separate release pipeline that deploys to a production environment for testing.
B.Use a single release pipeline that deploys to a staging slot and runs tests on the slot.
C.Run integration tests in the build pipeline using a mock environment.
D.Use a release pipeline that deploys to a new Azure App Service instance, runs tests, and then removes the instance.
AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
94
Multi-Selectmedium

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

Select 3 answers
A.Canary deployment
B.Rolling update
C.A/B testing deployment
D.Helm deployment
E.Blue-green deployment
AnswersA, B, E

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

Why this answer

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

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

Exam trap

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

Practice this question →
95
Multi-Selecthard

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

Select 3 answers
A.A virtual machine running in Azure.
B.Network connectivity to Azure DevOps services.
C.A Personal Access Token (PAT) to authenticate the agent.
D.An agent pool configured in Azure DevOps and the agent configured to use that pool.
E.Docker installed on the agent machine.
AnswersB, C, D

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

Why this answer

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

Exam trap

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

Practice this question →
96
MCQmedium

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

A.The service principal must have 'Owner' role on the resource group containing the AKS cluster.
B.The service principal lacks the 'Azure Kubernetes Service Cluster Admin Role' on the AKS cluster.
C.The workflow uses an incorrect Kubernetes version.
D.The AKS cluster has RBAC disabled, causing authentication failures.
AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
97
Multi-Selectmedium

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

Select 2 answers
A.Use a classic release pipeline instead of YAML for the deployment stages.
B.Publish build artifacts and use them in the release stages.
C.Store deployment credentials directly in the YAML file.
D.Use a multi-stage YAML pipeline that includes build, test, and deploy stages.
E.Create a separate pipeline for each microservice.
AnswersB, D

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

Why this answer

Option B is correct because publishing build artifacts (via the PublishBuildArtifacts or PublishPipelineArtifact task) creates an immutable, versioned output that downstream deployment stages can consume, ensuring the same tested binaries are promoted across environments rather than rebuilt. Option D is correct because a multi-stage YAML pipeline natively models build, test, and deploy stages in a single versioned definition, enabling CI/CD with stage dependencies, gates, and environment approvals as code. Option A is not appropriate because classic release pipelines are the legacy, UI-based approach and do not provide the pipeline-as-code benefits expected for a modern microservices CI/CD implementation.

Option C is wrong because storing deployment credentials directly in YAML exposes secrets in source control; secrets should be kept in Azure Key Vault or variable groups linked to the pipeline. Option E is not required because a single multi-stage YAML pipeline can build and deploy multiple microservices using templates, paths filters, or matrix strategies, so a separate pipeline per microservice is not a necessary action.

Exam trap

The trap is thinking that classic release pipelines are still preferred or that separate pipelines per microservice are necessary, when modern best practices favor YAML multi-stage pipelines and artifact reuse.

Practice this question →
98
MCQeasy

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

A.The 'azure/docker-login@v1' action does not support ACR.
B.The Dockerfile is not in the repository root.
C.The service principal used for authentication lacks the AcrPush role on the ACR.
D.The workflow uses the registry admin credentials, which are disabled.
AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
99
MCQmedium

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

A.Store the Personal Access Token (PAT) in a variable and use it in the NuGet config.
B.Create an Azure Artifacts service connection and select it in the NuGet task.
C.Add a 'NuGetAuthenticate@1' task before the NuGet restore task.
D.Install the NuGet credential provider on the agent manually.
AnswerC

NuGetAuthenticate@1 injects credentials for Azure Artifacts feeds into the NuGet configuration at runtime, authenticating via the pipeline's service connection or Microsoft Entra ID identity. Placing it before NuGetCommand@2 satisfies the stem's requirement that the authenticated feed restore succeeds without hard-coded credentials in nuget.config.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
100
MCQmedium

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

A.The Azure Container Registry name is incorrect
B.The build ID variable is not defined
C.The service connection does not have permission to access the registry
D.The Azure CLI is not installed on the agent
AnswerA

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

Why this answer

The error 'The resource with name 'myregistry' could not be found' indicates that the pipeline is trying to reference an Azure Container Registry that does not exist or is misspelled. The most likely cause is that the registry name in the pipeline configuration is incorrect, such as a typo or wrong environment variable. This is a resource resolution error, not a permissions or tooling issue.

Exam trap

AZ-400 often tests the distinction between resource-not-found errors and permission errors; candidates may incorrectly choose the service connection permission option when the error explicitly says the resource could not be found.

How to eliminate wrong answers

Option B is wrong because an undefined build ID variable would typically cause a different error related to variable expansion, not a resource-not-found message for a registry. Option C is wrong because insufficient permissions would produce an authorization error (e.g., 403 Forbidden), not a resource-not-found error. Option D is wrong because a missing Azure CLI would cause a command-not-found error, not a registry lookup failure.

Practice this question →
101
MCQhard

You are configuring a multi-stage YAML pipeline that deploys to Azure App Service. The deployment stage must use a service connection with least privilege. You create a service connection using the Azure Resource Manager service connection type. Which authentication method should you choose to avoid storing a client secret?

A.Workload identity federation (automatic)
B.Managed identity
C.Publish profile
D.Service principal (automatic)
AnswerA

Workload identity federation allows Azure Pipelines to authenticate to Azure without storing a secret. It uses OpenID Connect (OIDC) to obtain short-lived tokens. This is the recommended method for least privilege and secretless authentication. It eliminates the need to manage and rotate client secrets, reducing security risks and administrative overhead.

Why this answer

Workload identity federation (automatic) is the correct choice because it uses OpenID Connect to authenticate without storing a secret. The Azure DevOps service connection exchanges a token from Azure Pipelines with Microsoft Entra ID to obtain an access token. This method aligns with least privilege and secretless authentication, as no client secret is persisted in the service connection.

Exam trap

The trap here is assuming that service principal (automatic) is secretless, but it actually creates and stores a client secret that must be rotated.

Practice this question →
102
MCQmedium

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

A.Rolling deployment
B.Blue-green deployment
C.Swap with preview
D.Canary deployment
AnswerC

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

Why this answer

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

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
103
MCQmedium

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

A.Deploy to a staging slot, run tests against the staging slot, then swap to production.
B.Deploy to the production slot directly and run tests after deployment.
C.Deploy to a staging slot, swap, then run tests.
D.Deploy to a staging slot, run tests, then delete the staging slot.
AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
104
MCQmedium

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

A.Use pipeline decorators to inject error handling steps.
B.Add a manual approval between regions.
C.Configure each region deployment as a separate stage with no dependencies.
D.Define stage dependencies with 'dependsOn' and set 'condition' to 'succeeded()'.
AnswerD

Setting `dependsOn` with `condition: succeeded()` makes each regional stage run only when every preceding dependency completed successfully, so a failed region halts downstream stages. This directly satisfies the stem's requirement that the pipeline must not proceed to the next region after a failure, using native YAML stage gating rather than manual checks.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
105
MCQmedium

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

A.Add a manual intervention task in the production stage
B.Set a post-deployment approval on the production stage
C.Set a pre-deployment approval on the production stage
D.Set a branch policy on the release branch
AnswerC

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

Why this answer

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

Exam trap

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

Why the other options are wrong

A

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

B

Post-deployment approval occurs after deployment, not before.

D

Branch policies affect pull requests, not release pipelines.

Practice this question →
106
MCQhard

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

A.Store the mandatory tasks as a YAML template in a central repository. In each pipeline, use the 'template' reference to include the mandatory steps. Use branch protection rules on the central repository to require approval for changes to the template.
B.Use a global list of tasks in the Azure DevOps organization settings that automatically get injected into every pipeline.
C.Create a single pipeline that runs across all repositories and include the mandatory tasks in that pipeline.
D.Create a custom Azure DevOps extension that adds the mandatory tasks to all pipelines using a pre-job hook.
AnswerD

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

Why this answer

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

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

Exam trap

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

Practice this question →
107
MCQhard

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

A.Store credentials in a pipeline variable with 'secret' type.
B.Use a variable group linked to Azure Key Vault.
C.Hardcode the credentials in the pipeline YAML.
D.Use a secure file in the pipeline library.
AnswerB

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

Why this answer

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

Exam trap

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

Why the other options are wrong

A

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

C

This is insecure and violates best practices.

D

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

Practice this question →
108
MCQeasy

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

A.startsWith(variables['Build.SourceBranch'], 'main')
B.eq(variables['Build.SourceBranchName'], 'refs/heads/main')
C.eq(variables['Build.SourceBranch'], 'refs/heads/main')
D.eq(variables['Build.SourceBranch'], 'main')
AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
109
MCQmedium

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

A.Create two separate pipelines, one for each platform.
B.Use a multi-job pipeline with two jobs, each specifying a different pool.
C.Use a multi-stage pipeline with a stage for each platform.
D.Add a `strategy` with a `matrix` that specifies `vmImage: ['windows-latest', 'ubuntu-latest']` in the job.
AnswerD

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

Why this answer

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

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

Practice this question →
110
MCQhard

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

A.Rolling update with health probes.
B.Canary deployment with progressive exposure.
C.Blue-green deployment with traffic manager.
D.Recreate deployment by deleting the old version first.
AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
111
Multi-Selecthard

Which THREE are required components to implement a secure CI/CD pipeline using Azure Pipelines and GitHub?

Select 3 answers
A.An Azure service connection to authenticate to Azure resources.
B.A container registry to store Docker images.
C.A YAML pipeline definition with stages and jobs.
D.A GitHub personal access token stored as a plain text variable.
E.Branch protection rules requiring status checks to pass.
AnswersA, C, E

A service connection is required for secure authentication to Azure resources, storing credentials or using workload identity federation so the pipeline can deploy without hard-coded secrets. It is a core component because every Azure-bound task needs a valid, authorized identity.

Why this answer

Option A is correct because an Azure service connection (a service principal or workload identity federation stored in Azure DevOps) is the mechanism Azure Pipelines uses to authenticate to Azure subscriptions and deploy resources securely without embedding credentials in code. Option C is correct because a YAML pipeline definition with stages and jobs is the declarative pipeline artifact that Azure Pipelines executes to build, test, and deploy code in a repeatable, version-controlled manner. Option E is correct because branch protection rules requiring status checks to pass prevent unreviewed or failing code from being merged, enforcing quality and security gates in the GitHub workflow.

Option B is not required because a container registry is only needed when the pipeline builds and stores Docker images, which is not a universal requirement for a secure CI/CD pipeline. Option D is not required and is in fact insecure, since storing a GitHub personal access token as a plain text variable exposes the secret; tokens should be kept in Azure Key Vault or a secret variable group instead.

Exam trap

The trap here is that candidates often assume a container registry is universally required, but it is only needed for container-based workflows, not for all secure CI/CD pipelines.

Practice this question →
112
MCQmedium

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

A.Enable Dependabot alerts on the repository.
B.Configure a repository rule to require a pull request before merging.
C.Add a GitHub Actions workflow that runs on 'pull_request' and set it as a required status check in branch protection.
D.Create a webhook to trigger a build on Azure Pipelines.
AnswerC

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

Why this answer

To require a CI check before merge, you add a GitHub Actions workflow triggered on 'pull_request' and then configure branch protection (or a repository ruleset) to mark that workflow's job as a required status check. This blocks merging until the check passes.

Exam trap

AZ-400 often tests the confusion between merely triggering a build (webhook or workflow) and actually enforcing it as a required status check in branch protection — only the latter blocks merges.

How to eliminate wrong answers

Option A is wrong because Dependabot alerts notify about vulnerable dependencies and do not run CI or block merges. Option B is wrong because requiring a pull request before merging only enforces that a PR exists — it does not require any CI check to pass. Option D is wrong because a webhook merely triggers an external build; without a required status check configured in branch protection, the merge is not blocked by the build result.

Practice this question →
113
Multi-Selecthard

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

Select 3 answers
A.An Azure Resource Manager service connection
B.A personal access token (PAT) with Agent Pools (read, manage) scope
C.A machine (virtual or physical) to run the agent software
D.The agent software downloaded from the Azure DevOps organization
E.An Azure Active Directory account for the agent
AnswersB, C, D

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

Why this answer

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

Exam trap

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

Practice this question →
114
MCQhard

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

A.Pre-deployment conditions: Add approvers (user1, user2) with 'All' policy and set timeout to 480 minutes
B.Pre-deployment conditions: Add approvers (user1, user2) with 'Any one' policy
C.Pre-deployment conditions: Add approvers (user1, user2) with 'All' policy and set 'Allow deployment without approval' to true
D.Post-deployment conditions: Add approvers (team) with 'All' policy
AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
115
MCQhard

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

A.The app's startup command is not configured
B.The resource group name is incorrect
C.The runtime stack is not specified in the command
D.The deployment slot is not specified
AnswerA

ZIP deploy via Azure CLI unpacks files but App Service runs no build automation, so without an explicit startup command the container has no entry point and the app never launches. The deployment succeeds because files land correctly; the failure is purely at process start.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
116
Multi-Selecteasy

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

Select 2 answers
A.Stages can run in parallel if dependencies allow.
B.Each stage can contain only one job.
C.Each stage must run on the same agent.
D.Stages cannot have conditions.
E.They are defined in a single YAML file.
AnswersA, E

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

Why this answer

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

Exam trap

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

Practice this question →
117
Multi-Selecthard

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

Select 3 answers
A.Store configuration in environment-specific YAML variable files.
B.Embed configuration values directly into the container image.
C.Hardcode configuration in pipeline scripts for each environment.
D.Use Azure Key Vault references in variable groups.
E.Use variable groups linked to Azure DevOps library.
AnswersA, D, E

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

Why this answer

Option A is correct because environment-specific YAML variable files let a single pipeline definition load different values per environment (e.g., dev/staging/prod) without changing the pipeline logic, keeping configuration externalized and version-controlled. Option D is correct because Azure Key Vault references in variable groups retrieve secrets at runtime, so sensitive values such as connection strings or API keys are never stored in plain text in the pipeline or repo. Option E is correct because variable groups linked to the Azure DevOps library centralize shared and secret variables, allow scoping to specific stages/environments, and support approval and access controls.

Option B is wrong because embedding configuration into the container image bakes environment-specific values into an immutable artifact, forcing a rebuild per environment and risking secret leakage. Option C is wrong because hardcoding configuration in pipeline scripts duplicates logic, is error-prone, and exposes secrets in source control.

Exam trap

AZ-400 often tests the misconception that embedding configuration in container images or hardcoding in scripts is acceptable; candidates may overlook the need for externalized, secure configuration management.

Practice this question →
118
MCQeasy

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

A.Configure the build to use a self-hosted agent with previously restored packages
B.Use a private agent with a faster network connection
C.Use a Microsoft-hosted agent with a larger SKU
D.Enable the 'Cache' task to cache the NuGet packages folder
AnswerD

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

Why this answer

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

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

Practice this question →
119
MCQeasy

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

A.PublishBuildArtifacts@1
B.CopyFiles@2
C.DownloadBuildArtifacts@0
D.Cache@2
AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
120
MCQhard

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

A.Create a single release pipeline with one stage that deploys to both dev and staging simultaneously, and add a manual intervention task before staging deployment.
B.Create a single release pipeline with two stages: 'Dev' triggered automatically on successful build, and 'Staging' with a pre-deployment approval gate.
C.Create two separate release pipelines: one for dev with continuous deployment trigger, and one for staging with a manual trigger.
D.Create a single release pipeline with two stages: 'Dev' triggered automatically, and 'Staging' with a post-deployment approval gate and disable continuous deployment trigger.
AnswerB

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

Why this answer

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

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

Practice this question →
121
MCQmedium

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

A.Configure the agent pool to use a specific agent version (e.g., '2.210.0') and test new versions in a separate pool before updating.
B.Switch to using Microsoft-hosted agents instead of self-hosted.
C.Disable automatic agent updates on the self-hosted agents.
D.Install .NET 6.0 on the agent machine to meet the new requirement.
AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
122
MCQhard

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

A.Use an Azure CLI task to run 'kubectl rollout undo' in a post-deployment script.
B.Use a Helm upgrade task with --wait and --timeout flags.
C.Use the Kubernetes manifest task with 'canary' deployment strategy and configure 'stabilityCheck' and 'rollback' settings.
D.Use the Kubectl task with a 'rollback' subcommand condition.
AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
123
MCQeasy

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

A.trigger: branches: include: - 'main'
B.trigger: paths: exclude: - 'src/api/*'
C.trigger: tags: include: - 'v*'
D.trigger: paths: include: - 'src/api/*'
AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
124
MCQeasy

You are designing a release pipeline for a .NET application. The pipeline must deploy to multiple environments (Dev, Test, Prod) with manual approval at each stage. Which release trigger should you configure for the production stage?

A.Pull request trigger from the main branch.
B.Continuous deployment trigger after a successful build.
C.Manual trigger with pre-deployment approvals.
D.Scheduled trigger set to run nightly.
AnswerC

A manual trigger requires a user to explicitly initiate the release, and adding pre-deployment approvals ensures that a designated approver must authorize the deployment before it proceeds. This combination gives full human control over when the release starts and enforces a review step, which directly supports the design requirement.

Why this answer

The requirement specifies manual approval at each stage, and for the production stage, a manual trigger with pre-deployment approvals ensures that deployments only occur after explicit human authorization. This aligns with the need for controlled, gated releases to production, preventing automatic or scheduled deployments that bypass approval.

Exam trap

The trap here is that candidates confuse build triggers (like PR or continuous integration) with release triggers, mistakenly applying build automation concepts to production deployment stages where manual approval is required.

How to eliminate wrong answers

Option A is wrong because a pull request trigger from the main branch is used for build validation or testing, not for release deployment triggers; it would initiate a build or test run on PR creation, not a production deployment with approvals. Option B is wrong because continuous deployment trigger after a successful build would automatically deploy to production without manual approval, violating the requirement for manual approval at each stage. Option D is wrong because a scheduled trigger set to run nightly would deploy automatically on a fixed schedule, bypassing the required manual approval and pre-deployment gates for production.

Practice this question →
125
MCQmedium

Your Azure Pipelines build fails intermittently due to transient network errors when downloading NuGet packages. You want to implement retry logic. What is the best approach?

A.Add a PowerShell task that wraps the NuGet restore in a retry loop
B.Increase the number of parallel jobs to average out failures
C.Use a deployment group to deploy the build to a staging environment
D.Configure a build retention policy to automatically retry failed builds
AnswerA

Wrapping the NuGet restore in a PowerShell task enables you to implement a retry loop that checks exit codes and repeats the restore operation on transient failures (e.g., HTTP timeouts or package source throttling), while allowing the build to fail after a defined number of attempts. This directly addresses the intermittent nature of the failure without requiring changes to the pipeline's parallelism or deployment topology.

Why this answer

Adding a PowerShell task that wraps the NuGet restore command in a retry loop directly addresses transient network failures by reattempting the download. This approach is lightweight, customizable (e.g., using `Start-Sleep` between retries), and does not require changing pipeline architecture or relying on external infrastructure.

Exam trap

The trap here is that candidates confuse build-level retry mechanisms (like retention policies or parallel jobs) with step-level retry logic, assuming Azure Pipelines automatically handles transient failures when it does not.

How to eliminate wrong answers

Option B is wrong because increasing parallel jobs does not retry a failed step; it only runs more builds concurrently, which may increase load on the network and exacerbate failures. Option C is wrong because deployment groups are used for deploying to target environments, not for handling transient build-time failures like NuGet restore errors. Option D is wrong because build retention policies control how long artifacts are kept, not how failed builds are retried; Azure Pipelines does not automatically retry builds based on retention settings.

Practice this question →
126
Matchingmedium

Match each Azure Pipeline concept to its definition.

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

Concepts
Matches

Compute resource to run jobs

Logical boundary for pipeline phases

Sequence of steps on a single agent

Atomic build or deployment action

Why these pairings

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

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

Practice this question →
127
MCQeasy

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

A.Blue-green deployment
B.Canary deployment
C.Rolling deployment
D.Run once deployment with parallel execution
AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
128
Multi-Selectmedium

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

Select 2 answers
A.Use OpenID Connect to authenticate to Azure without storing any credentials.
B.Hardcode the secret in the YAML file.
C.Set the secret as an environment variable in the runner's shell profile.
D.Base64-encode the secret and include it directly in the workflow file.
E.Store the secret as an encrypted GitHub secret and reference it using ${{ secrets.SECRET_NAME }}.
AnswersA, E

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

Why this answer

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

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

Exam trap

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

Practice this question →
129
MCQmedium

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

A.Add a build validation policy that triggers the CI pipeline and requires it to succeed.
B.Require a linked work item.
C.Require a minimum number of reviewers.
D.Require comment resolution.
AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
130
MCQhard

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

A.The build output is not copied to the staging directory
B.The projects pattern '**/*.csproj' does not match any files
C.The task 'PublishBuildArtifacts@1' is misspelled
D.The artifact name 'drop' is invalid
AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
131
MCQeasy

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

A.The agent's execution policy is restricted.
B.The agent does not have the required capabilities (e.g., .NET Core SDK installed).
C.The agent is not authorized to run the pipeline.
D.The agent cannot connect to the internet to download the task.
AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
132
MCQhard

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

A.Use path filters in the trigger section to exclude 'docs/*' and '*.md' files.
B.Configure branch policy to require a pull request for documentation changes.
C.Add a 'condition' to the pipeline that checks if changed files are documentation.
D.Disable CI trigger and rely on scheduled builds.
AnswerA

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

Why this answer

Azure Pipelines YAML triggers support 'paths' with 'include' and 'exclude' filters, so adding 'exclude: - docs/* - *.md' under the trigger prevents builds when only documentation changes. This is evaluated at trigger time by the service, so no agent minutes are consumed. It is the native, declarative mechanism for path-based CI filtering.

Exam trap

AZ-400 often tests the difference between trigger-time path filters and runtime conditions — candidates pick 'condition' thinking it prevents the build, but it only skips steps after the agent starts.

How to eliminate wrong answers

Option B is wrong because branch policies gate merges, not pipeline triggers — a PR requirement does not stop a CI build from firing on push. Option C is wrong because a pipeline 'condition' runs after the pipeline has already started and consumed agent time; it can skip steps but not prevent the trigger. Option D is wrong because disabling CI and relying on scheduled builds eliminates continuous integration entirely, which is the opposite of the goal.

Practice this question →
133
MCQmedium

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

A.Use the 'PipAuthenticate' task with a pip.conf file.
B.Use the 'npmAuthenticate' task with a .npmrc file.
C.Use the 'MavenAuthenticate' task with a settings.xml file.
D.Use the 'NuGetAuthenticate' task with a nuget.config file.
AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
134
Multi-Selectmedium

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

Select 2 answers
A.Azure Policy.
B.LaunchDarkly.
C.Azure App Configuration.
D.Azure Monitor.
E.Azure Key Vault.
AnswersB, C

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

Why this answer

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

Exam trap

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

Practice this question →
135
Multi-Selecthard

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

Select 3 answers
A.DotNetCoreCLI@2 with command 'build'
B.NuGetCommand@2 with command 'install'
C.DotNetCoreCLI@2 with command 'restore'
D.DotNetCoreCLI@2 with command 'push'
E.DotNetCoreCLI@2 with command 'pack'
AnswersA, C, E

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

Why this answer

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

Exam trap

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

Practice this question →
136
Multi-Selectmedium

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

Select 3 answers
A.GitHub App webhooks
B.Polling GitHub on a schedule
C.GitHub pull request events
D.GitHub branch push events
E.Azure Pipelines schedule trigger
AnswersA, C, D

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

Why this answer

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

Exam trap

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

Practice this question →
137
Matchingmedium

Match each Azure Monitor feature to its use case.

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

Concepts
Matches

Application performance monitoring and diagnostics

Query and analyze log data from various sources

Visualize performance metrics from Azure resources

Proactive notifications based on conditions

Why these pairings

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

Practice this question →
138
MCQmedium

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

A.Canary deployment
B.Rolling update
C.Blue-green deployment
D.Recreate deployment
AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
139
MCQmedium

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

A.Set pre-deployment approvals on the Dev and QA stages.
B.Set pre-deployment approvals on the Prod stage.
C.Use a post-deployment approval on the QA stage.
D.Disable the automatic trigger for all stages.
AnswerB

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

Why this answer

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

Exam trap

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

Why the other options are wrong

A

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

C

Post-deployment approvals occur after deployment, not before.

D

That would stop all automatic deployments.

Practice this question →
140
MCQhard

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

A.Blue-green deployment
B.Canary deployment
C.Red/Black deployment
D.Rolling deployment across regions
AnswerA

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

Why this answer

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

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
141
MCQhard

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

A.The Azure service connection has expired.
B.The service principal used by the pipeline does not have RBAC permissions on the cluster.
C.The container registry is not accessible from the build agent.
D.The build agent's IP address is not allowed by the AKS cluster's network policies.
AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
142
MCQeasy

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

A.Define three separate stages: lint, test, build.
B.Define one job with parallel steps using 'parallel' keyword.
C.Define multiple jobs without dependencies.
D.Define one job with multiple steps: lint, test, build.
AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
143
MCQhard

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

A.Azure CLI task to run 'az acr scan'
B.Docker task with the 'push' action
C.Container scanning task from Microsoft Defender for Cloud
D.PublishBuildArtifacts task
AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
144
MCQmedium

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

A.Trigger: none
B.trigger: branches: include: - main
C.schedules: - cron: "0 0 * * *" branches: include: - main
D.pr: branches: include: - main
AnswerB

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

Why this answer

To automatically build and deploy on every commit to the 'main' branch, you need a CI trigger that includes the 'main' branch. The YAML snippet 'trigger: branches: include: - main' does exactly that. It tells Azure Pipelines to trigger a run whenever a commit is pushed to 'main'.

Other options either disable triggers, schedule runs, or trigger on pull requests, none of which meet the requirement of automatic build on commit.

Exam trap

The trap is confusing CI triggers with PR triggers. Candidates might think that a 'pr' trigger will run on commits to the branch, but it only runs on pull requests. Also, 'trigger: none' is sometimes mistakenly used to mean 'no automatic trigger', but it disables CI entirely.

How to eliminate wrong answers

Option A is wrong because 'trigger: none' disables CI triggers entirely, so no automatic build on commit. Option C is wrong because 'schedules' defines a scheduled trigger (cron), not a CI trigger on commit. Option D is wrong because 'pr' triggers are for pull request validation, not for commits to a branch; they run when a PR is created or updated, not on direct commits to main.

Practice this question →
145
MCQhard

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

A.Publish the container image as a pipeline artifact and reference it from each stage.
B.Use the same image tag in all stages, updating the tag as needed.
C.Enable immutable tags on the container registry to prevent overwrites.
D.Rebuild the container image in each stage to ensure freshness.
AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
146
Multi-Selectmedium

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

Select 3 answers
A.Red-black deployment.
B.Rolling deployment.
C.Blue-green deployment.
D.Canary deployment.
E.Linear deployment.
AnswersB, C, D

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

Why this answer

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

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

Exam trap

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

Practice this question →
147
MCQeasy

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

A.Verify that the deployment slot is correctly configured.
B.Check the Kudu console for errors.
C.Ensure the web.config file is present.
D.Review the App Service diagnostic logs.
AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
148
MCQeasy

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

A.DotNetCoreCLI task with test command
B.Npm task
C.Publish Test Results task
D.Visual Studio Test task
AnswerD

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

Why this answer

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

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
149
MCQhard

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

A.The build will be triggered but only if no other builds are running.
B.The build will be triggered.
C.The build will not be triggered because the path filter is too restrictive.
D.The build will not be triggered because the branch is not 'main'.
AnswerB

Path filters apply regardless of branch, so a commit touching src/app/config.json matches the src/app/** include pattern and queues a build on release/v1. Branch name does not exempt the run unless a branch filter excludes it.

Why this answer

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

Therefore, option B is correct.

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
150
Multi-Selectmedium

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

Select 2 answers
A.Use a `deployment: Staging` job with `displayName: Deploy to staging`.
B.Define a stage for 'Deploy' with `dependsOn: Test` and `condition: succeeded('Test')`.
C.Set `trigger: main` at the pipeline root.
D.Add `condition: succeeded()` to the build job.
E.Define the trigger in the `resources` section using `pipelines`.
AnswersB, C

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

Why this answer

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

Exam trap

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

Practice this question →
← PreviousPage 2 of 5 · 348 questions totalNext →

Ready to test yourself?

Try a timed practice session using only Design and implement build and release pipelines questions.

Start 20-question session