Platform Engineering Interview Questions India 2026: IDPs, Golden Paths, and Developer Experience

Platform engineering fundamentals:

1. What is platform engineering? Platform engineering is the discipline of building and operating the internal developer platform (IDP) that product engineering teams use to build, deploy, and operate their services. The platform team's customers are other engineers. Platform engineers apply product thinking and UX design to internal tooling: they treat engineers as users, define the developer experience (DevEx), and measure developer productivity metrics.

2. Platform engineering vs DevOps: DevOps is a cultural movement: break down silos between development and operations; shared responsibility for deployment and reliability; automate everything. Platform engineering emerged FROM DevOps as organisations scaled: instead of every development team running their own DevOps, a dedicated platform team builds and operates the IDP. Product engineers use the IDP's self-service capabilities without needing deep knowledge of Kubernetes, Terraform, or CI/CD configuration. Platform engineers reduce toil (repetitive, manual work) for product engineers.

3. Platform engineering vs SRE: SRE (Site Reliability Engineering): focused on reliability and availability of production services; defines SLOs; owns the on-call rotation and incident response. Platform engineering: focused on developer productivity and self-service; builds and operates the IDP; reduces cognitive load for product engineers. Both roles exist at large Indian companies (Flipkart, Swiggy, Razorpay); at smaller companies, the roles overlap.

4. The team topology: Stream-aligned teams: small product engineering teams that own a service or product area end-to-end. Platform team: a separate team that builds and operates the IDP for stream-aligned teams. Enabling teams: specialist teams (security, data, ML infrastructure) that temporarily embed with stream-aligned teams to help them adopt new capabilities. The platform team reduces the cognitive load on stream-aligned teams by providing self-service golden paths.

IDP components and design:

1. What is an internal developer platform (IDP)? An IDP is a self-service layer on top of infrastructure tools that allows developers to provision environments, deploy services, and manage their application lifecycle without deep infrastructure knowledge. Components of a mature IDP: self-service service provisioning (a developer creates a new service from a template in minutes: repository, CI/CD, Kubernetes namespace, staging deployment — all pre-wired), environment management (easily create and destroy ephemeral preview environments for each PR; no manual provisioning), secrets management (developers request secrets from Vault or AWS Secrets Manager through the platform), observability onboarding (new services are automatically connected to Grafana, Prometheus, and Jaeger), developer portal (Backstage: catalog of all services with ownership, documentation, API specs, runbooks, and operational health).

2. Golden paths: A golden path is the recommended, supported, opinionated way to accomplish a common task (deploy a service, add a database, set up monitoring). Following the golden path means: the platform's tooling is pre-configured, the security and compliance guardrails are built in, and the platform team will support you. Straying from the golden path means you own the consequences. Golden paths reduce cognitive load (engineers do not need to research how to do everything from scratch) and improve consistency (all services deployed via the golden path have the same structure, the same observability, the same security baseline). Key principle: golden paths must be easier than the alternatives. If they are not easy enough, engineers will bypass them.

3. Paved roads vs guardrails: Paved road: the easiest path is also the correct path; the golden path has low friction and clear documentation. Guardrails: boundaries that prevent engineers from making dangerous choices (a CI/CD pipeline that blocks deployments to production without an approved change request; a policy that prevents Docker images without a security scan from running in production). The best IDPs combine paved roads (make the right thing easy) with guardrails (make the wrong thing hard or impossible).

4. Developer experience (DevEx) metrics: DORA metrics: Deployment Frequency (how often does the team deploy to production?), Lead Time for Changes (how long from commit to production?), Change Failure Rate (what percentage of deployments cause a production incident?), Time to Restore Service (how long to recover from a production incident?). SPACE framework: Satisfaction, Performance, Activity, Communication, Efficiency. Cognitive load: measure how much engineers have to know to do their job (cognitive load is the enemy of developer productivity).

Platform tooling:

1. Backstage: Backstage is an open-source developer portal built by Spotify and donated to CNCF. It is the standard internal developer platform UI at large Indian companies (Flipkart, Razorpay, Swiggy, and many others have adopted it). Core features: software catalog (every service, its owner, its tech stack, its runbook, its SLO, its on-call rotation — searchable in one place), software templates (scaffolding for new services: create a new Node.js microservice, a Python ML service, or a Kafka consumer with one click), TechDocs (documentation-as-code: markdown docs rendered inside Backstage), plugins (integrate with GitHub, Jenkins, PagerDuty, Datadog, Kubernetes, ArgoCD, Vault — there are 200+ community plugins).

2. Self-service infrastructure with Terraform and Crossplane: Infrastructure as Code (IaC): all infrastructure is defined in code (Terraform, Pulumi) and version-controlled. Self-service: instead of filing a ticket with the infra team, a product engineer submits a pull request to a Terraform module (adds an RDS database to their service's module) — the platform team's CI/CD pipeline applies it automatically after approval. Crossplane: Kubernetes-native IaC; define infrastructure resources as Kubernetes custom resources; the Crossplane operator manages them. Allows platform teams to build self-service infrastructure APIs using the Kubernetes API server (engineers use kubectl or the Backstage UI to provision infrastructure, not Terraform directly).

3. GitOps and ArgoCD: GitOps: Git is the single source of truth for both application code and infrastructure configuration. All changes happen via pull requests; no manual kubectl apply or Terraform apply in CI. ArgoCD: a GitOps continuous delivery tool for Kubernetes. ArgoCD watches a Git repository and automatically syncs the cluster state to match the repository. Drift detection: ArgoCD detects when the cluster state drifts from the repository and alerts (or auto-heals). The platform team manages the ArgoCD configuration; product engineers only need to push code and configuration to Git.

4. Kubernetes operator pattern: Kubernetes operators encode operational knowledge as code. An operator watches for custom resources (CRDs) and manages the lifecycle of a complex stateful application (database, message queue, monitoring stack). Platform teams build operators to manage common infrastructure components: a Database operator that provisions, configures, backs up, and scales PostgreSQL databases; a Secrets operator that syncs secrets from AWS Secrets Manager to Kubernetes secrets. This allows self-service provisioning of complex infrastructure via simple Kubernetes YAML.

Platform engineering interview preparation:

1. Technical topics commonly tested: Kubernetes: pods, deployments, services, namespaces, RBAC, resource limits and requests, custom resources (CRDs), operators, Helm charts, ArgoCD/FluxCD. CI/CD: GitHub Actions, Jenkins, GitOps principles, pipeline design (lint, test, build, security scan, deploy to staging, deploy to production). Infrastructure as Code: Terraform (resources, modules, state management, workspaces), Pulumi, or Crossplane. Observability: Prometheus + Grafana (dashboards and alerting), distributed tracing (Jaeger, Tempo), log aggregation (Loki, ELK). Service mesh: Istio concepts (mTLS, VirtualService, DestinationRule). Security: Secrets management (Vault, AWS Secrets Manager), RBAC, image scanning (Trivy, Snyk), OPA/Gatekeeper (policy enforcement in Kubernetes).

2. Platform team vs application team mindset: Platform engineers must think like product managers for internal users: What are the pain points of the product engineers? What is the cognitive load they face? What are the most requested capabilities? What is the DORA metrics impact of each platform investment? They also think about reliability of the platform itself: the platform is shared infrastructure; a platform failure affects every team. High availability and backward compatibility are non-negotiable.

3. System design for platform engineering: Common platform engineering system design questions: Design a self-service database provisioning system that allows developers to request a PostgreSQL database and have it provisioned within 5 minutes, with automated backups, monitoring, and runbooks. Design a secrets management system that allows developers to access secrets from their services without storing secrets in code or CI/CD environment variables. Design an on-call management system that reduces alert fatigue and improves MTTD (mean time to detect) and MTTR (mean time to recover).

4. Platform engineering career in India: Platform engineering is a relatively new role at Indian product companies. It is in high demand as companies scale their engineering organisations. Roles: Platform Engineer, Senior Platform Engineer, Staff Platform Engineer (IC), Engineering Manager (Platform), VP of Infrastructure/Platform. Salaries: Platform Engineer India, 3-5 years: 25-50 LPA. Senior Platform Engineer (5-8 years): 45-90 LPA. Staff Platform Engineer (8+ years): 80-150 LPA. Companies hiring: Flipkart, Swiggy, PhonePe, Razorpay, Zepto, CRED, Meesho, Groww, and well-funded Indian startups with 100+ engineers.