Platform engineering fundamentals

Treat the internal engineers who use the platform as customers with a choice, not as a captive audience. Concretely, that means the platform team runs discovery before building a feature, tracks adoption rather than assuming a mandate will produce it, and accepts that a paved road nobody chooses to drive on has failed regardless of how well it was engineered. The alternative — building whatever the platform team believes infrastructure should look like and then mandating its use — produces compliant but resentful usage, and resentful usage is the leading indicator of the workaround that shows up eighteen months later.

An infrastructure team provisions and operates the underlying compute, network and storage; a platform team builds the self-service layer and the golden paths on top of it that let other engineers use that infrastructure without filing a ticket. The distinction matters because it changes who is being served: infrastructure serves the organisation's operational requirements, while a platform serves other engineers' daily workflow, and is measured by how much friction it removes from their work rather than by uptime alone. Many organisations run both functions inside one team, but conflating the two goals inside one roadmap is a common cause of a platform that is reliable and unloved.

Uptime alone tells you the platform didn't break; it says nothing about whether it's actually helping anyone, which is the number that determines whether the investment was worth it.

Metric                          What it actually tells you
-------------------------------  ---------------------------------------------
Weekly active users / eligible   Adoption, not just availability
Time from request to first use   Whether onboarding friction is real
Support tickets per feature      Where the self-service model is leaking
Deploy frequency, lead time      Whether teams are shipping faster because
                                  of the platform, not despite it
Voluntary opt-out rate           Whether teams leave the golden path and
                                  why, tracked explicitly rather than guessed

The metric worth resisting is a vanity number like total services onboarded, because it counts adoption at generation time and says nothing about whether those services still use the platform six months later. Voluntary opt-out is the uncomfortable one to track and the most honest, because a platform team that only measures what it built will never notice what got quietly abandoned.

A paved road is the platform team's recommended, supported way of doing something — the default CI template, the standard deployment pipeline — built to be clearly the easiest option without being the only one. It has to stay optional because forcing it onto a case it genuinely doesn't fit produces either a broken deployment forced into a shape it wasn't designed for, or a team that quietly forks the template and stops receiving any of its future updates. An enforced road produces compliance; an attractive one produces genuine adoption, and the two look identical in a rollout announcement but behave very differently a year later.

Because every speculative feature is built without a real user validating it, and it competes for the same limited engineering time as the feature an actual team is currently blocked on. A platform roadmap driven by "teams will eventually need multi-region support" instead of the specific team asking for a faster local development loop right now produces a platform that is broad and thin, technically covering many scenarios while poorly serving the scenario someone actually has today. The corrective discipline is building for a named team's named problem first, and generalising only once a second team hits the identical need.

Weigh the cost of integration and ongoing maintenance against the cost of building and then owning the equivalent forever, and weight that comparison by how close the capability is to your actual differentiator. A service catalog, a CI runner fleet, or a secrets vault are commodity problems solved well by existing tools, so building one from scratch is usually rebuilding something a vendor has already hardened against edge cases you haven't hit yet. The build case strengthens sharply when the requirement is genuinely specific to your organisation's constraints — a compliance rule no vendor product encodes, or an integration with a legacy system no product anticipates.

Rank by the product of how many teams are blocked and how completely they're blocked, not by who asked loudest or most recently, because a squeaky-wheel backlog optimises for internal politics rather than organisational throughput.

Request                        Teams blocked   Severity          Priority signal
------------------------------ --------------- ------------------ ---------------
Faster CI feedback loop        30 of 40 teams  Slower, not stuck  High reach, moderate severity
New compliance gate mandated   40 of 40 teams  Legally required   Non-negotiable, schedule first
Custom deploy target for 1 team 1 of 40 teams  Fully blocked      Low reach, high local severity

The genuinely hard case is the third row: one team fully blocked is a real problem for that team, but building a one-off integration to unblock it sets a precedent that the platform builds bespoke features on request, which does not scale as the number of teams grows. The usual resolution is to unblock that team with a manual workaround while declining to generalise the platform around a single team's need, and being explicit with that team about why.

It gives an organisation with hundreds of services one place to answer "what exists, who owns it, and how do I do the thing every service needs to do" — instead of that knowledge living in scattered wikis, a person's memory, or nowhere. The value compounds with the number of services, which is why small organisations often feel the tool is overkill: with ten services, everyone already knows who owns what, and the catalog is solving a problem that hasn't appeared yet.

A parameterised generator that produces a new service with the organisation's standard choices already made — the pipeline, the base image, the health-check endpoint, the on-call registration — so a team starts from a working, compliant baseline instead of copying fragments from an existing service and hoping they're still current. Its value is largest at the moment of creation and decays afterwards unless the template is also the mechanism for propagating later changes, which most template systems don't do automatically once a service has diverged from its generated starting point.

A plugin model lets each team add exactly the integration it needs — a cost dashboard, a deployment status widget — without the core platform team building or maintaining every feature itself, which is what makes the ecosystem scale beyond one team's capacity. The cost is that plugin quality and maintenance burden now vary by whoever wrote each one, and a portal accumulating dozens of thinly maintained plugins becomes fragile in ways the platform team didn't sign up for. The workable middle ground most organisations land on is curating a small, centrally owned set of plugins and treating anything beyond that as the requesting team's own maintenance responsibility.

A catalog entity is rarely useful alone; its value comes from the edges connecting it to a team, an API it exposes, and the other services it depends on.

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: checkout-service
  annotations:
    backstage.io/techdocs-ref: dir:.
spec:
  type: service
  owner: group:checkout-team      # resolves against an identity system
  dependsOn:
    - component:payments-gateway  # an edge, not just a label
  providesApis:
    - checkout-api

flowchart LR
    T[Team: checkout-team] -->|owns| C[checkout-service]
    C -->|depends on| P[payments-gateway]
    C -->|provides| A[checkout-api]

The edge worth noticing is dependsOn. A catalog that only records ownership answers "who do I contact"; a catalog that also records dependencies answers "what breaks if I change this", which is the question that actually matters during an incident or a planned migration, and it requires every team to keep the edges current rather than only the metadata about themselves.

Entities get created easily — often automatically, from a repository's existence — and almost never get deleted, because nobody owns the decision to remove one and doing so risks breaking a reference somewhere unseen. A catalog five years old accumulates entries for services that were decommissioned years earlier, and the accumulation quietly erodes trust in search results the same way stale ownership data does: a search returning three results, two of which no longer exist, teaches people to stop trusting the search.

Because they were built to a specification rather than validated against a specific team's actual daily task, so the portal covers what the platform team assumed was needed rather than what anyone opens the tool for repeatedly. A portal serving a page people need during an incident earns habitual use; a portal that mainly duplicates something a faster Slack query already answers will lose to that habit regardless of how polished its interface is, and no amount of onboarding messaging fixes a tool that is genuinely slower than the alternative it's replacing.

Continuous delivery means every change that passes the pipeline is in a releasable state, with a human deciding when it actually ships. Continuous deployment removes that human gate, so a passing change reaches production automatically. The practical difference is organisational risk tolerance and test confidence: continuous deployment demands a test suite and set of guardrails good enough that nobody needs to eyeball a diff before it reaches customers, which most organisations build toward gradually rather than adopt on day one.

A cache that's wrong in either direction is worse than no cache at all: too loose and it serves stale output silently, too strict and it never hits and buys nothing.

Cache key built from: source file hashes, compiler version, build flags

Correct:  key changes whenever anything that affects output changes
          -> cache hit means the output is provably identical

Too loose: key omits the compiler version
           -> a compiler upgrade reuses output built with the old compiler,
              and a subtle behaviour change ships without anyone rebuilding

Too strict: key includes an unrelated environment variable that always differs
            -> the cache never hits, and every build pays full cost while a
               dashboard still calls it "caching enabled"

The failure that actually damages trust is the loose key, because it produces a wrong build that looks like a successful one — nothing errors, the pipeline is green, and the bug ships. Getting the key exactly right, covering every input that can change output and nothing that can't, is the entire difficulty of build caching; everything else about it is bookkeeping.

A managed runner service removes the operational burden of patching, scaling and securing the machines that execute your jobs, at a per-minute cost that scales with usage and a ceiling on customisation — you generally can't attach specialised hardware or tune the network path the way you could on your own infrastructure. Self-hosted runners give you full control over the environment, can be cheaper at high, steady volume, and can sit inside your own network for jobs that need access to internal resources, at the cost of your platform team now operating a fleet of compute with its own patching, scaling and security surface. Most organisations end up with both: managed runners for the common case, and a self-hosted pool for jobs with a specific hardware or network requirement the managed offering can't meet.

A mechanism that serialises merges to a shared branch, testing each candidate change against the latest state of the branch, including changes that merged just ahead of it, before actually merging it. It prevents the specific failure where two individually passing pull requests break the branch when combined, because each was tested against a base that didn't yet include the other. Without a queue, that combination is discovered only after both land, on a broken main branch everyone else now has to work around.

A test that fails intermittently for reasons unrelated to the change being tested trains engineers to re-run a failing pipeline rather than investigate it, and that habit generalises to genuine failures once someone can no longer tell the two apart by looking at the result alone. Quarantining a known-flaky test — moving it out of the blocking suite into a tracked, non-blocking one until it's fixed — protects the signal value of a red pipeline, which is the entire reason the pipeline exists. Leaving flaky tests in the blocking path indefinitely is a slow, compounding tax on how much anyone trusts a passing or failing result.

Independent stages run in parallel where nothing depends on their order, and converge only where a later step genuinely needs all of them to have finished.

flowchart TD
    A[Checkout code] --> B[Unit tests]
    A --> C[Lint]
    A --> D[Security scan]
    B --> E[Converge: all must pass]
    C --> E
    D --> E
    E --> F[Build artifact]
    F --> G[Deploy to staging]

The point of the fan-out is that lint, unit tests and a security scan share no dependency on each other, so running them sequentially only adds wall-clock time without adding safety. The convergence point at E is deliberate and narrow: it exists because building an artifact from code that failed any of the three checks is pointless work, not because the three checks needed to run in any particular order relative to each other.

Working in short-lived branches merged to the main branch frequently, often daily, rather than maintaining long-lived feature branches that diverge for weeks. It changes CI design because the volume of merges to trunk becomes much higher and each one is smaller, which is exactly the workload a merge queue and fast, reliable pipelines are built to handle; a pipeline that takes forty minutes is tolerable against ten merges a day and untenable against a hundred. Long-lived branches hide integration problems until a large, painful merge; trunk-based development trades that for needing CI infrastructure good enough to absorb constant small integrations.

Compute for the environment's lifetime, plus the harder cost: keeping its data realistic enough to catch bugs without copying production data verbatim, which usually means a scaled-down or synthetic dataset refreshed on some schedule. The value is catching integration bugs before merge rather than after, on infrastructure that mirrors production closely enough for the test to mean something. Teams that skip the data problem end up with environments that are fast to spin up and nearly useless, because every test against an empty or unrealistic dataset passes regardless of what the change actually does.

Self-service works only if the module's exposed surface makes the dangerous choices impossible rather than merely discouraged in a comment.

# A module that exposes just enough to be useful and nothing that
# lets a requesting team accidentally provision something unsafe.
module "team_database" {
  source        = "platform/modules/postgres-instance"
  team          = "checkout"
  instance_size = "medium"       # constrained to an enum: small | medium | large
  # No parameter for public network access. No parameter for disabling
  # backups. Those are fixed inside the module, not left to the caller.
}

A requesting team gets exactly the levers the platform team decided were safe to expose — instance size, in this example — and nothing else, because every parameter left out of the module's interface is a decision the platform team made once rather than a discipline every future caller has to remember to apply correctly. This is the actual difference between self-service and simply removing a review step: the guardrail moved into the module's shape, so a team can't provision an insecure database even if nobody reviews the request.

Because a review step scales with the number of requests and eventually becomes either a bottleneck that erases the speed self-service was supposed to buy, or a rubber stamp that catches nothing once the reviewer is overwhelmed. A guardrail encoded in the module's interface — a constrained enum instead of a free-text field, a mandatory tag, a hard-coded backup setting — applies to every request automatically and doesn't degrade as request volume grows, whereas a human reviewer's attention very much does.

The gap between what your infrastructure-as-code definitions say should exist and what actually exists in the running environment, caused by a manual change made outside the code — someone clicking a console button during an incident and never encoding the fix back into the definition. It's detected by periodically running the infrastructure tool in a plan-only mode against live infrastructure and treating any unexpected diff as a finding to investigate, rather than assuming the code and reality agree just because nobody reported otherwise. Drift left unaddressed means the code stops being a trustworthy description of what actually exists, which defeats most of the point of having it.

A shared cluster amortises operational cost across every team using it and is cheaper to run, at the cost of a noisy-neighbour problem where one team's workload can degrade another's, and a security boundary that depends entirely on correctly configured namespace isolation rather than physical separation. Dedicated clusters per team remove both risks at the cost of duplicating the operational overhead — upgrades, monitoring, security patching — once per team, which stops scaling once the number of teams grows past what a small platform team can operate individually. Most organisations land somewhere in between: a shared cluster for most workloads, with dedicated infrastructure carved out for the handful of teams whose compliance or performance requirements genuinely justify the extra cost.

A team submits a request through the portal specifying a small set of constrained parameters — size, region, team identifier — which triggers an automated pipeline that runs the underlying infrastructure module, tags the resulting resource with its owning team for cost attribution and the catalog, registers it in the service catalog with a resolvable owner, and notifies the requesting team when it's ready, typically within minutes rather than the days a manual ticket-based process would take. The platform team's actual work happened earlier, encoded into the module and the pipeline, so the request itself needs no human in the loop unless it falls outside the parameters the module was designed to handle safely.

The platform's own reliability as experienced by the teams depending on it: whether self-service requests succeed and how quickly, whether the CI fleet has capacity when a burst arrives, whether the catalog's data is current. This is a different signal from any individual tenant service's health, because the platform can be entirely healthy by its own metrics while one tenant's workload is misbehaving on top of it, and conversely a platform-level incident — a provisioning pipeline broken for everyone — looks nothing like any single tenant's dashboard.

The classic four — latency, traffic, errors, saturation — still apply, but what they measure shifts from a user-facing request to a platform-facing one.

Signal       Application meaning          Platform meaning
-----------  ----------------------------  --------------------------------------
Latency      Response time to a user      Time from provisioning request to ready
Traffic      Requests per second          Deploys per day, catalog reads per day
Errors       Failed requests               Failed self-service requests, pipeline
                                            failures unrelated to the tenant's code
Saturation   CPU, memory, connections      CI runner queue depth, shared cluster
                                            capacity headroom

The row worth dwelling on is errors, because a platform-caused failure and a tenant-caused failure look identical from the tenant's side — their deploy failed — but demand entirely different responses. A platform team that can't separate "our pipeline broke" from "your code broke" from its own metrics will spend its incident response time investigating the wrong half of every failure.

A service-level objective the platform team sets and holds itself to, where the customer is internal engineering teams rather than an external end user — for example, ninety-five percent of self-service provisioning requests complete within ten minutes. It matters because it converts a vague expectation of platform reliability into a number the platform team can be held accountable to and can use to justify investment, the same way a customer-facing SLO justifies investment in a product team's reliability work.

Because it directly measures the onboarding experience a new engineer or a new team has, and a long time to first deploy compounds: every day spent fighting the platform before shipping anything is a day of lost productivity that a dashboard showing high uptime never reveals. It's also one of the few platform metrics a new hire can report honestly and immediately, since they have no institutional history biasing their account of how painful the process was, unlike an established team that's simply adapted to friction they've stopped noticing.

Alerts scoped per tenant multiply with the number of tenants, so a platform supporting two hundred services can generate two hundred times the alert volume of any single service, and most of those alerts are actually about a tenant's own workload rather than the platform's health. Without a way to distinguish a platform-caused alert from a tenant-caused one at the point the alert fires, the on-call platform engineer either gets paged for problems that aren't theirs to fix, or starts ignoring a category of alert that occasionally does contain a real platform incident buried in the noise.

Nothing about the affected team's own deployment changed, which is exactly why this is hard to diagnose from inside their dashboards alone.

flowchart TD
    A[Team B deploys a batch job<br/>with no resource limits set] --> B[Consumes most of the<br/>shared cluster's CPU]
    B --> C[Team A's unrelated service<br/>gets throttled by the scheduler]
    C --> D[Team A sees latency rise<br/>with no change on their side]

The diagnostic trap is that Team A's own metrics, logs and recent deploys show nothing wrong, because nothing about their service changed — the cause is entirely on another tenant's side of a shared resource. Detecting this requires the platform team to correlate a tenant's degradation against fleet-wide resource contention, not just against that tenant's own change history, which is why per-tenant resource limits and platform-level saturation metrics both matter: the limits prevent the problem, and the fleet-wide metric is what lets you diagnose it quickly when a limit was missing.

A platform incident affects the shared layer itself — the CI fleet is down, the catalog is unreachable, provisioning is failing for everyone — and its resolution is entirely the platform team's responsibility. A tenant's incident is a problem with one team's own service running on healthy platform infrastructure, and the platform team's role there is at most advisory. Conflating the two in an incident-response process means the platform team either gets paged for every tenant's problem or, worse, a genuine platform-wide incident gets triaged as if it were one tenant's isolated issue and the response is scoped far too narrowly.

Encoding a security or compliance rule as an automated, machine-evaluated check — a Kubernetes admission policy, a pipeline gate — rather than relying on a human reviewer to remember and apply the rule consistently across every request. It replaces a review checklist that degrades under volume and staff turnover with a check that applies identically to the first request and the ten-thousandth. The trade is that a policy encoded in code needs its own maintenance and exception-handling process, because a rule that was right last year can become wrong as requirements change, and a check nobody revisits ossifies the same way a checklist nobody updates does.

The check happens at the moment a resource is submitted to the cluster, not after it's already running and causing damage.

# A policy rejecting any pod spec that requests privileged access,
# evaluated by the cluster itself before the pod is ever scheduled.
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPPrivilegedContainer
metadata:
  name: no-privileged-containers
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
  enforcementAction: deny   # reject at admission, not just report

enforcementAction: deny is the entire difference between a guardrail and a dashboard. Setting it to a reporting mode instead lets a violation through and merely logs it, which is useful while rolling out a new policy to see what it would have blocked without breaking anything yet, but it is not enforcement, and a platform team that leaves a policy in report mode indefinitely has built a compliance report generator rather than a guardrail.

A hard gate blocks the pipeline from proceeding when its check fails; a soft gate records a finding and lets the pipeline continue, usually surfacing the finding for later human review. The choice depends on the cost of a false positive versus the cost of a missed true positive: a critical vulnerability in a direct dependency is usually worth blocking on even with an occasional false alarm, while a license flag that needs a legal judgement call is usually better as a soft gate that doesn't stop every team's release while legal catches up on a backlog.

Because a vault only helps for secrets that are actually stored in it, and the path of least resistance for an engineer under deadline pressure is often to paste a credential directly into a configuration file or an environment variable rather than wire up the vault integration correctly on the first attempt. Sprawl is a product of friction, not ignorance: reducing it usually means making the vault path measurably easier than the shortcut, plus scanning repositories and pipeline logs for accidentally committed secrets as a backstop, because relying on discipline alone has a well-documented failure rate.

Producing a machine-readable list of every dependency, direct and transitive, that went into a built artifact, so that when a vulnerability is disclosed in some library, the organisation can answer "which of our services actually contain this" in minutes rather than by manually auditing every codebase. Without one, a newly disclosed critical vulnerability triggers an organisation-wide scramble to figure out exposure, often taking days precisely when speed matters most, because nobody has a reliable, queryable record of what's actually running where.

A signature answers a specific question that testing and scanning cannot: is the thing about to be deployed actually the thing that was built and scanned, or something that was substituted afterwards.

Without signing:
  Build -> Scan -> Artifact stored -> [gap: anything could replace it here] -> Deploy

With signing:
  Build -> Scan -> Sign with build pipeline's key -> Deploy verifies signature
                                                       before running anything

If the artifact was tampered with after signing, or substituted with an
unsigned or differently-signed one, verification fails and the deploy is
rejected before it starts.

The gap the diagram marks is real: without signing, a compromised artifact registry, a supply-chain attack on a build dependency, or simple human error swapping a file can put something into production that was never actually scanned, and nothing in the pipeline as normally described would catch it. Verifying a signature at deploy time closes that specific gap, which is why it's increasingly treated as mandatory rather than a nice-to-have, particularly for anything handling payment or personal data.

The platform team usually owns the mechanism — revoking access, rotating a compromised credential, rolling back a deployment, isolating a compromised workload — because they built and operate the tooling that mechanism runs through. The security team usually owns the investigation and the decision of what response is warranted. Conflating the two roles during an actual incident, with the platform team trying to investigate or the security team trying to operate infrastructure they don't run day to day, is slower than a clear handoff where each does the part they're actually equipped for.

Making cloud cost visible and attributable enough that the engineers actually causing a cost can see it and make a trade-off, rather than cost being a lump sum a finance team discovers at the end of the month with no way to trace it back to a decision. In practice for a platform team it means tagging every resource with an owning team, building a dashboard that breaks total spend down by that tag, and surfacing that breakdown to the teams themselves rather than keeping it as a platform-team-only report.

The policy looks conservative and responsible on paper. The bill tells a different story.

Policy: keep 3x expected peak capacity warm at all times, "to be safe"

Typical daily peak usage             : 40 instances
Warm capacity kept running always     : 120 instances
Actual utilisation of warm capacity   : ~33%, all day, every day

Monthly cost of the unused two-thirds is paid regardless of whether
a spike requiring it ever actually occurs that month.

The instinct behind the policy is reasonable — nobody wants a spike to queue — but "just in case" sized against a guess rather than a measured burst distribution routinely overshoots by several multiples, and the overshoot is invisible on any dashboard that only reports whether requests are being served, because they always are. The fix is sizing warm capacity against the actual measured concurrency distribution rather than an intuition about safety margin, and treating the resulting idle-cost number as something to justify explicitly rather than accept by default.

A mechanism that allocates shared platform and infrastructure cost back to the teams consuming it, so a team's budget reflects what its usage actually costs rather than the platform's total cost being absorbed centrally with no feedback to anyone. Platform teams resist building one because it's genuinely hard to attribute shared cost fairly — a shared cluster's cost doesn't split cleanly by team without granular usage tracking — and because a chargeback model creates political friction the moment a team's bill goes up, even when the increase reflects real usage growth rather than any platform team failure.

Because a workload's actual resource needs change as its traffic pattern, code and dependencies evolve, so a size that was correct when set drifts out of date the same way a service catalog's ownership field does, quietly and without an error. A resource request set once at launch and never revisited is either wastefully oversized, paying for headroom nobody uses, or dangerously undersized for traffic the service has since grown into, and only a recurring review against actual usage data catches which direction it drifted.

Reserved capacity is committed to in advance at a discount in exchange for a usage commitment, and suits steady, predictable baseline load where the discount reliably beats on-demand pricing. Spot or preemptible capacity is offered at a steep discount in exchange for the provider being able to reclaim it with little notice, and suits workloads that can tolerate interruption — batch jobs, CI runners that can retry on a different instance, non-critical background processing. Running a customer-facing service's baseline capacity on spot instances trades a real cost saving for a real availability risk that shows up exactly when the provider needs the capacity back, usually during high demand for everyone.

A single average utilisation figure can look healthy while hiding a distribution that's actually a problem in two very different directions at once.

Fleet average utilisation: 55%, reported as "reasonably efficient"

Actual distribution:
  40% of the fleet running at  90-100% utilisation  -> undersized, throttling
  35% of the fleet running at  10-20%  utilisation  -> oversized, wasted spend
  25% of the fleet running near the average          -> actually fine

The average erases exactly the information that matters, because the fix for the undersized quarter and the fix for the oversized third are opposite actions, and a single number pointing at "55%, fine" recommends doing nothing to either. Acting on fleet cost or performance requires looking at the distribution, not the mean, for precisely the same reason a p50 latency number hides the p99 that's actually hurting your largest customers.

The accumulating cost of every team independently deciding when, or whether, to upgrade a shared base image, runtime version or library, which produces a fleet where some services run current dependencies and others are years behind, each with its own reason nobody has revisited. The structural fix is centralising the upgrade into the shared template or base image the platform team owns, so an upgrade happens once centrally and propagates through the mechanism described for compliance gates, rather than depending on forty individual teams each finding the time and motivation to upgrade on their own schedule.

Whether you think about other engineers as your users, not just about the technical correctness of a system. A backend round asks whether an API is well designed; a platform round asks the same question plus whether you considered how a hundred different teams with different needs will actually adopt what you built, whether you can measure that adoption honestly, and whether you'd notice and respond if they quietly stopped using it. The technical bar is often similar; the difference is the product-thinking layer laid on top of it.

Interviewers expect the trade-off named explicitly, not just a working design, because the design without the trade-off could be produced by someone who has never watched a golden path fail in practice.

A strong answer's shape:
1. What the template generates and why those specific defaults
2. What it costs the team whose service genuinely doesn't fit the template
3. A concrete, visible mechanism for deviating from it
4. How the platform team finds out a template is wrong for a whole
   category of service, rather than assuming universal compliance

A weak answer stops at step one and describes an elegant template with no acknowledgement that some team, at some point, will have a legitimate reason not to use it. The interviewer's follow-up almost always probes exactly that gap, so naming it before being asked is worth more than a more polished template design that never mentions it.

DevOps as originally coined describes a cultural practice — developers and operations collaborating rather than working in separate silos — and in practice the title is usually used for someone building and maintaining CI/CD pipelines and infrastructure automation for one or a few teams. A platform engineer builds the self-service layer that many teams use without needing platform-team involvement for each request, which is a product-oriented, one-to-many relationship rather than the more direct, one-to-few relationship most DevOps roles describe. Interviewers use the terms inconsistently across organisations, so the useful move is asking what the role actually does day to day rather than assuming the title tells you.

Because a technically excellent platform that nobody uses has delivered zero value, and an interviewer wants to know whether a candidate understands that distinction before they're in the role rather than after they've spent a year building something well-engineered and unused. Asking "how would you know if this failed" after a design forces the candidate to engage with the product side of the work rather than treating the architecture as the entire deliverable.

Describing the architecture in detail and stopping there, without saying whether anyone actually used it, what changed for the teams that did, or what they'd do differently now. An interviewer hearing only the architecture cannot tell whether the candidate shipped something valuable or something merely functional, and the two are not the same accomplishment even though they can look identical in a system diagram. The tell is usually the pronoun: a candidate who says "we built" throughout and never once says "teams started" or "adoption grew" is describing an artefact rather than an outcome, and an interviewer listening for that distinction will ask directly if it never comes up unprompted.

Directly, and with the specific signal that told you it wasn't working — low adoption, teams quietly working around it, a support ticket volume that never dropped — rather than reframing it as a success with minor caveats. Interviewers weight an honest account of a failure and what it taught you more heavily than a suspiciously frictionless success story, because every platform team has had at least one initiative that didn't land, and a candidate who can't name theirs is either inexperienced or not being straightforward about it.

Spend most of that time talking to the engineers who will use whatever you build, before writing any infrastructure code, and leave with a specific, validated problem rather than a generalised belief about what platform teams usually build. Shadow an on-call rotation if one exists, read the support channel's history for the same recurring complaint, and resist the pull toward an ambitious rewrite before you've earned the credibility of shipping one small thing that visibly helped someone. The thirty-day output that actually matters is a named problem and a named team who agrees it's their problem, not a design document.

This is the question that separates candidates most reliably, because it cannot be answered from documentation and it requires having actually operated a platform rather than only having designed one. A strong answer names a specific, honest cause — the feature didn't cover a task teams needed daily, an informal alternative stayed faster, the underlying data went stale and nobody trusted it after that — and describes what changed once that cause was identified and addressed, or admits candidly that it never got fixed and the initiative was eventually deprecated. A weak answer either claims adoption never dropped, which is rarely true of anything built at scale, or blames the teams for not adopting it properly, which answers a different, more defensive question than the one that was asked.