The interviewer asks: "How do you design infrastructure that remains portable across AWS, Azure, and GCP?" Which answer is most balanced?
Option B is strongest: it introduces the portability spectrum concept (not binary), organises the answer into three layers with specific trade-offs at each layer, explains why data is the hardest layer, introduces the portability tax concept with a concrete example (ML services), and closes with the honest insight that most multi-cloud is accidental (acquisition-driven) — which shows real enterprise architecture experience. Multi-cloud vocabulary:Portability tax — the operational overhead and capability sacrifice of cloud-agnostic design. Wire protocol — the network communication format between client and database (e.g., the PostgreSQL wire protocol). Cloud-agnostic API surface — an abstraction layer that works identically across cloud providers. Multi-cloud by acquisition — organisations that end up on multiple clouds through M&A rather than deliberate architecture. Options C and D are accurate but lack the portability spectrum framing and the data layer difficulty explanation.
2 / 5
The interviewer asks: "What's your strategy for avoiding vendor lock-in on managed database services?" Which answer is most nuanced?
Option B is strongest: it introduces the lock-in spectrum as a conceptual model, provides a three-factor decision framework for each service, names the Aurora gotcha (PostgreSQL-compatible wire protocol but proprietary storage layer — a nuance many candidates miss), and closes with the honest insight that some lock-in is justified for scaling — the ADR-based documentation of accepted lock-in is the mature governance response. Multi-cloud vocabulary:Wire protocol compatibility — the client can use standard drivers, but the internals are proprietary (Aurora vs. open-source Postgres). Lock-in spectrum — ranging from commodity services (easily portable) to proprietary services (hard to migrate). ADR (Architecture Decision Record) — a document capturing a technology decision and its rationale. Parquet / Avro — open columnar/row storage formats for analytics data. Options C and D are accurate but lack the Aurora wire protocol gotcha and the spectrum framing.
3 / 5
The interviewer asks: "How would you design a disaster recovery solution that spans two cloud providers?" Which answer is strongest?
Option B is strongest: it starts with business requirements (RTO/RPO) as the decision driver, defines both architectures with cost implications, identifies the write conflict problem in active-active as the primary design challenge, gives the cross-cloud network latency range (20-100 ms) as a concrete constraint, and closes with the annual game day testing requirement — "untested DR is a hypothesis" is a production SRE insight. Multi-cloud DR vocabulary:Active-passive — primary on one cloud, standby on another; failover required for recovery. Active-active — both clouds serve traffic simultaneously. Write conflict — when two nodes accept simultaneous writes to the same record. CRDT (Conflict-free Replicated Data Type) — a data structure designed to resolve conflicts without coordination. Game day — a planned exercise that simulates a disaster scenario to test recovery procedures. Options C and D are accurate but lack the write conflict mechanism and the latency constraint.
4 / 5
The interviewer asks: "How do you govern security policies consistently in a multi-cloud environment?" Which answer is most comprehensive?
Option B is strongest: it covers four governance layers (identity, policy, logging, secrets) with specific tools and rationale for each, explains the workload identity mechanism (OIDC-based, no static credentials), introduces the policy-as-code enforcement points (CI and runtime), explains dynamic secrets and their blast-radius reduction benefit, and names the cloud-specific log sources for SIEM aggregation. The OIDC workload identity detail shows real multi-cloud security engineering experience. Multi-cloud security vocabulary:Federated identity — using a central IdP for authentication across multiple systems. OIDC (OpenID Connect) — an identity federation protocol. OPA (Open Policy Agent) — a cloud-native policy engine. Conftest — a tool for validating configurations using OPA policies. Dynamic secrets — credentials generated on-demand and automatically revoked, reducing exposure window. Options C and D are accurate but lack the dynamic secrets rationale and the workload identity mechanism.
5 / 5
The interviewer asks: "How do you approach cloud cost optimisation across multiple cloud providers?" Which answer is most mature?
Option B is strongest: it identifies the gap in single-cloud tools, names specific cross-cloud platforms, explains the egress cost problem with actual pricing ($0.08-0.09/GB) — a practical insight that shapes design decisions, covers the per-provider commitment strategy differences, and introduces the FOCUS spec as an emerging normalisation standard — showing current FinOps knowledge. The egress insight is the most differentiated element. Multi-cloud FinOps vocabulary:Egress cost — the charge for data transferred out of a cloud provider's network. Cross-cloud cost arbitrage — running workloads on the cheaper cloud for each type. EDP (Enterprise Discount Programme) — AWS's volume commitment discount for large enterprises. CUD (Committed Use Discount) — GCP's version of reserved instances. FOCUS spec — an open standard for normalising cloud billing data across providers. Options C and D are accurate but lack the egress pricing specifics and the FOCUS spec reference.