5 exercises — choose the best-structured answer to common Cloud Native Developer interview questions. Focus on precise vocabulary, correct use of technical terms, and demonstrating real experience.
Structure for Cloud Native answers
Tip 1: 12-factor app: config in environment, stateless processes, disposable processes, port binding
Tip 2: Kubernetes: Pod lifecycle, readiness vs liveness probes, HPA, resource requests vs limits
Tip 3: Service mesh: Istio/Linkerd for mTLS, traffic splitting, observability without code changes
Tip 4: GitOps: Argo CD, Flux — desired state in Git, reconciliation loop
0 / 5 completed
1 / 5
The interviewer asks: "What does the 12-factor app methodology mean in a Kubernetes context?" Which answer best demonstrates cloud-native application design knowledge?
Option B is strongest because it maps specific 12-factor principles to concrete Kubernetes primitives with the correct tooling at each layer. Key structure: Config → ConfigMaps/Secrets; Processes → stateless Pods; Disposability → SIGTERM + preStop; Logs → stdout → Fluentd; Dev/prod parity → Helm values files. Option A is a humorous misreading. Option C is false — the 12-factor principles remain foundational to cloud-native design. Option D conflates environment variable count with the methodology.
2 / 5
The interviewer asks: "What is the difference between a liveness probe and a readiness probe?" Which answer best demonstrates Kubernetes operations knowledge?
Option B is strongest because it gives the precise definition of each probe, their failure behaviours, correct use cases, and the critical anti-pattern that causes cascading failures. Key structure: liveness (fail → restart, internal only) vs. readiness (fail → remove from endpoints, no restart, upstream checks allowed). Option A is partially correct but misses the failure behaviour difference. Option C is factually wrong about both the purpose and frequency. Option D is wrong — both probes run continuously throughout the pod's lifetime.
3 / 5
The interviewer asks: "What is a service mesh and what problems does it solve?" Which answer best demonstrates cloud-native infrastructure depth?
Option C is strongest because it defines the service mesh mechanism (sidecar proxy), lists all four problem categories it solves with specific tooling, and explicitly states the trade-offs. Key structure: sidecar proxy → observability (tracing + golden signals) + mTLS security + traffic management CRDs + resilience patterns — at the cost of latency + complexity. Option A confuses a service mesh with an ingress controller. Option B confuses it with service discovery (DNS). Option D describes cert-manager for database TLS, not a service mesh.
4 / 5
The interviewer asks: "What is GitOps and how does it differ from traditional CI/CD?" Which answer best demonstrates GitOps principles?
Option B is strongest because it explains the GitOps mechanism (operator reconciliation loop), the three key differences from push-based CI/CD, and the prerequisite governance requirements. Key structure: Git = source of truth → operator pulls and reconciles → pull-based + self-healing + full audit trail via git history. Option A describes storing pipeline scripts in Git, not GitOps. Option C confuses GitOps with IaC — GitOps is a deployment pattern, not a provisioning pattern. Option D describes the opposite of GitOps governance.
5 / 5
The interviewer asks: "How do you manage secrets in a cloud-native application?" Which answer best demonstrates secrets management depth?
Option B is strongest because it covers the full secrets lifecycle: source control protection, external management, secure injection, RBAC, rotation, and the at-rest vs. in-transit distinction. Key structure: never in Git (Sealed Secrets/SOPS) → External Secrets Operator → mount not CLI args → RBAC → auto-rotation → etcd encryption + mTLS. Option A is dangerously wrong — base64 is not encryption; Kubernetes Secrets are only as secure as RBAC and etcd encryption. Option C (.env in image) bakes secrets into every container layer. Option D (manual kubectl) is not repeatable, auditable, or automatable.