Platform Engineer Interview Questions and Answers

I'd start with the previous container's logs — kubectl logs --previous, because during the backoff no container is running for plain logs to read. Then the Events in describe, since image pull, mount and probe failures never reach the container's output. On exit codes I'm careful: 137 is 128+9, so it took SIGKILL — usually the OOM killer, but describe confirms that with Reason OOMKilled rather than me guessing. From there it's config, a dependency, a liveness probe, or an init container.

What the interviewer is checking: whether you have a method rather than a list of commands. Strong candidates narrow the space with each step; weak ones recite kubectl commands in a fixed order regardless of what they found.

⚠Common trap: reading 137 as proof of an OOM kill. It only says the process was SIGKILLed — the kubelet also sends that to a container which outlives its termination grace period.

Existing traffic mostly keeps flowing, because kube-proxy programs the node's iptables or IPVS rules rather than forwarding packets itself — the rules already in place stay there. What breaks is anything new: a Service whose endpoints change, a scaled or rescheduled pod, a newly created Service. Those rules never get written, so traffic to that Service keeps going to endpoints that may be gone. Pod-to-pod traffic by IP is unaffected, since that's the CNI's job, not kube-proxy's.

What the interviewer is checking: whether you can separate the control plane from the data path. The revealing part of the answer is what keeps working, not what breaks.

⚠Common trap: saying all Service traffic stops immediately. That describes a component in the packet path, which kube-proxy is not.

There are three, and you don't set them — the kubelet derives them from your requests and limits. Guaranteed means every container has requests equal to limits for both CPU and memory; Burstable means requests are set but don't match limits; BestEffort means neither is set. What they decide is who dies first: under node memory pressure the kubelet evicts BestEffort pods before Burstable, and Guaranteed last. So it's an eviction ranking you get as a side effect of how you sized the pod.

What the interviewer is checking: whether you connect resource specs to what happens on a node under pressure — the practical reason a platform sets defaults and a LimitRange.

⚠Common trap: describing QoS as a scheduling priority. Scheduling order comes from PriorityClass and preemption; QoS is about eviction once the node is already under pressure.

An inode holds a file's metadata — type, permissions, owner, timestamps, size, link count and the pointers to its data blocks — but not its name. The name lives in the directory entry that points at the inode, which is why a hard link is just a second name for the same inode. For a full disk that gives two cases beyond running out of blocks: on ext4 the inode pool is fixed at mkfs time so you can exhaust inodes while space remains, and a deleted file still held open by a process keeps its blocks, because the link count and the open descriptor both have to go before anything is freed.

What the interviewer is checking: whether you understand the filesystem a layer below the commands. It is a fast way to separate people who have debugged a full disk from people who have only read about one.

⚠Common trap: answering "it's a file's metadata" and stopping. The interesting half is the consequence — and claiming inodes are always a fixed pool is wrong on XFS and btrfs.

A /23 leaves 9 host bits, so 512 addresses. In classic subnetting two are unusable — the network address and the broadcast — which gives 510 usable hosts. In a cloud VPC the number is lower again because the provider reserves several per subnet; AWS takes five, so a /23 there gives 507. The way I get to it is the host-bit count rather than a memorised table: 32 minus the prefix is the exponent.

What the interviewer is checking: whether you can do subnet arithmetic on the spot, which is a standing screen question for infrastructure roles: employer-published screens routinely list networking and network security among their named topics.

⚠Common trap: giving 512 as the usable count, or giving the textbook 510 for a cloud subnet where the provider's reservations make it wrong.

It takes the change a commit introduced and applies it on top of your current HEAD as a new commit — new SHA, new parent, same diff. You cannot cherry-pick a branch as such, because a branch is just a pointer to a commit; what you can do is give it a commit range and get each one applied in turn. The consequence worth stating is that the change now exists as two different commits, so a later merge can conflict or the fix can quietly appear twice in the history.

What the interviewer is checking: whether you understand commits as objects rather than as positions in a timeline. The duplicate-change consequence is the part that shows you have lived with it.

⚠Common trap: saying yes to cherry-picking a branch. The question is worded that way on purpose — it is checking whether you know what a branch actually is.

First a plan, to see exactly what diverged — it refreshes its in-memory view against the real resources unless you pass -refresh=false, and shows the difference before anything changes. Then it's a decision rather than a reflex: if the change was wrong, apply brings the resource back to the declared state; if it was legitimate, I'd use a -refresh-only plan to accept it into state and write it into the configuration so the code is true again. The lasting fix is removing the ability to do it by hand, so the pipeline is the only writer.

What the interviewer is checking: whether you reach for a decision or for a command. Both outcomes — revert and codify — are correct depending on the change, and saying so is the answer they want.

⚠Common trap: answering only "apply to overwrite it". That is right about half the time and destroys a legitimate emergency fix the other half.

ENTRYPOINT is the command the container always runs; CMD supplies the default arguments to it. So arguments you pass to docker run replace CMD but are appended to ENTRYPOINT — overriding the entrypoint itself needs the --entrypoint flag. In practice I put the binary in ENTRYPOINT in exec form and the default flags in CMD, which gives an image that behaves like a command-line tool. Exec form matters too: shell form wraps the process in a shell, and then signals go to the shell instead of your application.

What the interviewer is checking: the signal-handling consequence. That is what turns this from trivia into the reason a pod takes 30 seconds to terminate.

⚠Common trap: describing them as interchangeable ways to start a process. The override behaviour and PID 1 signalling are the whole answer.

Before reading any value I'd check what the panels actually measure and over what time range, because a five-minute window and a seven-day window tell different stories. Then the golden signals together — traffic, errors, latency and saturation — since errors rising while traffic drops means something quite different from both rising, and I'd check whether latency is an average or a percentile, because an average hides the tail users complain about. For paging I'd alert on user-visible symptoms against an SLO and its error budget, keeping cause metrics as context — with the exception of imminent, unavoidable failure like a disk projected to fill or a certificate expiring.

What the interviewer is checking: whether you can be handed unfamiliar telemetry and reason about it, which is most of the job. This is often run as a live exercise with a real dashboard rather than as a spoken question.

⚠Common trap: narrating every panel you can see. They are testing prioritisation — say what you would look at first and why, and what you would deliberately ignore.

I'd say it is not purchasable at any budget, and explain why rather than just refusing: every dependency, network and deploy has a failure rate, and each additional nine costs more than the last while returning less. Then I'd redirect the conversation to what they actually want, which is usually that a specific critical flow does not fail visibly at a specific time. That is answerable — you can protect the checkout path with a tighter SLO, graceful degradation and a fallback, and accept less for the parts nobody notices.

What the interviewer is checking: whether you can push back on an unreasonable requirement without being obstructive. The answer they want is a redirect, not a lecture and not a yes.

⚠Common trap: agreeing and promising to try. It sets up a guaranteed breach and destroys the credibility of every number you quote afterwards.

One team asked us to run their bespoke data-reconciliation job as a platform service. I declined, because the first question is whether something off-the-shelf or an existing internal service already does it, and the second is leverage — this served one team and was really their domain logic wearing platform clothing, so owning it would have added surface everyone maintains and one team benefits from. What I offered instead was a namespace, a pipeline template and a runbook they own, and I said we would revisit if a second and third team asked for the same thing.

What the interviewer is checking: whether you understand that a platform's scope is a product decision with a cost, rather than a collection of everything anyone asked for. Saying no well is the senior signal here.

⚠Common trap: answering with a framework and no example. Candidates prepare what they built and get caught by the inverse — have a specific instance ready.

I'd frame it as a product story rather than a tour of the stack: who the users were, what specifically was slow or painful before, what we built first and why that, and what measurably changed — time to first deploy, or how many teams moved without being told to. Then the honest part, which is what I would do differently: where we abstracted too early, which capability nobody adopted, what we had to deprecate. The tooling gets a sentence, because the decisions are the interesting content and the tools are replaceable.

What the interviewer is checking: seniority. A list of tools reads as junior; a narrative of decisions with evidence and regrets reads as someone who has owned something. This is reported as the round candidates under-prepare most.

⚠Common trap: describing the architecture in detail and never mentioning whether anyone used it. Adoption is the outcome they are listening for.