How to get hired as a cloud architect in 2026-27

Cloud architect is four different jobs, and the posting tells you which

Before you write a line of your resume, work out which of four jobs the posting describes, because the preparation diverges almost immediately. All four say cloud architect. They differ on whose system you design, who you have to persuade, whether a certification is a commercial requirement or a nice to have, and whether the interview contains a coding round or a customer presentation.

Shape one is the internal enterprise cloud architect. The employer is a bank, insurer, retailer, health system, manufacturer or government body with an existing estate and a migration programme somewhere in it. The posting names a landing zone, governance, standards, an architecture review board, a cloud centre of excellence, cost management, and compliance regimes such as PCI DSS, HIPAA, SOC 2 or a sector regulator. You design for internal teams who do not report to you, and the hardest part of the job is not technical: it is getting forty delivery teams to use the thing you specified while granting exceptions carefully enough that the standard survives. The screen cares about estate scale, how many applications you moved, and whether you have run governance without authority.

Shape two is the customer-facing architect, at a cloud provider itself, a global systems integrator, a regional consultancy or a managed service provider. The posting mentions pre-sales, discovery, workshops, statements of work, proof of concept, a partner practice, or billable utilisation. You see many estates rather than one, you write a lot of proposals, and the hiring process will test how you behave in front of a customer who has already decided on the wrong answer. This is the one shape where certification is close to mandatory, because partner tier with the cloud provider is counted in certified heads, and it is also the fastest way to accumulate migration experience if you do not have any.

Shape three is the product architect at a software company. The subject matter is the company's own system: multi-tenancy model, region strategy, data residency, the control plane, tenant isolation, the per-customer cost of serving, and the resilience the contract promises. At a lot of these employers there is no architect title at all and the equivalent is staff or principal engineer, which matters for your job search because searching the word architect alone hides the jobs you would most want. The loop here looks like a senior software loop with an infrastructure accent: real code or infrastructure-as-code review, a design round that goes deep on failure modes, and no tolerance for someone who has stopped touching a terminal.

Shape four is the specialist. FinOps or cloud cost architect, cloud security architect, network architect, data platform architect, AI infrastructure architect. The specialism is the gate and general cloud breadth is assumed. A cloud security architect posting is read by security people and wants identity boundary design, segmentation, key management and threat modelling. A FinOps-leaning posting wants a cost model, commitment strategy and unit economics. Applying to these with a generalist resume fails at the screen, because the interviewer is listening for the specialism's failure modes.

There is a fifth pattern worth recognising so you can avoid it: the posting that is really a senior cloud engineer job with the word architect used as a retention device, or an architect job with no decision authority, where the role produces diagrams that delivery teams ignore. Two questions in the screen separate it. Who signs off a design in this company, and what happens when a team declines to follow a standard. If nobody can answer the first and the second answer is nothing, the title is decorative.

Classification takes about two minutes. Read the responsibilities for the possessive: our platform, our customers' environments, the client, the product. Count how many compliance regimes are named, because that tells you how much of the job is paperwork. Check whether a programming language appears as a requirement or only as a nice to have. Look for the word utilisation or billable, which only ever appears in shape two. Then open the employer's other postings on the same careers page, because an organisation with a real cloud architecture function posts several related roles and names the teams they serve.

• Shape one tells: landing zone, governance, standards, architecture review board, cloud centre of excellence, migration programme, named compliance regimes, stakeholder management. Prepare estate scale, migration counts and a governance story.
• Shape two tells: pre-sales, discovery, workshop, proposal, statement of work, proof of concept, partner practice, utilisation, travel. Prepare a customer whiteboard and expect the certification requirement to be real.
• Shape three tells: our product, multi-tenancy, tenant isolation, region strategy, control plane, latency targets, cost to serve, and a language in the required list. Prepare like a staff engineer interview and search for the staff and principal titles too.
• Shape four tells: the specialism appears before or instead of the word cloud, and the tool list is narrow and deep (identity providers and policy engines for security; commitment and allocation tooling for cost; routing, peering and private connectivity for network; accelerators, schedulers and model serving for AI infrastructure).
• A warning sign: one posting asking for landing zone design, hands-on Terraform delivery, a 24/7 on-call rotation, pre-sales support and FinOps ownership is describing an understaffed function, not a broad role. Ask how many people are in the architecture function and how many engineers it serves.
• One question resolves most of it with a recruiter: is this role designing our internal estate, designing for customers, or designing the product we sell? Any decent recruiter knows, and the answer picks your preparation.

What actually gates it: experience at decision scope, not paperwork

Nothing legal gates cloud architecture. There is no licence, no protected title in IT, no required degree and no mandatory exam, and plenty of working cloud architects arrived from systems administration, networking, backend development, data engineering, support or the military. Degrees still act as filters in graduate schemes, in parts of government and defence contracting, and in skilled-worker visa routes where a degree or an assessed equivalent counts toward eligibility. Outside those, the gate is an experience gate with a specific shape: have you owned a decision that would have cost a migration to reverse, and can you defend it in detail two years later.

That is the sentence to internalise, because it explains most rejections. A candidate with eight years of excellent cloud engineering can be turned down for an architect role while a candidate with five years gets it, and the difference is usually that the second one owned the choice rather than implemented it. Panels probe for this with questions that sound simple. Who decided that? What else did you consider? What were you told to do and what did you argue for? If every answer puts the decision somewhere above you, the panel concludes you have been a very good implementer, which is a different job.

On certifications, be clear about what each one buys, because candidates waste months here. At a consulting partner or a managed service provider a professional-level certification in the employer's primary cloud is close to a hard requirement and the firm will fund it, because the partner tier they sell against is counted in certified staff. At a product company the same certificate is a filter pass and nothing more, and the engineers on the panel will not mention it. Nowhere does a certification substitute for the production scar tissue the deep dive is looking for, and a resume that leads with six badges above two years of experience invites exactly the sceptical questioning you do not want.

If you are choosing one credential, choose the professional-level architecture certification in the cloud your target employers actually run, and run it alongside real work rather than instead of it. AWS Certified Solutions Architect Professional, Google Cloud Professional Cloud Architect and Microsoft Certified Azure Solutions Architect Expert all test long constrained scenarios rather than service trivia, which makes studying for them a decent rehearsal for the design round: the skill being examined is picking the option that fits the stated constraint rather than the most impressive option. A second cloud at associate level is worth having if your employers are genuinely hybrid; a second cloud at professional level is usually a worse investment than one more real migration.

Two specialist credentials carry weight where the posting leans their way. FinOps Certified Practitioner from the FinOps Foundation is short, inexpensive and directly relevant on cost-focused postings, and it gives you the vocabulary (allocation, showback, chargeback, commitment coverage, unit economics) that hiring managers in that area use. For security-leaning architecture, CISSP still opens doors in regulated enterprises and government contracting even though it is broad rather than cloud-specific, and the cloud providers' own security specialty exams are a better technical signal. TOGAF is worth having only if you are targeting large enterprises or markets where recruiters screen on it, and it will not impress a product company.

What no certification covers is the half of the job that decides promotions: writing the design down so other people can act on it, running a review in which someone senior disagrees with you, pricing an option before it exists, sequencing a migration so the risky cutover is not the first one, and saying no to a team in a way that leaves them still willing to talk to you. Those are assessed in the interview directly and they are the reason a candidate with three months to invest is usually better off producing one real artefact than collecting a second certificate.

One more real gate, often missed: hands-on currency. The most common quiet rejection for architect candidates is the panel concluding that the person has not touched the platform in three years. Interviewers test it fast, with a question that only a practitioner answers crisply. What does a NAT gateway cost you and how would you avoid it. What breaks first when you put a managed database behind a private endpoint. Read this Terraform plan and tell me which line is destructive. Keep enough hands in the system to answer those without hedging, even if you no longer build day to day.

• The gate in one sentence: you must have owned at least one decision whose reversal would require a migration, and be able to defend it two years later with the numbers attached.
• Worth doing if you target partners and consultancies: the professional-level architecture certification in their primary cloud, because it is a commercial requirement there rather than a signal.
• Worth doing if the posting leans at cost: FinOps Certified Practitioner, measured in days rather than months, mainly for the shared vocabulary.
• Worth skipping: a second professional-level cloud certification, generic Agile and Scrum certificates, and vendor badges for tools the employer does not use. None of these appear in an architect hiring decision at a product company.
• Worth reading instead, because interviewers use the vocabulary and expect you to know it: the AWS Well-Architected Framework pillars, the Microsoft Azure Well-Architected Framework and Cloud Adoption Framework, the Google Cloud Architecture Framework, the FinOps Foundation's framework, and the four DORA delivery measures. These are free and they are the language of the review conversation you will be asked to run.
• Put an active security clearance in the top third of the resume with the level and the year of last investigation, because for cleared roles it is the first filter applied and the absence of it ends the conversation regardless of your design skill.
• Keep one honest line about your hands-on currency, such as the last thing you personally built or debugged and when. Volunteering it is far better than being caught by a probe.

The five artefacts that prove architect level

If you want to step up to architecture, stop thinking about years and start thinking about artefacts. There is a short, stable list of documents that a panel treats as proof. Each one is something you can produce in your current job without permission, and each one answers a question an interviewer will ask you anyway. Produce them, keep sanitised copies, and the deep dive stops being a memory test and becomes a walkthrough.

Artefact one is the account and network topology. Not a pretty diagram: the decisions. How many accounts or subscriptions and on what boundary (environment, business unit, blast radius, billing), the organisational unit structure, which preventive controls are enforced centrally and which are advisory, the network pattern and why (hub and spoke, transit gateway, cloud WAN, or deliberately flat because the estate is small), the IP address plan and who owns it, how private connectivity to on-premises works and what happens when it fails, where logs and audit trails land and who can read them, how break-glass access works and who signs for it, and how a new team gets a working account in a day rather than a month. The strongest version of this artefact includes the thing you chose not to centralise and why.

Artefact two is the migration plan with the results next to it. An application inventory with a count, a disposition per application across the seven standard options (retire, retain, rehost, relocate, replatform, repurchase, refactor), the dependency mapping method you used, the wave sequence with the reasoning for what went first, the cutover runbook with its rollback point and the go/no-go criteria, and the data migration method per class of system. Then the part most candidates omit: what actually happened. How many applications moved, over how many months, how many waves slipped and why, downtime per cutover against what you promised, whether you ever used the rollback, what you retired instead of moving, and the run cost before and after. A plan with no outcome reads as a slide. A plan with outcomes, including the wave that went badly, reads as experience.

Artefact three is the cost model. Two halves. The first is a model of what a design costs before it is built, broken into the lines that actually move: compute with a commitment assumption, storage by tier and growth rate, data transfer including cross-zone and egress, managed service minimums and idle cost, logging and observability ingest, licensing, and support. The second is unit economics, which is the thing that marks you as an architect rather than a cost cutter: cost per tenant, per active user, per transaction, per thousand requests, per gigabyte ingested, per model call. Then one reduction you can attribute to a method rather than to a season: a rightsizing exercise with the measurement that justified it, commitment coverage raised from one figure to another, a storage lifecycle policy, an architectural change that removed cross-zone chatter or an egress path, idle environments shut down on a schedule, or a managed service swapped because the minimum was larger than the workload. Always say the base, the method and the period, because a saving without a base is not a number.

Artefact four is the resilience specification with a test behind it. RTO and RPO stated per service tier rather than per company, the failure domains you designed against (instance, zone, region, provider, dependency, human error, corrupted data), the recovery mechanism per tier, and the result of the last time you tested it with the date. The most persuasive version includes a region strategy you argued against: you looked at active-active across regions, priced it, found the business tolerance was two hours rather than two minutes, and built multi-zone with tested restore instead. Panels mark that higher than a multi-region design nobody asked for, because it shows you let the requirement pick the architecture.

Artefact five is a set of architecture decision records. One page each, in a consistent form: the context and the constraint, the options considered, the decision, the consequences accepted, and the condition that would make you revisit it. Write them for decisions your team is making right now, even small ones, even if nobody asked. Six months of this gives you exactly the material a past-decision deep dive wants, in your own words, with the rejected options already written down. It is the single highest-return habit for someone trying to move into architecture, and it costs an hour a week.

A sixth artefact is worth having if your target is shape one: the adoption record for a standard you wrote. A reference architecture or a set of approved modules, how many teams adopted it, how long adoption took, how many exceptions you granted and on what grounds, and whether you ever retired the old pattern. Governance that exists only as a document is not evidence. Governance with an adoption number and an exception log is.

• Sanitise, do not skip. Replace customer names, internal hostnames, IP ranges and absolute spend with ratios and orders of magnitude, then say out loud that you have sanitised it. Panels respect that; they do not respect a candidate who brings a client's live diagram.
• Each artefact needs a count, a unit and a date. Twelve accounts, four organisational units, 180 applications, nine waves, eleven months, 40 minutes of downtime per cutover, RPO of five minutes for tier one, last tested in March.
• Keep one artefact per shape. A landing zone and an adoption record for enterprise roles, a migration plan and a customer-facing design for partner roles, a multi-tenancy and cost-to-serve design for product roles.
• Write the decision you got wrong into the artefact rather than hiding it. Every panel asks, and an answer with the correction and the cost attached outperforms a flawless record that sounds rehearsed.
• If you do not have these yet, pick the one your current job already contains. Almost every team has an undocumented cost problem, an untested restore, and a decision nobody wrote down. Those are three artefacts sitting in plain sight.
• Do not bring a slide deck to a technical round unless asked. Bring the numbers in your head and draw on the whiteboard. Architects who can only present are a recognised failure mode and interviewers screen for it.

How the loop actually runs, and who screens you

The process for an experienced architect role runs two to five weeks at a product company or a partner, and routinely six to twelve weeks at a large enterprise or in government, where an architecture appointment goes through a panel, sometimes a board, and occasionally a written submission. Expect four to six conversations. The variation between the four shapes is mostly in who is in the room, not in the stages themselves.

The first screen is a recruiter and it is a matching exercise, not an assessment. They are checking the cloud (an estate on Azure will usually not shortlist a pure AWS architect for an internal role, however transferable the thinking is), the scale, the industry if it is regulated, the certification if the employer is a partner, location and clearance, and the salary band. Give them crisp numbers in the first two minutes: the cloud, the spend under your remit, the number of applications or accounts, the regulated regime if any, and the size of the biggest migration you have run. Recruiters pass on candidates they can summarise.

The second conversation is the hiring manager, and it is really about scope and authority. They want to know what decisions you have made rather than what systems you have touched, and they are deciding whether your scope matches theirs. This is the right place to ask your own scope questions: who signs off a design here, is there an architecture review forum and does the architect chair it, does the role carry delivery accountability or advisory only, how many teams does the function serve, and is the estate mid-migration or post-migration. The answers change the job more than the title does.

The third stage is the architecture design round and it is the one that decides most outcomes. Sixty to ninety minutes, open prompt, a whiteboard or a shared drawing tool. The prompts repeat across employers: migrate an estate of a named size within a named deadline; design a multi-tenant SaaS for customers who require data residency in three regions; design the landing zone for an organisation of forty engineering teams; take a system and meet a stated RTO, then tell me what it costs; or our bill tripled in a year, find it. The next section covers what reviewers are marking, because this round is scored on behaviour at least as much as on the design that ends up on the board.

The fourth stage is a deep dive on your own past work, often with the most senior person you will meet. It goes from the diagram down to a specific failure: why that database, what you did when the cutover window closed early, what the design cost, what you would do differently. Being unable to name a design you got wrong is close to disqualifying at this stage, because every architect with real mileage has one, and a candidate without one is either junior or not candid. Prepare one properly: the decision, the constraint you misread, the symptom that revealed it, the correction, the cost of the correction, and the rule you adopted afterwards.

The fifth stage varies by shape and is where candidates are least prepared. At a product company it is an engineering round with code or infrastructure as code: review a Terraform plan and name the destructive line, write a small script, read someone else's module and say what is wrong with it. At a consulting partner it is a customer simulation, where two or three people play a client with a budget, a deadline and a preferred wrong answer, and you are marked on whether you listened before drawing. In regulated enterprises it is a compliance and security round about identity boundaries, data classification, encryption and key custody, logging retention and evidence for auditors. In cost-leaning roles it is an explicit money round. Ask the recruiter what the stages are; almost all of them will tell you, and the answer changes what you rehearse.

The final stage is usually a stakeholder or executive conversation, with an engineering director, a CIO or CTO, or a business owner. It is not technical. They are testing whether you can explain a trade-off to someone who controls the budget without jargon and without pretending the risk away. Prepare three sentences that explain your biggest design in business terms: what it let the company do, what it cost, and what you accepted as a risk. If you cannot do that, this round goes badly however well the design round went.

• Typical stage list: recruiter screen, hiring manager scope conversation, architecture design round (60 to 90 minutes), past-design deep dive with a principal or head of architecture, a shape-specific round (code and IaC, customer simulation, security and compliance, or cost), then an executive conversation.
• Enterprise and public sector additions: a panel with set questions and scoring, sometimes a written design submission or a presentation to a review board, and references taken seriously. Timelines run in weeks rather than days and silence between stages is normal rather than a signal.
• Partner and consultancy additions: a mock customer whiteboard, a proposal or statement of work exercise, and questions about utilisation, travel and how you behave when the client is wrong.
• What the recruiter screen is really filtering: the cloud, the regulated industry, the certification if it is a partner, the clearance, the location, and whether your scale is within an order of magnitude of theirs.
• Ask for the design round format in advance: whiteboard or shared document, whether you may ask questions throughout, and whether cost is in scope. All three change your preparation and asking reads as professional rather than nervous.
• Bring your own questions to every stage and make at least one of them about authority. Who signs off a design, what happens when a team declines a standard, and what the last exception granted was. Candidates who ask these sound like architects; candidates who ask only about technology sound like engineers.
• If a process has no design round at all, be curious rather than relieved. An architect role with no design assessment often means the function has no decision authority, and you should ask directly what the last significant decision the architecture team made was.

The resume: scale, decisions and money, in that order

An architect resume fails differently from an engineer resume. The engineer version fails on missing tools. The architect version fails because the reader cannot tell what you decided or at what scale, so there is nothing to calibrate against. Every bullet should let a reader answer two questions without asking: how big was this, and what did you personally choose.

Open with a four or five line summary that is pure calibration, not adjectives. The cloud or clouds and the depth in each, the scale under your remit (accounts or subscriptions, applications, monthly spend as an order of magnitude, users or tenants, regions), the industries and any regulated regime you have delivered under, the biggest migration you have run stated as a count and a duration, and the specialism if you have one. A reader should be able to place you in a band in fifteen seconds. If you have a clearance, it goes here.

Then write bullets around decisions with numbers in front. The pattern that works: the decision, the scale, the constraint that drove it, the measured outcome. Designed the account topology for a 40-team organisation on a blast-radius boundary, 14 accounts and 4 organisational units with preventive controls enforced centrally, cutting new-team provisioning from six weeks to two days. Dispositioned 180 applications across the seven migration options, retiring 31 of them, and moved the remainder in nine waves over eleven months with a maximum cutover downtime of 40 minutes against a promised two hours. Rejected active-active multi-region after pricing it against a two-hour business tolerance and delivered multi-zone with quarterly tested restore, keeping the resilience budget inside the agreed figure. Each of those tells a reader what you own.

Money belongs on an architect resume and most candidates leave it off. Monthly or annual spend under your design is a scale signal, and reductions are an outcome signal, but a reduction without a method and a base is not credible. Write the method. Raised savings plan and reserved capacity coverage from a low fraction to most of the steady-state fleet. Removed a cross-zone data path that accounted for a large share of transfer cost. Introduced cost allocation tagging and took allocation coverage from partial to near complete, which is what made the rest possible. If you cannot share absolute figures, use ratios and say explicitly that the figures are ratios because the employer was confidential. Panels accept that; they do not accept vagueness.

Know what gets ignored or actively counts against you. A thirty-service logo list proves nothing, because every cloud architect has touched most of them; keep one compact skills block at the bottom for the keyword screen and nothing more. Claiming expert across AWS, Azure and Google Cloud reads as shallow and invites a brutal depth probe in whichever one you know least. A certification wall above a thin experience section reads as compensation. Phrases like designed scalable, highly available, secure solutions are filler, because nobody designs unscalable insecure ones on purpose. And a single lift and shift from years ago described as a cloud transformation dates you badly; if your most recent architecture work is old, lead with what is current.

Tailor by shape, because the same career supports different documents. For enterprise roles, lead with estate scale, migration counts, governance and adoption, and name the compliance regimes. For partner roles, lead with the number and variety of client environments, the deals or proposals you supported, the certifications, and the industries. For product roles, lead with the system you designed, the tenancy and region model, the latency and availability targets you actually hit, the cost to serve, and the fact that you still write code. For specialist roles, lead with the specialism's own metrics and let the general cloud work sit underneath.

Two practical mechanics. Applicant tracking systems still parse plainly, so keep it to a single column with real headings, no text inside images, and put the literal job title you are applying for somewhere in the document if it honestly describes you, because Cloud Architect, Cloud Solutions Architect and Cloud Infrastructure Architect are searched as different strings. And keep a one-page architecture portfolio separate from the resume: three sanitised artefacts, one page each, that you can send when a hiring manager asks for an example. Very few candidates have one, and it ends the question of whether you have really done the work.

• Lead the summary with calibration: clouds and depth, accounts or subscriptions, applications, spend order of magnitude, tenants or users, regions, regulated regimes, biggest migration as a count and a duration.
• Bullet pattern: decision, scale, driving constraint, measured outcome. If a bullet has no number and no decision, it is a duty, not evidence, and it should be cut.
• Always include at least one rejected option. Chose X over Y because of Z constraint is the single most architect-sounding sentence on a resume, and it survives every follow-up because you already know the reasoning.
• State cost work with a method and a base, or as ratios if the employer was confidential. Say which it is.
• Cut: thirty-service logo lists, expert in three clouds, designed scalable and secure solutions, responsible for, and any certificate older than its renewal window presented as current.
• Name the compliance regimes you have actually delivered under (PCI DSS, HIPAA, SOC 2, ISO 27001, FedRAMP, a sector regulator) rather than claiming compliance experience generally, because the screen for regulated roles searches for the specific regime.
• Keep a separate one-page architecture portfolio of three sanitised artefacts, ready to send the moment a hiring manager asks for an example of your work.

The architecture design round: what reviewers are actually marking

The design round is scored on behaviour as much as on the diagram, and the marking is more consistent across employers than candidates expect. Interviewers are watching for a sequence: did you establish what is actually required before designing, did you name the constraint that drives the shape, did you consider and reject a cheaper option out loud, did you reason about failure and blast radius, did you price it at least roughly, did you say what you would not build, and did you finish with a sequence for getting there from the current state. Candidates who jump to a diagram in the first three minutes lose most of those marks regardless of how good the diagram is.

Spend the first five to ten minutes on requirements and write them on the board where everyone can see them. Who uses this and how many of them. Request rate at peak and the shape of the peak. Data volume now and growth per year. Latency target and at which percentile. RTO and RPO, per tier if the tiers differ. Compliance regime and data residency constraints. Budget, or at least whether cost or speed is the binding constraint. The deadline and what happens if it slips. And the team: how many engineers, what they already run, what they are on call for. That last one is a legitimate design input and most candidates never ask it, which is exactly why asking it stands out. A design that requires a Kubernetes platform team at a company with four engineers is a wrong answer however elegant.

Then say the constraint out loud before you draw. This design is driven by the residency requirement, so I am starting from the region topology. Or this is driven by the eleven-month deadline, so the first wave has to be rehost and the refactoring comes later. Naming the driver tells the interviewer you are optimising for something real, and it gives the rest of the hour a spine. Interviewers write that sentence down.

Reject something cheaper, explicitly. This is the most reliable single way to look senior. The cheaper option is almost always one of: a single region instead of several, multi-zone instead of multi-region, a managed service instead of a self-run one, one shared database instead of per-tenant isolation, a scheduled batch instead of streaming, a queue instead of an event platform, rehost now and replatform later, or buying instead of building. Price it, say what it fails to deliver against the requirements you wrote on the board, and only then take the more expensive path. A candidate who arrives at the expensive design without visibly considering the cheap one reads as someone who will overspend the company's money.

Price the design in line items, not in a total. Say which lines dominate: compute and whether you assume commitments, storage by tier and growth, data transfer across zones and out to the internet, managed service minimums and anything that charges while idle, logging and observability ingest (which surprises people more often than compute does), licensing, and support plan. Then say the order of magnitude and that you would verify against current pricing rather than quoting a figure from memory. Saying I would check current rates is a strength here, not a weakness, because inventing a price is a tell that you have never owned a bill. Interviewers mainly want to see that you know which lines move.

Reason about failure concretely rather than saying highly available. Pick a component and walk it: this zone disappears, what breaks, what is the user impact, what recovers automatically and what needs a human, how long. Then do the awkward ones that candidates skip: the shared dependency that takes everything with it, a bad deploy, a credential expiring, a quota being hit, a region-level provider outage, and corrupted or deleted data, which is the failure a multi-region design does not help with at all. Say where the blast radius boundary sits and which account, subscription, network or key boundary enforces it. Then say what you would monitor to know it is working and what alert would page a human.

Finish with the two things most candidates run out of time for, which means you should budget for them: what you are deliberately not building, and how you get there from where the company is today. The refusal list is short and specific: not multi-cloud, not multi-region in phase one, not a service mesh at this team size, not per-tenant infrastructure until a customer pays for it, not a custom control plane when a managed one exists. The migration sequence is a phase plan with a first wave chosen because it is low risk and informative, a point at which you would stop and re-measure, a rollback position, and the first metric you would look at after go-live. Ending there, rather than on the diagram, is what separates a design from an architecture.

• Common prompts: migrate an estate of N applications in M months; design a multi-tenant SaaS with residency in three regions; design a landing zone for forty teams; meet a stated RTO and price it; the bill tripled, find it; connect three clouds and a datacentre; design for a regulated workload under a named regime.
• First ten minutes, out loud: users, peak rate, data volume and growth, latency target and percentile, RTO and RPO per tier, compliance and residency, budget or the binding constraint, deadline, and the size and skills of the team that will run it.
• Say the driving constraint before you draw, then design from it. Interviewers record that sentence as evidence of senior reasoning.
• Always reject a cheaper option explicitly and say what it failed to deliver. This is the single highest-value behaviour in the round.
• Price in line items and name the dominant ones, then say you would verify current rates. Do not invent per-unit prices.
• Walk at least three concrete failures including data corruption or deletion, which multi-region does not solve, and name the boundary that contains each blast radius.
• Reserve the last ten minutes for the refusal list and the migration sequence, with a rollback position and the first metric you would check after go-live.
• Keep the whiteboard legible and labelled, and restate the design in four sentences at the end. A reviewer who has to reconstruct your design from an unlabelled diagram scores communication down, and communication is half the job.

The questions that decide it, and how to answer them

A handful of questions recur in almost every cloud architect loop, and the strong answers have a shape in common: a number, a decision, a trade-off named honestly, and a consequence you lived with. Rehearse these out loud, because the failure mode is not ignorance, it is rambling.

Walk me through an architecture you own, end to end. Give the shape in four sentences before any detail: what the system does, the scale, the two or three decisions that define it, and the one thing you would change. Then let them steer. The mistake is starting at a component and narrating upward, which uses twenty minutes and never reaches a decision. Have the numbers ready: requests, data volume, spend, availability achieved, team size.

Tell me about a design decision you got wrong. Answer with the constraint you misread rather than with bad luck. I chose a single shared database for tenant data because the first eight customers were small, and I misjudged how fast one would grow; the symptom was noisy-neighbour latency on the largest tenant within a year; we extracted that tenant to dedicated capacity in a quarter, which cost roughly one engineer quarter of unplanned work; since then I ask for the expected distribution of customer size, not the average, before choosing a tenancy model. Constraint, symptom, correction, cost, rule. Never answer that you cannot think of one.

What drives your current cloud bill? This question separates architects from diagram producers in about forty seconds. You should be able to name the top three or four lines in rough proportion, say which of them is growing fastest, name the cheapest thing you have not yet fixed and why, and say what your commitment coverage is. If you genuinely do not know, say that you do not own the bill and then say what you would look at first, in order: allocation coverage, the largest line item, idle and orphaned resources, data transfer paths, logging ingest, and commitment coverage against the steady-state fleet.

When would you not go multi-region, and when is multi-cloud right? Both of these are maturity tests disguised as architecture questions. The honest answer on regions: multi-region costs you duplicated capacity, data replication, replication lag you have to design around, a much harder consistency story and a traffic management layer, so it is justified by a business tolerance measured in minutes, by residency requirements, or by latency to distant users, and not by a general wish to be resilient. Most organisations get better availability per pound from multi-zone with tested restore. On multi-cloud: portability costs you the managed services that make a cloud worth using and doubles the identity, networking, observability and skills surface, so the defensible versions are specific rather than general. An acquisition you have to run, a regulator or customer contract that requires it, a single workload placed deliberately where it runs best, or a commercial lever in a negotiation. Choosing multi-cloud as an abstract hedge is the answer that costs people this round.

How do you get teams to follow a standard when they do not report to you? Answer with a mechanism rather than with influence as a personality trait. Make the compliant path the easiest path, so an approved module or a provisioned account does more than a document ever will. Enforce the small number of things that are genuinely non-negotiable with preventive controls rather than review, because a control that cannot be bypassed does not need persuading. Make everything else advisory with a visible exception process that has an owner, an expiry date and a recorded reason, because an exception with an expiry is a negotiation and an exception without one is a permanent fork. Then show the adoption number, which is what tells the interviewer this actually happened.

What would you do in your first ninety days? Resist the urge to propose a target architecture. The answer that lands: read the bill and the account structure, find out what is already decided and by whom, list the top risks by what would hurt most if it failed, test one restore, talk to the delivery teams about what currently slows them down, and only then publish a short set of decisions with the reasoning. Then name the one thing you would fix immediately regardless, usually an identity or blast-radius problem or an untested backup, because an architect who changes nothing in a quarter is not useful and one who redesigns everything in a quarter is dangerous.

• Have ready, with numbers: one system you own end to end, one decision you got wrong, one cost reduction with a method, one failover you tested, one standard you got adopted, and one time you said no to a senior stakeholder and what happened next.
• Rehearse the four-sentence version of your biggest design, and a non-technical version of the same thing for the executive round. Both get asked.
• Expect at least one hands-on probe: read a Terraform plan and name the destructive line, explain why a private endpoint broke name resolution, say what a NAT gateway costs you and how to avoid it, or explain the difference between a security group and a network access control list and when each one bites.
• Expect one identity question with real depth: how you would grant a workload access across accounts without a long-lived key, where you draw the permission boundary, how you handle break-glass, and how you would detect a role that has quietly become too wide.
• Ask your own authority questions, and ask them in every loop: who signs off a design, does the architecture function chair its own review, what was the last exception granted, and is the estate mid-migration or post-migration.
• If you are asked a question about a service you have not used, say so in one clause and reason from the primitives it is built on. Interviewers mark bluffing far harder than gaps, and architects are expected to meet unfamiliar services weekly.

Stepping up without the title yet, and reading the offer

Most cloud architects were cloud, platform, infrastructure, network or backend engineers first, and the move is rarely a clean external jump. The gate is having owned a decision at architect scope, and the cheapest place to acquire that is the job you already have, which is why an internal move is usually easier than an external one: your employer can already see the decisions you made, while an external panel can only hear you describe them.

Start by producing architect output without the title. Write architecture decision records for the choices your team is making this quarter and circulate them, because the act of writing options and consequences down changes how people treat you within a few weeks. Volunteer for the work nobody wants that is secretly architecture: the cost review, the disaster recovery test, the vendor evaluation, the security exception nobody wants to own, the production readiness review, the capacity forecast, the cross-team design review. Each one produces an artefact and a story. Then ask the current architect to co-author the next reference architecture with you, which is both a mentorship and a credential.

Pick the entry route that matches your situation honestly. If you are at a large organisation with an architecture function, the internal route is: artefacts, then a visible design someone senior sponsored, then the first vacancy. If you are at a small company with no architect title, you are probably already doing parts of the job and the issue is evidence, so document what you decide and target scale-ups rather than enterprises, because an enterprise panel wants scar tissue you cannot have yet. If you have narrow depth and need breadth fast, a consulting partner or managed service provider is the most efficient accelerator available: several migrations a year, many estates, funded certifications, and a two-year resume that an internal role takes six years to build. The cost is real and you should go in knowing it: utilisation pressure, travel or at least client hours, less depth per system, and the risk of becoming fluent in proposals and rusty in production.

If you are coming from outside infrastructure, there are two viable bridges and one dead end. From software engineering, the bridge is owning the deployment, cost and resilience of a system you wrote, then generalising it. From networking or systems administration, the bridge is identity and the landing zone, because the organisational boundary work is closer to what you already do than application design is. The dead end is certifications with no production exposure: it produces candidates who can describe services and cannot answer what happened the one time it broke, and panels identify them in the first ten minutes.

On timing, be realistic about the market you are applying into. Cloud migration is no longer new, which changes the mix of jobs: there are fewer greenfield programmes and more work in optimisation, consolidation, cost reduction, repatriating workloads that were wrongly placed, regulated and sovereign requirements, and building the infrastructure for AI workloads. That is good news for anyone with operating and cost evidence and bad news for anyone whose only story is a migration finished years ago. If your experience is mostly the initial move to cloud, add one current artefact before you apply: a cost model, a tested restore, a consolidation, or an accelerator placement decision.

When an offer arrives, read the role rather than the title. Ask whether there is an architecture review forum and whether this role sits on it. Ask who can overrule a design and how often that has happened. Ask whether the role carries delivery accountability or is advisory, because advisory architects in organisations that do not want advice have short tenures. Ask the spend under the function's remit and the number of engineers it serves, which together tell you the real scope. Ask whether the estate is mid-migration or post-migration, because a post-migration architect job is mostly governance and cost, and some people love that and some people leave within a year. At a partner, ask the utilisation target and whether architects carry pre-sales expectations, and get the answer as a number. And ask what the last significant decision the architecture function made was, because the answer tells you more about the job than the job description does.

One last check before you sign: find out whether the title sits on the engineering ladder or in a separate architecture band, because that determines your next promotion and often your equity. At a product company an architect is usually a staff or principal individual contributor and the path onward is clear. In an enterprise architecture band the path onward may be management or nothing, and the band tends to pay less than the equivalent product-company level. Neither is wrong, but find out which one you are joining before you negotiate, not after.

• Four weeks of unglamorous work that changes an interview: write three architecture decision records for choices already being made, run one cost review and produce a model with unit economics, test one restore and write the result with a date, and document the account topology you already have including what you would change.
• Volunteer for these specifically: cost reviews, disaster recovery tests, vendor evaluations, security exceptions, production readiness reviews, capacity forecasts, cross-team design reviews. They are architecture work in disguise and nobody competes for them.
• Fastest breadth accelerator: a consulting partner or managed service provider, for the number of estates and the funded certifications. Known costs: utilisation pressure, travel, less depth, and the risk of drifting out of production.
• Search the titles that hide the job: Cloud Solutions Architect, Cloud Infrastructure Architect, Principal Cloud Engineer, Staff Infrastructure Engineer, Platform Architect, Solutions Architect, Enterprise Architect (cloud). At product companies the role you want is often advertised as principal engineer.
• Where the roles are in 2026 and 2027: optimisation and cost, consolidation, workload repatriation, sovereign and regulated estates, and infrastructure for AI workloads. Fewer pure greenfield migrations than three years ago.
• Offer questions worth more than the salary conversation: who signs off a design, what was the last exception granted, is this ladder engineering or a separate architecture band, is the estate mid-migration or post-migration, what is the spend under this function, and at a partner what is the utilisation target as a number.

What a screen is looking for

These are the terms that a resume screen, human or automated, is matching against for this role. Use the ones that are true of you, in the words the posting uses.

• Cloud Architect
• Cloud Solutions Architect
• Cloud Infrastructure Architect
• Solutions Architect
• Enterprise Architect
• Principal Cloud Engineer
• Staff Infrastructure Engineer
• Platform Architect
• Cloud Engineer
• Infrastructure Architect
• Security Architect
• Network Architect
• Data Platform Architect
• AI Infrastructure Architect
• AWS
• Amazon Web Services
• Microsoft Azure
• Google Cloud Platform
• GCP
• Oracle Cloud Infrastructure
• Hybrid cloud
• Multi-cloud
• Private cloud
• Sovereign cloud
• Landing zone
• AWS Control Tower
• AWS Organizations
• Service control policies
• Azure Landing Zone
• Management groups
• Azure Policy
• Google Cloud organization policy
• Resource hierarchy
• Account topology
• Subscription design
• Blast radius
• Guardrails
• Preventive controls
• Detective controls
• Policy as code
• Open Policy Agent
• Rego
• Conftest
• Checkov
• Cloud Custodian
• Well-Architected Framework
• Well-Architected Review
• Cloud Adoption Framework
• Google Cloud Architecture Framework
• Reference architecture
• Architecture decision record
• ADR
• Architecture review board
• Design authority
• Cloud Centre of Excellence
• Technology standards
• Exception process
• Cloud migration
• Migration strategy
• 7 Rs
• Rehost
• Replatform
• Refactor
• Repurchase
• Relocate
• Retire
• Retain
• Lift and shift
• Application portfolio assessment
• Dependency mapping
• Migration wave plan
• Cutover runbook
• Rollback plan
• Go/no-go criteria
• AWS Migration Hub
• Azure Migrate
• Database Migration Service
• Datacentre exit
• Workload repatriation
• Mainframe modernisation
• VMware migration
• Multi-tenancy
• Tenant isolation
• Noisy neighbour
• Control plane
• Data plane
• Region strategy
• Data residency
• Data sovereignty
• Availability zones
• Multi-region
• Active-active
• Active-passive
• Pilot light
• Warm standby
• RTO
• RPO
• Disaster recovery
• DR test
• Failover testing
• Backup and restore
• Immutable backups
• Business continuity
• SLA
• SLO
• SLI
• Error budget
• Chaos engineering
• Game day
• Infrastructure as code
• Terraform
• OpenTofu
• Terraform modules
• Module versioning
• Remote state
• Terragrunt
• Pulumi
• AWS CDK
• CloudFormation
• Bicep
• ARM templates
• Ansible
• Packer
• GitOps
• Argo CD
• Flux
• Kubernetes
• EKS
• AKS
• GKE
• OpenShift
• Helm
• Serverless
• AWS Lambda
• Azure Functions
• Containers
• ECS
• Fargate
• Cloud Run
• Event-driven architecture
• Microservices
• Modular monolith
• API gateway
• Service mesh
• Message queue
• SQS
• Kafka
• Event Hubs
• Pub/Sub
• Caching
• CDN
• CloudFront
• Networking
• VPC
• VNet
• Hub and spoke
• Transit Gateway
• Cloud WAN
• VPC peering
• PrivateLink
• Private endpoints
• Direct Connect
• ExpressRoute
• Cloud Interconnect
• VPN
• BGP
• DNS
• Route 53
• IPAM
• Subnetting
• Network segmentation
• Security groups
• Network ACLs
• Egress control
• Firewall
• WAF
• DDoS protection
• Zero trust
• IAM
• Identity federation
• Single sign-on
• SAML
• OIDC
• OIDC federation
• Workload identity
• Least privilege
• Permission boundaries
• Privileged access
• Break-glass access
• Machine identity
• Non-human identity
• Short-lived credentials
• Secrets management
• HashiCorp Vault
• KMS
• Key management
• Customer managed keys
• BYOK
• Encryption at rest
• Encryption in transit
• Certificate management
• Data classification
• Audit logging
• CloudTrail
• Centralised logging
• SIEM
• Compliance
• PCI DSS
• HIPAA
• SOC 2
• ISO 27001
• FedRAMP
• GDPR
• DORA regulation
• Regulatory reporting
• Evidence collection
• FinOps
• Cloud cost optimisation
• Cost model
• TCO
• Unit economics
• Cost per tenant
• Cost to serve
• Showback
• Chargeback
• Cost allocation tagging
• Reserved instances
• Savings Plans
• Committed use discounts
• Commitment coverage
• Rightsizing
• Autoscaling
• Spot instances
• Karpenter
• Storage lifecycle policies
• Data transfer costs
• Egress charges
• Idle resource elimination
• Budgets and alerts
• AWS Cost Explorer
• Azure Cost Management
• Kubecost
• OpenCost
• Capacity planning
• Quota management
• Observability
• OpenTelemetry
• Prometheus
• Grafana
• CloudWatch
• Azure Monitor
• Distributed tracing
• Incident response
• Postmortem
• Runbook
• On-call
• Change management
• CAB
• DORA metrics
• Deployment frequency
• Lead time for changes
• Change failure rate
• Time to restore service
• GPU
• Accelerators
• Accelerator quota
• Reserved capacity
• GPU scheduling
• Model serving
• Inference
• Inference cost
• LLM gateway
• Model routing
• Prompt caching
• Spend caps
• Rate limiting
• Token spend
• Retrieval augmented generation
• Vector database
• AI governance
• EU AI Act
• Model risk
• Human oversight
• AI coding agents
• Agent identity
• Human approval gate
• Sandbox accounts
• Shadow AI
• Stakeholder management
• Executive communication
• Technical writing
• Whiteboarding
• Pre-sales
• Discovery workshop
• Statement of work
• Proof of concept
• Proposal
• Utilisation
• Partner practice
• TOGAF
• AWS Certified Solutions Architect Professional
• Google Professional Cloud Architect
• Azure Solutions Architect Expert
• AZ-305
• AZ-104
• CKA
• CISSP
• FinOps Certified Practitioner
• Security clearance

Mistakes that cost people this job

Questions people ask