platform engineering

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.

Generation works when the inputs are genuinely data and dies when YAML grows loops. The line between encoding decisions and writing a worse programming language is where these interviews are actually scored.

Registries live or die on upgrade ergonomics, not on publishing features. Green example plans gate every tag, automation delivers upgrade PRs with plan output to consumers, and retirement is a census plus a date.

Tenancy is a dial from policy-based soft isolation to hard cluster boundaries with a virtual-control-plane middle ground. The scored answer picks by blast radius requirements and names what each model still leaves shared.

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.

Internal platforms hide a trap: the direct user is an engineer, but the real traffic belongs to their customers. Define SLIs from the consumer's vantage and turn the error budget into roadmap currency.

Threat modelling dies as a document ritual and lives as a design-stage habit. The answer that scores: tier reviews by blast radius, short sessions on RFCs, findings filed where engineers already work.

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.

This is a platform-organization question disguised as infrastructure. Score comes from separating enforcement from ownership and explaining what stops the gateway becoming a smart ESB.

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.

A catalogue nobody updates is worse than no catalogue, because people trust it once and get burned. Derive everything you can from systems that are already true, and make the rest a gate rather than a request.

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.

The instinct is to build a portal. The ticket mix decides whether a portal helps at all, and most teams never count 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.

Refuse every exception and teams leave the platform without telling you. Grant them freely and you are patching nine stacks. The detail that decides it is whether the exception has an expiry date.

Registration coverage tells you a script ran. It says nothing about whether an engineer has ever found the portal worth opening.

An internal platform with no stated objective still has one. Every team guesses it, they all guess differently, and the guesses only surface during an outage.

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

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.

Complaints measure volume and confidence, not cost. The loudest team is usually the one most comfortable complaining, which is not the same as the one losing the most time.

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.

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.

Support demand grows with teams multiplied by surface area, and headcount does not. The only durable lever is removing the reason people ask.

You cannot run the counterfactual. What survives scrutiny is a comparison design that narrows the alternatives, not a number that claims to settle it.

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.

Every capability a platform accepts is a permanent operational commitment. Teams that cannot say no end up operating six things badly instead of two things well.

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

Plan an on-call transition around service readiness, responder capacity and authority, with rehearsed escalation and evidence that the operating burden is sustainable.

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