Platform Engineer Interview Questions & Answers

Example answer

“I found that each of our 22 service teams maintained a different GitHub Actions deployment workflow, and median production lead time was 2.8 days because release engineers had to troubleshoot them. I built a versioned reusable workflow that ran image scanning, Helm linting, integration tests, and Argo CD promotion, with workload configuration kept in a small service repository. I piloted it with three teams, added an escape hatch for their custom database migration step, and published workflow failure dashboards in Grafana. Within four months, 18 teams adopted it, median lead time fell to 7.5 hours, and deployment-related support tickets dropped 41 percent. The important part was measuring adoption and failure modes; without that, it would have been another optional CI template.”

Example answer

“Our organization had six hand-maintained Jenkins controllers, each with different plugins and credential practices. We had 19 pipeline outages in one quarter, and patching Jenkins consumed about 30 platform-engineer hours every month. I proposed moving container builds and test stages to GitHub Actions, starting with low-risk services and publishing reusable actions for our common AWS authentication and Docker build steps. I tracked migration completion, build duration, and failure rate by team, and kept Jenkins read-only after each team's cutover. In five months, we retired four controllers, reduced CI maintenance to six hours monthly, and improved successful first-run pipeline executions from 82 percent to 94 percent.”

Example answer

“A new Kyverno policy required every Deployment to define resource limits, but our initial rule treated an absent limit as an admission failure rather than warning mode. During a release window, 31 legacy services could not deploy, including two services trying to roll back a production defect. I disabled enforcement for the affected namespaces, restored deployability in 18 minutes, and wrote the incident review myself because the failure was in our platform default. We changed the policy to audit mode first, generated a Prometheus-based compliance report, and gave teams a 30-day remediation window with suggested limits from historical usage. The next enforcement rollout reached 97 percent compliance before activation and caused zero blocked production rollbacks.”

Example answer

“A product team asked for privileged Kubernetes pods so they could mount the Docker socket for integration tests in their production-adjacent cluster. I showed them that this would turn a compromised test container into potential node-level access and violate our workload isolation standard. Instead, I created a dedicated CI runner pool using rootless BuildKit, short-lived AWS credentials through OIDC, and an isolated ECR cache. Their first concern was speed, so I benchmarked it against the requested design and got builds within 11 percent of the Docker socket approach. They shipped on schedule, and we avoided creating a privileged-pod exception that other teams would have copied.”

Example answer

“I would begin by confirming compliance boundaries, expected regional availability, and whether all 80 services have similar latency and isolation needs. For most teams, I would use separate AWS accounts for production and nonproduction, with one EKS production cluster per region initially, namespace tenancy, RBAC mapped from the identity provider, default-deny network policies, and workload AWS access through IRSA rather than static keys. Argo CD would reconcile Helm or Kustomize manifests from Git, while External Secrets would retrieve values from AWS Secrets Manager. I would run a centrally operated Prometheus stack with team labels, Grafana dashboards, and alert routing owned jointly by the service and platform teams. I would measure tenant onboarding time, deployment success rate, policy violations, cluster upgrade completion time, and p95 API-server or scheduling saturation, then split clusters only when those metrics or isolation requirements justify the added operational cost.”

Example answer

“I would not force AWS and Azure resources into a fake universal module because their networking, identity, and managed Kubernetes semantics differ too much. I would standardize the input contract at the platform layer, then provide separate approved modules for things like private networking, Kubernetes clusters, secret stores, and workload identities. Terraform state would be isolated by environment and blast radius, stored remotely with locking and encrypted access controlled by CI identities rather than developer credentials. Every pull request would run fmt, validate, provider-specific policy checks, and a plan reviewed against a change classification; scheduled plans would flag drift. I would track module version adoption, unapproved-resource policy violations, mean apply duration, and drift age, because a module catalog is only healthy if teams can upgrade and operate it predictably.”

Example answer

“I would first confirm whether the spikes are p99-only, whether they align with a deployment, and whether one zone, node pool, or endpoint is overrepresented. I would use Grafana to correlate request latency and error rate with ingress metrics, pod restarts, container throttling, node network errors, CoreDNS latency, and downstream database or API spans from OpenTelemetry. If CPU looked normal, I would specifically check CPU throttling, because a low average can hide a tight container limit during bursts, and I would inspect HPA behavior and pending pods. In one incident, this approach showed that a new node group had a lower MTU than the rest of the VPC path, causing retransmits for only pods on those nodes; p99 latency fell from 2.4 seconds to 380 milliseconds after correction. I then added node-group and availability-zone labels to the service latency dashboard and an alert on retransmit rate so the next signal would be visible in minutes.”

Example answer

“I would build the image once from a commit SHA, generate an SBOM, sign the image, and store it in a registry with immutable tags. The CI system would use OIDC to assume narrowly scoped cloud roles, run unit and integration tests, scan dependencies and images, and publish the image digest only after required checks pass. Promotion would update a GitOps environment repository by digest, so Argo CD—not a CI runner with cluster-admin credentials—reconciles the production workload. For high-severity exploitable vulnerabilities, I would block promotion; for lower-severity findings, I would create a time-bound exception process rather than silently failing teams. I would track p50 pipeline duration, commit-to-production lead time, deployment success rate, and mean rollback time, and I would optimize the slowest stage only if it materially affects those outcomes.”

Example answer

“I would first inspect TSDB head series, ingestion rate, top metrics by cardinality, query latency, and retention cost rather than immediately scaling the Prometheus disks. In a similar case, a team had added customer ID and full URL path labels, which raised active series from 4.2 million to 17 million and pushed query p95 above 18 seconds. I worked with them to replace those labels with route templates and use traces for customer-level investigation, then added admission checks to our metrics SDK guidance and scrape review process. We also created recording rules for the dashboards that repeatedly aggregated raw histograms. Active series dropped 61 percent, query p95 returned to 3.1 seconds, and ingestion headroom increased from six days to more than five weeks.”

Example answer

“I would identify which services actually inherit the vulnerable digest, which are internet-facing, and whether the vulnerable package is reachable in their runtime images. I would publish a patched golden base image, open automated dependency-update pull requests, and use our reusable CI workflow to rebuild and scan services without requiring each team to reinvent the fix. A dashboard would show remediation by service owner, exposure tier, and production deployment status, while any exception would need an expiry and compensating control. In a prior response, 146 services were affected; 119 were rebuilt and deployed within 48 hours, and all internet-facing services were remediated within 12 hours. The remaining services had tracked exceptions, not an invisible spreadsheet of unresolved risk.”

Example answer

“I would refuse to start with a blanket request-limit reduction because that often buys a short-term savings number and creates throttling or OOM incidents. I would use AWS cost allocation tags plus Kubecost-style namespace allocation to isolate whether the increase came from node pools, data transfer, storage, or a few new workloads. In one quarter, we found that nonproduction clusters ran oversized node groups around the clock and that 27 services requested three to five times their p95 memory usage. We scheduled nonproduction capacity down overnight, right-sized workloads after two weeks of Prometheus data, and enabled cluster autoscaler consolidation with protected disruption budgets. Spend fell 22 percent over the next two months while p99 latency and deployment success rate remained within baseline, which made the savings credible.”

Example answer

“I would first ask what exact change is needed and whether the existing GitOps path can be expedited with an approved reviewer and a narrow deployment window. If an out-of-band change were truly necessary, I would use a break-glass role with a short session, require a rollback command and a second approver, and capture the before-and-after manifests in the incident or change record. I would not allow a direct console edit that cannot be reconstructed. After the demo, the change would be committed to the GitOps repository or Terraform module before the next business day, and drift detection would verify convergence. On my last team, we tracked these exceptions monthly; reducing them from 14 to 3 per quarter exposed two missing self-service capabilities that we then built into the normal release path.”