Solutions architect interviews — AWS, GCP, Azure, or vendor-side — test system design, cost judgment, customer communication, and increasingly AI workload architecture. These questions recur in both cloud-provider and enterprise SA loops.
Turn this list into a Cloud Solutions Architect prep plan.
1.A customer wants to migrate a monolith to the cloud. Walk me through how you'd approach it.
What a strong answer covers: Resist redesigning immediately: assess first (dependencies, data gravity, compliance, team skills), then pick a migration strategy per workload from the classic ladder — rehost (lift and shift), replatform, refactor — with business drivers deciding, not architectural purity. Strong answers name when lift-and-shift is correct (deadline, data-center exit) and sequence quick wins before hard cores. Ask about the why of the migration before designing anything.
2.Design a highly available web application across availability zones. Where do people overspend?
What a strong answer covers: Cover the standard shape: load balancer across multi-AZ compute, stateless app tier, managed database with replica failover, static assets on object storage + CDN. Then the cost judgment they're testing: multi-region active-active is usually overkill (most businesses need multi-AZ plus backup-restore), NAT gateway data processing surprises people, and over-provisioned databases hide everywhere. Tie availability targets to actual business impact per hour of downtime.
3.A customer's cloud bill doubled in six months with flat traffic. How do you investigate?
What a strong answer covers: Cost-explorer methodology: break down by service, account, and tag to find the movers; usual suspects are data transfer (cross-AZ/region chatter), storage growth without lifecycle policies, forgotten non-prod environments, logging/observability ingestion, and in 2026 GPU instances and LLM API spend. Distinguish rate problems (buy commitments) from usage problems (fix architecture). Deliver findings as ranked savings with effort estimates, not a wall of numbers.
4.How would you architect an enterprise RAG/AI assistant on AWS (or your cloud of choice)?
What a strong answer covers: The 2026 staple. Cover: model access via managed endpoints (Bedrock/Vertex/Azure OpenAI) keeping data in-boundary, document pipeline into a vector-capable store (OpenSearch, pgvector, or managed vector store), access control inherited from source systems — the enterprise-critical detail — private networking throughout, cost controls on token spend, and evaluation/monitoring. Mention the build-vs-buy conversation: managed AI assistant products vs custom, and what tips it.
5.Explain the shared responsibility model and where customers actually get breached.
What a strong answer covers: Provider secures the infrastructure; customer secures configuration, identity, and data. The real-world part: breaches overwhelmingly come from customer-side misconfiguration — public object storage, over-permissive IAM, leaked long-lived credentials, exposed management ports — not provider failures. Strong answers include preventive posture: SCPs/org policies, credential rotation to short-lived roles, and config scanning as guardrails.
6.A customer insists on multi-cloud. How do you advise them?
What a strong answer covers: Test of consultative judgment. Probe the driver: regulatory requirement, acquisition reality, negotiating leverage, or resume-driven architecture. Present the honest tradeoff — multi-cloud doubles operational surface, dilutes discounts, and forces lowest-common-denominator services; genuine needs (data residency, specific service strengths, M&A) justify targeted multi-cloud, not symmetric everything-everywhere. Recommend a primary-cloud strategy with deliberate exceptions and portable layers (Kubernetes, Terraform) only where exit cost genuinely matters.
7.Walk me through designing the network for a multi-account enterprise environment.
What a strong answer covers: Cover: account strategy (workload isolation, blast-radius reduction), hub-and-spoke connectivity (Transit Gateway or equivalent), centralized egress and inspection, private connectivity to on-prem (Direct Connect/VPN with failover), DNS strategy across accounts, and IP address management before it becomes a crisis. Naming IPAM and overlapping-CIDR pain signals real enterprise experience — greenfield designs never mention it.
8.The customer's engineering team disagrees with your recommended architecture. What do you do?
What a strong answer covers: SA loops weight this heavily. Understand their objection fully first — they know constraints you don't; find the shared goal, and bring data (a proof of concept, cost model, or reference case) rather than authority. Know when to yield: if their approach works and they'll own it, their buy-in beats your elegance. Tell a real story where you were partially wrong — pure I-convinced-them stories read as ego.
9.How do you right-size a database choice? A customer asks for the same database they've always used.
What a strong answer covers: Start from access patterns, not familiarity: transactional consistency needs, query shapes, scale trajectory, and operational appetite. Managed relational covers more than people admit; NoSQL earns its place for known key-based access at scale; purpose-built stores (time-series, graph, vector) when the pattern is genuinely specialized. The consultative layer: familiar-and-adequate often beats optimal-and-foreign because the team operates it — say when you'd concede that.
10.Describe a well-architected review you'd run on an unfamiliar workload in two hours.
What a strong answer covers: Show a prioritized method: start with the money and the risk — single points of failure, backup/restore actually tested, security posture (public exposure, IAM hygiene), then cost quick wins, then operational readiness (monitoring, runbooks). Interview the team before reading diagrams; ask 'what pages you at night' and 'what would happen if this AZ died.' Deliver top-5 ranked findings with effort/impact, not a 40-page report.
11.How do you keep technical depth as an SA when you're not hands-on daily?
What a strong answer covers: They're testing for architects who've drifted into slideware. Concrete answers: personal lab projects, building the demos you present, certifications used as forcing functions (not trophies), staying close to one or two services deeply rather than all shallowly, and regular time in customer environments debugging real issues. Name what you built recently — that one detail carries the answer.
12.A customer asks: should we train our own model, fine-tune, or just use APIs? Frame the decision.
What a strong answer covers: The 2026 executive conversation. Framework: use APIs by default (fastest, best quality per dollar at low-to-mid volume); fine-tune open or provider models for narrow high-volume tasks, latency, or style consistency; train from scratch almost never — reserved for foundation-model companies or truly unique data at massive scale. Anchor it in their actual volumes, data advantage, and team capability, and put numbers on the token economics. Warning sign they're testing: a candidate who recommends training because it sounds impressive.
The 12 questions above stay public. Sign in free to unlock all 31, organized by competency and level, with follow-up probes and cross-device practice tracking.
Sign in free to unlock all 31 →
No payment required. Member questions are loaded after authentication and are not included in this public page.
Signed-in question bank
All 31 questions are unlocked.
The 12 public questions remain above. Use these 19 deeper prompts to cover incidents, tradeoffs, and project judgment. Sync stores only question IDs and practiced/saved flags for about 13 months after the last change.
Comparing adjacent roles?
See where the ownership, daily work, and interview signals split before you commit to a prep path.