More in Docker & Kubernetes — page 6
ConfigMap vs Secret
WHAT IT TESTS: Config-versus-sensitive-data separation. OUTLINE: ConfigMaps hold non-sensitive plain config; Secrets hold sensitive data, base64-encoded and treated specially (RBAC, optional encryption at rest).
Ingress resource vs Ingress controller
WHAT IT TESTS: Separating config from the engine. OUTLINE: The Ingress resource is declarative routing rules; the controller is the running proxy (NGINX, etc.) that reads them and serves traffic.
Restricting Pod ingress with a NetworkPolicy
WHAT IT TESTS: NetworkPolicy ingress control. OUTLINE: Create a NetworkPolicy with podSelector app=frontend, policyTypes Ingress, and one ingress from-rule matching podSelector role=api-gateway; requires a CNI that enforces policies.
kube-proxy and iptables vs IPVS modes
WHAT IT TESTS: How Service virtual IPs actually route. OUTLINE: kube-proxy watches Services/endpoints and programs node rules so ClusterIP traffic is DNAT'd to a backend Pod; iptables uses sequential rule chains, IPVS uses a hash table with real…
Debugging Service connectivity between Pods
WHAT IT TESTS: Systematic Service debugging. OUTLINE: kubectl get endpoints to check the Service has Pod IPs (selector match); kubectl describe service to verify selector and ports; exec into the frontend to curl the Service DNS name.
Headless Services and direct Pod DNS
WHAT IT TESTS: Understanding headless Services. OUTLINE: Set clusterIP: None so no virtual IP or proxy load balancing; DNS returns individual Pod IPs (A records). Primary use: StatefulSets needing stable per-Pod addressing.
Ingress for host and path routing
WHAT IT TESTS: Knowing when to use Ingress. OUTLINE: Use an Ingress with an Ingress controller for layer-7 host/path routing behind one external IP, instead of one cloud LoadBalancer per service.
Cross-namespace Service DNS resolution
WHAT IT TESTS: Knowledge of cluster DNS naming. OUTLINE: CoreDNS gives each Service a name; cross-namespace you must qualify it as my-service.B.svc.cluster.local (or my-service.B).
ClusterIP vs NodePort vs LoadBalancer
WHAT IT TESTS: Service type selection. OUTLINE: ClusterIP for internal-only access; NodePort opens a port on every node for basic external reach; LoadBalancer provisions a cloud load balancer for production external traffic.
Why Kubernetes Services exist
WHAT IT TESTS: Grasp of Pod IP instability. OUTLINE: Pod IPs are ephemeral and change on reschedule; a Service gives a stable virtual IP and DNS name plus load balancing across healthy Pods via label selectors.
Spreading Pods one-per-node for availability
WHAT IT TESTS: Pod anti-affinity knowledge. OUTLINE: Use required podAntiAffinity with topologyKey kubernetes.io/hostname matching the Deployment's own pod labels, so the scheduler refuses to co-locate two Pods on a node.
Stalled rollouts and progressDeadlineSeconds
WHAT IT TESTS: Understanding stalled rollouts. OUTLINE: With maxUnavailable respected, the rollout pauses partway and old Pods keep serving; progressDeadlineSeconds marks the Deployment as failed after no progress for that window.
Tuning maxSurge and maxUnavailable
WHAT IT TESTS: Rollout strategy tuning. OUTLINE: maxSurge allows Pods above desired; maxUnavailable allows Pods below desired during update. For zero downtime and speed, set maxUnavailable 0 and maxSurge high (e.g. 100%).
Sharing ephemeral cache between containers in a Pod
WHAT IT TESTS: Choosing the right ephemeral volume. OUTLINE: Use an emptyDir volume defined in the Pod spec and mounted into each container at the cache path; it is created with the Pod and deleted when the Pod is removed.
Liveness vs readiness probes
WHAT IT TESTS: Understanding probe semantics. OUTLINE: Liveness restarts a stuck container; readiness gates traffic by controlling Service endpoint membership. Readiness-only fits an app that pauses to reload a large cache but is still healthy.
Rolling back a bad Deployment
WHAT IT TESTS: Knowledge of Deployment rollback mechanics. OUTLINE: kubectl rollout undo deployment/NAME reverts to the prior revision by scaling the old ReplicaSet back up and the bad one down.
How a Deployment rolling update works
WHAT IT TESTS: Understanding of the Deployment-ReplicaSet relationship. OUTLINE: New image creates a new ReplicaSet; Deployment scales it up while scaling the old one down per maxSurge/maxUnavailable; old ReplicaSet is retained at zero for rollback.
Debugging a Pod in CrashLoopBackOff
WHAT IT TESTS: Practical Pod debugging instinct. OUTLINE: kubectl describe pod for events, restarts, and last state; kubectl logs (with --previous) for the crashed container's output.
Create a Deployment with 3 replicas via kubectl
WHAT IT TESTS: Basic kubectl Deployment fluency. OUTLINE: kubectl create deployment webapp --image=my-app:1.0, then kubectl scale to 3 replicas, or use --replicas if supported.
Deployment, ReplicaSet, and Pod hierarchy
WHAT IT TESTS: the ownership chain and rollout mechanics. OUTLINE: a Deployment manages ReplicaSets, each ReplicaSet keeps a set of identical Pods, and Deployments add rolling updates, rollback, and self-healing.