DevOps & Platform Interview Questions

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

Each question below has its own metadata. Use tags for cross-category placement: a question can have any number of tags and categories without duplication.

Question: A production API's latency doubled overnight. What do you investigate first?

Metadata

id: api-latency-investigation
roles:
- sre
- cloud-engineer
- devops-platform
- backend-engineer
- cloud-architect
categories:
- Troubleshooting
difficulty: Professional
type: Troubleshooting
tags:
- latency
- observability
- incident
- debugging
featured: production
status: published
relatedResources:
- label: Real-World Cloud Interview Questions
  href: /prepare/interviews/real-world-cloud-interview-questions

Interview Question

A 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?

Related Learning

• Real-World Cloud Interview Questions

Question: When would you introduce caching, and how would you prevent stale or incorrect data from becoming a problem?

Metadata

id: cache-strategy
roles:
- cloud-architect
- backend-engineer
- cloud-engineer
- sre
categories:
- Performance
difficulty: Professional
type: Trade-off
tags:
- caching
- latency
- consistency
featured: popular
status: published

Interview Question

When 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?

Related Learning

• Use the Interview Preparation learning paths and related site content to deepen any topic you could not confidently explain.

Question: What does a safe CI/CD pipeline need beyond build and deployment steps?

Metadata

id: ci-cd-design
roles:
- devops-platform
- cloud-engineer
- sre
- backend-engineer
categories:
- DevOps
difficulty: Foundation
type: Fundamentals
tags:
- CI/CD
- testing
- security
- delivery
featured: false
status: published

Interview Question

What 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?

Related Learning

• Use the Interview Preparation learning paths and related site content to deepen any topic you could not confidently explain.

Question: A production API is intermittently timing out. Explain how you would isolate the failure and prevent recurrence.

Metadata

id: cloud-incident
roles:
- cloud-architect
- devops-platform
- troubleshooting
categories:
- Troubleshooting
difficulty: Architect
type: Troubleshooting
tags: []
featured: false
status: published
timeMinutes: 7
relatedResources:
- label: Real-World Cloud Interview Questions
  href: /prepare/interviews/real-world-cloud-interview-questions

Interview Question

A 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.

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

Metadata

id: first-five-api-checks
roles:
- devops-platform
- cloud-architect
- troubleshooting
categories:
- Troubleshooting
difficulty: Foundation
type: Troubleshooting
tags: []
featured: false
status: published
timeMinutes: 5
relatedResources:
- label: Real-World Cloud Interview Questions
  href: /prepare/interviews/real-world-cloud-interview-questions

Interview Question

A 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.

Question: How would you safely roll out a new version of a Kubernetes workload?

Metadata

id: k8s-deployment-strategy
roles:
- kubernetes-engineer
- devops-platform
- sre
- cloud-engineer
categories:
- DevOps
difficulty: Professional
type: Trade-off
tags:
- Kubernetes
- deployment
- rollback
- observability
featured: popular
status: published

Interview Question

How 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?

Related Learning

• Use the Interview Preparation learning paths and related site content to deepen any topic you could not confidently explain.

Question: Kubernetes workloads are being OOMKilled intermittently. How would you investigate?

Metadata

id: kubernetes-oomkill
roles:
- kubernetes-engineer
- devops-platform
- sre
- cloud-engineer
categories:
- Kubernetes
difficulty: Professional
type: Troubleshooting
tags:
- OOMKill
- resources
- containers
featured: production
status: published
relatedResources:
- label: Kubernetes Architecture
  href: /learn/kubernetes/kubernetes-architecture

Interview Question

Kubernetes 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?

Related Learning

• Kubernetes Architecture

Question: What would you instrument in a distributed service before calling it production-ready?

Metadata

id: observability-design
roles:
- sre
- devops-platform
- cloud-engineer
- backend-engineer
- cloud-architect
categories:
- Observability
difficulty: Professional
type: Fundamentals
tags:
- metrics
- logs
- traces
- SLO
featured: must-know
status: published
relatedResources:
- label: Production Incident Checklist
  href: /learn/devops/troubleshooting/production-incident-checklist

Interview Question

What 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?

Related Learning

• Production Incident Checklist