Interview Questions: Cloud & AWS Fundamentals

Cloud interviews almost always start with the basics: what the cloud actually is, how AWS lays out its data centres around the world, who is responsible for what, and how you control access with identity. These questions feel simple, but interviewers use them to probe whether you understand the why behind each idea. This page gives you a crisp model answer for each question, plus the deeper follow-up the interviewer is really fishing for, so you can defend your answer instead of just reciting it.

What are IaaS, PaaS, and SaaS?

These three terms describe how much of the technology stack the cloud provider manages for you. The more they manage, the less control (and less work) you have.

• IaaS (Infrastructure as a Service) gives you raw building blocks: virtual servers, storage, and networking. You manage the operating system, runtime, and your app. Example: Amazon EC2 (Elastic Compute Cloud — virtual servers).
• PaaS (Platform as a Service) gives you a managed platform to deploy code; the provider handles the OS, patching, and scaling. Example: AWS Elastic Beanstalk or AWS Lambda.
• SaaS (Software as a Service) is finished software you just log into and use. Example: Gmail, or Amazon WorkMail.

Model	You manage	Provider manages	Best for
IaaS	OS, runtime, app, data	Hardware, virtualization, network	Full control, custom stacks, lift-and-shift
PaaS	App code and data only	OS, runtime, scaling, patching	Shipping fast without infra ops
SaaS	Just your settings/data	Everything else	Using software, not building it

The deeper “why”: Interviewers want to hear the trade-off, not just definitions. More managed means less operational burden but less flexibility and sometimes higher per-unit cost. The right answer is “it depends on how much control I need versus how much undifferentiated heavy lifting I want to offload.”

Tip: A clean one-liner that impresses: “IaaS is renting the kitchen, PaaS is renting the kitchen with a chef, SaaS is ordering the meal.”

What is the difference between a Region and an Availability Zone?

A Region is a separate geographic area (for example, us-east-1 in Northern Virginia or eu-west-1 in Ireland). An Availability Zone (AZ) is one or more discrete data centres within a Region, each with its own power, cooling, and networking. A Region contains multiple AZs (usually three or more), connected by fast, low-latency private links.

You choose a Region for reasons like latency to your users, data-residency laws, and price. You spread resources across AZs for high availability — if one AZ has an outage, the others keep running.

Concept	Scope	Why you pick it	Failure isolation
Region	Geographic area	Latency, compliance, cost	Total isolation between Regions
Availability Zone	Data centre(s) in a Region	High availability within a Region	One AZ can fail independently
Edge Location	CDN cache points (CloudFront)	Low-latency content delivery	N/A — caching only

List the Regions and AZs available to your account with the CLI.

aws ec2 describe-availability-zones --region us-east-1 \
  --query "AvailabilityZones[].ZoneName" --output text

Output:

us-east-1a  us-east-1b  us-east-1c  us-east-1d  us-east-1e  us-east-1f

The gotcha interviewers dig for: Deploying across multiple AZs protects against a data-centre failure, but a Region-wide event still takes you down. For true disaster recovery you need a multi-Region strategy. Also, your AZ name (us-east-1a) is randomized per account, so my us-east-1a may be physically different from yours — never assume two accounts share the same physical AZ.

Explain the AWS Shared Responsibility Model.

This model defines who secures what. The short version: AWS is responsible for security of the cloud; you are responsible for security in the cloud.

• AWS secures the cloud: physical data centres, hardware, the virtualization layer, and the managed-service software (for example, the underlying database engine in Amazon RDS).
• You secure your part: your data, OS patching on EC2, network and firewall rules (security groups), IAM permissions, and encryption settings.

The split shifts depending on the service. With EC2 (IaaS) you patch the OS yourself. With Lambda or S3 (more managed), AWS handles more — but you still own your data, access policies, and encryption choices.

Warning: A classic real-world breach is a public S3 bucket. AWS kept the storage secure, but the customer misconfigured the access policy. That is squarely on the customer side of the model — and it is exactly the kind of example interviewers love to hear.

What is IAM, and what is the difference between users, roles, and policies?

IAM (Identity and Access Management) is the service that controls who can do what in your AWS account.

• A user is a permanent identity for a person or app, with long-term credentials (a password or access keys).
• A role is an identity with no long-term credentials. It is assumed temporarily, handing back short-lived credentials that expire automatically.
• A policy is a JSON document listing permissions (allow/deny on actions and resources). You attach policies to users, roles, or groups.

A typical permission policy looks like this.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::my-app-bucket",
        "arn:aws:s3:::my-app-bucket/*"
      ]
    }
  ]
}

Create a role that an EC2 instance can assume.

aws iam create-role --role-name app-s3-reader \
  --assume-role-policy-document file://trust-policy.json
aws iam attach-role-policy --role-name app-s3-reader \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

Output:

{
  "Role": {
    "RoleName": "app-s3-reader",
    "Arn": "arn:aws:iam::123456789012:role/app-s3-reader",
    "CreateDate": "2026-06-15T10:42:08+00:00"
  }
}

Why roles over access keys — the key follow-up: Access keys are long-lived secrets. If one leaks (committed to GitHub, baked into an AMI), an attacker has standing access until you notice and rotate it. A role hands out temporary credentials that rotate automatically, so a leak has a tiny blast radius. Best practice in 2026: applications on EC2, ECS, or Lambda use roles; humans log in via IAM Identity Center (SSO), not standing keys.

Why does an explicit Deny always win?

IAM evaluates every applicable policy. The logic is: deny by default, an Allow opens a permission, but any explicit Deny overrides every Allow. This lets you write a guardrail (for example, “deny all access outside eu-west-1”) that no other policy can accidentally re-enable. Interviewers ask this to check you understand IAM is fail-safe by design.

How should you secure the root account?

The root user is the email address you signed up with. It has unrestricted power over the entire account and cannot be limited by IAM policies.

Things only the root user can do include: closing the AWS account, changing the account name or email, changing the support plan, restoring an IAM user’s deleted permissions in a lockout, and configuring some billing settings.

Lock it down like this:

1. Sign in to the AWS Management Console as root.
2. Open the account menu (top right) and choose Security credentials.
3. Enable Multi-Factor Authentication (MFA) — a second login factor such as a hardware key or authenticator app.
4. Delete any root access keys if they exist.
5. Create a separate IAM admin user (or an IAM Identity Center user) for daily work and stop using root.

Tip: After setup, the root credentials should go in a password manager or a safe and be used only for the rare root-only tasks above. Day-to-day administration should never touch the root account.

Best Practices

• Follow least privilege: grant only the permissions a user or role actually needs, and widen later if required.
• Use roles, not long-lived access keys, for applications and cross-account access.
• Enable MFA on the root account and all privileged users.
• Spread workloads across multiple AZs for availability, and plan multi-Region only when you truly need disaster recovery (it adds cost and complexity).
• Remember the shared responsibility model when reasoning about any security question: ask “is this AWS’s job or mine?”
• Use explicit Deny statements as guardrails for actions that must never happen, since they override any Allow.

Related Topics

• Interview: Compute & Networking
• Interview: Storage & Databases
• Interview: Serverless & Security