Upgrading and rolling back releases in Kubernetes - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Output of Helm upgrade command with dry-run

What is the output of the following Helm command when upgrading a release with the --dry-run flag?

Kubernetes

helm upgrade myapp ./mychart --dry-run

A Deletes the current release and installs a new one with the same name

B Simulates the upgrade and shows the rendered Kubernetes manifests without applying changes

C Upgrades the release and immediately rolls back if any error occurs

D Shows the history of previous releases for the given release name

💡 Hint

Think about what the --dry-run flag does in Helm commands.

The --dry-run flag simulates the upgrade process and outputs the Kubernetes manifests that would be applied, without making any changes to the cluster.

🧠 Conceptual

intermediate

Understanding Helm rollback behavior

When you run helm rollback myapp 2, what happens?

A The release named 'myapp' is reverted to the state it had in revision 2

B The release 'myapp' is deleted and a new release is installed with revision 2

C The release 'myapp' is upgraded to the latest revision ignoring revision 2

D The rollback command shows the differences between current and revision 2 without changing anything

💡 Hint

Rollback means going back to a previous version.

The helm rollback command reverts the release to the specified revision, restoring the previous state of the application.

❓ Troubleshoot

advanced

Troubleshooting failed Helm upgrade

You ran helm upgrade myapp ./mychart but the upgrade failed and the release is in a failed state. What is the best next step to recover the application?

A Run <code>helm rollback myapp</code> to revert to the previous working release

B Delete the release with <code>helm delete myapp</code> and reinstall it

C Run <code>kubectl delete pods -l app=myapp</code> to restart the pods

D Run <code>helm upgrade myapp ./mychart --force</code> to force the upgrade

💡 Hint

Think about how to restore a stable state after a failed upgrade.

Rolling back the release restores the last known good state, which is the safest way to recover from a failed upgrade.

🔀 Workflow

advanced

Correct sequence for upgrading and verifying a Helm release

What is the correct order of commands to upgrade a Helm release and verify it is running correctly?

A 1,3,2,4

B 1,4,2,3

C 2,1,3,4

D 1,2,3,4

💡 Hint

Think about upgrading first, then checking pods, then release status, then detailed pod info.

First upgrade the release, then check pods to see if they are running, then check release status, and finally describe pods for detailed info if needed.

✅ Best Practice

expert

Best practice for managing Helm release rollbacks in production

Which practice is best to minimize downtime and risk when rolling back a Helm release in production?

A Immediately delete the release and reinstall the previous version to ensure a clean state

B Manually edit Kubernetes resources to match the previous version before rolling back

C Use <code>helm rollback</code> combined with readiness probes and monitor pod status before confirming rollback success

D Force upgrade with <code>helm upgrade --force</code> to overwrite any issues without rollback

💡 Hint

Think about automation and monitoring during rollback.

Combining rollback with readiness probes and monitoring ensures the application is healthy before considering rollback complete, minimizing downtime and risk.