AWS Engineer interview questions and answers

On-Demand is pay as you go, billed per second for Linux, with no commitment: right for new or unpredictable workloads and short tests. Savings Plans and Reserved Instances give a large discount in exchange for committing to a level of use for one or three years: right for the steady baseline that runs all the time, like production web servers or databases. Spot uses AWS's spare capacity at a much bigger discount, but AWS can take it back with a two-minute warning: right for work that can be interrupted, such as batch jobs, CI runners and stateless workers.

A good answer combines them: Savings Plans for the baseline, On-Demand for normal peaks, Spot for interruptible extra capacity.

They solve different problems. Multi-AZ is for availability: RDS keeps a standby copy in another availability zone, updated synchronously. If the primary or its zone fails, RDS fails over automatically, usually within a couple of minutes, and the same endpoint now points to the standby. In the classic Multi-AZ setup the standby can't serve reads. (A Multi-AZ DB cluster has two standbys that can serve reads.)

A read replica is for read scaling: it is updated asynchronously, so it can lag a little behind, and the application sends read-only queries such as reports to its own endpoint. Replicas can be in another region and can be promoted by hand. For production you often use both: Multi-AZ for failover, replicas for heavy reads.

Remove every single point of failure. Make the server replaceable: build an AMI or launch template and run the app in an Auto Scaling group across two or three zones, with at least two instances, behind an Application Load Balancer with health checks. For that to work the instances must be stateless: move user sessions to ElastiCache or DynamoDB, uploaded files to S3, and the database off the instance to RDS with Multi-AZ.

Then point the domain at the load balancer with a Route 53 alias record, serve static files through CloudFront, and add CloudWatch alarms and automated backups. Mention that you'd move in steps, database first, and test by terminating an instance on purpose to check traffic keeps flowing.

Reactive scaling waits for metrics to rise, then new instances take minutes to boot and warm up, so a sudden spike arrives before the capacity does. For a known event, use scheduled scaling to raise the minimum and desired count before the sale starts. Speed up launches by baking the application into the AMI instead of installing it in user data, and consider a warm pool of pre-initialised instances. Scale on request count per target rather than CPU, since it rises earlier.

Also check the limits outside the group: your account's EC2 service quotas, the database (add caching or read replicas), and any part that should queue work, such as orders through SQS. Load test at sale traffic a week before.

A security group is a firewall on an instance's network interface. It is stateful: if inbound traffic is allowed, the reply goes out automatically. It has only allow rules, all rules are evaluated together, and a rule can name another security group as the source, such as "allow 3306 only from the app servers' group".

A network ACL works at the subnet level and is stateless, so you must allow the return traffic yourself, usually the ephemeral ports 1024 to 65535. It has both allow and deny rules, checked in order of rule number, lowest first, and the first match wins. The default NACL allows everything. In practice security groups do most of the work, and NACLs are used for broad subnet rules, like blocking a known bad IP range.

A /16 gives 65,536 addresses, so there's room to be generous. A common plan is three tiers in each of the three zones: public subnets for load balancers and NAT gateways (10.0.0.0/24, 10.0.1.0/24, 10.0.2.0/24), private application subnets (10.0.10.0/24 to 10.0.12.0/24), and private database subnets (10.0.20.0/24 to 10.0.22.0/24), leaving space for growth.

A /24 has 256 addresses, but AWS reserves five in every subnet: the network address, .1 for the VPC router, .2 for DNS, .3 for future use, and the last address. That leaves 251. Mention that on EKS each pod takes a VPC IP, so application subnets there are often much larger, such as /19.

Follow the packet's path. The private subnet's route table needs 0.0.0.0/0 pointing to a NAT gateway. That NAT gateway must sit in a public subnet whose own route table sends 0.0.0.0/0 to the internet gateway, and it must be in the available state with an Elastic IP. Then the instance's security group must allow outbound HTTPS, which the default does, and the network ACLs of both subnets must allow outbound 443 and the inbound ephemeral ports for replies.

Check DNS too: from the instance, dig the repository's hostname, then curl -I to it. VPC Reachability Analyzer can test the path for you. If the instance only needs S3, add a gateway endpoint instead; it has no charge and keeps the traffic off the NAT gateway.

Simple returns one record; weighted splits traffic by percentages, useful for gradual releases; latency-based sends users to the region with the lowest latency for them; failover has a primary and a secondary record; geolocation answers by the user's country or continent; and there are also geoproximity, IP-based and multivalue answer policies.

For failover, create a health check on the primary, such as the main region's load balancer or a /health URL, and two failover records for the same name: primary pointing to the main region, secondary to the backup region or a static S3 maintenance page. When the health check fails, Route 53 answers with the secondary. Use alias records for AWS targets; they work at the domain's root, and queries to them are free.

Use an IAM role. Create a role that EC2 can assume, attach a policy allowing only the actions it needs, like s3:GetObject and s3:PutObject on arn:aws:s3:::my-bucket/*, and attach the role to the instance through an instance profile. The AWS SDK and CLI then pick up temporary credentials automatically from the instance metadata service, and AWS rotates them for you.

Access keys in code end up in Git, in logs and on developers' laptops, they never expire unless someone rotates them, and a leaked key works from anywhere. Mention requiring IMDSv2 on the instance, which uses a session token and protects the metadata credentials against server-side request forgery attacks.

Two statements, because buckets and objects have different ARNs. One allows s3:ListBucket on arn:aws:s3:::reports-bucket, the bucket itself. The other allows s3:GetObject on arn:aws:s3:::reports-bucket/*, the objects inside. Putting both actions on one ARN is a common mistake that makes listing or downloading fail.

For the decision, everything starts as an implicit deny. A request is allowed only if some applicable policy explicitly allows it, and an explicit deny in any policy always wins over any allow. The policies involved can include identity policies, the bucket policy, permission boundaries and, in an organisation, service control policies. Interviewers often follow up by asking what you'd do to block deletes even for admins: an explicit deny.

KMS keys never leave KMS. It uses envelope encryption: KMS generates a data key, the data is encrypted with that data key, and the data key itself is stored encrypted under the KMS key, next to the data. To read it, the service asks KMS to decrypt the data key.

With SSE-S3, S3 manages the keys entirely, and since 2023 it applies to every new object by default. With SSE-KMS, the key is in KMS, so you control who can use it through the key policy, can disable it, and every use is logged in CloudTrail; KMS requests cost money, which S3 Bucket Keys reduce. A common troubleshooting point: reading an SSE-KMS object needs both s3:GetObject and kms:Decrypt on the key.

Ansible is a configuration management and automation tool. It is agentless: a control node connects to servers over SSH (WinRM for Windows) and runs tasks from YAML playbooks, using modules such as apt, copy, template and service. Nothing needs to be installed on the servers except Python. It's push-based: you run a playbook and it applies the changes in order.

Terraform is for provisioning infrastructure: VPCs, instances, databases. It is declarative and keeps a state file of what it created. Ansible is best at what happens inside the servers: installing packages, writing configuration files, deploying the application and restarting services. A common setup uses Terraform to create EC2 instances and Ansible to configure them. Mention roles: reusable folders of tasks, templates and handlers.

The inventory lists the hosts Ansible manages and groups them, such as web and db, with variables per host or group like the SSH user. A static inventory is an INI or YAML file, which works for a fixed set of servers.

With Auto Scaling, IPs change all the time, so use a dynamic inventory: the amazon.aws.aws_ec2 plugin. Create a file whose name ends in aws_ec2.yml, set plugin: amazon.aws.aws_ec2, the regions such as ap-south-1, filters such as tag:Environment: prod, and keyed_groups to create groups from tags, like a role_web group from a Role tag. ansible-inventory -i prod.aws_ec2.yml --graph shows the result. The control node needs an IAM role that can describe instances.

Idempotent means running a playbook again changes nothing if the server is already in the desired state. Modules describe a state, like state: present for a package, so the second run reports ok instead of changed. The shell and command modules just run commands and report changed every time, so prefer real modules, or add creates or changed_when. Use handlers so a service restarts only when its configuration file actually changed.

Drift is a server that no longer matches the code, usually after someone edited it by hand. Run ansible-playbook site.yml --check --diff on a schedule: it shows what would change without changing it. Re-running the playbook corrects drift; some teams avoid it altogether by baking AMIs and replacing servers instead of editing them.

Both run containers. ECS is AWS's own orchestrator: simpler to learn, with task definitions and services, deeply tied to AWS, and no charge for the control plane. EKS is managed Kubernetes: more complex, but you get the standard Kubernetes API, tools like Helm and its ecosystem, and skills and manifests that move to other clouds. It has an hourly fee per cluster.

Fargate is a way of running containers for either one without managing servers: you state the CPU and memory for each task or pod and pay for that while it runs, with no instances to patch or scale. The alternative is your own EC2 instances, which can be cheaper at steady high load and support things Fargate doesn't, such as GPUs.

S3 Standard is for frequently used data. Standard-IA and One Zone-IA cost less to store but charge per GB retrieved and bill at least 30 days; One Zone keeps data in a single zone. Intelligent-Tiering moves objects between tiers automatically for a small monitoring fee, which suits unknown access patterns. The Glacier classes are for archives: Instant Retrieval returns data in milliseconds, Flexible Retrieval in minutes to hours, and Deep Archive, the cheapest, within about 12 hours.

Lifecycle rules automate this. For application logs: move to Standard-IA after 30 days, to Glacier Flexible Retrieval after 90, and delete after a year. Also expire old versions in versioned buckets and abort incomplete multipart uploads, which quietly cost money.

Open Cost Explorer and compare this month with last, grouped by service, then by usage type, region, account and cost allocation tags; Cost Anomaly Detection may have flagged it already. The usual causes: NAT gateway data processing, often from pulling images or S3 data through it, which gateway endpoints fix; data transfer out; instances or volumes left running in another region; unattached EBS volumes and old snapshots; CloudWatch Logs filling up after someone left debug logging on; and oversized RDS instances.

Fix the cause, then prevent a repeat: AWS Budgets with alerts per team, a tagging policy so every resource has an owner, Compute Optimizer for rightsizing, and a Savings Plan once the steady baseline is clear.

$0 is the script's name, $1 to $9 are the arguments passed to it (${10} onwards need braces), $# is the number of arguments, "$@" is all the arguments as separate words (keep the quotes, so arguments with spaces stay intact), and $? is the exit status of the last command, 0 for success.

A function: check_file() { local f="$1"; if [ ! -f "$f" ]; then echo "missing: $f" >&2; return 1; fi; }. Call it like a command: check_file /etc/app.conf || exit 1. Inside a function, $1 means the function's own first argument. return sets only an exit status from 0 to 255; to return text, echo it and capture it with result=$(my_function).

grep searches for lines: grep -i "error" /var/log/app.log | grep -v healthcheck shows errors without the health-check noise, and grep -rn "db_host" /etc/myapp/ finds which config file sets a value, with line numbers.

sed edits text as a stream: sed -i.bak 's/^max_connections=.*/max_connections=200/' app.conf changes a setting in place and keeps a backup copy, which matters when you run it on many servers.

awk works with columns: awk -F: '{print $1}' /etc/passwd lists user names, and awk '{sum += $10} END {print sum}' access.log adds up the bytes sent in a web server log. Interviewers like it when you test a sed edit without -i first.

The key command:

ids=$(aws ec2 describe-instances --region ap-south-1 --filters "Name=tag:Environment,Values=dev" "Name=instance-state-name,Values=running" --query "Reservations[].Instances[].InstanceId" --output text)

Then if [ -n "$ids" ]; then aws ec2 stop-instances --region ap-south-1 --instance-ids $ids; fi, with $ids unquoted on purpose so each ID is a separate argument. Start the script with set -euo pipefail and log what it stopped.

Crontab: 0 21 * * 1-5 /opt/scripts/stop-dev.sh >> /var/log/stop-dev.log 2>&1. Watch the server's time zone; many EC2 images use UTC, where 9 pm IST is 15:30. Run it on an instance whose IAM role allows only describing and stopping instances. Mention that EventBridge Scheduler with Lambda does the same without a server.

Interviewers use this to judge whether you really built it, so be specific. Structure: the problem, the architecture, your part, one difficulty and the result. For example: "I built [project], a [what it does]. Users reach a CloudFront distribution and an Application Load Balancer; the app runs on [EC2 in an Auto Scaling group or ECS] in private subnets, with RDS MySQL in Multi-AZ and files in S3. I wrote it all in [Terraform or CloudFormation]. The hardest part was [problem, such as instances failing health checks], which I fixed by [fix]. It cost about [amount] a month, which I kept low by [choice]."

Expect follow-up questions on every service you name.

Show that you protect the client even when they ask for something risky, and that you offer a better way rather than just refusing. Structure: understand the need, explain the risk briefly, suggest a safe alternative, and record the decision. For example: "I'd ask what they need to do on the server. Opening port 22 to 0.0.0.0/0 invites constant attacks, so I'd offer Session Manager, which needs no open port, or allowing only their office IP. If they still insist, I'd ask my lead and get the decision in writing."

Avoid making it a conflict; most clients agree once they hear a quick, safe option.

Give a real reason for AWS, then show flexibility, since service companies move people between clouds. For example: "I started with AWS because it's the most widely used and has the most learning material, and I've built [project] on it. But the ideas carry over: networks, identity, compute, storage and infrastructure as code work the same way on Azure and Google Cloud, with different names. I'd be glad to learn another cloud for a project, and I'd start by mapping the services I know to theirs."

Avoid running down other clouds; your next client may use one of them.

Use STAR and show how you learn, not just that you did. For example: "In my internship, we needed to process uploaded files without running a server all day (situation). I had never used Lambda (task). I read the developer guide's getting-started section, built a small test that ran on an S3 upload event, then checked the limits that mattered for us: timeout, memory and package size (action). It went live within a week and replaced a server that ran around the clock (result)."

Mention the specific limit or gotcha you found; it shows you went beyond a tutorial.

Stay factual and helpful, never point fingers. Structure: collect evidence, explain calmly, and focus on preventing a repeat. For example: "I'd check the AWS Health Dashboard to confirm there was no AWS event, then look at CloudTrail and our monitoring for what changed. If a security group change at 10:42 caused it, I'd show the timeline and say: 'This change blocked the traffic; here is how we restored it and how we can stop it happening again,' perhaps with change approvals for production."

Keep the tone on solving the problem together; the client should leave trusting you more, not feeling blamed.