CCNA Build Release Pipelines Questions — Page 5 of 5

301

MCQhard

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

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

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

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

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

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

302

MCQeasy

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

A.Jenkinsfile

B..github/workflows/ci.yml

C.Dockerfile

D.azure-pipelines.yml

AnswerB

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

Why this answer

GitHub Actions workflows are defined in YAML files stored in the .github/workflows directory at the root of the repository. The file can have any name but must have a .yml or .yaml extension, and ci.yml is a common convention. This file contains the workflow definition, including triggers (on), jobs, and steps.

GitHub automatically detects and runs workflows from this directory.

Exam trap

AZ-400 often tests the specific file location and format required for GitHub Actions workflows, and candidates may confuse it with other CI/CD tools like Jenkins or Azure Pipelines.

How to eliminate wrong answers

Option A is wrong because a Jenkinsfile is used by Jenkins, not GitHub Actions, to define pipeline stages in Groovy DSL. Option C is wrong because a Dockerfile is used to build container images, not to define CI workflows. Option D is wrong because azure-pipelines.yml is used by Azure Pipelines, not GitHub Actions, to define build and release pipelines.

Practice this question →

303

MCQeasy

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

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

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

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

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

AnswerB

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

Why this answer

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

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

Practice this question →

304

MCQhard

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

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

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

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

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

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

305

MCQmedium

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

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

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

C.Configure pipeline permissions to require approval.

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

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

306

Multi-Selecthard

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

Select 2 answers

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

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

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

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

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

AnswersB, D

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

Why this answer

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

Exam trap

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

Practice this question →

307

MCQeasy

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

A.YAML template expressions

B.Branch control for environments

C.Deployment gates

D.Pipeline decorators

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

308

MCQeasy

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

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

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

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

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

AnswerC

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

Why this answer

Azure Repos branch policies on main can require a build validation that runs on pull requests and blocks completion until the build succeeds. This enforces that every PR is built and tested before merge, which is exactly the requirement. Manual runs, non-blocking pipelines, and post-merge CI triggers do not prevent merging of failing code.

Exam trap

The trap is choosing a CI trigger on main (which runs post-merge) instead of a PR build validation policy (which gates the merge) — the exam tests whether you know the difference between post-merge CI and pre-merge gating.

How to eliminate wrong answers

Option A is wrong because manual pipeline runs rely on human discipline and do not enforce or block merges. Option B is wrong because a non-blocking pre-merge pipeline provides feedback but does not prevent merging failing code. Option D is wrong because a CI trigger on main runs after commits are already merged, so it cannot prevent bad code from reaching main.

Practice this question →

309

Multi-Selectmedium

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

Select 2 answers

A.Log secret values for debugging purposes

B.Limit variable group permissions to specific pipelines

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

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

E.Store secrets as plain text variables in the pipeline

AnswersB, D

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

Why this answer

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

Exam trap

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

Practice this question →

310

MCQmedium

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

A.Configure pipeline permissions for the agent pool

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

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

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

AnswerD

A custom capability demand restricts pipeline job placement to self-hosted agents that carry that capability, so only approved, patched agents in the specified pool run the pipeline. This satisfies the requirement to enforce use of approved agents with current security patches.

Why this answer

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

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

311

MCQhard

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

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

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

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

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

AnswerD

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

Why this answer

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

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

Practice this question →

312

MCQmedium

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

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

B.NuGet restore task with 'cacheRestore' option.

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

D.PublishBuildArtifacts task to upload packages.

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

313

MCQmedium

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

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

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

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

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

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

314

MCQmedium

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

A.Pull request trigger in the build pipeline

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

C.Build completion trigger in the release pipeline

D.Scheduled trigger in the release pipeline

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

315

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

Option B is correct because the requirement explicitly states the images must be scanned for vulnerabilities, and adding a step that runs a scanning tool such as Trivy (e.g., aquasecurity/trivy-action) performs that vulnerability scan against the built image. Option C is correct because the requirement also states the images must be signed, and cosign (sigstore/cosign) is the standard tool for signing container images, producing a signature that can be verified against the image digest. Option E is correct because a multi-container application must actually be built and pushed to a registry before it can be scanned or signed, and docker/build-push-action is the canonical GitHub Actions step that builds and pushes the images.

Option A is not required because authenticating to Docker Hub is only necessary if pushing to Docker Hub specifically; the scenario does not mandate that registry, and authentication could be handled differently or target another registry. Option D is not required for the stated goals because checking out the code is a general prerequisite for many workflows but is not one of the three actions specifically needed to scan and sign the produced images.

Exam trap

The trap is including generic workflow steps (checkout, login) that are helpful but not the specific actions that perform scanning and signing — the exam wants the three steps that directly satisfy the stated security requirement.

Practice this question →

316

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 →

317

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 →

318

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

The File Transform task in Azure Pipelines can perform token replacement in configuration files like appsettings.json using variables defined in pipeline variable groups. This allows environment-specific settings to be injected during deployment without hardcoding secrets in source control. Variable groups can be linked to Azure Key Vault for secure secret management.

Exam trap

AZ-400 often tests the confusion between build-time and release-time configuration, and candidates may choose options that involve code changes or are specific to older technologies like Web.config.

How to eliminate wrong answers

Option B is wrong because separate build configurations and Web.config transforms are specific to ASP.NET and not applicable to appsettings.json in .NET Core. Option C is wrong because the Azure App Service Deploy task with Web Deploy parameterization is for web.config, not appsettings.json. Option D is wrong because setting environment variables in App Service and reading them in code is a valid approach but does not automatically replace settings in appsettings.json during deployment; it requires code changes to read environment variables.

Practice this question →

319

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 →

320

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

Using the 'azure/login' action with OIDC and configuring a federated identity credential in Microsoft Entra ID allows GitHub Actions to authenticate to Azure without storing any secrets. The federated credential establishes a trust relationship between GitHub's OIDC provider and an Azure AD app registration, so the workflow can obtain a short-lived token. This eliminates the need for a publish profile secret, improving security by removing long-lived credentials.

Exam trap

AZ-400 often tests the misconception that managed identities can be used directly from GitHub runners, but they are only available to Azure resources. The correct approach is to use OIDC with federated credentials.

How to eliminate wrong answers

Option A is wrong because Azure AD Managed Identity is not directly available to GitHub-hosted runners; it requires an Azure-hosted compute resource. Option C is wrong because storing a service principal secret as a GitHub secret still involves a long-lived credential, which OIDC aims to eliminate. Option D is wrong because setting the Publish Profile parameter to an empty string would break the deployment, not enable OIDC authentication.

Practice this question →

321

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 →

322

MCQmedium

Your team uses an Azure Pipelines YAML build pipeline to compile a .NET solution. The pipeline is defined in a repository named 'ContosoApp'. You need to ensure that the build runs only when changes are pushed to the 'main' branch, and that it does not run for any other branch. Which trigger configuration should you use?

A.trigger: branches: exclude: - main

B.pr: branches: include: - main

C.trigger: paths: include: - main

D.trigger: branches: include: - main

AnswerD

This configuration uses the trigger block with branches.include set to main, which is the correct YAML syntax to limit CI triggers to the main branch. It ensures the pipeline runs only when changes are pushed to main, satisfying the requirement. Other branches are excluded by default because only main is included.

Why this answer

The trigger block with branches.include is the standard way to specify which branches trigger a YAML pipeline. Including only main ensures the pipeline runs exclusively for pushes to main, meeting the requirement. The other options either exclude main, configure PR triggers, or misuse path filters.

Exam trap

The trap here is confusing branch filters with path filters, or mixing up CI triggers with PR triggers, leading to incorrect YAML syntax.

Practice this question →

323

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 let you preinstall bespoke toolchains, SDKs and agents directly on the runner machine, so jobs needing software absent from GitHub-hosted images execute without per-run setup steps. This satisfies the custom-software constraint, unlike GitHub-hosted runners whose images are fixed and cannot be modified.

Why this answer

Option A is correct because self-hosted runners are machines you provision and manage yourself, so you can preinstall any custom software, tools, or dependencies your workflows require rather than being limited to the GitHub-hosted runner image. Option D is correct because the self-hosted runner application supports Windows, Linux, and macOS operating systems, letting you register runners on any of these platforms. Option E is correct because self-hosted runners can be deployed inside your own network (for example on-premises or in a private VPC), giving workflows direct access to internal resources such as databases, file shares, and internal APIs that GitHub-hosted runners cannot reach.

Option B is not correct because GitHub does not autoscale self-hosted runners; scaling must be implemented by you, for example with the Actions Runner Controller or autoscaling groups. Option C is not correct because while GitHub does not charge for self-hosted runner usage, you still pay for the underlying compute, storage, and network infrastructure you provide.

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 →

324

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 →

325

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 →

326

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 →

327

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 →

328

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

In Azure Pipelines, environment-level checks such as pre-deployment approvals are the correct mechanism to gate a stage on human authorization. Approvals configured on the Prod environment (or on a service connection) block the deployment until an approver signs off, and the stage's dependency on Test ensures it only runs after Test succeeds. This combines the two required conditions — Test success and manual approval — declaratively.

Exam trap

AZ-400 often tests the confusion between task-level manual intervention and environment-level approval gates, tempting candidates to pick a manual intervention task when the requirement is a governed, dependency-aware approval on the target environment.

How to eliminate wrong answers

Option A is wrong because a manual intervention task inside the pipeline pauses execution but does not by itself enforce that Test succeeded first, and it is a task-level rather than environment-level control, making it harder to govern across pipelines. Option B is wrong because conditions on a stage cannot natively prompt a human for approval; conditions evaluate expressions, not interactive sign-off, so a 'manual intervention variable' is not a real approval mechanism. Option C is wrong because scheduling the Prod deployment and requiring a manual trigger does not guarantee Test succeeded — a schedule is time-based, not dependency-based, and a manual trigger bypasses the Test-success requirement.

Practice this question →

329

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's traffic-splitting rules operate at the ingress and sidecar layer, letting you weight traffic by percentage independently of pod replica counts. That satisfies the gradual, monitored shift the canary strategy demands, since rollback is a routing change rather than a redeployment.

Why this answer

A service mesh like Istio provides fine-grained traffic splitting at the network layer, allowing a precise percentage of traffic (e.g., 5%, then 10%, then 50%) to be routed to the canary version while the rest goes to the stable version. Istio's telemetry (via Envoy sidecars) enables real-time error-rate and latency monitoring, so you can automatically or manually roll back if anomalies appear. This is the most controlled, observable approach for canary deployments on AKS.

Exam trap

AZ-400 often tests the distinction between canary and blue/green or rolling deployments, tricking candidates into selecting ingress-level or Kubernetes-native strategies that lack the granular traffic-percentage control and observability a service mesh provides.

How to eliminate wrong answers

Option B is wrong because Application Gateway weighted backend pools operate at the ingress level and lack the per-request telemetry and dynamic traffic-shifting granularity of a service mesh; they also cannot easily perform header-based or user-based routing for canary analysis. Option C is wrong because AKS rolling updates replace pods gradually but do not control the percentage of user traffic hitting the new version — all traffic goes to whatever pods are ready, which is not a true canary. Option D is wrong because staging-to-production VIP swaps are blue/green deployments, not canary; they shift 100% of traffic at once and do not support gradual percentage-based rollout.

Practice this question →

330

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 →

331

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 →

332

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 →

333

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 →

334

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 →

335

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 one immutable build artifact through dev, test and prod guarantees identical binaries reach every environment, satisfying the same-artifact constraint. Rebuilding per environment would introduce drift, so a single build feeding staged deployments with approval gates is correct.

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 →

336

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 →

337

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 →

338

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

Hardcoding an admin password directly in an ARM template exposes credentials in source control, pipeline logs, and deployment history, creating a serious security vulnerability. The correct remediation is to reference a secret from Azure Key Vault or use a secure parameter, not to embed the value. This is the security concern the question asks you to identify.

Exam trap

The trap is that candidates focus on technical template correctness (apiVersion, VM size, defaults) rather than the security anti-pattern — the exam expects you to spot the hardcoded credential as the priority security issue.

How to eliminate wrong answers

Option A is wrong because VM size is a performance/cost consideration, not a security concern, and the question asks specifically about security. Option B is wrong because an outdated apiVersion is a compatibility/maintenance issue that may cause deployment failures, but it is not a security vulnerability. Option D is wrong because having a default value for the location parameter is a normal and acceptable ARM template practice, not a security risk.

Practice this question →

339

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 →

340

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 →

341

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 →

342

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 →

343

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 →

344

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 →

345

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 register multiple target machines as one logical set, letting a single pipeline run fan out to all of them. This removes the need to define and maintain separate pipeline stages or jobs per machine.

Why this answer

Option D is correct because deployment groups let a single pipeline job target a logical set of machines (defined by tags), so one pipeline run can deploy to many VMs without enumerating each machine individually. Option E is correct because deployment groups natively support rolling deployments, where the agent on each target machine runs the deployment steps and the pipeline can perform health checks and stop the rollout if a machine fails. Option A is not a deployment group feature; secrets such as connection strings are handled by Azure Key Vault, variable groups, or secret variables, not by deployment groups themselves.

Option B is incorrect because deployment groups do not shut down VMs to save cost; they only orchestrate deployment to registered machines. Option C is incorrect because automatic VM scaling is provided by VM scale sets or autoscale settings, not by deployment groups.

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 →

346

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

Installing the agent software on the target machine is mandatory: the agent listener establishes the outbound connection to Azure Pipelines and executes queued jobs. Without it, the machine cannot register with the pool or run pipeline work, so the self-hosted capability simply does not exist.

Why this answer

To set up a self-hosted agent pool in Azure Pipelines, you must install the agent software on the target machine (option A), which provides the listener that polls Azure DevOps for jobs and runs them locally. You also need to configure the agent with the agent pool name and the URL of the Azure DevOps organization (option C), since the agent registers itself into a specific pool under a specific organization endpoint. Authentication requires a personal access token (option E) with the appropriate scope (typically Agent Pools read/manage), which the agent uses during configuration to register with the service.

Option B is incorrect because deployment groups are a separate feature for classic release pipelines targeting machines, not the mechanism for creating an agent pool. Option D is incorrect because the Azure VM extension for Azure Pipelines Agent is an optional convenience for provisioning agents on Azure VMs, not a required component of a self-hosted agent pool.

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 →

347

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 →

348

MCQhard

You have a YAML pipeline that builds a container image and pushes it to Azure Container Registry (ACR). The pipeline uses a Docker task to build and push the image. You need to ensure that the image is tagged with both the build ID and the latest tag, but only when the build is from the main branch. Which approach should you use?

A.Use a single Docker task with the command buildAndPush and specify multiple tags in the tags input, and add a condition to the task to run only for the main branch.

B.Use two separate Docker tasks: one to build and push with the build ID tag, and another to build and push with the latest tag, each with its own condition.

C.Use a Docker task to build and push with the build ID tag, then use an Azure CLI task to run az acr repository update to add the latest tag, with a condition on the CLI task.

D.Use a Docker task to build and push with the latest tag, then use a script to retag the image with the build ID using docker tag and docker push, with a condition on the script.

AnswerA

The Docker task's buildAndPush command supports multiple tags via a comma-separated list in the tags input. You can specify both $(Build.BuildId) and latest. By adding a condition such as eq(variables['Build.SourceBranch'], 'refs/heads/main'), the task will only execute for the main branch, ensuring the tags are applied only in that case. This is the most straightforward and supported method.

Why this answer

The Docker task's buildAndPush command accepts multiple tags in the tags input, allowing both the build ID and latest to be applied in a single build and push operation. Adding a condition to the task ensures it only runs for the main branch. This is the most efficient and maintainable solution.

Exam trap

The trap here is overcomplicating the solution by using separate tasks or CLI commands to add tags, when the Docker task natively supports multiple tags in one step.

Practice this question →