Platform engineer system design interview questions

As asked

Your company has 80 engineering teams and every team deploys services differently. How would you design a self-service platform that standardises the paved road?

Sample answer outline

Start with the most common service path: repository template, CI pipeline, container build, deployment, secrets, observability, and rollback. The platform should expose simple self-service APIs or portals while hiding Kubernetes, cloud IAM, and network details where possible. Strong answers balance golden paths with escape hatches, because forcing every workload into one shape creates shadow platforms. Adoption depends on migration support, clear docs, sensible defaults, and measuring developer lead time, failure rate, and support burden. The common mistake is building a portal before standardising the underlying runtime contracts.

Expect these follow-ups

• What should be configurable and what should be fixed?
• How do you migrate the first 20 teams?
• What metric proves the platform is helping rather than adding process?

As asked

Your company has 40 data teams writing Airflow or Dagster jobs in different styles. How would you build a shared orchestration platform without becoming a ticket queue?

Sample answer outline

The platform should provide paved roads: project templates, deployment automation, secrets access, standard retries, alerting, and lineage out of the box. Teams should own their DAG code while the platform owns runtime reliability, conventions, and guardrails. Multi-tenancy needs isolation for dependencies, quotas, credentials, and noisy workloads. Adoption is won by making the easiest path the best path, not by banning all custom jobs on day one. Candidates often miss the product-management side of platform work: documentation, migration support, and measuring whether teams are actually faster.

Expect these follow-ups

• What should be centralised and what should remain team-owned?
• How do you prevent one team's job from starving everyone else?
• What platform metrics would you report after six months?

As asked

You are the first platform engineer at a company with 100 developers on AWS, all deploying via bash scripts and hand-edited YAML. Design the internal developer platform you would build over the next 12 months. What is the first thing you ship, how do you get adoption, and what does the end state look like?

Sample answer outline

Strong candidates start with the pain: identify the top 3 developer complaints (slow deployments, inconsistent environments, no self-service) and solve those first. The first deliverable is typically a golden-path CI/CD template that reduces time-to-deploy by 80%. Month 3 adds self-service namespace provisioning. Month 6 adds a service catalog and Backstage. Adoption strategy: embed in one high-profile team early, collect metrics (DORA), show wins, then expand. End state has a paved road with escape hatches, not a locked-down platform.

Expect these follow-ups

• How do you balance standardization with flexibility? What is the 'paved road vs guardrails' philosophy?
• How do you measure platform engineering success? Which specific metrics do you track?

As asked

Design a Kubernetes multi-tenancy model for 50 teams sharing one cluster, each team having dev, staging, and prod namespaces. Cover namespace isolation, network policies, RBAC, resource quotas, pod security standards, and audit logging. Where do you draw the line between shared cluster and separate clusters?

Sample answer outline

Each team gets three namespaces with a naming convention (team-dev, team-staging, team-prod). Network policies default-deny with allow rules between same-team namespaces. RBAC uses team-specific ClusterRoles bound at namespace scope. ResourceQuota prevents noisy neighbors. PodSecurityStandards set to Restricted for prod namespaces, Baseline elsewhere. Audit logs are shipped to a SIEM. Separate clusters are warranted when teams have different compliance requirements, need cluster-level admin access, or have such different resource profiles that fair sharing breaks down.

Expect these follow-ups

• What is the Hierarchical Namespace Controller and how does it simplify the multi-namespace model?
• How do you handle a team that needs a custom admission webhook that would affect all pods on the cluster?

As asked

Design isolation for an internal developer platform where hundreds of services share Kubernetes clusters and cloud accounts.

Sample answer outline

Use multiple layers of isolation: namespaces, RBAC, network policies, resource quotas, admission controls, workload identity, and separate accounts or clusters for higher-risk environments. A strong answer explains the difference between soft tenancy for ordinary services and hard isolation for regulated, privileged, or noisy workloads. They should discuss blast radius, auditability, cost allocation, and how platform defaults are enforced through policy-as-code. The design should include safe escape hatches because some workloads will not fit the default. A common miss is relying only on Kubernetes namespaces and ignoring cloud IAM or network egress.

Expect these follow-ups

• Which workloads deserve their own cluster?
• How do you prevent one team from exhausting shared cluster capacity?
• What policy would you enforce at admission time?

As asked

A product has years of hard-coded colours, spacing, and typography. How would you migrate it to design tokens without freezing feature work?

Sample answer outline

Define token layers clearly: primitive values, semantic tokens, and component-level decisions. Start with high-impact surfaces and introduce tokens alongside linting, codemods, visual regression tests, and documentation. Avoid a single big-bang rewrite; migrate by component or route and keep compatibility aliases during the transition. Partner with design so tokens reflect decisions, not just renamed hex values. The senior answer treats this as a change-management problem with adoption metrics and escape hatches, not merely a CSS refactor.

Expect these follow-ups

• How do you handle a brand refresh during the migration?
• What is the difference between a primitive and semantic token?
• How would you measure adoption and remaining debt?

As asked

Design a system where developers can request a managed PostgreSQL database through a Kubernetes custom resource and receive connection credentials automatically. The system must handle provisioning, credential rotation, backup configuration, and decommissioning safely. What are the components and failure modes?

Sample answer outline

A DatabaseClaim CRD triggers a Crossplane Composition or a custom operator that creates the RDS instance, applies a security group, and writes connection credentials to a Kubernetes Secret via External Secrets Operator from Vault. A rotation controller rotates the password on a schedule by calling the RDS API and updating the Vault secret. Decommissioning requires an explicit deletion with a protective finalizer that verifies no active connections before destroying. Failure modes include stale secrets after rotation and orphaned RDS instances if the finalizer logic fails.

Expect these follow-ups

• How do you prevent developers from accidentally deleting a production database by deleting the CR?
• How do you implement a cost approval gate so databases above a certain instance class require manager approval?

As asked

Design an observability stack for a company with 200 microservices generating metrics, logs, and traces. The solution must handle 10M metrics/minute, 1 TB of logs per day, and 50K traces per minute, with 90-day retention for metrics and 30-day for logs. Cost is a primary concern.

Sample answer outline

Metrics: Victoria Metrics or Thanos with S3 backend for long-term storage, Prometheus as the scrape tier with remote_write. Logs: Loki (cheaper than Elasticsearch) with object storage backend; use structured logging and index only essential labels to control cardinality. Traces: Tempo with S3 backend, OTel Collector for ingestion with tail-based sampling at 1% for healthy traces and 100% for error traces. Cost controls: recording rules pre-aggregate expensive queries, log retention tiers (hot 7 days, cold S3 23 days), and strict cardinality limits enforced at ingest.

Expect these follow-ups

• How do you implement correlation between a log line and the trace that generated it?
• What is exemplar support in Prometheus and Grafana, and how does it bridge metrics and traces?

As asked

Design the Git repository structure and Argo CD application model for 50 teams deploying to dev, staging, and prod clusters. How do you handle the tensions between team autonomy (teams want to own their Helm values) and platform governance (the platform team must enforce security policies and image signing)?

Sample answer outline

App-of-apps pattern: a platform repo owns the Argo CD Application objects, and each team has a deployment repo with their Helm values. Teams PR their values into their own repos; the platform repo references them via Argo CD's targetRevision. Governance is enforced at admission time (Gatekeeper policies, image signing verification) so no Git structure change can bypass it. Promotion across environments is a PR to the platform repo that changes the targetRevision tag, reviewed by the platform team.

Expect these follow-ups

• How do you handle emergency hotfixes that cannot wait for the normal Git PR review cycle?
• What is the ApplicationSet resource in Argo CD and how does it reduce the overhead of managing 150 Application objects (50 teams times 3 environments)?

As asked

Design the backup and disaster recovery strategy for a production Kubernetes platform. The RTO is 4 hours and RPO is 1 hour. Cover etcd backups, persistent volume backups, cluster state reconstruction, and how you test the DR procedure without causing an actual outage.

Sample answer outline

etcd backups every 30 minutes to S3 via a CronJob using etcdctl snapshot save, with versioned retention. PV backups via Velero with volume snapshots. Cluster state reconstruction: a Cluster API or eksctl configuration in Git is the source of truth for the cluster itself; the entire control plane can be recreated from a snapshot plus the Git state. Testing: quarterly DR drills in a parallel sandbox account using the latest backup, measuring actual recovery time. Chaos engineering runs in production to validate that the platform survives node and AZ failures without manual intervention.

Expect these follow-ups

• How does Velero handle PVs that are backed by CSI snapshots versus in-tree volume plugins?
• What is the difference between active-passive and active-active DR, and when is active-active worth the cost for a Kubernetes platform?

As asked

You are designing the API that developers use to provision resources on your platform: create services, databases, message queues, and DNS entries. Should this API be a REST API, a Kubernetes CRD API, or a CLI? How do you handle async provisioning, error states, and versioning of the API surface over time?

Sample answer outline

The Kubernetes CRD approach is compelling because it gives developers kubectl and GitOps integration for free, handles async via status conditions, and supports RBAC natively. A REST API gives more control over the experience but requires building auth, status polling, and a client from scratch. Strong candidates argue for CRDs plus a CLI wrapper (like a kubectl plugin) that improves the developer experience on top of the CRD API. Versioning uses apiVersion (v1alpha1, v1beta1, v1) with conversion webhooks for backward compatibility.

Expect these follow-ups

• How do you expose a progress indicator to a developer who is waiting for a database to be provisioned? CRD status fields alone are verbose.
• What is Backstage's relationship to this API, and how do you ensure both the Backstage UI and kubectl/CLI paths use the same underlying API?

As asked

Leadership wants monthly chargeback reports showing each team's cloud spend from their Kubernetes workloads. Design how you collect cost data, attribute it per team per namespace, handle shared costs (ingress controllers, monitoring stack, cluster overhead), and present it in a way teams can act on.

Sample answer outline

Use OpenCost or Kubecost to collect per-pod CPU/memory request and actual usage data, joining it with cloud billing data (AWS Cost and Usage Reports with node cost). Attribute by namespace using the team label. Shared costs (monitoring, ingress) are split by a proportional model (each team's share of total cluster utilization). Report monthly via a Grafana dashboard and push a Slack digest. For action: highlight top 3 wasteful workloads per team (high memory requests vs actual usage).

Expect these follow-ups

• What is the difference between cost based on requested resources and cost based on actual utilization, and which is more fair for chargeback?
• How do you handle spot instances in the cost model where the per-hour price varies?

As asked

You are moving a legacy application from self-managed VMs to the cloud. Which parts do you move to managed services, and which do you keep under your own control?

Sample answer outline

Classify components by operational burden, customisation needs, compliance constraints, and migration risk. Databases, queues, object storage, secrets, and load balancing often benefit from managed services because reliability work shifts to the provider. Keep control where latency, custom extensions, specialised networking, or vendor lock-in risk outweighs the operational win. A mature answer includes an incremental migration plan with strangler patterns, dual-write risk, rollback paths, and observability before cutover. Candidates trip up when they treat managed services as automatically cheaper or automatically more reliable.

Expect these follow-ups

• How do you compare managed Postgres with self-hosted Postgres for a regulated workload?
• What does rollback look like after moving state to a managed service?
• How do you measure whether the migration actually improved reliability?

As asked

A load balancer keeps sending traffic to unhealthy application nodes during deploys. How would you redesign health checks and draining?

Sample answer outline

Distinguish liveness, readiness, and dependency health. A node should be live if the process can keep running, ready only when it can serve real traffic, and draining when it should finish existing requests but reject new ones. Health checks should hit a cheap endpoint that validates critical dependencies without causing a cascading outage when one shared dependency is slow. Configure thresholds, intervals, slow-start, connection draining, and deregistration delay to match the application's startup and shutdown behaviour. Candidates often fail by using one shallow /health endpoint for every purpose.

Expect these follow-ups

• Should database connectivity be part of readiness?
• How do long-lived WebSocket connections change draining?
• What happens if all targets fail the health check at once?

As asked

Our CI builds 500 container images per day and 70% of build time is rebuilding layers that have not changed. Design a distributed layer cache solution for a 50-node CI fleet running BuildKit. How do you handle cache invalidation, storage costs, and security (preventing cache poisoning)?

Sample answer outline

BuildKit supports registry-based cache using --cache-to and --cache-from with a shared registry. A dedicated cache registry (e.g. AWS ECR with lifecycle policies for cost control) stores BuildKit cache manifests. Cache keys are based on Dockerfile content hash plus the base image digest. Cache poisoning prevention: the cache registry requires write access only from CI service accounts, and all cache images are read via the same signing policy as production images. For a 50-node fleet, a pull-through cache or sidecar registry per node reduces registry egress costs.

Expect these follow-ups

• How does BuildKit's inline cache differ from registry cache, and when would you use each?
• How do you measure cache hit rate and cache storage ROI to justify the infrastructure cost to leadership?