Solutions / cloud architect interview questions

What must an architecture diagram show before anyone can review it?

The strongest answer: The components, what talks to what and over which protocol, where the data lives, and the trust boundary — with a legend

Why it works: Exactly. Components, connections, data, boundaries, legend. That is a reviewable picture.

• Components, connections, data, trust boundary.
• A legend, so the arrows mean one thing.
• One view per question — not every box.
• Intent first; generated views are supporting evidence.

A senior says “that is a trade-off” in a design review and moves on. The junior asks you what was meant.

What does “that is a trade-off” actually mean, and what is the next sentence?

The strongest answer: We gain something and give up something; the next sentence names both and says which the requirement values more

Why it works: Exactly. Name the gain, name the cost, tie the choice to a requirement. That is the whole job.

• Name what you gain.
• Name what you give up.
• Tie the pick to a requirement.
• Then decide — do not park it.

A new product with a team of four: monolith or microservices to start?

The strongest answer: A well-structured monolith with clear module boundaries — services add network, deployment and data-consistency costs the team does not need yet

Why it works: Exactly. Modules now, services when a boundary earns the network hop. The structure is what keeps the option open.

• Start modular, not distributed.
• Services cost network, deploys and consistency.
• Boundaries follow the domain.
• Keep the split as a later option.

What is the difference between a region and an availability zone?

The strongest answer: A region is a geographic area with several availability zones; each zone is one or more separate data centres with its own power and network, so spreading across zones survives a data-centre failure

Why it works: Right. The zone is the fault boundary you design around; the region is where your data lives.

• Region: a geography with multiple zones.
• Zone: isolated power, cooling and network.
• Spread across zones for availability.
• Spread across regions for disaster recovery.

An interviewer says: “Design a URL shortener.” What do you do first?

The strongest answer: Ask what it must do and at what scale — reads vs writes, expiry, custom aliases, analytics — and state the assumptions you will design against before drawing anything

Why it works: Right. Requirements and numbers first; the boxes follow from them.

• Clarify functional and non-functional requirements first.
• State assumed scale in numbers.
• Only then draw.
• Check assumptions with the interviewer.

What does a load balancer do, and what does it not do?

The strongest answer: Spreads requests across healthy instances and drops unhealthy ones from rotation; it does not make a slow service fast or a stateful one safe to scale

Why it works: Exactly. Distribution and health checks. It hides instance failure, not design failure.

• Distributes across healthy instances.
• Health checks remove the sick ones.
• Does not fix slow code or shared state.
• Not an availability guarantee on its own.

IaaS, PaaS, SaaS — what does each one leave to you?

The strongest answer: IaaS gives you machines and networks and you run everything on them; PaaS runs the platform and you bring code and data; SaaS is a finished application you configure

Why it works: Exactly. The line that moves is who patches, scales and operates the layer underneath.

• IaaS: VMs, disks, networks — you run the rest.
• PaaS: bring code and data, the platform runs it.
• SaaS: a finished product you configure.
• The difference is who operates each layer.

When does adding a cache make sense, and what is the first question to ask?

The strongest answer: When the same read is repeated and the source is slow or expensive; the first question is how stale the data may be

Why it works: Exactly. Repeated reads, expensive source, and a staleness budget you can name before you build.

• Repeated reads of an expensive source.
• Ask how stale is acceptable.
• A cache is a copy; copies drift.
• Not a substitute for the store.

A stakeholder says “we need a reporting feature”. How do you turn that into functional requirements you can design against?

The strongest answer: Ask who uses it, for which decisions, with what data and how often; write each as a concrete behaviour with an example, and agree what is out of scope

Why it works: Exactly — functional requirements are observable behaviours with examples and a scope line, not a feature name.

• Behaviours, examples, scope.
• Ask who, what data, how often.
• Write each as an observable behaviour.
• Agree what is out of scope.

When would you use object storage rather than a block volume?

The strongest answer: For files you read and write whole over HTTP — uploads, backups, static assets, data-lake files — because object storage is durable, cheap and shared, while a block volume is a disk attached to one machine

Why it works: Right. Whole-object access, shared, durable and cheap; a disk is for a filesystem or a database.

• Object: whole files over HTTP, shared, cheap, durable.
• Block: a disk for one machine's filesystem or database.
• Pick by access pattern, not by speed.
• Static assets and backups belong in object storage.

What is the difference between scaling up and scaling out?

The strongest answer: Up means a bigger machine — simple, but there is a ceiling and one box to lose; out means more machines behind a balancer, which needs the service to be stateless or to share state elsewhere

Why it works: Right. Up is easy until the ceiling; out needs stateless services.

• Up: bigger box, ceiling, single failure.
• Out: more boxes, needs statelessness.
• Choose by state and ceiling.
• Neither is always right.

A developer asks why the team has coding standards at all. What do you tell them?

The strongest answer: So any of us can read and change any file: reviews then argue design, not style. We agree them as a team and let a formatter and linter enforce what they can

Why it works: Exactly — shared readability and cheaper reviews, with anything mechanical enforced by a tool rather than a person.

• Shared readability, enforced by tools.
• Agree them with the team.
• Automate format and lint.
• Review design, not style.

Orders currently succeed or fail based on whether the payment provider answers within thirty seconds.

The payments team wants the order service to call them synchronously for every order. What do you weigh?

The strongest answer: Whether the order truly needs the payment answer before it can proceed; if yes, keep it synchronous with timeouts and a fallback state, if not, make it an event and reconcile

Why it works: Exactly. The business question decides the integration style, and either way the failure behaviour is designed.

• Does this step need the answer now?
• Sync: timeouts and a fallback state.
• Async: events and reconciliation.
• Own your availability either way.

How do you change the shape of an event that three other teams already consume?

The strongest answer: Add optional fields and never repurpose existing ones; for a breaking change publish a new version alongside the old until consumers have moved, and record the contract in a schema registry or shared repo

Why it works: Exactly. Additive by default, versioned when breaking, contract written down.

• Additive changes only, by default.
• Breaking change: new version side by side.
• Write the contract down.
• Consumers move on their timeline.

A client retries a “create payment” request after a timeout. How does the design stop a double charge?

The strongest answer: The client sends an idempotency key; the server stores the result under that key and returns the same response on a repeat, so retries are safe by design

Why it works: Exactly. Key on the request, result stored, replay returns the original. Retries become harmless.

• Client supplies an idempotency key.
• Server stores the result by key.
• Replay returns the same answer.
• Retries are a given; design for them.

How do you version a public API so you can change it without breaking customers?

The strongest answer: Make additive changes without a version bump, put breaking changes behind a new major version, run old and new in parallel with a published sunset date, and measure who still calls the old one

Why it works: Exactly. Additive quietly, breaking under a version, parallel run, measured deprecation.

• Additive changes need no version.
• Breaking changes get a new major.
• Run both; publish the sunset date.
• Measure remaining callers before removal.

What does CAP actually mean for a design decision, in plain terms?

The strongest answer: When the network partitions, each part of the system either refuses some requests to stay consistent or answers with possibly stale data to stay available — you choose per operation, not per system

Why it works: Exactly. Partition is the given; the choice is what each operation does when it happens.

• Partitions happen; that is the given.
• Refuse (consistent) or answer stale (available).
• Choose per operation.
• No product “solves” it.

A service restarts in a loop every time its database has a slow minute.

What should a service’s health check actually test?

The strongest answer: Liveness: the process is running; readiness: it can serve traffic, including its critical dependencies — and keep them separate so a slow database does not cause a restart loop

Why it works: Exactly. Two questions, two probes, and failing readiness sheds traffic without killing the process.

• Liveness: process alive.
• Readiness: can serve, dependencies included.
• Keep them separate.
• Degrade on non-critical dependencies.

Product insists the follower count must be exactly right the instant someone follows.

How do you explain eventual consistency to a product manager who wants the total to “always be right”?

The strongest answer: Show a concrete case — the user posts, then refreshes and sees the old count for a moment — and ask whether that is acceptable, and for which screens it is not, so we can pay for strong consistency only there

Why it works: Exactly. A concrete scenario, a real choice, and a targeted spend on the screens that need it.

• Show the concrete stale moment.
• Ask where it is unacceptable.
• Pay for strong consistency only there.
• No jargon, no homework.

How do you make room for technical debt alongside features?

The strongest answer: An explicit, visible share of capacity agreed with product, spent on the debt that causes the most pain or blocks the roadmap

Why it works: Exactly. Debt work is a negotiated, visible investment tied to actual pain.

• Explicit, visible capacity.
• Agree it with product.
• Target the debt that hurts.
• Never hide it.

Two services both need customer data. Who owns it, and how does the other get it?

The strongest answer: One service owns the write model and is the source of truth; the other reads through its API or keeps a local copy fed by events, accepting that the copy lags

Why it works: Exactly. One writer, one truth; others read or subscribe and accept the lag.

• One owner writes.
• Others read via API or events.
• Copies lag by design.
• No shared tables between services.

You are writing a technical proposal for a change that touches three teams. What does it contain?

The strongest answer: The problem and goals, explicit non-goals, the options considered with their trade-offs, a recommendation, risks, rollout and rollback, open questions, and who decides by when

Why it works: Exactly — a proposal shows the thinking, not just the answer, so reviewers can engage with the trade-offs.

• Problem, options, recommendation, decision.
• State goals and non-goals.
• Options with fair trade-offs.
• Risks, rollout, rollback, deadline.

A user has an allow policy for an action and their group has a deny for it. What happens?

The strongest answer: The deny wins — policy evaluation starts from implicit deny, an explicit allow grants, and an explicit deny anywhere overrides every allow

Why it works: Right. Deny beats allow, always; that is what makes guardrail denies trustworthy.

• Default: implicit deny.
• Explicit allow grants.
• Explicit deny overrides everything.
• Guardrails are written as denies for that reason.

URL shortener: how do you generate the short code?

The strongest answer: Either hash the long URL and take the first characters, handling collisions by retry, or hand out pre-generated unique codes from a counter or key service; say which, and why — a counter gives guaranteed uniqueness but predictable codes, a hash is stateless but needs collision checks

Why it works: Right. Name the scheme and its trade-off.

• Hash-and-truncate or pre-generated keys.
• Handle collisions explicitly.
• Predictability vs statelessness.
• Length from the target count.

A fifteen-year-old billing system must be replaced while it keeps invoicing every month.

How do you replace a large legacy system without a big-bang cut-over?

The strongest answer: Put a facade in front, route one capability at a time to the new system while the old keeps serving the rest, and retire the old pieces as traffic moves — the strangler fig pattern

Why it works: Exactly. Facade, incremental routing, measured retirement. Every step is reversible.

• Facade in front of the legacy.
• Move one capability at a time.
• Retire as traffic moves.
• Every step reversible.

Twelve services, no tracing. How do you introduce distributed tracing without a year-long programme?

The strongest answer: Standardise the context propagation and instrumentation library first, instrument the gateway and the two slowest paths, sample sensibly, and let each team adopt the shared setup on its own schedule

Why it works: Exactly. Standard first, prove value on the painful paths, then spread.

• Standardise propagation first.
• Instrument the slowest paths.
• Sample deliberately.
• Spread by paved path, not decree.

What does zero trust change about how services talk to each other inside the network?

The strongest answer: Being on the network grants nothing: every call authenticates the caller, is authorised for the action, and is encrypted, so a compromised host cannot reach everything else

Why it works: Exactly. Identity per call, authorisation per action, encryption in transit — inside as well as outside.

• Network location grants nothing.
• Authenticate every caller.
• Authorise every action.
• Encrypt inside as well as outside.

Your cloud bill has grown quarter on quarter and finance has asked you to explain it.

How do you handle it?

The strongest answer: Make the cost visible to the team by service, set a target with them, fix the biggest waste first, and balance it against the delivery we owe

Why it works: Exactly. Visibility, a shared target, biggest waste first, and a trade-off you own.

• Make cost visible per service.
• Set the target with the team.
• Biggest waste first.
• Do not blame, do not mandate blindly.

A customer requires that their data stays in their country. What does that change in the architecture?

The strongest answer: Where data is stored and processed, including backups, logs, analytics copies and support access — you map every place the data flows before promising anything

Why it works: Exactly. Residency is about every copy and every processor, not the primary database alone.

• Map every place the data flows.
• Backups, logs and analytics count.
• Support access counts too.
• Encryption is not residency.

The team wants to rewrite the core service from scratch. How do you respond?

The strongest answer: Understand the pain concretely, then favour an incremental path — replace behind a seam piece by piece — and decide on evidence about risk and value

Why it works: Exactly. Name the pain, prefer incremental replacement, and decide on evidence.

• Understand the pain first.
• Incremental over big bang.
• Decide on evidence.
• Never freeze the business.

How do you decide whether to build or buy a component?

The strongest answer: Whether it is core to what differentiates us, the total cost including operation and lock-in, and whether the team has the capacity to own it well

Why it works: Exactly. Core versus context, whole-life cost, and honest capacity.

• Core or context?
• Total cost, including lock-in.
• Capacity to own it.
• Demos do not decide.

The e-commerce team is expanding from one country to four continents.

Product wants globally consistent inventory counts and sub-second responses from every continent. What do you say?

The strongest answer: Those pull against each other; propose strong consistency on the reserve-and-purchase path and a slightly lagging count on display, and show the cost of each alternative

Why it works: Exactly. Split the requirement by operation and make the cost of each visible.

• Name the tension out loud.
• Strong consistency where money moves.
• Lag allowed on display.
• Show the cost of each option.

The business asks for a disaster recovery plan. What two numbers do you ask for first, and why?

The strongest answer: RPO — how much data loss is acceptable — and RTO — how long the service may be down; together they decide whether backups, a warm standby or an active second region is the right answer, and what it costs

Why it works: Right. Every DR design is a point on the RPO/RTO/cost triangle; get the two numbers before the architecture.

• RPO: acceptable data loss.
• RTO: acceptable downtime.
• They pick backup, warm standby or active-active.
• Cost rises steeply as both approach zero.

Your queue delivers at least once. What does that force on every consumer?

The strongest answer: Idempotency: each message carries a key and the consumer records what it has processed, so a redelivery after a crash or a slow ack is a no-op; you design the side effects to tolerate repeats rather than hoping for exactly-once

Why it works: Right. Repeats are certain; make them harmless.

• At-least-once means duplicates.
• Consumer keeps processed keys.
• Side effects tolerate repeats.
• Do not rely on exactly-once.

Active-passive versus active-active across regions — what does active-active cost you beyond money?

The strongest answer: Data consistency: two regions taking writes means conflict resolution, replication lag and a data model that tolerates both, so active-active is a design constraint on the application, not only a bigger bill

Why it works: Right. The hard part is the data; the compute is the easy part.

• Active-active means writes in two places.
• Conflict resolution and lag are yours.
• Design the data model for it.
• Active-passive keeps one truth.

A hot cache key expires and 5,000 requests miss at once. Design against it.

The strongest answer: Coalesce: the first miss takes a lock or a single-flight slot and rebuilds while the others wait or serve the stale value; add early refresh before expiry with jittered TTLs so keys do not expire together; the database sees one read, not thousands

Why it works: Right. Single flight, stale-while-revalidate, jitter.

• One rebuild, others wait or serve stale.
• Refresh before expiry.
• Jitter TTLs.
• DB sees one read.

What principles guide how you design an engineering organisation?

The strongest answer: Teams aligned to value streams or domains they can own end to end, minimal handoffs, clear ownership, and an awareness that the org shape becomes the system shape

Why it works: Exactly. Ownership, flow, and an eye on Conway’s law.

• Align to value streams.
• Minimise handoffs.
• Clear ownership.
• Org shape becomes system shape.

After a two-hour regional outage, the executive team wants a global architecture by next quarter.

The CEO wants the platform “in every region so it never goes down”. What do you present?

The strongest answer: The actual availability and latency targets the business needs, the outage history, and the costed options from multi-zone through active-passive to active-active — with the data-conflict and operational burden of each named

Why it works: Exactly. Translate the wish into targets, then price the options honestly.

• Turn the wish into targets.
• Show outage history.
• Price zone, passive and active options.
• Name the operational burden.

The same class of incident keeps recurring across different teams. What does the architect do?

The strongest answer: Read the reviews together to find the shared cause — a missing platform capability, a default, a pattern — fix it once at the platform or standard level, and track whether the class disappears

Why it works: Exactly. Systemic causes need systemic fixes, then evidence that they worked.

• Find the shared cause across reviews.
• Fix at the platform or standard level.
• Prefer defaults over documents.
• Track whether the class disappears.

Cloud spend is growing faster than revenue and nobody owns it. What do you set up?

The strongest answer: Tagging and allocation so every cost has an owning team, budgets with alerts per team, a regular review of the biggest lines with the engineers who can change them, and architecture standards for the recurring wastes

Why it works: Exactly. Ownership, budgets, regular engineering review, standards. A system, not an event.

• Every cost has an owner.
• Budgets and alerts per team.
• Regular review with engineers.
• Standards for recurring waste.

You are asked to move a portfolio of two hundred applications to the cloud. How do you approach it?

The strongest answer: Inventory and classify by business value, risk and technical shape, assign each a path — retire, rehost, replatform, refactor, replace — sequence by dependencies and quick wins, and build a landing zone and a repeatable pipeline before the first wave

Why it works: Exactly. Classify, choose a path per application, sequence, and industrialise the mechanics first.

• Inventory and classify first.
• A path per application.
• Landing zone and pipeline before wave one.
• Learn on low-risk systems.

You are asked to make a payments service active in two regions. What is the first design question?

The strongest answer: Which data must be strongly consistent and which can be eventually consistent — balances need one writer or a consensus store, receipts can replicate later; that split decides the architecture and most of the cost

Why it works: Right. Sort the data by consistency need first; everything follows from that.

• Classify data by consistency requirement.
• One writer or consensus for the strongly consistent part.
• Eventual replication for the rest.
• Cost follows the split.

Design multi-tenancy for a product where some tenants are regulated.

The strongest answer: Tiered isolation: shared schema with a tenant key and row-level enforcement for most, and a separate database or cluster for tenants whose contract or regulation demands it — one code path, an isolation level chosen per tenant, with noisy-neighbour limits and per-tenant keys for encryption

Why it works: Right. One product, several isolation tiers.

• Isolation as a per-tenant tier.
• Shared with row-level enforcement.
• Dedicated where required.
• Same code path.

The core banking system exposes only SOAP web services. How does a modern platform integrate with it?

The strongest answer: Through one adapter service that owns the SOAP client generated from the contract, translates to the platform’s model, absorbs the system’s quirks and faults, and shields everything else — the one place to change when the core changes

Why it works: Exactly — an anti-corruption layer keeps the legacy model and protocol out of the platform.

• One adapter owns the legacy.
• Generated client behind your model.
• Absorb quirks and faults there.
• One place to change later.

What is a cell-based architecture and when is it worth the complexity?

The strongest answer: Running many small, independent copies of the whole stack, each serving a slice of customers, so a failure or a bad deploy hurts one cell rather than everyone; worth it once a single shared stack's blast radius is the biggest risk you have

Why it works: Right. Blast radius is the product; complexity is the price.

• Many independent full-stack copies.
• Customers routed to a cell.
• Failure contained to one cell.
• Adopt when blast radius is the top risk.

How do you limit the blast radius of a failure in a system serving millions?

The strongest answer: Cells: independent copies of the whole stack, each serving a slice of customers, with a thin routing layer; a bad deploy or a poison request takes out one cell, deploys roll cell by cell, and capacity grows by adding cells — at the cost of cross-cell features being hard

Why it works: Right. Isolation by cell; the cost is anything cross-cell.

• Independent full-stack cells.
• Customers pinned to a cell.
• Deploy cell by cell.
• Cross-cell features are the cost.

How much should an organisation worry about cloud vendor lock-in?

The strongest answer: Decide deliberately per layer: accept lock-in where the managed service is a real advantage, keep data and interfaces portable, and know the exit cost of each big dependency — total avoidance costs more than most lock-in

Why it works: Exactly. Lock-in is a price you pay knowingly, per layer, with data portability as the line you hold.

• Decide per layer, deliberately.
• Keep data and interfaces portable.
• Know the exit cost.
• Total avoidance is its own cost.

Your DR runbook is a document. How do you make it real?

The strongest answer: Run it: scheduled game days where the team fails over to the secondary using only the runbook, timed against the RTO, with every gap fixed and the runbook updated afterwards; automate the steps that keep failing

Why it works: Right. A runbook that has not been run is a story.

• Execute the runbook on a schedule.
• Time it against RTO.
• Fix and update after every run.
• Automate the flaky steps.