DevOps interviews care about the night the page went off

You can recite kubectl get pods and still get flattened by a DevOps interview. The interviewer asks why one node is throttling, how DNS failed between namespaces, and what evidence would justify waking someone at 2:11am. A command remembered from a certification guide won’t carry that conversation very far.

The Cloud / DevOps / SRE track gives you a place to practice that kind of questioning. Its compact catalog covers Linux internals and troubleshooting, networking, containers with infrastructure as code, and SLOs, monitoring and on-call work. The depth of your reasoning matters more than the number of tools you can name.

Linux is where the interview starts

Linux questions expose how you behave when the system stops making sense. A process is slow. Do you inspect CPU saturation, memory pressure, disk latency and open file descriptors, or do you reach for a restart before you know what changed? The order of operations matters because production debugging is mostly about reducing uncertainty without destroying evidence.

The useful details depend on the role. Someone supporting noisy multi-tenant workers should understand cgroups and why a container limit can look different from the host view. A candidate who has debugged storage should be able to explain iowait, filesystem capacity and inode exhaustion. File descriptor leaks, swapping and a clock drifting far enough to break TLS are ordinary failures with remarkably confusing symptoms.

I would prepare one Linux incident as a timeline. Say what alerted, what you checked first, which hypothesis died quickly and which command changed your mind. A small incident is fine. The Linux Internals and Troubleshooting session has somewhere to go once you bring that timeline with you.

Trace the network one hop at a time

“The service is unreachable” is an invitation to trace the path. Start with name resolution, then follow the connection through routing, load balancing, TLS and policy. In a Kubernetes environment, that may include service discovery, ingress, a NetworkPolicy and the container itself. A service mesh belongs in the answer only when it is present in the system.

Good network answers stay physical. Which hostname resolved? Where did the packet stop? Was the connection refused, reset or timed out? Those outcomes point in different directions. MTU problems, conntrack exhaustion and load balancers that reset idle connections often produce failures that application dashboards describe poorly.

Avoid reciting the OSI model unless the question asks for it. Use the model to organize your thinking, then talk through the machines and boundaries involved. The Networking session for DevOps and SRE roles is much closer to this packet-by-packet account than a seven-layer recital.

Treat infrastructure as a controlled change

Containers and infrastructure as code are change-management systems with technical machinery attached. Be ready to explain how an image is built, identified, promoted and rolled back. Then connect that image to the scheduler: placement, resource requests, health checks, rollout behavior and failure recovery.

For Terraform, Pulumi or CloudFormation, name the tool you used and stay with your experience. Where is state kept? How do two engineers avoid racing an apply? What is the blast radius of a module change? A strong answer includes the bad apply, the workspace mistake or the manual console edit that created drift, plus the safeguard added later.

Git as a source of truth sounds clean until an emergency change happens outside the pipeline. The interesting discussion begins there. Explain how you detect drift, reconcile the emergency fix and preserve an audit trail. A ban on console changes is a policy. It is still missing a recovery procedure for the day somebody clicks anyway.

The pager tests your judgment

An SLO connects user experience to engineering response. Pick a service and define the event that counts as successful. Explain the measurement window, the error budget and the alert that would lead to action. Four nines chosen because they sound mature will collapse under one question about maintenance, dependencies or the cost of meeting them.

Monitoring questions should lead to ownership. Say which signal pages a human, which one creates a ticket and which one stays on a dashboard for diagnosis. Alert volume matters because noisy pages train people to ignore the system by Thursday. The SLOs, Monitoring and On-Call session gives that ownership question a concrete incident to work through.

Some DevOps postings are mostly Jenkins, Ansible and ticket queues. Others expect production engineering judgment under pressure. Read the posting before you prepare, since an elaborate SRE answer can sound oddly theatrical in a role built around predictable deployment work.

Build an incident you can defend

Choose one incident and write down the first 15 minutes. Include the misleading clue, because incidents always have one. Describe what you measured before making a change and how you knew recovery was complete. Then explain the follow-up work, whether that was an alert adjustment, a runbook, a safer rollout or a small piece of automation.

Practice the story with interruptions. A hiring manager may stop you halfway through and ask what the customer saw, why the rollback took 20 minutes or who had authority to declare the incident over. Those questions test whether your account survives when the order changes.

A DevOps interview is a conversation about evidence, controlled change and responsibility when the system is sick. The Cloud / DevOps / SRE track gives that conversation enough room to become uncomfortable. Bring one incident you can explain all the way down to the command that changed your mind.