Overview
Cloud computing interviews typically probe three areas: core concepts (service and deployment models), architectural judgment (how you'd design for scale, availability, and cost), and operational knowledge (security, networking, and databases). The questions below are commonly asked at every level from associate to senior cloud engineer, and each answer below is written the way a strong candidate would explain it out loud.
Cricket analogy: A national selection panel tests a batter on technique, match-reading under pressure, and fitness data, just as cloud interviews probe core concepts, architectural judgment, and operational depth across every seniority level.
What is the difference between IaaS, PaaS, and SaaS?
IaaS (Infrastructure as a Service) provides raw compute, storage, and networking — you manage the OS, runtime, and application (e.g., AWS EC2). PaaS (Platform as a Service) adds a managed runtime and middleware layer so you only manage your application code and data (e.g., AWS Elastic Beanstalk, Heroku). SaaS (Software as a Service) delivers a fully finished application over the internet where the provider manages everything, including the application itself (e.g., Gmail, Salesforce). Moving from IaaS to SaaS shifts increasing operational responsibility from the customer to the provider.
Cricket analogy: Renting a stadium with just the pitch and stands is IaaS since you bring your own groundskeeping crew, hiring a fully-staffed venue with curators is PaaS, and buying a ready-made broadcast package like a franchise's matchday feed is SaaS.
Explain the shared responsibility model.
The shared responsibility model divides security duties between the cloud provider and the customer. The provider is responsible for the security OF the cloud — physical data centers, host infrastructure, and the virtualization layer. The customer is responsible for security IN the cloud — data encryption, identity and access management, network configuration (like security groups), and OS/application patching on anything they control. The exact split shifts depending on the service model: IaaS gives the customer more responsibility than PaaS, which gives more than SaaS.
Cricket analogy: The ground authority secures the stadium perimeter and pitch integrity, while the batting team is responsible for its own technique and shot selection, just as the provider secures the cloud's infrastructure and the customer secures their data and access.
What is the difference between horizontal and vertical scaling?
Vertical scaling (scaling up) adds more CPU, RAM, or disk to an existing instance — it's simple but has a hardware ceiling and usually requires downtime. Horizontal scaling (scaling out) adds more instances behind a load balancer — it has no practical ceiling, improves fault tolerance since no single instance is a bottleneck, and is the standard pattern for cloud-native, auto-scaled applications. Most cloud architectures favor horizontal scaling because it aligns with elasticity and high availability.
Cricket analogy: Adding a heavier bat to hit further is like vertical scaling with a hardware ceiling, while fielding more players across the boundary to cover ground is like horizontal scaling with no real limit on coverage.
How would you design a highly available web application in the cloud?
Deploy identical application instances across at least two availability zones within a region, front them with a load balancer that performs health checks, use auto-scaling groups to replace unhealthy instances automatically, and back the application with a multi-AZ managed database that supports automatic failover. Add a CDN for static assets, decouple components with queues where possible, and avoid any single point of failure — including in DNS and storage.
Cricket analogy: Fielding identical strong XIs at two different venues with a stand-in captain ready to step up mirrors deploying instances across two availability zones with a load balancer and auto-scaling group covering for any failure.
What is the difference between a container and a virtual machine?
A virtual machine virtualizes hardware and runs a full guest OS on top of a hypervisor, making it heavier (minutes to boot, GBs in size) but strongly isolated. A container virtualizes at the OS level, sharing the host kernel while packaging just the application and its dependencies, making it lightweight (seconds to start, MBs in size) and highly portable. VMs are chosen when strong isolation or a different OS is required; containers are chosen for fast, dense, portable deployment of microservices.
Cricket analogy: A full replica stadium built for one team, complete with its own turf and stands, is like a VM's heavy full-OS isolation, while a shared practice net that many teams quickly set up and tear down is like a lightweight, portable container.
What is serverless computing, and when would you avoid it?
Serverless computing (e.g., AWS Lambda) runs code in response to events without the developer provisioning or managing servers; the provider handles scaling and you pay only for execution time. It is ideal for event-driven, bursty, or infrequent workloads. You would avoid it for long-running processes (most platforms enforce execution time limits), workloads sensitive to cold-start latency, or applications that need persistent in-memory state across invocations.
Cricket analogy: A twelfth man who only comes on the field when a specific event like an injury happens, and is paid nothing while sitting in the stands, mirrors serverless functions that run only on triggering events and cost nothing when idle.
What is the difference between SQL and NoSQL databases in the cloud, and how do you choose?
SQL (relational) databases enforce a fixed schema and strong ACID transactional guarantees, and they scale primarily by scaling up or by read replicas — good for structured, relational data like financial records. NoSQL databases (key-value, document, wide-column, graph) offer flexible schemas and scale horizontally more naturally, trading some consistency guarantees for throughput and availability — good for high-velocity, semi-structured, or massive-scale data like session state or IoT events. The choice depends on data structure, consistency requirements, and expected scale.
Cricket analogy: A strict scorecard with fixed columns for runs, balls, and wickets that must always balance is like a SQL database's rigid schema and strong consistency, while a flexible fan-notes app where each entry can hold different free-form details is like NoSQL's flexible schema.
What are RPO and RTO, and why do they matter for disaster recovery?
RPO (Recovery Point Objective) is the maximum acceptable amount of data loss measured in time — it determines how frequently you must back up or replicate data. RTO (Recovery Time Objective) is the maximum acceptable downtime before service is restored after a disruption. Together they drive your disaster recovery strategy: a near-zero RPO and RTO justifies an expensive multi-region active-active architecture, while a looser RPO/RTO can be met with periodic backups and a pilot-light or warm-standby approach.
Cricket analogy: How many overs of highlights you're willing to lose if the broadcast feed cuts out is like RPO, while how quickly the broadcast must resume after a technical failure is like RTO, together shaping how much backup equipment a network invests in.
How do you approach cloud cost optimization?
Start by right-sizing instances to match actual utilization, use auto-scaling so you don't pay for idle peak capacity, choose the correct storage class/tier for access frequency, and use reserved or committed-use pricing for predictable steady-state workloads while using spot/preemptible instances for fault-tolerant, interruptible workloads. Continuously monitor spend with cost-allocation tags and billing alerts, and eliminate orphaned resources like unattached volumes or idle load balancers.
Cricket analogy: Choosing the right-sized squad for a tour instead of carrying excess players, rotating fast bowlers only when needed, and negotiating a season-long contract instead of paying match fees every game mirrors right-sizing, auto-scaling, and reserved pricing.
What is Infrastructure as Code, and why is it valuable?
Infrastructure as Code (IaC) means defining and provisioning infrastructure through machine-readable configuration files (e.g., Terraform, AWS CloudFormation) instead of manual console clicks. It's valuable because it makes environments reproducible and version-controlled, enables code review of infrastructure changes, supports consistent multi-environment deployments (dev/staging/prod), and allows disaster recovery by re-provisioning infrastructure from code rather than manual reconstruction.
Cricket analogy: Writing a detailed, reusable match-day playbook that any support staff can follow to set up the field identically every game, instead of setting it up from memory each time, mirrors Infrastructure as Code's reproducible, version-controlled provisioning.
What is a VPC, and why would you segment it into public and private subnets?
A Virtual Private Cloud (VPC) is an isolated, logically separated section of a cloud provider's network where you control IP ranges, subnets, route tables, and gateways. You segment it into public subnets (with a route to an internet gateway, for load balancers and bastion hosts) and private subnets (no direct internet route, for application and database servers) to minimize the attack surface — only resources that truly need direct internet exposure are reachable from outside, while backend resources stay isolated and reach the internet only through a NAT gateway if needed.
Cricket analogy: A stadium's public gate that fans use to enter is like a public subnet routed to the internet gateway, while the private dressing rooms reachable only through an internal corridor mirror a private subnet isolated from direct outside access.
- IaaS/PaaS/SaaS = decreasing customer management responsibility
- Shared responsibility: provider secures OF the cloud, customer secures IN the cloud
- Horizontal scaling (more instances) is preferred over vertical scaling for cloud-native HA
- Multi-AZ deployment + load balancer + auto-scaling = baseline HA pattern
- Containers share the host kernel; VMs virtualize full hardware and OS
- RPO = acceptable data loss window; RTO = acceptable downtime window
- IaC makes infrastructure reproducible, reviewable, and version-controlled
- Interviewers reward candidates who explain trade-offs, not just definitions
- Always connect a concept back to a concrete design decision or real scenario
- Security, cost, and availability are the three lenses most cloud questions test
- Know the shared responsibility model cold — it underlies many follow-up questions
Practice what you learned
1. Which service model requires the customer to manage the operating system?
2. Under the shared responsibility model, who is responsible for configuring security groups correctly?
3. Which scaling approach adds more machines rather than upgrading an existing one?
4. A near-zero RPO requirement most strongly implies which design choice?
5. What is the primary reason application and database servers are placed in private subnets?
Was this page helpful?
You May Also Like
The Shared Responsibility Model
Understand which security responsibilities belong to the cloud provider versus the customer, and how that split shifts across IaaS, PaaS, and SaaS.
High-Availability Design
Design systems that stay up through redundancy and automatic failover, and understand what each additional 'nine' of uptime really costs.
Cloud Service Models (IaaS, PaaS, SaaS)
How IaaS, PaaS, and SaaS differ in what the provider manages versus what the customer manages.
Data Backup and Disaster Recovery
Understand RPO and RTO and compare disaster recovery strategy tiers from backup-and-restore to multi-site active-active.