How to Hire a Cloud Architect in 2026: AWS, GCP, and What to Actually Test

Cloud architect is one of the most credentialed roles in tech and one of the easiest to hire wrong. The certification landscape — AWS, GCP, Azure, plus dozens of specializations — creates a paper trail that looks thorough but does not reliably predict whether someone will make good decisions on your infrastructure. Here is how to hire for the thing that actually matters: judgment.

Define the role before you post

The phrase “cloud architect” covers at least three distinct jobs depending on the company:

A solutions architect is primarily a designer. They produce the architectural drawings: account structure, networking topology, security boundaries, data flow, cost estimates. They work closely with product and engineering leadership and rarely write a lot of Terraform themselves.

A cloud engineer is primarily a builder. They implement what the architect designed, write the IaC, maintain the pipelines, handle the day-to-day operations of the platform. Sometimes called “infrastructure engineer” or “DevOps engineer” at smaller companies.

A platform engineer sits at the overlap of both. They build the internal developer platform: the CI/CD tooling, the service catalog, the standardized deployment patterns. Their customer is the application development team.

Most companies in the 100-500 person range actually need a platform engineer — someone who can do light design work and heavy implementation work. They write “cloud architect” in the job post, get 400 applications, and then wonder why most candidates are too senior or too theoretical for what they need.

Before posting, answer: is this role primarily design, build, or operate? That question determines the screen, the seniority bar, and whether you should be hiring at all — some of this work is better delivered as a time-boxed architecture review than a full-time hire.

What certifications tell you

AWS, GCP, and Azure certifications have become table stakes rather than differentiators. The AWS Solutions Architect Associate (SAA-C03) is now held by a wide population of engineers who studied for it, cleared it, and may or may not have used the knowledge in production. The Professional tier (SAP-C02) requires more depth and is harder to pass by studying alone — it is a better signal.

Treat certifications as a floor. A candidate for a senior cloud architect role without any certification deserves a question about why. A candidate with multiple certifications who cannot explain a trade-off between RDS and Aurora deserves the same question. The cert confirms they know what the services are named. The interview determines whether they know when to use them.

The screen that actually works

Forget the trivia questions. The cloud architect role requires judgment under uncertainty and often under pressure. Here is what to probe:

Walk me through a cost-reduction you drove. Real architects have identified and addressed overprovisioning, idle resources, wrong storage tiers, oversized RDS instances, or expensive egress patterns. Someone who has never touched cloud cost has either worked on small systems or let someone else handle it. Ask what the baseline spend was, what they changed, and what the result was. Vague answers (“we saved a lot by right-sizing EC2”) are a yellow flag.

Tell me about a multi-region or availability failure you debugged. Cross-region failures are complicated: DNS propagation, Route 53 health checks, data replication lag, session stickiness. If they have not debugged one, they have not operated production at meaningful scale. Ask what their role was in the response and what the root cause was.

Which service did you evaluate and decide NOT to use, and why? This is the most underrated question in cloud architecture interviews. Choosing not to use a managed service — because the lock-in risk was too high, the pricing model did not fit, or the team did not have the operational depth — is a sign of real judgment. Architects who default to “use the managed service” for everything are not making trade-off decisions, they are making default decisions.

Design a system for [your use case] on a $10k/month infrastructure budget. Give them a real constraint that reflects your actual situation. Watch how they decompose the problem, which assumptions they ask to clarify, and whether they think about cost from the start or add it as an afterthought.

AWS vs GCP vs Azure: does provider matter?

The platform your candidate knows best matters, but not the way most hiring managers think. The real question is not whether they are “an AWS person” or “a GCP person.” It is whether they understand the trade-offs across providers and can reason about them.

The architectural concepts — VPCs, IAM, object storage, managed databases, serverless compute, observability tooling — map across providers with enough consistency that an experienced architect can operate across them. Someone who has spent five years entirely on AWS and has never thought about multi-cloud or vendor lock-in is a narrower hire than someone who can articulate why you would or would not choose AWS for a specific workload.

That said, hands-on depth on your primary provider matters. If you are running AWS and plan to stay there, a GCP-heavy candidate carries a real ramp-up cost. Weight it, but do not treat it as disqualifying.

Pairing the cloud architect screen with IaC

Infrastructure-as-code fluency is now a baseline expectation. Whether the candidate defaults to Terraform, OpenTofu, Pulumi, or CDK is less important than whether they understand why IaC exists and can navigate the trade-offs between approaches. Ask them to walk through a module they have written. If they cannot, they are a designer who delegates all the implementation — which may be fine for your role, but you should know that going in.

For a more detailed look at the IaC landscape and where Terraform, OpenTofu, and Pulumi differ, the IaC comparison for 2026 covers the practical distinctions.

Red flags specific to cloud architects

Credentials as the whole pitch. A candidate who leads with their certification list and cannot quickly pivot to a specific decision they made is probably optimized for passing interviews, not shipping infrastructure.

No cost opinions. Infrastructure spend is one of the most impactful things an architect influences. If they have never thought about cost optimization or dismiss it as “ops work,” they have not been held accountable for the bills they generate.

Lock-in blindness. Architects who default to managed services without mentioning vendor lock-in are not making trade-off decisions. The right answer is almost never “never use managed services” or “always use managed services.” It is “for this specific workload, the operational savings outweigh the lock-in cost because…”

Only theoretical design experience. Architecture diagrams that were never built are not the same as architecture that shipped. Ask how much of their designed systems they personally operated post-launch. The ones who stayed through the first outage learned something the ones who handed off did not.

The FTE vs. fractional question

For many companies at the 50-150 person stage, a full-time cloud architect is the wrong hire. The design work is a burst — high at platform inception, low during steady-state operation. A fractional cloud architect (engaged for 10-20 hours per month) or a scoped architecture review from an agency can deliver the high-value design work without the full-time cost and the management overhead.

The case for a full-time hire is clearer when: the platform is actively scaling (above $100k/month in infrastructure spend), the team has more platform work than one fractional person can absorb, or regulatory requirements (HIPAA, SOC 2) demand a named responsible owner with ongoing availability.

For scoping that decision, the framework in our guide to hiring vetted software developers applies here too: define the actual work before deciding whether it requires a full-time seat or a specialist engagement.

What to look for in the take-home

A short architecture exercise is the most reliable screen for cloud architects. Give them:

• A realistic scenario (not a trick problem) with actual constraints: a rough traffic estimate, a compliance requirement, a cost ceiling, a stack they need to integrate with
• A few hours to produce a diagram and a short written summary of trade-offs
• An explicit note that you expect them to make and defend choices, not produce an exhaustive review of every option

Then run a 30-minute walk-through. Ask them to defend a specific decision they made and to describe a decision they considered but rejected. Those two questions reveal more than the diagram.

Cloud architecture is ultimately judgment applied under constraint. The best screen simulates the constraint and watches how they reason in it.