Cloud Architect Interview Questions: What the 2026 Loop Actually Tests

The honest cost is usually smaller than architecture diagrams suggest. Full provider portability sounds appealing until you calculate what it costs to avoid every managed service that made the first migration worth doing, and most teams end up paying that tax every day for a switch they never execute.

A more realistic mitigation: keep the application layer portable (containers, standard APIs) while accepting lock-in on managed data services where the operational savings are real. Abstract the interfaces you'd actually need to swap, not every service the provider offers, and skip building a portability layer for a migration that isn't already on a roadmap.

Encryption at rest protects data sitting on disk, so a stolen or improperly decommissioned drive doesn't expose readable data. Encryption in transit (TLS) protects data moving across a network from interception. Both are close to table stakes in 2026, most managed cloud services encrypt at rest by default now.

Key management is where the real decisions live. A provider-managed key is simpler but the provider technically has some level of access. A customer-managed key gives you rotation control, an audit trail of every use, and the ability to revoke access to a dataset instantly by disabling the key, which matters for offboarding a vendor or responding to a breach in a way that reducing a bucket's IAM policy doesn't.

Utilization metrics (CPU, memory, network) collected over a real window, at least two weeks to catch a weekly traffic pattern, flag instances running well under their provisioned size. An automated policy, via the provider's own tooling or something like AWS Compute Optimizer, can downsize or flag these without a human combing through a spreadsheet every quarter.

Idle resource cleanup catches a different failure mode: unattached EBS volumes, orphaned load balancers pointing at nothing, old snapshots nobody's referenced in a year. A scheduled job that flags anything untouched past a threshold, with a human approval step before deletion, catches most of this without accidentally deleting something someone actually needs.

High availability handles component failure inside a system designed to keep running, a server dies, traffic reroutes to a healthy one automatically, seconds of impact if any. Disaster recovery handles the loss of an entire environment, a full region, a data center, a catastrophic operator error, and recovery is measured in minutes to hours, with an explicit plan rather than automatic rerouting.

Candidates conflate them because a well-built HA system feels like it should cover disaster scenarios too, and sometimes multi-AZ HA genuinely does absorb a single-AZ failure. It doesn't cover a full-region outage or a bad deploy that corrupts data across every AZ simultaneously, and interviewers ask this specifically to check whether you know where that line actually sits.

Three copies of data, on two different storage types, with one copy offsite. In a cloud context that becomes: production data, a same-region backup (often just versioning plus lifecycle rules on object storage), and a cross-region or cross-account copy that a compromised primary account can't touch or delete.

The cross-account part matters more than people give it credit for. A backup living in the same account as production doesn't protect against a compromised credential or a malicious insider with delete permissions, since the same access that can delete production data can usually delete its backup sitting right next to it.

Name a real trade-off you made, what you deferred, and whether deferring it turned out to be the right call. "We shipped without a caching layer to hit launch, then added it three weeks later once we had real traffic data to size it against" is concrete. "I always try to balance both" tells the interviewer nothing they didn't already assume about you.

If a deferred decision later caused a real problem, say so. That's a more credible answer than one where every trade-off happened to work out perfectly, and interviewers can usually tell the difference between a real story and a polished one.

The titles overlap more than they differ at most companies. Where they diverge, cloud architect loops tend to weight infrastructure-level tradeoffs (multi-region, IaC, cost, DR) more heavily, while solutions architect loops sometimes lean toward mapping a specific business requirement to a design, closer to a pre-sales or consulting context at companies like AWS or Google Cloud. Ask the recruiter which flavor your specific loop is testing.

Less than a general software engineering loop, but it's not universal that there's none. Some companies include a light coding or scripting round, usually Python or Bash, often IaC-adjacent, writing a Terraform module or a script that checks a set of resources. Architecture and system design rounds dominate the loop at senior levels; coding, when it appears, is usually a filter earlier in the process rather than the centerpiece.

Deep enough to speak fluently about whichever provider the team actually runs, since interviewers will probe specific service names and behavior, not just concepts. The underlying tradeoffs, consistency models, cost optimization patterns, IAM design, transfer across providers, which is why this page stays mostly provider-agnostic, but expect the interviewer to translate every answer back to their specific stack during follow-ups.

Multi-region and disaster recovery scenarios show up in nearly every senior loop, usually with a cost or scale constraint layered on top of a design that would otherwise be straightforward. Multi-tenant SaaS isolation and cross-cloud or hybrid scenarios come up specifically at companies running that kind of environment, so it's worth asking the recruiter what the team's actual infrastructure looks like before the interview, not after.

Most loops run 3 to 6 weeks from application to offer, longer than a typical software engineering loop because senior architecture rounds are harder to schedule, fewer people are qualified to run them, and because a system design round often gets debriefed by a separate panel before a decision. A referral can compress the front end but rarely speeds up the design-round scheduling itself.

Not universally required, but it's the most commonly expected infrastructure-as-code tool at this point, and a candidate with zero IaC experience is a real gap in most 2026 loops. CloudFormation or Pulumi experience usually transfers fine conceptually. Interviewers are checking that you think about infrastructure as versioned, reviewable code, not that you've memorized Terraform's specific syntax.

Start with the team's operational maturity, not the feature list on a vendor's pricing page. A two-person platform team running a tight release schedule usually loses more time self-managing a Kubernetes cluster on IaaS than a managed PaaS option would ever cost them in markup. Flip that around for a team that needs low-level control over networking, kernel parameters, or a custom runtime, and PaaS starts working against you instead of for you.

The follow-up worth preparing for is the one where the interviewer changes a single variable, more scale, a tighter compliance requirement, a hard cost cap, and asks you to redo the call. A good answer treats the decision as reversible early and expensive to reverse later, which is itself the argument for starting with whichever option costs the least to change your mind about.

Lift-and-shift moves a workload with minimal changes, fastest to execute, but you inherit every architectural problem the workload already had, just running on someone else's hardware now. Replatform makes targeted changes, swapping a self-managed database for a managed equivalent, without touching the application architecture. Refactor rebuilds the workload around cloud-native patterns and usually delivers the biggest long-term win, at the highest cost and risk.

Pick lift-and-shift under a hard deadline, a data center lease expiring in 90 days, for example. Pick refactor when the current architecture is actively the bottleneck, not just old. Most real migrations end up mixing all three across different services in the same estate, and a candidate who assumes one strategy fits the whole portfolio is usually the one who gets pushed on it.

Route traffic for a specific capability, say the checkout flow, to a new service through a proxy or gateway, while everything else keeps hitting the monolith. Once that slice is proven in production, move to the next capability. Over time the new system grows around the old one until the monolith has nothing left to do.

Database decomposition is the part that actually slows this down. Splitting a table two services both need without breaking either one usually needs a dual-write or change-data-capture step in between, and that intermediate state is where most strangler migrations quietly stall for months.

Terraform wins on multi-cloud and has the largest provider ecosystem, which matters the moment you're not purely single-vendor. CloudFormation has deeper native integration with new AWS services on day one, since it ships from the same team, and no separate state file to manage. Pulumi lets you write infrastructure in a real programming language, which helps teams share logic and tests between application code and infrastructure code, at the cost of a steeper learning curve for anyone who isn't already writing that language.

For an AWS-only shop with no near-term multi-cloud plan, I'd lean CloudFormation before Terraform, and I know that's not the popular answer in most prep guides.

State is a file mapping the resources in your code to the real cloud resource IDs they correspond to, how Terraform knows what already exists versus what needs creating or changing on the next apply. Local state works fine for one person on one laptop and breaks the moment a second engineer runs apply against the same infrastructure. Without a lock, two applies can read the same state, calculate conflicting plans, and write over each other, corrupting the file or silently reverting someone's change.

terraform {
 backend "s3" {
  bucket     = "company-terraform-state"
  key      = "prod/network/terraform.tfstate"
  region     = "us-east-1"
  dynamodb_table = "terraform-locks"
  encrypt    = true
 }
}

TCO spreadsheets are the easy part, and usually the wrong first filter. Data sovereignty constraints decide more hybrid decisions than cost does: a GDPR Article 17 right-to-erasure obligation, a regulator that wants specific data physically inside a border, or a latency-sensitive workload sitting next to equipment that can't move. Those constraints are non-negotiable in a way a cost delta usually isn't.

Once the constraints are mapped, hybrid makes sense for exactly the workloads that hit one, and full public cloud is almost always the better default for everything else. Keeping a workload on-prem out of habit rather than a real constraint is the failure mode interviewers are listening for.

`terraform plan` on a schedule (a nightly CI job is common) catches drift by comparing real cloud state against what the code says should exist. When it finds a difference, you've got two honest options: update the code to match reality if the manual change was legitimate, or run apply to revert it if it wasn't. What you shouldn't do is ignore it, because drift compounds, the next apply from someone who doesn't know about the manual change can produce a plan nobody expects.

Restricting console access through IAM policy is the actual fix, not the detection job. Detecting drift after the fact is a safety net, not a strategy.

During a network partition you get to keep either consistency (every read sees the latest write) or availability (every request gets a response), not both. Most systems aren't choosing CP or AP in the abstract, they're choosing per operation. DynamoDB Global Tables and Cosmos DB default to eventual consistency for cross-region reads because global synchronous consistency at that latency budget isn't realistic, while Aurora Global Database offers a synchronous mode specifically because some workloads need it and are willing to pay the latency.

The mistake candidates make is treating this as a one-time architectural decision instead of a per-data-type one. A single system can, and usually should, mix strong consistency for the parts that need it with eventual consistency everywhere else.

Multi-cloud increases operational complexity faster than it reduces vendor lock-in for most teams under roughly 200 engineers. Every additional provider means a second IAM model, a second observability stack (or a third-party layer trying to unify two incompatible ones), and a second on-call runbook, and that tax gets paid every single day, not just during the rare event a full provider outage would actually justify it for.

Multi-cloud earns its cost in narrower cases: a genuine regulatory requirement for provider diversity, a best-of-breed service only one provider offers well, or an acquisition that inherited a second cloud where migrating everything off it costs more than running two. Picking multi-cloud as a default hedge against a provider outage that might happen once a decade is usually the wrong trade for a team that size.

GDPR doesn't strictly require EU data to stay on EU soil in every case, but Article 17's right-to-erasure obligation, plus the stricter interpretations several EU regulators have taken since Schrems II, push a lot of teams toward EU-region-only storage and processing anyway, since it removes an entire category of legal argument about cross-border transfer mechanisms. Pick a region (eu-west-1, eu-central-1, whichever the provider's EU footprint offers) and keep both primary storage and backups inside it.

The part candidates miss: logging and observability pipelines often ship data cross-region by default, and a compliant primary architecture with an app log stream quietly flowing to a US-region log aggregator is a real, common miss, not a hypothetical one.

There's no managed cross-cloud database that gives you the same guarantees a single-provider global table does, so you're usually building it yourself. Event streaming (Kafka, or a managed equivalent per cloud feeding a shared topic) with idempotent consumers on each side is the common pattern, each provider's database becomes an eventually-consistent replica of the event log rather than a source of truth in its own right.

Distributed transaction protocols like two-phase commit exist but rarely show up in production multi-cloud systems, the latency and the coordinator-as-single-point-of-failure problem outweigh the benefit for almost every workload that would otherwise reach for it. Saga patterns with compensating transactions are the more common real answer when a true multi-step transaction is genuinely needed.

User latency matters, but it's rarely the only constraint. Data residency rules out regions outright for some workloads. Service availability varies by region, a newer region sometimes launches without every managed service the architecture needs, so check the provider's regional service list before designing around it. Pricing differs by region too, sometimes by a meaningful margin for compute-heavy workloads.

Within a region, spread across at least 3 availability zones for anything that needs real availability. Two AZs still leaves you exposed to a single AZ failure taking out half your capacity at the worst possible moment, which has actually happened to major providers, not just a theoretical risk from a whitepaper.

Start from zero permissions and add only what a role actually needs to do its job, not what might be convenient someday. Time-bound elevated access instead of granting it permanently, a role that needs admin for a migration gets it for the migration window, not forever. Automated access reviews catch the permissions nobody remembers granting six months later, which is where most real-world over-privilege actually accumulates.

{
 "Version": "2012-10-17",
 "Statement": [
  {
   "Effect": "Allow",
   "Action": ["s3:GetObject"],
   "Resource": "arn:aws:s3:::app-uploads/${aws:PrincipalTag/team}/*",
   "Condition": {
    "StringEquals": { "aws:PrincipalTag/team": "billing" }
   }
  }
 ]
}

Break-glass emergency access needs to exist too, a documented, logged, time-limited path to elevated access for genuine incidents, because a least-privilege model with no emergency path just means someone routes around it during an actual outage, usually badly.

Role-based access control assigns permissions to named roles (admin, billing-viewer, deploy-bot) and users get roles. It's simple to reason about and simple to audit, until the number of roles needed to express every real-world combination of team, environment, and resource starts multiplying faster than anyone can maintain.

Attribute-based access control evaluates policy against attributes (team, environment, resource tag) at request time instead of a fixed role list, which scales better for large, fast-changing orgs but is genuinely harder to audit, since the effective permission for any request depends on attribute state at that moment rather than a static role assignment you can read off a list. Most enterprises end up with a hybrid: RBAC for broad access tiers, ABAC for the fine-grained resource-level rules layered on top.

A centralized secrets manager (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) instead of secrets baked into environment variables or, worse, committed to a repo at some point in its history. Services fetch secrets at runtime through an authenticated API call, and short-lived credentials with automatic rotation mean a leaked secret has a small window instead of an indefinite one.

The part that actually breaks in practice: rotating a database credential without a brief connection blast radius requires the app to gracefully pick up the new credential, a dual-credential window where both old and new work briefly, rather than a hard cutover that drops every open connection at the rotation instant.

Isolate it behind a proxy or gateway that speaks zero-trust protocols outward and whatever the legacy service actually supports inward. The proxy terminates mTLS and workload identity verification, then talks to the legacy service over a tightly scoped, network-segmented path that nothing else can reach directly.

Treat this as a bridge, not a permanent architecture. Every legacy exception is a place where the zero-trust guarantee doesn't actually hold, and a candidate who presents the proxy as the final state rather than a step toward retiring the legacy service is missing the point the interviewer is checking for.

PCI-DSS drives real architectural boundaries, cardholder data has to live in a segmented environment with its own access controls, and that segmentation often becomes the reason a company runs a separate account or VPC just for payment processing rather than one flat network. HIPAA's audit-logging requirement means every access to protected health information needs an immutable, queryable log, which shapes logging architecture from day one rather than being bolted on before an audit.

SOC 2 is the loosest of the three in terms of specific technical mandates, it's mostly about demonstrating a consistent, documented process, which is why some architecturally sound systems still fail a SOC 2 audit on process gaps rather than technical ones. Knowing which framework actually constrains the architecture versus which one constrains the paperwork is the signal interviewers are listening for here.

A separate, normally-disabled role with broad permissions that requires an explicit activation step, a second approver, a ticket reference, something that can't happen silently. Every activation triggers an alert to security and generates a permanent audit record, and the access itself expires automatically after a short window instead of relying on someone remembering to revoke it.

The design tension is real: too much friction and someone works around it during an actual 3am outage, too little and it's just a permanent backdoor with extra steps. A reasonable middle ground is a role any on-call engineer can self-activate immediately but that pages a second person and starts a countdown the moment it's used.

Work from coarse to fine. Billing dashboards grouped by service category first, then by tag (team, environment, product) if tagging discipline actually exists, then into the specific service and resource once you've narrowed it that far. Jumping straight to guessing which service is the culprit wastes more time than the systematic pass does.

The usual suspects, roughly in order of how often they're actually the answer: an oversized instance left running in a non-prod account nobody's watching, a retry loop multiplying invocations on a serverless function, NAT Gateway data-processing charges from a job moving far more data than expected, or a lifecycle policy on object storage that never actually got applied.

Reserved Instances and Savings Plans both trade a 1 or 3-year commitment for a discount, up to roughly 70% off on-demand pricing at 3 years, and are the right choice for stable, predictable baseline load, the part of your fleet running at 2am on a Sunday just as much as 2pm on a Tuesday. Savings Plans are more flexible across instance families and regions; Reserved Instances can go slightly deeper on discount for a workload that genuinely won't change shape.

Spot instances are 60 to 90% cheaper but can be reclaimed with roughly a two-minute warning, which makes them a fit for fault-tolerant, interruptible work, batch jobs, CI runners, stateless workers behind a queue, not anything holding user-facing state. A well-optimized fleet usually blends all three: commitments for the floor, spot for the elastic and interruptible part, on-demand for the unpredictable remainder.

NAT Gateway charges per hour it exists plus per gigabyte processed, and that per-gigabyte charge is the part that surprises people, since it applies to every byte flowing through it regardless of destination. A job moving large volumes of data through a NAT Gateway to reach another AWS service can rack up charges that dwarf the compute cost of the job itself.

VPC endpoints, gateway endpoints for S3 and DynamoDB, interface endpoints for most other AWS services, route that traffic privately without touching the NAT Gateway at all, and they're usually cheaper for any meaningful volume. The habit worth building: check whether a VPC endpoint exists for a service before assuming its traffic has to go through NAT.

A planned exercise where you deliberately break something in a controlled way, kill an instance, inject network latency, fail over a database, and watch whether the system, and the on-call team, responds the way the runbook says it should. Tools like Gremlin or AWS Fault Injection Simulator handle the injection; the value is in what breaks that the runbook didn't account for.

A good game day tests the people and the process as much as the system. Does the on-call engineer know which dashboard to check first? Does the alert actually fire, and does it fire in time to matter? A system that survives the technical failure but where the team fumbles the response for 20 minutes has found a real gap, even though nothing in the architecture diagram was technically wrong.

Multi-AZ protects against the failure modes that are actually common: a single data center losing power, a hardware failure, a network partition inside one zone. It's cheaper, lower-latency between components, and covers the overwhelming majority of real incidents most teams will ever face.

Multi-region protects against a full-region outage, rare but not hypothetical, cloud providers have had multi-hour, multi-service regional outages, and against a regulatory requirement for geographic redundancy that multi-AZ can't satisfy since all AZs in a region sit in roughly the same geography. The honest answer for most workloads: multi-AZ by default, multi-region only when a specific requirement justifies the added cost and complexity.

Almost always a cooldown period that's too short relative to how long a new instance actually takes to become useful. The policy scales up, the new instance isn't fully warm and serving traffic yet, the metric that triggered scaling hasn't visibly improved, so the policy scales up again, and once load actually drops the same short cooldown causes it to scale down too aggressively too.

The fix is usually boring: a cooldown long enough to cover instance startup plus warmup time, and a step size that adds meaningful capacity per action instead of one instance at a time when the metric says you need five. Target-tracking policies, holding a metric at a target value rather than reacting to threshold crossings, tend to flap less than simple step-scaling for workloads with a smooth, gradual load curve.

Rate limiting caps how much load one client, or one downstream service, can put on a resource, so one misbehaving caller can't exhaust capacity that every other caller also depends on. A circuit breaker sits on the calling side and stops sending requests to a downstream service once it's clearly unhealthy, failing fast locally instead of piling up threads or connections waiting on a service that isn't going to respond anyway.

Without a circuit breaker, a slow downstream dependency doesn't just get slower, it drags every upstream caller down with it as their thread pools or connection pools fill up waiting, and that's how a single degraded service turns into a full outage across a system that had nothing architecturally wrong with the rest of it.

Interviewers want a specific decision, the actual tradeoff you weighed, and what changed your mind, not a vague "I'd do more research next time." A strong answer names the constraint that made the original call reasonable at the time, a deadline, information you didn't have yet, a scale assumption that turned out wrong, and what you'd change given what you know now.

The follow-up almost always probes whether you actually learned something transferable or just got unlucky once. "We picked DynamoDB and later needed complex joins we hadn't planned for, so now I model access patterns before picking a database, not after" is a stronger answer than one where the lesson doesn't generalize past that one project.

The strongest answers quantify the tradeoff in terms the stakeholder actually cares about, not architecture jargon. "The cheaper option saves $4,000 a month but has a real chance of a multi-hour outage during our highest-revenue week" lands with a business stakeholder in a way "it's not fault-tolerant" doesn't.

Interviewers follow up on what happened when you were wrong, or when the stakeholder said no anyway. Have a real answer for that case, not just the version where your argument won cleanly, since architects who've never lost that argument haven't made very many of them yet.

The honest version of this answer includes what you actually did with the disagreement, not just that you felt it. Did you build the case with data and escalate it, implement it while flagging the risk explicitly in writing, or find a middle path that addressed the mandate's real intent without the specific implementation you disagreed with?

Pure compliance without pushback is a weaker answer than most candidates think, and so is a story where you simply overrode a decision above your level without a resolution. Interviewers are checking whether you can hold a technical position with evidence while still being someone a team can actually work with.

Start by nailing down the consistency requirement per data type, not for the system as a whole. Financial transactions usually need synchronous replication and accept the latency cost that comes with it. User preferences or a shopping cart can tolerate eventual consistency and shouldn't pay that latency tax.

Then design for the failure case explicitly: what happens when the write to us-east-1 succeeds and the replica write to eu-west-1 times out. Queue it and retry, accept a conflict and resolve it later with a defined merge rule, or reject the write and tell the user. Whichever you pick, say it out loud, because an interviewer who doesn't hear an explicit answer here will ask again until they get one.

Mutual TLS between every service, so a service proves its identity on every call instead of trusting anything already inside the network perimeter. OIDC-based workload identity, a pod or function gets a short-lived, auto-rotating identity token instead of a long-lived static credential baked into an environment variable, removes the standing-credential risk that a leaked secret creates.

A service mesh (Istio, Linkerd) or sidecar handles policy enforcement at the network layer so individual services don't each reimplement authentication and authorization. Legacy services that can't speak mTLS natively get isolated behind a proxy that terminates and re-establishes the zero-trust boundary on their behalf, which is usually the messiest part of a real zero-trust rollout, not the greenfield services.

Revoke the credential first, before investigating anything, every minute it stays valid is exposure. Then check CloudTrail (or the equivalent audit log) for what that credential actually did between when it leaked and when you revoked it. Don't assume the blast radius, verify it.

If the credential had broad permissions, rotate everything it could have touched, not just the credential itself, since an attacker with even a few minutes of access could have created a new, less obvious backdoor credential of their own. This is the scenario that makes the case for short-lived, auto-rotating credentials over long-lived access keys concrete instead of theoretical. A leaked role-assumed credential typically expires within the hour on its own; a leaked long-lived key works until someone notices.

Horizontal autoscaling handles a meaningful chunk of it, assuming the scaling policy's cooldown and step size are tuned for a fast ramp, not a policy that adds one instance every 5 minutes while the spike triples every 2. Pre-warmed capacity matters for anything with a slow cold start, a database read replica that takes minutes to spin up won't save you in the first 90 seconds of a spike no matter how good the autoscaling policy is.

Graceful degradation matters as much as scaling does: rate limiting non-critical endpoints, serving a cached or simplified response instead of the full computed one, shedding load intentionally rather than letting every request queue until the whole system falls over. Being honest in the interview matters too, you probably can't fully absorb a genuine 10x spike arriving inside 5 minutes without some visible degradation, and pretending otherwise is a weaker answer than naming what degrades gracefully and what doesn't.

Health checks usually test whether a process is alive and can respond at all, not whether it's responding within an acceptable latency budget, which is exactly the gap that lets this happen. Start with a distributed trace (X-Ray, Jaeger, whatever the stack uses) to find which hop in the request path is actually adding the latency, rather than guessing.

Common causes once you've localized it: connection pool exhaustion on a downstream database forcing requests to queue for a connection, a noisy-neighbor problem on shared infrastructure, garbage collection pauses on a JVM service under memory pressure, or a downstream dependency that's degraded but not fully down, so it's still passing its own health check while adding 800ms to every call through it.

Build once, deploy everywhere, the same container image or artifact gets promoted through every environment regardless of cloud, never rebuilt separately per target. A cloud-agnostic deployment layer, Kubernetes running on each provider's managed offering (EKS, AKS, GKE) with a shared Helm chart or Kustomize overlay, abstracts most of the provider-specific differences at the orchestration layer.

Provider-specific integration, a managed database connection string, a cloud-native secrets store, an IAM role binding, gets isolated into per-environment configuration rather than baked into application code, so the application layer itself stays portable even though the infrastructure underneath genuinely isn't.

A unified metrics and log pipeline is the goal, agents or exporters on every environment (on-prem, both clouds) shipping to a single backend, a self-hosted Prometheus and Grafana stack, a managed vendor like Datadog, or an open-source Grafana/Loki/Tempo combination, rather than three separate dashboards nobody correlates.

Trace context propagation across the boundary is the part that actually breaks in practice: a request touching an on-prem service and a cloud service needs the same trace ID carried across that hop, or your distributed trace stops at the boundary and you've lost the full request path, which defeats most of the point of having traces at all.

Separate accounts per environment at minimum, prod, staging, dev, and usually per major business unit too, so a mistake or a compromised credential in one account can't touch another by default. AWS Organizations (or the Azure and GCP equivalents) with service control policies enforces guardrails centrally, things no account can do regardless of what IAM policy someone writes locally, deleting the CloudTrail log bucket, for instance.

A shared services account holds things every other account needs, centralized logging, a Terraform state backend, a container registry, so you're not duplicating that infrastructure per team. The question interviewers actually probe is the blast-radius one: what's the worst thing that happens if one account gets fully compromised, and does your structure contain it or does it cascade.

Vector clocks or per-region version counters attached to each write let you detect when two writes to the same record happened concurrently, neither aware of the other, versus one write genuinely happening after the other. Last-write-wins by timestamp is the simplest resolution and is fine for data where silently losing a concurrent update is an acceptable cost, a user's last-viewed timestamp, for instance.

For anything where silently dropping a concurrent update actually matters, a shopping cart, an inventory count, resolve with an explicit merge function specific to the data type (union the cart items, sum the inventory delta) instead of picking one write and discarding the other. DynamoDB Global Tables and Cosmos DB both expose conflict resolution hooks for exactly this reason, and a candidate who doesn't know they exist usually reinvents a worse version of them live in the interview.

A 1-minute RPO rules out anything based on periodic snapshots or nightly backups outright, you need near-synchronous replication, something like Aurora Global Database with its typical sub-second cross-region lag, or continuous event streaming to a hot standby that's already processing the same writes in near real time.

A 15-minute RTO means the standby has to already be running, not provisioned from scratch during the incident, warm or hot standby, not cold. Automated failover, health checks driving DNS or a load balancer cutover, instead of a manual runbook, since a human paging through a runbook under pressure rarely hits 15 minutes reliably, especially at 3am.

Separate the data plane from the control plane on purpose. File content replicates across regions asynchronously, eventual consistency is fine here, users mostly tolerate a few seconds of propagation delay for a file that just uploaded. Metadata, filenames, permissions, the directory structure, needs strong consistency, because two users seeing a different answer to "does this file exist" or "who can access it" is a correctness bug, not a minor inconsistency.

A consensus-backed metadata store, something built on Raft or Paxos, or a managed service like Spanner that handles this for you, anchored in one region or a small quorum of regions, with content stored in region-local object storage and replicated asynchronously behind it, is the shape most real systems actually land on.

A managed event bus per cloud, EventBridge on AWS, Pub/Sub on GCP, Event Grid on Azure, feeding into a shared, cloud-agnostic stream, usually Kafka running independently or a managed Kafka-compatible service, since none of the three native event buses talk to each other directly. Schema registry enforcement at the point of ingestion catches a malformed event before it reaches the analytics layer instead of after, which is a much cheaper place to fail.

Idempotent consumers matter more here than in a single-cloud pipeline, because cross-cloud delivery guarantees are weaker, not stronger. Design every consumer to safely process the same event twice without producing a different result, rather than assuming exactly-once delivery across a boundary that spans providers.

Tenant isolation happens at multiple layers, not one. Data isolation through row-level security or per-tenant schema, row-level security scales better for a large number of small tenants, per-tenant schema or database gives stronger isolation for fewer, larger tenants who need it, a regulated enterprise customer, for instance. Compute isolation matters less for most SaaS workloads but becomes real once tenants have wildly different resource footprints, one tenant's batch job shouldn't be able to starve another tenant's real-time requests on shared infrastructure.

The interview signal here is usually the noisy-neighbor question: what stops one tenant from degrading service for every other tenant sharing the same database or compute pool. Resource quotas per tenant, query timeout limits, and connection pool caps per tenant are the concrete answer, not just "we'd monitor it."