Courseiva

CCNA Design and implement build and release pipelines Questions

75 of 461 questions · Page 5/7 · Design and implement build and release pipelines · Answers revealed

Practice these questionsDomain overviewAll questions
301
MCQmedium

You are designing a build pipeline for a Node.js application. The pipeline must run unit tests and publish code coverage results to Azure Pipelines. Which task should you use to ensure coverage results are available in the pipeline summary?

A.PublishTestResults@2
B.VSTest@2
C.CopyFiles@2
D.PublishCodeCoverageResults@1
AnswerD

This task publishes code coverage results in formats like Cobertura and displays them in the pipeline summary.

Why this answer

Option B is correct because the PublishCodeCoverageResults task consumes coverage data (e.g., Cobertura format) and displays it in the pipeline summary. Option A is wrong because the PublishTestResults task only publishes test results, not coverage. Option C is wrong because the Visual Studio Test task is for .NET, not Node.js.

Option D is wrong because the Copy Files task only copies files, it does not process coverage.

Practice this question →
302
MCQeasy

Your build pipeline for a Java application uses Maven. You need to run unit tests and integration tests separately. Unit tests should run on every commit, while integration tests should run only when the build is triggered by a pull request to the main branch. How should you configure the pipeline?

A.Add both test types as steps in the same job and use a step condition.
B.Create two separate stages: one for unit tests, one for integration tests.
C.Create two jobs: one with unit tests (always), one with integration tests conditioned on 'eq(variables['Build.Reason'], 'PullRequest')'.
D.Use a single job with both tests, but set the 'always()' condition on the integration test step.
AnswerC

Jobs can run in parallel or conditionally based on build reason.

Why this answer

Option C is correct because using two jobs with different conditions allows selective execution. Option A is wrong because the same condition applies to all steps. Option B is wrong because stages run sequentially, not conditionally.

Option D is wrong because 'always()' would run both jobs regardless.

Practice this question →
303
MCQeasy

You have a multi-stage YAML pipeline that builds and deploys a Node.js application. You want to ensure that the build stage runs only when changes are made to the 'src' folder. Which trigger configuration should you use?

A.Trigger with 'batch' set to true
B.Trigger with 'branches' filter
C.Trigger with 'paths' filter
D.Disable CI trigger and use a scheduled trigger
AnswerC

Paths filter specifies which files or folders trigger the pipeline.

Why this answer

Option A is correct because the path trigger filters changes to specific paths. Option B is wrong because it would trigger on any change. Option C is wrong because batch changes the number of triggers but not the path.

Option D is wrong because branches filter by branch, not path.

Practice this question →
304
MCQmedium

Your organization uses Azure Pipelines to build and deploy a .NET Core application to Azure App Service. The build pipeline takes 15 minutes. You want to implement continuous integration (CI) triggers but only for changes to the 'src' folder. The repository is in Azure Repos. How should you configure the trigger?

A.Set trigger: paths: include: - 'src/*'
B.Set trigger: paths: exclude: - 'src/*'
C.Set trigger: branches: include: - main
D.Set trigger: batch: true
AnswerA

This triggers CI only when files in src folder change.

Why this answer

Option C is correct because specifying paths in the trigger filters CI builds to only that path. Option A is incorrect because it excludes a path. Option B is incorrect because the branch filter is not needed and path is not specified.

Option D is incorrect because batch changes are not relevant.

Practice this question →
305
MCQmedium

You have a release pipeline that deploys to multiple stages. You want to ensure that a manual approval is required before deploying to the production stage. Which approach should you use?

A.Add a pre-deployment approval on the production stage.
B.Add a post-deployment approval on the staging stage.
C.Configure a deployment gate with a manual intervention task.
D.Use a pipeline decorator to inject approval step.
AnswerA

Why this answer

Pre-deployment approvals in Azure Pipelines allow you to require manual sign-off before a release proceeds to a specific stage. By adding a pre-deployment approval on the production stage, the pipeline will pause and wait for designated approvers to approve the deployment, ensuring that no code reaches production without explicit authorization.

Exam trap

The trap here is that candidates often confuse post-deployment approvals (which occur after a stage completes) with pre-deployment approvals (which occur before a stage starts), or they mistakenly think a manual intervention task inside a deployment gate can replace the native stage-level approval feature.

Why the other options are wrong

B

Post-deployment happens after deployment, not before.

C

Gates evaluate conditions, but manual approval is simpler and more direct.

D

Decorators are for injecting steps, not for approvals.

Practice this question →
306
MCQeasy

Your team uses Azure Repos Git and wants to enforce a policy that all pushes to the main branch must pass a build validation pipeline. The pipeline runs unit tests and code analysis. You need to configure this in the branch policy. Which setting should you enable?

A.Require comment resolution
B.Linked work items
C.Limit merge types
D.Build validation
AnswerD

This enforces a successful build on each push.

Why this answer

Azure Repos branch policies allow requiring a successful build for each push. The 'Require a minimum number of reviewers' is for pull request approvals, not pushes. Option C is correct.

Option A is for comments, not builds. Option B is for merge strategies. Option D is for work item linking.

Practice this question →
307
Multi-Selecthard

Your team uses Azure Pipelines to build a Java application. The build must produce a JAR file and publish it as a pipeline artifact. Which THREE steps should be included in the build pipeline?

Select 3 answers
A.Use a Maven or Gradle task to compile and package the application.
B.Use the DotNetCoreCLI task to build the application.
C.Use the Publish Build Artifacts task to upload the staging directory.
D.Use the Copy Files task to copy the JAR to $(Build.ArtifactStagingDirectory).
E.Use the NuGetCommand task to pack the JAR.
AnswersA, C, D

These tasks compile and create the JAR.

Why this answer

Option A is correct because Maven or Gradle builds the JAR. Option C is correct because Copy Files task moves the JAR to a staging directory. Option E is correct because Publish Build Artifacts uploads the artifact.

Options B and D are not required.

Practice this question →
308
MCQhard

Your team uses Azure Pipelines to deploy a microservices application to Azure Kubernetes Service (AKS). Each microservice has its own pipeline that builds a Docker image and deploys it to a shared AKS cluster. The deployment must support rolling updates with zero downtime. You need to ensure that if a deployment fails (e.g., health check fails), the pipeline automatically rolls back to the previous version. Which deployment strategy should you implement in the pipeline?

A.Use a canary deployment strategy with a pipeline task that gradually shifts traffic to the new version and monitors error rates. If errors exceed a threshold, the task stops the canary.
B.Use a rolling update strategy with the 'kubectl apply' command, and include a post-deployment step that checks the rollout status. If the rollout fails, run 'kubectl rollout undo' to roll back.
C.Use the 'KubernetesManifest' task with the 'rollout status' option, which automatically rolls back if the rollout status indicates failure.
D.Use a blue-green deployment strategy with two separate AKS clusters. Deploy the new version to the green cluster, run health checks, and then update the load balancer to point to green. If health checks fail, keep pointing to blue.
AnswerB

This leverages Kubernetes native rolling updates and automates rollback on failure.

Why this answer

Option D is correct because Kubernetes supports rolling updates natively, and with proper readiness probes, it can automatically roll back if the update fails. Combined with a pipeline task that monitors the rollout and triggers rollback on failure, this meets the requirement. Option A is wrong because canary deployments require manual or automated traffic shifting and do not automatically roll back the entire deployment.

Option B is wrong because blue-green deployments require an additional AKS cluster or namespace and manual rollback steps. Option C is wrong because the KubernetesManifest task with rollout status does not automatically roll back; it only monitors.

Practice this question →
309
MCQmedium

Your Azure DevOps pipeline deploys a web app to Azure App Service using a YAML pipeline. The deployment fails intermittently with the error 'Conflict' when updating deployment slots. What is the most likely cause?

A.Another deployment or swap operation is already in progress on the slot.
B.The service connection is using expired credentials.
C.The slot name is misspelled in the pipeline configuration.
D.The web app is locked by a file handle from a previous deployment.
AnswerA

Concurrent operations on the same slot cause conflict errors.

Why this answer

Option B is correct because swapping slots while a deployment is in progress can cause a conflict error. Option A is wrong because Resource Manager connections use service principals, not user credentials. Option C is wrong because slot names are case-insensitive.

Option D is wrong because file locks would cause different errors.

Practice this question →
310
MCQeasy

Your organization uses GitHub Actions for CI/CD. You want to ensure that the workflow runs only when a pull request is labeled 'safe-to-deploy'. Which trigger should you use?

A.on: workflow_run: workflows: ["Build"] types: [completed]
B.on: issue_comment: types: [created]
C.on: pull_request: types: [labeled] branches: [main]
D.on: pull_request_target: types: [opened, synchronize] branches: [main]
AnswerC

Correctly triggers on pull request labeled event on main branch.

Why this answer

GitHub Actions supports 'pull_request' triggers with 'types' to filter on specific actions, but labeling is not a pull_request type event; it's an 'issues' or 'pull_request' event with 'labeled' type. Option A is correct. Option B is wrong because 'pull_request_target' is similar but has different security implications; it still requires correct event types.

Option C is wrong because 'issue_comment' triggers on comments, not labels. Option D is wrong because 'workflow_run' triggers on completion of another workflow.

Practice this question →
311
Multi-Selectmedium

Your team uses Azure Pipelines to build a .NET application. You need to implement a secure build pipeline that meets the following requirements: - Secrets must be injected at build time without being exposed in logs or YAML files. - The build must use Microsoft-hosted agents. - All builds must be auditable. Which TWO actions should you take? (Choose two.)

Select 2 answers
A.Enable 'Allow scripts to access the OAuth token' on the agent job and use the token in scripts.
B.Use a variable group linked to Azure Key Vault to store secrets, and reference the variable group in the pipeline.
C.Store secrets as plain-text environment variables in the pipeline YAML file.
D.Use the 'Replace Tokens' task to substitute secrets from pipeline variables into configuration files.
E.Deploy a self-hosted agent on-premises to keep secrets within the corporate network.
AnswersA, B

This allows scripts to authenticate without storing secrets, and access is audited.

Why this answer

Option A is correct because variable groups linked to an Azure Key Vault provide secure, auditable secret injection. Option D is correct because the 'Allow scripts to access the OAuth token' setting enables scripts to use the token for authenticated operations without storing secrets. Option B is incorrect because environment variables in YAML are exposed in logs.

Option C is incorrect because secrets in variables cannot be used directly in file transforms; they must be mapped or accessed via scripts. Option E is incorrect because self-hosted agents are not required and may not meet the Microsoft-hosted agent requirement.

Practice this question →
312
MCQeasy

A team uses Azure Pipelines to build a .NET Core application. The build pipeline runs successfully, but the release pipeline fails when deploying to Azure App Service with the error: 'ERROR_FILE_IN_USE'. What is the most likely cause?

A.The deployment slot is not configured correctly.
B.The 'Take App Offline' setting is not enabled in the deployment task.
C.The Azure App Service plan is not scaled appropriately.
D.The build configuration is set to Release instead of Debug.
AnswerB

Taking the app offline releases file locks.

Why this answer

The 'ERROR_FILE_IN_USE' error occurs when the deployment process tries to overwrite files that are currently locked by the running application. Enabling the 'Take App Offline' setting in the Azure App Service deploy task places an app_offline.htm file in the wwwroot directory, which gracefully shuts down the application and releases all file locks before the new binaries are copied. Without this setting, the running process holds locks on the DLLs, causing the deployment to fail.

Exam trap

The trap here is that candidates often confuse 'ERROR_FILE_IN_USE' with a slot configuration or scaling issue, but the root cause is always the running process holding file locks, which is directly resolved by the 'Take App Offline' setting in the deployment task.

How to eliminate wrong answers

Option A is wrong because an incorrectly configured deployment slot would cause routing or swapping issues, not a file-lock error during deployment. Option C is wrong because scaling the App Service plan affects performance and resource allocation, not the ability to overwrite locked files. Option D is wrong because the build configuration (Release vs.

Debug) affects optimization and debugging symbols, not file-locking behavior during deployment.

Practice this question →
313
Multi-Selectmedium

Which two of the following are valid strategies to implement conditional deployment in a YAML pipeline? (Choose 2)

Select 2 answers
A.Use the 'condition' property on a stage
B.Use template expressions with parameters
C.Configure stage filters in the triggers section
D.Use dependency conditions like 'succeededOrFailed'
E.Add a PowerShell script to check environment
AnswersA, B

Why this answer

Option A is correct because the 'condition' property in Azure DevOps YAML pipelines allows you to specify custom conditions (e.g., `eq(variables['Build.SourceBranch'], 'refs/heads/main')`) that control whether a stage, job, or step runs. This is a native, declarative way to implement conditional deployment without scripting, evaluating the condition at runtime based on variables or expressions.

Exam trap

The trap here is that candidates confuse dependency conditions (like `succeededOrFailed`) with custom conditional logic, not realizing that dependency conditions are predefined and not a general-purpose strategy for implementing conditional deployment based on arbitrary criteria like branch names or variables.

Why the other options are wrong

C

Stage filters are for triggers, not conditions within a pipeline.

D

Dependency conditions are built-in for run order, not for custom conditional logic.

E

While possible, it's not a pipeline-native strategy; the question asks for valid strategies in YAML.

Practice this question →
314
Multi-Selecthard

Which TWO are best practices for securing Azure Pipelines? (Choose two.)

Select 2 answers
A.Use variable groups linked to Azure Key Vault for secrets.
B.Scope service connections to specific resource groups with 'Contributor' role.
C.Grant 'Administrator' role to all service connections for ease of management.
D.Store all pipeline variables in the YAML file as plain text.
E.Disable pipeline logging for all jobs.
AnswersA, B

Key Vault integration securely stores and retrieves secrets.

Why this answer

Options B and D are correct. Option B: Using variable groups with secret variables from Azure Key Vault ensures secrets are not stored in YAML. Option D: Service connections with 'Contributor' role scoped to a resource group limit blast radius.

Option A is unnecessary and insecure. Option C is not a security best practice. Option E is not a security practice.

Practice this question →
315
MCQeasy

Your team uses GitHub Actions for CI/CD. You want to automatically deploy to Azure App Service whenever a pull request is merged to the main branch. Which event trigger should you use in the GitHub Actions workflow?

A.pull_request: branches: [main]
B.pull_request: types: [closed] branches: [main]
C.push: branches: [main]
D.release: types: [published]
AnswerB

Triggers only when a PR is closed (merged) to main.

Why this answer

Option C is correct because the 'pull_request' event with type 'closed' and branch filter 'main' triggers when a PR is merged (closed) to main. Option A is wrong because 'push' triggers on every push, not just PR merges. Option B is wrong because 'pull_request' without type triggers on all PR events, including opened, synchronize, etc.

Option D is wrong because 'release' triggers on release creation, not PR merge.

Practice this question →
316
MCQmedium

You are designing a build pipeline for a Java application hosted in Azure Repos. The pipeline needs to run unit tests, package the application as a JAR file, and publish the build artifact. Which task should you use to publish the JAR file as a pipeline artifact?

A.Publish Build Artifacts task
B.Copy Files task
C.Archive Files task
D.Publish Pipeline Artifact task
AnswerD

Publish Pipeline Artifact publishes files as pipeline artifacts that can be used in subsequent stages.

Why this answer

Option B is correct because the Publish Build Artifacts task is designed to publish files as build artifacts from a pipeline. Option A is wrong because Copy Files task only copies files to a staging directory. Option C is wrong because the Archive Files task creates a ZIP archive.

Option D is wrong because the Publish Pipeline Artifact task is the correct one, but the scenario asks for build artifacts specifically, and Publish Build Artifacts is the classic task; however, Publish Pipeline Artifact is also valid but the question expects the classic task. Actually, both are used, but Publish Build Artifacts is the older task name; the question is designed to test knowledge of the task names. In modern Azure DevOps, Publish Pipeline Artifact is preferred.

To avoid confusion, we'll adjust: Option B is Publish Pipeline Artifact. Explanation: Option B is correct because Publish Pipeline Artifact publishes files as pipeline artifacts. Option A is wrong because it only copies files.

Option C is wrong because it archives files. Option D is wrong because it's not a valid task name.

Practice this question →
317
MCQhard

You are designing a release pipeline that deploys to multiple environments (dev, test, prod) sequentially. You need to require manual approval before deploying to prod. The approver should be able to review the changes and approve or reject. Which feature should you use?

A.Pre-deployment conditions.
B.Environment checks.
C.Approval gates.
D.Manual intervention task.
AnswerC

Approval gates provide manual approval with review and reject.

Why this answer

Option B is correct because approval gates allow manual approval with review. Option A is wrong because pre-deployment conditions include approvals but the gate is the feature. Option C is wrong because it only requires a manual step, not a proper approval with rejection capability.

Option D is wrong because checks are for Azure environments.

Practice this question →
318
MCQmedium

Your Azure Pipelines build uses a self-hosted agent that runs on a Windows VM. The build fails with the error 'Access to the path 'C:\agent\_work\1\s\bin' is denied.' What is the most likely cause?

A.The agent service account does not have write permissions on the working directory
B.The agent is not configured to use the correct agent pool
C.The build is trying to overwrite a file that is locked by another process
D.The source code checkout failed due to incorrect credentials
AnswerA

The agent runs under a service account that needs write access to the working directory.

Why this answer

Option A is correct because the agent runs as a service with a specific account that may not have write permissions. Option B is wrong because the issue is not about checkout. Option C is wrong because the error is about access, not file in use.

Option D is wrong because the agent is registered and working.

Practice this question →
319
MCQmedium

You are setting up a release pipeline for an ASP.NET Core application that is deployed to Azure App Service (Windows). The application uses Entity Framework Core for database migrations. You need to automate the execution of database migrations during deployment, ensuring that the migrations run only once and that the application is not started until the migration completes. You also need to handle rollback in case the migration fails. The pipeline should deploy to staging slot, run migrations, swap to production, and then run post-swap migrations if needed. Currently, the pipeline deploys the code and then runs a script to execute 'dotnet ef database update'. However, during swap, the staging slot's migrations may conflict with production. What is the recommended architecture for handling database migrations with zero-downtime deployment?

A.Use Idempotent migrations and run them in the staging slot before swap. Then, after swap, run migrations again in the production slot to ensure any remaining changes are applied.
B.Run migrations only in the staging slot before swap. After swap, the production slot will use the new schema automatically.
C.Run migrations only after the swap is complete, in the production slot. The application is stopped during migration to avoid errors.
D.Disable automatic migration execution in the pipeline. Instead, have a separate manual process to run migrations using a dedicated tool.
AnswerA

Idempotent migrations can be run multiple times safely, and running them before and after swap ensures both slots have the correct schema without downtime.

Why this answer

Option C is correct because using Idempotent migrations allows you to run them before swap without affecting production, and running them again after swap ensures any additional changes are applied. Running migrations before swap ensures the staging slot has the updated schema, and after swap, the production slot also gets the updates. Idempotent migrations ensure that running them multiple times is safe.

Option A is wrong because running migrations only in staging before swap does not update production's database unless you run migrations after swap. Option B is wrong because running migrations only after swap causes downtime during migration. Option D is wrong because disabling automatic migration and using manual scripts adds risk and does not ensure zero-downtime.

Practice this question →
320
MCQhard

Your release pipeline deploys a .NET Core web app to Azure App Service using a slot swap strategy. The pipeline runs acceptance tests on the staging slot before swapping. After a recent change, the acceptance tests pass but the production site becomes unresponsive after the swap. What is the most likely cause?

A.The staging slot had different app settings that were swapped into production, causing the site to fail.
B.The acceptance tests are not comprehensive enough and missed a regression.
C.The acceptance tests should have been run after the swap.
D.The slot swap was not 'warm-up' and caused downtime.
AnswerA

Slot swap swaps all settings, so if staging settings are not suited for production, the site can become unresponsive.

Why this answer

Option C is correct because slot swap swaps the entire configuration including connection strings and app settings. If the staging slot had different configuration values that are incompatible with production, the swap can cause issues. Option A is wrong because the tests passed on staging.

Option B is wrong because slot swap is designed to be zero-downtime. Option D is wrong because the issue is not related to test failure but to configuration after swap.

Practice this question →
321
Multi-Selecteasy

Which TWO features of Azure Pipelines help you manage build artifacts across stages? (Choose two.)

Select 2 answers
A.Pipeline variables
B.Release gates
C.Build tags
D.Download Pipeline Artifact task
E.Publish Pipeline Artifact task
AnswersD, E

This task downloads artifacts.

Why this answer

Options A and D are correct. A allows sharing artifacts between stages. D allows downloading artifacts from a previous stage.

B is wrong because variables are not artifacts. C is wrong because build tags are for filtering, not artifact management.

Practice this question →
322
Multi-Selecthard

Which TWO of the following are valid strategies to reduce the build time of a container image in Azure Pipelines?

Select 2 answers
A.Combine multiple RUN commands into a single RUN instruction to reduce layers.
B.Build multiple images in parallel using matrix strategy.
C.Use Docker layer caching with a registry cache.
D.Disable security scanning for the image.
E.Use a larger build agent with more CPU cores.
AnswersB, C

Parallel builds can reduce overall time.

Why this answer

Options A and D are correct. Option A reduces build time by reusing cached layers. Option D reduces build time by parallelizing image builds.

Option B is wrong because using a larger agent may not reduce build time if the bottleneck is network or I/O. Option C is wrong because running all commands in a single layer reduces layers but does not significantly reduce build time. Option E is wrong because skipping security scanning does not reduce build time.

Practice this question →
323
MCQhard

You have a classic release pipeline that deploys to Azure App Service. You need to implement a canary deployment strategy where 10% of traffic is routed to the new version for 30 minutes before full rollout. What should you use?

A.Configure multiple deployment slots and use Traffic Manager to distribute traffic.
B.Use the 'Azure App Service deploy' task with the 'Deploy to Slot' option, then manually adjust routing rules.
C.Deploy to a staging slot and then use Azure CLI to update routing rules after deployment.
D.Use slot swap with 'Swap with preview' and set traffic percentage in the swap settings.
AnswerD

Swap with preview allows you to validate and gradually increase traffic before full swap.

Why this answer

Azure App Service deployment slots with slot swap with preview allow you to route a percentage of traffic to the new version before swapping fully.

Practice this question →
324
MCQmedium

Your team uses Azure Pipelines with GitHub for source control. You need to ensure that whenever a pull request is created against the main branch, a validation build runs automatically. Which YAML trigger should you configure in the pipeline?

A.pr: branches: include: - main
B.pr: main
C.trigger: branches: exclude: - main
D.trigger: main
AnswerB

Correct: PR trigger on main runs validation builds for PRs targeting main.

Why this answer

Option A is correct because the pr trigger on main runs a validation build on pull requests targeting main. Option B is wrong because branches spec limits PR trigger to branches when PR source is from that branch. Option C is wrong because trigger is for CI builds, not PR validation.

Option D is wrong because exclude removes branches from CI trigger.

Practice this question →
325
MCQeasy

Your organization uses Azure DevOps and GitHub. You need to ensure that secrets such as API keys are not exposed in pipeline logs. What should you do?

A.Store the API key in a plain text variable and reference it as $(apiKey)
B.Store the API key in Azure Key Vault and use a variable group linked to the vault
C.Store the API key in a secret variable
D.Use the Logging Command to suppress output
AnswerC

Secret variables are masked in logs.

Why this answer

Azure Pipelines allows marking variables as secret, which hides them in logs. Option A is wrong because environment variables still appear in logs. Option C is wrong because Azure Key Vault stores secrets but you need to map them to secret variables.

Option D is wrong because logging warnings still expose the secret.

Practice this question →
326
MCQeasy

You are setting up a build pipeline for a Node.js application that uses npm for package management. The pipeline should restore npm packages on every build, but you want to leverage caching to speed up the process. The pipeline runs on a Microsoft-hosted agent. You also need to ensure that the build fails if any npm audit vulnerabilities are found. Which tasks and configuration should you use?

A.Use the 'npm' task with 'custom' command to run 'npm ci'. Use the 'Cache' task to cache 'node_modules' with a key based on 'package.json'.
B.Use the 'npm' task with 'install' command without caching. After install, run a PowerShell script to run 'npm audit --audit-level=high' and parse the output.
C.Use the 'npm' task with 'ci' command and set 'ignoreScripts' to true. Add a 'npm audit' task but set 'failOnVulnerabilities' to 'false' to avoid build failures.
D.Use the 'npm' task with 'install' command and enable caching by setting the 'workingDirectory' variable. Run a separate 'npm' task with 'audit' command and set 'failOnVulnerabilities' to 'true'.
AnswerD

This is the correct approach: restore, cache, and audit with fail on vulnerabilities.

Why this answer

The npm task with 'install' restores packages, and the 'npm audit' command checks for vulnerabilities. Caching is done with the Cache task using a key based on package-lock.json.

Practice this question →
327
MCQhard

Refer to the exhibit. You deploy this Bicep template to create an Azure App Service with a custom container. The deployment succeeds, but the container fails to start with an error 'Container didn't respond to HTTP pings'. What is the most likely missing configuration?

A.The template is missing the 'healthCheckPath' property in siteConfig.
B.The container image is not publicly accessible.
C.The WEBSITES_ENABLE_APP_SERVICE_STORAGE should be set to 'true'.
D.The template is missing the app setting 'WEBSITES_PORT'.
AnswerA

The health check path should be configured to match the container's endpoint.

Why this answer

Option D is correct because the container needs a health check path; the default is '/', but the container may expect a different path. Option A is wrong because the docker image is specified. Option B is wrong because the storage setting is not critical.

Option C is wrong because the app setting is present.

Practice this question →
328
MCQhard

Your team is adopting Infrastructure as Code (IaC) using Bicep. You have a multi-stage YAML pipeline that deploys Azure resources to dev, test, and prod environments. You need to ensure that the Bicep files are validated and deployed consistently, and that any changes to the infrastructure are approved for production. You also want to use the latest version of the Azure CLI task. What is the recommended approach?

A.Use the Azure Resource Manager Template Deployment task with the 'templateLocation' parameter pointing to the compiled ARM JSON.
B.Create three separate pipelines for each environment, each using the ARM Template Deployment task.
C.Use the AzureCLI task with inline script to run 'az deployment group validate' and 'az deployment group create'. Add environments with approval gates for production.
D.Use a PowerShell task with the 'New-AzResourceGroupDeployment' cmdlet.
AnswerC

AzureCLI supports latest Bicep and validation.

Why this answer

Option A is correct because it uses AzureCLI task with Bicep commands and environments for approvals. Option B is incorrect because ARM template deployment task may not support latest Bicep features. Option C is incorrect because PowerShell task lacks native Bicep support.

Option D is incorrect because separate pipeline per environment duplicates.

Practice this question →
329
Multi-Selecthard

Which THREE options are valid strategies to reduce build times in Azure Pipelines? (Choose three.)

Select 3 answers
A.Enable incremental builds by using the 'Clean: false' option.
B.Use a self-hosted agent with a local cache of dependencies.
C.Break the pipeline into multiple stages running sequentially.
D.Increase the number of parallel jobs in the pipeline.
E.Use the 'Cache' task to cache folders like node_modules or .m2.
AnswersA, B, E

Incremental builds only rebuild changed code.

Why this answer

Valid strategies: using a self-hosted agent with caching (A), using incremental builds (B), and using pipeline caching (D). Option C is wrong because increasing parallel jobs does not reduce build time for a single pipeline; it allows more builds to run concurrently but each build takes the same time. Option E is wrong because using multiple stages does not reduce build time; it adds sequential dependencies.

Practice this question →
330
MCQmedium

Your team uses Azure Pipelines for CI/CD. You need to ensure that a secret variable stored in Azure Key Vault is available to a build pipeline without exposing it in logs. What should you do?

A.Store the secret in a variable group linked to Key Vault and reference it without marking it secret.
B.Add the secret as a plain text variable in the pipeline YAML.
C.Use a Key Vault task to fetch the secret and map it to a pipeline variable marked 'secret'.
D.Add the secret to the repository's .env file and use a script to read it.
AnswerC

Key Vault task with secret mapping prevents logging.

Why this answer

Option C is correct because mapping a Key Vault secret to a pipeline variable and marking it as 'secret' ensures it is not logged. Option A is wrong because inline secrets are logged. Option B is wrong because variable groups don't automatically mask secrets.

Option D is wrong because secret variables are not available in checkout tasks.

Practice this question →
331
MCQhard

Your YAML pipeline uses a self-hosted agent pool. You need to ensure that only the pipeline can trigger builds on that pool, preventing other projects from using it. What should you do?

A.Set the agent pool to 'Disabled' for other projects
B.Configure pipeline permissions in the agent pool security settings
C.Use a deployment group instead of an agent pool
D.Create a separate agent pool for each project
AnswerB

Why this answer

Option B is correct because Azure DevOps agent pool security settings allow you to restrict which pipelines or projects can use a specific agent pool. By configuring pipeline permissions, you can grant the 'Use' permission only to the intended pipeline, preventing other projects from triggering builds on that pool. This ensures exclusive access without disabling the pool for all other uses.

Exam trap

The trap here is that candidates often confuse disabling the pool for other projects (Option A) with permission-based restrictions, not realizing that disabling removes all access, including the intended pipeline's ability to use it.

Why the other options are wrong

A

Disabling the pool prevents all usage, including the intended pipeline.

C

Deployment groups are for targeting specific servers, not for access control.

D

That would work but is not necessary; you can secure a single pool with permissions.

Practice this question →
332
Multi-Selecteasy

You are configuring a continuous integration (CI) trigger for your YAML pipeline. The trigger should run the pipeline when changes are pushed to the 'main' branch or any release branch matching 'release/*'. Which TWO trigger configurations are valid? (Choose two.)

Select 2 answers
A.trigger: branches: exclude: - main
B.trigger: branches: include: - main
C.branches: include: - main
D.trigger: branches: main
E.trigger: branches: include: - release/*
AnswersB, E

Correct: includes main branch.

Why this answer

Options A and B are correct. Option A uses exact branch name. Option B uses wildcard for release branches.

Option C is wrong because 'include' should be a list. Option D is wrong because 'branches' is nested under 'trigger'. Option E is wrong because 'exclude' is not needed.

Practice this question →
333
MCQmedium

You are implementing a CI pipeline for a Node.js application. The pipeline must run unit tests and generate code coverage reports. You want to publish the coverage results to Azure DevOps and enforce a minimum coverage threshold of 80%. Which tasks should you use?

A.Use the Publish Test Results task to publish coverage data.
B.Use the Publish Build Artifacts task with coverage files.
C.Use the Copy Files task to copy coverage files and then the Publish Build Artifacts task.
D.Use the Publish Code Coverage Results task and configure the threshold in the task settings.
AnswerD

This task publishes coverage and can enforce thresholds.

Why this answer

PublishCodeCoverageResults publishes coverage reports, and the threshold can be enforced via a script or gate. Option A is wrong because CopyFiles copies files, not coverage. Option C is wrong because PublishTestResults publishes test results, not coverage.

Option D is wrong because PublishBuildArtifacts publishes build artifacts, not coverage.

Practice this question →
334
MCQeasy

You need to deploy a web app to Azure App Service using Azure Pipelines. The deployment slot should be 'staging' first, and after smoke tests, swap to production. Which deployment strategy should you use?

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

Azure App Service slots allow deploying to staging and swapping to production.

Why this answer

Option B is correct because slot swap allows deploying to staging and swapping to production. Option A is wrong because rolling update updates instances gradually without slots. Option C is wrong because blue-green requires separate environments.

Option D is wrong because canary routes a small percentage of traffic.

Practice this question →
335
MCQeasy

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

A.Production slot
B.Warmup slot
C.Staging slot
D.All slots simultaneously
AnswerC

Deploy to staging, then swap to production for zero-downtime.

Why this answer

Option B is correct because you should deploy to a non-production slot (e.g., staging), then swap it with the production slot. Option A is wrong because deploying directly to production defeats the purpose of slot swap. Option C is wrong because Azure DevOps does not have a 'warmup' slot.

Option D is wrong because you should deploy to a specific slot, not all slots.

Practice this question →
336
Multi-Selectmedium

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

Select 2 answers
A.Add a post-deployment approval on the staging stage.
B.Add a pre-deployment approval on the production stage.
C.Set the trigger to 'After release' and filter by artifact.
D.Set the deployment queue setting to 'After previous deployment' for the production stage.
E.Add a gate that checks if the staging deployment succeeded.
AnswersB, D

Requires manual approval before deploying to production.

Why this answer

You need to set the deployment queue setting to 'After previous deployment' to enforce order (C) and add a pre-deployment approval (E). Option A is wrong because a post-deployment approval on staging would approve after staging, not before production. Option B is wrong because a trigger on artifact source is not needed.

Option D is wrong because gates evaluate conditions but don't enforce order or approvals.

Practice this question →
337
MCQhard

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

A.The reference function cannot be used in a properties object.
B.The reference function syntax is incorrect.
C.The Application Insights component is not defined as a resource in the template.
D.The apiVersion for the config resource is outdated.
AnswerC

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

Why this answer

Option A is correct because the reference function cannot reference a resource that is not defined in the template unless it exists already. Option B is wrong because the expression syntax is correct for ARM. Option C is wrong because apiVersion is valid.

Option D is wrong because the reference function can be used in outputs if the resource is defined.

Practice this question →
338
MCQmedium

Refer to the exhibit. You run the Kusto query in Azure Monitor to analyze pipeline performance. The query returns no results even though you know some pipelines have average durations over 10 minutes. What is the most likely reason?

A.The column name 'RunStartTime' is incorrect; the actual column may be 'StartTime'.
B.The 'avg' function ignores values over 600, so no rows are returned.
C.The 'ago(7d)' function is not supported in Azure Monitor.
D.The 'RunDurationSeconds' column stores durations as strings, so the average cannot be calculated.
AnswerA

If the column name is wrong, the query returns no results.

Why this answer

Option B is correct because the query filters by 'RunStartTime' but the column is likely named differently (e.g., 'StartTime'). The KQL query uses an incorrect column name. Option A is wrong because the 'ago' function works correctly.

Option C is wrong because the query would return results even if durations are stored as integers. Option D is wrong because averaging does not filter out results over 600.

Practice this question →
339
Multi-Selectmedium

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

Select 2 answers
A.Store the Key Vault name and secret names in a secure file in the repository.
B.Define secrets as pipeline variables and mark them as secret.
C.Grant the Azure DevOps service principal 'Get' and 'List' permissions on the Key Vault.
D.Use the 'Azure CLI' task to run 'az keyvault secret show' for each secret.
E.Use the 'Azure Key Vault' task to download secrets as pipeline variables.
AnswersC, E

Necessary for the pipeline to access secrets.

Why this answer

To securely use secrets from Azure Key Vault, you should grant the build service principal access to the vault (A) and use the 'Azure Key Vault' task to download secrets as variables (D). Option B is wrong because checking in secrets to the repository defeats the purpose of Key Vault. Option C is wrong because secrets should be stored in Key Vault, not as pipeline variables.

Option E is wrong because the Key Vault task can directly retrieve secrets without using the Azure CLI.

Practice this question →
340
MCQmedium

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

A.The script type 'pscore' is not supported on Ubuntu.
B.The variable 'resourceGroupName' uses $(environment) which cannot reference a parameter.
C.Parameters cannot be used in YAML pipelines; they must be defined in a template.
D.The 'trigger: none' prevents the pipeline from running.
AnswerB

Parameters are accessed via ${{ parameters.environment }} in variables.

Why this answer

Option A is correct. In Azure Pipelines, variables defined in YAML using 'variables' can reference parameters using ${{ parameters.environment }} but not $(environment). The macro syntax $(variable) is for runtime variables, but 'environment' is a parameter.

So $(environment) is not resolved. Option B is incorrect because parameters can be used in templates. Option C is not the issue.

Option D is incorrect because the script type is valid.

Practice this question →
341
MCQhard

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

A.Use variable groups linked to environments
B.Use the 'variables' section in the pipeline YAML with conditions
C.Define variables in each stage of the YAML pipeline
D.Store all variables in Azure Key Vault and reference them in the pipeline
AnswerA

Variable groups can be scoped to environments.

Why this answer

Variable groups allow sharing common variables across pipelines and overriding per environment. Option A is wrong because stage-level variables duplicate per stage. Option B is wrong because Azure Key Vault stores secrets, not all variables.

Option D is wrong because the variables section in YAML is still duplicated.

Practice this question →
342
MCQeasy

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

A.condition: eq(variables['Build.SourceBranch'], 'refs/heads/main')
B.condition: eq(variables['Build.SourceBranch'], 'main')
C.condition: and(succeeded(), eq(variables['System.PullRequest.TargetBranch'], 'main'))
D.condition: ne(variables['Build.Reason'], 'PullRequest')
AnswerA

Why this answer

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

Exam trap

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

Why the other options are wrong

B

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

C

This checks PR target branch, not the source branch.

D

This excludes PRs but does not limit to main branch.

Practice this question →
343
MCQhard

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

A.Incremental
B.Complete
C.Validate
D.CreateOrUpdate
AnswerA

Why this answer

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

Exam trap

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

Why the other options are wrong

B

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

C

Validate mode only validates the template without actually deploying resources.

D

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

Practice this question →
344
MCQeasy

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

A.Use a custom action to manually mask secrets in the logs.
B.Define secrets as environment variables directly in the workflow YAML.
C.Store secrets in GitHub repository secrets and reference them in workflows using ${{ secrets.SECRET_NAME }}. GitHub automatically masks secrets in logs.
D.After the workflow runs, delete the logs from GitHub.
AnswerC

This is the recommended approach; GitHub automatically redacts secrets.

Why this answer

Option A is correct because GitHub automatically redacts secrets in logs. Option B is incorrect because masking is automatic, not manual. Option C is incorrect because secrets should be stored in repository secrets, not environment variables in YAML.

Option D is incorrect because adding a step to delete logs does not prevent exposure.

Practice this question →
345
Multi-Selectmedium

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

Select 2 answers
A.Add a post-deployment approval gate to the Dev and QA stages.
B.Use the 'Approvals and gates' settings in the release pipeline stage.
C.Configure branch policy on the release branch to require approvals.
D.Add a 'Manual Validation' task in the YAML pipeline.
E.Add a pre-deployment approval gate to the Staging and Production stages.
AnswersB, E

Correct: Approval gates are configured per stage in release pipeline settings.

Why this answer

Option A is correct because pre-deployment approvals can be set on each stage. Option D is correct because approval gates are configured in the release pipeline editor. Option B is wrong because post-deployment approvals are after deployment.

Option C is wrong because branch policies are for PRs, not releases. Option E is wrong because YAML pipelines use 'approvals' keyword, not a separate task.

Practice this question →
346
MCQeasy

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

A.Use the 'overrides' keyword in the pipeline YAML to specify which steps to replace.
B.Create a copy of the template and modify the step directly.
C.Use a conditional 'if' statement in the template to skip steps based on a parameter.
D.Use template parameters with a 'steps' object that can be injected, and use the 'replace' keyword in the pipeline to override the step.
AnswerD

Template parameters allow injecting custom steps, and 'replace' can override specific steps.

Why this answer

Option D is correct because Azure DevOps YAML templates support parameterized steps objects, allowing a pipeline to inject a custom set of steps that replace the default ones defined in the template. The `replace` keyword is used within the template to designate a default steps object that can be overridden by the calling pipeline, enabling step-level customization without modifying the template file.

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
347
MCQhard

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

A.The 'DotNetCoreCLI@2' task does not support the counter expression.
B.The counter expression uses a variable that is not defined as a counter, causing it to reset.
C.The counter expression resets every time the pipeline runs because of the 'minorVersion' variable.
D.The counter expression is evaluated after the build steps, so it always returns 0.
AnswerB

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

Why this answer

Option A is correct because the counter expression uses 'minorVersion' as the seed, which is a string variable '0', not a numeric counter. The counter function expects a numeric seed to increment; using a variable that is not a counter expression itself causes the counter to reset each time. Option B is wrong because the counter is not resetting per run; it stays at 0.

Option C is wrong because the counter is evaluated at pipeline start, not per step. Option D is wrong because the counter is not related to the build task.

Practice this question →
348
MCQhard

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

A.Audit log monitoring
B.Secret scanning alerts
C.Required reviewers on workflows
D.Automatic log redaction
AnswerD

GitHub automatically redacts secrets from workflow run logs.

Why this answer

GitHub Actions automatically redacts secrets from logs when they are printed or used in commands. This is a built-in security feature.

Practice this question →
349
MCQmedium

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

A.Add a YAML template that includes the signing task and require all pipelines to extend it.
B.Set a branch policy requiring a signed build status.
C.Configure a manual approval gate on the build pipeline.
D.Use a Pipeline decorator to inject the signing task into every build pipeline.
AnswerD

Pipeline decorators inject tasks at runtime, ensuring every pipeline runs the signing step.

Why this answer

Option D is correct because Pipeline decorators allow injecting a task (like signing) into every pipeline without modifying each pipeline definition. Option A is wrong because requiring a manual approval gate does not enforce signing. Option B is wrong because branch policies control PR merges, not build steps.

Option C is wrong because YAML templates require explicit inclusion in each pipeline.

Practice this question →
350
MCQeasy

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

A.Publish Test Results task
B.Copy Files task
C.npm test
D.Publish Build Artifacts task
AnswerA

Publishes test results to Azure DevOps from various formats.

Why this answer

The 'Publish Test Results' task is specifically designed to publish test results in formats like JUnit, NUnit, etc., to Azure DevOps. Option A is wrong because 'npm test' only runs tests but doesn't publish results. Option B is wrong because 'Copy Files' only copies files.

Option D is wrong because 'Publish Build Artifacts' publishes build outputs, not test results.

Practice this question →
351
MCQeasy

Refer to the exhibit. The pipeline will trigger when changes are pushed to which branches?

A.All branches
B.The main branch and any branch starting with 'release/'
C.Only the main branch
D.Only branches starting with 'release/'
AnswerB

The includes specify main and release/*, which matches branches like release/v1.

Why this answer

Option C is correct because the trigger includes 'main' and 'release/*' branches, so any branch matching 'main' or starting with 'release/' will trigger the pipeline. Option A is wrong because it only includes main, not release/*. Option B is wrong because it includes all branches.

Option D is wrong because it only includes release/* branches.

Practice this question →
352
MCQhard

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

A.The variable 'BuildConfiguration' is misspelled.
B.The branch 'main' does not exist.
C.All agents in the pool are currently busy.
D.The pipeline definition ID is incorrect.
AnswerC

With no demands, the build can run on any agent. If all agents are occupied, the build will wait.

Why this answer

The build is queued but not starting. Since priority is normal and there are no demands, the most likely cause is that all available build agents are busy or the agent pool has no agents.

Practice this question →
353
MCQmedium

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

A.Use a Docker Compose task in the pipeline to start the database container before running integration tests.
B.Configure the pipeline to use a self-hosted agent that has the database already installed and running.
C.Install the database as a service in the pipeline using the Service Fabric task.
D.Use a PowerShell script in the pipeline to install and start the database on the build agent.
AnswerA

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

Why this answer

Option B is correct because Docker Compose allows you to define and run multi-container Docker applications, making it easy to spin up a database container for integration tests. Option A is incorrect because it requires manual steps and is not automated. Option C is incorrect because a self-hosted agent with preinstalled database reduces flexibility.

Option D is incorrect because it's not a feature of Azure DevOps.

Practice this question →
354
MCQmedium

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

A.Push trigger
B.Manual trigger
C.PR trigger
D.Scheduled trigger
AnswerC

PR trigger runs when a pull request is opened or updated.

Why this answer

Option B is correct because 'pr' trigger is specifically for pull request validation in GitHub. Option A is wrong because 'push' trigger runs on commits. Option C is wrong because 'schedules' trigger runs on a timer.

Option D is wrong because 'manual' is not a trigger type.

Practice this question →
355
MCQhard

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

A.Use a release pipeline with a pre-deployment approval and a post-deployment automatic rollback trigger.
B.Configure pre-deployment approvals on the production environment and use a post-deployment gate that fails the deployment.
C.Configure pre-deployment approvals and add a manual intervention task to roll back if health check fails.
D.Enable 'Auto-revert' on the production environment and set post-deployment conditions.
AnswerD

Auto-revert automatically rolls back on post-deployment failure.

Why this answer

In Azure Pipelines, environment approvals provide manual gate before deployment. The 'post-deployment auto-revert' feature can be enabled on the environment to automatically revert to the previous successful deployment if the post-deployment conditions (like health checks) fail. Option D is correct.

Option A is incorrect because the approval is pre-deployment, not post-deployment. Option B is incorrect because approvers cannot trigger rollback automatically. Option C is incorrect because 'Automatically revert' is the feature name.

Practice this question →
356
MCQmedium

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

A.Enable 'Auto-rollback' in the release pipeline settings.
B.Use a multi-stage YAML pipeline with manual intervention.
C.Configure pre-deployment approval gates.
D.Add a post-deployment script that runs a rollback script on failure.
AnswerD

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

Why this answer

Approval gates only pause deployment; they don't roll back. Pre-deployment conditions can check conditions but not automatically roll back. Rollback scripts in the pipeline can reverse changes if a failure is detected.

Using multiple stages doesn't automatically roll back; it just defines stages.

Practice this question →
357
Multi-Selectmedium

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

Select 3 answers
A.Azure Policy
B.Manual approval
C.Invoke Azure Functions
D.REST API
E.Query Azure Monitor alerts
AnswersC, D, E

Runs custom function code to evaluate conditions.

Why this answer

Option A is correct: 'Query Azure Monitor alerts' can be used as an automated gate to check for active alerts. Option B is correct: 'Invoke Azure Functions' can run custom logic to evaluate quality. Option C is correct: 'REST API' can call external services to check conditions.

Option D is incorrect because 'Manual approval' is not automated. Option E is incorrect because 'Azure Policy' is not a gate type in release pipelines, though it can be used via other integrations.

Practice this question →
358
Multi-Selectmedium

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

Select 2 answers
A.Grant the least privilege to service connections
B.Use Azure Key Vault to store secrets and fetch them at runtime
C.Use the default hosted agent for all builds
D.Store secrets as plain text in pipeline variables
E.Allow contributors to bypass the required reviewer policy
AnswersA, B

Least privilege minimizes potential damage.

Why this answer

Options B and D are correct. B reduces the attack surface by limiting permissions. D ensures secrets are not stored in code.

A is wrong because using the default agent may expose the pipeline to untrusted code. C is wrong because it bypasses security reviews.

Practice this question →
359
MCQeasy

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

A.The variable 'Build.SourceBranch' is misspelled; it should be 'Build.SourceBranchName'.
B.The condition syntax is correct but the branch name should not include 'refs/heads/'.
C.The variable 'Build.SourceBranch' is not available in the condition context.
D.The condition should be in a template expression instead of a runtime condition.
AnswerA

'Build.SourceBranchName' returns the branch name without 'refs/heads/'.

Why this answer

In Azure DevOps YAML pipelines, variables are evaluated at runtime. The correct way to reference the source branch variable is 'variables['Build.SourceBranch']' or '$(Build.SourceBranch)'. Option C is correct because the condition syntax 'eq(variables['Build.SourceBranch'], 'refs/heads/main')' is valid and should work; the issue is likely that the variable name is misspelled or the branch name is incorrect.

However, the most common mistake is using 'SourceBranchName' instead of 'SourceBranch'. Option A is incorrect because template expressions are evaluated at compile time, but conditions are runtime. Option B is correct: using 'SourceBranchName' would give only the branch name without 'refs/heads/'.

Option D is irrelevant.

Practice this question →
360
MCQmedium

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

A.Post-deployment approvals on the Production environment
B.Deployment queue settings on the Production environment
C.Deployment gates on the Production environment
D.Pre-deployment approvals on the Production environment
AnswerD

Correct: Pre-deployment approvals pause before deploying to that environment.

Why this answer

Option A is correct because pre-deployment approvals can be set on the Production environment. Option B is wrong because post-deployment approvals occur after deployment. Option C is wrong because gates are automated checks, not manual approvals.

Option D is wrong because deployment queue settings control parallelism, not approvals.

Practice this question →
361
MCQmedium

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

A.parameters:
B.arguments:
C.inputs:
D.variables:
AnswerA

Template parameters are defined under 'parameters'.

Why this answer

Option C is correct because 'parameters' is the correct YAML key to define template parameters. Option A is wrong because 'inputs' is for task inputs. Option B is wrong because 'variables' are for pipeline variables.

Option D is wrong because 'arguments' is not a valid key.

Practice this question →
362
MCQhard

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

A.Create separate pipelines for each service with path triggers, and create an additional comprehensive pipeline that triggers only when shared libraries change.
B.Keep the single pipeline but add caching for dependencies.
C.Use a single pipeline but add conditional stages to skip unchanged services.
D.Create separate pipelines for each service with path triggers, and disable the comprehensive pipeline.
AnswerA

This optimizes build time while preserving integration testing.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
363
MCQmedium

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

A.Allow only comment resolution.
B.Require a successful build before merging.
C.Limit merge types to squash merge.
D.Require a minimum number of reviewers.
AnswerD

This policy enforces code review before merge.

Why this answer

Option A is correct because a branch policy requiring pull request reviews enforces code review before merge. Option B is wrong because build validation is separate. Option C is wrong because it restricts direct pushes but doesn't enforce review.

Option D is wrong because commenting doesn't enforce review.

Practice this question →
364
MCQeasy

You ran the above Azure CLI command to check the deployment source of an Azure Web App. The web app is not deploying automatically when commits are pushed to the main branch. Based on the output, what is the most likely cause?

A.Deployment rollback is disabled, preventing automatic deployments.
B.The continuous deployment sync is not enabled; you need to enable it or configure a pipeline.
C.The branch is set to 'main' but commits are pushed to 'master'.
D.The repo URL uses GitHub but Azure Web Apps only supports Azure Repos.
AnswerB

The output shows the source but not that CD is active; likely sync is off.

Why this answer

Option D is correct because the output does not show a CI/CD trigger; it only shows the source. The web app may have disconnected sync. Option A is wrong because branch is main.

Option B is wrong because deployment rollback is disabled, which is fine. Option C is wrong because GitHub is supported.

Practice this question →
365
MCQmedium

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

A.The Prod environment requires manual approval before deployment.
B.The release definition ID 5 is incorrect.
C.The Prod environment has a pre-deployment condition that waits for the Dev environment to succeed.
D.The build artifact with ID 123 is not accessible.
AnswerC

By default, release environments can be set to deploy only after previous environments succeed, which would cause Prod to wait for Dev.

Why this answer

The release is created successfully with two environments: Dev and Prod. Dev is in progress, but Prod is not started. This suggests that the release pipeline is configured with a trigger condition that delays or gates the Prod deployment until after Dev completes successfully.

Also, note that 'preDeployApprovals' are empty, so approvals are not the issue.

Practice this question →
366
Multi-Selecteasy

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

Select 2 answers
A.pull_request: branches: [ main ]
B.push: branches: [ main ]
C.release
D.workflow_dispatch
E.schedule
AnswersA, B

Correct: Triggers on PR targeting main.

Why this answer

Options A and C are correct. Option A triggers on push to main. Option C triggers on pull request events targeting main.

Option B is wrong because workflow_dispatch is manual. Option D is wrong because schedule is time-based. Option E is wrong because release triggers on GitHub releases.

Practice this question →
367
MCQeasy

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

A.Use OpenID Connect (OIDC) with a federated identity credential.
B.Use the GITHUB_TOKEN to authenticate to Azure.
C.Use an SSH deploy key to authenticate to AKS.
D.Store an Azure service principal password as a GitHub secret.
AnswerA

OIDC allows passwordless authentication from GitHub Actions to Azure.

Why this answer

OpenID Connect allows workflows to authenticate to Azure without secrets by exchanging tokens. Option A is wrong because PATs are stored as secrets. Option C is wrong because SSH keys are for code access.

Option D is wrong because GitHub tokens are for GitHub API, not Azure.

Practice this question →
368
MCQmedium

You are configuring a YAML pipeline that deploys to multiple environments. The pipeline should automatically trigger when changes are pushed to the main branch, but only if the build artifact changes. Which trigger configuration should you use?

A.trigger: branches: include: - main
B.trigger: paths: include: - src/*
C.pr: branches: include: - main
D.resources: containers: - container: myContainer
AnswerB

Why this answer

Option B is correct because the `trigger: paths: include: - src/*` configuration specifies that the pipeline should only trigger when changes are pushed to the `main` branch AND those changes affect files under the `src/` directory. This ensures that the pipeline runs only when the build artifact (source code) changes, not for other changes like documentation or configuration files. The `paths` filter works in conjunction with the branch filter to provide fine-grained control over pipeline triggers.

Exam trap

The trap here is that candidates often confuse the `trigger` and `pr` keywords, or assume that a branch trigger alone is sufficient, forgetting that path filtering is required to restrict triggers to specific file changes.

Why the other options are wrong

A

This triggers on any change to main, regardless of artifact changes.

C

This triggers on pull request to main, not on pushes.

D

This defines a container resource, not a trigger.

Practice this question →
369
MCQeasy

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

A.Azure CLI authentication with a user account.
B.Azure Resource Manager service connection using a service principal.
C.Use a SAS token for the App Service.
D.Managed Identity assigned to the Azure DevOps agent.
AnswerB

Service principal provides secure, automated authentication.

Why this answer

Option B is correct because the Azure Resource Manager service connection with Service Principal authentication is the recommended and secure method. Option A is wrong because Azure CLI does not provide persistent service connection. Option C is wrong because Managed Identity is not directly used by Azure DevOps.

Option D is wrong because SAS tokens are for storage, not App Service.

Practice this question →
370
MCQmedium

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

A.Add the tool as a capability of the agent pool and use the 'Install Tool' task.
B.Add the 'Run Security Scan' task from the Azure DevOps marketplace.
C.Create a custom service hook to trigger the scan externally and wait for results.
D.Use a command-line task (e.g., Bash, PowerShell) to execute the security scan tool.
AnswerD

You can run any command-line tool installed on the agent via a script task.

Why this answer

Option C is correct because you can use a command-line script task (e.g., bash, PowerShell) to run the security scan tool installed on the agent. Option A is wrong because there is no generic 'Run Security Scan' task. Option B is wrong because the third-party tool may not have an API.

Option D is wrong because you would need to execute it, not just install it.

Practice this question →
371
MCQhard

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

A.Use managed identity for GitHub Actions and assign it to the AKS cluster
B.Store the service principal credentials in a Kubernetes secret in the AKS cluster
C.Store the service principal credentials as GitHub Actions secrets and reference them in the 'azure/login' action
D.Store the service principal credentials as environment variables in the workflow file
AnswerC

Secrets are encrypted and can be used securely with the 'azure/login' action.

Why this answer

Option B is correct because GitHub Actions secrets are encrypted and the 'azure/login' action can use them. Option A is wrong because environment variables are exposed in logs. Option C is wrong because the Kubernetes secret is for cluster secrets, not workflow secrets.

Option D is wrong because the service principal is not stored in AKS.

Practice this question →
372
MCQhard

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

A.Configure a rolling update with readiness and liveness probes
B.Use a blue-green deployment strategy
C.Use Helm charts with pre-upgrade hooks
D.Implement a canary deployment with manual verification
AnswerA

Kubernetes automatically rolls back if probes fail.

Why this answer

Option B is correct because Kubernetes deployment strategy with health probes enables automatic rollback. Option A is wrong because blue-green does not automatically rollback. Option C is wrong because canary does not automatically rollback.

Option D is wrong because Helm alone does not provide health check-based rollback.

Practice this question →
373
Multi-Selecthard

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

Select 3 answers
A.Encrypted variables in workflows
B.Organization-level secrets
C.Secret scanning alerts
D.Environment-specific secrets
E.Repository-level secrets
AnswersB, D, E

Organization secrets are available to all repositories in the organization.

Why this answer

Options B, C, and D are correct. Environments in GitHub Actions allow secret scoping, organization secrets are available across repos, and repository secrets are scoped to a single repo. Option A is secret scanning, which is a security feature but not for managing secrets across environments.

Option E is about encrypted variables, which is redundant with secrets.

Practice this question →
374
MCQeasy

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

A.Set 'trigger: none' in YAML
B.Set 'trigger: branches: include: - release/*'
C.Set 'trigger: branches: include: - main'
D.Set 'trigger: tags: include: - v*'
AnswerB

This triggers on any branch matching release/*.

Why this answer

Option C is correct because specifying a branch filter with wildcard triggers on release branches. Option A is wrong because it triggers on all branches. Option B is wrong because it disables CI.

Option D is wrong because it triggers on tags only.

Practice this question →
375
MCQmedium

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

A.The artifact is not downloaded to the expected path; the artifact name must be included in the path.
B.The wildcard pattern '*.zip' is not supported.
C.The Azure service connection has expired.
D.The pipeline is using a Microsoft-hosted agent that does not support the download task.
AnswerA

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

Why this answer

Option C is correct because the 'download: current' step downloads the artifact from the current pipeline run, but the artifact path usually includes the artifact name as a subfolder. The correct path would be '$(Pipeline.Workspace)/drop' or '$(Pipeline.Workspace)/drop/**/*.zip'. Option A is wrong because the service connection is unrelated to the artifact.

Option B is wrong because the wildcard is valid. Option D is wrong because the agent type does not affect artifact download behavior.

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

Ready to test yourself?

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

Start 20-question session