AZ-400 Practice Question: The lead DevOps engineer for a large e-commerce…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Implement a canary deployment strategy with automated health checks and automatic rollback on failure.

  Why this is correct

  A canary deployment with automated health checks and automatic rollback is the correct choice because it incrementally routes a small percentage of production traffic to the new release, say 5%, then gradually increases it only if health checks pass. Automated checks monitor key signal like HTTP 5xx error rate, request latency, and custom application health endpoints, and if a threshold is breached, the release pipeline automatically reverts the routing to the previous stable version. This catches misconfigurations and regressions early with a minimal blast radius, preventing full-scale downtime. Unlike blue-green or a staged test deploy, it validates against real production load and configuration while keeping the majority of users on the safe version.

• ✗

  Use a blue-green deployment strategy with deployment slots in AKS.

  Why it's wrong here

  A blue-green deployment with AKS doesn't map cleanly because AKS has no native 'deployment slots' like Azure App Service; you'd manage two full environments yourself. More importantly, blue-green switches all production traffic to the new version at once, so if a health check fails after the switch, you've already exposed 100% of users to the broken configuration. Without additional automation (e.g., a separate watch dog that reverts the service selector), there's no automatic rollback on health check failure, meaning downtime until manual intervention. Canary avoids this by shifting only a small percentage of traffic first, so the bad release is caught before widespread impact.

• ✗

  Add a manual approval gate before the deployment to East US, requiring a tester to verify the deployment in West Europe.

  Why it's wrong here

  Requiring a manual approval gate after a deployment to West Europe does not protect a different region like East US, because configuration issues are often region-specific (e.g., Azure SQL firewall rules, regional key vaults, or CDN endpoints). A single tester manually verifying a deployment in West Europe is slow and can miss automated checks like load testing, error-rate spikes, or subtle logic errors that only manifest under real traffic. Moreover, this gate happens before the East US deployment, so it can't react to health issues that appear after traffic is shifted; there's no automatic rollback mechanism. Automated canary health checks provide continuous, objective validation on the actual East US environment and trigger rollback without human delay or regional blind spots.

• ✗

  Deploy to a separate test environment first, run integration tests, then deploy to production.

  Why it's wrong here

  A separate test environment often suffers from configuration drift, especially connection strings, feature flags, and environment-specific variables, which is exactly the type of misconfiguration that caused past incidents. Integration tests passing in test give false confidence because the production environment may have different secrets, network policies, or cluster-scoped settings. Even if tests pass, this approach doesn't add any post-deployment safety net; after deploying to production, there is no automated health check or rollback if the app fails with the actual production configuration. The canary strategy directly tests the real production environment with a subset of live traffic, so config mismatches are caught under authentic conditions.

Go deeper

Related to this question