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.
What does "Multi-Cloud Architect Interview Questions — IT English Practice — IT English Practice" cover?
Practice answering Multi-Cloud Architect interview questions in English: cloud portability, vendor lock-in avoidance, cost governance, disaster recovery, and multi-cloud security.
How many questions are in this interview set?
This set has 5 exercises, each with a full explanation.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
Do these exercises include model answers?
Yes. Each interview question gives you several possible responses and asks you to pick the one that communicates most clearly and completely — the explanation then breaks down exactly why that answer works, including the specific vocabulary a strong candidate would use.
What if I choose an answer that isn't the strongest one?
You'll see which option was correct and read a full explanation of why it's stronger than the alternatives, plus the key vocabulary and phrasing worth reusing in a real interview.
Can I retry the questions?
Yes — use the "Try again" button on the results screen to reset and go through the set again.
Is this the same as a real technical or behavioural interview?
No — it's focused practice for the language side of interviewing: recognising which phrasing sounds precise and confident versus vague, and knowing the vocabulary interviewers expect for this role. It won't replace mock interviews, but it builds the vocabulary you'll need in one.
Where can I find interview prep for other roles?
Browse the full Interview exercises hub for 170+ modules covering behavioural, technical, and system design rounds across dozens of IT roles, or check the "Next up" link below to continue.
Do I need an account, and is my progress saved?
No account is needed. Progress is tracked only for your current visit — reloading or leaving the page resets the counter.
Who writes these interview questions?
Every question is written by the CoderSlingo team based on real technical interview patterns for this role, then reviewed for accuracy and clarity.