Cloud Platforms, Containers, and Orchestration
This domain covers running workloads: cloud identity and network boundaries, container image construction, and the Kubernetes controls that decide whether a rollout is safe.
Core rules
- Shared responsibility: the provider secures physical and managed layers; you secure identity, configuration, data and network paths. Least-privilege IAM roles, no owner/root keys in workloads, workload identity or OIDC federation instead of static credentials.
- Images: multi-stage builds, minimal base (distroless or slim), non-root
USER, no build tools or secrets in final layers. Tag immutably by digest or git SHA and scan in CI. - Objects: Deployment → ReplicaSet → Pod; Services select pods by label; Ingress/Gateway routes from outside; ConfigMaps and Secrets inject configuration (Kubernetes Secrets are base64, not encrypted by default - enable etcd encryption and an external secret store).
- Probes: readiness controls Service endpoints, liveness restarts the container, startup shields slow-booting apps from liveness. Set requests and limits so scheduling and QoS behave; HPA scales on metrics; PodDisruptionBudget limits voluntary disruption during drains and upgrades.
- Rollouts:
maxSurge/maxUnavailable,kubectl rollout status,kubectl rollout undo. NetworkPolicy default-deny, RBAC least privilege, ResourceQuota per namespace.
Worked example
A Java service needs 90 seconds to warm up. Its liveness probe uses initialDelaySeconds: 10, periodSeconds: 10, failureThreshold: 3. Reasoning: the kubelet kills the container at roughly 40 seconds, before startup finishes; the pod never becomes Ready, the old ReplicaSet keeps serving, and the rollout churns in CrashLoopBackOff while surge pods are created and killed. Fix: add a startupProbe with periodSeconds: 10 and failureThreshold: 18 (a 180-second budget), keep the readinessProbe for traffic decisions, and reserve liveness for genuine deadlocks. Readiness failing removes endpoints without restarting - the correct signal for a warming application.
Traps
- Confusing liveness and readiness: aggressive liveness turns a slow dependency into a cluster-wide restart storm.
- Setting CPU limits far below requests (throttling) or omitting requests entirely so the scheduler overpacks nodes.
- Expecting a Deployment restart to pick up ConfigMap changes consumed as environment variables - the pod template must change (a checksum annotation does this).
- Mounting cloud credentials as Kubernetes Secrets instead of using workload identity.