Platform Architect Interview Questions

Option B is the strongest: it defines both terms precisely, introduces the Internal Developer Platform (IDP) concept with its key goal (lower cognitive load), explains golden paths as curated abstractions over underlying services, and distinguishes adoption models — manual integration vs. self-service interfaces. Key vocabulary for Platform Architect interviews: Internal Developer Platform (IDP) — the platform a company builds for its own engineers; the sum of tooling, workflows, and self-service capabilities. Golden path (also "paved road") — the opinionated, recommended way to do something on the platform; captures best practices so teams don't start from scratch. Cognitive load — the mental effort placed on developers; reducing it is the primary goal of a platform. Abstraction vs. integration — shared services require teams to integrate each capability; a platform abstracts the complexity behind consistent, curated interfaces. Self-service — developers can provision resources, deploy services, and configure environments without raising a ticket. Option C correctly identifies productisation but misses the abstraction and IDP concepts. Option D raises the product mindset point well but doesn't address golden paths or cognitive load.

Option B is the strongest: it opens with the three canonical isolation models (silo/pool/bridge), applies them at the platform level, precisely names the noisy neighbour problem and the mechanisms that mitigate it (resource quotas, LimitRanges, network policies), addresses the data layer separately with a concrete pattern (per-tenant schemas + row-level security), and frames the design decision around blast radius. Key multi-tenancy vocabulary: Isolation models — silo (dedicated), pool (shared), bridge (hybrid). Each trades isolation against cost and operational overhead. Noisy neighbour problem — a tenant consuming disproportionate shared resources and degrading performance for others. Resource quotas / LimitRanges — Kubernetes primitives that cap CPU, memory, and object counts per namespace. Namespace isolation — Kubernetes namespaces as logical tenant boundaries, enforced by RBAC and network policies. Blast radius — the scope of impact when something goes wrong; a key design constraint in multi-tenant systems. Consumer-driven rate limits — API gateway throttling per tenant to prevent one tenant from monopolising platform throughput. Option C is technically solid but misses the isolation model taxonomy. Option D focuses well on the noisy neighbour problem but doesn't address isolation models or data-layer design.

Option B is the strongest: it explicitly rejects mandates and explains why (resentment, shadow IT), names all the key concepts — golden paths, paved roads, developer experience (DX), internal developer portal — gives concrete metrics (time-to-first-deployment under an hour), mentions a measurement framework (SPACE), and crucially includes off-ramps, which signals mature platform thinking. Key vocabulary for voluntary adoption answers: Golden path / paved road — the opinionated, well-supported route that embeds best practices; following it gives you compliance, security, and observability automatically. Developer experience (DX) — the quality of the developer's interaction with the platform: tooling, docs, feedback speed, error messages. Shadow IT — teams building their own solutions outside the platform because the platform doesn't meet their needs; the failure mode of mandated adoption. Internal developer portal (IDP) — a single UI for discovering services, provisioning resources, and accessing documentation (Backstage is the canonical open-source example). Off-ramps — explicit escape valves allowing teams to deviate from the golden path when justified; builds trust by avoiding the "all or nothing" dynamic. SPACE framework — a developer productivity measurement model (Satisfaction, Performance, Activity, Communication, Efficiency). Option C is a good answer about community and social proof but misses golden paths and off-ramps. Option D introduces "activation energy" well but doesn't name the key concepts precisely enough for a senior role.

Option B is the strongest: it defines breaking changes precisely, applies semantic versioning correctly, introduces a structured deprecation policy with a concrete notice window, mentions consumer-driven contract tests (the most sophisticated tool for preventing accidental breakage), and includes the often-missed step of instrumenting usage to know when retirement is safe. Key backwards compatibility vocabulary: Semantic versioning (SemVer) — MAJOR.MINOR.PATCH: MAJOR bumps signal breaking changes, MINOR add backwards-compatible features, PATCH fix bugs. Breaking change — any change that forces a consumer to modify their code: removing a field, changing a type, altering required parameters, modifying error shapes. Deprecation policy — the formal commitment on how long old API versions are supported after a replacement ships; critical for consumer trust. Consumer-driven contract tests (Pact) — tests where each consumer publishes a "contract" describing what it uses from a provider; the platform runs these contracts in CI to catch breaking changes before they reach production. Migration path / codemod — tooling that automates the consumer-side migration, reducing the cost of adopting a new API version. Usage instrumentation — tracking per-version call volume to identify when an old version has zero consumers and is safe to retire. Option C introduces Postel's Law but misses contract testing and deprecation policy structure. Option D is solid on communication but doesn't address contract testing or how to define breaking changes precisely.

Option B is the strongest: it addresses both observability layers (platform health and tenant tooling), makes a precise case for OpenTelemetry with the correct rationale (vendor-neutral, single instrumentation, OTLP standard), names the cardinality problem as the key scaling challenge and explains it, articulates the centralised vs. federated trade-off explicitly, and ends by connecting back to platform SLOs — a senior-level synthesis. Key platform observability vocabulary: OpenTelemetry (OTel) — the CNCF standard for generating and collecting telemetry data (metrics, logs, traces) with a single SDK and OTLP wire protocol; the current industry default. Three pillars of observability — metrics (time-series aggregates), logs (structured event records), traces (distributed request flows). OTLP (OpenTelemetry Protocol) — the wire protocol for shipping telemetry to any compatible backend; enables vendor portability. Cardinality — the number of unique label combinations in a metric. High cardinality (e.g., per-user or per-request labels) causes exponential time series growth and is the most common cause of Prometheus instability at scale. Centralised vs. federated — whether all teams share one observability stack or each has their own, aggregated at query time. Golden signals — the four key platform health metrics from Google SRE: latency, error rate, saturation, and traffic. Option C is technically strong and mentions cardinality but doesn't address the centralised/federated trade-off or platform SLOs. Option D distinguishes the two audiences well but misses cardinality and the centralised/federated architecture decision.

Option B is the strongest: it articulates the tension precisely, introduces the canonical paved road with off-ramps metaphor with concrete examples, mentions Architecture Decision Records (ADRs) as the governance tool for preserving decisions, applies graduated autonomy calibrated to risk, and ends with the insight that standardisation must earn trust by being demonstrably better — a senior-level observation that separates platform architects from platform administrators. Key vocabulary for standardisation vs. autonomy answers: Paved road (golden path) — the supported, opinionated route that teams can follow for zero-configuration value; following it confers free benefits (security scanning, compliance, observability). Off-ramps — explicit, documented mechanisms for deviating from the standard path with stated trade-offs; prevents the "all or nothing" dynamic that creates shadow IT. Architecture Decision Records (ADRs) — short documents capturing the context, decision, and trade-offs for significant architectural choices; makes reasoning auditable and revisitable. Graduated autonomy — calibrating team freedom to the risk profile of the domain; tight standards where mistakes have broad impact, loose standards where mistakes are local. Shadow IT — teams building outside the platform because it doesn't meet their needs; the failure mode of over-standardisation. Option C introduces a useful tiered model but doesn't name ADRs or graduated autonomy. Option D's "thin platform" framing is valid but too abstract and misses the paved road / off-ramps language that demonstrates platform product maturity.

Option B is the strongest: it names and briefly explains the SPACE framework (the most current, multi-dimensional developer productivity model), distinguishes leading vs. lagging indicators with a clear rationale, identifies the right leading metrics for a platform (onboarding time, deployment frequency, toil reduction), and includes the sophisticated insight about off-ramp usage as a signal of path quality, and the distinction between adoption rate (vanity) and retention (signal). Key platform measurement vocabulary: SPACE framework — a developer productivity model from Microsoft Research: Satisfaction and well-being, Performance, Activity, Communication/Collaboration, Efficiency and flow. More comprehensive than DORA alone. DORA metrics — four metrics from the DevOps Research and Assessment programme: Deployment Frequency, Lead Time for Changes, Change Failure Rate, Mean Time to Recovery. A platform should move teams toward Elite performance. Leading vs. lagging indicators — leading (onboarding time, deployment frequency) predict future outcomes; lagging (time-to-market, revenue impact) confirm past performance. Platform decisions need leading indicators because lagging ones arrive too late. Toil reduction — measuring the decrease in undifferentiated infrastructure work is the most direct signal that the platform is delivering its core value proposition. Retention vs. adoption — adoption rate counts teams that have tried the platform; retention measures teams actively staying on it. A platform with high adoption but low retention is failing. Option C is a solid comprehensive answer but doesn't mention SPACE or the leading/lagging distinction. Option D mentions DORA and cognitive load well but misses the retention vs. adoption nuance.

Option B is the strongest: it frames capacity planning as demand forecasting combined with an explicit headroom policy, breaks platform load into components for separate modelling (traffic modelling), validates the model against reality via load testing, applies per-tenant quotas to isolate demand, and — the senior-level differentiator — connects the capacity forecast to a rolling budget plan with concrete numbers and an efficiency metric to catch runaway growth. Key capacity planning vocabulary: Demand forecasting — projecting future resource requirements from current trends, seasonal patterns, and roadmap input; the analytical foundation of capacity planning. Traffic modelling — decomposing aggregate load into its constituent signals (RPS, storage growth, queue depth) and modelling each separately because they scale independently. Headroom policy — a proactive commitment to maintain a percentage of free capacity (e.g., 30%) at all times; not a reactive alert threshold but a design constraint. Load testing — validating capacity models against real breaking points in a controlled environment; prevents the model from being purely theoretical. Per-tenant quotas with burst allowances — isolating demand spikes from individual tenants so one team's traffic event doesn't exhaust platform capacity for others. Capacity efficiency metrics — tracking cost-per-unit-of-platform-usage to detect inefficiency early. Rolling capacity plan — a living forecast (typically 6–12 months) that informs budget cycles with specific, quantified projections. Option C is correct on methodology but lacks the headroom policy concept, per-tenant quotas, and the budget-connection that demonstrate senior-level thinking. Option D's elastic vs. fixed distinction is useful but misses demand forecasting rigour and the budget narrative.

This scenario tests understanding that Platform Architects don't just react to symptoms. Scaling without investigation is a common mistake. The correct answer emphasizes the need for deeper analysis – identifying bottlenecks – before applying a potentially costly solution. Option B is incorrect as immediate scaling isn't always effective.

The core concept here is about *platform governance*. A Platform Architect isn't just about features; they're responsible for enforcing standards and promoting best practices. Option B misunderstands the purpose of a code review tool. The correct answer focuses on guiding developers toward consistent architecture.

This tests understanding of *API design*. A good API description anticipates future needs. David's response highlights the importance of thinking beyond just the current implementation and including considerations like rate limits and error handling – key elements for a robust, evolvable platform.

This question probes understanding of *platform product thinking*. While microservices are a technical detail, a Platform Architect needs to articulate *why* they were chosen – and what value that brings. Option B focuses solely on the technical aspects, missing the crucial link to business agility.

This question tests understanding of *observability*. Simply reacting to high CPU without investigating the cause is a classic problem. A Platform Architect's role is to understand the underlying issues and prevent future problems – proactively monitoring for further spikes is key.