Platform engineer interview questions, with worked answers

How to use these questions

Answer with a platform you built or ran: who used it, what it gave them, what they complained about, and what you changed. Interviewers listen for whether you treat developers as customers, with numbers on adoption and time saved.

What a platform engineer is expected to know

• The product: the internal developer platform, golden paths, self-service, developer experience and adoption.
• The ground: KubernetesAsked in 63% of platform engineer ads (as of 5 Nov 2026).Run shared clusters for many teams: namespaces, quotas, network rules, operators and upgrades without outages. for many teams, infrastructure as code with TerraformAsked in 35% of platform engineer ads (as of 5 Nov 2026).Modules other teams reuse, state kept safe, versions pinned, and plans reviewed before they are applied. or another tool, on AWSAsked in 29% of platform engineer ads (as of 5 Nov 2026).Accounts, identity, networks and the managed services the platform offers to teams, and their cost. depends on the provider, AzureAsked in 31% of platform engineer ads (as of 5 Nov 2026).Subscriptions, identity and the managed services the platform wraps for teams in a Microsoft setting. depends on the provider or Google CloudAsked in 14% of platform engineer ads (as of 5 Nov 2026).Projects, identity and managed Kubernetes in Google Cloud, offered to teams through the platform. depends on the provider.
• Delivery: shared CI/CDAsked in 64% of platform engineer ads (as of 5 Nov 2026).Shared pipeline templates that build, test, scan and deploy every service the same way. templates, GitOps, secrets and policy as code.
• Running it: observability with PrometheusAsked in 14% of platform engineer ads (as of 5 Nov 2026).Metrics for the platform itself and the defaults every service gets, with Grafana dashboards on top. or similar, upgrades, on-call, cost and security.

The platform as a product

What is an internal developer platform, and why run it as a product?

What they check: that you build for users, not a collection of tools.

Short answer: "An internal developer platform is the set of shared tools and services that lets product teams create, ship and run software on their own: clusters, pipelines, templates, secrets, monitoring. Platform as a product means we treat the developers as customers: we find out what slows them down, publish a roadmap, write documentation and measure whether they choose to use it."

The full answer: A platform built without its users ends up as a mandatory hurdle that teams work around. Talk to teams, watch a new service being set up, and start with the step that hurts most. The aim is less cognitive load for developers: fewer things each team must know to ship safely. A developer portal such as Backstage, Port or Humanitec can be the front door; a wiki and good templates are often enough to start.

A weak answer: "We install Kubernetes and tell teams to use it." Follow-up: "How do you know the platform is working?" Name the measures you would track.

How would you design a golden path for a new service, with templates teams can trust?

What they check: a supported default that is quick, safe and still leaves room.

Short answer: "A golden path is the supported way to build a common kind of service, such as a web API: a template creates the repository with the pipeline, tests, container build, monitoring, secrets and deployment already set up. A team can leave the path, but then owns what it builds. I keep the templates versioned, so updates reach services already created."

The full answer: Start with the two or three kinds of service most teams build, not every case. Templates rot unless someone owns them and changes reach old services, so plan how an update to the template flows into existing repositories. A service catalogue then shows which services follow which path and who owns them.

A weak answer: "One template for everything." Follow-up: "A team needs a batch job, not an API." Explain when you add a new path and when you say no.

How do you give teams self-service without losing control?

What they check: guard rails that work through policy, not through tickets.

Short answer: "Self-service means a team gets a database, a namespace or a pipeline by itself, in minutes, through a template, a merge request or a portal. Control comes from the defaults and from policy checked automatically: approved settings, quotas, encryption on, no public access. Exceptions are possible but asked for and recorded."

The full answer: A ticket queue is the opposite of self-service and the platform team becomes the bottleneck. Let the platform enforce the few rules that matter and advise on the rest. Show teams what they own and what it costs, so freedom comes with responsibility.

A weak answer: "Teams open a ticket and we create it for them." Follow-up: "Security wants to review every new database." Explain how the policy can do the review.

How do you measure developer experience and the adoption of the platform?

What they check: that you measure outcomes for users, not activity of the platform team.

Short answer: "I measure how long a new service takes to reach production, how often teams deploy and how often changes fail, how many teams and services use the golden paths, and what developers say in short regular surveys. Falling adoption or rising workarounds tell me the platform is missing something."

The full answer: Combine numbers from the tools with talking to people; each misses what the other sees. Be careful with metrics about individual developers, which damage trust and in some countries need agreement from staff representatives. Share the results and what you will change.

A weak answer: "We count tickets closed." Follow-up: "Adoption stalled at half the teams." Explain how you would find out why.

Kubernetes, infrastructure as code and GitOps

How do you run multi-tenant Kubernetes for many teams on shared clusters?

What they check: isolation, fairness and safety between teams on shared clusters.

Short answer: "Multi-tenancy means several teams share a cluster safely. Each team gets namespaces with quotas, network rules that block traffic it does not need, roles limited to its own space, and policies that refuse risky settings. Very sensitive or noisy workloads get clusters of their own."

The full answer: Decide early between few large shared clusters and many small ones: shared clusters are cheaper and harder to isolate, many clusters are simpler for each team and costlier to run. Charge or at least show cost per team. Admission policies, with tools such as OPA Gatekeeper or Kyverno, enforce the rules at the door.

A weak answer: "Everyone gets cluster admin, they are all colleagues." Follow-up: "One team's job uses all memory on a node." Explain quotas and limits.

How do you plan Kubernetes and platform upgrades when many teams depend on you?

What they check: upgrades as a routine with notice, testing and a way back.

Short answer: "I keep a calendar of upgrades, announce them early, test them on a non-production cluster with real workloads, and check for removed features the teams still use. Then I upgrade cluster by cluster, starting with the least critical, and keep capacity to move workloads off nodes safely."

The full answer: Falling behind is the larger risk: support ends and several versions must be jumped at once. Automate the checks for deprecated settings, and give teams a tool that shows what they must change. Helm charts and operators that the platform installs need the same upgrade discipline.

A weak answer: "We upgrade when something breaks." Follow-up: "A team cannot update in time." Explain how you balance their deadline with the support window.

How do you manage infrastructure as code at platform scale, across modules, state and tools?

What they check: reusable modules, safe state and a fair view of the tools.

Short answer: "I write small, versioned TerraformAsked in 35% of platform engineer ads (as of 5 Nov 2026).Modules other teams reuse, state kept safe, versions pinned, and plans reviewed before they are applied. modules with clear inputs, keep state remote, encrypted and locked, and split it so one change cannot touch everything. Every change is planned in a pipeline and reviewed before apply. Teams consume modules by version and upgrade when they are ready."

The full answer: The tools sit side by side: Terraform and its open fork OpenTofu, Pulumi in general programming languages, and Crossplane, which manages cloud resources from inside Kubernetes. Choose by the team's skills and what already exists, and avoid running three without a reason. Detect drift on a schedule and decide what happens when someone changes things by hand.

A weak answer: "One big state file for the whole company." Follow-up: "A module change would recreate forty databases." Explain how you would roll it out safely.

What is GitOps, and when would you use it?

What they check: that you understand the pull model and its trade-offs.

Short answer: "GitOps means the desired state of the clusters lives in a Git repository, and an agent in each cluster, such as Argo CD or Flux, keeps the cluster in step with it. A change is a merge request; rollback is a revert. It suits Kubernetes platforms with many services and clusters, because every change is reviewed and recorded."

The full answer: Secrets need care, because they should not sit in the repository in plain form. Promotion between environments needs a clear structure in the repository. Not everything fits: cloud resources outside the cluster are often still applied by pipelines.

A weak answer: "GitOps means we use Git." Follow-up: "Someone changed a setting in the cluster by hand." Explain what the agent does and how you see it.

Pipelines, secrets, policy and cost

How do you build CI/CD pipelines that every team can use and still change?

What they check: shared templates that are safe by default and easy to extend.

Short answer: "I offer pipeline templates for the common cases with build, tests, security scans, the container image and deployment built in, in GitLab CIAsked in 10% of platform engineer ads (as of 5 Nov 2026).One of the common pipeline tools; write templates many projects include. depends on the provider, GitHub ActionsAsked in 8% of platform engineer ads (as of 5 Nov 2026).One of the common pipeline tools; write reusable workflows many repositories call. depends on the provider or whatever the company runs. Teams include the template and add their own steps; the required checks cannot be removed."

The full answer: Version the templates and announce changes, because a broken template stops every team at once. Keep pipelines fast; developers notice every minute. Sign images and keep a list of what is inside them, which supply chain rules increasingly ask for.

A weak answer: "Each team writes its own pipeline from scratch." Follow-up: "The security scan doubles the pipeline time." Discuss how you would speed it up or move it.

How do you handle secrets across the platform?

What they check: no secrets in code, rotation, and identities instead of keys where possible.

Short answer: "Secrets live in a secret store, the cloud's own or a vault, and reach workloads at run time through their own identity. Where the cloud allows it, workloads use their identity directly and need no secret at all. Secrets are rotated on a schedule and the access to them is logged."

The full answer: Scan repositories and images for leaked secrets in the pipeline. Make the safe way the default in the templates, so a team does not have to decide. Plan rotation so it does not need a release of every service.

A weak answer: "Secrets are in the repository, but it is private." Follow-up: "A key leaked an hour ago." Revoke first, check use, then fix the path that let it out.

How do you enforce policy as code without blocking teams?

What they check: a few strong rules, automated, with a clear way to ask for an exception.

Short answer: "I write the few rules that must never be broken as policy that runs in the pipeline and at the cluster's door, such as no public storage, encryption on, images only from our registry. The rest are warnings with advice. A team that needs an exception asks for it, it is approved for a time and recorded."

The full answer: Start rules in warning mode, fix the existing violations with the teams, then switch to blocking. Write the reason next to each rule. Policies that block without explanation turn the platform team into the enemy.

A weak answer: "We block everything that is not approved." Follow-up: "A rule stops a release on a Friday evening." Explain the exception path.

How do you keep platform cost under control and show it to the teams?

What they check: cost as a design property with owners.

Short answer: "I tag or label every resource with its team and service, show each team its own cost every month, set requests and limits so clusters are not oversized, and scale non-production down at night. Shared costs are split by a simple rule everyone knows."

The full answer: The platform itself has a cost too: compare it with what teams would spend building the same alone. Commitments with the cloud provider lower the rate for steady load. Cost dashboards next to the service catalogue make the owner visible.

A weak answer: "Cost is finance's problem." Follow-up: "One team's cost tripled." Explain how you would find out what changed.

On-call, migration and the roadmap

How do you set up on-call for the platform, and split the responsibility with product teams and SREs?

What they check: clear ownership at night, written down before it is needed.

Short answer: "The platform team is on call for the platform itself: clusters, pipelines, shared services. Product teams are on call for their own services, helped by SREs where the company has them. The service catalogue says who owns what, and runbooks say when to hand an incident over."

The full answer: Without that line, every incident starts with a hunt for the owner. Track pages for the platform team; if most come from one team's mistakes, fix the guard rail. A shared incident process across platform, SRE and product teams avoids two processes in one outage.

A weak answer: "The platform team is on call for everything that runs on it." Follow-up: "A team's service fails because of a cluster change." Explain who leads and how.

Plan the migration of fifty services onto the new platform.

What they check: a plan by waves that earns trust, with help for the teams.

Short answer: "I start with two or three friendly teams with simple services, learn from them, and fix the platform before the next wave. Each wave has a date, a checklist and engineers from the platform team sitting with the product team. The old setup is switched off on a date agreed at the start."

The full answer: Make moving worth it for teams: faster pipelines, less on-call, things they no longer have to own. Leave the hardest services for last, when the platform is proven. Track progress openly, and accept that a few services may never move and need a plan of their own.

A weak answer: "We announce a deadline and teams move themselves." Follow-up: "Two teams refuse to move." Explain how you would find out why and what you would offer.

As a staff platform engineer or platform engineering manager, how would you build the platform roadmap?

What they check: priorities from evidence, and the courage to say no.

Short answer: "I collect what teams need from surveys, incidents, support requests and the company's plans, estimate the value and the effort, and publish a roadmap by quarter with a few clear bets. I say what we will not do as clearly as what we will. Progress is reported in the measures teams care about."

The full answer: At staff platform engineer level the work is the design of the platform's core and the standards across teams; as platform engineering manager and later head of platform it is the team, the budget, the roadmap and the relationship with engineering leadership. Expect a case where three departments each want the platform team's next quarter.

A weak answer: "We build whatever the loudest team asks for." Follow-up: "The CTO wants a new tool next month." Explain how you would weigh it against the roadmap.

Your CV for these questions

Each platform piece on your CV invites the questions above: who used it, what it replaced, what broke and what changed for developers. One line per platform piece, under the job where you built it, gives the interviewer the hook for each story:

A free score against a platform engineer job shows the gaps an interviewer will probe; prepare the stories behind those skills before anything else.