Scenario-Based AWS Interview Questions

“That's DNS caching doing its job. When a resolver looks up our name, it keeps the answer for as long as the record's TTL says. If the TTL was a day, some users won't see the change for up to a day, and a few clients with their own cache hold on even longer. I'd confirm it by querying the name through a few public resolvers with dig and looking at the TTL that's left. The important thing right now is not to switch the old servers off. I'd keep them serving, or have them forward to the new load balancer, and watch their traffic fall to zero before retiring them. For the next cutover, I'd lower the TTL to a minute or so at least one old TTL before the change, switch, then raise it once things are stable.”

“I'd measure before changing anything, using real user timing or synthetic checks from that continent. If most of the time is connection setup and downloading assets, distance is the problem, and CloudFront fixes a lot of it: static files come from a nearby edge, and even dynamic requests get faster because TLS ends close to the user and the edge keeps warm connections back to our origin. If server time is the slow part, that's our code or database, and geography isn't the fix. For non-HTTP traffic, Global Accelerator puts users onto the AWS network early. Only if that still isn't enough would I run the app in a second Region with latency-based routing, and then the hard question is where writes go, because the database can't simply be in two places.”

“When DNS fails only under load and every service is healthy, I suspect the resolver limit rather than the services. The Amazon-provided DNS resolver in a VPC only accepts a certain number of packets per second from each network interface, and an app that looks up names on every single request can hit that as traffic climbs. Past the limit, queries get dropped, so lookups time out now and then. I'd confirm it by measuring how many DNS queries each instance sends, and by checking the network driver's link-local allowance counter, which counts packets dropped for exactly this reason. The fix is a local DNS cache on each instance, like systemd-resolved, dnsmasq or unbound, so repeated lookups are answered on the box. I'd also look at the app, because reusing HTTP connections instead of opening a new one per call cuts lookups a lot.”

“AMI IDs are Regional. The same Amazon Linux image has a different ID in every Region, and our own custom images only exist where we built them. So a hard-coded ID works in one place and fails everywhere else. For AWS's public images, I'd stop hard-coding: CloudFormation can read the current image ID from the public Systems Manager parameters AWS publishes, using an SSM parameter type, so each Region resolves its own ID at deploy time. For our own AMIs, I'd copy them to the new Region as part of the image pipeline and keep each Region's ID in a parameter with the same name. While I'm in there, I'd check other things that don't travel: key pair names, certificate ARNs, and any Availability Zone names typed in instead of looked up.”

“The instance status check failing, rather than the system check, tells me the AWS hardware is fine and the problem is inside the OS. So I'd look at how it booted: the system log from the console, the instance screenshot, or the serial console if it's enabled. After an update, common causes are a bad fstab entry for a disk that isn't attached, a kernel that won't boot, or broken network config. If I can fix it through the serial console, great. If not, I stop the instance, detach its root volume, attach it to a healthy helper instance in the same AZ, mount it, fix the file, like adding nofail to that fstab line, then move the volume back and start it. Before any of this I'd take a snapshot so I can't make it worse.”

“The volume isn't really all there yet. When you create an EBS volume from a snapshot, you can use it straight away, but the blocks are fetched from S3 in the background, and any block you read before it has arrived is pulled on demand. So the first read of each block is slow, and a database that touches lots of data feels terrible until the volume has been read through. I'd confirm it from the volume metrics: high read latency that improves as the working set gets touched. To fix it now, I'd read the whole device once with fio or dd, which forces every block down. For next time, if restore speed matters, I'd turn on Fast Snapshot Restore for that snapshot in the Availability Zone we'd restore into, so new volumes are fast from the start. It costs money while it's on, so I'd keep it for the critical snapshots.”

“A retirement notice means the host underneath has a problem AWS can't fix in place, and on that date the instance will be stopped, or terminated if it's backed by instance store. I'd rather pick the moment myself than have it happen at three in the morning. First I check how it's built. If the root volume is EBS, a stop and start in a quiet window moves it to healthy hardware and the data stays. A reboot doesn't help, because the instance stays on the same host. If anything lives on instance store, like a cache or scratch files, it's gone after a stop, so I'd copy off anything that matters. I'd also check for a public IP without an Elastic IP, since that changes, and warn the service's users about the window. Then the bigger question: why is one instance critical enough that a hardware notice worries us?”

“I'd rank by what could kill the business, and that's losing the data, not an hour of downtime. So on day one I set up automated EBS snapshots with a lifecycle policy, and I actually restore one to prove it works. Then I'd look at why it went down twice. If it's the disk filling or memory running out, that might be a quick fix that buys breathing room. Next I'd move the database to RDS with Multi-AZ and automated backups, because that removes the scariest single point of failure and takes patching and failover off their plate. If there's time left, I'd make the app server rebuildable from a launch template and run two instances in different zones behind a load balancer. I'd tell the founder plainly what's done, what's left and how the running cost changes, so they can decide.”

“Auto Scaling reacts in minutes, and a TV spike hits in seconds, so I'd scale ahead rather than wait. I'd add a scheduled action to raise the group's minimum before airtime, and check our EC2 service quotas so we can actually launch that many. But the web tier is rarely what breaks. The single database is. So I'd put CloudFront in front for static files and anything cacheable, like the landing page, and push heavy reads to a read replica or a cache. Writes that don't need to be instant, like signup emails, can go on a queue. Tonight I'd run a quick load test to see where it bends. And I'd prepare a light static holding page, so if it does tip over, people see something friendly instead of errors.”

“That pattern sounds like cold starts. When no environment is warm, Lambda has to create one, load the runtime and run my setup code before the request is handled. I'd confirm it in the logs: cold invocations show an Init Duration on the REPORT line, and I'd see if those match the slow requests. Then I'd shrink the startup. Trim the deployment package, avoid importing big libraries I don't need, and make sure SDK clients and connections are created once outside the handler. More memory also gives more CPU, which can speed up initialisation. If it's a Java function, I'd look at SnapStart. And if the endpoint really can't afford any delay, provisioned concurrency keeps a set number of environments warm, which costs money even when idle, so I'd use it only where users feel it.”

“I'd split it into three hops: did the event reach EventBridge, did my rule match it, and did the call to the function work. The rule's metrics answer most of that. If nothing matched, the pattern is wrong or I'm looking in the wrong place. EC2 state change events go to the default bus in the Region where the instance runs, so a rule in another Region or on a custom bus never sees them. Patterns are also exact: a typo in the detail type, or Stopped with a capital S when the event says stopped, and nothing matches. I'd paste a real sample event into the pattern tester to check. If the rule matched but invocations failed, it's usually permissions: when the rule is created in code rather than the console, someone has to add the permission that lets EventBridge invoke the function. I'd also give the target a dead-letter queue so failures aren't silent.”

“I'd move everyone to Session Manager. The SSM agent on each instance makes an outbound connection to Systems Manager, so the engineer gets a shell in the browser or the CLI without any inbound port open and without SSH keys. To set it up, the instances need the agent, which many Amazon-provided images already include, an instance role with the core SSM managed policy, and a network path to the service, either through a NAT gateway or through VPC interface endpoints if the subnets are fully private. Access is controlled by IAM, so I can allow only certain teams or certain tagged instances, and session activity can be logged to CloudWatch or S3. It also supports port forwarding, which covers the case where someone needs to reach a private database from their laptop.”

“I'd move the pipeline to federation. Most CI systems can issue a short-lived OIDC token for each run. In IAM I add that provider as an OIDC identity provider, then create a deploy role whose trust policy accepts tokens from it. The important part is the conditions: I check the audience, and I check the subject claim so only our repository, and only the main branch or a production environment, can assume the role. Without the subject check, other repositories on the same CI service could try. The pipeline then assumes the role with web identity and gets temporary credentials that expire soon after the run. I'd give the role only what the deploy needs. Once a few deploys pass, I deactivate the old key, watch for anything that breaks, and then delete it.”

“I'd treat the password as leaked, since anyone who ever pulled that image or repo has it, so just moving it isn't enough; it has to change. Step one, I put the current password into Secrets Manager and change the app to fetch it at startup through its instance role, with a short cache and a re-fetch if a login fails. I deploy that while the old value still works. Step two, I rotate. To avoid downtime I'd use the alternating users approach: a second database user gets the new password, the secret switches to it, and once all instances have picked it up, the old user is disabled. Then I build a new image without the password, remove it from the config file, and turn on scheduled rotation so this stays fixed.”

“First I cancel the deletion, right now, before anything else. A key that's pending deletion also can't be used, so anything that needs to decrypt with it may already be failing. After cancelling, the key comes back disabled, so I enable it again and check the databases and backup jobs are healthy. The reason to move fast is that once a KMS key is actually deleted, all data encrypted under it, every backup included, can't be decrypted ever again. The waiting period, at least seven days, is the only safety net. Then I'd find out from CloudTrail who scheduled it and ask them why; it might be an honest cleanup mistake. Finally I'd make it hard to repeat: an EventBridge rule that alerts on any ScheduleKeyDeletion call, and a key policy or SCP that denies it to everyone except a break-glass role.”

“I'd treat it as a real compromise. First, contain it without destroying it. I take it out of the load balancer and the Auto Scaling group, so it isn't replaced and terminated automatically, and swap its security group for an isolation group with no rules. Existing tracked connections can survive a security group change, so I might add a network ACL deny as well. Then I snapshot its volumes for evidence. The attacker may have used the instance role, so I revoke its active sessions and check CloudTrail for what those credentials did, like launching more instances in other Regions. Then I look for the way in: an unpatched app, an exposed port, a leaked key. The server itself gets rebuilt from a clean image, never cleaned in place. And I'd tell the security lead early.”

“I'd keep scanned and unscanned files physically apart. Uploads go straight from the browser into a quarantine bucket through presigned URLs, and nothing in the app can hand out download links for that bucket. A new object event triggers the scan. I could run an antivirus engine in a Lambda function for small files, or in a container task for big ones, or use GuardDuty's malware protection for S3 if I'd rather not maintain the engine and its signatures. Clean files are copied to the serving bucket and the database record flips to available. Infected files move to a locked-down bucket, and security gets an alert. Two details matter. A scan that errors or times out must leave the file blocked, never marked clean. And the user needs feedback, so the file shows as processing until the scan finishes instead of failing silently.”

“I'd start by asking what saving we're aiming for, because the goal might be reachable another way. Then I'd lay out the risk in plain terms: if that one zone has trouble, the whole app is down until it recovers, and customers see it. I'd bring options rather than just a no. We could run fewer or smaller instances but keep them spread across both zones, since most of the cost comes from how many instances we run and how big they are, not from how many zones they sit in. We could look for savings in idle dev environments, old snapshots or commitments for steady workloads. Or we could move internal tools to one zone and keep customer-facing parts in two. If my manager still decides on one zone, that's their call, and I'd support it, but I'd write the decision and the accepted risk down so nobody is surprised later.”

“I'd start by getting a clear picture: tag everything with an owner and an environment, and chase whatever isn't tagged, because unknown resources are usually the waste. Then the big win is scheduling. If people only work office hours, most dev and test instances and databases can stop in the evening and on weekends. I'd use a scheduler, something like EventBridge Scheduler triggering a small function, and give the team an easy way to start things early or skip a night for a long test. Next I'd right-size, since dev boxes are often copies of production size, and delete unattached EBS volumes and old snapshots. The key is agreeing the schedule with the developers first, so nobody loses a half-finished test run at seven in the evening.”

“I'd fix production. The infrastructure as code rule exists to keep things reliable, and it shouldn't keep users down longer. But I'd do it carefully: I post in the incident channel what I'm about to change, get a second pair of eyes if anyone's around, make the smallest change that works, and write down exactly what I did and when. The danger with console changes is that the code no longer matches reality, so the next deploy quietly undoes the fix or fails halfway. That makes the follow-up as important as the fix. The next working day I put the same change into the template, run drift detection to confirm they match, and note it in the incident review. And I'd ask why the pipeline couldn't get a fix out fast enough, because that's the real gap.”

“First I'd open a stopped task and read its stopped reason, because it tells me whether this is a network problem or a permissions problem. If it's a timeout, the task can't reach ECR at all. In private subnets, Fargate needs either a route to a NAT gateway or VPC endpoints. With endpoints, people often add the ECR API one and forget the rest: you also need the ECR Docker registry endpoint and an S3 gateway endpoint, because the image layers are actually stored in S3. If logs go to CloudWatch, a logs endpoint too, and the endpoints' security group has to allow HTTPS from the tasks. If the reason says access denied, I'd check the task execution role, not the task role, since that's the one that pulls the image. And if it says there's no matching manifest, the image was built for a different CPU architecture.”

“On EKS with the default VPC CNI, every pod gets a real IP address from the subnet its node sits in, so pods can run out of addresses long before the nodes run out of CPU. There are two separate limits. One is the subnet: a small subnet with lots of pods simply has no free addresses left, and new pods get stuck creating with an IP assignment error. The other is per node: each instance type can hold only so many network interfaces and addresses, which caps how many pods it runs. I'd check free addresses in the subnets and the node's max pods, then read the CNI logs. If it's the node cap, prefix delegation hands each interface small blocks of addresses so a node fits many more pods. If the subnet is full, I'd add a secondary CIDR range to the VPC and use custom networking so pods draw from bigger subnets.”

“No deploy doesn't mean nothing changed, so I'd open Performance Insights or Database Insights and look at the top SQL by load for that hour. Usually one or two statements stand out. If it's a query that got slow because a table grew past the point where a missing index hurts, I'd check its plan and add the index. If it's a scheduled report someone started running at peak, I'd move it to a read replica or off hours. I'd also check the instance class: if it's a burstable type, it may simply have spent its CPU credits and dropped to baseline. And I'd look at connection count in case the app is retrying and piling on. If users are suffering right now, killing a runaway query or scaling up is fine as a stopgap, but I'd still find the query.”

“That's a cache stampede. The database was quietly sized for the few requests that miss the cache, and when the node came back empty, every request missed at the same moment and hit the database together. First I'd protect the database: limit traffic or serve a lighter version of the busiest pages, and warm the hottest keys with a script before letting full traffic back. For the lasting fix, I'd run the cache with a replica and automatic failover, so losing one node promotes a replica that already holds the data instead of starting cold. In the code, I'd make sure only one request rebuilds a missing key, using a short lock, while the others wait briefly or get a slightly stale value. And I'd add random jitter to expiry times, because keys that all expire together cause a smaller version of the same stampede.”