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 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.

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. Compare what each mechanism 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. Instant reload is the common assumption and the kubelet has never offered it.

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

The registry is often assumed to figure 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.

Four nested things and one rule that explains most confusion: jobs run on different machines and share nothing unless you make them. Everything about artifacts and caching follows from that.

Git merges by comparing both branches against their common ancestor. A conflict means both sides changed the same region, and the resolution nobody checks is the one that compiles and is semantically wrong.

Compare rollout capacity, traffic exposure and state compatibility, then work through a payments canary with too little evidence to promote.

Follow commit identities through a rebase, recover a collaborator’s work with an explicit boundary, and explain the limits of force-with-lease and revert.

Calculate the pipeline critical path, separate runner queues from execution, and improve feedback time without hiding flaky or skipped checks.

Sequence a compatible column migration, reconcile concurrent writes, and identify when returning to the old application starts requiring data repair.

Compare a shared-library patch across forty services, including affected builds, staged releases, runtime inventory and source-access boundaries.

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.

The pull model is the famous part and explains none of the operational pain. The storage engine 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.

Queue time and build time are separate problems with separate fixes, and most teams spend a quarter optimising the one that is not hurting. Size the fleet from arrival rate, then attack the build with caching and graph awareness.

Most migrations are safe and a handful can take the site down by holding a lock for eight seconds. Build the tooling to tell those apart automatically, because a review culture cannot do it two hundred times a month.

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.

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.

Announcing a deadline is not a migration plan. The teams that miss it are the ones who were never going to read the announcement.

A generated template is a copy, not a link. Drift is not a discipline failure, it is the predictable result of the mechanism you chose.

Forty minutes is a symptom with at least four different causes, and three of them are cheaper to fix than moving everyone's development to a remote machine.

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

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.

Address repeated test and review bypasses through verified evidence, immediate risk containment and a repair that preserves the required coverage.

Evaluate a bespoke platform request by its user need, lifetime support cost and available alternatives, then record the decision and any bounded exception.

Define the shared operating requirements before standardizing delivery, then test representative migrations and keep supported exceptions explicit.

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.

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.

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.

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.

Service types choose how an application is exposed. Follow the actual traffic path: cloud controllers can target nodes or pods, and internal exposure differs from public exposure.

A Service moves connections and an Ingress reads requests. The gap between those two sentences is hostname routing, path routing and TLS, and it is also why an Ingress object alone does nothing.

Compare proxy, hosted and group repositories. Trace a tested artifact into production, and understand when a cache can keep builds running during an upstream outage.

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.