Red Hat SRE / Platform Engineer interview questions

Five stages, and which one you are stuck in tells you what to fix. A machine that reaches a GRUB prompt has a different problem from one that hangs waiting on a filesystem that no longer exists.

Most of what looks like used memory on a healthy Linux box is page cache doing its job. Knowing which column to read, and why df and du disagree, is half of Linux triage.

Two different resources produce the same errno, and the second one is invisible unless you know to look. One command distinguishes them.

A beginner question with a senior follow-up hiding in it. Once you know a hard link is a second name for an inode, log rotation and backup behaviour both stop being mysterious.

The two-syscall duet behind every process on the box. The follow-ups live in what survives the transition, and candidates who skip that fail the next question.

Most hand-written units boot in dev and die in production. The gap is Type selection, restart policy, and the drop-in workflow vendors expect you to respect.

Two authentications happen in every SSH session, and the one usually left out is the server proving itself to you. Knowing who proves what, and where your agent socket ends up, is the scored material.

Everything top, htop and your APM agent display is derived from procfs anyway. Knowing the raw files turns any bare SSH session into a monitoring console.

Five commands separate people who have actually built this from people who read about it once. Here is the working sequence, plus the gotchas that break it.

tcpdump copies packets to userland; eBPF aggregates inside the kernel next to the event. Know which hook runs where, what a verifier log is telling you, and when XDP drops for free.

Patching is easy; surviving the rollout is the interview. Staged rings with health gates, what livepatching can and cannot buy you, and the rollback plan you write before starting.

Sets instead of thousand-rule chains, one engine for both IP families, atomic ruleset swaps, and a compatibility shim with sharp edges. Migration risk lives in coexistence and tooling assumptions, not syntax.

Volatile by default on many distros, size-capped by silent policy, binary on disk. Know the storage modes, the vacuum knobs, and how journald feeds central logging.

Absolute caps versus latency-target protection, systemd IO attributes versus raw io.max, and why ionice lies to you. The staff-level answer assigns the job its own slice with intent.

Roles versus users looks like syntax trivia and is actually a secrets-management position. The follow-ups about instance profiles and IRSA separate practitioners from tutorial graduates.

Managed Kubernetes offers several responsibility models. Application availability remains yours even when the provider also manages nodes and networking, and the interview tests whether you know where that line sits.

It copies a small Python program to the target over SSH, runs it, and deletes it. Once that is clear, the agentless claim, the performance characteristics and the idempotency requirement all stop being separate topics.

A staple of services-company interviews, and the boring answer (provisioning versus configuration) is only half of it. The useful half is what happens when you push either tool past its model.

The question that finds out whether someone writes playbooks or writes shell scripts wrapped in YAML. Idempotence is a property of the module you chose, not of Ansible.

Scan plan JSON on every pull request, run new rules advisory for two weeks, and block only what is law. Waivers live in version control with an owner and an expiry date, or the gate becomes noise within a quarter.

Vault's weakness is the single shared password, not the AES256 underneath. The senior answer covers rekey ceremonies on offboarding, encrypt_string for readable diffs, labelled vault-ids per environment, and shrinking what needs encrypting at all.

OpenTofu is the Linux Foundation fork of Terraform 1.5 under MPL, drop-in compatible for most code, with distinct features such as native state encryption. Removed blocks and provider mocking also exist in Terraform. Portability survives by pinning version floors and testing both binaries in CI.

Distinguish a gated Terraform run workflow from a cloud controller that reconciles continuously. Both can start from Git, but they expose different approval, drift and credential boundaries.

The pitch is continuous reconciliation instead of a plan someone runs. The cost is that your cloud estate now depends on a cluster, and that drift correction without a plan step is a very different risk posture.

A VM virtualises hardware and boots its own kernel. A container is a process on the host kernel with its view of the world restricted. Everything else, including the security answer, follows from that one difference.

Follow a Deployment change through the API server, controllers, scheduler and kubelet. Each handoff gives you a different place to investigate when a pod never starts.

A pod is a shared network and storage boundary that happens to contain containers. Once you can say what the containers inside one share, sidecars and init containers stop needing separate explanations.

Three states, three completely different causes, and one command that tells you which you are looking at. The state name says whether the problem is the scheduler, the registry or your own process.

A namespace scopes names, permissions and quotas. It does not scope the kernel or the network by default, and the gap between what people assume it isolates and what it does is where the trouble starts.

A ReplicaSet keeps a count. A Deployment manages a sequence of ReplicaSets, and that is the entire difference: it is what turns a change into a rollout you can pause and undo.

Build instructions depend on earlier inputs, so changing source can invalidate a dependency installation placed after it. Ordering the Dockerfile by how often things change is the whole optimisation, and multi-stage is how the compiler stops shipping to production.

The single most common Kubernetes interview question, and the one where a vague answer is most obvious. Every stage you name is a place the interviewer can ask you to debug.

The writable layer is part of the container, not the image, and it dies with the container. Everything about volumes follows from knowing which of those two a file is in.

It is Kubernetes with an opinion, and the opinion that catches everyone is that containers do not run as root. A manifest that works on vanilla Kubernetes and fails here usually fails for exactly that reason.

Evaluate identity, traffic policy and telemetry against measured proxy overhead and operating responsibilities, then test the authorization boundary.

Both run pods, so the answer sounds obvious until an interviewer asks what happens when you delete one. The guarantees are narrower and more specific than most candidates think.

Everyone can recite the three. Explain what each failure causes, and why a badly configured liveness probe is more dangerous than none at all.

Trace sandbox setup, address allocation and a cross-node packet, then distinguish pod reachability from Service translation.

Almost always a finalizer, and the fast fix is the one that loses data. The safe answer explains what the finalizer is protecting against before removing it.

A practical question with a precise answer, and the size is not the real cost. Pull time on every node, registry storage, and attack surface all scale with it.

The scheduler is behaving correctly, which is the part that confuses people. It optimises placement at admission time and never revisits, so a cluster drifts out of balance by design.

Both solve the same surface problem and they disagree about how. Compare what each mechanism makes hard, and notices that the GitOps tool you use changes the calculus.

Compare the configured Service datapaths and their lookup and update mechanisms. The iptables datapath degrades with service count, and eBPF replaces a linear scan with a map lookup.

Default-deny egress breaks name resolution before it breaks anything else, and every connection times out confusingly. The practitioners are the ones who test with positive AND negative probes and know their CNI's fine print.

The two ideas that decide whether an operator is safe are level-triggered reconciliation and finalizer semantics. The partition question separates people who have written a controller from people who have installed one.

Explain per-node eligibility and update behaviour, then verify that a Ready collector is actually delivering logs.

Rootless is the rare security control with a visible invoice. Compare its effective resource controls, storage behaviour and remaining host-user access.

The kubelet is a local reconcile loop with its own event stream, probe workers and eviction brain. The detail worth holding onto is that Ready status can reflect either a reported health failure or missing heartbeats, and those have different causes and different fixes.

Every control plane component depends on the API server, so who starts the API server? The bootstrap paradox sits at the heart of every cluster, and the kubelet plus a directory of files is the accepted way out.

Dockershim is gone and the CRI contract decides what a runtime must do. The senior-level part is the shim model: a supervisor process that owns exit codes and stdio so the daemon can die without taking workloads with it.

Repeated full-resource polling can make an operator an expensive API client. This question separates people who run controllers at ten-thousand-object scale from those who copied a tutorial: watch semantics, cache behaviour, and which LISTs touch etcd.

SSH plus yum is how outages start. The senior answer replaces nodes from versioned images on a cadence, orchestrates with surge capacity and PDBs, and can explain the kernel-skew problem that makes fleet homogeneity a feature.

Upgrades look like rolling restarts right up to the morning the CNI stops talking to the new kubelet. The scored answer is ordering, skew policy, and addon sequencing, not courage under pressure.

Pods authenticate with JWTs minted per-pod now, not eternal Secrets. The scored answer separates authentication from authorization, explains audience binding, and treats automount as opt-in rather than ambient.

Yes, the proxy moves: one L4 agent per node, eBPF in-kernel, waypoints only where L7 policy demands. The scored answer quantifies the sidecar bill, compares where each architecture lands the proxy, and names migration risks.

Heartbeats, conditions and taints are the only vocabulary the control plane understands. NPD translates journald and kernel ring messages into that vocabulary; custom plugins carry your hardware's dialect.

Kubernetes does not see GPUs, it sees an extended resource that something has to advertise. When that advertisement is missing or wrong, the scheduler is behaving correctly and the node is lying.

A Job with a sidecar was broken by design for years: the workload finishes, the proxy does not, and the pod never terminates. Native sidecars fix it by making the container an init container that keeps running.

Changing pod resources historically required recreation, which made vertical autoscaling disruptive for workloads with expensive recovery. In-place resize changes that, with limits worth knowing.

Ingress solved routing by convention and annotation, which meant every controller invented its own. Gateway API's real contribution is not features, it is splitting one object into three so that platform and application teams stop editing the same file.

An end-of-maintenance date changes the risk even while traffic stays healthy. The work is proving routing and security parity before moving a production hostname.

Clusters multiply for good reasons: regions, isolation, tenancy, blast radius. The problem is not creating them, it is that cluster seven diverges from cluster three and nobody knows until an upgrade behaves differently.

Route attachment and cross-namespace backend access have different owners. Use route status to find the failing boundary before broadening any permission.

Self-heal did exactly what it was configured to do. The response needs an authorized emergency path, a controlled reconciliation pause when required, and evidence that automation can resume safely.

One Application declaring others sounds like trivia until you need to rebuild a cluster in an afternoon or hand a team a bounded slice of the platform. Here is when the pattern earns its keep, and when ApplicationSet should replace it.

Public fork PRs normally get a read-only token and no repository secrets. Privileged triggers, runner access and untrusted shell input can break that boundary.

Base layers are dependencies: digest-pin them, let bots bump them weekly, and let CVE disclosures trigger scoped rebuilds through the normal pipeline. Days, not quarters.

Changelogs fail because discipline lives in people instead of gates. Enforce commit convention at merge time, generate at tag time, and know what automation cannot write.

Backports look trivial until a cherry-pick conflicts. Branch-per-line discipline, forward-port-first ordering, and an honest EOL calendar are what keep three versions shippable at once.

Dashboard sprawl is an operating-model problem wearing a tooling costume. The scored answer moves definitions into git, attaches ownership metadata to every panel, and deletes without ceremony.

Three places, and which one depends on how the thing was started. Knowing which logs the runtime collects and which the application writes itself, and that journald may not persist across reboots, saves the first twenty minutes.

Tests whether you know that Kubernetes waits, and for how long. The default timings surprise most candidates, and they explain why a node failure hurts longer than people expect.

One disk metric explaining a whole cluster's weirdness is the point of this question. Restarting etcd first turns a slow cluster into a down one, because a restarted member has to catch up before it can vote.

Same-node good, cross-node bad is not a random clue, it is nearly a diagnosis. One short decision tree separates overlay reachability, encapsulation blocks, MTU and policy.

The kill was not random and it was not fair. Learn the scoring function the kernel actually uses, then bend it with oom_score_adj before your monitoring dies during the next leak.

Every client fails at once, which rules out pods and points at shared PKI. Know which certificates share one expiry clock, and a controlled recovery that preserves cluster state.

A drain that hangs without erroring is almost always eviction being refused, and the two refusals that look identical from the outside have opposite fixes.

The disk is not full, the keyspace quota is. Defragmenting without disarming the alarm leaves the cluster read-only, and disarming without compacting puts it back within minutes.

Running pods already have their images, so a credential expiry is invisible until something needs to start. That gap is why this always surfaces during an unrelated incident, at the worst moment.

Three terms that get used interchangeably and answer three different questions. The one that makes them operational is the admission rule at the end: no provenance, no deploy.

Most clusters fail an RBAC review on the same handful of patterns. Naming them concretely, plus the namespace-first design that prevents them, is what separates operators from tutorial readers.

Naming the replacement is the floor of this question. What scores is the audit-then-warn-then-enforce sequence and an honest answer about the vendor chart you cannot fix.

Signing proves what shipped, not what runs. The strong answer covers syscall-level detection, the signals that matter, tuning against alert fatigue, and the response path once a sensor fires.

Break-glass exists to restore login when the identity provider is the thing that died. Few accounts, sealed hardware factors, an alert on every authentication, a printed runbook and a quarterly drill.

Escapes ride kernel bugs, privileged configuration and host mounts, not namespace magic. Cut the syscall and capability surface first, sandbox only what the trust boundary demands, and build nodes expecting compromise.

An agent is a workload that acts on behalf of a person, holds credentials for several systems, and decides what to call based on text it read. Every one of those properties breaks an assumption in your existing access model.

This is a machine identity problem wearing a secrets costume. Candidates who start at encryption miss that authentication of the caller and delivery mechanics are the real design space.

Build once and move the same bytes. The moment an environment rebuilds from source, you are testing something that has never run anywhere, and no amount of pipeline output can tell you what production holds.

Turning on strict mTLS across two hundred services in one change breaks everything that talks to something outside the mesh. Permissive mode exists so the migration can be observed instead of guessed at.

The instinct is to build a portal. The ticket mix decides whether a portal helps at all, and most teams never count it.

The expensive part of these incidents is almost never the fix. It is the twenty minutes spent deciding whose incident it is.

Each team is behaving rationally. The cost of migrating is theirs, immediate and certain; the benefit is later and uncertain. That asymmetry does not resolve by being explained again.

Operational load is not a discipline problem. It is the interest payment on everything the team shipped without an owner, and it compounds.

Saying yes without a contribution contract produces features the platform team did not design and now supports forever, on call, at 3am.

The driver, the container toolkit, the CUDA runtime inside the image and the framework build all have to agree. Upgrade the wrong one first and every pod on the node fails to start with an error that names none of them.

A model artifact is code that runs in your cluster with GPU access. Most of the supply-chain controls you already run for containers apply, and the file format adds one of its own.

Retire an internal tool through verified user needs, compatibility evidence and an owned cutover, while treating its maintainer as a source of context rather than a barrier.

The question that separates people who have debugged a hung rollout from people who have read about one. The interesting half is not the signal, it is PID 1.

Ordering and retransmission are what TCP adds, and both of them cost time. Naming something that deliberately gives them up, and saying why, is what turns a textbook answer into a real one.

The pair everyone configures and few can explain. QoS hints at eviction risk, but usage versus requests and Pod priority determine node-pressure ranking, and CPU and memory behave completely differently when you exceed them.

A staple of every networking round, and the follow-up is always about TLS termination. Knowing which layer sees what decides most of the answer.

The oldest question in systems interviewing and still the best, because it is unbounded: every layer you can describe is another layer you could debug.

Experienced answers are ordered and verifiable: minimal base, benchmark applied as code, identity and exposure next, then continuous proof it stayed that way. Checklists recited out of order are the tell.

The classic ephemeral port exhaustion question. TIME_WAIT is a familiar phrase and the useful facts are narrower: which side accumulates it, and why the popular fix is dangerous.

Everyone can say state maps config to reality. The follow-up that separates candidates is what else is in the file, and what that means for who may read it.