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?

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.

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.

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.

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.

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.

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?

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?