Top 15 Cloud Interview Questions (AWS, Azure, GCP)

I’ve been on both sides of cloud interviews. Asked the questions. Answered them. Bombed a couple I probably shouldn’t have.

Here’s what stuck with me: nobody gets hired for reciting what EC2 is. Interviewers want to know if you’ve operated actual infrastructure. Broken something in production. Fixed it under pressure. Made trade-offs you can defend without squirming.

These 15 questions keep showing up across AWS interview loops, Azure interview panels, and GCP rounds. Not trivia — real questions that separate builders from tutorial-watchers.

Foundational Questions That Still Catch People

You’d assume the basics would be easy. They’re not. Interviewers don’t want definitions. They want nuance.

IaaS vs PaaS vs SaaS — sure, everyone memorizes the pyramid. What trips people up is that the boundaries are blurry now. Lambda sits somewhere between IaaS and PaaS. So does App Engine. Saying that out loud shows you’ve thought past the textbook.

The Shared Responsibility Model is where junior candidates fall apart. They describe it in the abstract. Don’t. Try this instead: “If my EC2 instance gets compromised because I didn’t patch it, that’s on me.” One sentence. Proves more than a five-minute monologue.

VPCs. Subnets, CIDR blocks, security groups, NACLs — know them cold. AWS VPC, Azure VNet, GCP VPC all implement things differently, but the concept is identical. You’re building walls around your workloads. If you can’t explain why a database belongs in a private subnet, you’re not ready for the interview.

Regions and Availability Zones reveal whether you’ve designed for failure or just read about it. Multi-AZ isn’t a checkbox. It’s a decision with cost, latency, and compliance consequences. GDPR alone can dictate your entire region strategy.

Horizontal vs vertical scaling. Vertical hits a ceiling and usually needs downtime. Horizontal gives you fault tolerance. That’s the textbook answer. The better answer? Some managed services — Aurora, Cloud Spanner — handle this for you, and knowing when to lean on them is the actual skill being tested.

Mid-Level: Proving You’ve Built Something Real

This is where cloud interview questions get interesting. And where preparation separates candidates.

“When would you pick NoSQL over relational?” Wrong answer: listing DynamoDB features. Right answer: it depends on your access patterns. DynamoDB is incredible for known key-value lookups at scale. PostgreSQL on RDS wins when you need ad-hoc queries and joins. Most production systems I’ve worked on use both. Saying that — honestly — lands better than picking a side.

“Design a highly available architecture on AWS.” They want specifics. Two AZs minimum. ALB in front. Auto Scaling Group with health checks. RDS Multi-AZ for failover. S3 plus CloudFront for static assets. Then quantify it: “this targets 99.99% uptime on the application tier.” Numbers make you credible. Vague promises don’t.

Infrastructure as Code. When someone asks why IaC is non-negotiable, they’re really testing whether you’ve been burned by manual console changes. (You have, right? We all have.) Terraform, CloudFormation, Pulumi — the tool matters less than the principle. Version-controlled, repeatable, auditable infrastructure. Mention Terraform state management headaches. It proves you’ve actually used the thing.

Secrets management is straightforward but people still get it wrong. Never hardcode credentials. Use Secrets Manager, Key Vault, or GCP Secret Manager. Rotate automatically. Prefer IAM roles over long-lived keys. I’ve seen production outages caused by expired hardcoded API keys — completely preventable. And yet.

The Myth of Needing All Three Providers

Here’s the thing. A lot of candidates burn weeks trying to learn AWS, Azure, and GCP at equal depth. That’s a mistake.

Honestly? Most companies use one cloud provider for 90% of their workloads. Interviews test depth, not breadth. If you know AWS well, you can bridge to the others: “In AWS I’d use SQS. Azure Service Bus and GCP Pub/Sub serve similar roles, though delivery guarantees differ.” That kind of reasoning impresses more than shallow knowledge of three platforms.

Where multi-cloud awareness does matter: comparing serverless options. Lambda has the richest trigger ecosystem. Azure Functions integrates deeply with the Microsoft stack and has Durable Functions for stateful workflows. Cloud Functions is simplest for HTTP triggers and pairs well with Firebase. Know the cold start tradeoffs and pricing differences. That’s usually enough.

A controversial opinion, maybe — but I’d rather hire someone who’s deeply operated one cloud than someone who’s skimmed all three certification guides.

Advanced Questions — Where Operational Scars Show

No faking it at this level.

Monolith to microservices. The answer is the Strangler Fig pattern. Don’t rewrite everything at once. Extract one bounded context at a time. Give each service its own database. Use async messaging — SQS, EventBridge, Pub/Sub — to reduce coupling. But here’s what most candidates forget to say: you’re trading code complexity for operational complexity. Acknowledging that trade-off? Interviewers notice.

CAP theorem. Network partitions happen. Period. So you’re choosing between consistency and availability. DynamoDB defaults to eventual consistency but offers strongly consistent reads. Cloud Spanner claims both C and A through TrueTime… though it bends during actual partitions. Relate it to something real: “We chose eventual consistency because our use case tolerated stale reads for 200ms.” That’s what makes an answer stick.

Zero-downtime deployments. Blue-green or rolling updates. Blue-green: deploy to an inactive environment, test, switch the load balancer, keep the old one for rollback. Rolling updates in Kubernetes replace pods incrementally with readiness probes gating traffic. The hard part is always database migrations — expand-contract pattern. Add new columns first, deploy code that writes to both schemas, migrate data, then drop old columns.

Cost optimization. Start with visibility — Cost Explorer, billing alerts. Then right-size instances, use Reserved Instances or Savings Plans for steady workloads, Spot for batch jobs, S3 Glacier for cold data. Kill zombie resources: unattached EBS volumes, idle load balancers, forgotten snapshots. Teams that run monthly cost reviews save real money. Teams that don’t… well, they find out eventually.

When You’re Stumped

It happens in every AWS interview, Azure panel, or GCP round. Someone asks about a service you’ve never touched.

Be honest. Then reason out loud.

“I haven’t used that directly, but based on the problem, I’d expect it to work like [analogous thing]. Here’s how I’d validate that.” Engineering thinking beats encyclopedic knowledge. Every time.

Certifications help get past resume filters. They don’t replace having built something real. A cert plus a personal project you can actually demo — that combination still works better than three certs and no hands-on experience.

FAQ

Do I need certifications for cloud interviews?

They help you get past HR filters, especially at larger companies. But I’ve interviewed plenty of certified candidates who couldn’t troubleshoot a misconfigured security group. The cert opens the door. What you’ve built is what gets you through it.

Which cloud provider should I learn first?

AWS still has the largest market share and the most interview demand. Start there unless you’re targeting a company that’s clearly an Azure or GCP shop. The concepts transfer — once you deeply understand one provider, picking up another takes weeks, not months.

How technical do cloud interviews actually get?

Depends on the role. For a cloud engineer or SRE position, expect to whiteboard architectures and discuss failure scenarios in detail. For a backend developer role, they’ll probably ask a few cloud questions but won’t go as deep. Look at the job description. If it mentions Terraform or Kubernetes, prepare accordingly.

What’s the biggest mistake people make in cloud interviews?

Talking in abstractions. Saying “I would use a load balancer” without specifying which one, how it’s configured, or why. Specificity signals experience. Vagueness signals tutorials.

Need a full preparation plan? These cloud questions are one piece of the puzzle. For the complete picture — coding, system design, behavioral, and timing — read how to prepare for a technical interview in 2026.

Done reading? Join the early access →