DevOps & Cloud Topic
DevOps Interview Practice: Cloud, Kubernetes, Security and Reliability
Use these questions to practise explaining your thinking in clear language. Learn the idea, then answer in your own words. Interview questions differ between companies; this list is practice, not a promise of what an interviewer will ask.
How to practise
Read one question. Say a short answer aloud. Add a small example and explain one limit or risk. If you have not used a tool at work, describe your lab experience honestly.
1. How would you design a reliable web app?
Start with users, expected traffic and recovery needs. Choose a simple design, remove important single points of failure and test recovery. Extra replicas do not protect a single database by themselves.
Example to discuss: Ask about acceptable downtime and data loss before naming cloud products.
2. What are RTO and RPO?
Recovery time objective is the target time to restore service. Recovery point objective is the target maximum data loss measured in time. They guide backup and recovery design.
Example to discuss: A one-hour backup interval does not prove a one-hour RPO unless backups and restores work as expected.
3. How would you investigate a slow app?
Measure where time is spent. Check request latency, errors, queues, resource limits and dependencies. Compare with a recent healthy period.
Example to discuss: A busy CPU is a clue, not proof. The app could be waiting for a database or external API.
4. What is an SLO?
An SLO is a target for a defined service measurement over a defined period. Agree the user journey and what counts as success. An SLA is a customer agreement and may have consequences.
Example to discuss: For one million valid requests and a 99.9% success target, the error budget is 1,000 unsuccessful requests.
5. How do readiness and liveness differ?
Readiness controls whether a Pod should receive Service traffic. Liveness can restart a container that is stuck. Startup probes allow time for startup before the other checks take over.
Example to discuss: Do not restart every app instance just because a shared database is temporarily unavailable.
6. How do Kubernetes requests and limits work?
Requests help scheduling and describe resource needs. CPU limits can throttle work. Going beyond a memory limit can lead to termination. Choose values from measurements and testing.
Example to discuss: A CPU-based HPA needs metrics and suitable CPU requests. A manifest alone does not install a metrics service.
7. Why might a Service not reach a Pod?
Check the namespace, selector labels, ready endpoints and target port. Then check the app listener and relevant network policies. Start with the simplest broken link.
Example to discuss: A process listening only on 127.0.0.1 inside a Pod is not reachable through the normal Pod network.
8. What are ConfigMaps and Secrets?
ConfigMaps hold ordinary configuration. Secrets hold values that need restricted access. Base64 encoding is not encryption. Both need correct access and handling.
Example to discuss: Environment values in existing Pods do not automatically change when their ConfigMap changes; plan a rollout.
9. How do you troubleshoot an image pull error?
Read the Pod events and check the image name, tag or digest, registry access and architecture. For a local kind image, load it into the named cluster.
Example to discuss: Do not fix a private registry issue by making the registry public.
10. What is GitOps?
Git holds the desired configuration, and a controller compares it with the running system. The controller can report differences or apply them. Review and access control still matter.
Example to discuss: In Argo CD, manual sync is a useful first lab. Automated pruning can delete resources removed from Git.
11. How do you recover from a bad GitOps change?
Find a known good desired state and review a revert in Git. Let the controller reconcile that state. A manual live edit may be overwritten when self-healing is enabled.
Example to discuss: Data recovery is separate. A Git revert cannot necessarily undo a database migration.
12. What is infrastructure drift?
Drift is a difference between the intended infrastructure and the real environment. It can come from manual changes or other automation. Investigate before applying a plan.
Example to discuss: A plan that replaces a resource deserves special review. Do not apply it just to make the difference disappear.
13. How do you protect Terraform state?
Use restricted storage, appropriate encryption, versioning and coordination. State may hold secrets even when outputs are marked sensitive. Separate environments with suitable access boundaries.
Example to discuss: On current Terraform S3 backends, native lockfiles use use_lockfile=true. DynamoDB locking is deprecated.
14. How do you avoid permanent cloud keys in CI?
Use an identity federation method such as OIDC when supported. The job gets a short-lived identity. Configure a narrow trust policy and a separate least-privilege permission policy.
Example to discuss: A GitHub id-token: write permission permits requesting a token; it does not grant AWS resource access by itself.
15. How do you secure third-party CI actions?
Review what they do and pin actions to a reviewed full commit SHA. Give the job limited permissions. Treat untrusted pull-request input as untrusted code and data.
Example to discuss: A pinned action still needs updates and review. Pinning is not a guarantee that its code is safe.
16. What are an SBOM and build provenance?
An SBOM lists software components. Provenance records information about how an artifact was built. They support investigation and policy, but do not prove the artifact is free of vulnerabilities.
Example to discuss: Use a suitable scanner and a process to fix findings. Check that your registry and image store preserve attestations.
17. How do security groups and network ACLs differ in AWS?
Security groups apply to attached resources and track allowed connections. Network ACLs apply at subnet boundaries and are stateless. Their rule models differ.
Example to discuss: Also check routes and the application listener. A firewall rule cannot start a stopped service.
18. What is a private subnet?
In AWS it has no direct route to an internet gateway. Private resources may still reach external services through a NAT or other controlled path. Private placement does not replace identity checks.
Example to discuss: Ask whether an outbound path is needed, what it permits and what it costs.
19. How do you scale a database-backed service?
Find the bottleneck first. App replicas may increase database connections and make the problem worse. Review queries, indexes, pooling and workload before adding capacity.
Example to discuss: Use load tests with realistic data in an authorised environment. Explain the limits of the test.
20. When are retries harmful?
Retries can multiply load during an outage. They can also repeat a payment or order. Use timeouts, bounded retries, backoff and idempotency where needed.
Example to discuss: An idempotency key needs reliable storage and atomic handling; a key in a log line is not enough.
21. How would you reduce cloud cost?
Find the owner and purpose of the spend. Compare cost with useful work, then check idle resources, sizing and storage retention. Verify that a saving does not break performance or recovery.
Example to discuss: A budget alert usually notifies people; it is not automatically a hard spending cap.
22. What is platform engineering?
A platform team provides useful shared paths for developers, such as a supported service template and delivery workflow. Treat developers as users and improve from feedback.
Example to discuss: A catalog is one part. It does not automatically provide permissions, deployment or a successful developer experience.
23. Where can AI help in operations?
It can summarise redacted evidence, suggest hypotheses or help draft a runbook. People must check its claims. Start with read-only use and clear boundaries.
Example to discuss: A confident explanation is not proof. Never let text in a log become an instruction to run a command.
24. How do you handle a question you do not know?
State what you know and what you would check next. Ask a useful clarifying question. Do not invent a command or claim production experience you do not have.
Example to discuss: Practise explaining one lab failure clearly: evidence, hypothesis, safe check, result and lesson.
Build one example you can explain
Work through the Docker lab, the Kubernetes lab and the reliability guide. Write what worked, what failed and what you would change before production. You do not need every tool to show careful problem solving.
Official references and further reading
Reviewed on 25 October 2026. Tools change, so check the official documentation for the version you use.
Comments (1)
Great