Top 50 Solutions Architect Interview Questions 2026

Top 50 Solutions Architect Interview Questions 2026

"Solutions architect" covers two jobs that share a title. The pre-sales SA sits next to an account executive, runs discovery calls, whiteboards with the customer's engineers, builds demos and proofs of concept, and writes the architecture section of a proposal. The delivery or cloud SA sits inside a project or a platform team and owns the design that actually gets built - migrations, landing zones, DR, cost. Most loops for either role cover both halves, because the best pre-sales SAs can defend a design under questioning and the best delivery SAs can explain it to a CFO.

What the interviewer is really testing is judgement under incomplete information. Anyone can recite the six Well-Architected pillars. The signal is whether you ask what the RTO is before proposing multi-region active-active, whether you can say "no" to a customer without losing the deal, and whether your cost estimate survives the first follow-up. The 50 questions below escalate from discovery fundamentals through the technical core to the whiteboard scenarios and the behavioral round that close most loops.

Practice alongside this post. The technical half is drilled as timed multiple-choice in the cloud architecture question bank and the system design question bank, with the system design trade-offs cheat sheet as your reference. If you want a structured track, pick your cloud: AWS solutions architect, Azure solutions architect or GCP solutions architect, or the vendor-neutral cloud architect prep. For the provider-specific service questions, the sibling posts are Top 50 AWS interview questions, Top 50 Azure interview questions and Top 50 GCP interview questions.

Part 1: The role and discovery (1-6)

1. What does a solutions architect actually do, and how is it different from a software architect or a cloud engineer?

A solutions architect maps a business problem to a technical solution that can be delivered within a budget, a timeline and a set of constraints the customer often has not written down. A software architect usually owns the internal structure of one system - module boundaries, data model, code-level patterns. A cloud engineer builds and operates the infrastructure. The SA sits between the business and those people: they decide which services, which integration points, which trade-offs, and they write it down so someone else can build it.

In pre-sales, add a commercial dimension: the SA has to make the solution credible enough to win, and honest enough that delivery does not inherit a promise it cannot keep. A good answer names both sides - "I am accountable for the design being right and for the customer understanding why it is right."

2. Walk me through how you run a discovery call.

Start with outcomes, not technology. A structure that works:

1. Why now? What changed - a contract renewal, a data center exit, an outage, a new product line. The trigger tells you the real deadline.
2. What does success look like, and how is it measured? Revenue, cost, latency, compliance pass, headcount freed.
3. Current state. Systems, volumes, integrations, who owns what, what hurts.
4. Constraints. Budget range, compliance regimes, data residency, existing contracts and licensing, skills on the team, timeline.
5. Stakeholders and decision process. Who signs, who can veto (security, procurement), who will run it afterwards.
6. Non-functionals. Availability target, RPO/RTO, peak load, growth.

Close by playing back what you heard and agreeing the next step. The follow-up interviewers like: "What do you do when the person on the call cannot answer the non-functional questions?" Answer: write down an assumption, flag it as one in the proposal, and name who has to confirm it.

3. How do you distinguish a requirement from a solution the customer has already picked?

"We need Kubernetes" is a solution. The requirement underneath might be "deploy many small services independently," "avoid lock-in," or "the new CTO likes it." Ask "what would that let you do that you cannot do today?" until you hit a business outcome. Then evaluate the stated solution against that outcome along with one or two alternatives.

This matters because the cheapest, fastest or most operable answer is often not the one the customer walked in with. You do not have to talk them out of it, but you do have to know whether you are designing for a goal or for a preference, and say which in the design doc.

4. What non-functional requirements do you always ask about?

Availability target (and what "down" means to them), RPO and RTO, latency at a named percentile, peak and average throughput, data volume and growth, retention, security and compliance regimes (PCI DSS, HIPAA, SOC 2, GDPR, sector-specific rules), data residency, operability (who is on call, what skills they have), and cost ceiling.

The gotcha is that customers say "99.999%" and "zero data loss" by reflex. Translate those into money: five nines is roughly five minutes of downtime a year, which usually means multi-region active-active and a team that can operate it. Ask what an hour of downtime actually costs them. That number sets the budget for availability.

5. How do you handle a stakeholder group that disagrees about priorities?

Make the disagreement explicit and put it on paper. List the competing goals (for example security wants private connectivity only, the business wants a launch in six weeks), the options, and the cost of each in time and money. Then take it to whoever owns the decision, usually the executive sponsor identified in discovery.

What you should not do is quietly design for the loudest voice. A decision record ("we chose X over Y because Z, owner: name, date") is the SA's best tool here; it ends the relitigating and protects the delivery team later.

6. What artifacts do you produce after discovery?

Typically: a requirements summary with assumptions and open questions; a current-state diagram; a target architecture at context and container level; a decision log; a risk register; a rough cost estimate with its assumptions; and a phased plan. In pre-sales, these feed the proposal and SOW. In delivery, they become the design baseline that change requests are measured against.

Part 2: From business goals to architecture (7-11)

7. How do you translate a business goal into architecture decisions?

Turn each goal into a measurable quality attribute, then into a design choice. For example:

The interviewer is checking that you can walk the chain in both directions - from a diagram box back to the business reason it exists.

8. What are the pillars of the AWS Well-Architected Framework?

Six: operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability. Sustainability was added in late 2021, so an answer that lists five is dated. Azure's Well-Architected Framework uses five pillars (reliability, security, cost optimization, operational excellence, performance efficiency), and Google Cloud publishes its own Well-Architected Framework covering similar ground.

The follow-up is always "how do you use it?" The answer: as a structured review, not a checklist to recite. Run it against a workload, record the high-risk items, and prioritise them with the owner. On AWS the Well-Architected Tool records reviews and tracks improvement plans, and lenses (serverless, SaaS, generative AI and others) add domain-specific questions.

9. Which pillars trade off against each other most often?

Reliability against cost is the classic one: every extra AZ, region or standby copy costs money. Security against operational speed is another: private networking, approval gates and key separation slow down delivery. Performance against cost shows up in provisioned capacity versus on-demand. Sustainability usually aligns with cost (fewer idle resources) but can conflict with reliability when the reliable answer is "keep spare capacity running."

A strong answer names the trade-off for this workload and who agreed to it, for example: "Internal reporting tool, RTO of a day is fine, so single region with backups and we spend the difference on better access control."

10. How do you decide between managed services and self-managed?

Default to managed when the service meets the requirements, because it shifts undifferentiated operations (patching, failover, backups, scaling) to the provider. Choose self-managed when you need a capability the managed service lacks, a specific version or extension, portability that is a hard requirement rather than a preference, or when at very large steady scale the operating cost is lower and the team can actually run it.

The gotcha: total cost of ownership includes the engineers. A self-run database cluster that looks cheaper on the bill often is not once you price the on-call rotation and the upgrade projects.

11. When do you recommend serverless, containers or VMs?

Most real estates are a mix. Say what drives the choice for this workload (traffic shape, team skills, runtime) rather than declaring one the winner.

Part 3: Migration (12-15)

12. What are the 7 Rs of migration?

AWS's prescriptive guidance lists seven strategies:

• Retire - decommission it; no business value in moving it.
• Retain - keep it where it is for now (compliance, dependencies, recently upgraded, waiting for a SaaS version).
• Rehost - lift and shift, no application changes.
• Relocate - move a whole platform without changing it, for example VMware workloads to VMware Cloud on AWS.
• Repurchase - replace with a different product, usually SaaS.
• Replatform - lift, tinker and shift: small optimisations such as moving to a managed database, without changing core architecture.
• Refactor or re-architect - change the application significantly to use cloud-native capabilities.

The follow-up: which ones dominate a large migration? AWS's own guidance favours rehost, replatform, relocate and retire for large programmes, and recommends modernising after the move rather than refactoring during it.

13. How do you decide the strategy for each application in a portfolio?

Run a portfolio assessment: discover the inventory and dependencies (agent-based or agentless discovery tooling, CMDB, interviews), then score each application on business value, technical fit, risk and effort. Low-value, low-use applications go to retire. Applications with compliance blockers or hardware dependencies go to retain. Commodity functions with good SaaS options go to repurchase. Most of the rest rehost or replatform, and a short list of strategic applications earns refactoring.

Group applications into waves by dependency, not by team. Moving an application without the database it talks to on every request creates a latency problem across the hybrid link.

14. What makes a migration fail?

Common causes: undiscovered dependencies (a hardcoded IP, a nightly file drop, a licence server); underestimated data transfer time; licensing terms that do not permit the new deployment model; no rollback plan; cutover windows planned without the business; and treating "moved" as "done" so costs climb because nothing was rightsized afterwards.

A good answer includes how you de-risk: a pilot wave with low-risk applications to prove the factory, rehearsed cutovers, explicit rollback criteria, and a post-migration optimisation phase that is in the plan and the budget from day one.

15. How do you migrate a large database with minimal downtime?

Use a full load followed by change data capture (CDC). The pattern: take an initial copy, start continuous replication of changes from the source, let the target catch up, validate row counts and checksums, then cut over in a short window by stopping writes, letting replication drain, and switching the application's connection string. On AWS, Database Migration Service handles full load plus CDC, and the Schema Conversion Tool helps with heterogeneous moves (for example Oracle to PostgreSQL).

Follow-ups: what about very large datasets over a thin network link? Consider offline transfer devices for the bulk load and CDC for the delta. And heterogeneous migrations need application testing, not just data validation, because stored procedures and data type semantics differ.

Part 4: High availability and disaster recovery (16-20)

16. Define RPO and RTO and explain how they drive design.

RPO (recovery point objective) is the maximum acceptable data loss, measured in time - "we can lose at most 5 minutes of writes." RTO (recovery time objective) is the maximum acceptable time to restore service. RPO drives your replication and backup design (nightly backups give an RPO measured in hours; synchronous replication approaches zero). RTO drives how much infrastructure is pre-provisioned and how automated recovery is.

Set them per workload with the business, based on the cost of downtime and data loss. Then design the cheapest strategy that meets them. Over-delivering on RPO/RTO is a cost problem, not a virtue.

17. Compare backup and restore, pilot light, warm standby and multi-site active-active.

The AWS reliability pillar lists these in order of increasing cost and complexity and decreasing RTO and RPO:

The precise distinction interviewers want: pilot light cannot serve requests until you take action (start or deploy servers, then scale), while warm standby can take traffic immediately at reduced capacity and only needs to scale up. A warm standby scaled to full size is called hot standby.

18. What is the difference between high availability and disaster recovery?

High availability keeps a workload running through common, localised failures - an instance, a disk, an Availability Zone - usually automatically and with no data loss, by spreading across AZs behind a load balancer with a multi-AZ database. Disaster recovery restores the workload after a larger event that takes out the primary location or corrupts data, usually to another region, with defined RPO/RTO.

The gotcha: replication is not backup. Active-active replication faithfully copies a bad deploy or a ransomware encryption to every region. You still need point-in-time recovery and immutable or logically separated backups.

19. How would you implement multi-region failover for a web application on AWS?

DNS-level routing with health checks (Route 53 failover or latency routing), or Amazon Application Recovery Controller for controlled, data-plane-based failover. Data replication depends on the store: Aurora Global Database for relational data, DynamoDB global tables for key-value, S3 replication for objects. Infrastructure in the recovery region is defined in the same IaC as primary so it does not drift.

The detail that separates candidates: avoid depending on control-plane operations during recovery. Creating resources or changing configuration in the middle of a regional event is exactly when those APIs may be impaired. Pre-provision what you need, and make failover a data-plane action like flipping a routing control or a health check.

20. How do you know your DR plan works?

You test it. Scheduled game days that fail over a real workload, measure actual RPO and RTO against targets, and record the gaps. Automate the runbook so recovery does not depend on whoever is on call remembering steps. Track configuration drift between primary and recovery environments, and check quotas in the recovery region - a standby that cannot scale because of a service quota is a common silent failure.

Part 5: Cost optimization (21-23)

21. A customer's cloud bill doubled in six months. Where do you start?

Get visibility before acting: break the bill down by service, account and cost-allocation tag (Cost Explorer on AWS, Cost Management on Azure, billing reports on GCP). Find the top few line items - usually they are most of the growth. Then look for the usual suspects: idle or oversized compute, unattached volumes and old snapshots, data transfer (cross-AZ, cross-region, NAT gateway processing), logging volume, non-production environments running 24/7, and storage that never moved to a cheaper tier.

Then fix the process, not just the bill: tagging policy enforced at creation, budgets and anomaly alerts per team, and a monthly review owned by someone. The interviewer wants to see you separate quick wins from structural causes.

22. How do you choose between on-demand, commitments and spot capacity?

Cover the steady baseline with commitments (Savings Plans or Reserved Instances on AWS, reservations and savings plans on Azure, committed use discounts on GCP); leave variable load on demand; put interruption-tolerant work (batch, CI, stateless workers, some training jobs) on spot or preemptible capacity. On AWS, Compute Savings Plans apply across EC2, Fargate and Lambda, which makes them a safer first commitment than instance-specific options.

The gotcha: commit after rightsizing, not before. Committing to an oversized fleet locks in the waste. Size commitments to the floor of usage over recent months, not the average.

23. How do you present cost to a customer during a sale?

Give a range with stated assumptions, not a single number. Break it into fixed (baseline infrastructure, support) and variable (per user, per request, per GB) components so the customer can see how it scales. Use the provider's pricing calculator and save the estimate so it can be audited later. Call out the items that are hardest to predict: data transfer, logging, and for GenAI workloads, tokens.

Part 6: Security and identity (24-27)

24. Explain the shared responsibility model and where customers get it wrong.

The provider secures the cloud itself - physical facilities, hardware, the hypervisor, the managed service internals. The customer secures what they put in it - identity and access, data classification and encryption choices, network configuration, OS patching on VMs, application code. The split shifts with the service model: on a VM you own the OS; on a managed database you own access, network exposure and data, but not the engine patching.

Where customers get it wrong: assuming "managed" means "secured," leaving storage buckets or databases publicly reachable, and over-privileged IAM roles. Most cloud breaches trace back to customer-side misconfiguration and credentials, not the provider.

25. How do you design identity and access for a multi-account organization?

On AWS: AWS Organizations with accounts per environment and workload; IAM Identity Center federated to the corporate identity provider so humans use short-lived credentials and no long-lived IAM users; roles for workloads; service control policies (SCPs) as guardrails on what any principal in an account can do; resource control policies to set a maximum on what can be done to resources; permission boundaries for delegated role creation. A dedicated log archive and security tooling account receives CloudTrail and findings from every account.

Azure's equivalents are management groups, Microsoft Entra ID, Azure RBAC and Azure Policy; Google Cloud uses the resource hierarchy, IAM and organization policies. The principle is the same everywhere: central identity, least privilege, guardrails that cannot be removed by account admins.

26. How do you approach encryption and key management?

Encrypt at rest by default (most managed services do) and in transit with TLS everywhere, including internal traffic where compliance requires it. The design decision is key ownership: provider-managed keys are simplest; customer-managed keys in KMS or Key Vault give you control over rotation, key policy and the ability to revoke access by disabling the key; external or hardware-backed key stores serve regulated customers who must hold key material outside the provider.

The interviewer's follow-up is usually about separation of duties: the people who administer keys should not be the people who read the data, and key policies should be part of that design.

27. A customer insists their data must never leave their country. What do you check?

Which regions exist in-country and which services are available there (not every service is in every region); where backups, replicas and logs go; whether any managed service processes data outside the region (support access, global control planes, some AI services with cross-region inference); and whether the requirement is legal residency, sovereignty (control over who can be compelled to access it), or a preference. Then enforce it: guardrail policies that deny resource creation outside approved regions, and documentation the customer's compliance team can audit.

Part 7: Data architecture and integration (28-32)

28. How do you choose a database for a new workload?

Start from access patterns, not from a favourite engine:

The follow-up: "the team only knows Postgres." That is a legitimate constraint - Postgres covers a remarkable range, and a slightly worse fit the team can operate often beats a perfect fit they cannot.

29. Data lake, data warehouse or lakehouse - how do you advise?

A warehouse stores structured, modelled data optimised for SQL analytics and BI. A data lake stores raw data of any shape cheaply in object storage, with schema applied on read. A lakehouse puts open table formats (Apache Iceberg, Delta Lake, Hudi) on the lake so you get transactions, schema evolution and warehouse-style queries over object storage.

Advice depends on the consumers. Mostly BI dashboards on known data: a warehouse is simplest. Data science, varied formats, multiple engines reading the same data: lake or lakehouse. Many customers end up with both, so the real design question is governance - one catalogue, one access-control model, one definition of each metric.

30. When do you use synchronous APIs versus asynchronous messaging?

Synchronous request-response (REST, gRPC) when the caller needs the answer to continue and the callee is reliably fast. Asynchronous messaging when the work can complete later, when you need to absorb spikes, or when the downstream system is slow or unreliable. Queues decouple availability: the producer keeps working while the consumer is down.

The gotcha: async moves complexity into idempotency, ordering and retries. Consumers must handle duplicates (most queues deliver at least once), and you need dead-letter queues and alerting on them, or failed messages disappear silently.

31. Compare queues, pub/sub and event buses.

• Queue (SQS, Azure Queue Storage / Service Bus queues, Cloud Tasks): one message, one consumer group; good for work distribution and buffering.
• Pub/sub topic (SNS, Service Bus topics, Google Pub/Sub): one message fans out to many subscribers.
• Event bus (EventBridge, Event Grid, Eventarc): routes events by content rules to many targets, often across services and accounts, and integrates SaaS sources.
• Stream (Kinesis, Event Hubs, Kafka / MSK): ordered, replayable log per partition for high-throughput consumers that keep their own position.

A common pattern is SNS-to-SQS fan-out: publish once, give each consuming service its own queue so a slow consumer does not affect the others. For multi-step business processes, an orchestrator such as Step Functions or Logic Apps makes the flow and its failures visible.

32. How do you integrate a cloud application with a legacy on-premises system?

Pick the connectivity first: site-to-site VPN for quick start and modest bandwidth, dedicated connectivity (Direct Connect, ExpressRoute, Cloud Interconnect) for steady bandwidth and predictable latency, often with VPN as backup. Then the integration style: wrap the legacy system with an API layer if it can take request load; use CDC or scheduled file exchange if it cannot; put a queue in between if it is slow or has maintenance windows.

Part 8: The customer-facing work (33-38)

33. A customer wants something you believe is the wrong architecture. What do you do?

First, make sure you understand why they want it - there may be a constraint you did not hear (a contract, a skill set, a political commitment). Then make the case with their goals, not your preferences: "You told me the priority is launching in eight weeks with a team of three. Running our own Kubernetes control plane adds operational work that competes with that. Here is the option that meets the deadline, and here is what we give up."

If they still choose their path and it is safe, document the decision and the risks, and help them do it well. If it is unsafe - a compliance violation, a single point of failure on a system they said cannot go down - escalate and say clearly that you cannot put your name on it. Interviewers want to hear both the persuasion and the line you will not cross.

34. How do you handle a technical objection in a sales meeting, for example "your platform will lock us in"?

Acknowledge it as legitimate, then make it concrete. Ask what lock-in they are worried about: data portability, skills, pricing leverage, or exit cost. Address each with specifics: data in open formats and how to export it, which components use open standards (containers, PostgreSQL, OpenTelemetry), where they would depend on proprietary services and what that buys them. Offer to put an exit plan in the architecture document.

Do not dismiss it and do not overclaim. "There is no lock-in" is false for any platform; "here is exactly where the switching cost is and why it is worth it" is credible. If you do not know an answer, say you will come back with it, and do.

35. What goes into a statement of work, and what is the SA's part in it?

A SOW defines scope (in and explicitly out), deliverables, acceptance criteria, assumptions, customer responsibilities, milestones, timeline, roles, and the change control process. Pricing and commercial terms usually come from the account or delivery lead.

The SA owns the technical truth of it: the architecture the scope assumes, the effort estimate behind each deliverable, and especially the assumptions ("customer provides network connectivity by week 2", "up to 20 applications in wave one", "integration with no more than three source systems"). Vague scope is where projects lose money. A useful test: could a delivery team that was not in the sales cycle read this and know exactly when they are done?

36. How do you run a good technical demo?

Tailor it to the problems from discovery - show their use case with data shaped like theirs, not a generic tour. Lead with the outcome ("this is the report your finance team builds by hand every month, generated in seconds"), then show how it works for the technical audience. Keep it short, leave room for questions, and rehearse the failure path: have a recording or screenshots ready if the live environment misbehaves.

The follow-up: "what if they ask to see a feature you do not have?" Say so, explain how customers solve it today (partner, roadmap, workaround), and move on. A demo that hides a gap creates an escalation six months later.

37. How do you scope a proof of concept so it actually helps close the deal?

Agree success criteria in writing before you start: specific, measurable, tied to the buying decision ("ingest last month's claims data and answer these 20 questions with at least this accuracy, within this latency"). Time-box it, typically a few weeks. Agree who on the customer side provides data and access, and who will make the decision when it succeeds.

The anti-pattern is the open-ended "free pilot" with no exit criteria, which consumes engineering time and becomes production without the architecture to support it. Also be clear what the POC does not prove - security hardening, scale, operations - so nobody mistakes it for the production design.

38. How do you explain a technical design to a non-technical executive?

Start with the decision you need from them and the business impact, not the diagram. Use one picture with the customer journey or data flow, three or four boxes, plain names. Translate each trade-off into money, risk or time: "Option A costs about X more per month and means an outage in one region does not stop orders; Option B is cheaper and an outage would stop orders for roughly an hour."

Part 9: GenAI solutions (39-43)

39. When do you recommend RAG versus fine-tuning?

Most enterprise "chat with our documents" requests are RAG problems: knowledge changes, needs to be cited, and must respect permissions. Fine-tuning does not reliably add facts, and you would have to retrain every time the documents change. A good answer starts with prompting, adds retrieval, and reaches for fine-tuning only when there is evidence the first two do not get there. Our complete guide to RAG interview questions goes deeper on chunking, retrieval and evaluation.

40. Sketch a RAG architecture on a managed cloud stack.

Ingestion: documents land in object storage; a pipeline parses, chunks and embeds them and writes vectors plus metadata (source, permissions, timestamps) to a vector store. Query: the user's question is embedded, the store returns the top chunks filtered by the user's permissions, a reranker optionally reorders them, and the model generates an answer with citations. Around it: guardrails on input and output, logging of prompts and retrieved sources for evaluation, and an evaluation set of real questions with expected answers.

On AWS, Bedrock Knowledge Bases manages ingestion and retrieval over vector stores such as OpenSearch Serverless, Aurora PostgreSQL with pgvector or S3 Vectors. Azure commonly pairs Azure AI Search with Azure OpenAI; Google Cloud has Vertex AI Search and the Vertex AI RAG Engine. The follow-up is always about permissions: retrieval must enforce the same access rules as the source system, or the bot becomes a data leak.

41. What guardrails would you put on a customer-facing GenAI application?

Layer them:

• Input: prompt-injection detection, denied topics, PII detection and masking, length limits.
• Retrieval: permission filtering, and treat retrieved content as data, not instructions.
• Output: content filtering, PII redaction, grounding checks against the retrieved sources, format validation for structured output.
• Action: if the model can call tools, least-privilege credentials, allow-listed actions, and human approval for anything irreversible.
• Operations: logging, rate limiting per user, abuse monitoring, an evaluation suite run on every prompt or model change.

Amazon Bedrock Guardrails packages several of these as configurable policies: content filters (including a prompt attack category), denied topics, word filters, sensitive information filters, contextual grounding checks and Automated Reasoning checks. Know the managed option for your cloud, and know that no single filter is sufficient on its own.

42. How do you estimate cost per request for an LLM feature?

Build it from tokens:

cost per request =
    (input tokens  x input price per token)
  + (output tokens x output price per token)
  + retrieval cost (embedding the query, vector search)
  + guardrail / moderation cost
  + amortised infrastructure (vector store, compute, logging)

Input tokens include the system prompt, conversation history and retrieved chunks, which is why RAG requests are often input-heavy. Measure real token counts from a prototype rather than guessing, multiply by expected requests per user per month, and compare to what the feature earns or saves.

Levers to bring it down: route easy requests to a smaller model, cache repeated prompt prefixes (prompt caching is supported by several providers), trim retrieved context, cap output length, and batch non-interactive work where the provider offers batch pricing. Look up current prices at quote time - model pricing changes often enough that a number in a slide from last quarter may be wrong.

43. How do you measure whether a GenAI solution is working?

Define metrics before launch. Offline: an evaluation set of real questions with reference answers, scored for correctness, groundedness (is every claim supported by retrieved sources), and retrieval quality (did the right document come back). Online: task completion, escalation or handoff rate, user feedback, latency and cost per request. Review samples by hand regularly; automated LLM-as-judge scoring helps at volume but needs calibration against human judgement.

Part 10: Whiteboard design scenarios (44-47)

These are the questions a live loop actually runs on. Interviewers score how you clarify, how you structure the board, and how you handle the curveball, more than the final diagram.

44. Design a highly available e-commerce platform that must survive a flash sale.

Clarify first: peak orders per second, catalogue size, regions, payment provider, acceptable RPO for orders. Then:

• CDN in front of static assets and cacheable catalogue pages.
• Stateless web/API tier across at least two AZs behind a load balancer, autoscaling on request metrics, pre-warmed or scheduled scaling before a known sale.
• Catalogue reads from a cache in front of the database.
• Orders written to a queue, processed by autoscaling workers, so a spike becomes a backlog rather than an outage; idempotency keys so retries do not double-charge.
• Inventory decremented atomically (conditional writes) to prevent overselling.
• Multi-AZ database for orders; DR posture chosen from the agreed RPO/RTO.

Curveball: "the payment provider rate-limits you." Answer: queue payment calls, back off and retry, show the customer "order received, confirming payment" rather than holding the request open. The flash sale walkthrough goes through this design end to end.

45. A bank wants to move a core customer portal to the cloud. Regulators require an RTO of 1 hour and an RPO of 5 minutes. Design it.

Those targets rule out backup and restore and point at pilot light or warm standby across two regions; with a one-hour RTO, warm standby gives more margin and less dependence on scaling actions during an incident. Design: primary region multi-AZ; database with cross-region asynchronous replication whose lag is monitored and alarmed well below 5 minutes; application tier running at reduced capacity in the recovery region; failover through pre-provisioned routing controls; secrets and keys replicated; IaC deploying both regions identically.

Add the regulated-industry layer: customer-managed keys, private connectivity to on-premises, centralised immutable audit logs, data residency checks on both regions, and a tested DR runbook with evidence the regulator can review. Say that asynchronous replication means RPO is "lag at the moment of failure," which is why the lag alarm matters.

46. A customer wants an internal assistant that answers HR policy questions for 20,000 employees. Design it and estimate the cost.

Clarify: languages, where the policies live, whether answers vary by country or employee group, whether the assistant can take actions (book leave) or only answer. Design: RAG over the policy repository with metadata for country and employee group; retrieval filtered by the user's attributes from the identity provider; citations to the policy document in every answer; guardrails for PII and denied topics such as individual legal or medical advice; handoff to an HR ticket when the answer is not grounded.

Cost: estimate from usage, not headcount. If a share of employees ask a few questions a month, multiply requests by measured tokens per request (from question 42), add the vector store and logging baseline, and present a range. The interviewer is checking that you ask about usage, build the estimate from units, and call out the evaluation plan.

47. Migrate 300 VMs from a data center whose lease ends in nine months.

Clarify: what runs on them, dependencies, licensing, network bandwidth to the cloud, team size. Plan: discovery and dependency mapping in the first weeks; classify each workload by the 7 Rs (expect most to rehost, some to retire, a few to replatform onto managed databases); build the landing zone (accounts, network, identity, logging) in parallel; a pilot wave of low-risk applications to prove the process; then dependency-grouped waves with rehearsed cutovers and rollback criteria.

Deadline risk drives the strategy: with nine months, refactoring is out of scope except where it is the only option. Modernisation goes in a phase after the exit. Name the risks out loud: bandwidth for data transfer, licensing for software tied to hardware, and anything that cannot move and needs a colocation or retain plan.

Part 11: Behavioral (48-50)

These are answered in STAR form (situation, task, action, result) with one specific story each. The behavioral question bank has more prompts to rehearse against.

48. Tell me about a time you lost a technical argument with a customer.

Pick a story where you made a strong case, the customer chose differently for a legitimate reason, and you helped them succeed anyway. Show what you learned - often that you had misjudged their constraints or the weight of a business factor. Interviewers are screening for ego: SAs who need to win every argument burn customer trust. The best version ends with the customer coming back to you later because you handled it well.

49. Describe a design you got wrong.

Choose a real one with a measurable consequence - a cost overrun, a scaling limit hit earlier than planned, a DR test that failed. Explain what you assumed, what turned out to be different, how you found out, how you fixed it, and what you now do differently (for example, load testing earlier, or asking a specific discovery question every time).

50. Tell me about a deal or project where you had to say no.

The strongest answers involve a commitment you refused to make - a timeline, a feature, a security shortcut - and how you kept the relationship. Explain how you framed the no in terms of the customer's interests, what alternative you offered, and the outcome. If the deal was lost, say so and say why you would make the same call.

How to practice for a solutions architect interview

• Rehearse discovery out loud. Have a friend play a vague customer ("we want to modernise") and practise getting to measurable outcomes, constraints and decision makers in fifteen minutes.
• Whiteboard one scenario a day against a clock. Clarify, draw, defend, and handle one curveball. Part 10 gives you four; the system design walkthroughs give you many more.
• Know one cloud deeply and map the others. Interviewers accept "on AWS I would use X; the Azure equivalent is Y" but not vague service names. Certification blueprints such as AWS Solutions Architect Associate, AWS Solutions Architect Professional, Azure AZ-305 and Google Professional Cloud Architect are a good map of what is fair game.
• Build one cost model. Price a real three-tier app and a RAG feature in a pricing calculator, with assumptions written down. Doing it once makes question 23 and question 42 easy.
• Write a one-page proposal. Problem, outcome, architecture, assumptions, out of scope, risks. That is the SOW muscle the pre-sales loop tests.
• Prepare five stories that cover disagreement, failure, saying no, influence without authority and a customer win, and rehearse each in under two minutes.

Keep going

• Drill the technical core: the cloud architecture and system design question banks, and the free daily challenge for one question a day with no account.
• Follow a track: AWS solutions architect, Azure solutions architect, GCP solutions architect or cloud architect prep.
• Go deeper on the provider: Top 50 AWS, Top 50 Azure and Top 50 GCP interview questions, and whether the AWS Solutions Architect Professional is worth it.
• For the GenAI and customer-embedded side: the complete guide to RAG interview questions and forward deployed engineer interview prep, which covers the closest neighbouring role.
• Practise the conversation: the chat-based AI mock interview asks the "and what if the customer says no?" follow-ups that decide SA loops.
• Related guides: Top 50 AWS Networking and VPC Interview Questions 2026, Top 50 AWS Lambda and Serverless Interview Questions 2026, Top 50 Technical Program Manager (TPM) Interview Questions 2026.

#solutionsarchitect #cloud #architecture #aws #azure #gcp #interviews #career