Chapter 70: DevOps Interview Questions by Topic and Company
70.11 Scenario-Based DevOps Interview Questions
Scenario prashna madhe ghabru naka. Aadhi user la vachva, mag karan shodha - kramane steps sanga.
What you will learn in this lesson
- 35 real Scenario-Based DevOps questions with short answers
- Which companies asked them, from public interview stories
- Fresher, experienced and senior levels
- A simple way to answer: why, what, how
Why: the problem
Senior rounds are mostly "what will you do if..." questions. They test calm, ordered thinking more than tool names.
What: how to read this lesson
Each question has a short answer in three parts.
- Why: the reason the thing exists.
- What: the plain meaning.
- How: how you use it, often with a small command.
"Asked at" names a company only when a public interview story says the question was asked there. No tag means it is a common question that many companies ask.
Companies with the most questions in this lesson: Flipkart (8), Infosys (5), Capgemini (4), TCS (3), LTIMindtree (3), Amazon (3).
How: answer any question in 4 steps
- Start with the reason. One sentence.
- Give the plain meaning. No big words.
- Show one command or file.
- Add one example from your work. Then stop and wait.
Experienced questions (2-5 years)
Q1. A production deployment failed midway. What do you do?
Why they ask: Users may be affected right now.
Idea: Stabilise first, then find the cause.
How to answer:
- Stop the pipeline
- Check impact with monitoring
- Roll back to the last good version
- Tell the team and stakeholders
- Read logs to find the cause
- Fix, test in staging, redeploy
- Write a short post-mortem
kubectl rollout undo deploy/web
Q2. Tell us about a production issue you solved.
Why they ask: They test real experience and structure.
Idea: Use STAR: situation, task, action, result.
How to answer:
- Describe the alert
- Your first checks
- The root cause
- The fix
- What you changed so it does not repeat
Q3. An app works in QA but fails in production. Why?
Why they ask: Environment differences are common.
Idea: Something differs: config, data, scale, network or permissions.
How to answer:
- Compare config and secrets
- Compare versions and images
- Check network rules and DNS
- Check data size and load
- Check IAM permissions
- Reproduce with prod-like data
Q4. A container's memory keeps growing. What do you do?
Why they ask: Memory leaks end in OOMKilled.
Idea: Prove the trend and find the leak.
How to answer:
- Watch memory over time in Grafana
- Check limits and heap settings
- Take a heap dump or profile
- Fix the leak or add a restart as a short-term guard
- Set alerts
Q5. The upload to cloud storage fails from your app. How do you debug?
Why they ask: Common in cloud apps.
Idea: Usually permissions, network or size.
How to answer:
- Read the exact error code
- Check IAM role/policy and bucket policy
- Check VPC endpoint or NAT
- Check KMS key permissions
- Check file size and multipart settings
Q6. You find hardcoded secrets in the code. What do you do?
Why they ask: Security incidents need fast action.
Idea: Treat it as leaked.
How to answer:
- Rotate the secret immediately
- Remove it and move to a secret store
- Clean Git history
- Check logs for misuse
- Add secret scanning to CI
Q7. A 3 GB Docker image is slowing deployments. How do you fix it?
Why they ask: Big images slow pulls and scaling.
Idea: Find what makes it big.
How to answer:
- Run docker history
- Use a slim base
- Use multi-stage builds
- Add .dockerignore
- Remove caches and build tools
docker history --no-trunc app:latest
Q8. The application fails during traffic spikes. What do you do?
Why they ask: High-traffic product companies ask this.
Idea: Find the bottleneck under load.
How to answer:
- Check which resource saturates (CPU, DB connections, threads)
- Add autoscaling with headroom
- Add caching and queues
- Add rate limiting
- Load test before sale events
Q9. A downstream service is slow and affects your service. What do you do?
Why they ask: Cascading failures take down systems.
Idea: Protect your service.
How to answer:
- Add timeouts
- Add retries with backoff (limited)
- Add a circuit breaker
- Use fallbacks or cache
- Alert the owning team
Q10. The cache is on, but database load is still high. Why?
Why they ask: Tests caching knowledge.
Idea: The cache is not doing its job.
How to answer:
- Check cache hit ratio
- Check TTLs and keys
- Check cache stampede when keys expire
- Look at slow queries not cached
- Warm the cache
Q11. Latency increased but CPU is normal. What could it be?
Why they ask: Not all slowness is CPU.
Idea: Waiting, not working.
How to answer:
- Check DB and downstream latency
- Check connection pool and thread limits
- Check GC pauses
- Check network and DNS
- Check disk I/O wait
Q12. The deployment succeeded but errors increased. What do you do?
Why they ask: Green pipelines can still break prod.
Idea: The new version is bad.
How to answer:
- Compare error rate before and after
- Roll back quickly
- Read errors in logs and traces
- Add canary analysis next time
Q13. Only some users are affected by an issue. How do you find the cause?
Why they ask: Partial issues are hard.
Idea: Find what the affected users share.
How to answer:
- Group by region, device, version, tenant
- Check one AZ, node or pod
- Check feature flags
- Check CDN edge
Q14. Autoscaling did not help during an incident. Why?
Why they ask: Scaling is not always the answer.
Idea: The bottleneck was elsewhere.
How to answer:
- Check if the DB or a shared dependency was the limit
- Check scaling speed and max limits
- Check startup time
- Check quotas
Q15. There are no errors in logs, but the app is slow. How do you debug?
Why they ask: Logs do not show everything.
Idea: Use metrics and traces.
How to answer:
- Look at latency percentiles (p95, p99)
- Use tracing to find the slow span
- Check resource saturation
- Profile the app
Q16. A developer made a change directly in production. How do you handle it?
Why they ask: Process and people.
Idea: Fix the process, not just the person.
How to answer:
- Check impact and revert if needed
- Talk to the developer calmly
- Restrict prod access with IAM/RBAC
- Make all changes go through Git and CI
Q17. The application is unresponsive. What do you check?
Why they ask: First-response skills.
Idea: Check from outside in.
How to answer:
- Is the server up (ping, SSH)?
- Is the process running?
- Is the port listening?
- Check CPU, memory, disk
- Read app logs
- Check dependencies (DB)
Q18. The pipeline is failing. How do you debug it?
Why they ask: Daily work.
Idea: Find the first real error.
How to answer:
- Read the log from the first failure
- Check what changed (code, tools, secrets)
- Re-run to rule out flaky tests
- Reproduce locally
- Fix and add a check
Q19. The backup bucket became unavailable. What do you do?
Why they ask: Backups must be reliable.
Idea: Find why and protect future backups.
How to answer:
- Check bucket policy, KMS key and IAM changes in CloudTrail
- Restore access
- Enable cross-region replication and object lock
- Alert on backup failures
Q20. The private subnet ran out of IP addresses. What do you do?
Why they ask: Happens with EKS.
Idea: Pods and nodes need IPs.
How to answer:
- Add new subnets with a larger CIDR
- Add a secondary VPC CIDR
- Use prefix delegation or custom networking in EKS
- Clean unused ENIs
Q21. Someone changed a bucket policy manually and Terraform shows drift. What do you do?
Why they ask: Real-world drift.
Idea: Decide the source of truth.
How to answer:
- Find who and why via CloudTrail
- If the change is needed, add it to code
- Otherwise apply to restore
- Restrict console write access
Q22. Disk is full on a production server. What do you do?
Why they ask: Very common on-call issue.
Idea: Free space safely, then prevent it.
How to answer:
- df -h to find the mount
- du to find big folders
- Clean old logs and compress
- Check deleted-but-open files
- Add log rotation and alerts
sudo du -xh /var | sort -h | tail
Q23. An API returns wrong output. How do you debug it?
Why they ask: Asked in an Amazon interview.
Idea: Follow the request.
How to answer:
- Reproduce with curl
- Check logs for that request ID
- Check recent deploys and config
- Check downstream data
- Write a test for the bug
curl -s -H "X-Request-ID: test1" https://api.example.com/v1/items
Q24. Users cannot connect to the database. How do you investigate?
Why they ask: Cloud support style question.
Idea: Check layer by layer.
How to answer:
- Is the DB up?
- Network/port reachable?
- Security group rules
- Max connections reached?
- Credentials and SSL
- DNS for the endpoint
Q25. You must upgrade Kubernetes with zero downtime. How?
Why they ask: Common for EKS teams.
Idea: Upgrade in small safe steps.
How to answer:
- Check deprecated APIs
- Back up etcd/state
- Upgrade the control plane
- Add new node group, cordon and drain old nodes with PDBs
- Upgrade add-ons
- Test apps
Q26. A certificate expired and the site is down. What do you do now and later?
Why they ask: Avoidable outage.
Idea: Renew now, automate later.
How to answer:
- Renew and deploy the certificate
- Check the full chain
- Move to auto-renewal (ACM or cert-manager)
- Add expiry alerts
Q27. Terraform plan wants to destroy a production database. What do you do?
Why they ask: Protects data.
Idea: Never apply blindly.
How to answer:
- Stop and read why (rename, changed force-new attribute)
- Use moved blocks or state mv for renames
- Add prevent_destroy
- Take a snapshot first
Q28. How would you handle secrets errors in a deployment?
Why they ask: Asked about failing secrets.
Idea: The app cannot read a secret.
How to answer:
- Check the secret exists in the right namespace
- Check key names
- Check IAM/RBAC for the secret store
- Check sync status of External Secrets
- Restart pods to load new values
Senior questions
Q29. It is 3 AM and production is down. What do you do?
Why they ask: Calm process under pressure.
Idea: Restore service first, root cause later.
How to answer:
- Acknowledge the alert
- Check dashboards for impact
- Check recent changes and roll back if needed
- Escalate early
- Keep a timeline in the incident channel
- Post-mortem next day
Q30. How do you handle a P1 incident?
Why they ask: Senior roles own incidents.
Idea: Clear roles and communication.
How to answer:
- Declare the incident and assign an incident commander
- Mitigate (rollback, failover)
- Communicate updates on a fixed schedule
- Resolve and confirm
- Blameless post-mortem with actions
Q31. The ingress controller crashes under high load. What do you do?
Why they ask: Edge failures affect everyone.
Idea: Scale and tune the edge.
How to answer:
- Check controller pod CPU/memory and limits
- Scale replicas and add HPA
- Tune worker connections and timeouts
- Spread across nodes
- Add rate limiting or a CDN in front
Q32. A region goes down. How do you fail over?
Why they ask: DR design.
Idea: Have a ready second region.
How to answer:
- Replicate data to another region
- Keep infra as code ready
- Use Route 53 failover with health checks
- Run regular DR drills
Q33. A Docker policy-as-code tool blocked a deployment. How do you handle it?
Why they ask: Security gates are now common.
Idea: The policy is doing its job; understand the violation.
How to answer:
- Read the violation (root user, latest tag, missing limits)
- Fix the manifest or image
- Request an exception only with approval
- Keep policies in Git
Q34. How do you migrate a monolith to microservices on Kubernetes?
Why they ask: Big project question.
Idea: Move step by step.
How to answer:
- Containerise the monolith first
- Split one service at a time (strangler pattern)
- Add CI/CD per service
- Add observability
- Move data carefully
Q35. How would you design a CI/CD system for 100 developers?
Why they ask: Platform thinking.
Idea: Fast, safe, self-service.
How to answer:
- Shared templates
- Autoscaling runners
- Caching
- Security scans
- GitOps deploys
- Dashboards for pipeline health
Practice tasks
Medium A production deployment failed midway. What do you do?
Why: Saying it once with your own words makes it stick.
What to do: Answer this question as if the interviewer just asked it.
- Open a lab VM or container, never production.
- Run or write the example from the answer.
- Read the output line by line.
- Say the answer aloud in under 60 seconds.
Check: Your answer has a reason, a plain meaning and one command.
Medium Tell us about a production issue you solved.
Why: Saying it once with your own words makes it stick.
What to do: Answer this question as if the interviewer just asked it.
- Write three short points: why, what, how.
- Add one example from your own project.
- Say it aloud in under 60 seconds.
Check: Your answer has a reason, a plain meaning and one example.
Medium An app works in QA but fails in production. Why?
Why: Saying it once with your own words makes it stick.
What to do: Answer this question as if the interviewer just asked it.
- Write three short points: why, what, how.
- Add one example from your own project.
- Say it aloud in under 60 seconds.
Check: Your answer has a reason, a plain meaning and one example.
Medium A container's memory keeps growing. What do you do?
Why: Saying it once with your own words makes it stick.
What to do: Answer this question as if the interviewer just asked it.
- Write three short points: why, what, how.
- Add one example from your own project.
- Say it aloud in under 60 seconds.
Check: Your answer has a reason, a plain meaning and one example.
Medium The upload to cloud storage fails from your app. How do you debug?
Why: Saying it once with your own words makes it stick.
What to do: Answer this question as if the interviewer just asked it.
- Write three short points: why, what, how.
- Add one example from your own project.
- Say it aloud in under 60 seconds.
Check: Your answer has a reason, a plain meaning and one example.
Medium You find hardcoded secrets in the code. What do you do?
Why: Saying it once with your own words makes it stick.
What to do: Answer this question as if the interviewer just asked it.
- Write three short points: why, what, how.
- Add one example from your own project.
- Say it aloud in under 60 seconds.
Check: Your answer has a reason, a plain meaning and one example.
Medium A 3 GB Docker image is slowing deployments. How do you fix it?
Why: Saying it once with your own words makes it stick.
What to do: Answer this question as if the interviewer just asked it.
- Open a lab VM or container, never production.
- Run or write the example from the answer.
- Read the output line by line.
- Say the answer aloud in under 60 seconds.
Check: Your answer has a reason, a plain meaning and one command.
Medium The application fails during traffic spikes. What do you do?
Why: Saying it once with your own words makes it stick.
What to do: Answer this question as if the interviewer just asked it.
- Write three short points: why, what, how.
- Add one example from your own project.
- Say it aloud in under 60 seconds.
Check: Your answer has a reason, a plain meaning and one example.
Homework: try at home
- Pick five questions you find hard.
- Write your own answer for each in three lines.
- Record yourself answering them. Listen once and improve.
Recap
In short
- Answer in order: why, what, how, then one example.
- Show one small command when you can.
- "Asked at" comes from public interview stories.
- Practise aloud; do not memorise word for word.
FAQ
Do I need to learn all 35 questions?
No. Start with the fresher ones. Then add the experienced ones for your level.
Should I memorise these answers?
No. Understand the why, then say it in your own words. Interviewers notice memorised lines.
What if I do not know an answer?
Say so honestly. Then explain how you would find out, step by step.
Are these questions only for one company?
No. "Asked at" shows where people said it was asked. Other companies ask the same things.
How long should an answer be?
About 30 to 60 seconds. Give a reason, a plain meaning and one example.
Is a lab really needed?
Yes. Running the command once makes your answer real and confident.
Interview questions
Practise these five first. Many companies asked them.
- A production deployment failed midway. What do you do? - Stabilise first, then find the cause.
- Tell us about a production issue you solved. - Use STAR: situation, task, action, result.
- An app works in QA but fails in production. Why? - Something differs: config, data, scale, network or permissions.
- A container's memory keeps growing. What do you do? - Prove the trend and find the leak.
- The upload to cloud storage fails from your app. How do you debug? - Usually permissions, network or size.
Quick quiz
Q1. A production deployment failed midway. What do you do?
Stabilise first, then find the cause.
Q2. A downstream service is slow and affects your service. What do you do?
Protect your service.
Q3. A developer made a change directly in production. How do you handle it?
Fix the process, not just the person.
Q4. The private subnet ran out of IP addresses. What do you do?
Pods and nodes need IPs.
Q5. A certificate expired and the site is down. What do you do now and later?
Renew now, automate later.
Samajla ka?
Revision card
Interview card