Here’s a thing that happens in cloud engineer interviews: you get asked about a service you’ve used dozens of times, and your mind goes blank. Not because you don’t know it. Because interview pressure is strange and the exact phrasing of a question can trigger or block recall in ways that feel arbitrary.
I find it helpful to organize preparation around concepts rather than services. The services change. The concepts are stickier.
the concepts that show up across all three platforms
Some questions appear in roughly the same form whether you’re interviewing for an AWS, Azure, or GCP role. These are worth knowing cold.
Shared responsibility model. Every cloud provider has a version of this. The interviewer’s real question is: do you understand where your responsibility starts? For IaaS, you own the OS and everything above it. For managed services like RDS or Azure SQL, you don’t own the database engine. For SaaS-like services, the line moves further. A lot of security incidents happen at the boundary, when teams assume someone else owns a configuration they actually own themselves.
High availability vs fault tolerance. These are not the same thing. High availability means the system stays up through component failure (think load balancers, health checks, auto-scaling). Fault tolerance means the system continues operating even if a component fails mid-transaction (think ACID databases, idempotent queues). Interviewers ask about this because engineers conflate them, and the conflation leads to real outages.
VPC networking and subnets. Every major cloud platform has a VPC model. The concepts that get tested: public vs private subnets, NAT gateways, VPN vs Direct Connect vs ExpressRoute, security groups vs network ACLs (and that NACLs are stateless, which surprises people who haven’t run into that problem in production). The specific service names differ across AWS, Azure, and GCP but the underlying problems are identical.
AWS-specific questions I see most often
IAM and permissions: “What’s the difference between an IAM role and an IAM policy?” Roles are identities. Policies are permission documents attached to identities. Roles can be assumed by services, users, or other accounts. This sounds simple, but the nuances around permission boundaries, service control policies, and cross-account role assumption come up in senior interviews.
Lambda cold starts: Interviewers ask about Lambda cold starts specifically because they trip up engineers who haven’t run latency-sensitive workloads on serverless. Cold starts happen when a new execution environment is initialized. Mitigation strategies include provisioned concurrency (you pay to keep environments warm), choosing a faster runtime (Go and Python cold start faster than Java), and keeping the function package small.
EC2 purchasing options: On-Demand, Reserved, Savings Plans, and Spot. The interview question isn’t “what are these” but “when would you use each.” Spot instances can be interrupted with two minutes notice, which makes them wrong for stateful applications but right for fault-tolerant batch processing. Reserved instances require a 1-year or 3-year commitment. Savings Plans are more flexible. This is a cost optimization question dressed as a compute question.
Azure questions that come up in enterprise roles
Azure Active Directory vs on-premise AD: Most enterprise Azure roles involve hybrid identity. The question is usually about the sync patterns (Azure AD Connect, pass-through authentication vs password hash sync) and the trade-offs in terms of latency and dependency on on-premise infrastructure. If you’ve only worked in greenfield cloud environments, this is worth studying.
ARM templates vs Bicep vs Terraform: Azure interviewers often ask which IaC approach you prefer and why. ARM templates are verbose JSON. Bicep is a domain-specific language that compiles to ARM. Terraform abstracts across cloud providers. A reasonable answer is: Bicep for Azure-only shops, Terraform for multi-cloud or for teams with existing Terraform expertise. There isn’t a universally right answer, so the interview is testing whether you have a reasoned opinion.
GCP questions and why they’re different
GCP interviews tend to go deeper into data and networking than AWS or Azure interviews, in my experience. Probably because Google’s historical strength is in those areas and the people writing interview questions built those systems.
BigQuery: “Explain how BigQuery handles a query across a 5TB table.” The important concepts are columnar storage, slot-based query processing, and partition/cluster optimization. If you’ve only used BigQuery as a SQL endpoint without thinking about how it executes, this question exposes that gap quickly.
GCP’s global VPC: Unlike AWS VPCs which are regional, GCP’s VPC is a global resource by default. Subnets are regional but the VPC spans all regions. This changes how you think about routing and firewall rules. It’s a legitimately interesting architectural difference and interviewers use it to test whether you’ve actually operated GCP or just read about it.
Preparing under real interview conditions
The Stack Overflow Developer Survey 2024 found that AWS, Azure, and GCP are the top three cloud platforms by usage, in that order. Job demand follows a similar distribution. BLS projects cloud and infrastructure roles growing 15% through 2032, which suggests interview volume in this space is not shrinking.
One thing I find genuinely useful for cloud interview prep is practicing with something that can push back. Static lists of questions are fine for recall, but cloud architect interviews are conversational. You say something, the interviewer asks why, you defend it. Craqly’s mock interview mode simulates that follow-up pattern, which is harder to get from reading alone. (That said, there’s no substitute for actually deploying things and watching them break.)
The honest gap in most cloud interview prep is operational knowledge. Anyone can describe what Auto Scaling is. Fewer people can describe a specific time they tuned scaling policies and what they got wrong first. That second kind of answer is what senior interviewers are trying to pull out of you. If you have those stories, prepare to tell them clearly. If you don’t have them yet, go build something with a budget ceiling and see what breaks.