AWS & Cloud Interview Questions and Answers

They describe how much of the stack the provider manages. With IaaS you rent virtual machines, storage and networks and manage the operating system and everything above; EC2 is the AWS example. With PaaS the provider also runs the platform and runtime, so you deploy code; Elastic Beanstalk or App Runner are examples. With SaaS you simply use finished software, like a hosted CRM or email service.

Lambda is often called FaaS or serverless: you supply a function and AWS handles servers, patching and scaling. The boundaries are blurry, so I explain them as a spectrum of who is responsible for what, and choose the highest level that still gives the control the workload needs.

What the interviewer is checking: Clear mental model of responsibility levels, not memorised acronyms.

Likely follow-up: Why might a team choose EC2 over a more managed option?

AWS is responsible for security of the cloud: the data centres, hardware, host virtualisation and the managed service software. The customer is responsible for security in the cloud: their data, identity and access configuration, network rules, and, depending on the service, the operating system and application.

For EC2, AWS secures the physical host and hypervisor, but I patch the guest OS, configure security groups and protect the keys. For S3, AWS runs the storage infrastructure, but I decide who can access a bucket, whether it is public, and whether objects are encrypted. Most real breaches come from customer-side misconfiguration, not from AWS infrastructure failing. The split shifts toward AWS as services become more managed.

What the interviewer is checking: Knows that configuration and access are the customer's job.

Likely follow-up: Who is responsible for patching when you use RDS?

A Region is a separate geographic area that contains multiple, isolated Availability Zones. An AZ is one or more discrete data centres with independent power and networking, linked to its siblings by fast, low-latency connections. Edge locations are points of presence used by services like CloudFront to serve content close to users.

For availability I spread a workload across at least two AZs so one facility failure does not take it down. I choose the Region by latency to users, data residency or compliance rules, service availability and cost. Regions are isolated by design, so surviving a Region-wide problem needs deliberate cross-Region replication and failover.

What the interviewer is checking: Understanding the failure boundaries that drive architecture decisions.

Likely follow-up: Is multi-AZ enough for compliance that says data must stay in one country?

A policy is a JSON document that states what actions are allowed or denied on which resources. A user is an identity for a person or application with long-lived credentials. A group is a collection of users to which you attach policies together. A role is an identity with no permanent credentials that something trusted can assume to receive temporary ones.

For workloads I prefer roles: an EC2 instance, Lambda function or ECS task gets a role, so there are no access keys stored on disk or in code. Access is denied by default, an explicit deny always wins over an allow, and I protect the root account with MFA and avoid using it day to day.

What the interviewer is checking: Core IAM vocabulary and the preference for temporary credentials.

Likely follow-up: A Lambda function needs to read one S3 bucket. What exactly do you create?

S3 Standard is for frequently accessed data. Standard-IA and One Zone-IA are cheaper for infrequent access but add retrieval charges, and One Zone keeps data in a single AZ. Intelligent-Tiering moves objects between tiers automatically based on access patterns. The Glacier classes suit archives, trading lower storage cost for slower or costlier retrieval.

For logs I would add a lifecycle rule: keep them in Standard for the first weeks while people still look at them, transition to an infrequent-access or archive class after a month, and expire them when the retention policy ends. I would check minimum storage durations and retrieval fees first, because moving tiny or short-lived objects can cost more than it saves.

What the interviewer is checking: Matches access patterns to storage tiers and knows the hidden costs.

Likely follow-up: How would you handle data when you cannot predict how often it will be accessed?

Instance families target different shapes of workload: general purpose (balanced), compute-optimised for CPU-heavy work, memory-optimised for large in-memory data, storage-optimised for high disk throughput, and accelerated types with GPUs. I start from the bottleneck, test with a representative load, and rightsize rather than guess.

For purchasing, On-Demand has no commitment and suits unpredictable or short-term load. Savings Plans or Reserved capacity give a discount for committing to steady, long-running use. Spot uses spare capacity at a large discount but can be interrupted with short notice, so it fits fault-tolerant jobs like batch processing or stateless workers, not a single primary database.

What the interviewer is checking: Practical selection logic and cost awareness.

Likely follow-up: How would you make a Spot-based workload tolerate interruptions?

A security group is a virtual firewall attached to an instance's network interface. It is stateful: if inbound traffic is allowed, the response is automatically allowed back out. It only has allow rules, and all rules are evaluated together. A network ACL works at the subnet level, is stateless, so return traffic must be allowed explicitly, and supports both allow and deny rules evaluated in numbered order.

Day to day I do most filtering with security groups, and I can reference another security group as a source, for example letting only the load balancer's group reach the app tier. NACLs are a coarse extra layer, useful for blocking a specific bad address range across a whole subnet.

What the interviewer is checking: Stateful versus stateless and the level at which each applies.

Likely follow-up: A request works one way but the response never arrives. Which of the two would you suspect?

A VPC is your own logically isolated virtual network in a Region, with a CIDR range that you divide into subnets, each living in one AZ. What makes a subnet public is its route table: it has a route sending internet-bound traffic to an internet gateway, and instances also need a public IP to be reachable.

A private subnet has no such route, so nothing on the internet can start a connection to it. That is where I put app servers and databases. They can still make outbound calls through a NAT gateway placed in a public subnet. The usual layout is public subnets for load balancers, private subnets for application tiers and isolated subnets for data stores.

What the interviewer is checking: That you define public versus private by routing, not by name.

Likely follow-up: How do you let private instances reach S3 without using the internet at all?

An internet gateway makes a VPC reachable to and from the internet and performs address translation for instances that have public IPs; it is what turns a subnet public. A NAT gateway lets instances with only private addresses initiate outbound connections, for example to download packages, while preventing the internet from initiating connections back in.

The NAT gateway sits in a public subnet, and private route tables point their default route to it. It is a managed, resilient component within one AZ, so for high availability I create one per AZ. It charges for time and for data processed, which can become a large line item; gateway endpoints for S3 and DynamoDB, or interface endpoints, can keep that traffic off the NAT.

What the interviewer is checking: Network flow understanding plus awareness of the AZ and cost implications.

Likely follow-up: An instance in a private subnet cannot reach the internet. What do you check?

S3 now provides strong read-after-write consistency for object writes, overwrites and deletes, and list operations reflect them too. Older material that describes eventual consistency for overwrites is out of date, though it still shows up in interviews, so I mention the change.

Versioning keeps every version of an object. An overwrite creates a new version, and a delete just adds a delete marker, so I can restore accidentally removed or overwritten data. It does not protect against someone with permission deliberately deleting specific versions, and it increases storage cost because old versions accumulate, so I pair it with lifecycle rules to expire noncurrent versions. For stronger protection, add MFA delete or Object Lock, and replicate to another Region.

What the interviewer is checking: Up-to-date factual knowledge and understanding of what versioning really covers.

Likely follow-up: How do delete markers work, and how would you permanently remove an object?

A presigned URL embeds a signature, created with the credentials of whoever generated it, that grants time-limited permission to perform one specific operation, such as GET or PUT on one key. Anyone holding the URL can perform that action until it expires, without having AWS credentials themselves.

I use it so a browser can upload a photo directly to S3 or download a private invoice, instead of streaming the file through my server. Keep the expiry short, scope it to one key, and remember it is a bearer token: anyone who gets the link can use it. If it was signed with temporary role credentials, it stops working when those credentials expire, even if the URL's own time is longer.

# creates a GET link valid for 15 minutes (900 seconds)
aws s3 presign s3://<bucket>/<key> --expires-in 900

What the interviewer is checking: Secure direct-to-S3 access patterns and bearer-token awareness.

Likely follow-up: How would you restrict an upload URL so users cannot upload huge or wrong file types?

An Auto Scaling group launches and terminates instances from a launch template, keeping the count between a minimum and maximum around a desired capacity. Scaling policies adjust that, most simply target tracking, such as holding average CPU or requests per target near a chosen value. It also replaces instances that fail health checks and can spread them across AZs.

To be useful, the instances must be stateless and start themselves from an image or a startup script with no manual steps. A load balancer distributes traffic and its health checks feed the group, and warm-up times prevent it from reacting to a new instance's startup load. Sessions and uploads should live outside the instance, in a cache or S3.

What the interviewer is checking: Knows scaling needs stateless design and health integration, not just a policy.

Likely follow-up: Why might scaling on CPU be a poor signal for a queue-processing fleet?

An ALB works at layer 7. It understands HTTP and HTTPS, so it can route by host name, path or header, handle WebSockets, and terminate TLS. A NLB works at layer 4, forwarding TCP, UDP or TLS connections with very high throughput and low latency, and can provide a static IP per AZ.

I use an ALB for web apps and microservices where content-based routing helps, with target groups per service. I use an NLB for non-HTTP protocols, extreme performance, or when clients need fixed IPs for allow-listing. Both run health checks and only send traffic to healthy targets. The load balancer itself should span at least two AZs.

What the interviewer is checking: Layer 4 versus layer 7 and matching the tool to the protocol.

Likely follow-up: How would you route /api and /admin to different services behind one domain?

I decide by the data and the access patterns. RDS runs managed relational engines, so it fits structured data with relationships, joins, transactions and ad hoc queries, such as bookings linked to customers and payments. It scales mostly vertically, with read replicas for reads.

DynamoDB is a managed key-value and document store where I design tables around known queries using a partition key and optional sort key. It scales horizontally with consistently low latency but offers no joins and limited ad hoc querying, and a poor key choice creates hot partitions. If requirements are still fluid or reporting-heavy I start with RDS; if I have a clear, high-volume lookup pattern like session or order-by-id, DynamoDB fits well. Many systems use both.

What the interviewer is checking: Choosing by access patterns and trade-offs instead of fashion.

Likely follow-up: What is a hot partition in DynamoDB and how do you avoid one?

SQS is a queue: producers send messages, consumers pull them, and each message is processed by one consumer. It decouples services and absorbs bursts. SNS is publish and subscribe: a message published to a topic is pushed to every subscriber, such as queues, Lambda functions, HTTP endpoints or email.

A common pattern is fan-out: an order service publishes one event to an SNS topic, and separate SQS queues for billing, inventory and notifications each receive a copy and process at their own pace with their own retries. Standard queues deliver at least once and may reorder, so consumers must be idempotent; FIFO queues add ordering within a message group. A dead-letter queue catches messages that keep failing.

What the interviewer is checking: Queue versus pub/sub semantics and at-least-once delivery awareness.

Likely follow-up: What is the visibility timeout and what happens if it is too short?

A cold start is the extra latency when Lambda must create a new execution environment: fetch the code, start the runtime and run your initialisation code before handling the request. Later invocations reuse a warm environment and skip that cost. It is affected by runtime choice, package size, heavy initialisation, and sometimes network setup.

Mitigations: keep packages and dependencies small, create SDK clients outside the handler so warm calls reuse them, and use provisioned concurrency or options such as SnapStart for supported runtimes when latency matters. Lambda is a poor fit for very long-running jobs because of the maximum duration, for steady high-volume workloads where always-on containers cost less, or when you need fine control over the host.

What the interviewer is checking: Understands the mechanism, mitigations, and honest limits of serverless.

Likely follow-up: How does Lambda scale under a sudden spike, and what protects a database from being overwhelmed?

CloudFront is a content delivery network. Requests go to a nearby edge location; if the object is cached there it is returned immediately, otherwise CloudFront fetches it from the origin, such as S3 or a load balancer, and caches it according to TTL and cache-key settings. That reduces latency and origin load, and it also terminates TLS close to users.

To keep the bucket private, I block public access on it and use Origin Access Control so only that CloudFront distribution may read objects through a bucket policy. For updated files I prefer versioned file names, since invalidations are slower and may cost more. Dynamic and API traffic can also go through CloudFront with caching disabled or tuned.

What the interviewer is checking: Caching mechanics and the secure S3 origin pattern.

Likely follow-up: A user still sees the old CSS after deploy. What are your options?

It breaks least privilege: s3:* on * lets the service do anything to every bucket in the account, including deleting data or changing bucket policies. If the service is compromised, so is all your storage.

I would restrict actions to what the code needs, say s3:PutObject and s3:GetObject, and the resource to one bucket and prefix such as arn:aws:s3:::<bucket>/invoices/*. Add conditions where useful, attach it to a role not a user, and use IAM Access Analyzer and CloudTrail to see what is actually used so I can trim permissions further. Start narrow and widen on evidence rather than starting wide.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": "*"
    }
  ]
}

What the interviewer is checking: Applies least privilege to a concrete policy instead of reciting the phrase.

Likely follow-up: How would you give a partner's AWS account read access to just that prefix?

I enable S3 Block Public Access at the account level and on buckets, which overrides public ACLs and policies. Buckets stay private by default; access is granted to specific roles by identity or bucket policies, and ACLs are disabled where possible so one policy model is easy to audit.

I enforce encryption at rest and require TLS with a bucket policy condition. For content that must be public, I serve it through CloudFront with Origin Access Control instead of opening the bucket. IAM Access Analyzer and AWS Config rules detect drift, and the bucket definitions live in infrastructure as code, so changes go through review. Prevention, detection and a response runbook all matter.

What the interviewer is checking: Layered, defensive thinking about a common misconfiguration.

Likely follow-up: How would you find every public bucket across 40 accounts?

First, visibility: cost allocation tags, Cost Explorer and budgets with alerts, so I know which team and service drives spend. Then rightsizing: compare provisioned CPU and memory with real usage and shrink or switch instance types, and delete idle or orphaned resources such as unattached volumes and old snapshots.

Next, match purchasing to workload: Savings Plans for steady baselines, Spot for interruptible work, and auto scaling so capacity follows demand, including shutting down non-production environments out of hours. For storage, apply lifecycle policies and tiering. Finally, look at data transfer: traffic across AZs, out to the internet and through NAT gateways is often a surprise, and caching or VPC endpoints can reduce it.

What the interviewer is checking: Systematic approach starting with measurement before cutting.

Likely follow-up: When is it a mistake to commit to a one- or three-year plan?

High availability keeps a workload running through common failures, like an instance or an AZ going down, using redundancy and automatic failover within a Region. Disaster recovery is about restoring service after a major event, such as losing a Region, corrupted data or a destructive deployment, and usually involves a second location and backups.

RPO, recovery point objective, is how much data loss is acceptable, measured in time since the last good copy. RTO, recovery time objective, is how long you can be down. Tighter targets cost more. The usual strategies, in increasing cost and speed, are backup and restore, pilot light, warm standby and active-active across Regions. I choose per workload from business impact, and I test recovery regularly, because an untested backup is only a hope.

What the interviewer is checking: Distinguishes the two concepts and ties strategy to RPO, RTO and cost.

Likely follow-up: Backups exist and replication is on. How would a bad deployment that deletes data still hurt you?

Multi-AZ is for availability. In the classic setup RDS keeps a standby copy in another AZ using synchronous replication and fails over automatically if the primary has a problem. That standby is not used to serve read traffic, and the endpoint stays the same after failover.

Read replicas are for scaling reads. They use asynchronous replication, so they can lag, and applications connect to their separate endpoints. They can live in other Regions and can be promoted to standalone databases, which helps with migration or disaster recovery. So the question is availability versus read throughput: you can and often do use both together. Newer Multi-AZ options with readable standbys blur the line, so I check the specific engine.

What the interviewer is checking: Separates availability from read scaling and knows replication-lag consequences.

Likely follow-up: A replica shows stale data right after a write. How should the application cope?

Route 53 points to an Application Load Balancer in public subnets across at least two AZs, optionally behind CloudFront for static content and caching. The app runs on an Auto Scaling group or containers in private subnets, spread across the same AZs. The database is RDS with Multi-AZ in isolated subnets, and uploads go to S3.

Security groups chain tiers: the load balancer reaches the app, and only the app reaches the database. A NAT gateway per AZ gives outbound access, and sessions go to a cache or token, so instances are stateless. CloudWatch alarms, logs and tracing provide observability, and everything is defined in infrastructure as code. I then discuss the weak points: a single Region, the database failover time, and the cost of the extra AZ.

What the interviewer is checking: Structured architecture reasoning with named failure domains and trade-offs.

Likely follow-up: How would you extend this design to survive the loss of an entire Region?

The six pillars are operational excellence, security, reliability, performance efficiency, cost optimisation and sustainability. They are a lens for reviewing a design and exposing trade-offs rather than a checklist to maximise all at once.

An example is reliability versus cost. Multi-AZ databases, a NAT gateway per AZ and cross-Region replicas all raise availability but also the bill. For an internal tool with a tolerant business, single-AZ with good backups may be the right call; for a payment flow it is not. Likewise security pushes toward private subnets and least-privilege roles, which add operational work. I record those decisions and revisit them as requirements change.

What the interviewer is checking: Applies the framework to real trade-offs, not just recites the list.

Likely follow-up: Which pillar do teams most often neglect, and what is the consequence?

SQS delivers at least once, and a failed invocation returns the message to the queue after the visibility timeout, so the handler must be idempotent, for example by using a unique message or business ID and an upsert or conditional write. I set the queue's visibility timeout longer than the function timeout, or messages are reprocessed while still running.

I configure a dead-letter queue with a sensible receive count so poison messages stop looping, and report partial batch failures so one bad record does not retry the whole batch. To protect the database from a spike, I limit the event source's maximum concurrency or use connection pooling or a proxy. Then I alarm on queue age and dead-letter depth.

What the interviewer is checking: Understanding of distributed-systems realities: duplicates, retries, back-pressure.

Likely follow-up: When would you choose a FIFO queue, and what does it cost you?

I follow the packet's path. First, the private subnet's route table needs a default route to a NAT gateway. The NAT gateway must sit in a public subnet whose route table sends the default route to an internet gateway, and it needs an Elastic IP. Then I check the instance's security group allows outbound traffic, and that network ACLs permit both the outbound requests and the return traffic on ephemeral ports.

Also check DNS resolution is enabled in the VPC, that a proxy or OS firewall is not interfering, and that the NAT gateway is in the same healthy AZ. If only S3 or other AWS APIs are needed, a VPC endpoint avoids NAT entirely. Reachability Analyzer or VPC Flow Logs show exactly where the traffic is dropped.

What the interviewer is checking: Systematic network troubleshooting across route tables, gateways and filters.

Likely follow-up: How do VPC Flow Logs help tell a security group block from a NACL block?

I create a role in the target account whose trust policy names the pipeline's identity as allowed to assume it, and attach a permissions policy with only the deployment actions needed. The pipeline calls STS AssumeRole and receives temporary credentials that expire automatically. Both sides must allow it: the trust policy on the role, and an identity policy letting the caller assume that role.

If the pipeline runs outside AWS, I use OpenID Connect federation so the CI provider's short-lived token is exchanged for a role, removing stored keys altogether. I restrict the trust condition to the specific repository and branch, enable CloudTrail to audit every assumption, and set a short session duration. That limits damage if a token leaks.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::<account-id>:role/<pipeline-role>" },
      "Action": "sts:AssumeRole"
    }
  ]
}

What the interviewer is checking: Understands trust versus permission policies and temporary credentials.

Likely follow-up: What is the confused-deputy problem and how does an external ID help?