AZ-400 Practice Question: Design and implement build and release pipelines

Answer analysis

Option-by-option breakdown

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

• ✗

  Manually redeploy the previous Helm chart version.

  Why it's wrong here

  Manually redeploying the previous Helm chart version is error-prone because you must locate the exact chart archive and the precise `values.yaml` that was used, then construct a new `helm upgrade` command that recreates the prior state. This approach bypasses Helm's versioned release history and can introduce unintended changes if the chart's defaults or dependent charts have drifted since the original deployment. It also consumes more time and human attention than a single-built-in rollback command, and it does not guarantee that the re-rendered manifests match the previously successful release. In contrast, Helm's rollback operates directly on the stored release revision, restoring the exact manifests and values that were applied at that revision.

• ✗

  Use a canary deployment strategy.

  Why it's wrong here

  A canary deployment strategy is fundamentally a progressive delivery technique for validating a new version by gradually shifting traffic while monitoring metrics; it is not designed as a rollback mechanism. If the canary detects a regression, the standard practice is to halt traffic to the new version, but the existing healthy version remains in place—it does not actively restore the cluster to a prior desired state. In a scenario where the current release is already broken and you need an immediate, clean revert, a canary approach adds unnecessary lead time and does not automatically replace the faulty deployment. Helm rollback, by contrast, performs a direct, atomic restoration of the previous release revision without needing to orchestrate traffic splitting or wait for observation windows.

• ✓

  Use Helm rollback command.

  Why this is correct

  The Helm rollback command is the correct approach because Helm maintains an ordered release history for each release name, with every deployment sequence stored as an immutable revision that includes the rendered manifests, values, and metadata. Executing `helm rollback <RELEASE> <REVISION>` instructs Helm to perform an in-place upgrade using the exact templates and values from that prior revision, thereby reinstating the known-good configuration atomically and quickly. This operation is fully tracked by Helm, incrementing to a new revision, so the release state and history remain internally consistent for subsequent upgrades or further rollbacks. Unlike manual redeployments or kubectl-level actions, Helm rollback does not require reconstructing old charts or reconciling drift—it simply reapplies the previously successful applied state.

• ✗

  Use a Kubernetes Deployment rollout undo.

  Why it's wrong here

  Using `kubectl rollout undo` on a Kubernetes Deployment is tempting because it can quickly revert the Pod template to the previous ReplicaSet, but it bypasses Helm's release tracking entirely. When you modify a Deployment directly with kubectl, Helm is unaware of that change; its release history still records the original (faulty) revision as the latest applied state. On the next `helm upgrade` or `helm rollback`, Helm will compare its stored manifests against the cluster and may attempt to overwrite or confuse the drift, leading to unpredictable behavior or forcing manual reconciliation. Moreover, `kubectl rollout undo` only operates on Deployment resources, whereas Helm manages a chart as a whole—including Services, ConfigMaps, Secrets, and Ingress—so it cannot restore the complete release state that a Helm rollback accomplishes.

Go deeper

Related to this question