Courseiva

CCNA Build Release Pipelines Questions

75 of 461 questions · Page 2/7 · Build Release Pipelines topic · Answers revealed

Practice these questionsExam hubAll questions
76
MCQhard

You are reviewing an Azure Policy definition applied to an Azure DevOps project. The project has a build pipeline that deploys to production. What is the effect of this policy on the build pipeline?

A.The policy blocks the pipeline from running if fewer than two reviewers approve.
B.The policy requires two reviewers and blocks the pipeline if not met.
C.The policy audits the pipeline but does not enforce any mandatory reviewers.
D.The policy does not apply to build pipelines because the field type is teamProjects.
AnswerC

The audit effect logs compliance without blocking.

Why this answer

Azure Policy definitions applied to Azure DevOps projects use the 'audit' effect by default for policy types that do not support 'deny' or 'enforce' on build pipelines. Since the policy in question does not specify a mandatory reviewer requirement with enforcement, it only audits the pipeline's compliance without blocking execution. Therefore, the pipeline runs regardless, and the policy logs a compliance state.

Exam trap

The trap here is that candidates assume Azure Policy can enforce pipeline-level controls like mandatory reviewers, but in Azure DevOps, Azure Policy only audits or denies resource-level configurations, not pipeline execution logic.

How to eliminate wrong answers

Option A is wrong because Azure Policy cannot block a build pipeline from running based on reviewer count; it only audits or denies resource creation, not pipeline execution. Option B is wrong because the policy does not enforce mandatory reviewers; it only audits, and Azure Policy does not have a 'require' effect for pipeline reviewers. Option D is wrong because Azure Policy applies to Azure DevOps projects via the 'Microsoft.DevOps/pipelines' resource type, and the field type 'teamProjects' is not a valid exclusion for build pipelines.

Practice this question →
77
MCQhard

Your organization uses GitHub for source control and Azure Pipelines for CI/CD. You have a monorepo with multiple projects. You need to design a pipeline that only builds and tests the projects that have changed in each commit. You want to minimize build time and avoid unnecessary runs. The pipeline should also handle dependencies between projects. Which approach should you use?

A.Create a single pipeline that builds all projects on every commit
B.Configure path filters in the pipeline trigger, and use a custom script to detect dependencies and build only affected projects plus their dependents
C.Use a single pipeline with a condition that checks which files changed and runs only the corresponding job
D.Create separate pipelines for each project and trigger them manually
AnswerB

Path filters limit triggers and dependency detection ensures build correctness.

Why this answer

Using path filters with dependency detection is efficient. Option B builds all projects, wasting time. Option C builds changed projects but ignores dependencies.

Option D uses manual triggers, which is not automated.

Practice this question →
78
MCQeasy

Refer to the exhibit. You have a YAML pipeline that deploys an ARM template. The pipeline runs successfully on the first commit to main, but subsequent commits fail with 'The resource group myResourceGroup already exists'. How should you modify the pipeline to avoid this error?

A.Change the location to a different region.
B.Add a condition to check if the resource group exists before creating it.
C.Use a different service connection for each deployment.
D.Rename the pipeline to trigger a clean build.
AnswerB

Using an Azure CLI condition (e.g., 'az group exists') before creating avoids the error.

Why this answer

Option C is correct because adding a condition to check if the resource group exists before creating it will prevent the error. Option A is wrong because changing the location does not solve the existence issue. Option B is wrong because using a different pipeline name is irrelevant.

Option D is wrong because the error is not about credentials.

Practice this question →
79
MCQmedium

You have a multi-stage YAML pipeline that deploys to Azure Kubernetes Service (AKS). The pipeline uses a deployment job with a strategy of 'runOnce'. You need to ensure that if the deployment fails, the pipeline automatically redeploys the previous successful version. Which strategy should you use instead?

A.Use the 'canary' strategy with manual intervention
B.Use the 'rolling' strategy and configure 'on:failure: always'
C.Use the 'blueGreen' strategy and configure automatic swap
D.Use the 'runOnce' strategy with a rollback task
AnswerB

Why this answer

Option B is correct because the 'rolling' strategy in Azure DevOps deployment jobs supports an 'on:failure' hook that can be configured to run actions like 'always', which can trigger a rollback to the previous successful version. This ensures automatic redeployment of the last stable release upon failure, meeting the requirement without manual intervention.

Exam trap

The trap here is that candidates often confuse the 'rolling' strategy's 'on:failure' hook with the 'blueGreen' strategy's swap capability, assuming automatic swap implies rollback, but swap only shifts traffic and does not revert the deployment on failure.

Why the other options are wrong

A

Canary strategy does not automatically roll back; it requires manual approval or additional steps.

C

BlueGreen strategy requires manual swap; it does not roll back automatically.

D

runOnce does not support automatic rollback; you would need custom scripting.

Practice this question →
80
Multi-Selectmedium

Which two actions can you use to validate that a deployment to a staging environment is successful before promoting to production? (Choose two.)

Select 2 answers
A.Configure gates on the staging environment to check health metrics.
B.Add a manual intervention task in the pipeline.
C.Set a post-deployment approval on the staging stage.
D.Use a pull request to validate the deployment.
E.Run a load test as part of the pipeline.
AnswersA, C

Why this answer

Gates with health checks can monitor metrics like error rates before allowing promotion. Manual intervention with a post-deployment approval also allows a human to validate before proceeding. Both are valid methods.

Exam trap

Candidates may select 'Use a pull request' which is for code review, not deployment validation.

Why the other options are wrong

B

Manual intervention tasks are deprecated; use approvals instead.

D

Pull requests validate code changes, not deployments.

E

Load testing is a good practice but not a direct validation mechanism for promotion approval.

Practice this question →
81
MCQeasy

You are designing a build pipeline for a Python application that uses multiple third-party packages from the public PyPI repository. Your organization has security policies that require all build dependencies to be scanned for known vulnerabilities before being used. The build pipeline runs on Microsoft-hosted agents. You need to integrate vulnerability scanning into the build pipeline with minimal overhead and without storing credentials in the pipeline. What should you do?

A.Configure a service connection to a private vulnerability database and use a script to scan.
B.Write a custom script that uses pip audit to scan the requirements.txt file.
C.Use a pre-build validation step in the pipeline to manually review dependencies.
D.Add a dependency scanning task from the Azure DevOps marketplace to the build pipeline.
AnswerD

Marketplace tasks are easy to add and often support credential-free scanning for public packages.

Why this answer

Option A is correct: Dependency scanning task (e.g., WhiteSource Bolt or GitHub Dependabot) integrates easily without credentials. Option B is incorrect because storing credentials in variables is not recommended. Option C is incorrect because custom scripts require maintenance and may not integrate well.

Option D is incorrect because manual scanning defeats automation.

Practice this question →
82
MCQhard

You are designing a release pipeline for a critical business application that must adhere to strict compliance requirements. The pipeline must deploy to multiple environments (dev, test, staging, prod) with manual approvals required for staging and prod. Additionally, the pipeline must automatically run integration tests after deployment to dev and test, and only proceed to the next environment if tests pass. You need to implement this using Azure Pipelines YAML. What should you do?

A.Use a single multi-stage YAML pipeline with a stage per environment. Add approvals on staging and prod stages. Ensure stages run sequentially by default.
B.Create separate YAML pipelines for each environment and use pipeline completion triggers to chain them together.
C.Use a classic release pipeline with environments and pre-deployment approvals on staging and prod. Add a post-deployment task to run integration tests in dev and test environments.
D.Use a single multi-stage YAML pipeline with a stage per environment. Add a job after deployment to dev that runs integration tests, and use a condition on the next stage to run only if tests passed. Add approvals on staging and prod stages.
AnswerD

Stages with conditions and approvals fulfill all requirements.

Why this answer

Option C is correct because it uses stages with dependencies and conditions to run tests after deployment, and approvals on staging and prod. Option A is incorrect because release pipelines with environments can't easily run tests conditionally. Option B is incorrect because separate pipelines lack coordination.

Option D is incorrect because stages run sequentially by default but approvals are per environment, not stage.

Practice this question →
83
Multi-Selecthard

Your organization uses GitHub Actions for CI/CD. You need to enforce branch protection rules and ensure that all pull requests to the main branch require a successful status check from a specific workflow. Which TWO actions should you take? (Choose two.)

Select 2 answers
A.Configure a GitHub environment with required reviewers.
B.Add a workflow to the repository that runs tests and reports a conclusion status.
C.Use a repository ruleset to require status checks.
D.Set up branch policies in Azure Repos for the main branch.
E.In the repository settings, enable 'Require status checks to pass before merging' under branch protection rules.
AnswersB, E

The workflow provides the status check that can be required.

Why this answer

Option A is correct: Add a workflow that runs tests and reports a status. Option D is correct: Configure branch protection rules to require status checks. Option B is incorrect: GitHub environments are for deployment protection, not branch protection.

Option C is incorrect: Branch policies are an Azure Repos feature, not GitHub. Option E is incorrect: Repository rulesets are an alternative but 'require status checks' is a branch protection setting.

Practice this question →
84
MCQeasy

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

A.Add an approval gate that requires a manager to approve the release.
B.Add a deployment gate that checks the source branch.
C.Add a branch filter to the release pipeline's artifact trigger.
D.Add a branch filter to the build pipeline trigger.
AnswerC

The artifact trigger's branch filter controls which builds trigger a release.

Why this answer

Option C is correct because branch filters in the release trigger control which branches can start a release. Option A is wrong because it restricts build triggers, not releases. Option B is wrong because deployment gates do not filter branches.

Option D is wrong because approval gates are for manual approval, not branch restriction.

Practice this question →
85
MCQeasy

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

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

This correctly ensures the stage runs only when the source branch is main.

Why this answer

Option B is correct because the 'condition' property with 'eq(variables['Build.SourceBranch'], 'refs/heads/main')' ensures the stage runs only for the main branch. Option A is wrong because 'and(succeeded(), eq(...))' would also require previous stages to succeed, which is not specified. Option C is wrong because 'ne(variables['Build.SourceBranch'], 'refs/heads/main')' would run for all branches except main.

Option D is wrong because 'contains(variables['Build.SourceBranch'], 'main')' could match branch names containing 'main' like 'feature/maintenance'.

Practice this question →
86
MCQeasy

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

A.Set the 'Continue on error' option to false for the test task.
B.Add a custom condition to the test task to only run if previous tasks succeeded.
C.Set the 'Always run' option for the test task.
D.Ensure the task control option 'Run this task' is set to 'Only when all previous tasks have succeeded'.
AnswerD

This setting prevents the pipeline from running subsequent tasks if a previous task fails.

Why this answer

Setting the task control option 'Run this task' to 'Only when all previous tasks have succeeded' ensures that the pipeline stops on failure. Option A is wrong because 'Continue on error' allows the pipeline to continue even if the task fails. Option C is wrong because 'Always run' runs the task regardless of previous failures.

Option D is wrong because 'Custom conditions' can be used but are not the simplest way to stop on failure.

Practice this question →
87
MCQmedium

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

A.Define an environment with approvals required for the production stage.
B.Use deployment gates in the production stage to check for manual intervention.
C.Use a classic release pipeline with pre-deployment approvals.
D.Configure a branch policy on the main branch to require approval for pull requests.
AnswerA

Environment approvals provide manual sign-off before deployment.

Why this answer

Option B is correct because environment approvals in a multistage YAML pipeline allow you to specify approvals before a stage runs. Option A is wrong because gates are for health checks, not approvals. Option C is wrong because release pipelines are legacy and not recommended for new projects.

Option D is wrong because branch policies control code quality, not deployment approvals.

Practice this question →
88
MCQhard

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

A.Hardcode credentials in the script and encrypt the script file
B.Store credentials as pipeline variables and reference them
C.Use Azure Key Vault task to fetch secrets during deployment
D.Use environment variables on the target machines
AnswerC

Key Vault securely stores and injects secrets.

Why this answer

Option A is correct because Azure Key Vault integration provides secure secret storage and retrieval. Option B is wrong because storing in pipeline variables exposes secrets. Option C is wrong because environment variables can be logged.

Option D is wrong because plaintext in scripts is insecure.

Practice this question →
89
MCQeasy

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

A.Define pipeline stages with environment resources and pre-deployment approvals.
B.Use environment resources with 'auto' trigger and no approvals.
C.Use classic release pipelines with approval gates per environment.
D.Use a custom PowerShell script to pause and prompt for approval.
AnswerA

YAML pipelines support environments with approvals directly.

Why this answer

Option C is correct because environments in Azure Pipelines support approvals and gates, and can be used in a multi-stage pipeline with manual triggers. Option A is outdated; releases are the classic approach. Option B is insufficient for approvals.

Option D requires custom scripting.

Practice this question →
90
MCQmedium

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

A.Increase the number of parallel jobs in the organization.
B.Use more pipeline triggers.
C.Provision self-hosted agents.
D.Reduce the number of parallel jobs.
AnswerC

Self-hosted agents are dedicated and reduce queue times.

Why this answer

Option A is correct because using self-hosted agents provides dedicated capacity. Option B is wrong because reducing parallel jobs doesn't help queue time. Option C is wrong because it increases parallelism but doesn't reduce queue time per job.

Option D is wrong because more jobs would increase queue time.

Practice this question →
91
MCQmedium

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

A.Add a branch protection rule that requires status checks to pass.
B.Enable 'Require approval for all workflows' in the organization settings.
C.Set the workflow to be required in the 'Require status check' settings of each pull request.
D.Create a repository ruleset that requires linear history.
AnswerA

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

Why this answer

Branch protection rules can require status checks to pass before merging. In GitHub, you can set up a branch protection rule that requires status checks, including GitHub Actions workflows. Option A is correct.

Option B is wrong because rulesets are for repository rules, not for requiring checks. Option C is wrong because the required status check can be set at the branch level, not per workflow file. Option D is wrong because GitHub Actions does not have a built-in 'Approval' feature for workflow runs; approval is for deployments.

Practice this question →
92
Multi-Selecthard

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

Select 3 answers
A.Restrict agent pool permissions to only necessary users
B.Use Microsoft Entra ID to control access to pipelines
C.Store secrets as plain text in YAML files
D.Use variable groups with Azure Key Vault integration for secrets
E.Run build agents on domain controllers
AnswersA, B, D

Least privilege principle applies to agent pools.

Why this answer

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

Exam trap

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

Practice this question →
93
MCQhard

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

A.Store the values in a variable group and map them to Helm values.
B.Store the values file in Azure Key Vault and use the HelmDeploy task's 'overrideValues' parameter to set values.
C.Store the values file as a secure file in Azure Pipelines library.
D.Store the values file in a separate Git repository and clone it during the pipeline.
AnswerC

Secure files are encrypted and can be downloaded only during the pipeline run.

Why this answer

Option C is correct because Azure Key Vault can securely store secrets and configuration files, and the HelmDeploy task can reference them. Option A is incorrect because storing values files in a separate branch is not secure. Option B is incorrect because checking secrets into the repo is a security risk.

Option D is incorrect because variable groups are for simple key-value pairs, not files.

Practice this question →
94
MCQeasy

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

A.Set the pipeline trigger to 'Manual' only
B.Add a 'Manual Intervention' task in the pipeline
C.Configure branch policies on the main branch
D.Define an environment with required approvers for the production stage
AnswerD

Environment approvals require explicit approval before deployment.

Why this answer

Option C is correct because environment-level approvals gate the deployment. Option A is wrong because branch policies do not control approvals. Option B is wrong because stage-level approvals can be used but environment approvals are more granular.

Option D is wrong because manual triggers do not enforce approvals.

Practice this question →
95
Multi-Selecteasy

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

Select 2 answers
A.Use a variable group linked to Azure Key Vault.
B.Store secrets directly in the YAML pipeline file.
C.Use the 'secret' variable type in the pipeline UI.
D.Use environment variables in the build agent.
E.Print the secret in a script to verify it is correct.
AnswersA, C

Key Vault provides secure secret storage.

Why this answer

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

Option D is wrong because logging secrets is not secure. Option E is wrong because environment variables are not inherently secure.

Practice this question →
96
MCQeasy

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

A.Use a conditional step that runs only when the build succeeds to tag the image as 'latest'
B.Use the build ID as the tag and manually update 'latest'
C.Use the Git commit hash as the tag and push 'latest' separately
D.Always tag the image as 'latest' regardless of build status
AnswerA

Conditional tagging ensures only successful builds are tagged.

Why this answer

Option A is correct because tagging only on successful builds ensures 'latest' reflects the last successful image. Option B is wrong because tagging all images with 'latest' would overwrite even failed builds. Option C is wrong because it does not ensure success.

Option D is wrong because it tags all images, not just successful ones.

Practice this question →
97
Multi-Selectmedium

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

Select 2 answers
A.Store secrets in environment variables on the agent machine.
B.Define secrets as pipeline secret variables and reference them as $(secretName).
C.Store secrets in a YAML file and include the file in the repository.
D.Use plain text variables in the pipeline and mask them using the 'Logging Command' feature.
E.Use Azure Key Vault to store secrets and reference them via variable groups linked to Key Vault.
AnswersB, E

Secret variables are encrypted and masked in logs.

Why this answer

Options B and D are correct. Option B: Using Azure Key Vault to store secrets and linking them to pipeline variables ensures secure access. Option D: Using secret variables prevents exposure in logs.

Option A is wrong because storing secrets in YAML files is insecure. Option C is wrong because using plain text variables exposes them. Option E is wrong because using environment variables in the agent is not secure as they can be read by other processes.

Practice this question →
98
Multi-Selecteasy

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

Select 2 answers
A.Schedule trigger
B.Pull request (PR) trigger
C.Continuous integration (CI) trigger
D.'on: push' trigger in YAML
E.Commit trigger
AnswersB, C

PR trigger runs on pull request creation or updates.

Why this answer

Options A and B are correct. A: CI trigger runs when changes are pushed to a branch. B: PR trigger runs when a pull request is created.

Option C is wrong because there is no 'on: push' in Azure Pipelines YAML; that's GitHub Actions syntax. Option D is wrong because 'commit' trigger is not a term; it's CI trigger. Option E is wrong because 'schedule' trigger is valid but it's not a basic trigger; CI and PR are the primary triggers.

Practice this question →
99
MCQhard

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

A.NuGetCommand@2 with the restore command
B.CopyFiles@2
C.PowerShell@2 to manually download and cache
D.Cache@2 (CacheBeta)
AnswerD

Cache task caches folders like the NuGet packages directory.

Why this answer

Option C is correct because the Cache task (CacheBeta@2) is designed to cache dependencies like NuGet packages. Option A is wrong because the NuGet task has a restore command but no caching. Option B is wrong because the Copy Files task is for copying files.

Option D is wrong because the PowerShell task can be used but is not the built-in caching solution.

Practice this question →
100
MCQmedium

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

A.--configuration Release
B.--runtime linux-x64
C.--output $(Build.ArtifactStagingDirectory)
D.--self-contained true
AnswerB

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

Why this answer

Option D is correct because the --runtime flag specifies the target runtime for a self-contained deployment. Option A is wrong because --configuration specifies build configuration. Option B is wrong because --output specifies output path.

Option C is wrong because --self-contained is a property in the project file, not a CLI argument.

Practice this question →
101
MCQmedium

Match each Azure DevOps concept to its correct description.

A.Build pipeline
B.Release pipeline
C.Task
D.Variable
E.Trigger

Why this answer

Each concept matches a specific functionality: Build pipeline compiles code, Release pipeline deploys, Task is a single action, Variable holds values, Trigger starts pipeline.

Exam trap

Candidates may confuse Build and Release pipelines, or Task vs Variable.

Why the other options are wrong

A

Matches 'Compiles source code and runs tests'

B

Matches 'Deploys artifacts to target environments'

C

Matches 'A single action in a pipeline, such as a script or build step'

D

Matches 'A name-value pair used to store configuration or secrets'

E

Matches 'An event that starts a pipeline run'

Practice this question →
102
MCQmedium

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

A.Immutable deployment
B.Rolling deployment
C.Blue-green deployment
D.Canary deployment
AnswerB

Rolling updates instances gradually and can tolerate failures in one region.

Why this answer

A rolling deployment updates instances gradually and can continue if one region fails. Option A is wrong because blue-green would switch all traffic at once. Option B is wrong because canary targets a small subset.

Option D is wrong because immutable replaces all instances.

Practice this question →
103
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

Correct: GitHub Secrets are encrypted and masked in logs.

Why this answer

Option A is correct because GitHub secrets are encrypted and automatically masked in logs. Option B is wrong because environment variables are not encrypted and may be logged. Option C is wrong because encrypted variables in Azure DevOps are not a GitHub feature.

Option D is wrong because hardcoding secrets is insecure.

Practice this question →
104
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 repository resource triggers to work, the 'Trigger' setting for the pipeline must be enabled, and the repository trigger must be explicitly configured. In this case, the pipeline trigger might be disabled.

Why this answer

The pipeline's own repository (self) triggers only when its own default branch receives commits. The repository resource 'internal' is configured with a trigger, but the pipeline itself may not have CI triggers enabled, or the trigger for the repository resource might be disabled by default unless explicitly enabled.

Practice this question →
105
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

Code splitting reduces initial bundle size.

Why this answer

Option C is correct because the Webpack task can be configured to analyze bundle size and split code. Option A is wrong because caching dependencies does not reduce bundle size. Option B is wrong because minification is likely already done.

Option D is wrong because unit tests do not affect bundle size.

Practice this question →
106
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

Approval checks require manual sign-off.

Why this answer

Environment approvals are the native way to require manual sign-off before deployment. Option B is wrong because deployment gates are automatic checks. Option C is wrong because branch policies restrict source branches.

Option D is wrong because pipeline decorators add steps but don't enforce approvals.

Practice this question →
107
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

CodeQL analysis can run on PRs and report results as check runs that block merging.

Why this answer

GitHub Code Scanning with a workflow can run security scans and block PRs via check runs. Option B is wrong because Dependabot only updates dependencies. Option C is wrong because secret scanning detects secrets, not vulnerabilities.

Option D is wrong because branch protection rules enforce checks, but the scan itself is Code Scanning.

Practice this question →
108
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

Runs unit tests and produces results.

Why this answer

Option A is correct because the VSTest task runs tests. Option C is correct because the Publish Test Results task publishes results. Option B is wrong because the Copy Files task copies files, not runs tests.

Option D is wrong because the Publish Build Artifacts task publishes artifacts, not test results. Option E is wrong because the Azure PowerShell task runs scripts, not tests.

Practice this question →
109
Multi-Selecteasy

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

Select 2 answers
A.Continuous integration trigger
B.Scheduled release trigger
C.Continuous deployment trigger
D.Pull request trigger
E.Branch policy trigger
AnswersB, C

Scheduled trigger starts a release at a specified time.

Why this answer

Options A and D are correct. Continuous deployment trigger starts a release when a build artifact is ready, and scheduled release trigger starts at a defined time. Options B and C are build triggers, not release triggers.

Option E is for build validation, not release.

Practice this question →
110
MCQmedium

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

A.Use the 'VSTest@2' task with 'retryFailedTests: true' option.
B.Create a custom script that runs each test individually and retries on failure.
C.Enable 'test retry' in the pipeline settings under 'General'.
D.Wrap the test task in a 'Retry' loop using a 'each' expression.
AnswerA

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

Why this answer

Option B is correct because the 'retryFailedTests' option in the VSTest task automatically retries failed tests. Option A is a workaround but not a built-in feature. Option C requires custom scripting.

Option D is not available in Azure DevOps.

Practice this question →
111
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

Azure Pipelines automatically maps Key Vault secrets as pipeline variables accessible with $(VariableName).

Why this answer

Option A is correct because Key Vault-backed variables are automatically mapped as secret variables, and you reference them using the variable name. Option B is incorrect because $(variable) syntax is for non-secret variables; secrets require $(). Option C is incorrect because the task name is not part of the reference.

Option D is incorrect because task.getVariable is a scripting method, not YAML.

Practice this question →
112
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 reduces download time for packages.

Why this answer

Option B is correct because enabling NuGet package caching in Azure Pipelines stores downloaded packages on the agent, avoiding repeated downloads from the NuGet feed on subsequent builds. This significantly reduces build time, especially when the same packages are used across multiple pipeline runs, as network latency and package restore operations are minimized.

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 →
113
Multi-Selecthard

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

Select 2 answers
A.Enable a system-assigned managed identity on the agent VM.
B.Use the 'docker login' command in the pipeline.
C.Add a service principal connection to the pipeline.
D.Set the 'identity' field in the container resource definition.
E.Use the Azure CLI task with '–identity' flag.
AnswersA, D

Why this answer

Option A is correct because a system-assigned managed identity on the agent VM allows the container to authenticate to Azure resources without storing credentials. Option D is correct because setting the 'identity' field in the container resource definition explicitly assigns that managed identity to the container, enabling it to request tokens from Azure AD for resource access.

Exam trap

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

Why the other options are wrong

B

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

C

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

E

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

Practice this question →
114
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

CI trigger runs automatically for non-production.

Why this answer

Option B is correct because approval gates can be added to the production stage. Option D is correct because the trigger should be set for CI triggers on non-production branches. Options A, C, and E are not correct.

Practice this question →
115
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

Slot-specific settings stay with the slot during swap, preventing conflicts.

Why this answer

Option A is correct because 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 →
116
MCQeasy

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

A.Keep the previous Docker image tag in ACR and update the manifest to point to it manually.
B.Rerun the previous successful pipeline run.
C.Use the Kubernetes task with the 'rollback' option, which runs 'kubectl rollout undo' on the deployment.
D.Use Helm to manage releases and rollback using 'helm rollback' command.
AnswerC

Kubernetes built-in rollback reverts to the previous revision.

Why this answer

Using Kubernetes native rollback with 'kubectl rollout undo' is the simplest. Option B uses Helm rollback, which is similar but adds complexity. Option C relies on ACR tags, which is not immediate.

Option D requires manual re-run.

Practice this question →
117
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 can require specific status checks to pass before merging.

Why this answer

Option C is correct because branch protection rules allow you to require status checks to pass before merging. Option A is wrong because workflow triggers define when workflows run, not merge requirements. Option B is wrong because required reviewers are for manual approval, not automated checks.

Option D is wrong because environment protection rules are for deployments, not pull request merges.

Practice this question →
118
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 require designated reviewers to approve deployments.

Why this answer

Approvals and checks enforce separation by requiring ops approval before deployment. Environment security ensures only specific users can deploy to production. Option C is wrong because branch policies are for source control, not deployment.

Option D is wrong because service connections are for authentication, not separation of duties. Option E is wrong because pipeline decorators inject steps but do not enforce separation.

Practice this question →
119
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

Why this answer

Option A is correct because variable groups linked to Azure Key Vault allow you to securely store and manage secrets (like connection strings and API keys) centrally, and reference them across multiple pipelines and environments without hardcoding sensitive values. This approach integrates with Azure Key Vault's access policies and automatic secret rotation, ensuring configuration consistency and security across environments.

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 →
120
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

Environments offer visibility into deployment status.

Why this answer

Options A, C, and D are correct. Option A: YAML pipelines with environments support Kubernetes resources for tracking deployments to AKS. Option C: Environments provide a centralized view of deployments and live resource health.

Option D: Environments support checks such as approvals, gates, and manual intervention. Option B is wrong because YAML pipelines do not support pre-deployment gates directly; they use checks. Option E is wrong because environments are available in both YAML and classic pipelines.

Practice this question →
121
MCQmedium

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

A.Configure a quality gate in the release pipeline to check coverage.
B.Add a script task that reads the coverage report and prints a warning.
C.Use the 'PublishCodeCoverageResults' task with a 'codeCoverageThreshold' setting.
D.Use the VSTest task with the 'codeCoverageEnabled' option set to true.
AnswerC

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

Why this answer

Option B is correct because the PublishCodeCoverageResults task can set a coverage threshold and fail the pipeline if not met. Option A is wrong because the test runner does not enforce thresholds. Option C is wrong because the build summary doesn't fail the pipeline.

Option D is wrong because quality gates apply to release, not CI.

Practice this question →
122
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

Slot settings remain with the slot, preventing misconfiguration after swap.

Why this answer

Option C is correct because slot-specific settings should be marked as 'deployment slot settings' so they persist across swaps. Option A is wrong because verifying before swap is reactive, not preventive. Option B is wrong because manual validation is error-prone.

Option D is wrong because deployment center doesn't control slot settings.

Practice this question →
123
MCQeasy

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

A.pr:
B.trigger:
C.schedules:
D.resources:
AnswerA

Correct: pr trigger fires on pull requests.

Why this answer

Option A is correct because the `pr:` trigger in Azure Pipelines YAML is specifically designed to automatically start a pipeline when a pull request is created or updated against a specified branch. By default, `pr:` triggers are enabled for the `main` branch, so configuring `pr: main` ensures the pipeline runs on PR creation without needing a separate branch policy.

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
124
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

Correct: Build.SourceBranch includes full ref path.

Why this answer

Option C is correct because 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 →
125
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

Correct: This satisfies all requirements with GitHub Actions for CI, Flux for GitOps, and rollback via Git revert.

Why this answer

Option A is correct because it uses GitHub Actions for CI per microservice, pushes to ACR, and uses Flux v2 for GitOps-based deployment with rollback by reverting Git. Option B is wrong because Azure Pipelines is not preferred if the team already uses GitHub Actions and GitOps. Option C is wrong because multi-branch pipelines in a single repo would mix concerns and violate requirement 1 (separate repos).

Option D is wrong because Argo CD is not a native GitHub or Azure solution and introduces complexity.

Practice this question →
126
MCQhard

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

A.Use three slots: production, staging, and a new slot for the new version. Apply schema changes in the new slot, then swap new to staging, warm up staging, then swap staging to production. On failure, swap staging back to production.
B.Use two slots (staging and production) with auto-swap enabled. The auto-swap handles warm-up automatically. If the swap fails, Azure automatically rolls back.
C.Use three slots: production, staging, and a new slot for the new version. Apply schema changes in the new slot, then swap new slot to staging, then staging to production. On failure, swap staging back to production.
D.Use two slots (staging and production). Apply schema changes in staging before swap. If swap fails, manually redeploy the old version to production.
AnswerA

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

Why this answer

Option C is correct because adding a third slot (e.g., 'test') allows you to apply schema changes in a non-production slot, swap test to staging to warm, then swap staging to production. If the final swap fails, you can swap back because the production slot still has the old code and old schema. Option A is wrong because swapping staging to production applies schema changes to production before the swap is complete, risking data loss on failure.

Option B is wrong because swapping staging for a new slot without schema changes doesn't address database rollback. Option D is wrong because swapping staging to production uses automatic swap with no rollback handling.

Practice this question →
127
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

Ephemeral environments are ideal for temporary testing.

Why this answer

Option D is correct because 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 →
128
MCQeasy

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

A.Use a self-hosted agent on an Azure VM with a custom image that includes Visual Studio and SDKs.
B.Deploy a container-based agent using a Docker image that includes Visual Studio.
C.Use a Microsoft-hosted agent with the 'windows-2022' image that includes Visual Studio Build Tools.
D.Provision a self-hosted agent on an Azure VM and install required components manually.
AnswerC

Pre-configured and automatically updated.

Why this answer

Option C is correct because Microsoft-hosted agents come with Visual Studio pre-installed and are automatically maintained. Option A is incorrect because custom images require maintenance. Option B is incorrect because Azure VM agents require manual updates.

Option D is incorrect because container agents need custom image management.

Practice this question →
129
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

Gradually routing traffic to a new version.

Why this answer

A canary deployment is a valid Kubernetes deployment pattern where a small subset of users (the 'canary') receives the new version of an application before a full rollout. This allows monitoring for issues with minimal impact, and Kubernetes supports this via techniques like multiple Deployments with shared labels and service mesh traffic splitting (e.g., Istio). It is a core strategy for progressive delivery in Kubernetes.

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 →
130
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

Agent needs to communicate with Azure DevOps.

Why this answer

Correct answers: A, C, D. A: agent must be registered with a PAT. C: agent machine needs network access to Azure DevOps.

D: agent must be configured with the account. B is wrong because you don't need a VM in Azure; self-hosted can be on-premises. E is wrong because Docker is optional.

Practice this question →
131
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

This role is required to fetch admin credentials.

Why this answer

The 'azure/aks-set-context' action requires the 'Azure Kubernetes Service Cluster User Role' or 'Azure Kubernetes Service Cluster Admin Role' to get cluster credentials. Contributor role does not grant permission to retrieve admin credentials. Option A is correct because the service principal needs the 'Azure Kubernetes Service Cluster Admin Role'.

Option B is incorrect as the action does not require cluster creation. Option C is incorrect because the issue is not about RBAC within the cluster. Option D is irrelevant.

Practice this question →
132
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

Artifacts ensure the same build is deployed across stages.

Why this answer

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

Option A is wrong because using separate pipelines for each microservice would increase complexity; you can use a single pipeline with matrix strategies. Option C is wrong because you should not store credentials in YAML; use variable groups or Azure Key Vault. Option E is wrong because Azure Pipelines supports YAML for both CI and CD.

Practice this question →
133
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

AcrPush role is required to push images.

Why this answer

Option B is correct because the Docker login action requires a service principal with AcrPush role. Option A is wrong because the action supports ACR. Option C is wrong because the action does not need admin credentials by default.

Option D is wrong because the action can handle private registries.

Practice this question →
134
MCQmedium

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

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

This task authenticates with Azure Artifacts.

Why this answer

Option B is correct because the NuGetAuthenticate task handles authentication to Azure Artifacts feeds. Option A is wrong because service connection is not directly used by NuGet tasks. Option C is wrong because PAT is less secure and not recommended.

Option D is wrong because the NuGet task has built-in support via NuGetAuthenticate.

Practice this question →
135
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 states the resource could not be found.

Why this answer

Option B is correct because the registry name might be incorrect or not exist. Option A is wrong because the CLI is available. Option C is wrong because authentication is not the issue if the error says not found.

Option D is wrong because build ID is a variable that resolves.

Practice this question →
136
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

Allows validation and retains previous config in staging.

Why this answer

Option D is correct because swap with preview allows you to validate before completing the swap, and the staging slot keeps the old production configuration. Option A is wrong because rolling update doesn't use slots. Option B is wrong because blue-green typically uses separate environments, not slots.

Option C is wrong because canary deploys traffic gradually, not slot swap.

Practice this question →
137
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

This validates the app before swapping, ensuring zero downtime.

Why this answer

Option C is correct because deploying to a staging slot, running tests, then swapping ensures zero downtime. Option A is incorrect because deploying to production directly causes downtime. Option B is incorrect because running tests before swap does not validate the deployed app.

Option D is incorrect because deploying to staging then deleting the slot loses the deployed app.

Practice this question →
138
MCQmedium

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

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

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

Why this answer

Using a multi-stage YAML pipeline with stage dependencies ensures stages run sequentially and stop on failure. Option A is wrong because parallel stages continue independently. Option B is wrong because pipeline decorators inject steps but don't handle dependencies.

Option C is wrong because manual approvals don't automatically stop on failure.

Practice this question →
139
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

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 →
140
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.
AnswerA

This enforces the use of the template and allows versioning and central updates.

Why this answer

Option C is correct because using a template repository with required templates and branch protection rules enforces the use of the mandatory steps. Option A is wrong because extensions can be disabled. Option B is wrong because a single pipeline cannot serve all repositories.

Option D is wrong because the YAML template repository approach with enforcement through branch policies is the recommended way.

Practice this question →
141
MCQeasy

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

A.pr:
B.schedules:
C.trigger: tags:
D.resources: pipelines:
AnswerC

This is the correct syntax to trigger on tags.

Why this answer

The 'tags' trigger under 'trigger' enables pipelines to run when specific tags are pushed.

Practice this question →
142
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

Why this answer

Option B is correct because 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 →
143
MCQeasy

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

A.Define the connection string as a plain variable in the YAML pipeline.
B.Hardcode the connection string in the deployment script and set the file as read-only.
C.Define the connection string as a secret variable in the pipeline's variable group or in the pipeline settings UI, and reference it as `$(connectionString)`.
D.Store the connection string in Azure Key Vault and use the 'Azure Key Vault' task to retrieve it at runtime.
AnswerC

Secret variables are encrypted and masked in logs.

Why this answer

Option B is correct because Azure Pipelines secret variables are encrypted and not exposed in logs. Option A is wrong because storing secrets in YAML variables directly exposes them. Option C is wrong because Azure Key Vault is more complex for simple secrets and requires additional permissions.

Option D is wrong because environment variables in the agent are visible to other processes.

Practice this question →
144
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

Correctly compares the full source branch ref.

Why this answer

Option C is correct because eq(variables['Build.SourceBranch'], 'refs/heads/main') compares the source branch to the main branch. Option A is wrong because 'main' is not a valid branch reference; Azure Pipelines uses 'refs/heads/main'. Option B is wrong because 'Build.SourceBranchName' returns 'main' but comparing to 'refs/heads/main' would fail.

Option D is wrong because 'startsWith' might match branches like 'maintenance'.

Practice this question →
145
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

A matrix strategy runs the same job on multiple agent pools in parallel, meeting the requirement efficiently.

Why this answer

Option B is correct because a strategy with a matrix allows running the same job on multiple agent pools in parallel. Option A is wrong because it duplicates the pipeline. Option C is wrong because it would create two separate jobs that are not easily managed.

Option D is wrong because multi-stage runs stages sequentially, not in parallel for this purpose.

Practice this question →
146
Multi-Selectmedium

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

Select 2 answers
A.Add a condition that checks if the source branch is 'main'.
B.Set the trigger on the stage to 'After stage' and select the previous stage.
C.Add a condition: 'eq(variables['Build.SourceBranch'], 'main')' to the stage.
D.Add a condition: 'succeeded()' to the stage.
E.Add a condition: 'eq(variables['Build.SourceBranch'], 'main')' with correct syntax.
AnswersA, B

Required to restrict to main branch.

Why this answer

Options A and D are correct. Option A ensures the stage runs after the previous stage succeeds. Option D ensures the build is from main branch.

Option B is wrong because it does not check main branch. Option C is wrong because it does not check stage success. Option E is wrong because 'eq(variables['Build.SourceBranch'], 'refs/heads/main')' is the correct syntax, not 'main' without refs/heads.

Practice this question →
147
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 allows instant switchover and rollback, minimizing downtime.

Why this answer

Option B is correct because blue-green deployment allows you to deploy a new version (green) alongside the old (blue) and switch traffic after validation, minimizing downtime. Option A (rolling update) gradually replaces pods but can cause downtime if the new version is broken. Option C (canary) only routes a small percentage of traffic, which is good for testing but not for minimizing downtime for the entire app.

Option D (recreate) causes full downtime.

Practice this question →
148
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

Service connections securely store credentials for Azure.

Why this answer

A service connection is needed for authentication, a YAML pipeline defines the process, and branch protection enforces quality. Option B is optional, D is for container scanning, E is for Kubernetes.

Practice this question →
149
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

This ensures the CI check must pass.

Why this answer

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

Practice this question →
150
Multi-Selecthard

Which THREE components are required to implement a GitHub Actions self-hosted runner on a Windows virtual machine? (Choose three.)

Select 3 answers
A.GitHub Actions runner application installed on the VM
B.A personal access token (PAT) for registering the runner
C.Windows operating system installed on the VM
D.IIS (Internet Information Services) running on the VM
E.Docker Desktop installed on the VM
AnswersA, B, C

The runner application executes jobs.

Why this answer

Options A, B, and D are correct. A is the runner agent. B is required for the runner to authenticate.

D is the operating system for hosting. C is wrong because GitHub Actions does not require a web server. E is wrong because Docker is optional.

Practice this question →
← PreviousPage 2 of 7 · 461 questions totalNext →

Ready to test yourself?

Try a timed practice session using only Build Release Pipelines questions.

Start 20-question session