AWS Interview Questions for 3 Years Experience (2 to 4 Years)

“We moved a Lambda into our VPC so it could talk to a private RDS database, and right after that every call it made to a payment provider just hung until the timeout. The reason is that a VPC-attached function gets network interfaces in your subnets, and those never get a public IP, even if you put them in a public subnet. So there was simply no way out. The fix was to place the function in private subnets and point their route table at a NAT gateway that sits in a public subnet. It was also reading a secret from Secrets Manager, so we added an interface endpoint for that, which kept the call inside the VPC. Since then, whenever I attach a function to a VPC, I list every outside thing it calls before I deploy.”

“We had an order API on Lambda talking to a Postgres database on RDS. When a promotion went out, concurrency jumped into the hundreds, and every execution environment opened its own connection, so we blew past the database's connection limit and requests started failing. The first thing I checked was the code, and sure enough the connection was being opened inside the handler, so even warm invocations opened a fresh one. I moved it outside the handler so each environment reuses its connection. That helped, but it can't stop a burst of new environments, so we put RDS Proxy in front, which keeps a shared pool and hands connections out as needed. We also set reserved concurrency on the function so it can never open more than the database can take.”

“I wrote a Lambda that made thumbnails whenever an image landed in a bucket. To keep things simple, I wrote the thumbnails back into the same bucket. The trigger fired on every new object, including my thumbnails, so the function kept triggering itself. I noticed within about twenty minutes, because invocations on the dashboard shot straight up. The first thing I did was set the function's reserved concurrency to zero, which stops it instantly. Then I fixed the design: uploads go under one prefix, the trigger only listens to that prefix, and thumbnails go to a separate output bucket, so the function can't see its own output. I also added a CloudWatch alarm on invocations, and told the team what happened, since it cost us an unusual bill for the day.”

“I keep the handler thin. It pulls the bucket and key out of the event and passes them to plain functions, so most of the logic is ordinary Python I can unit test. For the parts that call AWS, I either stub the boto3 client with botocore's Stubber or use moto, which fakes S3 and DynamoDB in memory, so tests run fast and offline. I save real sample events as JSON files and use them with sam local invoke to check the wiring, like whether I'm reading the key right, since S3 URL-encodes it in the event. Then the pipeline deploys to a dev stage, where a small integration test uploads a real file and checks the item appears. Only after that does it go to production.”

“When a worker receives a message from SQS, the message isn't removed, it's just hidden for the visibility timeout. Ours was 30 seconds, but sending an email through our provider sometimes took longer on a slow day. So the message became visible again, a second worker picked it up, and both sent the email before either deleted it. I raised the visibility timeout well above our slowest processing time. But a standard queue can also deliver the same message twice on its own, so that alone isn't enough. The real fix was making the handler idempotent: before sending, it does a conditional write to a DynamoDB table keyed by the email job id, and if that id is already there it skips the send. After that, duplicates became harmless.”

“We had a Lambda reading order events from SQS in batches of ten. One message had a malformed date, the function threw, and because the whole batch failed, all ten went back to the queue and came round again, over and over. First I added a dead-letter queue with a redrive policy, so after a few failed receives a message gets moved aside instead of retrying forever. Then I turned on partial batch responses, so the function returns just the ids of the messages that failed and the other nine get deleted normally. We also put a CloudWatch alarm on the dead-letter queue having any messages, because a DLQ nobody watches just hides failures. Once I'd fixed the date parsing, I used the redrive option to send those messages back to the main queue.”

“A deploy pipeline started failing with AccessDenied when it tried to write to a bucket in another account. My first step was to check which role was really making the call, and CloudTrail showed it was the pipeline role, not the deploy role I expected, because a step was missing its assume-role. After I fixed that, it still failed, but the error message now said no resource-based policy allowed the action. Cross-account access needs both sides, so our role policy allowed the write, but the bucket policy in the other account didn't mention our role. I asked that team to add a statement scoped to that one role and prefix. The habit I kept is to work through the layers in order rather than widening our own policy, which would never have fixed it.”

“This one caught me once. S3 permissions were fine, but the objects were encrypted with a customer managed KMS key, and to read an object like that S3 has to ask KMS to decrypt it on your behalf, using your permissions. So the role also needs kms:Decrypt on that key, and for uploads it needs kms:GenerateDataKey. In our case the role's policy had nothing for KMS. There's a second layer too: the key has its own key policy, and unless it allows the caller or delegates to IAM in that account, an IAM policy alone won't help. I added kms:Decrypt on that key ARN only. When it's cross-account, you also can't use the default AWS managed key for S3, because you can't edit its policy, so it has to be a customer managed key.”

“We kept the database credentials in Secrets Manager. The service ran on ECS, its task role could read just that one secret, and the code fetched it at startup and cached it, so nothing sat in the repo, the image or the CloudFormation template. We picked Secrets Manager over a SecureString in Parameter Store mainly because it can rotate RDS passwords for you. That rotation bit us once: after the first rotation, the app kept its old cached password and started failing to connect. So I changed it to fetch the secret again when a login fails, then retry once. Before that project, I'd seen passwords sitting in plain Lambda environment variables in a template, and anyone who could read the stack could read the password.”

“The first thing I run is aws sts get-caller-identity, which tells me the account and the role I'm really using. aws configure list shows where each value came from, like an environment variable or a profile. In my case, I'd exported access keys for a test account in that terminal earlier, and environment variables win over the default profile in the config file, so my command went to the test account instead of the one I meant. Since then, I don't keep long-lived keys on my laptop at all. We use SSO, each account is a named profile, and I pass the profile on every command or set it per terminal. My shell prompt shows the current profile, and anything that deletes, I run get-caller-identity before it.”

“I get why they're asking, they want to ship. But admin on a pipeline role means anything that can change the pipeline can do anything in the account, and those grants never seem to get removed. So I'd sit with them for ten minutes and look at the actual error. It usually names the action and the resource, and if not, CloudTrail does. Most of the time it's one or two missing actions, like permission to pass a role or to write to a new bucket. I'd add exactly that, scoped to the resource, as a small change to the role's template and get it reviewed quickly. That usually unblocks them faster than arguing about admin. If it really was urgent and complex, I'd ask our lead for a time-boxed exception, not a permanent one.”

“I'd open Logs Insights, pick the service's log group and the last hour, and first count the errors in five-minute bins, because the shape tells me a lot: did it start at a deploy, is it still climbing, or was it one burst. Then I'd run a second query to see the latest error messages themselves. In my last project our logs were JSON, so I could also group by the error code or the route, which quickly showed that nearly every error came from one endpoint. For Lambda I also query the REPORT lines, which carry the duration of each invocation, to see if timeouts are the real cause. Once I know the pattern, I save the query so the next person on call doesn't have to write it again.”

“Our nightly export ran on Lambda from an EventBridge schedule, and I'd put an alarm on the function's Errors metric. Then someone disabled the rule during a change and forgot to turn it back on. The function didn't run, so it produced no errors, and the alarm just sat there, because no invocations means no data points to breach. The fix was to alarm on the thing we actually care about, that the job succeeded. I set an alarm on the Invocations metric being below one over a day, and set missing data to count as breaching, so silence itself raises the alarm. We also found the code caught some exceptions and only logged them, which kept the Errors metric at zero, so I added a metric filter on those log lines too.”

“During an incident, a teammate added an inbound rule to a security group in the console to let a new service in. A week later I added the same rule properly to our template, and the stack update failed because that rule already existed, so everything rolled back. I ran drift detection on the stack, and it showed the security group had a rule the template didn't know about. Since my change was going to add that exact rule, I removed the manual one in a quiet window and ran the update again, and CloudFormation put it back as part of the stack. After that we agreed that any change made by hand during an incident gets a ticket to move it into the template the next day.”

“When it happened, API Gateway was calling the function's live alias, and every deploy published a new version, so the rollback was quick. I pointed the alias back at the previous version and the errors stopped within a minute, with no rebuild. The bug was new code expecting an environment variable that existed in dev but not in production. Afterwards I changed our SAM template so deploys go through CodeDeploy. With an auto-published alias and a canary deployment preference, a small slice of traffic goes to the new version for a few minutes first. We attached a CloudWatch alarm on the alias's errors, so if it fires during that window, traffic shifts back on its own. I also added a pre-traffic hook that invokes the new version once with a test event before any real traffic reaches it.”

“Early on, I wrote a CloudFormation template for a new service where the Lambda's role had s3:* on every resource, because I wasn't sure which actions it needed and I wanted it to just work. The reviewer asked me to list exactly what the function called. It was two actions on one bucket. She pointed out that with the wildcard, a bug or a stolen credential could delete every bucket in the account. That stuck with me. Now I start with no permissions, run the function, and add what the AccessDenied errors ask for, scoped to the exact bucket and prefix. The same reviewer also caught me hard-coding an image ID for one region. When I review others' templates, wildcards in IAM are the first thing I look for.”

“We heard about it from users, not from CloudWatch, and that was the first lesson: the built-in EC2 metrics show CPU and network, but not how full the disk is. I got in with Session Manager, ran df, and the root volume was full. du pointed at the app's log folder, where debug logging had been left on after a release and nothing rotated the files. I compressed the old logs and moved them to S3 to get the app back up. Since we wanted headroom, I also increased the EBS volume size while it stayed attached, then grew the partition with growpart and the file system with xfs_growfs, with no reboot. For the cause, we added logrotate, turned debug logging off, and installed the CloudWatch agent with an alarm on disk used.”

“First I split them using the metrics: errors generated by the load balancer and errors returned by the targets are counted separately. Ours were from the balancer. The 502s were random and low, and the cause was keep-alive. Our Node service closed idle connections after five seconds, which is Node's default, while the load balancer keeps them open much longer and reuses them. Now and then it sent a request just as the app closed the connection, and that came back as a 502. Setting the app's keep-alive timeout longer than the balancer's idle timeout stopped it. The 504s were different: a report endpoint ran longer than the idle timeout, so the balancer gave up waiting. We moved that report to a background job instead of raising the timeout.”

“The activity history showed every instance being terminated for failing load balancer health checks. The target group said the health checks were timing out. So either the app wasn't up yet, or it was broken. I suspended the ReplaceUnhealthy process so one instance would stay alive, and looked at its cloud-init output log. The new release had added a warm-up step, and the app now took longer to start than our health check grace period, so the group killed it before it was ready. On top of that, our health path queried the database, so a slow database could also fail it. We raised the grace period, and I changed the health endpoint to report only whether the app itself is up. Then I resumed the process.”

“The page listed a customer's open orders. The code scanned the orders table with a filter on customer id and status. That worked in testing with a small table, but a Scan reads every item and only then applies the filter, so we were paying to read the whole table to return five orders, and it took several paged calls to get through it. I added a global secondary index with customer id as the partition key and status plus created date as the sort key, then changed the code to Query that index with a key condition. The page went from seconds to milliseconds, and read usage dropped sharply. One thing I had to explain in review is that reads from a global index are eventually consistent, which was fine for that page.”

“The bug was a read-modify-write. Two requests read the same order, each changed a field in code, and each wrote the whole item back with put_item, so whichever landed second wiped out the other one's change. I fixed it with optimistic locking. The item carries a version number, and the update has a condition that the version still equals the one I read. If someone else wrote in between, DynamoDB rejects it with a conditional check failure, and I read the item again and retry. I also switched to update_item so we only touch the fields we change. For a simple counter, you don't need a version at all, you just add to it in the update expression, which DynamoDB applies atomically.”

“Almost certainly pagination. list_objects_v2 hands back at most 1000 keys per call, with a flag saying there's more and a continuation token for the next page. My script called it once, got the first thousand, and happily finished. It worked on the test bucket because that had a few hundred files, so the bug only showed up in production. The fix is to use boto3's paginator, which follows the tokens for you. Also, a page with no matches has no Contents key at all, so I read it with get and a default of an empty list. Since then I treat every list or describe call as paginated, and before running a script like that for real, I print a count and check it against what I expect.”

“I was asked to move a service's instances from public subnets into private ones, and I said two days, since it felt like a subnet change. It took almost two weeks. What I missed was everything that quietly depended on those public IPs. The instances pulled packages at boot, so we needed a NAT gateway. They read from S3 a lot, so we added a gateway endpoint to keep that off the NAT. People SSH'd in directly, so we set up Session Manager. And a partner allowlisted our old IPs, so they had to add the NAT's address, which took a week of emails. Now, before I estimate a network change, I spend half a day listing everything that goes in and out, and I give a range with those unknowns called out.”

“I wouldn't delete anything on day one. First I'd try to find an owner: tags if there are any, and CloudTrail to see who created it, if it's recent enough. Then I'd check use. An unattached EBS volume is a good candidate, but I'd look at its name and snapshots, because sometimes it's a detached data disk someone still needs. For the bucket, I'd look at its request metrics or access logs, and search our templates and code for its name. Then I'd post a list in the team channel with a delete date two weeks out, tag everything with that date, and snapshot the volumes before deleting them. The snapshots are cheap to keep for a while and they turn a wrong call into a small restore instead of an incident.”