AZ-400 Release Management 4 — Questions and Answers
Question 1: A company uses Azure Key Vault to store secrets. How should a release pipeline securely access these secrets without hardcoding them?
- Link the Key Vault as a variable group and reference variables in the pipeline (Correct answer)
- Pass secrets as plain-text pipeline variables
- Encode secrets in Base64 and store in pipeline YAML
- Use the Azure CLI task to echo secrets into environment variables
Correct answer: Link the Key Vault as a variable group and reference variables in the pipeline
Linking an Azure Key Vault to a variable group in Azure DevOps dynamically fetches secrets at runtime and exposes them as masked pipeline variables.
Question 2: What is the difference between a 'Runbook' gate and an 'Invoke Azure Function' gate in Azure Pipelines release pipeline?
- Runbook gates run PowerShell directly on agents; Azure Function gates run in the cloud
- Runbook gates execute Azure Automation runbooks; Azure Function gates invoke serverless HTTP-triggered functions (Correct answer)
- Runbook gates require approval; Azure Function gates do not
- There is no functional difference; both invoke scripts remotely
Correct answer: Runbook gates execute Azure Automation runbooks; Azure Function gates invoke serverless HTTP-triggered functions
The Runbook gate integrates with Azure Automation to run existing runbooks, while the Azure Function gate invokes an HTTP-triggered Azure Function for custom logic.
Question 3: In Azure DevOps, what is a 'release definition' (classic) equivalent to in YAML pipelines?
- A YAML pipeline file with stages defined under the 'stages' key (Correct answer)
- A branch policy in Azure Repos
- A deployment group configuration
- An artifact feed in Azure Artifacts
Correct answer: A YAML pipeline file with stages defined under the 'stages' key
In YAML pipelines, the stages section with deployment jobs and environments replicates the functionality of a classic release definition with its environments and stages.
Question 4: Which deployment strategy in Azure Pipelines YAML should be used to deploy to a percentage of targets first, verify health, then roll out to the rest?
- runOnce
- rolling
- canary (Correct answer)
- blueGreen
Correct answer: canary
The 'canary' deployment strategy in YAML pipelines deploys to a defined percentage of targets first, allows health checks, then proceeds to the remaining targets.
Question 5: A DevOps engineer needs to ensure that a failed deployment to production automatically triggers a rollback to the previous release. Which Azure Pipelines feature enables this?
- Pre-deployment approvals with rollback policy
- Automatic redeploy on failure in stage options (Correct answer)
- Post-deployment gate with rollback action
- Pipeline failure notifications
Correct answer: Automatic redeploy on failure in stage options
The 'Auto-redeploy trigger' option in a stage's deployment conditions can be configured to redeploy the last successful release when the current deployment fails.
Question 6: When using environments in Azure Pipelines YAML, what is the benefit of recording deployment history per environment?
- It reduces pipeline execution time by caching deployments
- It provides audit trails showing which commit and pipeline run deployed to each environment (Correct answer)
- It automatically encrypts environment-specific variables
- It prevents concurrent deployments across all pipelines
Correct answer: It provides audit trails showing which commit and pipeline run deployed to each environment
Environment deployment history tracks which pipeline runs deployed to an environment, what commit was deployed, and who triggered it, providing full deployment audit capability.
Question 7: A team wants to prevent multiple pipelines from deploying to the production environment simultaneously. Which Azure Pipelines environments feature handles this?
- Branch policies on the environment
- Exclusive lock on the environment (Correct answer)
- Approval gates requiring sequential sign-off
- Concurrent job limits on the agent pool
Correct answer: Exclusive lock on the environment
Setting an exclusive lock on a YAML pipeline environment ensures only one deployment job runs against that environment at a time, queuing others.
A company uses Azure Key Vault to store secrets.
How should a release pipeline securely access these secrets without hardcoding them?