What AWS Cloud Engineer Interviews Actually Test in 2026

User data is a script or set of commands passed in at launch time. EC2 runs it once, or on every boot if you configure it that way, to bootstrap the instance: install packages, pull a config, register with a service. Instance metadata is different. It's a live HTTP endpoint on the instance itself (169.254.169.254) that exposes facts about the instance while it's running, its instance ID, its private IP, and its IAM role's temporary credentials.

Candidates who've only used user data in a tutorial usually don't realize metadata is a separate thing until an IAM question forces the connection. The real follow-up: how does the AWS SDK on that instance get credentials with nothing hardcoded anywhere? Through the metadata service, not user data.

Bucket policy, in almost every case. ACLs are the older, object- and bucket-level permission model, and AWS disabled them by default on new buckets starting in April 2023, recommending IAM and bucket policies for basically everything going forward.

If an interviewer asks about ACLs at all in 2026, they're usually checking whether you know they still exist for legacy compatibility, a bucket created years ago, cross-account log delivery from certain AWS services, not whether you'd design a new access model around them. Reaching for ACLs on a brand-new bucket without a specific legacy reason is a small tell that your mental model is a few years out of date.

Yes, and it's a genuinely common surprise. An incomplete multipart upload leaves the already-uploaded parts sitting in the bucket, billed at normal storage rates, even though the object never completed and never shows up in a normal listing.

The fix is a lifecycle rule that aborts incomplete multipart uploads after a set number of days. Buckets that have run for years without that rule can carry a surprising amount of orphaned, unusable data on the bill. It's a small line item individually. Across years of activity, it adds up to real money for data nobody can even use.

Network ACL. Security Groups are stateful, apply at the instance level, and only support allow rules, there's no way to write an explicit deny in a Security Group. A NACL is stateless, applies at the subnet level, and supports explicit deny rules evaluated in numbered order, exactly what you need to block one address without touching every instance's Security Group individually.

The question is really checking whether you know Security Groups can't deny anything at all. Candidates who reach for a Security Group rule to block an IP usually don't realize that option doesn't exist.

A Policy is a JSON document defining a set of permissions, nothing more. A Role is an identity, something that gets assumed, by an EC2 instance, a Lambda function, a user in another AWS account, or a federated identity coming through SSO. You attach policies to roles, not the other way around.

The common mistake interviewers watch for is conflating "least privilege" with "fewest policies." One overly broad policy attached to a role is worse for security than five narrow, specific policies attached to the same role, even though the second option looks messier on paper.

Because a static key that never expires is a static key that, if it leaks into a public GitHub repo, a log file, a Slack message, works forever until someone manually rotates or revokes it. Temporary credentials issued through a role expire on their own, typically within an hour, so a leaked credential has a short shelf life even if nobody notices the leak right away.

AWS's own guidance pushes toward IAM Identity Center for human access and roles for everything programmatic, treating a long-lived access key on an IAM user as something you should be able to explain, not something you reach for by default.

KMS manages encryption keys, it encrypts and decrypts data, or other keys, but doesn't store your actual secrets, an API key or a database password, as a retrievable value. Secrets Manager stores the secret itself, using a KMS key to encrypt it at rest, plus it adds rotation, versioning, and fine-grained access policies on the secret as its own object.

Candidates sometimes describe them as competing options. They're not. Secrets Manager is built on top of KMS, not an alternative to it.

Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, and Sustainability, the last one added as a sixth pillar in late 2021 (AWS Well-Architected Framework). The neglected one is almost always Operational Excellence, runbooks, post-incident reviews, change management, because its failures stay invisible until an incident happens and nobody has a documented process to follow.

Security and Reliability get attention by default because their failures are loud and visible. Operational Excellence failures are quiet right up until they aren't.

A Well-Architected Review identifies risks against the six pillars. It's a snapshot assessment, not a certification that the risks it found actually got fixed. Plenty of teams complete a review, get a long list of medium and high-risk items, and never circle back to remediate most of them because the review itself became the deliverable instead of a starting point.

My honest take: treating a completed review as the finish line is a bigger red flag in an interview than not having done a review at all. It signals the team optimizes for the appearance of being well-architected rather than the outcome.

AWS Cost Anomaly Detection, paired with budget alerts through AWS Budgets tied to an SNS topic that actually pages someone, rather than an email that sits unread. Anomaly Detection uses machine learning against your historical spend pattern, so it catches an unusual spike relative to your own baseline, rather than a fixed dollar threshold you'd have to guess at and constantly adjust.

The gap most teams have isn't the tooling, both are free to set up. It's that nobody's actually subscribed to the alert, or it's routed to an inbox checked once a week.

A stateless API deploy is straightforward, drain connections, stop routing new requests to the old instance, done in seconds. A WebSocket connection is long-lived by design, a user might be connected for hours, so "drain and terminate" either forcibly disconnects every active user on that instance or requires an unreasonably long wait for connections to close naturally.

The actual answer usually involves the client reconnecting automatically on disconnect, which the client-side code has to be built for deliberately, it doesn't happen for free, combined with a longer, more patient draining window on the load balancer than you'd ever use for a stateless service. You accept some brief reconnection blips as the trade-off instead of pretending zero-downtime means zero-interruption for every open connection.

A Region is a geographic area, us-east-1, eu-west-1, and so on. Inside each Region, AWS runs multiple Availability Zones, physically separate data centers with independent power, cooling, and networking, tied together by low-latency private links. An AZ going down (a bad transformer, a fiber cut, a cooling failure) is supposed to stay isolated from the AZ next door. That isolation is the entire reason multi-AZ deployments exist.

The practical gotcha most juniors miss: EBS volumes are pinned to a single AZ. If your instance in us-east-1a dies and you try to attach its volume to a fresh instance in us-east-1b, it won't work, you have to snapshot the volume and restore it in the new AZ first. That's why spreading an Auto Scaling group across AZs behind an ALB, with stateless instances and state pushed out to S3 or a Multi-AZ RDS instance, covers the failure mode that actually happens day to day. Going multi-region is a different, much more expensive bet against a Region-wide outage, which is rare enough that most teams should get multi-AZ solid first.

AWS is responsible for security "of" the cloud: the physical data centers, the host hypervisor, the network hardware, and for managed services, patching the underlying software (RDS's database engine patches, for instance). You're responsible for security "in" the cloud: how you configure IAM, whether your S3 buckets are public, whether your security groups are wide open, whether the OS is patched on your EC2 instances, and how you handle encryption and access control.

Where it gets confusing is the managed services in between. With RDS, AWS patches the engine and the underlying OS, but you're still responsible for the parameter group settings, who holds the database credentials, and whether the instance is reachable from the internet at all. With Lambda, AWS manages the entire runtime and host OS, so your responsibility narrows to your code, your IAM role's permissions, and your environment variables, don't put secrets in plaintext env vars there either. The line shifts as you move up the stack from EC2 to containers to serverless, less infrastructure to secure yourself, but the data and access control layer never becomes AWS's job.

ALB operates at layer 7. It understands HTTP and HTTPS, so it can route based on path, host header, or other headers, terminate TLS, and send traffic to different target groups depending on content. That's the right default for a typical web app or an API split across microservices behind one domain.

NLB operates at layer 4, forwarding TCP or UDP traffic without inspecting the payload at all. You reach for it when you need very low latency and very high throughput, a static IP per AZ (ALB doesn't offer that, NLB does, which matters if a partner needs to allowlist your IP), or you're balancing something that isn't HTTP, like a raw TCP service or a protocol that doesn't fit an HTTP model. The Classic Load Balancer is effectively legacy at this point, it lacks target groups and AWS stopped actively developing it years ago, so unless you're maintaining something old that never got migrated, there's no reason to provision a new one today.

CloudWatch is about metrics, logs, and alarms. It tells you what your resources are doing right now: CPU at 80%, error rate spiking, a Lambda function throttling. CloudTrail is an audit log. It records every API call made against your account, who made it, from what IP, using what credentials, and whether it succeeded or was denied. CloudWatch answers "is something wrong," CloudTrail answers "who did what, and when."

During a security incident, CloudTrail is where you start. If an S3 bucket suddenly became public, or an IAM role picked up a new inline policy, CloudWatch won't surface that at all unless you already built a metric filter or EventBridge rule watching for it. CloudTrail shows you the exact API call, PutBucketPolicy, AttachRolePolicy, along with the caller's access key or assumed role and the source IP, which is usually enough to tell whether it was a legitimate change, a misconfigured pipeline, or a compromised credential. Mature teams route CloudTrail events into CloudWatch Logs or a SIEM and set alarms on sensitive calls, root logins, IAM policy changes, security group edits, so nobody has to go digging after the fact.

This is almost always one of two things. Either the health check grace period is too short for the instance to finish bootstrapping (installing dependencies, warming a cache, registering with a load balancer) before the check starts failing it, or the check itself is pointed at the wrong thing, EC2 status instead of the actual application endpoint behind the load balancer.

Bump the grace period first and watch one full cycle before touching anything else. If instances still fail after a generous grace period, the problem usually isn't scaling configuration at all. It's the application not coming up cleanly, and Auto Scaling is just the thing making that failure loud and expensive instead of quiet.

gp2 ties IOPS to volume size, roughly 3 IOPS per GB, so hitting a reasonable IOPS number on a small volume means over-provisioning storage you don't need just to buy performance. gp3 decouples the two: a baseline 3,000 IOPS and 125 MB/s throughput on any volume size, with IOPS and throughput purchasable independently up to much higher ceilings, and it's cheaper per GB than gp2 to begin with.

The real signal isn't naming the numbers. It's whether you'd migrate a live production volume without downtime. You can, EBS supports modifying an attached volume's type in place, but the honest answer includes watching CloudWatch for a brief dip in throughput during the transition on genuinely busy volumes, instead of firing the API call and walking away.

Instance Store data disappears the moment the instance stops or terminates, which sounds strictly worse than EBS in every case. It isn't, for one specific shape of workload: you need the highest possible IOPS for data that's genuinely disposable, shuffle data in a distributed sort, or a Kafka broker's local log where replication elsewhere already handles durability.

The interviewer isn't testing whether you know Instance Store exists. They're testing whether you default to the safer option without thinking, or whether you can name the one case where the trade-off actually favors something that looks riskier on paper.

Request pricing, not storage pricing, is usually the surprise. S3 charges per PUT, COPY, POST, and LIST request, small amounts individually, but an application writing many small objects (one file per event, one object per log line) can rack up millions of requests a day well before the storage itself gets expensive.

The fix is almost never "store less data." It's batching, aggregating small writes into fewer, larger objects before they hit S3 at all, or buffering events and flushing on a schedule instead of writing one object per event. Candidates who only think about storage tiers miss this entirely, because the tier they picked was fine. The write pattern was the actual problem.

Multipart upload solves reliability and parallelism for a single large object, splitting it into parts that upload concurrently and can retry individually. Transfer Acceleration solves a different problem: distance. It routes uploads through CloudFront's edge network to get onto AWS's backbone sooner, which matters when the uploading client is geographically far from the bucket's region, a user in Singapore uploading to a bucket in us-east-1, for instance.

They're not competing options, you can use both together. The trap is treating Transfer Acceleration as a general performance switch for any slow upload. It does nothing for a client already close to the bucket's region, and AWS's own comparison tool shows a near-zero improvement in that case, worth knowing so you don't recommend it reflexively.

Route table first. Does the private subnet's route table actually point 0.0.0.0/0 at a NAT Gateway? Then the NAT Gateway itself, does it sit in a public subnet with its own route to an Internet Gateway? Then Security Group outbound rules, then the NACL on both subnets, since NACLs are stateless and have to allow the return traffic explicitly, beyond the outbound request alone.

Most candidates jump straight to Security Groups because that's the service name they remember best. The routing table is the actual culprit far more often, and it's the fastest thing to check first if you run the checklist in the order that matches how traffic really flows.

aws ec2 describe-route-tables 
 --filters "Name=association.subnet-id,Values=subnet-0abc123" 
 --query "RouteTables[].Routes"

A Gateway VPC Endpoint for S3. It's a route table entry, not a network interface, so there's no hourly cost the way there is for an Interface Endpoint, and traffic to S3 stays entirely on AWS's internal network instead of exiting through a NAT Gateway, which bills per GB processed on top of whatever data transfer charges apply.

The gotcha interviewers like to add: a Gateway Endpoint is regional and tied to specific route tables. Add a new private subnet later and forget to associate its route table with the endpoint, and traffic silently falls back to routing through NAT instead of erroring out, which means the mistake shows up as a cost anomaly weeks later, not an outage today.

Attach an IAM Role to the EC2 instance or Lambda function. The AWS SDK automatically picks up temporary credentials from the instance metadata service, no access keys anywhere in code or config. The near-universal follow-up is about IMDSv2, which requires a PUT request to fetch a session token before requesting the actual credentials, specifically to prevent SSRF attacks from tricking a vulnerable application into harvesting credentials through an unauthenticated GET.

Skip mentioning IMDSv2 unprompted and a security-focused interviewer usually asks about it directly anyway. Not bringing it up first is a minor tell, either way.

TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" 
 -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -H "X-aws-ec2-metadata-token: $TOKEN" 
 http://169.254.169.254/latest/meta-data/iam/security-credentials/

A Service Control Policy sits at the AWS Organizations level and caps what's possible for every principal in an account or OU, even the account's own administrators can't exceed it no matter what IAM policy they write. A permissions boundary is narrower, applied to a specific IAM user or role, capping what that one identity can do regardless of its attached policies.

You'd want both when delegating IAM creation itself, letting a team lead create roles for their own team, say. An SCP caps the entire account so nobody can ever touch billing or security services, and a permissions boundary on the roles that team lead creates makes sure they can't grant themselves permissions past what their own role allows. Without the boundary, delegated IAM creation is a privilege escalation path.

A confused deputy happens when a trusted third party, a SaaS vendor you've granted a cross-account role to, gets tricked into using its own legitimate permissions on behalf of an attacker, because the trust relationship doesn't verify who's actually asking. If Vendor A's account has a role trust policy that lets any caller assume it, and an attacker knows Vendor A's account ID, the attacker can potentially get Vendor A to act on their behalf.

ExternalId adds a shared secret the trust policy checks before allowing the AssumeRole call to succeed, so even a caller who somehow gets the right account ID and role ARN can't assume it without also knowing the ExternalId value, which only the legitimate vendor relationship has. It's a small addition to a trust policy that closes a real attack path AWS has documented specifically, not a theoretical one.

CloudTrail first, always. Search for CreateRole, PutRolePolicy, and AttachRolePolicy events against that role's name or ARN, which tells you who, or what automation, created it and when, before touching anything else. Only after knowing the origin do you decide whether it's legitimate automation nobody documented, a former employee's leftover access, or something worse.

If the origin turns out to be unexplainable, the honest next step isn't quietly deleting the policy. It's rotating anything that role could have touched and treating it as a real incident until proven otherwise. Deleting evidence before you understand it is the mistake that turns a containable problem into one where nobody ever finds out what happened.

Separate AWS accounts per team is the cleanest version of this in 2026, with a Transit Gateway connecting them where cross-team traffic is genuinely needed, and each account owning its own non-overlapping CIDR block planned out in advance. This is where teams get burned, picking CIDR ranges ad hoc per team without a shared allocation plan, then discovering two teams both used 10.0.0.0/16 the day they actually need to connect the two VPCs.

A shared VPC with per-team subnets works too, and costs less operationally to set up, but it means one team's misconfigured route table or overly broad Security Group can affect another team's workload in the same VPC, which separate accounts prevent by default through the account boundary itself.

Separate Auto Scaling groups and deployment pipelines per service is the baseline. A bad deploy to one service's instances shouldn't touch another service's instances at all. Beyond that, circuit breakers on service-to-service calls stop a slow or failing downstream dependency from exhausting the calling service's own connection pool or thread capacity while it waits on something that isn't coming back.

The part people skip: testing what actually happens once the circuit breaker trips. Does the calling service degrade gracefully, serve cached data, a simplified response, or does it just throw errors faster? A breaker that fails fast instead of failing gracefully still protects the platform, but it's a worse outcome for the user than most teams realize until they've actually tested it.

Multi-AZ RDS roughly doubles the compute cost for the standby replica, and AWS handles failover automatically, typically completing in 60 to 120 seconds with no application changes required, since the endpoint stays the same. A DIY failover script against a single-AZ instance costs less in raw compute but shifts real operational risk onto whoever wrote and maintains it. Does it handle a partial network partition correctly? Does it avoid split-brain if the primary comes back mid-failover? Has anyone actually tested it against a real failure instead of a simulated one?

I'd take Multi-AZ's extra cost over a custom failover script in almost every case I can think of. The failure mode you're protecting against is rare enough that most homegrown scripts never get properly tested before the one time they're actually needed.

Not a full rewrite into Terraform on day one. That's the textbook answer, and it's usually wrong in practice, since a from-scratch IaC rewrite against a system nobody fully understands yet tends to miss the console-configured edge cases that keep the thing running.

Import the highest-change-frequency resources first, using something like Terraformer or manually writing resource blocks and running terraform import, so the parts that change often get version control and review the soonest. Leave the stable, rarely touched pieces, a VPC that hasn't changed in two years, for later. Prioritizing by actual change frequency instead of trying to cover everything at once is the difference between a project that ships incrementally and one that stalls at 60% forever.

A Compute Savings Plan, or Reserved Instances if you want a slightly deeper discount in exchange for less flexibility, covers the steady-state web tier, since that load is predictable enough to commit to and the discount, up to roughly 72% over On-Demand on a 3-year all-upfront term, is worth the commitment. The nightly batch job goes on Spot if it's genuinely interruption-tolerant with checkpointing built in, since batch workloads with a flexible completion window are exactly what Spot's 90%-off pricing is meant for.

Mixing the two purchasing models on the same workload is the trap. Putting the steady-state tier on Spot to save money, then getting paged at 2am because AWS reclaimed half the web servers during a traffic spike, is a cost optimization that costs more than it saved the first time it actually happens.

CPU is rarely the actual bottleneck when latency climbs at moderate usage. Check IOPS and storage throughput against the volume's provisioned limit first, a query pattern doing more random reads can hit an IOPS ceiling long before CPU becomes the constraint. Then connection count against max_connections, and lock contention or long-running transactions blocking other queries behind them, both of which show up as climbing latency with CPU looking almost fine.

Candidates who stop at "CPU looks okay, so it's not a resource problem" are treating one metric as the whole picture. It's one input into a diagnosis, not the diagnosis itself.

A single failed health check doesn't immediately mark a target unhealthy. ALB requires a configurable number of consecutive failures, the unhealthy threshold, before it removes a target from rotation, preventing one flaky check from yanking a perfectly good instance out of service. The flip side matters just as much during a deploy: a target that's actually gone, an instance mid-termination, keeps receiving new connections for however long that threshold takes to trip, unless you've also configured connection draining, deregistration delay, to stop new traffic to it immediately while letting in-flight requests finish.

Teams that only tune the health check interval and skip the deregistration delay configuration are the ones who see a handful of failed requests during every deploy and can't figure out why. The health check side was tuned correctly. The draining side wasn't.

Customer-facing impact and recurrence risk are what actually matter, not the severity of the technical cause alone. A scary-looking technical near-miss that never reached a customer might still warrant a short writeup if the same failure mode could easily recur elsewhere in the system, while a customer-facing incident that's genuinely one-off and fully understood might only need a brief recap if there's nothing structural to fix.

The judgment call interviewers are actually testing: can you tell the difference between "this was bad" and "this teaches us something we'd otherwise repeat." Those aren't the same question, and treating every incident as postmortem-worthy burns a team out on process just as fast as skipping postmortems that were actually needed.

Hot partitions happen when the partition key has low cardinality, or when access patterns skew heavily toward a handful of values regardless of how many distinct keys exist. Two real options: redesign the partition key with a random suffix that spreads reads and writes across N logical partitions, which means scatter-gathering reads back together afterward and adding some latency, or put DAX in front of the table to cache the repeated reads hitting that one hot key.

The partition key redesign is the actual fix. DAX is what you ship at 2am while the redesign is still in progress, not a replacement for doing the redesign at all.

When a consumer receives a message from SQS, the message isn't deleted, it's just hidden from other consumers for the length of the visibility timeout (30 seconds by default). If your worker finishes and deletes the message before that window closes, everything's fine. If processing runs longer than the timeout, the message becomes visible again and a second consumer can pick it up and start on it too, now the same job is running twice.

The fix isn't simply setting a longer timeout, because you often don't know your worst-case processing time up front, and a timeout that's too long means a crashed worker holds a message hostage for a while before it's retried. The real answer is a heartbeat pattern: call ChangeMessageVisibility from inside the worker while it's still processing, extending the timeout in small increments as long as the job stays alive. If the worker crashes, it stops sending heartbeats and the message becomes visible again at the last extended timeout rather than sitting locked for the full original window. On top of that, your processing logic needs to be idempotent regardless, since SQS is at-least-once delivery by design, duplicates can still happen from network retries with no visibility timeout issue at all, so deduping on a message ID or business key downstream isn't optional if double-processing has real consequences.

Latency-based routing alone gets you the geographic split. Route 53 answers each DNS query with whichever Region has the lowest measured latency from the resolver's location, so US users land on us-east-1 and European users land on eu-west-1 without you hardcoding any geography. But latency routing by itself doesn't know or care whether the endpoint it's returning is actually healthy.

The failover piece comes from attaching a health check to each latency record. You configure Route 53 health checks against an endpoint in each Region, an ALB or a dedicated health path, and if us-east-1's health check starts failing, Route 53 stops returning that record for latency-based queries and falls through to the next best answer, typically routing US traffic to eu-west-1 instead of a dead endpoint. This is different from a pure Failover routing policy, which is built for a primary and secondary pair rather than a latency-optimized multi-region setup, so most teams combine latency records with health checks attached directly to them instead of bolting failover routing on top. The part people get wrong is skipping the health check entirely and assuming latency routing alone handles regional outages, it doesn't, it only tells you what's geographically closest, not what's alive.

Read replicas work by streaming the binlog (MySQL) or WAL (Postgres) from the primary to one or more replica instances asynchronously, and you point your read-heavy traffic, reporting queries, dashboards, search indexing jobs, at the replica endpoint instead of the primary. That takes load off the primary and scales reads horizontally, which is exactly what you want when your bottleneck is read volume and writes are still comfortably within one instance's capacity.

The part that trips teams up is that replication is asynchronous, so there's always some lag, usually milliseconds, but it can stretch to seconds or more under heavy write load or a large batch update on the primary. If your application reads its own writes right after making them, a user updates their profile, then the next page load reads from a replica that hasn't caught up yet, they'll see stale data, which looks like a bug even though the system is working as designed. The fix is either reading from the primary for that specific request path, checking the ReplicaLag metric in CloudWatch before trusting a replica for anything time-sensitive, or accepting eventual consistency for those particular queries. Read replicas also do nothing for you if the actual problem is write throughput or lock contention, that's a different problem entirely, and there you're looking at write-side fixes like better indexing, sharding, or moving to Aurora for more write scaling headroom.

Before touching anything, check CloudTrail data events, or S3 server access logs if enabled, for actual GetObject requests against that bucket over the past few weeks. That tells you whether anything real is actually using the public access, a CDN origin, a public asset folder, or whether it's genuinely unused and just misconfigured.

If something's using it, replace public access with a CloudFront distribution using Origin Access Control instead, which lets the bucket stay private while still serving content publicly through CloudFront. If nothing's using it, enable S3 Block Public Access at the bucket level and move on. Turning on Block Public Access first and checking usage after is the faster path to an outage, not the safer one.

AWS reclaims a Spot Instance whenever it needs the capacity back, and you get a two-minute interruption notice through the instance metadata endpoint, or an EventBridge event if you're watching for it, before termination. Two minutes is plenty if your architecture is built for it, and useless if it isn't.

In practice that means checkpointing progress somewhere durable, S3 or DynamoDB, at intervals shorter than your expected interruption window, not just at the end of the job. A worker polling for the interruption notice can catch the signal, stop pulling new work, flush its current checkpoint, and exit cleanly instead of getting killed mid-task. For queue-based batch processing this pairs naturally with SQS: if a Spot node dies before finishing a message, the visibility timeout just expires and another instance picks it back up, so the interrupted node doesn't need to do anything heroic, it just needs to avoid corrupting shared state on the way out. The workloads that get burned by Spot are the ones that assume a job runs start to finish on one long-lived instance with in-memory state and no checkpointing, that design belongs on On-Demand or Reserved capacity, not Spot.

Scheduled scaling handles the predictable part. Set a scaling action to add capacity a few minutes before the spike so instances are already warm and passing health checks when traffic actually arrives, instead of scrambling to catch up after latency has already climbed. Target tracking stays on as a safety net for anything scheduled scaling doesn't anticipate, a surprise spike on a Tuesday, a marketing email sent at an unusual hour.

Skip the scheduled half and you're purely reactive. Target tracking eventually catches up, but users feel every one of those first few minutes of degraded performance, every single morning, and that's a solved problem you're choosing not to solve.

Concurrency limits, almost always. Lambda's default regional concurrent execution limit sits at 1,000 (raisable by support request), and if timeouts only appear at scale, not at low volume, you've likely hit that ceiling and new invocations are queuing or throttling rather than running. Reserved concurrency on the critical function buys a guaranteed slice while you wait on a limit increase.

The secondary check is how S3 batches event notifications into the function. A burst of thousands of object creations at once can outpace whatever your downstream (a database, another API) can actually absorb, independent of Lambda's own limits entirely. This question filters candidates who debug Lambda as a code problem first instead of a capacity problem first.

VPC Peering connects exactly two VPCs and doesn't support transitive routing. Peer A to B and B to C, and A still can't reach C without its own direct connection to it. That's fine for a handful of VPCs. Once you're managing more than around 10 across multiple accounts, the peering mesh becomes unmanageable, connection count grows as n(n-1)/2, so 15 VPCs means 105 individual connections to maintain.

Transit Gateway is a hub-and-spoke model instead, every VPC attaches once and routes through the hub, scaling linearly instead of quadratically. I don't have a clean number for exactly where Transit Gateway's per-attachment pricing crosses over to cheaper than a peering mesh, that depends heavily on traffic patterns, but architecturally the operational crossover point is usually well before 15 VPCs, closer to 8 or 10.

Two separate things both have to allow it. Your IAM identity's policy has to permit GetObject on that bucket's ARN, and the bucket's own resource-based policy has to permit your principal specifically. One without the other doesn't work, and candidates get this half right constantly, configuring the caller's side and assuming that's sufficient.

The interviewer is checking whether you know S3 supports resource-based policies in addition to identity-based ones, which is genuinely unusual among AWS services. Most don't have a resource-side policy at all.

The trap is scoping the Resource to the bucket ARN alone, which grants access to every object in it. Scoping to a specific prefix means appending the prefix path with a wildcard to the object-level ARN, and GetObject is an object-level action, so the bucket ARN by itself won't work for it at all. You need s3:ListBucket separately, scoped to the bucket ARN with a condition on the prefix, plus GetObject scoped to the prefixed object ARN.

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

Candidates who write only the first statement and skip the ListBucket condition usually find out it's incomplete the first time their code tries to list objects under that prefix and gets denied.

Multi-AZ behind an Application Load Balancer, with an Auto Scaling group spread across at least two AZs so losing one doesn't take the whole service down. Route 53 health checks on the ALB, with a failover record pointing at a static, S3-hosted degraded page if the entire primary path goes down.

99.99% works out to roughly 52 minutes of downtime a year, and multi-AZ within a single region gets you there for most workloads on its own. I'd only reach for multi-region active-active if the SLA genuinely requires it. The operational complexity that comes with it is real, and most teams underestimate it until they're the ones running it at 2am.

Backup-and-restore is out immediately, restoring from backups takes hours in almost every realistic scenario, not minutes. Pilot light is the minimum viable tier, keeping core infrastructure, a database replica, minimal compute, running in a second region at low cost, then scaling it up fast when a failover actually happens. Warm standby, a scaled-down but fully running copy of the whole stack in the second region, is the safer choice if 15 minutes is a hard number with real consequences for missing it, since pilot light still needs time to scale up compute after the failover decision gets made.

Full active-active is overkill for a 15-minute RTO unless there's a separate reason for it, needing zero downtime specifically rather than just a fast recovery.

Pilot light, scaled up. Keep a minimal footprint running continuously in a second region, a database replica staying in sync, core networking already provisioned, but application compute scaled down to near-zero or not running at all until it's needed. When the primary region actually goes down, an automated runbook, not a manual one, scales the second region's compute up and cuts DNS over.

The honest trade-off: this costs meaningfully less than active-active every month, but recovery isn't instant. Expect real minutes of downtime during the actual cutover, not the near-zero downtime active-active would give you. For most companies, that trade is the right one. For a payments system where every minute of downtime has a hard dollar cost, it usually isn't, and that's a business decision, not a purely technical one.

Cost Explorer, filtered by service and then by usage type, not by account total. Data transfer is almost always the line item nobody modeled ahead of time, cross-region transfer and NAT Gateway processing charges add up fast and rarely show up in a rough back-of-envelope estimate. EC2 instances left running after a load test is a close second, and it's the more embarrassing one to explain.

Good candidates also mention setting up Cost Anomaly Detection proactively, so the next surprise gets flagged within a day or two instead of showing up as a monthly invoice a month after the spend already happened.

The honest first move is figuring out whether this needs a fix at all, or just a better alert. If it's genuinely self-healing with no measurable customer impact, the real problem might be an alert threshold set too aggressively, and tuning it, or adding a short grace period before it pages anyone, is a legitimate fix, not avoidance.

If it does have real impact, even a brief one, that's different, and the fix is root-causing the transient condition itself: a downstream dependency's connection pool briefly exhausting under a load pattern, a DNS resolution hiccup, a cold function scaling up. My honest opinion: too many teams reach straight for "just add a retry" here, when a retry papers over the symptom without anyone learning what caused it, and the same failure tends to come back in a slightly different, harder-to-diagnose form later.

Gateway VPC Endpoints for S3 and DynamoDB first, since traffic to those two services is often a meaningful chunk of what's routing through NAT unnecessarily, and Gateway Endpoints cost nothing extra to add. Interface Endpoints for other AWS services you talk to heavily cut NAT traffic further, though those carry their own hourly and per-GB cost, worth checking the actual NAT savings against the endpoint's own cost before adding it everywhere reflexively.

Beyond endpoints, check whether cross-AZ traffic within your own architecture is inflating the number. Data transferred between AZs, even without leaving the VPC at all, isn't free, and an architecture that fans requests across AZs more than necessary pays for that traffic twice, once in AZ transfer and again if any of it also happens to route through NAT.

Standard for the first stretch, maybe 30 days, while logs are still actively queried for recent incidents. Transition to Standard-IA or Intelligent-Tiering next, since access drops off sharply after the first month but millisecond retrieval still matters if something needs investigating. Past 90 days, Glacier Instant Retrieval or Flexible Retrieval for compliance-driven retention where access is rare but not zero. Deep Archive only if there's a real regulatory reason to keep years of logs nobody will ever query, since restore times there run hours, not seconds.

The part candidates skip: an expiration rule at the end. Logs kept forever with no deletion policy are the single most common reason a "we set up lifecycle tiering" answer still results in a storage bill that climbs every month regardless.