Designing for portability across two clouds

WHAT THIS TESTS The interviewer wants to see whether you treat multi-cloud as a deliberate trade-off rather than a buzzword. Strong candidates reason about lock-in cost, operational overhead, and which abstractions actually buy portability.

A GOOD ANSWER COVERS Start by separating the compute layer from data and integration. Containers orchestrated by Kubernetes give you a portable runtime, and infrastructure-as-code tools like Terraform or Crossplane describe resources declaratively across providers. Push portability through open interfaces: an object-storage abstraction over S3 and Blob, a message-queue abstraction, and a database you can self-host or that exists on both clouds such as Postgres. Keep proprietary, deeply managed services behind adapters so swapping them is contained. Acknowledge that genuine portability means accepting the lowest common denominator and forgoing the best-of-breed managed offerings.

COMMON WRONG ANSWERS Claiming you simply deploy to both clouds with no architectural cost. Assuming a single IaC tool makes you portable while your code still calls provider-specific SDKs everywhere. Ignoring data gravity and egress fees, which often make true cross-cloud failover impractical.

LIKELY FOLLOW-UPS How do you handle identity and secrets across two clouds. What is your data egress and networking cost model. Would you run active-active or active-passive across providers. When is single-cloud with multi-region the better answer.

ONE CONCRETE EXAMPLE A SaaS vendor whose enterprise customers demand a choice of AWS or Azure packages its product as Helm charts on Kubernetes, provisions clusters with Terraform modules per provider, and stores blobs through an internal storage interface backed by S3 or Blob. They run Postgres rather than DynamoDB to stay portable, and they accept slower feature delivery as the price of selling into both ecosystems, rather than splitting one workload live across two clouds.