AWS Interview Questions for AI Training Work

An IAM user represents a person or application with long-lived credentials, while a role is an identity that other trusted entities, like an EC2 instance or a Lambda function, can assume temporarily to get short-lived credentials. Services running on AWS infrastructure should use roles rather than embedding a user's access keys, since role credentials rotate automatically and are never stored on disk where they could leak.

Standard is for frequently accessed data and has the highest storage cost but no retrieval fee or delay. Infrequent Access lowers storage cost in exchange for a per-retrieval fee, suited to backups accessed occasionally. Glacier trades much lower storage cost for retrieval times ranging from minutes to hours, making it appropriate for archival data that's rarely if ever read back, like compliance records.

A security group is stateful and attached to individual resources like EC2 instances, so if inbound traffic is allowed, the corresponding outbound response is automatically allowed too. A network ACL is stateless and applies at the subnet level, evaluating inbound and outbound rules independently, which means you have to explicitly allow both directions of traffic even for a simple request-response pattern.

An Auto Scaling group uses scaling policies tied to CloudWatch metrics, commonly CPU utilization or request count, and adjusts the desired instance count when a metric crosses a defined threshold for a sustained period. Target tracking policies simplify this by letting you specify a target value, like 60% average CPU, and AWS calculates the scaling adjustments automatically instead of requiring manually tuned step policies.

RDS is a managed relational database, appropriate when data has complex relationships, needs multi-table transactions, or benefits from SQL's flexible querying. DynamoDB is a managed NoSQL key-value store built for predictable low-latency access at scale, but it requires designing access patterns upfront since it doesn't support arbitrary joins. I'd pick DynamoDB when access patterns are known and simple and scale is a priority, RDS when the data model itself is genuinely relational.

I'd first check whether the account-level or function-level concurrency limit is actually the bottleneck via CloudWatch metrics, then request a limit increase if the workload legitimately needs it. I'd also look at whether reserved concurrency on a less critical function is starving a more important one, and consider provisioned concurrency for latency-sensitive functions so they don't wait on cold starts during a spike.

I'd start with Cost Explorer to find where spend is actually concentrated rather than guessing, since it's often a small number of services driving most of the cost. Common wins are rightsizing over-provisioned EC2 instances based on actual CloudWatch utilization, moving steady-state workloads to Reserved Instances or Savings Plans, and cleaning up unattached EBS volumes or old snapshots, none of which touch production reliability directly.

I'd deploy across at least two, ideally three, Availability Zones within the region, with an Auto Scaling group spanning all of them behind a load balancer that health-checks each instance. For stateful components, RDS Multi-AZ handles automatic failover for the database, and S3 is already regionally redundant by default, so the main design work is making sure the compute and any in-memory state don't assume a single AZ.

A NAT Gateway was silently costing far more than expected because a service was routing a large volume of S3 traffic through it instead of using a VPC endpoint. It worked fine functionally, so nobody noticed until the bill flagged it. Adding a VPC endpoint for S3 cut that cost close to zero, and it changed how I evaluate new services now, checking the network path cost upfront rather than only after the bill arrives.

A team wanted broad admin permissions on a shared AWS account to unblock a deadline. Instead of granting that outright, I set up a scoped IAM role with exactly the permissions their task needed, which took about an hour longer to configure but avoided leaving a wide-open credential in the account afterward. Framing it as a small time cost now versus a much larger incident-response cost later made the tradeoff easy to agree on.