docs: add Kubernetes CKS study notes

kubernetes/level 1/task-6.md

@@ -0,0 +1,85 @@
+# Assignment
+
+Earlier today, the Nautilus DevOps team deployed a new release for an application. However, a customer has reported a bug related to this recent release. Consequently, the team aims to revert to the previous version.
+
+
+There exists a deployment named nginx-deployment; initiate a rollback to the previous revision.
+
+Note: The kubectl utility on the jump-host has been configured to work with the Kubernetes cluster.
+
+# Solution
+
+# Rollback — `nginx-deployment` to the previous revision
+
+Revert the deployment to the revision that was live before the buggy release.
+
+> **Why no heredoc `apply` here:** a rollback isn't a declarative manifest operation. It
+> doesn't describe a desired end-state in YAML — it tells the Deployment controller to
+> switch back to a **previously recorded ReplicaSet revision** stored in rollout history.
+> That's an imperative rollout action, so `kubectl rollout undo` is the correct (and only
+> idiomatic) tool. Re-applying an old manifest would work only if you happened to still
+> have the exact prior YAML, and even then it's the wrong abstraction.
+
+## Command
+
+```bash
+# Roll back to the immediately previous revision
+kubectl rollout undo deployment/nginx-deployment
+
+# Block until the rollback finishes and pods are Ready
+kubectl rollout status deployment/nginx-deployment
+```
+
+## How it works
+
+### Rollout history and revisions
+
+Every change to a Deployment's pod template (image bump, env change, etc.) creates a new
+**revision**, each backed by its own ReplicaSet. Kubernetes retains old ReplicaSets (up to
+`spec.revisionHistoryLimit`, default 10) precisely so you can roll back. You can inspect
+them:
+
+```bash
+kubectl rollout history deployment/nginx-deployment
+```
+
+### What `rollout undo` does
+
+- With no `--to-revision` flag, it reverts to the **immediately previous** revision — the
+  one running before the current (buggy) release. That's exactly this task.
+- Mechanically, it scales the **previous ReplicaSet** back up and the **current** one down
+  using the same `RollingUpdate` strategy — so the rollback itself is gradual and keeps the
+  app serving, no full outage.
+- The rollback is recorded as a **new** revision in history (revisions move forward even
+  when the content is an older template), so you always have a clean audit trail.
+
+### Targeting a specific revision (if needed)
+
+If "previous" isn't the right target, pick an explicit revision from the history:
+
+```bash
+kubectl rollout undo deployment/nginx-deployment --to-revision=<N>
+```
+
+For this task the default (previous revision) is what's required, so no flag is needed.
+
+## Verify
+
+```bash
+# Rollback completed, pods Ready
+kubectl rollout status deployment/nginx-deployment
+
+# Confirm the image/template reverted to the prior version
+kubectl get deployment nginx-deployment \
+  -o jsonpath='{.spec.template.spec.containers[0].image}{"\n"}'
+
+# History shows a new revision at the top reflecting the rollback
+kubectl rollout history deployment/nginx-deployment
+```
+
+Expected — rollout reports success with all pods `Running`/`READY`, the container image
+reverted to the previous release's tag, and a new revision entry recording the rollback.
+
+> If the rollback stalls, `kubectl describe deployment nginx-deployment` and
+> `kubectl get pods -l <selector>` show what's blocking (e.g. the old image also failing to
+> pull).