A candidate I spoke with last year described bombing a Principal Cloud Architect loop at a large financial services firm. He’d memorized every AWS service acronym in existence. He could recite RTO and RPO definitions verbatim. But when the panel asked him to justify a multi-region active-active design over active-passive, given a specific cost ceiling, he froze. He hadn’t thought about the tradeoff. He’d thought about the pattern.<\/p>\n
That gap – between knowing cloud patterns and reasoning about cloud tradeoffs – is exactly what senior interview panels probe for. The BLS projects 12% employment growth for computer network architects through 2034<\/a>, with roughly 11,200 openings per year. Below are the 15 questions separating offers from close-but-no-thanks rejections, with the reasoning interviewers want to hear.<\/p>\n A note on how LastRound AI users prep for architecture rounds<\/p>\n Teams using LastRound AI’s mock interview mode<\/a> for system design say the hardest part isn’t knowing the right answer – it’s articulating the tradeoff clearly under time pressure. The AI copilot surfaces follow-up questions an interviewer would actually ask, so candidates practice reasoning out loud.<\/p>\n<\/div>\n<\/div>\n Interviewers aren’t testing vocabulary. They want to know if you reason from constraints. Start with the team’s operational maturity, not the feature list. If your team has two ops engineers and a tight release schedule, running your own Kubernetes cluster on IaaS probably costs more than it saves compared to a managed PaaS option. Pick a real scenario – a stateful batch job that needs GPU access, say – and walk through why IaaS might win there even if PaaS wins for the API layer.<\/p>\n The dangerous answer is a confident description of the happy path: traffic routing, data replication, health checks. Interviewers want you to break it yourself. What happens when replication lag between regions hits 800ms during a write-heavy spike? Do you accept stale reads? Block writes? The answer that earns points: “I’d nail down the consistency requirement for each data type. Financial transactions need synchronous replication and accept the latency cost. User preference data can tolerate eventual consistency. That split drives different replication choices for different parts of the schema.”<\/p>\n Most candidates jump to TCO spreadsheets. That’s incomplete. Data sovereignty often forces the hybrid hand regardless of economics. GDPR Article 17 right-to-erasure obligations may require on-prem processing for certain EU customer records even if the rest of the stack runs on AWS. Lead with “what constraints aren’t negotiable?” before you build the cost model.<\/p>\n CAP theorem is table stakes. The better answer: pick your consistency model first – strong, eventual, or causal – then work backwards to the mechanism. For strong consistency across providers you’re looking at distributed transaction protocols or consensus algorithms like Raft, and the latency cost is real. Acceptable for financial ledgers. Totally unacceptable for a user activity feed. One thing I genuinely don’t know how to answer confidently: at what point does cross-provider network latency make active-active consistency untenable for sub-100ms SLAs. I’d run the actual numbers before committing to a design.<\/p>\n Most candidates answer only the pro side. The honest answer: multi-cloud increases operational complexity faster than it reduces vendor lock-in for teams under 200 engineers. Two sets of IAM policies, two Terraform providers, two monitoring stacks. The 2025 Stack Overflow Developer Survey shows AWS at 43.3% adoption, Azure at 26.3%, GCP at 24.6%<\/a> – but these platforms are diverging on AI-native services faster than abstraction layers can keep up. Multi-cloud makes sense for geographic compliance or price negotiation. Not for genuine redundancy in most cases.<\/p>\n Zero-trust means “never trust, always verify” at every request boundary. The implementation: mutual TLS between services, short-lived credentials via OIDC workload identity (not long-lived service account keys), policy enforcement at the sidecar or service mesh layer, continuous authorization rather than session-based trust. The follow-up interviewers love: “How do you handle a legacy service that can’t support mTLS?” Isolate it behind a proxy that handles authentication and treats the legacy service as an untrusted external endpoint. Don’t pretend the problem doesn’t exist.<\/p>\n Least privilege is expected. What earns points: time-bounded access for privileged operations, automated access reviews triggered by role-change events, break-glass emergency access with full audit logging and automatic expiration. The thing that gets skipped: service-to-service identity. Applications don’t have humans behind them. They need workload identities with narrow scope, not human credentials shared as environment variables.<\/p>\n Work from coarse to fine: billing dashboards by service category first, then by tag (team\/environment\/product), then into the specific service. Common culprits: forgotten dev environments, unexpected cross-region data transfer fees, autoscaling groups that didn’t scale back after a load test. The senior-level answer: describe building tag enforcement policy so the next spike takes minutes to trace, not hours.<\/p>\n Serverless is optimized for intermittent, event-driven, stateless work with unpredictable traffic. Containers are better for long-running processes, stateful workloads, or anything needing sub-100ms cold start. The economics invert at sustained high volume – Lambda at very high throughput often costs significantly more than an equivalent reserved container instance. The CNCF’s 2025 survey found 82% of container users now run Kubernetes in production<\/a>, up from 66% in 2023. Do the math with real traffic projections before you pick.<\/p>\n 1-minute RPO means near-synchronous replication – Aurora Global Database with synchronous writes, or event streaming to a hot standby. 15-minute RTO means automated failover, not a manual runbook. Warm standby with pre-provisioned capacity and automated DNS cutover is the minimum. Pilot light won’t make the window unless ramp-up is fully scripted. And then test it. Monthly.<\/p>\n Horizontal autoscaling on stateless tiers, pre-warmed capacity for slow-initializing services (JVM apps, large model inference), rate limiting at the API gateway, and a graceful degradation plan for when scaling can’t absorb the spike in time. The honest answer: you probably can’t fully absorb a 10x spike arriving in under 5 minutes. Load testing to 3x your expected peak and having a playbook for the gap is more realistic than promising infinite elasticity.<\/p>\n Terraform wins on multi-cloud scenarios – you can manage DNS, cloud infrastructure, and Kubernetes objects in a single declarative layer. CloudFormation wins on deep AWS service integration for AWS-only shops who want minimal operational overhead. The Terraform gotcha most candidates undersell: state file management is a real problem at scale. Who owns the state lock? What happens when state diverges from reality? You need a story for state backends, remote state locking, and workspace isolation before you have a production-grade setup.<\/p>\n Strangler fig pattern is the right answer – extract capabilities incrementally, routing traffic to new services while the monolith handles the rest. What the explanation usually skips: database decomposition is the hard part. You can run two services in parallel relatively easily. Running two services that share a single database schema is a trap – you get microservices complexity with none of the independent deployability. Data separation needs to happen before or alongside service extraction, not after.<\/p>\n A pattern holds across all 13 questions above: candidates who get offers explain their reasoning before their answer. Not “use Aurora Global Database for DR” but “for a 1-minute RPO you need near-synchronous replication, which points to Aurora Global Database, and here’s the write latency tradeoff you’re accepting.” The answer is downstream of the reasoning.<\/p>\n If you want structured practice on system design, the system design interview guide<\/a> covers the end-to-end framework most senior panels use. And the LastRound AI interview copilot<\/a> pushes back on your answers the way a real interviewer does – the gap that solo prep consistently misses.<\/p>\nCloud fundamentals and strategy<\/h2>\n
1. How do you decide between IaaS, PaaS, and SaaS for a new workload?<\/h3>\n
2. Walk me through designing a multi-region active-active architecture.<\/h3>\n
3. How do you evaluate a hybrid cloud vs. full public cloud migration?<\/h3>\n
Multi-cloud and consistency tradeoffs<\/h2>\n
4. How do you maintain data consistency across cloud providers?<\/h3>\n
5. When does a multi-cloud strategy hurt more than it helps?<\/h3>\n
Security and zero trust<\/h2>\n
6. How would you implement zero-trust in a cloud-native environment?<\/h3>\n
7. Walk me through IAM best practices for a large enterprise deployment.<\/h3>\n
Cost optimization<\/h2>\n
8. How do you investigate an unexpected 40% spike in cloud spend?<\/h3>\n
9. Serverless vs. containers – how do you make the call?<\/h3>\n
High availability and disaster recovery<\/h2>\n
10. Design a DR strategy with a 15-minute RTO and 1-minute RPO.<\/h3>\n
11. How do you handle a 10x traffic spike you didn’t predict?<\/h3>\n
Infrastructure as code and migration<\/h2>\n
12. Terraform vs. CloudFormation – which and when?<\/h3>\n
13. How do you migrate a legacy monolith to cloud-native without downtime?<\/h3>\n
What makes the difference in senior rounds<\/h2>\n