Atlassian SRE / Platform Engineer interview questions

Every ops engineer schedules jobs; few can say which shell cron uses, where stdout lands, or why percent signs delete half a command. Those gaps are exactly what interviews test.

A and AAAA are the easy part. The bites live at the zone apex, inside 255-byte TXT chunks, in CAA blocking your renewals, and in SRV records half the internet ignores.

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.

Most candidates can sell serverless. The question asks you to argue against it, which needs a real understanding of the execution model rather than the marketing.

Sessions, locks and pub/sub are three very different contracts with the same server. Knowing which guarantees each one lacks is the difference between a cache and an outage.

Rapid function scaling can overwhelm a shared dependency. Concurrency limits, reserved capacity and queue buffering are the containment toolkit.

Origin access control pins the bucket to your distribution, and signed URLs or cookies decide who plays what. Get the expiry wrong and the leak comes back with a signature on it.

Account-per-team is the right instinct, but hand-rolled account setup drifts within a month. Vending turns governance into a pipeline with an SLA instead of a ticket queue.

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.

The Terraform question that actually filters. Everyone knows both meta-arguments exist; the answer is about how state addresses resources, and why an index is a fragile key.

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.

Everyone answers state locking. The follow-up is what happens when locking is not configured, and what you do with a stale lock at 2am, which is where the answer gets real.

Extract too early and you maintain a wrapper nobody thanks you for. Here is the extraction trigger, the semver contract that maps onto Terraform surfaces, and the parallel-release path for breaking changes.

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.

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.

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.

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

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

A specific configuration trap with a clean explanation. Both controllers act on the same signal from opposite directions, and the result oscillates.

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.

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.

Scale-downers mark a node removable only when every pod on it can leave safely. Your batch workload died because nothing marked it special. The mechanism is a filter cascade, and the fix is priorities, PDBs and annotations.

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.

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.

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

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.

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.

A vocabulary check with a trap inside it. Strict semantic versions bind libraries and SDKs; continuously deployed services play a different game, and pretending otherwise signals inexperience.

Long-lived branches pile up merge debt until integration becomes a gamble. There is a named technique that ships a three-month refactor in releasable increments, and its final step is deletion.

The honest mechanics of merging to trunk many times a day: flags, fast CI, trunk locks, and the conditions under which you should not run it at all.

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

Green PRs can still break main because they were validated against a stale tip. Merge queues revalidate the exact combination that lands, trading latency for certainty.

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.

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.

One cadence for every team is the naive answer. Cadence follows constraints: store review for mobile, compatibility windows for APIs, contracts and embedded realities for trains.

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.

Metrics describe the server's experience; synthetics describe the user's. The strong answer designs a few money-path journeys from real geographies, pages only on persistent failure, and budgets for script rot.

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.

Rotation length decides focus versus fatigue, handoff quality decides whether Tuesday inherits Monday's mess, and follow-the-sun only works when every region holds real authority.

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.

Comms is a role, not a chore bolted onto the incident commander. Audience-specific cadences, a committed next-update time in every message, and plain language that support can actually repeat.

You have added a dependency with a latency distribution an order of magnitude wider than anything else in your stack, whose failure mode is a plausible wrong answer rather than an error.

Agent per node, gateway per cluster, and one decision that shapes everything else: tail sampling needs every span of a trace in one place, which is why the topology has a tier that looks redundant until you need it.

There is no status code and no caller waiting, so latency and error rate stop meaning what they meant. The signals that replace them are age, lag and completion, and they answer a question the request-response set never had to ask.

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.

Self-healing unavailability is a timeout arithmetic story. Pull the balancer's removal timestamps, lay them against the GC log, and the pause that ejects the instance will be sitting there in plain sight.

A public registry throttles by source IP and your whole fleet shares one. Why fifty nodes count as a single anonymous user, and authentication and caching changes that reduce upstream demand.

Every client fails at once, which rules out pods and points at shared PKI. Know which certificates share one expiry clock, and the ten-minute fix that avoids a rebuild.

Slow leaks hide inside restart cycles and percentage thresholds. Plot weeks of absolute memory against deploys, prove it with profiler deltas, and alert on predicted time-to-limit instead.

A rebuilt index and a wrong answer means the staleness is somewhere else: a cache, a routing pointer, a chunk that survived deletion, or a document that never reached the pipeline at all.

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.

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.

Exceptions rot when they lack expiry dates, named owners and an aggregate view. Structured records where engineers work, auto-expiry with teeth, and a monthly portfolio review that treats growth as a control failure.

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.

Champions programmes die as mailing lists with a name. Survivors protect the time, pay in career currency, keep the job description tiny, and measure outcomes rather than attendance.

The dangerous question is not whether the vendor is secure but what the integration can touch once connected. Scope of granted access, data flow, offboarding, then tier the vendor and match effort to tier.

Adoption is a product problem: templates with tested safe defaults, guardrails that start in audit mode, and metrics on paved-road share. Remove reasons to leave the road rather than writing memos.

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.

Model output is attacker-influenced data by construction, because the model reads attacker-influenced input. Every rule you already apply to user input applies here, and teams forget because the text came from a system they built.

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.

Flags sit on the request path of everything, so a slow flag service is a site-wide outage waiting to happen. Local snapshots, propagation numbers, and audit trails are what interviewers dig for.

Every candidate lists the three isolation models. The offer-worthy answer prices them per tenant, does the migration fan-out arithmetic, and lands on a hybrid with reversal conditions.

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

Teams need comparable evaluations before they approve a model change. Design versioned test data, recorded runs and release thresholds that a pipeline can enforce.

The hard parts are not search. They are deciding what to keep before you pay to store it, isolating one team's query from everyone else's, and making the cost visible to the people generating it.

Without one, every team implements its own retries, its own key handling, its own logging policy, and nobody can answer what the company spends or what a model change would break.

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.

Token spend has no natural ceiling. Every retry, every retrieved document, every chain step multiplies, and nothing in the system tells anyone until the invoice arrives.

Both workloads are legitimate and they want opposite things from the same GPU. Combine tenant rate limits with fair admission and measured capacity reservations; separate fleets are an option when shared scheduling cannot meet the targets.

It reads as a configuration change and it is a capacity change. Cache memory per request grows with the limit, prefill cost grows with what people actually send, and concurrency falls in proportion.

Asking nicely in the prompt gets you most of the way and fails on the tail, which is where the automation breaks. Constrained decoding can guarantee the shape of completed output for supported schemas. Interrupted generations still need a failure path, and compilation has a latency cost.

A model provider is a single dependency with a shared failure domain across every customer they have. Treating it like a database you cannot fail over from is how a product goes down for four hours.

One request touches an embedding call, a vector search, a rerank, a prompt build and a generation, and a single duration for the whole thing tells you nothing about any of them.

Prompts contain whatever the user typed, which in a support product is names, account numbers and medical detail. Full-text logging is a data-protection decision, not a debugging preference.

The database part is easy. The operational problems are reindexing when the embedding model changes, recall degrading silently as filters get stricter, and memory growing faster than anyone forecast.

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.

Shared batching puts two tenants' data in one process on one device. That is defensible, and it is not what most customers assume they bought, so the answer has to be specific about which boundary exists where.

A mandatory gateway can centralize limits and filtering, while applications authorize business actions. Neither a prompt nor a PII classifier guarantees that sensitive data stays private.

The most revealing behavioral question there is, because the interesting part is what you did after losing. Most candidates answer a different question, the one where they were right all along.

This question scores negotiation shape, not stubbornness. Interviewers want the candidate who re-scoped reality honestly, and they are screening out both the pushover and the person who just says no.

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.

Use a real example if you have shipped an AI feature. If you have not, say so and offer a clearly hypothetical response about evaluation, containment and customer communication.

Arguing that reliability matters loses to a roadmap every time, because both sides agree it matters. What wins is converting it into the same currency features are argued in: a number, a cost, and a decision someone owns.

Asked in almost every cloud screen, and most candidates recite the table without ever naming the failure it causes. The ephemeral port range is the whole answer.

Turns the standard autoscaling definition into the problem it actually causes. Almost every candidate can define an HPA; far fewer can say why theirs did not save them.

The question that separates console users from people who have debugged a permissions failure across accounts. Evaluation order is deterministic and knowing it makes AccessDenied readable.

A design question with a clear answer at this scale, and the reasoning is what scores. The three options solve different problems and peering and Transit Gateway connect networks while PrivateLink exposes services.

Trace the route and return path before changing rules. First establish whether the failing connection uses IPv4, IPv6 or a private service endpoint.

The junior-filter question that still separates candidates who understand the model from those who memorised a definition. The answer is three mechanical differences and one economic one.

S3 access failures are rarely about the bucket policy alone. The caller, object ownership and network path determine which authorization checks apply. Start with the failed request and trace changes across those boundaries.

Database redundancy still needs reconnecting clients. Distinguish the deployment type, then measure how promotion and DNS changes affect application requests.