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

376

Multi-Selecthard

Your team uses GitHub Actions to build a multi-container application. The build must produce container images that are scanned for vulnerabilities and signed. Which THREE actions are required in the workflow?

Select 3 answers

A.Use the docker/login-action to authenticate with Docker Hub.

B.Add a step to run a container scan tool like Trivy.

C.Add a step to sign the container image using cosign.

D.Use the actions/checkout action to checkout the code.

E.Use the docker/build-push-action to build and push images.

AnswersB, C, E

Adding a step to run Trivy scans the container image for known vulnerabilities in OS packages and application dependencies. Trivy integrates into GitHub Actions via aquasecurity/trivy-action, can fail the build based on severity thresholds, and generates a SARIF report for GitHub code scanning, making it the correct step for a security scanning requirement.

Why this answer

To produce container images that are scanned for vulnerabilities and signed, the workflow must include steps to scan the image (e.g., using Trivy), sign the image (e.g., using cosign), and build and push the image (e.g., using docker/build-push-action). Option A is not required because authenticating to Docker Hub specifically is not necessary if the target registry is not Docker Hub. Option D is not strictly required; checking out the code is a common first step but could be done differently or may already be available.

Practice this question →

377

MCQmedium

Your team uses a YAML-based build pipeline in Azure Pipelines. You need to ensure that the pipeline runs automatically when a pull request is created against the main branch, but only if the changes include modifications to the 'src/' directory. Which trigger configuration should you use?

A.trigger: - main; pr: none

B.trigger: none; pr: branches: include: - main paths: include: - src/*

C.trigger: none; pr: - main

D.pr: - main; trigger: - main

AnswerB

This is the correct configuration because it disables CI triggers entirely (trigger: none) and defines a PR trigger that runs only for pull requests targeting the main branch and only when changes occur under the src/ path. This filters out irrelevant PRs, ensuring the pipeline runs precisely when code in src/ is modified, saving resources and providing focused validation.

Why this answer

It sets `trigger: none` to disable CI triggers on commits, and uses a PR trigger with `branches: include: - main` and `paths: include: - src/*` to ensure the pipeline only runs automatically when a pull request targets the main branch and the changes include modifications to the 'src/' directory. This configuration meets the requirement of conditional PR-triggered builds based on file paths.

Exam trap

The trap here is that candidates often confuse CI triggers (`trigger`) with PR triggers (`pr`) and forget that path filtering must be explicitly specified under the PR trigger to restrict which file changes initiate the pipeline.

How to eliminate wrong answers

Option A is wrong because it sets a CI trigger on main (trigger: - main) and disables PR triggers (pr: none), so the pipeline would run on every commit to main, not only on pull requests. Option C is wrong because it sets `trigger: none` and `pr: - main` without a `paths` filter, so the pipeline would run on any pull request to main, regardless of whether changes are in 'src/'. Option D is wrong because it sets both CI and PR triggers on main without a `paths` filter, causing the pipeline to run on every commit to main and on every pull request to main, not only when 'src/' changes.

Practice this question →

378

MCQmedium

The pipeline above fails with: 'The deployment job 'DeployToProd' references environment 'Production' which does not exist.' What should you do to resolve this error?

A.Remove the 'environment' property from the deployment job.

B.Change the deployment strategy from 'runOnce' to 'rolling'.

C.Add a script step before the deployment job to create the environment.

D.Create an environment named 'Production' in Azure DevOps project settings.

AnswerD

The deployment job fails because it references an environment named 'Production' that does not yet exist in the Azure DevOps project. You must create the environment in Project Settings > Pipelines > Environments before running the pipeline; this provides the required resource for deployment job execution and enables tracking, approvals, and security on that environment.

Why this answer

The error indicates that the Azure DevOps pipeline references an environment named 'Production' that does not exist in the project. Environments must be explicitly created in Azure DevOps project settings before they can be used in deployment jobs. Option D resolves this by creating the required environment, allowing the deployment job to target it correctly.

Exam trap

The trap here is that candidates may think a script step can dynamically create the environment before the deployment job runs, but Azure DevOps validates environment references at pipeline compile time, not runtime, so the environment must already exist.

How to eliminate wrong answers

Option A is wrong because removing the 'environment' property would eliminate the deployment target, which is likely required for approvals, checks, and traceability; the pipeline would then fail to deploy to the intended stage. Option B is wrong because changing the deployment strategy from 'runOnce' to 'rolling' does not address the missing environment; it only alters how resources are updated during deployment, not the existence of the environment itself. Option C is wrong because environments cannot be created dynamically via a script step in a pipeline; they must be pre-created in Azure DevOps project settings or via the REST API, and a script step cannot create an environment that the deployment job references at parse time.

Practice this question →

379

MCQmedium

Your team is using Azure Pipelines to deploy a web application to Azure App Service. The application uses a configuration file (appsettings.json) that contains environment-specific settings. You need to manage these settings across development, staging, and production environments without exposing secrets in the source code. The pipeline should automatically replace the settings during deployment. What should you configure?

A.Use the 'File Transform' task in the release pipeline to replace tokens in the configuration file with variables defined in pipeline variable groups.

B.Create separate build configurations for each environment and use the 'Transform Web.config' task.

C.Use the 'Azure App Service Deploy' task with the 'Use Web Deploy' option and configure parameterization.

D.Set environment variables in the Azure App Service and read them in the application code.

AnswerA

The File Transform task is the correct choice because it directly performs token replacement in configuration files like appsettings.json, using variable values from pipeline variable groups. It supports both standard and secret variables, so connection strings and API keys can be injected at release time without exposing them in the repository.

Why this answer

Use the 'File Transform' task to substitute variables from pipeline variables or variable groups. Option B is incorrect because build configuration transforms are for .NET projects and require specific setup. Option C is incorrect because environment variables are not directly used for file transforms.

Option D is incorrect because Azure App Service application settings are for the runtime, not for transforming configuration files during deployment.

Practice this question →

380

MCQmedium

Refer to the exhibit. You have an Azure Pipelines YAML file for a .NET Core application. The pipeline is triggered on changes to the main branch, but only for files under src/. After a push to main that modifies a file in src/, the pipeline does not start. What is the most likely reason?

A.The branch filter is missing the 'refs/heads/' prefix.

B.The trigger configuration has a syntax error: 'include' should be 'includes'.

C.The variable 'buildConfiguration' is not defined at the top level.

D.The path filter 'src/*' does not match files in subdirectories of src/.

AnswerD

Path filters in Azure Pipelines follow minimatch semantics, where a single asterisk (*) matches characters within a path segment but not directory separators. Consequently, 'src/*' only matches files directly inside 'src' and does not match files in subdirectories like 'src/WebApplication/Program.cs', so the trigger will not fire for changes in subdirectories.

Why this answer

The path filter `src/*` uses a single asterisk, which only matches files directly within the `src/` directory, not files in subdirectories (e.g., `src/app/main.cs`). Azure Pipelines path filters require a double asterisk `src/**` to recursively match all files under `src/`. Since the modified file is in a subdirectory, the trigger condition is not met, and the pipeline does not start.

Exam trap

The trap here is that candidates confuse the single asterisk `*` with the recursive double asterisk `**`, assuming `src/*` matches all files under `src/` including subdirectories, which is incorrect in Azure Pipelines path filters.

How to eliminate wrong answers

Option A is wrong because branch filters in Azure Pipelines YAML triggers do not require the 'refs/heads/' prefix; the branch name alone (e.g., 'main') is sufficient. Option B is wrong because the correct keyword is 'include' (not 'includes'), and 'include' is valid syntax for path filters in YAML triggers. Option C is wrong because the variable 'buildConfiguration' is defined later in the YAML (under variables) and does not need to be at the top level; its absence does not prevent the trigger from firing.

Practice this question →

381

MCQmedium

Your organization uses GitHub Actions for CI/CD. You have a workflow that deploys to Azure App Service. The deployment uses a publish profile secret stored as a GitHub secret. You want to improve security by using OpenID Connect (OIDC) to authenticate to Azure without storing secrets. What should you do?

A.Remove the secret and use Azure AD Managed Identity directly from the GitHub runner.

B.Configure the GitHub workflow to use the 'azure/login' action with OIDC, and set up a federated identity credential in Microsoft Entra ID for the GitHub environment.

C.Replace the publish profile secret with an Azure service principal secret stored as a GitHub secret.

D.Use the 'Azure App Service Deploy' task with the 'Publish Profile' parameter set to an empty string.

AnswerB

The 'azure/login' action with OIDC exchanges GitHub's OIDC token for an Azure AD access token by using a federated identity credential configured in Microsoft Entra ID for the GitHub environment. You create the credential with the correct subject identifier (e.g., repo:owner/repo:environment:prod) so that GitHub's token is trusted, and the action automatically retrieves the token without requiring a client secret. This eliminates long-lived secrets, enables automatic token rotation, and is the recommended secure pattern for GitHub Actions to Azure deployments.

Why this answer

Configuring OIDC with Microsoft Entra ID (formerly Azure AD) using a federated identity credential for the GitHub environment allows token-based authentication without storing secrets. Option A is incorrect because Azure Managed Identity cannot be used directly from a GitHub runner; Managed Identity is designed for Azure-hosted resources, not external runners. Option C is incorrect because replacing the publish profile secret with a service principal secret still requires storing a secret, which does not improve security compared to OIDC.

Option D is incorrect because setting the 'Publish Profile' parameter to an empty string does not enable OIDC authentication; the deployment would fail due to missing credentials.

Practice this question →

382

MCQmedium

You have a build pipeline that produces several artifacts. You need to publish these artifacts to Azure Artifacts feed, but only if the build succeeds. Which task should you add to the pipeline?

A.Add a 'Publish Build Artifacts' task and then a 'Universal Publish' task.

B.Add an 'npm publish' task to publish packages.

C.Add a 'Copy Files' task to copy artifacts to the feed location.

D.Add a 'NuGet push' task to push packages to the feed.

AnswerA

Correct: Publish build artifacts first, then publish to Azure Artifacts feed.

Why this answer

The 'Publish Build Artifacts' task makes the build outputs available as pipeline artifacts, and the 'Universal Publish' task is the correct way to publish those artifacts to an Azure Artifacts feed (which supports Universal Packages). This combination ensures artifacts are only published after the build succeeds because both tasks run in the pipeline's job sequence, and by default, subsequent tasks execute only if the previous task succeeded.

Exam trap

The trap here is that candidates often assume any package-specific task (npm, NuGet) can publish to Azure Artifacts, but the question asks for publishing 'several artifacts' (not just one package type), so the Universal Publish task is the only correct choice for a generic, multi-artifact scenario.

How to eliminate wrong answers

Option B is wrong because 'npm publish' is specific to npm packages and cannot publish arbitrary build artifacts to an Azure Artifacts feed. Option C is wrong because 'Copy Files' only copies files to a local or network path, not to an Azure Artifacts feed; it does not perform any publish operation. Option D is wrong because 'NuGet push' is limited to NuGet packages and cannot handle other artifact types like Universal Packages or Maven artifacts.

Practice this question →

383

MCQmedium

Your organization uses GitHub for source control and Azure Pipelines for CI/CD. You need to implement a pipeline that automatically builds and tests a Python application on every pull request to the main branch, but only if the pull request is from a fork. The pipeline must also publish test results as a build artifact. What should you do?

A.Use GitHub Actions to build and test the application on PRs, and then trigger Azure Pipelines for deployment.

B.Use a scheduled trigger to run the pipeline every hour and check for new PRs from forks.

C.Set up a pipeline completion trigger on the main branch that runs the pipeline after every merge.

D.Configure a branch protection rule on main that requires status checks from Azure Pipelines. Set the pipeline trigger to 'Pull request validation' and include a condition to run only if the pull request is from a fork.

AnswerD

This correctly uses Azure Pipelines as the PR validation engine: setting the pipeline trigger to 'Pull request validation' makes Azure Pipelines run on each PR, and the condition limits it to fork PRs. The branch protection rule on main then requires the Azure Pipelines status check to pass before the PR can be merged, enforcing validation as a merge gate.

Why this answer

It configures a branch protection rule on the main branch that requires status checks from Azure Pipelines. By setting the pipeline trigger to 'Pull request validation' and including a condition to run only if the pull request is from a fork, the pipeline automatically builds and tests the Python application on every pull request from a fork to main. The pipeline can also publish test results as a build artifact.

Option A is incorrect because GitHub Actions is not Azure Pipelines; the requirement specifies using Azure Pipelines for CI/CD. Option B is incorrect because a scheduled trigger polling for PRs is inefficient and not the proper way to handle PR events. Option C is incorrect because a pipeline completion trigger runs after a merge, not on pull requests.

Practice this question →

384

MCQeasy

Your team uses Azure Pipelines to build a Node.js application. The build pipeline runs linting, unit tests, and creates a production build. You want to ensure that the pipeline fails if the test coverage drops below 80%. You need to implement this check. What should you do?

A.Configure a pipeline variable 'CoverageThreshold' and use it in a gate.

B.Set a branch policy that requires code coverage to be at least 80%.

C.Use the 'Visual Studio Test' task with code coverage enabled and set the 'Minimum coverage' option.

D.Add a 'Publish Test Results' task with code coverage enabled, then use a 'Script' task that reads the coverage report and fails if below 80%.

AnswerD

This is the correct pattern: the Publish Test Results task accepts coverage output (e.g., Cobertura XML from Istanbul/nyc) and publishes it to the pipeline, and then a subsequent Script task (PowerShell, Bash, etc.) parses the generated report—such as reading the 'coverage-summary.json' or the Cobertura XML—and explicitly fails the build if the line coverage is below 80%. This gives you arbitrary custom logic to enforce the threshold exactly as required.

Why this answer

The 'Publish Test Results' task can publish code coverage reports, and a subsequent script task can parse the report (e.g., using a tool like c8 or nyc) and exit with a non-zero code if coverage is below 80%, causing the pipeline to fail. Option A is incorrect because a pipeline variable alone cannot enforce coverage thresholds; you need a task that checks the coverage. Option B is incorrect because branch policies can enforce code review requirements but not specific code coverage percentages from build results.

Option C is incorrect because the 'Visual Studio Test' task is designed for .NET applications, not Node.js; it does not work with Node.js coverage reports.

Practice this question →

385

Multi-Selectmedium

Which THREE of the following are true about GitHub Actions self-hosted runners?

Select 3 answers

A.They can have custom software installed.

B.They are automatically scaled by GitHub.

C.They are free and do not incur any costs.

D.They can run on Windows, Linux, or macOS.

E.They can access on-premises resources.

AnswersA, D, E

Self-hosted runners are machines you control, so you can pre-install any custom software, tools, or libraries required by your workflows, unlike GitHub-hosted runners which have a fixed set of pre-installed software.

Why this answer

GitHub Actions self-hosted runners are machines you manage, allowing you to install any custom software, libraries, or tools required by your workflows. Unlike GitHub-hosted runners, which have a fixed set of pre-installed software, self-hosted runners give you full administrative control over the environment, enabling you to meet specific build or test dependencies.

Exam trap

The trap here is that candidates often assume self-hosted runners are entirely free and automatically managed by GitHub, overlooking the operational overhead and infrastructure costs, while also forgetting that GitHub does not handle scaling for self-hosted runners.

Practice this question →

386

MCQeasy

Your team uses Azure Repos and wants to trigger a pipeline automatically when a pull request is created targeting the main branch. The pipeline should run validations and report the status to the PR. Which trigger type should you configure?

A.Path filter

B.Scheduled trigger

C.PR trigger

D.CI trigger

AnswerC

PR triggers automatically start a pipeline when a pull request is created, updated, or reopened against a target branch, evaluating the merged result of the source and target branches. In Azure Pipelines, a PR trigger is the correct event type to validate changes before merging, and it can be configured specifically for individual or multiple branches, unlike CI triggers which only fire on direct pushes.

Why this answer

A PR trigger is the correct choice because it specifically initiates a pipeline when a pull request is created or updated against a target branch (main). This allows the pipeline to run validations (e.g., builds, tests, linting) and report the status back to the PR via the Azure Repos status API, enabling branch protection policies to block merging if checks fail.

Exam trap

The trap here is that candidates often confuse CI triggers (which run on branch pushes) with PR triggers (which run on pull request events), especially when they see 'trigger on main branch' and incorrectly assume a CI trigger will handle PR validation.

How to eliminate wrong answers

Option A is wrong because a path filter is not a trigger type; it is a configuration option used within CI or PR triggers to limit execution based on file changes in specific paths. Option B is wrong because a scheduled trigger runs pipelines at predefined times (e.g., nightly builds) and does not respond to pull request events. Option D is wrong because a CI trigger runs when code is pushed to a branch (e.g., main), not when a PR is created; it does not automatically report status to a PR and is intended for continuous integration on commits.

Practice this question →

387

MCQeasy

You are configuring a build pipeline for a JavaScript application. You want to run linting, unit tests, and build steps only when changes are pushed to the 'develop' branch. Which trigger should you configure?

A.Enable pull request trigger.

B.Enable scheduled trigger.

C.Enable continuous integration (CI) trigger without branch filters.

D.Enable CI trigger with a branch filter for 'develop'.

AnswerD

Enabling CI with a branch filter for 'develop' ensures the pipeline is triggered automatically on every push to the develop branch, while ignoring pushes to other branches. This provides immediate build validation for changes integrated into the mainline, aligning exactly with the requirement of building on direct pushes to develop.

Why this answer

Enabling a CI trigger with a branch filter for 'develop' ensures that the pipeline automatically runs linting, unit tests, and build steps only when changes are pushed to the 'develop' branch. This matches the requirement precisely, as CI triggers respond to push events, and the branch filter restricts execution to the specified branch.

Exam trap

The trap here is that candidates often confuse CI triggers with pull request triggers, mistakenly thinking a CI trigger without branch filters is sufficient, but the branch filter is essential to restrict execution to a specific branch.

How to eliminate wrong answers

Option A is wrong because pull request triggers run when a PR is created or updated, not when changes are pushed directly to a branch; this would not satisfy the requirement to run on pushes to 'develop'. Option B is wrong because scheduled triggers run at specified times regardless of code changes, which does not align with the requirement to trigger only on pushes. Option C is wrong because enabling a CI trigger without branch filters would cause the pipeline to run on pushes to any branch, including feature branches, not just 'develop'.

Practice this question →

388

Multi-Selecthard

Which THREE factors should you consider when designing a release pipeline for a critical production application? (Choose three.)

Select 3 answers

A.Use of service principal with least privilege

B.Rollback strategy

C.Single environment deployment

D.Deployment health monitoring

E.Approval gates before production deployment

AnswersB, D, E

A rollback strategy is essential because even with thorough testing in lower environments, production failures can still occur; a well-defined process to revert to the last known good artifact, whether through redeployment or automated restore, minimizes mean time to recovery (MTTR) and reduces customer impact.

Why this answer

A release pipeline for a critical production application must include a rollback strategy (e.g., deployment slots or redeploying a previous artifact) to recover quickly from failed releases, deployment health monitoring (e.g., Application Insights, Azure Monitor) to detect issues early and trigger rollbacks or alerts, and approval gates before production deployment to ensure manual or automated checks are passed. These three factors together minimize downtime and ensure controlled, safe releases.

Exam trap

The trap here is that candidates confuse security best practices (like service principal least privilege) with release pipeline design factors, or they mistakenly think a single environment is acceptable for critical apps, ignoring the necessity of staging and rollback capabilities.

Practice this question →

389

MCQmedium

Your team uses Azure Pipelines to deploy a Docker container to Azure Kubernetes Service (AKS). The pipeline builds a Docker image, pushes it to Azure Container Registry (ACR), and then runs a deployment to AKS. You want to ensure that the deployment uses the exact image that was built in the same pipeline run. Which approach should you use?

A.Use two separate pipelines: one for build/push, one for deploy, and share the image tag via a variable group.

B.Use a single task for build and push, and rely on ACR's internal pull-through cache.

C.Generate a unique tag (e.g., Build.BuildId) and pass it to both the Docker build and Kubernetes manifest via variable substitution.

D.Tag the image as 'latest' and reference it in the Kubernetes manifest.

AnswerC

Using Build.BuildId (or another unique identifier) as the image tag makes each build's image reference immutable and traceable, and when you inject that same tag into the Kubernetes manifest during variable substitution, the deployment is guaranteed to pull the exact artifact produced by the current pipeline run. This eliminates tag-mutation races and provides clear auditability.

Why this answer

Using a unique tag like Build.BuildId ensures that the exact image built in the pipeline is referenced in the Kubernetes manifest. This prevents deployment from accidentally using a stale or overwritten image, as the tag is unique per run and passed consistently via variable substitution from the Docker build to the deployment YAML.

Exam trap

The trap here is that candidates often choose the 'latest' tag (Option D) because it seems simpler, but they overlook that 'latest' is mutable and can cause deployment of a different image than the one built in the same pipeline run.

How to eliminate wrong answers

Option A is wrong because using two separate pipelines with a variable group introduces a race condition and does not guarantee that the deploy pipeline uses the exact image from the same build run; the variable group could be overwritten by another run. Option B is wrong because relying on ACR's internal pull-through cache does not enforce image identity; it only caches layers and does not tie the deployment to the specific build output. Option D is wrong because tagging the image as 'latest' is mutable and can be overwritten by subsequent builds, leading to deployment of a different image than the one built in the same pipeline run.

Practice this question →

390

MCQeasy

You are setting up a release pipeline for a web application. The pipeline must deploy to three environments: Dev, Test, and Prod. The deployment to Prod must be triggered only after a successful deployment to Test and after a manual approval. How should you configure the pipeline?

A.Add a manual intervention task before the Prod deployment in the pipeline.

B.Use a condition on the Prod stage to require success from Test and manual intervention variable.

C.Schedule the Prod deployment to run after Test, and require manual trigger.

D.Add a pre-deployment approval gate on the Prod environment.

AnswerD

A pre-deployment approval gate is configured directly on the Prod environment in Azure Pipelines, and it forces the pipeline to pause before the deployment job to that environment begins. Designated approvers must explicitly approve the release, which provides a formal, auditable sign-off that blocks the Prod stage from starting until the required approval is granted.

Why this answer

Pre-deployment approval gates on the Prod environment block the release until manual approval is granted, and a stage condition ensures it runs only after successful Test deployment. Option A is wrong because manual intervention tasks are not designed for approvals and do not integrate with pipeline stages as seamlessly. Option B is wrong because conditions can't enforce manual approval; they only evaluate at runtime.

Option C is wrong because scheduling doesn't provide manual approval; triggers can be manual but not combined with stage success conditions effectively.

Exam trap

Candidates often confuse manual intervention tasks with approval gates. Pre-deployment approvals are the proper Azure DevOps feature for manual sign-off on a stage.

Practice this question →

391

MCQhard

Your Azure DevOps pipeline deploys to multiple environments (Dev, Test, Prod) using YAML multi-stage pipelines. The Prod deployment requires manual approval. However, the approval gate shows 'Pending' even after an authorized user approves. What is the most likely cause?

A.The pipeline run was triggered by a PR merge, and the approval needs to be re-applied after the build completes.

B.The build pipeline includes a step that modifies the approval settings.

C.The approval gate is configured to require approval on the latest commit, but a newer commit was pushed after the approval.

D.The approver is not a member of the security group defined in the approval settings.

AnswerC

Correct: Environment approval gates are configured to evaluate the latest commit of the pipeline run; if a newer commit is pushed after the approval was granted, the gate detects the changed commit and requires re-approval before the deployment proceeds.

Why this answer

In Azure DevOps, approvals are associated with a specific pipeline run and its commit. When a new commit is pushed after an approval, it triggers a new pipeline run. The new run has its own approval requirement, so it remains 'Pending' until approved.

The previous approval does not carry over to the new run.

Exam trap

The trap is that candidates assume an approval applies to the stage or environment indefinitely, rather than to a specific pipeline run/commit. A new commit generates a new run with a new pending approval.

How to eliminate wrong answers

Option A is wrong because PR merges trigger the pipeline, but the approval gate is evaluated after the build completes; re-applying approval is not required unless a new commit is pushed. Option B is wrong because build pipeline steps cannot modify approval settings; approval settings are defined at the environment or stage level in YAML, not altered by pipeline tasks. Option D is wrong because if the approver were not a member of the security group, the approval would fail or be rejected, not remain in 'Pending' state.

Practice this question →

392

MCQhard

You are designing a release pipeline for a critical application that requires zero-downtime deployments. The application runs on Azure Kubernetes Service (AKS) with multiple replicas. You are using Azure Pipelines with a canary deployment strategy. What is the best approach to gradually shift traffic to the new version while monitoring for errors?

A.Use a service mesh like Istio to route a percentage of traffic to the new version.

B.Use Azure Application Gateway as an ingress controller with weighted backend pools.

C.Use the AKS rolling update strategy with max surge.

D.Deploy to a staging environment, then swap VIPs with production.

AnswerA

Istio enables precise traffic routing for canary deployments.

Why this answer

Using a service mesh like Istio allows granular traffic splitting between versions, enabling gradual canary deployments with real-time monitoring. Option B is incorrect: Azure Application Gateway can route traffic to backends, but it works at the ingress level and cannot easily shift traffic at the pod level without additional configuration; it's less flexible than a service mesh for canary. Option C is incorrect: AKS rolling update gradually replaces pods but does not split traffic between old and new; all traffic goes to the new version once a pod is updated, making it unsuitable for gradual traffic shift.

Option D is incorrect: VIP swap is a blue-green deployment, which switches all traffic at once, not gradually.

Practice this question →

393

MCQmedium

Your build pipeline uses a self-hosted agent. The agent is running low on disk space. You need to clean up the agent's working directory after each build. Which option should you configure in the pipeline?

A.Set the 'Clean' option to 'Sources' in the pipeline settings.

B.Add a 'Delete Files' task at the end of the pipeline to delete the sources directory.

C.Add a 'Cleanup' task from the marketplace to clean the agent.

D.Use the 'clean' parameter in the checkout step of the YAML pipeline.

AnswerD

Correct: 'clean: true' cleans the working directory before checkout.

Why this answer

The `clean` parameter in the YAML checkout step is the native, built-in way to instruct the agent to delete the sources directory before or after the build. Setting `clean: true` or `clean: all` ensures the working directory is purged, directly addressing the low disk space issue without requiring additional tasks or marketplace extensions.

Exam trap

The trap here is that candidates often confuse the classic pipeline 'Clean' setting (which is a pre-build option) with the YAML `clean` parameter (which can be configured to run after the build), leading them to incorrectly select Option A.

How to eliminate wrong answers

Option A is wrong because the 'Clean' option set to 'Sources' in the classic pipeline settings only cleans the sources directory before the build starts, not after each build, and it does not apply to YAML pipelines. Option B is wrong because adding a 'Delete Files' task at the end of the pipeline is an extra, non-native step that can fail if the agent lacks permissions or if the sources directory is locked, and it is not the standard or recommended approach for cleaning the working directory. Option C is wrong because a 'Cleanup' task from the marketplace is unnecessary overhead; the built-in `clean` parameter in the checkout step provides the same functionality without relying on external extensions.

Practice this question →

394

MCQhard

Your release pipeline uses Azure Kubernetes Service (AKS) and Helm charts. You need to roll back to a previous release quickly if the new release fails health checks. What is the BEST approach?

A.Manually redeploy the previous Helm chart version.

B.Use a canary deployment strategy.

C.Use Helm rollback command.

D.Use a Kubernetes Deployment rollout undo.

AnswerC

The Helm rollback command is the correct approach because Helm maintains an ordered release history for each release name, with every deployment sequence stored as an immutable revision that includes the rendered manifests, values, and metadata. Executing `helm rollback <RELEASE> <REVISION>` instructs Helm to perform an in-place upgrade using the exact templates and values from that prior revision, thereby reinstating the known-good configuration atomically and quickly. This operation is fully tracked by Helm, incrementing to a new revision, so the release state and history remain internally consistent for subsequent upgrades or further rollbacks. Unlike manual redeployments or kubectl-level actions, Helm rollback does not require reconstructing old charts or reconciling drift—it simply reapplies the previously successful applied state.

Why this answer

Helm provides a built-in `helm rollback <release> <revision>` command that reverts a release to a previous revision in a single, atomic operation. This is the fastest and most reliable method for rolling back a failed Helm-based deployment on AKS, as it directly restores the exact Kubernetes manifests and configuration from the specified revision without manual intervention.

Exam trap

The trap here is that candidates confuse Kubernetes-native rollback (`kubectl rollout undo`) with Helm's release-level rollback, forgetting that Helm manages releases as a unit and that using `kubectl` directly breaks Helm's revision history and can leave the release in a broken state.

How to eliminate wrong answers

Option A is wrong because manually redeploying the previous Helm chart version is error-prone, slow, and requires the operator to locate and re-run the exact previous chart and values, which defeats the purpose of a quick rollback. Option B is wrong because a canary deployment strategy is a progressive delivery technique used to test a new release with a subset of traffic before full rollout, not a rollback mechanism; it does not revert a failed release but rather mitigates risk during rollout. Option D is wrong because `kubectl rollout undo` works on a Kubernetes Deployment object directly, but when using Helm, the Deployment is managed as part of a Helm release; using `kubectl rollout undo` bypasses Helm's release tracking, leading to state inconsistency between the Helm release history and the actual cluster state.

Practice this question →

395

MCQhard

Your release pipeline deploys to multiple environments (Dev, QA, Prod) using approvals. You need to ensure that the deployment to Prod only proceeds if the deployment to QA succeeded and an approval is granted. Which combination of triggers and pre-deployment conditions should you configure?

A.Set the trigger on Prod to 'Automatic' and add a post-deployment approval on QA.

B.Set the trigger on Prod to 'After release' and add a pre-deployment approval on Prod.

C.Set the trigger on Prod to 'Manual only' and add a pre-deployment approval on Prod.

D.Set the trigger on Prod to 'After stage' and select QA as the stage, and add a pre-deployment approval on Prod.

AnswerD

Setting the Prod trigger to 'After stage' and selecting QA creates a dependency where the Prod deployment is queued only after the QA stage completes successfully, so a QA failure will prevent Prod from starting. Adding a pre-deployment approval on Prod then provides the required human authorization before the actual deployment, ensuring both QA success and an explicit approval gate.

Why this answer

It configures the Prod stage trigger to 'After stage' with QA selected as the preceding stage, ensuring that the release to Prod only starts after QA completes successfully. Adding a pre-deployment approval on Prod then enforces that a manual approval is granted before the deployment actually begins. This combination satisfies both conditions: dependency on QA success and required approval.

Exam trap

The trap here is that candidates often confuse 'After release' (which triggers based on release creation, not stage completion) with 'After stage' (which triggers based on a specific preceding stage's outcome), leading them to pick Option B or A without recognizing the need for explicit stage dependency.

How to eliminate wrong answers

Option A is wrong because setting the trigger on Prod to 'Automatic' would cause Prod to deploy immediately after the release is created, without waiting for QA to succeed, and a post-deployment approval on QA does not gate the Prod deployment. Option B is wrong because 'After release' trigger starts Prod after the release is created, not after QA completes, so it ignores the QA stage outcome. Option C is wrong because 'Manual only' trigger requires a manual start but does not enforce that QA must succeed first; the pre-deployment approval only adds an approval gate without the stage dependency.

Practice this question →

396

MCQeasy

You are configuring a release pipeline in Azure DevOps to deploy to multiple environments (dev, test, prod). You need to ensure that the production deployment requires manual approval from the release manager. What should you configure?

A.Set pre-deployment approvals on the production stage.

B.Add a manual intervention task before the production deployment.

C.Set post-deployment approvals on the test stage.

D.Use a condition on the production stage to check a variable.

AnswerA

Pre-deployment approvals on the production stage create a formal gate before the stage begins, requiring designated approvers to explicitly authorize the release. This is the correct mechanism because it applies to the entire stage, ensuring no production deployment occurs without human sign-off.

Why this answer

Pre-deployment approvals on the production stage enforce manual sign-off before any deployment to that environment begins. This ensures the release manager must explicitly approve the deployment, meeting the requirement for manual approval on production. Azure DevOps stages support pre-deployment and post-deployment approval gates, with pre-deployment being the correct choice for controlling when a stage starts.

Exam trap

The trap here is confusing a manual intervention task (which pauses within a stage) with a pre-deployment approval (which gates the start of a stage), leading candidates to incorrectly select the task-based option instead of the stage-level approval.

How to eliminate wrong answers

Option B is wrong because a manual intervention task is a step within a stage that pauses execution, but it does not prevent the stage from starting; the release would already have been deployed to the stage before the task runs, which does not satisfy the requirement to gate the production deployment itself. Option C is wrong because post-deployment approvals on the test stage control what happens after test completes, not before production starts; they cannot block the production deployment from beginning. Option D is wrong because a condition on the production stage to check a variable can control stage execution based on a variable value, but it cannot enforce manual human approval; it is an automated check, not a manual approval gate.

Practice this question →

397

MCQeasy

You are setting up a GitHub Actions workflow to deploy an Azure Resource Manager (ARM) template. The workflow must run whenever a pull request is opened against the main branch. Which trigger should you use?

A.pull_request: branches: [main] types: [opened]

B.pull_request_target: branches: [main]

C.workflow_dispatch

D.push: branches: [main]

AnswerA

This trigger fires automatically when a pull request targeting the main branch is opened, using the code from the pull request's merge commit rather than the base branch. It is the correct choice for deploying the ARM template proposed in the PR, because it runs as a pre-merge validation and uses the PR's changes.

Why this answer

The `pull_request` trigger with `branches: [main]` and `types: [opened]` ensures the workflow runs only when a pull request targeting the `main` branch is newly opened. This is the correct trigger for the stated requirement. Note that `pull_request` events from forks run with limited permissions and do not have access to repository secrets by default, which is a safety measure.

If secrets are required for deployment, additional configuration such as using `pull_request_target` (with caution) or environment-scoped secrets would be necessary, but the trigger itself remains `pull_request`.

Exam trap

Candidates often confuse `pull_request_target` with `pull_request`. `pull_request_target` runs in the context of the base repository and has access to secrets, but it should be used with extreme caution because it can be exploited via malicious PRs. `pull_request` is the standard, safer trigger for PR events and does not expose secrets to untrusted forks; however, it also does not allow access to secrets for fork PRs without additional mechanisms.

How to eliminate wrong answers

Option B is wrong because `pull_request_target` runs in the context of the base branch (main) with full write permissions and secret access, which is intended for safe handling of PRs from forks but is not the standard trigger for deploying ARM templates on PR open; it also lacks the `types: [opened]` filter, so it would run on all PR events (synchronize, reopened, etc.). Option C is wrong because `workflow_dispatch` requires manual triggering via the GitHub UI or API, not automatic execution when a PR is opened. Option D is wrong because `push: branches: [main]` triggers on direct commits or merges to main, not on pull request creation, so it would deploy after a merge rather than when the PR is opened.

Practice this question →

398

MCQeasy

Your team needs to automatically run a pipeline whenever a pull request is created in GitHub. Which trigger should you configure in Azure Pipelines?

A.Pipeline completion trigger

B.Scheduled trigger

C.Pull request trigger

D.Continuous integration trigger

AnswerC

A pull request trigger automatically runs a pipeline whenever a pull request is created, updated, or reopened against the target branch, enabling validation of the proposed changes before merge. This directly matches the requirement to run a pipeline whenever a PR is created, making it the correct choice.

Why this answer

Azure Pipelines provides a dedicated pull request trigger that automatically starts a pipeline when a pull request is created or updated in GitHub. This trigger validates proposed changes before merging, ensuring code quality and preventing broken builds from entering the main branch.

Exam trap

The trap here is that candidates often confuse the continuous integration trigger (which runs on branch pushes) with the pull request trigger, failing to recognize that CI triggers do not activate on pull request creation events unless the PR branch is also pushed to, which is not the same as the PR event itself.

How to eliminate wrong answers

Option A is wrong because a pipeline completion trigger starts a pipeline when another pipeline finishes, not in response to a GitHub pull request event. Option B is wrong because a scheduled trigger runs pipelines at specified times (e.g., nightly builds) and cannot react to real-time pull request creation. Option D is wrong because a continuous integration trigger runs on pushes to branches (e.g., main or feature branches), not specifically on pull request creation; it would run on every commit push, not just when a PR is opened.

Practice this question →

399

MCQmedium

You are designing a release pipeline that deploys to multiple environments (dev, test, prod) with approval gates between each. You need to ensure that the same build artifact is deployed to all environments. Which strategy should you use?

A.Use a multi-stage YAML pipeline with a separate artifact for each stage.

B.Create a separate build pipeline for each environment to ensure environment-specific configurations.

C.Use a single build pipeline but trigger a new build for each environment.

D.Use a single build pipeline and promote the same build artifact through each environment.

AnswerD

Promoting the same artifact ensures consistency across environments.

Why this answer

Promoting the same build artifact through each environment ensures consistency and traceability. In Azure Pipelines, a single build produces one immutable artifact; deploying that same artifact across dev, test, and prod eliminates the risk of environment-specific build variations. Approval gates between stages control the promotion, while the artifact remains unchanged.

Exam trap

The trap here is that candidates confuse environment-specific configuration (which is handled by variable groups or pipeline variables) with the need for separate build artifacts, leading them to incorrectly select options that create multiple builds instead of promoting a single artifact.

How to eliminate wrong answers

Option A is wrong because using a separate artifact for each stage breaks the principle of deploying the same build across environments, introducing potential inconsistencies and making it impossible to guarantee that the exact same bits reach production. Option B is wrong because creating a separate build pipeline for each environment defeats the purpose of a unified release pipeline; it forces rebuilding for each environment, which can introduce different compilation results or dependency versions. Option C is wrong because triggering a new build for each environment means each environment receives a different artifact, violating the requirement to deploy the same build artifact to all environments.

Practice this question →

400

MCQmedium

Your team uses GitHub Actions for CI/CD. You want to reuse a workflow across multiple repositories without duplicating code. Which approach should you use?

A.Store the workflow in a shared repository and use environment secrets to share credentials.

B.Create a reusable workflow in a central repository and reference it using 'uses: owner/repo/.github/workflows/workflow.yml@ref'.

C.Create a composite action and reference it from each workflow.

D.Create a workflow template in the organization's .github repository.

AnswerB

A reusable workflow is a YAML file in another repository that declares `on: workflow_call`, and it is referenced from a calling workflow using `uses: owner/repo/.github/workflows/workflow.yml@ref` where `ref` can be a branch, tag, or SHA. This allows centralized management of CI/CD logic, versioned reuse, and parameterized inputs/secrets across multiple repositories within your organization.

Why this answer

GitHub Actions supports reusable workflows that allow you to define a workflow in a central repository and reference it from other repositories using the 'uses' syntax with the format 'owner/repo/.github/workflows/workflow.yml@ref'. This eliminates code duplication while maintaining a single source of truth for the workflow logic, and the referenced workflow can be triggered by events in the caller repository.

Exam trap

The trap here is that candidates often confuse reusable workflows with composite actions or workflow templates. Reusable workflows allow you to reference a complete workflow (jobs/steps) from a central repository, but they do not define their own triggers; they are invoked via `workflow_call` from a caller workflow.

How to eliminate wrong answers

Option A is wrong because storing a workflow in a shared repository does not enable reuse without duplication; environment secrets only handle credential sharing, not workflow logic reuse, and you would still need to copy the workflow file into each repository. Option C is wrong because a composite action is designed to encapsulate a series of steps (a reusable action), not an entire workflow with triggers, jobs, and steps; it cannot define workflow-level events like 'on: push' or 'on: pull_request'. Option D is wrong because a workflow template in the organization's .github repository provides a starting point for new workflows but does not allow referencing an existing workflow from another repository; each repository must still maintain its own copy of the workflow file.

Practice this question →

401

Multi-Selecteasy

Which TWO of the following are benefits of using deployment slots in Azure App Service? (Select TWO.)

Select 2 answers

A.Automatic rollback on failure.

B.Independent scaling of each slot.

C.Zero-downtime deployments.

D.Validate changes in a staging environment before production.

E.Geographic redundancy.

AnswersC, D

By deploying to a staging slot and then performing a swap, you can instantly redirect production traffic to the new version with no downtime, as the swap operation is atomic and warm-up can be handled before the slot receives production traffic.

Why this answer

Deployment slots enable zero-downtime deployments (C) by allowing you to swap a staging slot with the production slot. The swap operation warms up the target slot's application before routing traffic, ensuring no requests are dropped. This is a core feature of Azure App Service for safe, continuous delivery.

Exam trap

The trap here is that candidates confuse the ability to swap slots with automatic rollback (A) or assume slots provide independent scaling (B), when in fact slots share the same plan and rollback requires manual intervention.

Practice this question →

402

MCQmedium

Refer to the exhibit. You are reviewing an ARM template used in an Azure Pipeline deployment. Which security concern should you address?

A.The VM size is too small for production

B.The apiVersion is outdated

C.The admin password is hardcoded in the template

D.The location parameter has a default value

AnswerC

Hardcoding the admin password as a plaintext string in the ARM template or its default parameters exposes the secret to anyone with read access to the source repository or deployment history. The template should accept the password via a secureString parameter and reference an Azure Key Vault secret, or use a managed identity and guest configuration to set credentials without embedding them.

Why this answer

The admin password is hardcoded in plain text in the ARM template, which is a significant security vulnerability. Passwords should be stored securely using Azure Key Vault or referenced as secure parameters. Option A is incorrect because VM size is not a security concern.

Option B is incorrect because the apiVersion is valid. Option D is incorrect because a default value for location is acceptable.

Practice this question →

403

Multi-Selecthard

You are creating a YAML pipeline that builds a .NET Core application. The pipeline must use a multi-stage build with separate stages for 'Build', 'Test', and 'Deploy'. The 'Deploy' stage should only run if both 'Build' and 'Test' succeed. Which two conditions can you use to achieve this? (Select all that apply.)

Select 2 answers

A.In the Deploy stage, set 'dependsOn: [Build, Test]'

B.In the Deploy stage, set 'condition: and(succeeded('Build'), succeeded('Test'))'

C.In the Deploy stage, set 'condition: succeeded()' and 'dependsOn: [Build, Test]'

D.In the Deploy stage, set 'dependsOn: [Build, Test]' and 'condition: stageDependencies.Build.result == 'Succeeded''

AnswersA, C

Setting 'dependsOn: [Build, Test]' is correct because the default stage condition is 'succeeded()', which evaluates to true only if all explicitly listed dependency stages (Build and Test) complete successfully. This ensures Deploy runs only after both stages succeed without requiring an explicit condition.

Why this answer

Setting 'dependsOn: [Build, Test]' in the Deploy stage ensures that the Deploy stage only starts after both the Build and Test stages have completed. By default, a stage runs only if all its dependencies succeed, so this alone meets the requirement without needing an explicit condition. This is the standard way to enforce sequential execution in multi-stage YAML pipelines.

Exam trap

The trap here is that candidates often confuse the 'succeeded()' function with the ability to check individual stage results, leading them to incorrectly select Option B, or they misremember the exact syntax for accessing stage dependencies in Option D.

Why the other options are wrong

This syntax is for job conditions; stage conditions do not accept string arguments for succeeded().

'stageDependencies' is not a valid expression; you would use 'dependencies.Build.result'.

Practice this question →

404

MCQmedium

Refer to the exhibit. You have this GitHub Actions workflow YAML. The workflow does not trigger when you push to the main branch. What is the most likely issue?

A.The branch name should be in a list under 'branches' inside 'push'.

B.The 'vmImage' should be 'windows-latest' for scripts.

C.The correct keyword is 'on', not 'triggers'.

D.The 'triggers' keyword is misspelled; it should be 'trigger'.

AnswerC

GitHub Actions uses the top-level `on` key to define the events that trigger a workflow, such as `push` or `pull_request`. The exhibit incorrectly uses `triggers`, which is not a recognized key in GitHub Actions syntax, causing the workflow to be invalid or never run.

Why this answer

GitHub Actions workflows use the `on` keyword to define triggers, not `triggers`. The YAML snippet incorrectly uses `triggers`, which is not a valid key in GitHub Actions syntax; the workflow engine ignores it, so no push event on `main` will start the workflow. This is a common syntax error where the candidate confuses Azure Pipelines (which uses `trigger`) with GitHub Actions (which uses `on`).

Exam trap

The trap here is that candidates familiar with Azure Pipelines might choose option D, thinking `triggers` is a misspelling of `trigger`, but GitHub Actions requires `on`, not `trigger`.

How to eliminate wrong answers

Option A is wrong because GitHub Actions allows a single string or a list under `branches`; a single string like `main` is valid, so the issue is not the format. Option B is wrong because `vmImage: 'ubuntu-latest'` is perfectly valid for running scripts; there is no requirement to use `windows-latest` for scripts. Option D is wrong because the keyword is not `trigger`; GitHub Actions uses `on`, not `trigger` or `triggers`, so the misspelling is irrelevant.

Practice this question →

405

MCQhard

Your release pipeline deploys to multiple environments (Dev, Test, Prod) using approval gates. Recently, the Prod deployment failed because a manual validation task timed out after 30 minutes. You need to ensure that if the manual validation is not approved within 15 minutes, the pipeline automatically rejects the deployment and sends a notification. What should you do?

A.Set the 'Timeout in minutes' for the entire stage to 15.

B.In the Manual Validation task, set 'Timeout' to 15 and 'On timeout' to 'Reject'.

C.Configure a pre-deployment approval with a timeout of 15 minutes.

D.Add a PowerShell task after the manual validation that checks the status and cancels the pipeline if not approved.

AnswerB

The Manual Validation task has a 'Timeout' property and an 'On timeout' action. By setting the timeout to 15 and 'On timeout' to 'Reject', if a user does not respond within 15 minutes, the task automatically rejects the deployment, which immediately stops the pipeline and marks the deployment as rejected. This is the only option that directly enforces the desired rejection on a per-validation basis.

Why this answer

The Manual Validation task has a 'Timeout' setting and an 'On timeout' option. Setting Timeout to 15 minutes and On timeout to 'Reject' will automatically reject the deployment if not approved within 15 minutes. Additionally, you can configure a notification using an Azure DevOps subscription or service hook for the rejection event.

Option A is incorrect because the stage timeout does not specifically handle manual validation rejection. Option C is incorrect because, although pre-deployment approvals do have a timeout that can reject on timeout, they apply to the approval gate before the stage, not to a manual validation task within the stage. Option D is incorrect because adding a PowerShell task is unnecessary and less reliable than the built-in timeout behavior.

Practice this question →

406

MCQmedium

You are implementing a release pipeline that deploys a web app to Azure App Service. The deployment must be approved by a manager before proceeding to the production slot. However, the manager is on leave and the deployment is critical. What should you do to ensure the deployment can proceed without delaying the release?

A.Skip the approval for this deployment by overriding the settings.

B.Add an additional approver in the pre-deployment approval settings.

C.Configure the approval to time out after 24 hours and automatically approve.

D.Remove the approval requirement from the pipeline.

AnswerB

Adding an additional approver in the pre-deployment approval settings ensures that if the primary approver is unavailable, a designated backup can review and approve the release, allowing the deployment to proceed without delay. This maintains the required human gate and auditability, unlike skipping or auto-approving, making it the correct approach to handle approver unavailability.

Why this answer

Adding an additional approver in the pre-deployment approval settings allows another authorized user (e.g., a backup manager or team lead) to approve the deployment while the primary manager is unavailable. This maintains the required governance and security controls without blocking the critical release. Azure Pipelines supports multiple approvers, and any one of them can approve to proceed.

Exam trap

The trap here is that candidates may think skipping or removing the approval is acceptable for a critical release, but Azure DevOps enforces governance; the correct approach is to add an additional approver to maintain control while enabling progress.

How to eliminate wrong answers

Option A is wrong because skipping the approval by overriding settings bypasses the required governance and security controls, which violates compliance policies and could lead to unauthorized deployments. Option C is wrong because configuring the approval to time out after 24 hours and automatically approve would cause an unacceptable delay for a critical release and still does not guarantee timely approval. Option D is wrong because removing the approval requirement from the pipeline permanently eliminates the approval gate for all future deployments, which is an overreaction and weakens the release governance.

Practice this question →

407

MCQhard

You are designing a release pipeline for a multi-tenant SaaS application that is deployed to Azure App Service. Each tenant has its own App Service instance. The pipeline must deploy a new version of the application to a staging slot for each tenant, run smoke tests, and then swap the staging slot to production. You need to ensure that if the smoke tests fail for any tenant, the swap is not performed for that tenant, while other tenants continue. Which release pipeline configuration should you use?

A.Create a release with multiple jobs (one per tenant) in the same stage, each deploying to a tenant's staging slot, running tests, and conditionally swapping. Set the 'Run this job' condition to 'Only when all previous jobs have succeeded' or use custom conditions to skip swap on failure.

B.Create a single stage with a 'foreach' loop over tenants, and if smoke tests fail, skip the swap using a condition.

C.Create a single job with parallel tasks for each tenant, and configure failure conditions to skip the swap.

D.Create a single stage with multiple deployment tasks, one per tenant, and use a 'continue on error' option on each task.

AnswerA

Multiple jobs can run in parallel, and each job can independently handle success/failure for its tenant.

Why this answer

It uses separate jobs per tenant within a single stage, each with its own deployment, smoke test, and conditional swap. By setting the 'Run this job' condition to 'Only when all previous jobs have succeeded' or a custom condition, you ensure that a failed smoke test for one tenant blocks only that tenant's swap, while other tenants' jobs proceed independently. This design aligns with Azure Pipelines' job-level isolation, where each job runs on its own agent and can have independent success/failure conditions.

Exam trap

The trap here is that candidates often confuse job-level parallelism with task-level parallelism, assuming that parallel tasks within a single job can achieve the same isolation, but in Azure Pipelines, tasks within a job share the same agent and failure context, so a single failure can halt all tenant deployments.

How to eliminate wrong answers

Option B is wrong because a 'foreach' loop over tenants within a single job would execute sequentially and a failure in one iteration would stop the entire loop, preventing other tenants from being processed. Option C is wrong because parallel tasks within a single job share the same agent and failure conditions; if one task fails, the entire job fails by default, blocking all tenants. Option D is wrong because 'continue on error' on each task allows the pipeline to continue after a failure, but it does not prevent the swap for the failed tenant; the swap task would still execute unless explicitly conditioned, and the pipeline would not isolate failures per tenant.

Practice this question →

408

Multi-Selecthard

Which THREE of the following are valid steps to implement a trunk-based development workflow in Azure Repos? (Select THREE.)

Select 3 answers

A.Run CI builds on the main branch.

B.Use feature flags and pair programming.

C.Merge to main only once per week.

D.Use short-lived feature branches that are merged within a day.

E.Create release branches for each production release.

AnswersA, B, D

Running CI builds on the main branch is a core trunk-based development practice: every commit to main must compile and pass automated tests, ensuring the integration point is always stable and deployable, which allows teams to merge frequently without accumulating integration debt.

Why this answer

Trunk-based development requires developers to integrate into the main branch frequently. In Azure Repos, you set a CI trigger on main so every commit is built and validated (A). Developers use short-lived feature branches that are merged into main within a day (D) to keep integration conflicts small.

Feature flags and pair programming are supporting practices that allow work to be integrated even before a feature is complete, avoiding long-running branches (B). Merging to main only once per week (C) contradicts the continuous-integration principle, and creating a release branch for every production release (E) is characteristic of GitFlow/release-flow, not trunk-based development.

Exam trap

The trap here is that candidates confuse trunk-based development with GitFlow or release-based branching strategies, leading them to select options like creating release branches or infrequent merges, which are antithetical to the trunk-based workflow's emphasis on continuous integration and minimal branching.

Practice this question →

409

MCQmedium

Refer to the exhibit. You are deploying this Bicep file using Azure Pipelines. The 'environment' parameter should be set to 'dev', 'qa', or 'prod' based on the release stage. How should you pass the parameter value?

A.Define the parameter in the 'parameters:' section of the YAML pipeline.

B.Set a pipeline variable named 'environment' and reference it in the AzureResourceManagerTemplateDeployment task's overrideParameters.

C.Use a task to replace the string '${environment}' in the Bicep file before deployment.

D.Modify the Bicep file to include a default value for environment.

AnswerB

The overrideParameters field in the AzureResourceManagerTemplateDeployment task accepts key-value pairs that override Bicep/ARM template parameters at deployment time. By setting a pipeline variable and referencing it like -environment $(environment), you dynamically supply the environment-specific value per stage, leveraging Azure DevOps native variable scoping.

Why this answer

The AzureResourceManagerTemplateDeployment task's `overrideParameters` property allows you to dynamically pass parameter values at deployment time. By setting a pipeline variable named `environment` (which can be scoped per stage) and referencing it as `$(environment)` in `overrideParameters`, you can inject the correct value ('dev', 'qa', or 'prod') based on the release stage without modifying the Bicep file or its defaults.

Exam trap

The trap here is that candidates confuse YAML pipeline parameters (defined with `parameters:`) with Bicep file parameters, or assume that modifying the Bicep file's default value is a valid dynamic override, when in fact `overrideParameters` is the intended mechanism for stage-specific value injection.

How to eliminate wrong answers

Option A is wrong because the `parameters:` section in a YAML pipeline defines pipeline-level parameters (e.g., for manual triggers or template inputs), not runtime overrides for a Bicep file's parameters; it cannot pass values directly to the ARM deployment task's `overrideParameters`. Option C is wrong because string replacement in the Bicep file before deployment is an unnecessary and fragile workaround; Bicep files are compiled to ARM templates, and the proper way to supply parameter values is via the deployment task's `overrideParameters` or parameter file. Option D is wrong because adding a default value to the Bicep file would fix the parameter to a single value (e.g., 'dev') and prevent dynamic assignment per stage, which defeats the purpose of stage-specific overrides.

Practice this question →

410

Multi-Selectmedium

Which TWO are benefits of using deployment groups in Azure Pipelines compared to using individual virtual machines?

Select 2 answers

A.Built-in secrets management for connection strings.

B.Reduced cost because VMs are shut down when not in use.

C.Automatic scaling of virtual machines based on load.

D.Simplified targeting of multiple machines with a single pipeline run.

E.Rolling deployment support with health checks.

AnswersD, E

Deployment groups group machines together for parallel deployment.

Why this answer

Deployment groups in Azure Pipelines allow you to target multiple machines with a single pipeline run by logically grouping them, enabling parallel or rolling deployments across all machines in the group. This simplifies management compared to configuring each individual VM separately in the pipeline, as you can define the group once and reuse it across releases.

Exam trap

The trap here is confusing deployment groups with Azure VM scale sets, leading candidates to incorrectly associate automatic scaling or cost-saving shutdown features with deployment groups, when those are separate Azure services.

Practice this question →

411

Multi-Selecthard

Which THREE components are required to set up a self-hosted agent pool in Azure Pipelines?

Select 3 answers

A.The agent software installed on the target machine

B.A deployment group target

C.The agent pool name and URL of the Azure DevOps organization

D.Azure VM extension for Azure Pipelines Agent

E.A personal access token (PAT) for authentication

AnswersA, C, E

The agent software is essential for the self-hosted agent.

Why this answer

The self-hosted agent requires the Azure Pipelines agent software to be installed on the target machine. This software, which includes the agent listener and worker processes, is what registers the machine with the agent pool and executes pipeline jobs. Without the agent software, the machine cannot communicate with Azure Pipelines or run any tasks.

Exam trap

The trap here is that candidates often confuse the Azure VM extension (a convenience tool) with a mandatory requirement, or they mistakenly think a deployment group target is needed for agent pools, when in fact deployment groups are for targeting specific machines in a release context, not for agent registration.

Practice this question →

412

MCQeasy

Your team uses GitHub Actions for CI/CD. You need to ensure that secrets are not exposed in build logs. What should you use?

A.Hardcoded values in the workflow YAML

B.Environment variables in the workflow

C.GitHub Secrets

D.Artifact storage

AnswerC

GitHub Secrets are the correct way to store sensitive data because they are encrypted at rest and only decrypted for the specific actions or workflows that reference them. Secrets are automatically masked in logs, preventing accidental exposure, and they support environment-based scoping for granular access control. This ensures credentials and API tokens remain protected throughout the CI/CD pipeline.

Why this answer

GitHub Secrets (Option C) is the correct choice because GitHub Actions provides a built-in encrypted secrets store that automatically masks secret values in build logs. When you reference a secret using `${{ secrets.MY_SECRET }}`, GitHub ensures the value is never printed or exposed in workflow output, unlike plaintext or environment variables that can be inadvertently logged.

Exam trap

The trap here is that candidates often confuse environment variables (which can be set in the workflow YAML) with GitHub Secrets, not realizing that environment variables are not automatically masked and can leak in logs, whereas GitHub Secrets are specifically designed for secure injection and automatic log redaction.

How to eliminate wrong answers

Option A is wrong because hardcoded values in the workflow YAML are stored as plaintext in the repository, visible to anyone with read access and exposed in logs if the workflow prints them. Option B is wrong because environment variables defined in the workflow YAML (e.g., `env: MY_VAR: value`) are not automatically masked; if a step echoes the variable or an error message includes it, the value appears in plaintext in the logs. Option D is wrong because artifact storage is used to persist build outputs (e.g., compiled binaries, test results) between jobs, not to securely store or inject secrets at runtime.

Practice this question →

413

Multi-Selectmedium

Your release pipeline deploys a web app to Azure App Service. You need to implement safe deployment practices that minimize downtime and enable quick rollback. Which THREE strategies should you recommend?

Select 3 answers

A.Deploy to a staging slot first, validate, then swap.

B.Use rolling deployment with manual step to approve each instance.

C.Deploy directly to the production slot.

D.Configure monitoring and alerts to trigger automatic rollback if error rate increases.

E.Use deployment slots with swap and auto-swap.

AnswersA, D, E

Staging slot allows testing before production.

Why this answer

Deploying to a staging slot first allows you to validate the application in a production-like environment without affecting live traffic. Once validated, swapping the staging and production slots ensures zero-downtime deployment by instantly routing all traffic to the validated version. This is a core safe deployment practice for Azure App Service.

Exam trap

The trap here is that candidates often confuse 'rolling deployment' (which is a valid strategy for virtual machine scale sets) with Azure App Service's slot-based swap, and they may incorrectly think manual approval per instance is a safe practice when it actually breaks automation and consistency.

Practice this question →

414

MCQmedium

Refer to the exhibit. A build pipeline fails with this error. What is the most likely cause?

A.The build agent does not have the 'ASP.NET and web development' workload installed.

B.The build agent is out of disk space.

C.The pipeline is using the wrong version of MSBuild.

D.The solution file is corrupted.

AnswerA

The error indicates that the imported Microsoft.WebApplication.targets file cannot be found, which is installed with the 'ASP.NET and web development' workload in Visual Studio Build Tools. Without that workload, Web Application projects fail during MSBuild evaluation regardless of agent disk space or MSBuild version.

Why this answer

The error indicates that the MSBuild targets file for Web Applications is missing. This typically occurs when the build agent does not have the required Visual Studio workload installed, specifically the Web development build tools.

Practice this question →