Platform Engineer — interview prep kit

The mindset that defines the role. Interviewers want to hear that a platform has users, that adoption is earned, and that the measure of success is other teams' productivity.

1. known

   What is a platform engineer, and how is the role different from DevOps or SRE?

   What it tests Whether you understand the distinct value of the role rather than treating the titles as interchangeable.

   Model answer

   A platform engineer builds the internal platform — the reusable, self-service capabilities that application teams use to build, ship and run their software — treating it as a product whose users are the other engineers. The distinction: DevOps is a culture and practice of collaboration between dev and ops, often meaning an engineer who does CI/CD and infrastructure for their own team; SRE is a discipline focused on the reliability of services, often embedded with or owning specific production systems; platform engineering builds the paved road that both of those travel — the templates, the internal developer platform, the golden paths — so that every team does not reinvent CI/CD, deployment, and observability. The framing that signals understanding: a platform engineer's output is other teams' productivity and consistency. Where a DevOps engineer might build a pipeline for one service, a platform engineer builds the system that lets any team get a pipeline in minutes. Success is measured by adoption and by how much friction you remove, not by the infrastructure you personally operate.

   Likely follow-ups:

   • How would you measure whether your platform is succeeding?
   • Can a platform team exist without SRE and DevOps practices?
2. known

   What is a golden path, and how do you keep it from becoming a golden cage?

   What it tests Whether you understand the central tension of platform design — helpful defaults versus imposed constraints.

   Model answer

   A golden path is the well-supported, opinionated, easy way to do a common thing — 'here is how you create a new service with CI, deployment, and monitoring already wired up' — so teams get the 80% case for free and consistently. The value is enormous: consistency, speed, and less for each team to learn. The risk is the golden cage: an abstraction so rigid that the moment a team needs something slightly different, they are stuck, and the platform becomes a blocker instead of an enabler. Avoiding it comes down to escape hatches — the golden path should be the easiest option, not the only one, so a team can drop to a lower level of abstraction when they genuinely need to, without abandoning the platform entirely. Design for the common case, but do not hide the underlying primitives so completely that customisation is impossible. The judgement interviewers want: opinionated defaults with an off-ramp; a platform that forces everyone into one shape drives your most capable teams to build their own thing, which is exactly the fragmentation the platform was meant to prevent.

   Likely follow-ups:

   • Give an example of an escape hatch you would build into a deployment golden path.
   • How do you decide what to make configurable versus fixed?
3. known

   A team refuses to adopt your platform and wants to run their own tooling. How do you handle it?

   What it tests Whether you understand that platform adoption is earned through value, not enforced by mandate.

   Model answer

   First, treat it as feedback, not defiance — a team going its own way usually means the platform does not meet a real need of theirs, and that is information. So I would understand *why*: is there a genuine gap (their use case is not covered), a friction problem (the platform is harder than doing it themselves), or a trust problem (they were burned by a platform change)? Each has a different response. The principle is that adoption is earned by making the paved road the easiest, best-supported path, not by policy — if you have to mandate it, the platform is not good enough, and mandates create resentment and shadow tooling. If the gap is real, that is roadmap input. If the friction is real, that is a DX bug to fix. Sometimes the right answer is to let them stay off the platform for now and win them later, or to meet them partway (adopt part of the platform). The maturity signal: a platform engineer sells the platform by being genuinely useful and reduces the effort of adoption, rather than wielding authority — because a platform nobody wants to use has failed regardless of how good the technology is.

   Likely follow-ups:

   • When is it acceptable to let a team stay off the platform?
   • How does mandating adoption backfire?
4. known

   How do you decide what belongs on the platform roadmap versus letting teams solve it themselves?

   What it tests Whether you can prioritise platform investment by leverage rather than building everything.

   Model answer

   The platform should build what has leverage — a capability that many teams need, where a single good implementation saves the whole company from N mediocre ones. So the question for any candidate feature is: how many teams need this, how much pain does each feel solving it themselves, and how much better is a shared solution than N independent ones? High-leverage things (CI/CD, deployment, observability, secrets, service scaffolding) are clear platform territory because everyone needs them and consistency has real value. Low-leverage or highly team-specific things — a capability only one team needs, or one where teams' needs genuinely diverge — are better left to the teams, because building them into the platform adds maintenance burden and often produces a worse fit than the team would build. The trap to avoid is the platform team becoming a bottleneck by trying to own everything, or building speculative features nobody asked for; the discipline is to source the roadmap from real, repeated demand (the same friction showing up across teams, the same support tickets) and to prioritise by teams-affected times pain-per-team. And sometimes the right platform move is not to build the thing but to make it easy for teams to build it — provide the primitives, not the whole solution.

   Likely follow-ups:

   • How do you avoid the platform team becoming a bottleneck?
   • When should the platform provide primitives rather than a finished solution?

Platform teams usually own how software gets deployed. GitOps and self-service deployment are core, and interviewers probe how the mechanism works and why it is safer.

1. known

   What is GitOps, and what does it give you over pushing deploys from a CI pipeline?

   What it tests Whether you understand the model, not just the buzzword — the pull-based reconciliation and its consequences.

   Model answer

   GitOps means the desired state of your system lives in Git, and an in-cluster agent continuously reconciles the real state to match it — Git is the single source of truth, and deploying is merging a change to that repository. The contrast with CI-push: in a push model, the pipeline has credentials to the cluster and imperatively applies changes from outside; in GitOps, the agent (Argo CD or Flux) runs *inside* the cluster, pulls the declared state, and applies it. The advantages that follow: the cluster's credentials never leave it (a push pipeline needs powerful cluster access, a security exposure); the repository is a complete, auditable record of what should be running and who changed it; drift is detected and can be auto-corrected because the agent constantly compares desired to actual, so a manual change in the cluster gets reverted; and rollback is git revert. The framing: GitOps turns 'what is running' into a reviewable, version-controlled artifact and makes the cluster self-healing toward that artifact — versus a push model where the truth is whatever the last pipeline happened to apply.

   Likely follow-ups:

   • Why is pull-based reconciliation more secure than a CI pipeline holding cluster credentials?
   • How does GitOps handle someone making a manual change directly in the cluster?
2. known

   How would you design a self-service deployment platform so a developer can ship a new service without a platform engineer?

   What it tests Whether you can design an abstraction that empowers developers while keeping guardrails.

   Model answer

   The goal is that a developer describes *what* they want at a high level and the platform handles *how*, safely. A common shape: the developer fills in a small manifest or uses a template/scaffolding tool ('new service' generates a repo with CI, a Helm chart, and the GitOps config already wired), specifying only the things that vary — the service name, resource sizes, dependencies, scaling. The platform provides the rest as opinionated defaults: the pipeline, the base image, the observability wiring, the ingress, the secrets integration. Deployment is GitOps — the developer changes a value (an image tag) via a pull request, and the platform's agent rolls it out with the standard safety (health checks, progressive rollout). Guardrails are enforced by the platform, not left to the developer: resource limits, network policies, image-signing requirements via admission control, so a self-service action cannot violate policy. The keys to name: a high-level interface (the developer should not write raw Kubernetes YAML), sensible defaults with escape hatches, and policy enforced centrally so self-service does not mean unsafe. Bonus: an internal developer portal (like Backstage) as the front door that ties scaffolding, docs, and the service catalog together.

   Likely follow-ups:

   • How do you stop self-service from letting someone deploy something unsafe?
   • What belongs in the developer's manifest versus the platform's defaults?
3. known

   How do you roll out a change to the platform itself — say a base-image upgrade — across many teams safely?

   What it tests Whether you appreciate that platform changes have huge blast radius and need special care.

   Model answer

   A platform change affects every team that depends on it, so the blast radius is the whole company — which means you roll it out like a risky production change, not a routine one. Never big-bang. The approach: stage it — test the change against a representative sample first, then roll it out progressively across teams or environments (a canary set of services, then a wider ring, then everyone), watching for breakage at each stage so a problem is caught while it affects a few teams, not all of them. Make it opt-in before mandatory where possible — announce the new base image, let teams adopt it and report problems, then set a deprecation timeline for the old one — so teams have agency and you get feedback before forcing it. Keep changes backward-compatible as long as you can, and give teams a way to pin or roll back if the change breaks them. And communicate relentlessly, with lead time, because a surprise platform change that breaks builds destroys the trust the platform runs on. The principle: the platform is a shared dependency, so its changes get more caution, more staging, and more communication than a single team's change — you are effectively deploying to everyone at once.

   Likely follow-ups:

   • Why is opt-in-then-deprecate usually better than a forced upgrade?
   • How does a broken platform change differ from a broken single-service change?
4. known

   How do you manage secrets on a platform so many teams can use them safely without seeing each other's?

   What it tests Whether you know secrets management at platform scale — isolation, injection, and not committing secrets to Git in a GitOps world.

   Model answer

   The platform's job is to give every team a safe, self-service way to use secrets without teams reinventing it or leaking them, and with strict tenant isolation. The core: a secret store (a cloud secret manager or Vault) holds the secrets, scoped by tenant so a team's RBAC only lets it read its own; secrets are injected at runtime into workloads (as env vars or mounted files, or synced into the namespace by an operator), never baked into images or committed to repos. In a GitOps setup this needs care, because the desired state is in Git and you must not put plaintext secrets there — the answers are either a sealed/encrypted secret committed to Git that only the in-cluster controller can decrypt (Sealed Secrets, SOPS), or an external-secrets operator that keeps only a *reference* in Git and pulls the actual value from the secret store at reconcile time (usually the cleaner choice — Git holds pointers, not secrets). Isolation is enforced by namespace RBAC and by scoping each team's access in the store. Add rotation, audit logging (who read what), and short-lived credentials via OIDC where possible so there are fewer long-lived secrets to manage at all. The principle: teams get self-service access to their secrets, the platform guarantees isolation and that nothing plaintext lands in Git or an image.

   Likely follow-ups:

   • How do you keep plaintext secrets out of a GitOps repository?
   • What is the difference between sealed secrets and an external-secrets operator?

Platforms often run shared clusters that many teams use. The hard problems are isolation, fairness, and stopping one tenant from hurting another.

1. known

   How do you isolate tenants in a shared Kubernetes cluster?

   What it tests Whether you know the isolation primitives and their limits — a core platform responsibility.

   Model answer

   Multi-tenancy on a shared cluster stacks several mechanisms because no single one is enough. Namespaces are the basic boundary — each tenant gets a namespace, giving name isolation and a scope for policy. On top of that: RBAC so a tenant can only act within their namespace; ResourceQuotas and LimitRanges so a tenant cannot consume the whole cluster's CPU/memory or create unlimited objects; NetworkPolicies so pods in one namespace cannot reach another's unless allowed (by default Kubernetes networking is flat and open — this must be added); PodSecurity standards / admission policies so a tenant cannot run privileged containers that escape to the node. The honest limit to state: this is soft multi-tenancy — namespaces share a kernel and control plane, so a determined or hostile tenant is not fully contained (a kernel exploit or a node-level attack crosses the boundary). For genuinely untrusted tenants you need hard multi-tenancy — separate clusters, or node isolation, or sandboxed runtimes — because namespace isolation was designed for cooperating teams, not adversaries. Knowing that distinction is the platform-engineer signal.

   Likely follow-ups:

   • What is the difference between soft and hard multi-tenancy?
   • Why must NetworkPolicies be added explicitly — what is the default?
2. known

   One team's workload is starving others of resources on a shared cluster. How do you prevent and fix this?

   What it tests Whether you understand resource governance and the noisy-neighbour problem practically.

   Model answer

   This is the noisy-neighbour problem, and it is a governance failure — the platform let one tenant take more than its share. Prevention is the real answer: ResourceQuotas per namespace cap how much CPU and memory each tenant can request in total, so no tenant can claim the whole cluster; LimitRanges set default and maximum per-pod requests/limits so a single pod cannot be unbounded; and requests set correctly so the scheduler packs nodes fairly and does not overcommit into contention. For the CPU-starvation case specifically, understand that CPU is compressible (throttled, shared by weight) while memory is not (a pod over its limit is killed) — so CPU contention degrades everyone, and the fix is quotas plus, if needed, dedicated node pools for greedy or latency-sensitive tenants (taints and tolerations to keep them apart). To fix an active incident: find the offending workload, and if it has no limits, that is the bug — apply them; longer term, enforce that no workload can be admitted without requests and limits (an admission policy). The principle: fairness on a shared cluster is enforced by quotas and limits set by the platform, not left to each team's good behaviour, because one team without limits can hurt everyone.

   Likely follow-ups:

   • Why does CPU contention degrade everyone while a memory overcommit kills one pod?
   • When would you give a noisy tenant its own node pool?
3. known

   When would you give teams separate clusters instead of sharing one?

   What it tests Whether you can reason about the trade-off between consolidation and isolation, a recurring platform decision.

   Model answer

   It is a trade-off between efficiency and isolation. Shared clusters are cheaper (better bin-packing, less control-plane overhead, one thing to operate and upgrade) and give teams a consistent environment, which is why they are the default for cooperating internal teams. Separate clusters give stronger isolation — a blast-radius boundary (one cluster's failure or bad upgrade does not touch another), hard security separation (no shared kernel between untrusted parties), independent upgrade cadence, and clean compliance boundaries. You reach for separate clusters when: tenants are untrusted or have strict compliance/regulatory separation requirements (namespace isolation is not enough for adversaries); the blast radius of a shared control plane is unacceptable (you do not want a cluster-wide problem to hit everyone); teams need different Kubernetes versions or configurations; or scale outgrows what one cluster's control plane handles well. The nuance interviewers want: it is not all-or-nothing — many orgs run a cluster per environment or per business unit, sharing within a trust boundary and separating across it. The cost of many clusters is operational (you now manage a fleet), which is itself a platform problem — fleet management, consistent config across clusters — so 'separate everything' is not free.

   Likely follow-ups:

   • What new operational burden do you take on by running many clusters?
   • How does the trust level between tenants drive this decision?
4. known

   How would you enforce organization-wide policy — like 'no privileged containers' or 'all images must be signed' — across a shared cluster?

   What it tests Whether you know admission control and policy-as-code, the platform mechanism for guardrails.

   Model answer

   You enforce it at admission — the point where a request to create or change a resource enters the cluster — so a violating workload is rejected before it ever runs, rather than detected after. The mechanism is an admission controller driven by policy as code: a policy engine like Kyverno or OPA/Gatekeeper runs as a validating (and sometimes mutating) admission webhook, checks each incoming resource against declared policies, and denies the ones that violate them — 'no privileged containers', 'every image must carry a signature from our build workflow', 'every pod must have resource limits', 'no latest tags'. Two modes to mention: validating (reject the bad resource) and mutating (fix it automatically — e.g. inject a default, or rewrite an image tag to its verified digest). The advantages of doing it this way: it is centralised (one place, not trusting every team to comply), declarative and version-controlled (the policies are code, reviewed and rolled out like anything else), and it fails safe (violations cannot be admitted). Roll policies out in audit mode first (report violations without blocking) so you find what would break before you enforce, then flip to enforce — because a policy that instantly blocks half the existing workloads is how you cause an outage while trying to improve security. The principle: guardrails belong in the platform as enforced policy, not in documentation teams are trusted to follow.

   Likely follow-ups:

   • Why roll a new policy out in audit mode before enforcing it?
   • What is the difference between a validating and a mutating admission policy?

The product side of the role. Interviewers want evidence that you optimise for the developer's experience and know how much abstraction is the right amount.

1. known

   How would you measure and improve developer experience for the platform's users?

   What it tests Whether you treat DX as a measurable product concern, not a vague nicety.

   Model answer

   You measure it because 'developer experience' is otherwise just a feeling, and you cannot improve what you do not measure. Quantitative signals: time to first deploy for a new service (how long from 'I want a service' to 'it is running' — a headline number), lead time for a change, adoption rate of golden paths, support ticket volume and what they are about (recurring tickets are DX bugs), and the DORA metrics as outcomes. Qualitative signals matter as much: developer surveys (something like a periodic DevEx survey), and just talking to users — sitting with a team as they onboard reveals friction no dashboard shows. Then improve the biggest friction points: if onboarding a service takes two days of manual steps, that is where scaffolding pays off; if teams keep filing the same ticket, automate or document that away. The framing that signals product-thinking: the platform's job is to remove friction, so you find the friction (measure and observe), fix the worst of it, and track whether the numbers moved — treating the developers as customers whose satisfaction and speed are your KPIs.

   Likely follow-ups:

   • What is a single metric you would watch as a proxy for platform health?
   • How do recurring support tickets inform the roadmap?
2. known

   How much abstraction is the right amount? When does an abstraction hurt more than it helps?

   What it tests Whether you have judgement about the cost of abstraction, not just enthusiasm for it.

   Model answer

   The right amount hides the accidental complexity (the boilerplate every team would otherwise repeat) while leaving the essential complexity visible and controllable. An abstraction helps when it lets people do the common thing without understanding the machinery underneath and without a real loss of control. It hurts when: it is leaky in the wrong way — things break in terms of the layer below, so users must understand both the abstraction and what it hides (worst of both worlds); it is too rigid — the golden-cage problem, blocking anything off the happy path; or it hides something they need to reason about — for example, an abstraction that hides cost or performance leads teams to make expensive or slow choices unknowingly. The principle to state: abstraction is not free — every layer is something to learn, debug, and maintain, and a wrong abstraction is worse than none because it adds cognitive load without removing enough. So abstract the genuinely repetitive and safe-to-hide parts, keep escape hatches, and be willing to *not* abstract something if the abstraction would be more confusing than the thing itself. The senior instinct: prefer a thin, understandable abstraction over a magic one, because platform users eventually have to debug through it.

   Likely follow-ups:

   • Give an example of an abstraction that hides too much.
   • Why can a wrong abstraction be worse than no abstraction?
3. known

   A platform capability you built is used by 30 teams and you need to make a breaking change. How do you handle it?

   What it tests Whether you understand API/contract versioning and migration for internal platforms — a mature, real problem.

   Model answer

   A breaking change to something 30 teams depend on is exactly like breaking a public API, so you treat it as one: never break silently, give a migration path and time, and version. The approach: introduce the new version alongside the old one rather than replacing it, so nothing breaks on day one and teams migrate at their own pace; announce the change with clear docs, a migration guide, and a deprecation timeline for the old version; make migration as easy as possible — provide a codemod, a script, or examples, and offer to pair with teams, because friction in migration is what makes deprecations drag on forever. Track adoption of the new version so you know who is still on the old one, and only remove the old version after everyone (or an agreed cutoff) has moved, with warnings escalating as the deadline approaches. Where you can, avoid the breaking change entirely by making it additive/backward-compatible — a new optional parameter rather than a changed signature. The principle interviewers want: internal platform contracts deserve the same discipline as external APIs — versioning, deprecation windows, and migration support — because 'I changed it and 30 teams' builds broke' is how a platform team loses all its credibility at once.

   Likely follow-ups:

   • How do you know when it is safe to finally remove the old version?
   • How would you have designed the original interface to avoid the breaking change?
4. known

   What is an internal developer portal (like Backstage), and what problem does it solve?

   What it tests Whether you know the developer-portal concept and the discoverability problem it addresses at scale.

   Model answer

   An internal developer portal is the single front door to the platform — a place where developers can discover, create, and manage their software and the platform's capabilities. Backstage (from Spotify, now a CNCF project) is the best-known. The problem it solves is discoverability and fragmentation at scale: in a large org with hundreds of services and dozens of tools, engineers cannot find what exists, who owns it, how to create a new service the right way, or where the docs are — knowledge lives in people's heads and scattered wikis. A portal centralises this into: a service catalog (every service, its owner, its dependencies, its health), software templates (the scaffolding golden path — 'create a new service' with everything wired up), TechDocs (documentation living next to the code), and plugins that surface CI status, deployments, and on-call in one place. The value is reduced cognitive load and a consistent entry point — a new engineer can find and understand the landscape, and creating a compliant new service is a few clicks instead of a tribal-knowledge quest. The framing that signals platform maturity: the portal is where the platform's golden paths become *discoverable and usable*, turning capabilities the platform team built into things developers can actually find and self-serve — without it, even a great platform is underused because nobody knows what it offers.

   Likely follow-ups:

   • What is in a service catalog, and why does ownership matter?
   • How does a portal relate to the golden paths and scaffolding you already build?

A platform is a dependency for everyone, so its reliability is multiplied. Interviewers probe how you keep the paved road itself from becoming a single point of failure.

1. known

   The platform you run is now a critical dependency for every team. How does that change how you operate it?

   What it tests Whether you appreciate that a platform's failure is a company-wide failure and operate accordingly.

   Model answer

   Once every team depends on the platform, the platform's reliability is multiplied — an outage of the deployment system or the CI or the shared cluster does not affect one service, it stops the whole company from shipping or, worse, takes production down. So it must be operated to a *higher* reliability bar than the services on top of it, with the SRE discipline: SLOs on the platform itself (the CI is available X%, deploys succeed Y%, the portal responds in Z), because your users — the other engineers — need to know they can rely on it; blast-radius limits so one tenant or one bad change cannot take the platform down for everyone; staged rollout of platform changes (covered earlier) because a platform change is a deploy to everyone; and genuine on-call and incident response for the platform, treating a platform outage as a real incident. Two things people miss: the platform must degrade gracefully (if a non-critical component fails, teams should still be able to deploy) and must not have a single point of failure whose loss blocks everyone — for example, if all deploys route through one service, that service is now the most critical thing in the company. The mindset shift interviewers want: you stop thinking like someone building tools and start thinking like someone running a tier-0 service, because that is what a widely-adopted platform is.

   Likely follow-ups:

   • What SLOs would you put on the platform itself?
   • How do you make sure the platform is not a single point of failure for all deploys?
2. known

   How do you keep the platform's own infrastructure (CI runners, the GitOps controller, the registry) reliable and not a bottleneck?

   What it tests Whether you think about the reliability and scaling of the platform's plumbing, not just the abstractions on top.

   Model answer

   These are the load-bearing pieces, so they get the same treatment as any production service — capacity, redundancy, and monitoring. CI runners: autoscale them so a burst of builds does not queue for an hour (a slow build queue is a platform outage in slow motion), monitor queue depth and wait time as SLIs, and isolate them so one team's giant build does not starve others. The GitOps controller (Argo CD/Flux): it is critical for deploys, so run it HA, monitor its reconciliation lag and health, and understand that if it is down, drift is not corrected and deploys stall — page on it. The registry: it is on the critical path of every deploy and node scale-up (nodes pull images from it), so it must be highly available and probably cached/mirrored, because a registry outage means no new pods can start anywhere — a subtle single point of failure people forget. The general method: identify every component on the critical path of 'a team ships a change' or 'a pod starts', give each an SLO and monitoring, remove single points of failure, and capacity-plan them ahead of growth. The maturity signal: recognising that the platform's plumbing is itself production infrastructure with its own failure modes — a down registry or a saturated CI is a company-wide incident, not an internal-tools hiccup.

   Likely follow-ups:

   • Why is the container registry a subtle single point of failure?
   • What would you monitor on CI runners as an SLI?
3. known

   How do you roll out and test upgrades to a shared Kubernetes cluster that everyone depends on?

   What it tests Whether you can upgrade critical shared infrastructure without breaking the teams on it.

   Model answer

   A Kubernetes upgrade on a shared cluster is high-stakes because a bad upgrade breaks everyone's workloads at once, and Kubernetes upgrades do carry breaking changes (removed API versions, deprecated behaviours). The method: never upgrade prod first — test the new version on a non-production cluster that mirrors prod, and run the workloads' tests against it. Check for deprecated/removed APIs before upgrading (tools scan manifests for APIs the new version drops) and get teams to migrate their manifests first, because an upgrade that removes an API version silently breaks anything still using it. Upgrade one minor version at a time (Kubernetes only supports skew of one), the control plane before the nodes, and roll nodes gradually (cordon, drain, replace) so workloads reschedule with capacity headroom and you can stop if something breaks — a rolling node upgrade, not all at once. Have a rollback plan (control-plane upgrades are hard to reverse, so this is really about catching problems in the non-prod test first) and communicate the maintenance window and any required team action with lead time. For the fleet case, roll the upgrade across clusters progressively (canary cluster, then wider) so a problem in the upgrade process hits one cluster, not all. The principle: shared-cluster upgrades combine 'staged rollout of a platform change' with the specific Kubernetes hazards (API removal, version skew, node draining) — caution, a prod-like test, and gradual rollout are what keep everyone's workloads alive.

   Likely follow-ups:

   • How do you find workloads using an API version the new Kubernetes drops?
   • Why upgrade the control plane before the nodes, and one version at a time?
4. known

   How would you provide observability as a platform capability so every team gets it without building their own?

   What it tests Whether you can design a shared observability platform with the multi-tenancy and cost concerns it raises.

   Model answer

   The goal is that a team gets metrics, logs, traces and dashboards by default — wired in when they use the golden path — rather than each team standing up and operating its own stack. The design: run centralised observability infrastructure (a metrics store like Prometheus/Mimir, logs like Loki, traces like Tempo/Jaeger, Grafana for dashboards) that the platform operates, and make services emit to it automatically — the service template includes the instrumentation, the scrape config or agent, and standard dashboards, so a new service shows up in observability with zero effort from the team. Key concerns a platform engineer must raise: multi-tenancy (teams should see their own data by default and not accidentally each other's, and one team's cardinality explosion must not take down the shared store — per-tenant limits, because a single label with unbounded values can OOM a metrics backend and hurt everyone); cost (observability data is expensive at scale — retention policies, sampling for traces, and cardinality limits are how you keep it affordable, and teams should see what their telemetry costs); and self-service (teams can add their own dashboards and alerts on top of the defaults). The value interviewers want: consistency (every service observable the same way, so cross-service debugging works), no reinvention, and the platform absorbing the operational burden of running the observability stack — while guarding against the shared-store failure modes (cardinality, cost) that a naive 'just give everyone Prometheus' would hit.

   Likely follow-ups:

   • How can one team's metrics take down the shared observability store, and how do you prevent it?
   • How do you keep observability costs under control across many teams?