KAUSTUBHSHARMA.COM

Interview Question Bank

DevOps & Platform Interview Questions

DevOps, Kubernetes, observability, performance, and troubleshooting interview questions.

Click a question to reveal its answer and related guidance.

Q1A production API's latency doubled overnight. What do you investigate first?

What the interviewer is testing

  • Incident framing
  • Hypothesis-driven investigation
  • Safe mitigation

Real-World Sample Answer

I would approach “A production API's latency doubled overnight. What do you investigate first?” by clarifying the requirements first, then using these considerations: in a real interview, i would not jump straight to a technology choice. for “a production api's latency doubled overnight. what do you investigate first?”, i would first establish the exact time window and affected traffic. then i would compare application, infrastructure, database, and dependency signals and check deployments and traffic changes. i would also use logs, metrics, and traces to narrow the cause. finally, i would separate immediate mitigation from root-cause prevention. i would make the assumptions explicit and explain what evidence or production signals would make me revisit the decision.. I would state my assumptions and defend the trade-offs rather than presenting the choice as universally correct.

What a Strong Answer Should Cover

In a real interview, I would not jump straight to a technology choice. For “A production API's latency doubled overnight. What do you investigate first?”, I would first establish the exact time window and affected traffic. Then I would compare application, infrastructure, database, and dependency signals and check deployments and traffic changes. I would also use logs, metrics, and traces to narrow the cause. Finally, I would separate immediate mitigation from root-cause prevention. I would make the assumptions explicit and explain what evidence or production signals would make me revisit the decision.

Common Mistakes

  • Restarting services without evidence
  • Looking at only one metric
  • Stopping after mitigation

Interviewer Follow-ups

  • What assumptions would you clarify before committing to the design?
  • What changes if the scale, reliability target, security requirement, or budget changes?
  • What is the biggest failure mode in your proposed approach?
Q2When would you introduce caching, and how would you prevent stale or incorrect data from becoming a problem?

What the interviewer is testing

  • Performance reasoning
  • Consistency trade-offs
  • Invalidation strategy

Real-World Sample Answer

I would approach “When would you introduce caching, and how would you prevent stale or incorrect data from becoming a problem?” by clarifying the requirements first, then using these considerations: in a real interview, i would not jump straight to a technology choice. for “when would you introduce caching, and how would you prevent stale or incorrect data from becoming a problem?”, i would first identify the latency or load problem first. then i would choose what can safely be cached and define ttl or invalidation behavior. i would also consider cache stampedes, failures, and cold starts. finally, i would measure hit rate, latency, and correctness. i would make the assumptions explicit and explain what evidence or production signals would make me revisit the decision.. I would state my assumptions and defend the trade-offs rather than presenting the choice as universally correct.

What a Strong Answer Should Cover

In a real interview, I would not jump straight to a technology choice. For “When would you introduce caching, and how would you prevent stale or incorrect data from becoming a problem?”, I would first identify the latency or load problem first. Then I would choose what can safely be cached and define ttl or invalidation behavior. I would also consider cache stampedes, failures, and cold starts. Finally, I would measure hit rate, latency, and correctness. I would make the assumptions explicit and explain what evidence or production signals would make me revisit the decision.

Common Mistakes

  • Adding a cache before proving the bottleneck
  • Saying cache invalidation is not important
  • Ignoring cache failure behavior

Interviewer Follow-ups

  • What assumptions would you clarify before committing to the design?
  • What changes if the scale, reliability target, security requirement, or budget changes?
  • What is the biggest failure mode in your proposed approach?
  • Use the Interview Preparation learning paths and related site content to deepen any topic you could not confidently explain.
Q3What does a safe CI/CD pipeline need beyond build and deployment steps?

What the interviewer is testing

  • Quality gates
  • Supply-chain awareness
  • Release safety

Real-World Sample Answer

I would approach “What does a safe CI/CD pipeline need beyond build and deployment steps?” by clarifying the requirements first, then using these considerations: in a real interview, i would not jump straight to a technology choice. for “what does a safe ci/cd pipeline need beyond build and deployment steps?”, i would first automated tests and quality gates. then i would artifact integrity and dependency controls and environment promotion and approvals where justified. i would also observability and rollback. finally, i would auditability of who changed and released what. i would make the assumptions explicit and explain what evidence or production signals would make me revisit the decision.. I would state my assumptions and defend the trade-offs rather than presenting the choice as universally correct.

What a Strong Answer Should Cover

In a real interview, I would not jump straight to a technology choice. For “What does a safe CI/CD pipeline need beyond build and deployment steps?”, I would first automated tests and quality gates. Then I would artifact integrity and dependency controls and environment promotion and approvals where justified. I would also observability and rollback. Finally, I would auditability of who changed and released what. I would make the assumptions explicit and explain what evidence or production signals would make me revisit the decision.

Common Mistakes

  • Focusing only on deployment speed
  • Skipping security checks
  • No rollback or release evidence

Interviewer Follow-ups

  • What assumptions would you clarify before committing to the design?
  • What changes if the scale, reliability target, security requirement, or budget changes?
  • What is the biggest failure mode in your proposed approach?
  • Use the Interview Preparation learning paths and related site content to deepen any topic you could not confidently explain.
Q4A production API is intermittently timing out. Explain how you would isolate the failure and prevent recurrence.

What a Strong Answer Should Cover

  • Define the symptom and blast radius
  • Trace the request path
  • Use metrics and logs to narrow the bottleneck
  • Apply the smallest safe fix
  • Add prevention and verification steps

Common Mistakes

  • Jumping to a technology before clarifying the problem
  • Explaining the solution without the reasoning or trade-offs
  • Omitting verification, failure handling, or prevention

Interviewer Follow-ups

  • What signal would you trust first and why?
  • What is the smallest safe mitigation?
  • What prevention work should follow the incident?

What the interviewer is testing

  • Problem isolation and evidence-based reasoning
  • Safe mitigation and verification
  • Prevention and operational learning

Real-World Sample Answer

A strong real-world response should connect requirements to engineering decisions, explain why the chosen approach fits the constraints, and make failure, security, cost, observability, and verification explicit.

Q5A production API suddenly becomes slow. Walk through the first five things you would check before changing anything.

What a Strong Answer Should Cover

  • Confirm the symptom and time window
  • Check scope and affected users
  • Review recent changes
  • Compare application and dependency health
  • Use evidence before selecting a fix

Common Mistakes

  • Jumping to a technology before clarifying the problem
  • Explaining the solution without the reasoning or trade-offs
  • Omitting verification, failure handling, or prevention

Interviewer Follow-ups

  • What evidence would make you change your hypothesis?
  • What would you do if the issue disappears before you isolate it?
  • How would you prevent a repeat incident?

What the interviewer is testing

  • Problem isolation and evidence-based reasoning
  • Safe mitigation and verification
  • Prevention and operational learning

Real-World Sample Answer

A strong real-world response should connect requirements to engineering decisions, explain why the chosen approach fits the constraints, and make failure, security, cost, observability, and verification explicit.

Q6How would you safely roll out a new version of a Kubernetes workload?

What the interviewer is testing

  • Release safety
  • Failure signals
  • Rollback planning

Real-World Sample Answer

I would approach “How would you safely roll out a new version of a Kubernetes workload?” by clarifying the requirements first, then using these considerations: in a real interview, i would not jump straight to a technology choice. for “how would you safely roll out a new version of a kubernetes workload?”, i would first define health and business success signals. then i would use a staged rollout appropriate to risk and monitor before increasing exposure. i would also keep rollback fast and tested. finally, i would consider schema and compatibility changes. i would make the assumptions explicit and explain what evidence or production signals would make me revisit the decision.. I would state my assumptions and defend the trade-offs rather than presenting the choice as universally correct.

What a Strong Answer Should Cover

In a real interview, I would not jump straight to a technology choice. For “How would you safely roll out a new version of a Kubernetes workload?”, I would first define health and business success signals. Then I would use a staged rollout appropriate to risk and monitor before increasing exposure. I would also keep rollback fast and tested. Finally, I would consider schema and compatibility changes. I would make the assumptions explicit and explain what evidence or production signals would make me revisit the decision.

Common Mistakes

  • Treating deployment success as application success
  • Having no rollback condition
  • Ignoring database compatibility

Interviewer Follow-ups

  • What assumptions would you clarify before committing to the design?
  • What changes if the scale, reliability target, security requirement, or budget changes?
  • What is the biggest failure mode in your proposed approach?
  • Use the Interview Preparation learning paths and related site content to deepen any topic you could not confidently explain.
Q7Kubernetes workloads are being OOMKilled intermittently. How would you investigate?

What the interviewer is testing

  • Container resource reasoning
  • Evidence gathering
  • Safe remediation

Real-World Sample Answer

I would approach “Kubernetes workloads are being OOMKilled intermittently. How would you investigate?” by clarifying the requirements first, then using these considerations: in a real interview, i would not jump straight to a technology choice. for “kubernetes workloads are being oomkilled intermittently. how would you investigate?”, i would first confirm whether the container or node is exhausting memory. then i would inspect requests, limits, actual usage, and recent changes and look for leaks, workload spikes, and eviction pressure. i would also validate the fix under representative load. finally, i would add monitoring and capacity safeguards. i would make the assumptions explicit and explain what evidence or production signals would make me revisit the decision.. I would state my assumptions and defend the trade-offs rather than presenting the choice as universally correct.

What a Strong Answer Should Cover

In a real interview, I would not jump straight to a technology choice. For “Kubernetes workloads are being OOMKilled intermittently. How would you investigate?”, I would first confirm whether the container or node is exhausting memory. Then I would inspect requests, limits, actual usage, and recent changes and look for leaks, workload spikes, and eviction pressure. I would also validate the fix under representative load. Finally, I would add monitoring and capacity safeguards. I would make the assumptions explicit and explain what evidence or production signals would make me revisit the decision.

Common Mistakes

  • Simply increasing limits
  • Ignoring node pressure
  • Not checking whether usage is a symptom of an application problem

Interviewer Follow-ups

  • What assumptions would you clarify before committing to the design?
  • What changes if the scale, reliability target, security requirement, or budget changes?
  • What is the biggest failure mode in your proposed approach?
Q8What would you instrument in a distributed service before calling it production-ready?

What the interviewer is testing

  • User-impact thinking
  • Signal selection
  • Incident readiness

Real-World Sample Answer

I would approach “What would you instrument in a distributed service before calling it production-ready?” by clarifying the requirements first, then using these considerations: in a real interview, i would not jump straight to a technology choice. for “what would you instrument in a distributed service before calling it production-ready?”, i would first define service-level indicators around user experience. then i would use metrics for trends and alerting and use structured logs for detailed events. i would also trace cross-service requests. finally, i would connect signals to actionable runbooks and slos. i would make the assumptions explicit and explain what evidence or production signals would make me revisit the decision.. I would state my assumptions and defend the trade-offs rather than presenting the choice as universally correct.

What a Strong Answer Should Cover

In a real interview, I would not jump straight to a technology choice. For “What would you instrument in a distributed service before calling it production-ready?”, I would first define service-level indicators around user experience. Then I would use metrics for trends and alerting and use structured logs for detailed events. I would also trace cross-service requests. Finally, I would connect signals to actionable runbooks and slos. I would make the assumptions explicit and explain what evidence or production signals would make me revisit the decision.

Common Mistakes

  • Collecting every possible metric
  • Alerting on infrastructure without user impact
  • Ignoring correlation across services

Interviewer Follow-ups

  • What assumptions would you clarify before committing to the design?
  • What changes if the scale, reliability target, security requirement, or budget changes?
  • What is the biggest failure mode in your proposed approach?