AZ-400 Continuous Delivery & Release Management 5 — Questions and Answers
Question 1: A pipeline must deploy to three regions sequentially, failing fast if any region fails. Which YAML configuration achieves this?
- Three parallel jobs with no dependsOn
- Three stages each with dependsOn pointing to the previous stage and condition: succeeded() (Correct answer)
- One job with three deployment tasks and maxParallel: 1
- Three environments with a single approval gate
Correct answer: Three stages each with dependsOn pointing to the previous stage and condition: succeeded()
Chaining stages with dependsOn and condition: succeeded() ensures each region deploys only after the previous succeeds, providing sequential fail-fast behavior.
Question 2: What is the purpose of the 'Initialize Job' step that automatically appears at the start of every Azure Pipelines job?
- It installs required pipeline extensions
- It sets up the agent environment, downloads tools, and prepares the workspace (Correct answer)
- It pulls the latest source code from the repository
- It authenticates the service connection for the job
Correct answer: It sets up the agent environment, downloads tools, and prepares the workspace
The Initialize Job step prepares the hosted or self-hosted agent by setting environment variables, configuring the workspace, and downloading required agent capabilities.
Question 3: Which Azure Pipelines feature enables releasing the same build artifact to multiple environments in parallel rather than sequentially?
- Setting dependsOn to an empty array [] on multiple stages (Correct answer)
- Using deployment groups with parallel execution
- Configuring multiple CD triggers on the artifact
- Creating separate release pipelines for each environment
Correct answer: Setting dependsOn to an empty array [] on multiple stages
Setting dependsOn: [] on multiple stages removes their dependency on each other, allowing them to execute in parallel after their common predecessor completes.
Question 4: In Azure DevOps, what does 'continuous delivery' differ from 'continuous deployment'?
- Continuous delivery deploys every commit automatically; continuous deployment requires manual approval
- Continuous delivery ensures every build is release-ready but may require manual approval to deploy; continuous deployment automatically deploys every successful build (Correct answer)
- Continuous delivery applies only to infrastructure; continuous deployment applies to application code
- There is no difference; the terms are interchangeable in Azure DevOps
Correct answer: Continuous delivery ensures every build is release-ready but may require manual approval to deploy; continuous deployment automatically deploys every successful build
Continuous delivery automates the release process up to a production-ready state but may include a manual approval gate, while continuous deployment fully automates production releases without human intervention.
Question 5: A release fails in the 'Deploy to Staging' stage. Which built-in Azure release pipeline option can automatically retry the failed stage with the same artifact?
- Re-deploy option on the failed stage from the release summary (Correct answer)
- Auto-redeploy trigger with rollback condition
- Restart pipeline from the failed job using the YAML resume feature
- Re-queue the CI build and trigger a new release
Correct answer: Re-deploy option on the failed stage from the release summary
The 'Redeploy' option on a failed stage in the Azure release pipeline summary allows re-executing that stage without creating a new release.
Question 6: Which service connection type should be configured when an Azure Pipelines release needs to deploy resources to an AWS environment?
- Azure Resource Manager service connection
- Generic service connection with AWS endpoint
- AWS service connection via the AWS Toolkit for Azure DevOps extension (Correct answer)
- SSH service connection to an EC2 instance
Correct answer: AWS service connection via the AWS Toolkit for Azure DevOps extension
The AWS Toolkit for Azure DevOps extension provides a dedicated AWS service connection type that securely stores AWS credentials for use in pipeline tasks.
Question 7: What is the 'release retention policy' in Azure DevOps release pipelines used for?
- Limiting the number of concurrent release deployments
- Controlling how long release records and associated artifacts are kept before automatic deletion (Correct answer)
- Setting the maximum duration a deployment stage can run
- Defining which branches are eligible to trigger a release
Correct answer: Controlling how long release records and associated artifacts are kept before automatic deletion
Release retention policies define the number of days or number of releases to keep, after which Azure DevOps automatically deletes old release records and their stored artifacts.
A pipeline must deploy to three regions sequentially, failing fast if any region fails.
Which YAML configuration achieves this?