How to Vet a Cloud Architect: The Senior Practitioner's Checklist

Most cloud architect interviews fail in the same way: the buyer asks about services (“have you used EKS?”, “do you know Terraform?”) and the candidate answers in services. Both parties leave the conversation feeling productive, and neither has learned whether the candidate can actually design a system that will not collapse in production.

This is the checklist we use when vetting senior cloud architects for placement in regulated-industry engagements. It is equally useful as a self-assessment for consultants who want to know where they actually stand.

Start With the Failure Mode, Not the Service

The first useful signal is whether a candidate reasons about failure before they reason about features. A useful opening prompt:

“Walk me through the last production incident you owned end to end. What was the blast radius, what was the root cause, and what changed in the system after.”

What you are listening for:

A clear distinction between the trigger (what happened) and the root cause (why the system was vulnerable)
Quantified impact — requests affected, duration, customer-visible vs. internal
A post-incident change that is structural, not procedural (“we added a runbook step” is weaker than “we removed the shared dependency”)
Honest discussion of what the candidate personally got wrong

Architects who have never owned an incident in production tend to design systems that have never survived one.

The Architecture Whiteboard Question

Give the candidate a constrained problem and force trade-offs. A version we use:

“Design a system that ingests 50,000 medical claims per hour, runs eligibility checks against three external payer APIs, and writes adjudicated claims to a warehouse for analytics. The external APIs have 95th percentile latency of 800 ms and occasionally return 500s. You are on GCP. Budget is real but not the primary constraint.”

Strong candidates do these things, usually in this order:

Ask about the read pattern on the warehouse — batch nightly vs. near real-time changes the entire pipeline
Ask what “adjudicated” means in this context, because the answer determines whether retries are idempotent
Decompose into ingest, enrichment, persistence
Pick a queue (Pub/Sub, or Cloud Tasks if they need per-message scheduling) and explain why
Handle the flaky external API explicitly — circuit breaker, dead-letter, retry with jitter, and a clear answer for what happens to a claim that cannot be enriched in 24 hours
Address PHI handling without being prompted — encryption at rest, CMEK if appropriate, IAM boundaries between the ingest service and the warehouse, audit logging

Weak candidates draw boxes and arrows and then add “and we’ll use Dataflow” without a reason. Reasonable-sounding word salad with no commitment to trade-offs is the most common failure mode at the senior level.

The IAM Question

Identity is where cloud systems actually break. A useful probe:

“You inherit an AWS account with 400 IAM roles and no documentation. Walk me through your first two weeks.”

Listen for:

Read-only access first, not write
A pass to identify roles with AdministratorAccess or wildcards on sensitive resources
IAM Access Analyzer or equivalent (GCP Policy Analyzer, Azure PIM) to surface external trust
A plan to baseline current usage with CloudTrail / Access Advisor before removing anything
An understanding that you do not delete roles, you deprecate them with monitoring

Candidates who immediately reach for a tool (“we’ll run Steampipe”) without describing the analysis loop are usually pattern-matching, not thinking.

The Cost Question Most Interviews Skip

Cost is an architecture concern, not a finance concern. Ask:

“Give me an example where you changed an architectural decision because of cost. What was the original design, what did the bill look like, and what did you change.”

You are looking for:

Awareness that egress, cross-AZ traffic, and NAT gateway charges are usually the surprise
A specific story with numbers, not “we right-sized instances”
Comfort with the idea that the cheapest option is often the boring one (one region, one provider, fewer managed services)

If the candidate has never had a finance team escalate a bill to them, they have probably never operated at scale where it mattered.

The Compliance Question, If Relevant

For regulated engagements (HIPAA, FedRAMP, PCI, SOC 2 Type II), the question is not “have you seen this framework” but “can you draw the line between what the cloud provider gives you and what you still have to build.”

A clean version:

“AWS is HIPAA-eligible and you have a signed BAA. Your application stores PHI in S3 and processes it in Lambda. What controls do you still own.”

Acceptable answers cover:

Encryption key management (KMS CMK vs. AWS-managed)
Access logging and retention (CloudTrail data events on the PHI bucket are off by default and cost extra)
Network egress — Lambda outside a VPC will route over the public internet
Authentication and authorization at the application layer
Backup, retention, and right-to-delete workflows

A candidate who says “AWS handles it because we have a BAA” should not be near a regulated workload.

Red Flags

Patterns that consistently correlate with bad outcomes:

Service-first reasoning. “I’d use Fargate” before they understand the workload.
No production scars. No incident stories, no rollback stories, no “we tried this and it failed.”
Tool maximalism. Service mesh, GitOps, multi-cluster, multi-region, and policy engine on a system serving 200 requests per minute.
Vendor monoculture without trade-off awareness. Knowing one cloud deeply is fine. Insisting that the other two are categorically worse is not.
No opinion on testing infrastructure code. If they have never written a Terratest, a Pulumi unit test, or even a terraform plan review process, they have not lived with their own IaC.
Hand-waving about cost. “We can always optimize later” is how you get a 40,000 dollar monthly bill for a staging environment.

What to Verify, Not Just Ask

References are usually low signal because candidates pick them. The higher signal moves:

Ask for a specific artifact — a sanitized architecture diagram they drew, a postmortem they wrote, a Terraform module they own. The quality of the artifact tells you more than the interview.
Ask the candidate to review a deliberately bad diagram you prepared. What they notice, in what order, is highly diagnostic.
For long engagements, run a paid two-day design exercise before committing. Almost everyone agrees if the scope is honest, and the signal is an order of magnitude better than another interview round.

A Note for Consultants Reading This

If you are a cloud architect and you read the above and thought “I could not answer half of those clearly,” that is useful information. The fastest way to close the gap is not another certification. It is:

Own an incident end to end and write the postmortem
Inherit a messy IAM environment and clean it up with a written plan
Look at a bill you are responsible for, every month, for a year
Work in at least one regulated environment where the auditor is real

The architects we place into senior engagements have done all four. The certifications are downstream of the work.

Cloud Technology Partners is a Florida-based C2C network placing senior cloud practitioners into enterprise and regulated-industry engagements. Join our network or contact us to discuss your architecture staffing needs.