Platform Engineer Interview Prep: Questions and a Mock Test

The Certified Kubernetes Administrator exam is a useful proxy for what the technical rounds cover, because its weightings were derived from what practitioners actually do. Its five domains are cluster architecture, installation and configuration at 25 percent, workloads and scheduling at 15 percent, services and networking at 20 percent, storage at 10 percent, and troubleshooting at 30 percent.

Troubleshooting being the single largest domain is the detail worth internalising. It is also a performance-based exam, described as "an online, proctored, performance-based test that requires solving multiple issues from a command line", with two hours to complete it. Nothing about that format rewards recall of concepts; it rewards being able to find and fix a broken thing under time pressure.

Interviews mirror this. Expect at least one round that hands you a broken cluster or a broken workload and asks you to diagnose it live. Preparation that consists of reading about controllers will not survive that round, and preparation that consists of breaking things deliberately and fixing them will.

One practical note on currency: the certification updates quarterly to track Kubernetes releases, and the platform ecosystem moves fast enough that specifics age quickly. Being able to say what changed recently, and to distinguish something you have run in production from something you have read about, is more valuable than pretending uniform depth.

The conceptual question interviewers use to separate depth from familiarity is why the system is declarative.

A controller watches for a difference between desired state, which you declared, and observed state, which it measures, and takes action to reduce the gap. It then repeats, forever. That loop is the whole architecture, and several practical consequences follow directly from it.

Applying the same manifest twice is a no-op, because the second application produces no gap. Deleting a managed resource by hand results in it being recreated, because the controller sees a gap and closes it. A partial failure is self-healing rather than requiring a rerun, because the loop will try again. And the system converges rather than executing steps, which is why there is no rollback in the imperative sense: you change the declaration and the loop moves toward it.

The distinction to be able to draw is between this and an imperative pipeline that runs a sequence of commands. The imperative version knows what it did and not what is true; the declarative version knows what should be true and does not care what it did.

The follow-up is usually about extending the system with a custom controller, and the strong answer is that a custom resource plus a controller is how you make your own abstractions first-class, so that a team declares a database and the platform reconciles one into existence, rather than filing a ticket.

Resource configuration causes more real incidents than any other Kubernetes topic, so it is heavily examined.

The core distinction: a request is what the scheduler uses to find a node with sufficient uncommitted capacity, and a limit is what the runtime enforces once running. They do different jobs, and setting only one produces predictable pathologies.

The enforcement asymmetry matters. Exceeding a memory limit gets the container killed, because memory cannot be throttled. Exceeding a CPU limit throttles the process, which produces latency that looks like a mysterious application slowdown with no obvious cause. That asymmetry is why memory limits are near-universally recommended and CPU limits are genuinely contested: throttling a latency-sensitive service that is briefly bursty can be worse than letting it use idle capacity.

Requests set too low mean the scheduler overcommits a node, and under pressure the kubelet evicts pods, choosing by quality of service class: pods with no requests or limits go first, then those where requests and limits differ, and last those where they are equal. Requests set too high waste money and cause pods to sit unschedulable while the cluster looks half empty.

Expect questions on placement too. Node selectors and affinity express where a workload may run; taints and tolerations invert the relationship, letting a node repel workloads that have not explicitly opted in, which is how dedicated hardware such as GPU nodes is kept for the workloads that need it. Pod anti-affinity spreading replicas across nodes and zones is what makes a Deployment survive a node failure.

Networking is 20 percent of the syllabus and the area candidates most often gloss over.

The model to be able to state: every pod gets its own IP and pods can reach each other directly without translation, which is why the network is a flat address space rather than a set of port mappings. Pod IPs are ephemeral, so a Service provides a stable virtual address and a name, selecting the pods behind it by label. That label selector is the join, and a Service with a selector that matches nothing is a functioning Service with no endpoints, which presents as connection refused or timeouts rather than as an error at creation.

DNS resolution inside the cluster follows a predictable name pattern per service and namespace, and knowing that failed name resolution and failed connectivity are different failures with different diagnostics is a distinguishing detail.

An Ingress or Gateway sits above Services and handles routing from outside, including host and path rules and TLS termination. NetworkPolicy is the segmentation layer, and the important property is that it is deny-by-default only once a policy selects a pod: with no policies at all, everything can talk to everything, which surprises people who assume namespaces are isolation boundaries. They are not, by default.

The practical debugging chain interviewers like to hear is: does the pod have endpoints, does DNS resolve, does a direct connection to the pod IP work, does a policy block it, is the container listening on the port the Service targets.

The half of the interview that is not technical asks whether you understand that an internal platform is adopted, not imposed.

The strongest framing is that developers are customers with alternatives: they can build their own pipeline, deploy directly to the cloud provider, or simply not use what you built. So the questions to have answers for are how you would decide what to build, how you would measure whether it worked, and what you would do about a team that refuses to adopt it.

Golden paths are the usual vocabulary: a well-supported default that makes the common case easy without making the uncommon case impossible. A platform that is only a golden path becomes a blocker for anything unusual; a platform with no opinions is just a wiki.

Measurement is where DORA's delivery metrics come in. They are useful here as a set for tracking whether the platform improved delivery, and the guidance is explicit that treating an individual metric as a standalone target "encourages gaming the system", and that comparing across teams with different contexts is a mistake. A platform team measuring its own success by adoption alone risks optimising for mandated adoption rather than for teams shipping better.

Expect a question about self-service versus tickets. The answer that scores treats a ticket queue as a design failure to be automated away, while acknowledging that the first version of any capability is often a ticket, and that the mistake is leaving it there.