Cloud Solutions Architect Interview Prep: Questions and a Mock Test

The AWS Well-Architected Framework is the closest thing this role has to a syllabus, and interviewers use it as one. There are six pillars: operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability. Sustainability is the one candidates most often omit, and it was added after the original five, so leaving it out is a small dating signal.

The useful way to hold them is as a review pass rather than a list to recite. Given any design you have just drawn, each pillar asks a different question. Operational excellence asks how you would run it and how you would know it was broken. Security asks where the trust boundaries are and what the blast radius of a compromise is. Reliability asks what happens when each component fails and whether recovery is tested. Performance efficiency asks whether the resource type actually matches the workload. Cost optimization asks what you are paying for that nobody uses. Sustainability asks about the resources consumed to deliver the same outcome.

What interviewers reward is applying the pass unprompted. A candidate who finishes a design and then says "the weakness here is the single write node, and here is what I would do if the availability requirement were higher" has demonstrated the behaviour the framework is trying to encode. A candidate who names all six pillars but proposes a design with no failure story has demonstrated recall.

The shared responsibility model comes up in almost every cloud interview, and the phrasing is worth having exactly right, because the distinction is genuinely load-bearing.

AWS is "responsible for protecting the infrastructure that runs all of the services offered in the AWS Cloud", which covers hardware, the software running the services, networking and facilities. That is security of the cloud. The customer is responsible for security in the cloud, which for a virtual machine includes "management of the guest operating system (including updates and security patches), any application software or utilities installed by the customer on the instances, and the configuration of the AWS-provided firewall".

The part that produces good follow-up questions is that the line moves with the service. Running your own instances leaves you patching an operating system. Using a managed database moves patching to the provider but leaves you owning schema, access control and data. Using object storage or a serverless function moves almost all operational burden across, and still leaves you entirely responsible for who can read the data and whether it is encrypted.

That last point is where most real cloud breaches live. Publicly readable storage, over-broad identity policies and long-lived static credentials are configuration failures on the customer's side of the line, not provider failures, and an architect is expected to say so plainly.

Availability questions turn on understanding what the physical layout actually guarantees.

An availability zone is a separate set of facilities with independent power and cooling, close enough to others in the same region that synchronous replication between them is practical. Spreading across zones protects against a datacentre-level failure, and it is the default expectation for anything described as highly available. It is also cheap in latency terms, which is why it is usually the right first answer.

A region is a different geography. Spreading across regions protects against a regional outage and can serve users closer to home, but the distance makes synchronous replication impractical, so multi-region designs almost always involve asynchronous replication and therefore a real possibility of data loss on failover. That is the tradeoff to name explicitly.

The vocabulary interviewers expect is recovery time objective, how long you may be down, and recovery point objective, how much data you may lose. Those two numbers drive the architecture, and asking for them before proposing a disaster recovery approach is the strongest possible opening. Backup and restore is cheap with a long recovery time. Pilot light and warm standby trade cost against speed. Active-active is fast and expensive and forces you to solve conflicting writes.

Be ready for the honest observation that an untested failover is a hypothesis, not a capability.

Selection questions look like trivia and are actually about reasoning from requirements.

On compute, the spectrum runs from virtual machines through containers to functions, and the axis that matters is how much operational surface you want in exchange for how much control. Functions suit spiky, short, event-driven work and bring cold starts, execution time limits and a per-invocation cost model that becomes unattractive at sustained high volume. Containers suit long-running services with predictable resource profiles. Virtual machines remain right when you need specific hardware, licensing arrangements or kernel-level control. The strong answer names the workload characteristic that decides it rather than the service that is currently fashionable.

On storage, the first question is the access pattern. Object storage is for large immutable blobs read whole; it is cheap and durable and is not a filesystem. Block storage is for a single instance's disk. File storage is for shared POSIX semantics across instances. For databases, the choice follows from the query shape and consistency need: relational when relationships and transactions matter, key-value when access is by primary key at high volume, document when the shape varies, wide-column for very high write throughput with known access paths, and a column store when queries scan many rows and few columns.

The answer that scores adds what each choice costs. Every one of these is cheap in the case it was designed for and expensive outside it.

Cost questions separate architects from designers, because cloud pricing punishes specific design choices in ways that are not obvious from a diagram.

Data transfer is the one candidates most often miss. Traffic into a provider is typically free, traffic out is not, and traffic between availability zones is usually charged in both directions. That single fact changes designs: a chatty service mesh spread across zones for availability is paying per message for that availability, and a design that keeps request paths within a zone while keeping data replicated across them is a genuinely different shape.

Storage classes are the second area. Infrequent-access and archival tiers are dramatically cheaper per gigabyte and add retrieval cost and retrieval latency, so lifecycle policies are the right answer only once you know the read pattern. Requests themselves cost money at high volume, which is why many small objects can cost more than the bytes suggest.

The third is committed spend. Reserved capacity and savings plans trade flexibility for a large discount, and spot capacity trades availability for a larger one, which suits fault-tolerant batch work and suits a stateful primary database not at all.

The habit worth demonstrating is estimating before designing. A rough monthly figure derived out loud, with the assumption stated so the interviewer can correct it, is worth more than a precise number, because it shows cost is part of how you choose rather than something finance discovers later.