Cohesyve · Practice for candidates
Preparing for a Cloud Architect role? Start by finding out where you stand.
Import the actual job you're going for, run a simulation built from it, and get a scored report showing which of these areas you're weakest in — before you spend weeks studying the wrong thing.
3
free assessments
$0
no card required
Full
scored report every run
Every
question type included
3 free assessments · No card required · Pro from $16/mo
Overview
Cloud architect interviews are conversations about trade-offs, and they are unforgiving of candidates who present one preferred architecture regardless of context. You will be asked to design for constraints that conflict — cost against resilience, speed of delivery against governance, autonomy against standardisation — and to defend your choices when the interviewer changes a requirement. Expect a long design round, a cost and governance discussion, a migration scenario and at least one stakeholder conversation. Preparation is mostly about rehearsing structured reasoning aloud, not memorising service names.
The hiring process, stage by stage
Recruiter and hiring manager screen
Covers your primary cloud platform, the size and nature of estates you have designed for, whether the role is customer-facing or internal, and how much hands-on work you still do.
How to prepare: Prepare a summary of two architectures you owned, with the constraint that shaped each one. Be clear about whether you implemented, advised or governed, since architect roles differ enormously on this axis.
Architecture design interview
A long open-ended design for a described business scenario, typically ninety minutes. The interviewer will change requirements mid-way — a new compliance constraint, a tighter recovery objective, a budget cut — to test whether your design is reasoned or rehearsed.
How to prepare: Practise starting with requirements: users, load, data residency, recovery time and point objectives, budget and team capability. Draw the design incrementally and state a trade-off with every choice. Rehearse changing your own design gracefully when a constraint moves.
Cost, governance and security review
Questions on landing zones, account and subscription structure, identity, network segmentation, tagging, guardrails and cost accountability. Often includes a scenario about a cloud bill that has grown faster than the business.
How to prepare: Prepare a clear position on multi-account structure and why, on preventative guardrails versus detective controls, and on making cost visible to the teams that generate it. Have a concrete example of a cost reduction and the mechanism behind it.
Migration or modernisation scenario
You are given a legacy estate and asked to plan a move to the cloud, including sequencing, risk, dependencies and what you would deliberately not modernise.
How to prepare: Rehearse a staged approach: discovery and dependency mapping, wave planning, the pattern chosen per application, data migration and cutover, and rollback. Be ready to argue for rehosting some workloads rather than rewriting everything.
Stakeholder and influence interview
A conversation with engineering leadership or a business stakeholder about how you get an architecture adopted, handle disagreement with a strong-willed team, and communicate risk to people who do not want to hear it.
How to prepare: Prepare an example where your recommendation was rejected and what you did, and one where you changed your position after a team pushed back. Practise explaining a technical risk in commercial terms.
What to study
Requirements-led design and trade-offs
The design round scores your reasoning, not your architecture, and a design proposed before requirements are established fails regardless of quality.
Resilience and recovery design
Recovery time and recovery point objectives are the questions interviewers use to check whether your resilience claims are grounded.
Landing zones, identity and governance
Most architect roles inherit an estate that grew without structure, and governance questions dominate the practical side of the interview.
Cost architecture
Cloud cost is now an executive-level concern, and architects are expected to design for it rather than optimise after the fact.
Migration and modernisation patterns
Many architect roles exist because of a migration, and interviewers want realism about sequencing rather than an aspirational end state.
Cohesyve for candidates
Practise a Cloud Architect assessment before the real one
Run the same AI job simulations companies use to evaluate applicants. You get a scored report showing where you're strong and where you're not, plus what to work on.
Your preparation plan
Four weeks out
Consolidate your own architectural history and fill platform gaps
- •Write up two architectures you owned, each framed around the constraint that drove the design
- •Revise resilience patterns until you can state the recovery objectives your designs actually met
- •Study the specific cloud platform named in the job description if it is not your primary one
- •List the governance areas you have avoided — identity at scale, network segmentation, policy enforcement — and study them
Two weeks out
Practise the long design round aloud with moving requirements
- •Run three ninety-minute design exercises out loud, covering a customer-facing platform, a data platform and a regulated workload
- •Have someone change a requirement halfway through each one and practise adapting without defensiveness
- •Prepare a cost reduction story with the architectural mechanism, not just the figure
- •Rehearse explaining a technical risk to a commercial stakeholder in under two minutes
The final week
Rehearse end to end and prepare for the stakeholder round
- •Sit one full-length timed assessment rather than isolated design questions, since the long round tests stamina and structure
- •Read the company's public engineering material and infer their likely platform constraints
- •Prepare your questions about decision rights, governance and how architecture actually gets adopted there
- •Practise drawing clearly on the tool the interview will use, since illegible diagrams cost you
The day before and the day of
Arrive with a method rather than a preferred architecture
- •Test the whiteboard or diagramming tool and your screen share
- •Reread your two architecture write-ups once and stop
- •Write your opening sequence on a card: users, load, data, recovery objectives, compliance, budget, team
- •Plan to say the trade-off out loud with each choice, since silent reasoning scores nothing
Questions to expect
“Design a platform for a business expanding into a second region.”
What they're really asking: Whether you establish why they are expanding — latency, residency or resilience — before designing anything.
How to answer: Ask the purpose first, because it determines the architecture entirely. Latency suggests read replicas and edge caching; data residency suggests partitioned data with regional isolation; resilience suggests a failover design with explicit recovery objectives. Then design for the stated driver, state the data consistency implications plainly, and give the cost and operational complexity you are accepting in exchange.
“The cloud bill has doubled in a year while revenue has not. What do you do?”
What they're really asking: Whether you attack structure or reach immediately for discounts and instance resizing.
How to answer: Start with attribution: without tagging and ownership you cannot act, so establish where the money goes by team and workload. Separate growth-driven spend from waste — idle environments, over-provisioned capacity, unnecessary data egress, retained data nobody reads. Fix the architectural drivers first because they change cost by orders of magnitude, then consider commitments once usage is stable. Finish on accountability: teams that see their own spend behave differently.
“How do you decide between managed services and self-managed infrastructure?”
What they're really asking: Whether you weigh operational capacity honestly or default to a position on lock-in.
How to answer: Frame it around the team's operational capacity and the workload's criticality. Managed services trade unit cost and control for reduced operational burden, which is usually correct for a small team. Self-managing makes sense when scale changes the economics, when you need behaviour the managed service does not offer, or when a hard portability requirement exists. Address lock-in honestly: it is a real cost, but portability has a cost too and is often paid for a migration that never happens.
“What recovery time and recovery point objectives would you design for, and how would you prove them?”
What they're really asking: Whether your resilience claims have ever been tested.
How to answer: Say that the objectives come from the business, differ per workload, and that uniform targets across an estate are a sign nobody asked. Then explain how you prove them: scheduled restore tests, failover exercises with the application actually serving traffic, and measuring the real time taken rather than the theoretical one. Mention the parts that usually fail in practice — DNS propagation, credentials, and dependencies that did not fail over with you.
“How would you structure accounts and permissions for a growing engineering organisation?”
What they're really asking: Whether you can design governance that scales without becoming a bottleneck.
How to answer: Describe separation by blast radius and environment — workload and environment isolation at the account or subscription level, with shared services separated out. Explain federated identity with role assumption rather than long-lived credentials, and preventative guardrails via organisational policy so teams can move freely inside safe boundaries. Emphasise that governance which requires a ticket for every change gets circumvented, so the design must make the safe path the fast path.
“A team wants to adopt a technology you think is a poor fit. How do you handle it?”
What they're really asking: Whether you can influence without authority, since most architects cannot simply mandate.
How to answer: Start by understanding what problem they are solving, since the proposal is often a symptom of an unmet need you could address differently. Make your concerns concrete — operational burden, on-call impact, cost, hiring — rather than stylistic. Offer a bounded trial with agreed success criteria and an exit if it fails. Then say plainly that if they proceed, you document the decision and its accepted risks, and you support them rather than withdrawing.
What to bring as evidence
Two architectures you owned, each with the constraint that drove the design and one thing you would now do differently
An architecture decision record showing the options you rejected and why
A cost reduction you achieved with the architectural mechanism behind it, not just a figure
A migration you planned or led, including how you sequenced waves and handled cutover
Evidence of a resilience claim you actually tested, such as a failover exercise and its results
An example of getting an architecture adopted across teams that did not initially want it
Common mistakes
Presenting an architecture before establishing recovery objectives, residency requirements or budget
Designing for a hypothetical scale the business will not reach for years
Treating multi-cloud portability as an obvious good without pricing the complexity it adds
Ignoring the operational capability of the team who will run the design
Refusing to change the design when the interviewer moves a requirement, which is the point of the exercise
Talking only about technology in the stakeholder round, when the role is largely persuasion
Questions to ask them
- ?
Who has the authority to reject an architecture, and how often does that actually happen?
- ?
How much of this role is designing new systems versus untangling decisions already made?
- ?
How is cloud cost attributed today, and do teams see the cost of their own services?
- ?
When did you last test a regional failover, and what broke?
- ?
How do architectural standards get adopted here — guardrails, review boards, or persuasion?
- ?
What is the biggest piece of technical debt in the estate, and what has stopped it being addressed?
Frequently Asked Questions
Do I need certifications for a cloud architect role?
They help pass an initial filter, particularly with agencies and consultancies, but they carry little weight in the design round. Interviewers are testing whether you can reason about trade-offs under changing constraints, which certifications do not measure.
How hands-on will I be expected to be?
It varies more than any other factor in these roles. Some architect positions are largely advisory and governance-focused, others expect you to write infrastructure code weekly. Ask directly in the first conversation, because a mismatch here is a common reason people leave within a year.
What if my experience is on a different cloud platform to theirs?
Usually acceptable at architect level, provided you map concepts accurately rather than pretending familiarity. Learn their naming and the genuinely different parts — identity and networking models diverge most — and be candid about where you would need ramp-up time.
How long is the design interview and how should I pace it?
Commonly sixty to ninety minutes. Spend the opening ten on requirements, build the design incrementally rather than presenting a finished picture, and leave time for the interviewer to change a constraint. Running out of time because you designed in silence is a frequent failure.
Can I practise this kind of interview realistically beforehand?
You can, and it matters more here than in most roles because the long design round rewards structure and stamina. Cohesyve builds a simulation from a real architect posting and gives three free scored assessments, with feedback on where your reasoning was thin.
Practice
What a Cloud Architect assessment tests, and how it's scored →
Career guide
What a Cloud Architect actually does, and where the path leads →
Prepare for another role
Cohesyve · Practice for candidates
Don't walk in guessing. Find out where you stand first.
Three free scored practice runs, a full report on every one, and a learning pathway built from what you actually got wrong. No card required.
3
free assessments
$0
no card required
Full
scored report every run
Every
question type included
3 free assessments · No card required · Pro from $16/mo
For hiring teams
Hiring for a Cloud Architect role? See how your applicants perform before you spend interview time.