Kubernetes · Orchestration under pressure
What Kubernetes practices do you insist on in production?
Short answer
Pin images, set requests and limits, use probes and disruption budgets, apply least-privilege RBAC, enforce network and pod security, and manage everything through reviewed declarative manifests.
Production readiness is a set of defaults, not a checklist applied once. Workloads should be declarative, versioned and reproducible. Images should be pinned by digest, configuration should be externalized, and every service should have an owner, a Service, probes and a disruption budget.
- Set requests and limits from measured usage, not guesses
- Use readiness, liveness and startup probes with realistic thresholds
- Pin image digests and scan them; never deploy latest to production
- Apply least-privilege RBAC and dedicated ServiceAccounts
- Enforce default-deny NetworkPolicy and restricted Pod Security
- Use ResourceQuota and LimitRange per namespace
- Keep manifests in Git and deploy through a reviewed pipeline
kubectl rollout status deployment/api -n production
kubectl get pdb,networkpolicy,resourcequota -n production
kubectl auth can-i --list --as=system:serviceaccount:production:api
kubectl drain node-1 --ignore-daemonsets --delete-emptydir-dataOperational practices matter as much as manifests: capacity headroom, tested restores, upgrade plans, etcd backups for self-managed clusters, and clear ownership for alerts. A cluster is a product with users, not a one-time installation.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1How do you enforce these practices across many teams?
- 2What is the minimum set of guardrails for a new cluster?
- 3How do you balance platform standards with team autonomy?
- 4What would you prioritize in the first 90 days of owning a cluster?
Say it in the interview
I insist on pinned images, measured requests and limits, real probes, disruption budgets and least-privilege identity. On the platform side I want namespace quotas, default-deny network policy, restricted pod security and Git-based reviewed deployments. I also care about tested restores, upgrade plans and ownership for alerts, because manifests alone do not make a cluster operable. I add complexity only when it solves a problem the team can actually run.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Kubernetes mock interview and get scored feedback on depth, clarity and confidence.