AZ-400 Deployment Patterns 4 — Questions and Answers
Question 1: A company wants to reduce risk by deploying changes to a small cluster of servers before the full fleet. This pattern is best described as:
- Blue-green
- Canary or ring deployment (Correct answer)
- Shadow deployment
- Recreate deployment
Correct answer: Canary or ring deployment
Deploying to a small subset first (canary) or to progressively larger rings limits blast radius before fleet-wide rollout.
Question 2: In Azure Pipelines, which YAML keyword defines a deployment job that tracks environment history and supports deployment strategies?
- job:
- task:
- deployment: (Correct answer)
- stage:
Correct answer: deployment:
The 'deployment:' job type in Azure Pipelines YAML links to an environment, records deployment history, and supports strategy blocks like runOnce, rolling, or canary.
Question 3: What is the purpose of the 'postRouteTraffic' lifecycle hook in an Azure Pipelines canary strategy?
- To run tests before any traffic is routed to the canary
- To execute steps after canary traffic has been routed, typically for monitoring or validation (Correct answer)
- To permanently remove the old version
- To scale up the canary to 100%
Correct answer: To execute steps after canary traffic has been routed, typically for monitoring or validation
postRouteTraffic runs after traffic is shifted to the canary, allowing teams to run smoke tests or observe metrics before deciding to roll out or roll back.
Question 4: You are implementing a deployment pipeline for a microservices app. Which practice ensures each service can be deployed independently without breaking consumers?
- Deploying all services together in a single pipeline
- Using consumer-driven contract testing (e.g., Pact) before deployment (Correct answer)
- Sharing a single database across all services
- Running all integration tests only in production
Correct answer: Using consumer-driven contract testing (e.g., Pact) before deployment
Consumer-driven contract tests verify that a service's API still satisfies its consumers' expectations, enabling safe independent deployments.
Question 5: An Azure release pipeline's pre-deployment gate queries Application Insights for the exception rate. The gate is configured with a 'Stabilization Time' of 5 minutes. What does this mean?
- The gate waits 5 minutes after the previous stage finishes before starting evaluation (Correct answer)
- The gate ignores the first 5 minutes of data to let metrics stabilize after deployment
- The gate runs for exactly 5 minutes then auto-approves
- Deployments are throttled to one per 5 minutes
Correct answer: The gate waits 5 minutes after the previous stage finishes before starting evaluation
Stabilization time is a delay after the stage or trigger before the gate begins its first evaluation, giving the system time to settle.
Question 6: Which Azure DevOps Environments feature provides a visual audit trail of all deployments to a target resource?
- Pipeline run logs only
- Environment deployment history with commit, requester, and duration details (Correct answer)
- Azure Monitor dashboards
- Azure Policy compliance reports
Correct answer: Environment deployment history with commit, requester, and duration details
Azure Pipelines Environments maintain a deployment history per resource, showing which commit was deployed, by whom, and when.
Question 7: A team wants to use Terraform in their Azure pipeline to implement infrastructure-as-code with drift detection. Which gate or task pattern best detects configuration drift before deployment?
- Run 'terraform apply' directly in the pipeline without plan
- Run 'terraform plan' and fail the gate if the plan shows unexpected changes (Correct answer)
- Use Azure Policy deny effects only
- Use ARM What-If only, not Terraform
Correct answer: Run 'terraform plan' and fail the gate if the plan shows unexpected changes
Running 'terraform plan' and inspecting output (or using OPA/Sentinel policies on the plan) detects drift and unintended changes before 'apply' is executed.
A company wants to reduce risk by deploying changes to a small cluster of servers before the full fleet.
This pattern is best described as: