AWS Interview Questions

"I start with what the app is short of. EC2 groups instances into families: general purpose for balanced web and app servers, compute optimized for CPU-heavy work like encoding or batch jobs, memory optimized for caches and in-memory databases, storage optimized for very fast local disk, and accelerated instances with GPUs for machine learning. Inside a family, the size just scales CPU and memory together. Burstable types are fine for small services that idle most of the day but can run out of CPU credits under steady load. I'd also check whether the code runs on ARM, because the Graviton types usually give better value. Then I don't guess for long: I pick a sensible size, load test it, watch CPU and memory in CloudWatch, and right-size from there."

"There are four main ways to pay. On-Demand has no commitment, so it's right for new workloads, spiky traffic, or anything I don't understand yet. Once I know the steady baseline a system always needs, I cover that with a Savings Plan or Reserved Instances, committing for one or three years in exchange for a much lower rate. Savings Plans are the more flexible choice, since a compute plan follows you across instance families and regions. Spot is spare capacity sold cheaply, but AWS can reclaim it with a two-minute notice, so I only use it for stateless or restartable work like batch jobs, CI runners or extra web nodes behind a load balancer. Dedicated Hosts are for when a software licence or a compliance rule needs physical isolation. In practice a good setup mixes them: commitments for the floor, On-Demand and Spot above it."

"Standard is the default for data that's read often. If I honestly don't know how often something will be read, Intelligent-Tiering moves each object between tiers for me based on access, for a small monitoring charge. For data that's read rarely but must come back fast, like old reports, there's Standard-IA, and One Zone-IA if the data can be recreated, since it lives in one Availability Zone only. Those charge per retrieval and have a minimum storage duration, so they're wrong for short-lived files. Then there are the Glacier classes for archives: Instant Retrieval, Flexible Retrieval that takes minutes to hours, and Deep Archive, the cheapest, where a restore takes hours. To move data automatically I set a lifecycle rule, say logs go to Standard-IA after a month, to Glacier after a quarter, and get deleted after a year."

"Yes. S3 has had strong read-after-write consistency since late 2020, so once a PUT succeeds, any read after it gets the new data, and that covers overwrites, deletes and list operations too. Before that, overwrites and deletes were only eventually consistent, which is why you still see old code with retries or extra databases just to track what's really in a bucket. What strong consistency does not give me is locking. If two processes write the same key at almost the same time, the one that lands last wins and the other write is simply gone. So if I need coordination, like only one worker processing a file, I use a conditional write, which S3 itself now supports with an if-none-match or if-match check, or a lock record in DynamoDB. Turning on versioning also means an overwrite never destroys the older copy."

"I'd go layer by layer. First, make sure nothing is public. New buckets now start with Block Public Access on and ACLs disabled, but I'd confirm both, turn Block Public Access on for the whole account too, and make sure no bucket policy has a wildcard principal. Second, access goes through IAM roles with the smallest set of actions and prefixes each service needs, and I add a bucket policy that denies any request not using HTTPS. Third, encryption. New objects are encrypted at rest by default now, but for customer documents I'd use a KMS key, so key use is logged and I can control who may decrypt. Fourth, protection from mistakes: versioning so an overwrite or delete can be undone, and Object Lock if there's a retention rule. Finally, logging, with CloudTrail data events so I can see who read what. Customers get files through short-lived presigned URLs, never a public link."

"I'd use a presigned URL. The browser calls my API and says it wants to upload a file. The API checks the user is logged in and allowed to, then picks the object key itself, something like the user's ID plus a random name, so nobody can overwrite someone else's file. It signs a PUT URL for that exact key with a short expiry, a few minutes, using the backend's own role. The browser uploads straight to S3 with that URL, so the heavy traffic never touches my servers and no AWS credentials ever reach the client. For very large files I'd use multipart upload with a presigned URL per part. Then I need to know it landed, so either an S3 event triggers processing, or the client tells the API and the API checks the object exists. The bucket also needs a CORS rule that allows the PUT from my site."

"A policy is the rulebook: a JSON document that allows or denies actions, like reading objects in one bucket. On its own it does nothing until it's attached to an identity or a resource. A user is a long-term identity, a person or an old-style application, with a console password or access keys. A group is just a way to attach the same policies to many users, like a developers group. A role is different: it has no permanent credentials. Someone or something assumes it and gets temporary credentials that expire, maybe an EC2 instance, a Lambda function, a user from another account, or a person signing in through single sign-on. These days I'd push almost everything towards roles, because temporary credentials expire on their own, so a leaked one isn't useful for months the way a forgotten access key is."

"It should never have access keys in the code, a config file or environment variables. I'd create an IAM role whose policy allows reading only the bucket, or the prefix, that the app needs, and attach it to the instance through an instance profile. Then the AWS SDK finds the credentials by itself: it asks the instance metadata service, gets temporary credentials, and refreshes them before they expire, so there's nothing to rotate or leak into a repository. I'd also require IMDSv2 on the instance, because it uses a session token and makes it much harder for a bug like server-side request forgery to steal those credentials. The same idea applies everywhere: Lambda functions get an execution role, and containers get a task role."

"I think of it as a funnel. It starts from an implicit deny: if nothing allows the action, it fails. Then AWS gathers every policy that applies, meaning identity policies, resource policies like a bucket policy, organization service and resource control policies, permission boundaries and session policies. If any of them has an explicit deny that matches, the answer is deny, full stop, whatever else says allow. The organization policies, boundaries and session policies act as ceilings: they don't grant anything, but the action has to be inside them. Then there must be an allow from an identity or resource policy. Across accounts it's stricter: the caller's own policy and the resource policy on the other side must both allow it. So when I debug an access denied, I check for a deny first, then the ceilings, then whether an allow exists at all."

"The trap here is that S3 actions work at two levels. Listing is an action on the bucket itself, so s3:ListBucket goes on the bucket ARN, and I restrict it with a condition so the caller can only list keys starting with the reports folder. Reading is an action on objects, so s3:GetObject goes on the object ARN with the folder prefix and a wildcard after it. If I put GetObject on the bucket ARN, or ListBucket on the object path, the policy looks right but doesn't work. I keep the actions explicit, no s3 star, and no other buckets. If the objects were encrypted with a customer-managed KMS key, I'd also need kms:Decrypt on that key, which people often forget."

"I'd assume it's already been found, because automated scanners pick up public keys within minutes. So step one is deactivating the key right away, even if something in production uses it. A short outage is better than an attacker with our credentials. Then I'd investigate with CloudTrail, searching every region for calls made with that access key ID, because attackers often launch instances in regions we never use. I'd look for new IAM users, keys or roles they may have created to keep access, and remove them, along with any instances or other resources they started. If the key could read secrets or data, I'd treat those as exposed and rotate them. Deleting the commit isn't enough, since it's already been copied. Afterwards the app gets a role instead of a key, and we add secret scanning so this can't reach a repository again."

"There's no public checkbox on a subnet. What makes it public is its route table: if it has a route for all internet traffic, 0.0.0.0/0, pointing at an internet gateway, it's public. An instance in it also needs a public or Elastic IP to be reachable. A private subnet has no route to the internet gateway, so nothing on the internet can start a connection to it. If the instances there need to download updates, their route table sends outbound traffic to a NAT gateway sitting in a public subnet. The usual layout is a public and a private subnet in each Availability Zone: the load balancer lives in the public ones, and the app servers and databases live in the private ones, reachable only from the load balancer and each other."

"A security group sits on the network interface of an instance, a load balancer or a database. It's stateful, so if I allow inbound traffic on port 443, the reply goes back out automatically. It only has allow rules, and a nice feature is that a rule can point at another security group, like the database accepting traffic only from the app servers' group. A network ACL sits at the subnet boundary. It's stateless, so I have to allow the return traffic myself, which usually means opening the ephemeral port range outbound, and that's where people break things. It has both allow and deny rules, evaluated in order by rule number, first match wins. In practice I do almost all my filtering with security groups and use NACLs rarely, for a blunt subnet-wide rule like blocking a known bad range."

"Servers in a private subnet still need to reach out now and then, for package updates or a third-party API. A NAT gateway sits in a public subnet and lets them start outbound connections, while nothing from the internet can start a connection back in. A standard NAT gateway lives in one zone, so it's a single point of failure for the others. For production I put one in each Availability Zone with each private route table pointing at its own zone's gateway, or I use the newer regional NAT gateway, which spreads across zones by itself. When the traffic is to AWS services themselves, I'd rather use VPC endpoints. A gateway endpoint for S3 or DynamoDB is just a route table entry and costs nothing extra, and interface endpoints cover services like Secrets Manager. That keeps the traffic off the internet path and cuts NAT data charges."

"I'd say no to the public subnet, but not stop there, because the vendor's need is real. Putting the database in a public subnet exposes it to constant scanning and password guessing, and one weak setting means our customer data is out. Then I'd ask what they actually need. If they need a live connection, a site-to-site VPN or PrivateLink keeps traffic private, and they'd connect to a read replica, never the primary, so their queries can't slow down production. If they only need certain data, an export to a bucket they can read, or a small API, is even safer. Either way they get a read-only database user limited to the tables they need, access is logged, and it has an end date. If time is short, I'd propose the smallest safe version first rather than the quick unsafe one."

"An Application Load Balancer works at layer 7, so it reads the HTTP request. That lets me route by path or host name, like sending /api to one target group and /images to another, send redirects, terminate TLS with a certificate from Certificate Manager, and put a web application firewall in front. It's my default for websites and HTTP APIs. A Network Load Balancer works at layer 4, so it just forwards TCP or UDP connections without looking inside. I'd pick it for non-HTTP protocols, for extreme throughput with very low latency, when a client needs a fixed IP address per zone to put on an allow list, or when the backend has to see the client's original IP. Both do health checks and spread traffic across Availability Zones, so the choice is really about which layer you need to work at."

"An Auto Scaling group keeps a fleet of identical instances built from a launch template, between a minimum and a maximum, spread across subnets in several Availability Zones. It does two jobs. One is healing: if an instance fails its health check, it's terminated and replaced, and I use the load balancer's health check so an instance that's running but serving errors gets replaced too. The other is elasticity. My default policy is target tracking, where I pick a metric and a target, like average CPU around the middle or a number of requests per instance, and it adds or removes instances to hold it. Scheduled scaling helps when I know the pattern, like a daily morning peak. I also set a warm-up time so a new instance isn't counted before it's ready, and make sure the app is stateless, because any instance can disappear on scale-in."

"A region has several Availability Zones, each made of one or more separate data centres, so the goal is that no piece lives in only one. At the front, an Application Load Balancer enabled in at least two zones, with CloudFront for static files. Behind it, stateless app servers in an Auto Scaling group spread across those zones, sized so the remaining zones can carry the full load if one disappears. That headroom is what people forget. State moves out of the servers: sessions in ElastiCache or DynamoDB, uploads in S3, and the database on RDS Multi-AZ so a standby in another zone takes over automatically. Then I hunt hidden single points, like one NAT gateway, one cron server or one bastion host, and fix each. Finally I'd test it by taking a zone's instances out of service in staging and watching what breaks."

"RDS gives me a managed relational database, like PostgreSQL or MySQL, where AWS handles backups, patching and failover. I'd pick it when the data is relational, I need joins and transactions across tables, and I expect to ask new questions of the data later, like a billing system or an admin dashboard. DynamoDB is a serverless key-value and document store. It gives steady, fast responses at almost any scale with no servers to size, which suits things like user sessions, carts or event data with huge traffic. The catch is I have to design the table around my access patterns up front, because querying by something that isn't a key is awkward or expensive. So my first question is: do I know exactly how I'll read this data? If yes and scale matters, DynamoDB. If the queries will keep changing, RDS."

"Multi-AZ is about availability. RDS keeps a standby copy in another Availability Zone and writes to it synchronously, so no committed data is lost. If the primary fails, or during some maintenance, RDS fails over to the standby and the endpoint name stays the same, so the app just reconnects. In the classic Multi-AZ setup, the standby doesn't serve any traffic. The newer Multi-AZ cluster option does have readable standbys, but that's a different deployment. A read replica is about scale. It's an asynchronous copy that I can point read-heavy work at, like reports or search pages, and it can even live in another region. Because it's asynchronous it can lag behind, so I wouldn't read from it right after a write that the user expects to see. And it doesn't fail over by itself; I'd have to promote it. For production I usually want Multi-AZ for safety and replicas only if reads are the bottleneck."

"I start from the queries, not the entities. DynamoDB hashes the partition key to decide where an item lives, and each partition has a throughput limit, so I want a key with many distinct values that traffic hits evenly, like a user ID or an order ID. The sort key then lets me fetch ranges inside one partition, like all orders for a customer newest first. A hot partition happens when one key gets far more traffic than the rest, like a date as the key where every write lands on today. Adaptive capacity helps a bit, but the real fix is design: spread writes by adding a random or calculated suffix to the key and reading across the suffixes, or put a cache in front of heavy reads. For a second access pattern, like finding orders by status, I'd add a global secondary index with its own keys."

"The first hard limit is time: a standard function invocation can run for at most 15 minutes. Memory goes up to about 10 GB, and CPU is allocated in proportion, so raising memory is also how you get more CPU. Concurrency is capped by a regional quota that all functions in the account share, so one runaway function can starve the others unless I set reserved concurrency. Then there are the practical limits. A new execution environment has a cold start, which adds latency, especially for heavy runtimes. Nothing survives between runs except by luck, so state goes to S3 or a database. And thousands of concurrent functions can flood a relational database with connections, which is what RDS Proxy is for. So Lambda is wrong for jobs longer than 15 minutes, for steady, heavy traffic that's cheaper on containers, or for anything holding a long-lived connection."

"The S3 event can carry more than one record, so I loop over Records and pull out the bucket name and the key. The trap is that the key arrives URL-encoded, so a file called my report.csv shows up with a plus sign instead of the space, and I have to decode it or the GetObject call fails. I create the S3 client outside the handler, so a warm environment reuses it. Two more things matter in production. First, I never write the output back into the same bucket and prefix that triggers the function, or it triggers itself in a loop. Second, delivery is at least once, so the same event can arrive twice, and processing should be safe to repeat. If a record keeps failing, I'd send it to a dead-letter queue rather than lose it."

"CloudWatch has three parts I'd use together. Metrics: EC2 sends CPU, network and status checks on its own, but not memory or disk usage, because AWS can't see inside the operating system. For those I install the CloudWatch agent, which can also ship log files. Logs: the app's logs go to CloudWatch Logs, and Logs Insights lets me query them when something breaks. Alarms: I'd alarm on what users feel first, like the load balancer's 5xx errors and response time, then on causes like high CPU, a full disk or a failed status check. Alarms send to an SNS topic that pages the on-call person or posts to the team chat, and some can trigger actions like scaling or recovering an instance. A small dashboard with those same numbers helps anyone see health at a glance."

"CloudFormation is AWS's infrastructure as code. I describe resources in a YAML template, and CloudFormation creates them as a stack, working out the order from the dependencies. Because the template lives in version control, changes get reviewed like application code, and I can build the same environment again for staging. For production, I never apply a change blind. I create a change set, which shows every resource that will be added, modified or deleted, and most importantly anything that will be replaced, because a replaced database or bucket can mean lost data. On stateful resources I set both the deletion policy and the update-replace policy to Retain, so neither deleting nor replacing throws the data away, and I turn on termination protection for the stack. If an update fails halfway, CloudFormation rolls back to the last working state. And I run drift detection now and then to catch anyone changing things by hand in the console."

"I'd keep it serverless because the load is bursty. The client asks an API, API Gateway plus a small Lambda, for an upload URL. That checks the user and returns a presigned PUT for a key it chooses in an uploads bucket. When the file lands, S3 sends an event into an SQS queue, and a Lambda reads from the queue, makes the thumbnail and the medium size, and writes them to a separate output bucket, so it can never trigger itself. The queue gives me retries and a dead-letter queue for images that keep failing. Photo records, like owner, status and sizes, go in DynamoDB keyed by user so the app can list a user's photos fast. Output is served through CloudFront with the bucket kept private. Lifecycle rules clear abandoned uploads, alarms watch the dead-letter queue, and the whole thing is defined in CloudFormation."

"I'd open Cost Explorer with daily granularity and group by service to see what jumped, then drill into region and usage type. That usually points straight at something. A service in a region we don't use, especially lots of big instances, makes me think of a compromised account first, so I'd check CloudTrail straight away. Other common causes I'd look for: a Lambda function triggering itself in a loop, an Auto Scaling group stuck at its maximum, a NAT gateway suddenly carrying heavy traffic because something started pulling data from S3 over the internet path, or debug logging left on and flooding CloudWatch Logs. Tags tell me which team owns it, so I can fix it with them rather than guess. Afterwards I'd set up AWS Budgets alerts and Cost Anomaly Detection, so next time we hear about it in hours, not at the end of the month."

"At my last company our API started timing out every evening for about twenty minutes. CloudWatch showed the app servers' CPU was fine, but the load balancer's response time spiked at the same moment every day. I pulled the logs for that window in Logs Insights and saw the slow requests were all waiting on database connections. The RDS metrics showed connections hitting the limit exactly when a nightly report job started, because the job opened a fresh connection per row. As a quick fix we moved the job to a read replica, which cleared the timeouts the same day. The real fix was rewriting the job to use a small connection pool. I also added an alarm on database connections so we'd see it coming, and wrote a short note in our runbook. The lesson I took was to line up metrics from each layer on one timeline."

"When I joined my last team, the main application ran with an IAM user whose access keys were years old and had full admin rights. Several services and a couple of scripts shared those keys, and nobody was sure which. Revoking them in one go would have taken production down. So I first looked at CloudTrail to see which actions and resources those keys actually used over the past few months, and IAM Access Advisor to see which services were touched. That gave me a real list. I created a separate role for each service with only what it used, moved the services one at a time to their roles, and watched for access denied errors after each move. Once CloudTrail showed no calls on the old keys for two weeks, I deactivated them, waited a bit more, then deleted them. We also added a rule to flag any new long-lived keys."

"At my last company the team had a staging environment someone had clicked together in the console two years earlier. When we needed a second copy for a new client, nobody could remember every setting, and the first attempt was missing a security group rule that took a day to find. I offered to put it into CloudFormation. I listed every resource by hand, wrote the template, and then used resource import so the stack adopted the existing VPC, instances and database instead of rebuilding them. Before calling it done, I ran drift detection and a change set to confirm the template matched reality with nothing to change. After that, building the new client's environment took an afternoon from the same template with different parameters. We also agreed that any change goes through the template, and drift detection runs weekly to catch anyone who forgets."