Technical challenges of a multi-cloud strategy

WHAT THIS TESTS This probes whether you understand that multi-cloud trades lock-in for substantial operational and technical complexity, especially around data, networking, and identity.

A GOOD ANSWER COVERS Data consistency is the hardest problem: an application split across providers needs its data somewhere, and synchronizing or replicating state across clouds introduces latency, conflict resolution, and large egress fees, since moving data out of a provider is expensive. You often end up pinning data to one cloud or accepting eventual consistency. Networking requires connecting otherwise isolated provider networks through VPNs or dedicated interconnects, dealing with cross-cloud latency, overlapping IP ranges, and differing network primitives like security groups versus NSGs. Identity is genuinely difficult because each provider has its own IAM model and policy language; you need a central identity provider and federation so a single identity and consistent least-privilege policy span clouds. On top of all this sits duplicated tooling, monitoring, and the breadth of expertise required.

COMMON WRONG ANSWERS Believing multi-cloud delivers seamless portability for free. Ignoring egress costs. Underestimating inter-cloud latency for chatty or stateful workloads. Assuming one IAM system covers all providers. Pretending a single abstraction layer removes all differences without its own cost.

LIKELY FOLLOW-UPS How do you handle a shared database across clouds? Federate identity how? Is the lock-in avoidance worth it? When is multi-cloud actually justified?

ONE CONCRETE EXAMPLE A firm runs compute on both AWS and GCP. They keep the primary database in one cloud to avoid cross-cloud write latency and egress, connect the two with a dedicated interconnect, and federate access through a central identity provider with SAML or OIDC so engineers use one identity, while accepting that they now maintain monitoring and IaC for both platforms.