GitLab SRE / Platform Engineer interview questions

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 most candidates narrate only one. Knowing who proves what, and where your agent socket ends up, is the scored material.

The answer that lands is about one epoll loop per core, not config snippets. Master versus worker duties, the arithmetic of worker_connections, and the limits people forget to raise.

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.

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.

A green plan is evidence, not proof. Build the pyramid: lint in seconds, policy on every PR, real-cloud verification only where shared modules and money justify the burn.

Stack boundaries follow blast radius and change frequency, not the org chart. The monorepo only pays for itself while a machine can answer, from a commit, exactly which roots need planning.

Managed platforms sell governance, not execution: locked state with RBAC, plans on every pull request, and audit logs. Price them per resource under management against the engineering hours self-hosting quietly burns.

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.

Provider upgrades are a scheduled platform product: automatic version inventory, a canary stack inside days, automation that fans out pinned bumps with plan output attached. Estates without this routine get upgraded by deprecation deadlines.

Preview environments succeed or die on teardown: webhook destroys plus a nightly janitor with a TTL. Get the data policy and cost tagging right or the invoice ends the experiment before the demo does.

A mock can confirm that a module requests private storage while missing the IAM denial that stops creation. Separate configuration contracts from provider behavior, and make the costly tests deliberate.

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.

Both solve the same surface problem and they disagree about how. The answer that scores names what each one makes hard, and notices that the GitOps tool you use changes the calculus.

Three propagation mechanisms live inside this one question and only one of them is automatic. Most candidates promise instant reloads; the kubelet has never promised that to anyone.

Rootless is the rare security control with a visible invoice. Candidates who can name what it costs, not just what it buys, are the ones who have actually migrated a build farm.

Most candidates say the registry figures it out. The real mechanism is an index of per-platform manifests and a client-side choice at pull time, and knowing which layer makes that choice is the whole question.

Fail protects the policy, Ignore protects availability, and every real answer starts with per-webhook threat model plus scoping. The canonical outage, a webhook that rejects its own restart, separates the people who have run this from those who read about it.

Exec into a distroless image and you get nothing, because there is nothing to exec into. Ephemeral containers inject tooling into a running pod without restarting it, and the security caveats are what interviewers really listen for.

Kind precedence orders manifests, hooks jump the queue with their own weights and delete policies, and --atomic plus --wait turn hope into rollback. Split charts along blast radius, not folder aesthetics.

The interviewer does not want the three definitions. They want a decision, the number that justifies it, and what you do when the canary looks fine for nine minutes and then does not.

The fetch and pull half is a warm-up. The rebase half is where candidates either show they understand that rebasing rewrites commits or reveal that they have only ever followed instructions.

A question about developer experience as much as engineering. Measure before optimising, and notice that the trust problem and the duration problem may have different causes.

The deployment question that has a real answer and a real trap. Code and schema deploy at different speeds, and any step where they must change together is the step that causes the outage.

A question where both answers are defensible and the reasoning is the entire score. The operational consequences are concrete: what happens when a shared library needs a security patch.

Testing is a pipeline design problem in this role, not a QA one. The constraint is the question: you cannot run everything on every commit, so what you choose to defer is the answer.

The security argument for GitOps is more specific than 'Git is the source of truth'. Pull deployment can remove cluster credentials from CI, and that single fact is most of the case.

Same commit, different dependency trees: the vocabulary answer is lockfiles, the practitioner answer includes frozen installs, integrity hashes and pinned toolchains.

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.

Cost per merge beats cost per minute. Attribute spend by pipeline, attack caches and matrix sprawl first, and know what self-hosted runners really cost.

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.

Hooks must finish in seconds or developers bypass them, and a bypassed hook protects nothing. Budget feedback latency numerically and split checks by authority and hermeticity.

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.

Central pipeline logic fails two ways: forked copies that drift, or a platform team queue every change must wait behind. Versioned templates with pinned consumers and declared hooks avoid both.

Dependency bots fail as noise generators or silent auto-mergers. Tiering by risk, weekly batching, and treating bot PRs with a real review SLA is what keeps updates flowing.

Deploying the application per pull request is a solved problem. Giving it data it can work against, and dependencies it can call, is where these projects stall and where the data-protection incident lives.

A token naming the right repository does not prove that the approved deployment workflow ran. Bind the caller, deployment context and called workflow into the cloud trust contract.

OpenTelemetry is an API and a wire protocol, not a product. Candidates who promise instant multi-vendor bliss have never run the collector in production or negotiated with a vendor who knows it.

Most candidates recite the pull model and stop. The interviewer asking this wants the storage engine story, because that is where Prometheus hurts in production: crash recovery, cold queries, disk death.

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.

Routing rots because orgs change faster than configs. The senior answer treats ownership as data resolved from a catalog at fire time, with drift detection on the routing itself.

Usable runbooks live one click from the alert, front-load symptom-to-action pairs, and stay alive because CI and drills force the issue rather than anyone hoping.

One surface cannot serve the responder and the review. Tier dashboards by the question each audience asks, and make every tile answer in five seconds or link one click deeper.

Assert on the shape of a trace: which spans ran, in what order, with which attributes. Catches the cross-service regressions unit and contract tests structurally miss, at the price of instrumentation discipline.

A deceptively deep question, because there are at least six places a version can get stuck and they span the pipeline, the cluster and the edge. Work the path in order.

Everyone reaches for reinstall. The disciplined path is one journal file, four failure signatures, and an explicit decision about whether this host deserves surgery at all.

The leaf is valid and the root is trusted, yet verification fails. The gap lives in the middle of the chain, and the exact verify code names it before you open a single config file.

The automation stopped because it could not decide, which is the correct behaviour and an incomplete design. Somebody has to decide, and the interesting question is what evidence that decision needs.

A loop with no step cap has no natural ceiling, and runaway spending keeps accruing while you investigate. Stop the spend first, then find out what it was doing.

Easy to define and easy to fail. The scoring half is where each gate sits, what it does to build time, and the honest admission of what the whole set misses.

An incident response question wearing a Git costume. The wrong instinct is to rewrite history first, and it costs you the hour that matters.

The single highest-value security change available to most pipelines, and the reason it works is worth understanding rather than configuring. It removes the secret rather than protecting it.

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.

Four tools that solve the same sentence and differ on one question: where does the plaintext end up? In a regulated environment that question decides the answer.

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.

Warn forever becomes wallpaper; block on day one gets the gate switched off. The durable answer is a severity-and-fixability matrix plus suppressions that expire.

VPN grants a network, ZTNA brokers an application. The strong answer covers the engineer-specific protocols nobody mentions, device posture for contractors, and the break-glass path when the IdP is down.

One directory as source of truth, conventionally named groups, apps mapping groups to roles in code. Protocol choice matters less than mapping discipline and a joiner-mover-leaver wire that actually removes access.

Most insider incidents are boring: a departing engineer copies a repo, a contractor keeps a token. Buy hygiene rather than surveillance, and protect the culture that makes people report their own mistakes.

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.

Outbound delivery looks like a queue and a loop until one subscriber hangs for sixty seconds and takes your workers with it. Isolation, retry horizons, and signatures are where the marks are.

Reciting both acronyms is the median answer. Expert level chooses by connectivity assumptions and undo semantics, then defends CRDT metadata growth with numbers.

A platform question that is really a product question. The design is the easy half; the answer that scores explains how you would know developers chose it rather than were forced onto it.

A release-automation design question with a specific trust boundary. The novel risk is prompt injection: untrusted text reaching a privileged agent, where the text is the instruction and your usual input validation does not apply.

Untrusted text reaching a privileged agent is the whole vulnerability. It is the pull_request_target mistake again, with a model in the middle that will follow instructions it finds in the data.

The valuable part is the first ten minutes of context gathering, which is tedious and mechanical. The dangerous part is anything that changes production while a human is still working out what is wrong.

Generated infrastructure code is plausible, fluent and confidently wrong in specific ways. The volume goes up, the reviewer attention per line goes down, and the controls that used to be optional stop being optional.

Every team standing up its own tool server produces a permission surface nobody can enumerate. The gateway exists so that connecting an agent to a system is a reviewed act rather than a config file in somebody's repository.

A standards confrontation, not a mentoring story. Interviewers score whether you diagnose why the shortcut is rational, fix the system that rewards it, and confront the pattern privately with evidence.

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.

Asked in nearly every senior Kubernetes loop, and most candidates answer with a feature list. The scoring answer names the three problems it solves and then argues for not adopting it.

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. The scoring answer is what each failure causes, and why a badly configured liveness probe is more dangerous than none at all.

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.

The question that finds out whether you know Kubernetes networking or just use it. The model has three rules and everything about CNI follows from them.

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.

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.