Thuta Learning
ExercisesDevOpsintermediate

Hands-On Practice Set 2

Relax. We'll talk through this in plain words — no textbook voice.

What you'll walk away with

  • Understand Hands-On Practice Set 2 without any of the intimidation
  • Get comfortable running the kubectl commands/YAML yourself
  • Apply this concept right away in a real project

Let's think about it this way for a moment

This round is a step up from round 1 — instead of practicing each skill in isolation, you'll need to combine them. That means deciding how to split config between ConfigMap and Secret, working out an HPA's min/max/target based on a traffic pattern, and writing up a production rollback plan as a document. Give each task around 10 minutes.

Let's connect this to a real scenario

Task 1: Split five pieces of config data (API_URL, LOG_LEVEL, DB_PASSWORD, FEATURE_FLAG, JWT_SECRET) between a ConfigMap and a Secret, and explain why you split them that way. Task 2: If a web app averages 50 req/sec but can spike to 500 req/sec at peak time, estimate the HPA's min/max replicas (assume one pod can handle ~50 req/sec). Task 3: If the error rate climbs to 20% after rolling out production deployment v3, write the sequence of commands you'd use to respond (a rollback plan). Task 4: Write an RBAC Role for this requirement: 'the CI/CD pipeline should only be allowed to update Deployments — no deleting pods, no viewing Secrets.'

Let's look at it together

text
# Task 2 - HPA sizing
Average: 50 req/sec, 1 pod handles ~50 req/sec -> min replicas ~= 1-2
Peak: 500 req/sec / 50 req/sec per pod = 10 pods needed at peak
-> min: 2 (headroom for normal spikes + 1 for safety)
-> max: 10 (covers documented peak)

# Task 3 - rollback plan
1. kubectl rollout status deployment/web-deployment  (confirm stuck/bad)
2. kubectl rollout undo deployment/web-deployment    (revert to last good)
3. kubectl rollout status deployment/web-deployment  (confirm recovery)
4. Check error rate metric back to baseline
5. File incident notes: what broke in v3, before retrying
You should see
You'll come away with criteria for splitting ConfigMap/Secret, an HPA sizing estimate, a rollback plan, and a scoped RBAC Role.

5-minute try-it

Actually run Task 3's rollback plan on a local minikube cluster (roll v1 → v2, then roll back) and time it — note how long it takes to fully roll back.

A quick word of caution

When writing an RBAC Role, don't casually reach for `"*"` (wildcard, allow everything) in the `verbs` list just because it seems like it'll 'probably cover it' — write out exactly the verb the requirement calls for (update), and nothing more.

Easy traps

  • Sizing an HPA based only on average traffic and never accounting for peak traffic — at peak time you can end up with too few pods and dropped requests
  • Writing a rollback plan that stops at 'once we roll back, we're done' and never documents root-cause investigation

Now try it yourself

Actually run Task 3's rollback plan on a local minikube cluster (roll v1 → v2, then roll back) and time it — note how long it takes to fully roll back.

You'll know it worked when: You'll come away with criteria for splitting ConfigMap/Secret, an HPA sizing estimate, a rollback plan, and a scoped RBAC Role.

Hands-On Practice Set 2 | Thuta Learning