AWS interview questions and answers

A Region is a geographic location with its own isolated set of infrastructure. An Availability Zone is one or more discrete data centres inside a Region, with independent power, cooling and networking.

The consequence worth stating: spreading across AZs is how you survive a data centre failure and it is cheap, whereas spreading across Regions is how you survive a Region failure and it is expensive and complicated. Most designs should do the first and very few need the second.

One detail that catches people out: AZ names are mapped per account, so eu-west-1a in your account is not necessarily the same physical zone as in someone else's.

A role is an identity with permissions that no one owns permanently. Something assumes it and receives temporary credentials that expire, typically within an hour.

Access keys are the alternative and the problem: they are long-lived, they have to be stored somewhere, and that somewhere ends up being a config file, an environment variable or a commit. Leaked keys are one of the most common causes of real AWS incidents.

• On EC2, attach an instance profile and the SDK picks up credentials from the metadata service automatically.
• On EKS or ECS, use a service account or task role so each workload gets only what it needs.
• In CI, use OIDC federation so the pipeline exchanges its own identity token for a role, with no stored secret at all.
• Across accounts, let a principal in one account assume a role in the other.

The summary interviewers want: roles remove the thing that gets leaked.

The stateless half is the practical trap. A NACL that allows inbound on 443 but has no outbound rule for the ephemeral port range will let the request in and drop every reply, which presents as a timeout with a security group that looks perfectly correct.

In practice: use security groups for almost everything, and reach for NACLs only for a coarse subnet-level deny, such as blocking a range.

S3 is an object store with a flat namespace. There are no directories; a key just happens to contain slashes, and the console renders them as folders. Objects are immutable, so "editing" one replaces it in full.

Three consequences:

• No partial writes or appends. You cannot seek into an object and change ten bytes, which is why databases do not live on S3 directly.
• Listing is a query, not a directory read. Listing a prefix with millions of keys is paginated and slow, and there is no cheap "size of this folder".
• Renaming is copy then delete, because a key is part of the object's identity.

The detail worth adding: S3 is strongly consistent for reads after writes, which it has been since December 2020. Claiming it is eventually consistent is a common way to sound out of date.

Two things interviewers listen for. Instance store is ephemeral and does not survive a stop, which surprises people who think of it as a disk. And a stopped instance still costs money for its volumes, which is why "we stopped it to save money" is only partly true.

A group is not an identity and cannot be a principal in a policy, which is a detail that gets probed. And the modern answer to "how many users should we have" is close to zero: humans federate through SSO into roles, and workloads assume roles directly.

Two availability zones minimum, and three subnet tiers in each.

1. 1Public subnets, one per AZ, with a route for 0.0.0.0/0 to an internet gateway. The load balancer and the NAT gateways live here, and nothing else needs to.
2. 2Private application subnets, one per AZ, with a route for 0.0.0.0/0 to a NAT gateway in the same AZ. The instances or Pods live here and are not reachable from the internet.
3. 3Private data subnets, one per AZ, usually with no internet route at all. The database lives here and accepts traffic only from the application security group.

Security groups do the real enforcement: the load balancer group allows 443 from anywhere, the application group allows its port from the load balancer's group, and the database group allows its port from the application group. Referencing groups rather than CIDRs means the rules stay correct as instances come and go.

Two senior-sounding details. Put a NAT gateway in each AZ rather than sharing one, or an AZ failure takes out outbound traffic for the others and you pay cross-AZ transfer in normal operation. And use VPC endpoints for S3 and DynamoDB so that traffic skips the NAT gateway entirely, which is both faster and noticeably cheaper.

Through a NAT gateway that lives in a public subnet. The private subnet's route table sends 0.0.0.0/0 to the NAT gateway; the NAT gateway's own subnet routes 0.0.0.0/0 to the internet gateway.

That indirection is the whole answer, and putting the NAT gateway in the private subnet is the classic mistake: it then has no path out itself, and nothing works.

What makes a subnet public or private is only its route table. The name is a convention.

NAT is outbound only, so it lets the instance fetch packages and call APIs while nothing on the internet can initiate a connection to it. If you need inbound, that is a load balancer in the public subnet, not NAT.

Worth mentioning the cost, since it is a common real-world surprise: NAT gateways charge per hour and per gigabyte processed, and a chatty workload pulling images through one can cost more than the instances. VPC endpoints for S3, ECR and DynamoDB remove that traffic.

The distinguishing details: an ALB gets a DNS name whose IPs change, so it cannot be an allowlist target, whereas an NLB can have a static or Elastic IP per AZ. An NLB preserves the client IP, while an ALB needs X-Forwarded-For. And CloudFront is not a load balancer, it sits in front of one.

The hairpin trap is worth volunteering: a target that reaches the NLB in front of itself hangs, because the source and destination are the same interface. That is the design, not a bug.

The mistake to name is using EFS as a general-purpose disk. It is a network filesystem, so per-operation latency is far higher than EBS, and workloads with many small file operations perform badly on it.

Also worth saying that an EBS volume lives in one AZ, so an EBS-backed instance cannot simply move availability zone. You take a snapshot, which is stored in S3, and restore into the other AZ.

A scaling policy watches a CloudWatch metric and acts on an alarm. Three kinds:

• Target tracking aims at a value, such as 60% average CPU, and AWS works out the rest. This is the right default.
• Step scaling adds a different number of instances depending on how far past the threshold the metric is.
• Scheduled changes capacity by time, for a known daily or weekly pattern.

The parts people miss matter more than the policy type. Health checks: pointing the group at the load balancer's health check rather than just EC2 status means it replaces an instance whose application is broken but whose OS is fine. Warm-up and cooldown: without them the group scales again before the new instance is serving, and oscillates. And the metric has to reflect load: CPU is a poor proxy for an IO-bound service, which may be saturated at 20% CPU, so a request-count or queue-depth target is often better.

Worth adding that scaling out is fast and scaling in is deliberately slow, because a wrong scale-in drops connections.

Confirm which identity is actually being used first, because it is often not the one you assumed.

aws sts get-caller-identity

The credential chain picks up environment variables before the profile, so a stale AWS_ACCESS_KEY_ID export explains a surprising share of these. aws configure list shows where each value came from.

Then ask IAM rather than guessing:

aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789012:role/AppRole \
  --action-names s3:PutObject \
  --resource-arns arn:aws:s3:::acme-uploads/report.pdf \
  --query 'EvaluationResults[].[EvalDecision,MatchedStatements[].SourcePolicyId]'

implicitDeny means nothing grants the action, so add it. explicitDeny names the policy doing the blocking, and an explicit deny beats every allow anywhere.

If the resource is in another account, check its resource policy too. Cross-account access requires both sides to allow it, and the error looks identical either way.

They solve different problems and the question is often a check on whether you conflate them. Multi-AZ gives you no extra read capacity; a read replica gives you no automatic failover, and because replication is asynchronous it can lag, so reading your own write from a replica may not return it.

The detail worth adding: failover is a DNS change on the endpoint, so the application has to reconnect and should not cache the resolved IP. Java's default DNS caching has caused real outages here.

Block public access at the account level, and treat everything else as defence in depth.

1. 1Turn on S3 Block Public Access, ideally for the whole account. It overrides bucket policies and ACLs, so it is the control that actually holds.
2. 2Disable ACLs by setting object ownership to bucket owner enforced. ACLs are legacy and are the mechanism behind most accidental exposure.
3. 3Write a least-privilege bucket policy, and consider denying any request where aws:SecureTransport is false so plaintext HTTP is refused outright.
4. 4Turn on default encryption, with SSE-S3 or SSE-KMS where you need key-level audit and control.
5. 5Serve content through CloudFront with OAC rather than making objects public, which is the normal way to publish static assets while keeping the bucket closed.

Worth naming the real-world failure: buckets are almost never exposed by a subtle policy bug. They are exposed by a legacy ACL, or by someone ticking public to make a demo work.

Look before changing anything, and go from coarse to fine.

aws ce get-cost-and-usage \
  --time-period Start=2026-08-01,End=2026-09-01 \
  --granularity MONTHLY --metrics UnblendedCost \
  --group-by Type=DIMENSION,Key=SERVICE

Cost Explorer grouped by service tells you where, then grouping by usage type tells you what, which is the step that actually names the cause.

The usual culprits, in rough order of how often they are the answer:

• Data transfer, especially NAT gateway processing and cross-AZ traffic. It hides because it is not attributed to the service that caused it.
• Forgotten resources: unattached EBS volumes, old snapshots, idle load balancers, Elastic IPs that are not associated.
• Storage growth where no lifecycle policy exists, so every log ever written is still in Standard.
• A change in behaviour, such as a retry storm or a new log level, which multiplies request counts rather than resource counts.

The habit worth stating: without cost allocation tags this investigation is guesswork, so tagging is a prerequisite rather than a nice-to-have.

A cold start is the time to create an execution environment before your code runs: downloading the package, starting the runtime, and running any initialisation outside the handler. Subsequent invocations reuse that environment and skip it.

It matters for user-facing synchronous requests and rarely anywhere else. A queue consumer or a nightly job does not care.

What actually helps, in order:

• Smaller packages and fewer dependencies, since the download is part of the cost.
• Move work out of the handler only if it should be reused, and be aware that anything initialised outside the handler persists between invocations, which is how connection reuse works and also how state leaks between requests.
• More memory, because CPU scales with it, so a larger setting is sometimes both faster and cheaper overall.
• Provisioned concurrency for a known latency requirement, accepting that you now pay for idle capacity and have given up part of the serverless bargain.

Worth mentioning that a VPC-attached Lambda used to add seconds to a cold start. That was largely fixed in 2019, and repeating the old warning dates you.

Deny by default, then in this order:

1. 1Explicit deny anywhere. Any deny in any applicable policy ends it immediately, and nothing can override it.
2. 2Service control policies, if the account is in an Organization. An SCP is a ceiling, not a grant: it can only remove permissions, never add them, and an action missing from an SCP is denied even if the identity policy allows it.
3. 3Resource control policies and permission boundaries, which are also ceilings on what can be allowed.
4. 4Identity-based policies on the user or role.
5. 5Resource-based policies on the resource itself, such as a bucket policy or a KMS key policy.
6. 6Session policies, if the credentials came from AssumeRole with one attached.

Two consequences that mark a senior answer. Within the same account, an identity policy or a resource policy is enough, so a bucket policy alone can grant access. Across accounts, both sides must allow it, which is why cross-account debugging so often ends at a resource policy nobody thought to check. And a permission boundary on a role means a developer with iam:* still cannot escalate past it, which is how you delegate IAM safely.

Multiple accounts, because the account is AWS's strongest isolation boundary. A mistake in one cannot consume another's quotas, and its blast radius genuinely stops there.

A reasonable baseline:

• A management account that does nothing but hold the Organization. No workloads.
• A security or audit account owning CloudTrail organisation trails, Config, and GuardDuty findings, with read-only access into the rest.
• A shared services account for CI, artefact registries and shared networking.
• One account per environment per workload, so production is isolated from staging rather than separated by a tag or a naming convention.

Then: SCPs at the organisational unit level to deny whole classes of action, such as leaving the Organization or disabling CloudTrail. IAM Identity Center for human access, so people assume roles rather than holding users. And a landing zone, whether Control Tower or your own Terraform, because manually configured accounts drift immediately.

The honest trade: multi-account adds real overhead in networking, DNS and cost visibility, and for a very small team a single account with tight IAM can be the better call. Saying that is worth more than reciting the reference architecture.

Two very different questions, and conflating them is the trap.

An AZ failure should be a non-event. Instances spread across at least two AZs behind a load balancer, Auto Scaling replacing what it lost, RDS Multi-AZ failing over, and a NAT gateway per AZ so outbound survives. What actually breaks in practice: capacity, because you now need the remaining AZs to absorb everything, so running at 90% utilisation across two AZs means an AZ loss is an outage anyway. And anything single-homed, such as a lone EBS volume or a service pinned to one subnet.

A Region failure is a design decision, not a configuration. Honest options:

The senior point: almost nobody needs active-active, and claiming it without having tested a failover is worse than admitting the recovery time. Also worth naming that the global control plane dependencies bite here. IAM, Route 53 and S3 bucket naming are global, and several services have historically had us-east-1 control plane dependencies, which has turned regional incidents into wider ones.

At sustained, predictable load. Lambda's price per unit of compute is high; what makes it cheap is paying nothing when idle. Remove the idle and the arithmetic inverts.

Roughly: spiky, bursty or low-volume workloads favour Lambda. A service handling steady traffic all day is usually cheaper on containers or reserved instances, and the crossover is often lower than people expect.

The costs that are easy to miss:

• API Gateway frequently costs more than the Lambda behind it, and an ALB or Function URL can be much cheaper at volume.
• Per-request charges compound with chatty architectures, where one user action fans out into many invocations.
• NAT gateway processing for VPC-attached functions.
• Step Functions state transitions, which are billed per transition and add up fast in a loop.

The framing worth offering: the real argument for serverless is usually operational rather than financial, and the honest comparison includes engineering time, not just the bill.

Never in code, never in environment variables set from a repository, and never in an AMI.

The parts that matter beyond picking a service. Fetch at runtime and cache with a short TTL, so rotation takes effect without a redeploy. Grant per-secret, not secretsmanager:*, so a compromised workload cannot read everything. Encrypt with a customer-managed KMS key where you need the key policy as a second gate and an audit trail of decryptions.

And the answer interviewers most want to hear: prefer no secret at all. IAM roles, RDS IAM authentication and OIDC federation remove the credential rather than protecting it, and you cannot leak what does not exist.

When the work can be interrupted, and that is a narrower set than the discount tempts you into. Spot is up to about 90% cheaper and can be reclaimed with two minutes of notice.

Good fits: CI runners, batch and data processing, stateless web tiers with enough capacity headroom, and Kubernetes nodes for workloads that tolerate rescheduling. Bad fits: anything holding state locally, long jobs with no checkpointing, and a control plane.

Using it safely:

• Handle the interruption notice. Two minutes is enough to drain connections and checkpoint, and a workload that ignores it will lose work.
• Diversify across instance types and AZs, because capacity is per pool. A single type in a single AZ is the way to get reclaimed constantly.
• Mix with on-demand, so a base of guaranteed capacity carries you when spot dries up.
• Never assume it is available. A spot request can simply not be fulfilled.

Also worth mentioning Savings Plans and reserved capacity as the other lever: for the steady base of a workload they give a meaningful discount with no interruption risk, and the two strategies are complementary rather than alternatives.

Quotas are per-account, usually per-Region limits on how much of a service you can use. Some are adjustable and some are hard. They cause incidents because they are invisible until you hit one, and the failure arrives as a throttle or a refusal in the middle of something else going wrong.

The pattern is always the same: an incident triggers scaling, scaling hits a quota, and the quota turns a recoverable event into an outage. Classic examples are Elastic IPs per Region, VPCs per Region, running on-demand vCPUs, Lambda concurrent executions, and API rate limits on the control plane.

aws service-quotas list-service-quotas --service-code ec2 \
  --query 'Quotas[?Adjustable==`true`].[QuotaName,Value]' --output table

What good looks like: know the quotas your scaling path depends on, alarm on utilisation rather than on breach, request increases before you need them since they are not instant, and treat a quota as part of capacity planning. The senior version of the answer mentions that API throttling on the control plane is itself a quota, which is why a retry storm during an incident makes recovery slower.

They get conflated because all three are described as monitoring. The distinction that matters in an interview is that CloudTrail is your audit and forensic trail, so it belongs in a separate account with the management account unable to delete it, while Config is how you answer compliance and drift questions.

Two practical details. CloudTrail management events are free for the first copy and data events, such as S3 object access, are not, which is why full data event logging on a busy bucket gets expensive. And CloudWatch Logs charges for ingestion, so a debug log level left on in production shows up on the bill before anyone notices it in the logs.

The reasoning matters more than the choice. Fargate removes capacity management and is usually right for a small team. ECS on EC2 gives you the host back when you need specialised instances or want to pack tasks densely. EKS is right when the team already knows Kubernetes, when you want an ecosystem of operators, or when portability across clouds is a real requirement rather than an aspiration.

The answer that reads as experience is naming what EKS actually costs: a control plane charge, an upgrade cadence you cannot ignore, and enough Kubernetes knowledge on the team to debug it at three in the morning. Choosing it because it is the default is the mistake.

AWS is responsible for the security of the cloud. You are responsible for security in it.

• AWS: the physical data centres, the hardware, the hypervisor, and the managed service software itself.
• You: your IAM policies, your security groups, your patching where you run the operating system, your encryption choices, and your data.

The line moves with the service, which is the part worth saying. On EC2 you patch the operating system. On RDS, AWS patches the database engine but you still control network access, credentials and encryption. On Lambda you own almost nothing but your code, its dependencies and its permissions.

The practical consequence: a public S3 bucket or a leaked key is never an AWS failure, and those are what actual breaches are made of.

Route 53 resolves a name, and a routing policy decides what it returns. For availability the relevant ones are:

• Failover: a primary and a secondary record, where the secondary is returned only when the primary's health check fails.
• Latency-based: returns the Region with the lowest latency for that resolver.
• Weighted: splits traffic by proportion, which is how you do a canary across Regions.
• Geolocation: answers by where the query came from, usually for data residency.

The limitation to volunteer is DNS caching. Failover is only as fast as the TTL plus whatever the resolver and the client actually honour, and some clients cache far longer than they should. So DNS failover is measured in minutes, not seconds, and if you need faster you want something in the data path, such as a global accelerator or an active load balancer.

Also worth knowing that a health check on a private endpoint needs a CloudWatch alarm as its source, because Route 53 checks from the public internet.

By matching the class to the access pattern, and the saving comes almost entirely from data that nobody reads any more.

A lifecycle policy then moves objects by age and expires them, which is the part that actually reduces the bill because it stops the bucket growing forever.

The traps worth naming. Transitions cost money per object, so moving millions of tiny objects can cost more than it saves, and there are minimum storage durations, so an object deleted early from Standard-IA is still billed for thirty days. Intelligent-Tiering has a small monitoring charge per object, which makes it a poor fit for very many very small objects. And incomplete multipart uploads accumulate invisibly: they do not appear in a normal listing and they are billed, so a rule to abort them is nearly free money.

When the access patterns are known and narrow, and you need them to stay fast at any scale.

The real decision is whether you know your queries. DynamoDB requires you to design the table around the access patterns, and a query nobody planned for means a new index or a scan. RDS lets you ask questions you had not thought of, which is worth a great deal early in a product's life.

The answer that shows experience: most teams reaching for DynamoDB for scale do not have a scale problem, and a relational database with proper indexes handles far more than people assume. Choose DynamoDB for the access pattern and the operational model, not because it sounds more scalable.