Cloud Architect interview loops

A cloud architect is the person who designs how an organisation's systems are laid out on one or more cloud providers: how the estate is divided into accounts and networks, where its data may be kept, how it recovers when a provider's zone or region fails, what it costs, and how what still runs in a data centre moves into it. Where a DevOps engineer builds the pipeline that takes a change to production, a cloud architect decides the shape of the estate that pipeline deploys to.

As of October 2026 the title covers three jobs. Inside a company it is the person who decides what an estate becomes: a Ripple posting has its staff cloud architect owning the infrastructure architecture of one product's platform and answering for trade-offs that will shape its cost and upkeep for years, while senior engineers do most of the building and the day-to-day running (Ripple). At a provider or a services firm it can face customers, helping to sell the work and then leading it: an AWS posting has its senior cloud architect scoping and estimating the work each contract covers and then leading the migrations and modernisations that follow (AWS), and an Ensono posting for a principal solution architect, cloud, has them helping to plan migrations down to the cutover runbooks and leading the architecture until operations take over, with experience of any one of AWS, Azure or Google Cloud accepted (Ensono). After the sale it can sit in a forward deployed engineering organisation: a DoiT posting has its senior cloud architect working with existing customers on cost, reliability, security and their AI workloads (DoiT). The loop below is written for the first job: an architect joining an estate that already runs.

The work is decisions whose cost arrives later. Which account a team's data lands in, which address range a network is given, where the business recovers when a region goes, what a three-year commitment is bet on, which systems are moved as they are and which are rebuilt on the way: each is cheap on the day it is made and expensive to change once other teams have built on it. The architect rarely builds most of it. They are the person who has to be right about it two years later, and the person who has to get the teams it affects to accept it, in writing, before anyone starts.

That makes the role awkward to interview for in two ways. The first is that the vocabulary is everywhere — every provider publishes a framework of pillars and principles, and a candidate who has read one can talk fluently about all of them. The second is that a whiteboard design starts from nothing, and this job never does: it starts from a platform in one region, a bill nobody has read closely, a data centre with a contract end date, and decisions already marked accepted. So the rounds below hand the candidate something that already exists and has something wrong with it, and score what they notice, what they price, and what they are willing to promise. They are written to be provider-neutral. A candidate from any of the large providers can take them, and naming a service from their own is welcome; knowing one provider's catalogue is not what is scored.

Employers draw the line on AI in different places, including on the work done before the interview. Anthropic asks candidates to do take-home assessments and live interviews without it unless told otherwise (Anthropic, updated July 2025), while Pinterest invites it in designated parts of its process, such as an assignment done at home, and keeps it out of live questions unless the interviewer allows it (Pinterest, as of October 2026). None of the plans below says either way. All four rounds in the loop send their pack 24 hours ahead, and each pack carries faults it does not label, which the plans credit the candidate for finding unprompted: transaction logs archived only in the region whose loss the design must survive, a nightly job that rereads a month of data, a batch server due to move in a different wave from its database, a decision record that would not have prevented the incident it cites. An assistant given a pack overnight could find them instead, and do much of the arithmetic the plans score, so allowing one on the packs changes what the rounds measure. The rest of each round is a decision defended live: the paragraph the board signs, the sentence for finance about a zone, the call on the portal database, the answers to four colleagues. So decide before the first pack goes out, and tell the candidate which packs, and which parts of the hour, an assistant may be used on.

A loop is a set of round plans in order. Each round scores one to three competencies, every must-have is scored in at least two rounds by different interviewers, and the debrief goes competency by competency rather than round by round, so no single interview decides the hire. How these plans work covers the rest of the method.

Further reading, as of October 2026. The well-architected frameworks of AWS, Azure and Google Cloud each warn against promising more than a system can deliver, whether zero data loss (AWS), a recovery nobody has tested (Azure) or 100% uptime (Google Cloud). The board in the system design round asks for no data loss and at most fifteen minutes of downtime, and the plan credits the candidate who prices that promise rather than making it or refusing it. The FinOps Foundation's FinOps Framework treats Allocation, Unit Economics, Planning & Estimating and Rate Optimization, which covers commitment discounts, as separate capabilities, and the cost review asks about all four, from who owns a line of the bill to a three-year commitment. RFC 1918 (1996), which set aside 10.0.0.0/8 and two smaller blocks for private networks, warned that networks numbered from them without coordination may clash once they are joined, and the migration review asks the candidate to join two that do. Michael Nygard's Documenting Architecture Decisions (2011) marks a decision proposed until its stakeholders agree, and asks for all of its consequences, not only the good ones; the record in the design review was marked accepted before its review, and its consequences are all benefits.