AWS EC2 Interview Questions
Reviewed by Mark Dickie · Last updated
5 questions on this page you can answer and see marked on the spot. Go to the first one
Amazon EC2 (Elastic Compute Cloud) is a web service that provides resizable virtual machines—called instances—running in AWS data centers. For an EC2-focused interview, you need to know instance families and their pricing models, how VPC networking attaches to instances via ENIs, EBS volume types and their performance characteristics, IAM roles versus key pairs for access, and how Auto Scaling groups interact with Elastic Load Balancers.
Most EC2 questions fall into a handful of buckets. The table below maps the common areas to what interviewers probe:
| Topic area | What gets tested |
|---|---|
| Instance types & pricing | On-Demand vs Reserved vs Spot vs Savings Plans; right-sizing to a workload |
| Storage | EBS volume types (gp3, io2, st1, sc1); instance store vs EBS; Snapshots and AMIs |
| Networking | ENI, private vs public IPs, security groups vs NACLs, placement groups |
| Security | IAM roles attached to instances, key pairs, IMDSv2, encryption at rest |
| Scaling & availability | Auto Scaling policies, ELB target groups, multi-AZ deployment, launch templates |
What instance pricing models should I know for an EC2 interview?
Interviewers expect you to compare the four main purchasing options and pick the right one for a given workload. The key distinctions:
- On-Demand — pay per second with no commitment; good for short-term, unpredictable workloads or development.
- Reserved Instances / Savings Plans — commit to 1 or 3 years for a large discount (up to 72%); suited for steady-state production.
- Spot — bid on spare capacity at up to 90% discount; instances can be interrupted with two minutes' notice, so use them for batch or fault-tolerant jobs.
- Dedicated Hosts — physical servers reserved for your use; needed when software licensing is tied to cores, sockets, or VM affinity.
How do security groups and NACLs differ at the EC2 level?
Security groups are stateful, attached to ENIs, and evaluate all rules before deciding to allow traffic—there is no explicit deny. Network ACLs are stateless, operate at the subnet boundary, and support both allow and deny rules processed in numbered order. A common interview follow-up asks you to troubleshoot why an instance cannot be reached on a port: check the security group inbound rules first, then the subnet NACL, then the route table.
The quiz below pulls from these areas. Work through it to find gaps before your interview.
Key facts
- Tarmac has 15 AWS interview questions on this topic, 10 of them on this page, at difficulty 1–5 of 5.
- Tarmac tracked 5,372 job postings asking for AWS in September 2026.
- Roles asking for AWS advertise a median base salary of US$173,425, across 1,898 job postings as of September 2026.
- Tarmac last reviewed these AWS interview questions on 24 August 2026.
At a glance
| Questions | 10 shown · 15 in the bank |
|---|---|
| Difficulty | 1–5 of 5 |
| Formats | Multiple answer, Design exercise, Fill in the blank, Multiple choice, True / false, Short answer, Flashcard, Ordering |
What you'll review
- ec2
Practice questions
Try one before you open the answer. Pick an option and press Check; it's marked on the spot.
Which statements about Amazon EC2 security groups are correct? Select all that apply.#
Options
Pick every one that applies.
Show answer
Amazon EC2 security groups are stateful, so return traffic for an allowed inbound connection is automatically permitted. A single security group can also be attached to multiple EC2 instances within the same VPC. They support only allow rules; explicit deny rules belong to network ACLs.
Security groups are stateful: when an inbound connection is allowed, the response traffic is tracked and allowed back out automatically, so no matching outbound rule is needed for that reply. A single security group can also be associated with many instances, in the same VPC. Security groups support only allow rules, so explicit deny of a specific IP is not possible; that is a network ACL capability. Security groups are applied at the instance's network interface, not at the subnet boundary as stateless filters, which describes network ACLs.
A small startup wants to host a simple web application on a single EC2 instance in AWS. The app serves a few hundred users per day, must be reachable from the public internet over HTTPS, and the team has no on-premises infrastructure. Design the EC2-based setup: which instance family and size you would choose and why, how you would configure networking so the instance is internet-accessible, how you would secure it, and what storage the instance would use. Cover each of these areas concretely.#
Show answer
I would launch a single t3.micro (or t3.small) EC2 instance in the us-east-1 region. The t3 family is burstable and cost-effective, which suits a workload with only a few hundred daily users and intermittent traffic spikes — the accumulated CPU credits cover short bursts without paying for sustained high performance.
For networking, I would create a VPC (or use the default VPC) with at least one public subnet in an Availability Zone. I would attach an Internet Gateway to the VPC and ensure the public subnet's route table has a default route (0.0.0.0/0) pointing to that IGW. The EC2 instance would be launched into the public subnet with a public IPv4 address (auto-assigned or via an Elastic IP) so it is reachable from the internet.
For security, I would attach a Security Group to the instance allowing inbound TCP 443 (HTTPS) from 0.0.0.0/0 so users can reach the app securely, and inbound TCP 22 (SSH) restricted to the team's office or VPN CIDR for administration. All other inbound traffic would be denied by default. I would also place a Network ACL on the subnet as a stateless secondary layer, though the Security Group is the primary control.
For storage, the instance would use an EBS-backed root volume — a gp3 general-purpose SSD of around 8–30 GB — to hold the operating system, application code, and any local data. EBS volumes persist independently of the instance lifecycle, so data survives a stop/start. I would also enable EBS snapshots for basic backup.
This design exercise tests foundational EC2 knowledge at a junior level: selecting an appropriate burstable instance family for a low-traffic workload, configuring VPC networking with a public subnet and Internet Gateway for internet accessibility, applying Security Group rules to restrict inbound traffic, and identifying EBS as the storage layer. The rubric awards points for each concrete design element, and the sample answer covers all four criteria.
An EC2 instance's public IPv4 address is released when the instance is stopped, so it changes on the next start. To keep a fixed public IPv4 address that survives stop and start cycles, associate an _____ with the instance.#
Show answer
An EC2 instance's public IPv4 address is released when the instance is stopped, so it changes on the next start. To keep a fixed public IPv4 address that survives stop and start cycles, associate an Elastic IP with the instance.
By default, an EC2 instance receives a public IPv4 address from the AWS pool, and that address is released when the instance stops, so a restarted instance gets a different one. An Elastic IP address is a static public IPv4 address that you allocate to your account and associate with an instance, and it stays yours across stop and start cycles until you release it. The blank therefore takes the name of that static address resource.
You stop a general-purpose EC2 instance that has an attached EBS-backed root volume. While the instance remains in the stopped state, which billing statement is correct?#
Options
Show answer
When an EC2 instance is stopped, you are no longer billed for instance compute hours, but you continue to be billed for any attached EBS volume storage. The EBS volume persists independently of the instance and accrues charges until it is explicitly deleted.
When an EC2 instance is stopped, AWS releases the underlying host capacity, so you stop paying for compute (the instance type's per-hour/per-second charge). However, the EBS volume's storage persists independently and continues to accrue charges at the normal GB-month rate until the volume is deleted. Therefore the statement that you are not billed for the instance's compute hours but continue to be billed for the attached EBS volume is correct and the other options either over-bill (billing for both compute and storage, or billing for compute but not storage) or under-bill (billing for nothing) what you are actually charged for.
True or false: For an EBS-backed EC2 instance with no Elastic IP address attached, stopping the instance and then starting it again keeps the same public IPv4 address.#
Options
Show answer
An EBS-backed EC2 instance does not keep its auto-assigned public IPv4 address when it is stopped and then started. Stopping releases that address and starting assigns a new one, while the private IP stays the same. A reboot keeps the public address, and an attached Elastic IP gives a fixed public address across stops.
The statement is false. An auto-assigned public IPv4 address is released when an EBS-backed instance is stopped, and the instance receives a new public IPv4 address when it is started. The private IPv4 address stays the same across a stop and start. A reboot, by contrast, keeps the public address. An Elastic IP address is the way to keep a fixed public IPv4 address across stops and starts.
A batch-processing team wants the lowest possible EC2 compute price and can tolerate their instances being reclaimed by AWS when capacity is needed elsewhere. Which EC2 purchasing option fits this requirement?#
Show answer
Spot Instances use spare EC2 capacity at a steep discount compared with On-Demand pricing. The trade-off is that AWS can reclaim a Spot Instance with a two-minute interruption notice when it needs the capacity back, which the batch team has said it can tolerate. On-Demand Instances have no interruption but offer no discount. Standard Reserved Instances lower the price through a 1- or 3-year commitment but do not allow AWS to reclaim the instance. Dedicated Hosts provide physical server isolation at a premium over shared On-Demand pricing and are not a discount option.
Spot Instances use spare EC2 capacity at a steep discount compared with On-Demand pricing, offering the lowest price among the listed options. The trade-off is that AWS can reclaim a Spot Instance with a two-minute interruption notice when it needs the capacity back, which the batch team has said it can tolerate. On-Demand Instances have no interruption but offer no discount. Standard Reserved Instances lower the price through a 1- or 3-year commitment but do not allow AWS to reclaim the instance. Dedicated Hosts provide physical server isolation at a premium over shared On-Demand pricing and are not a discount option.
When Amazon EC2 needs to reclaim a running Spot Instance because capacity is constrained, which of the following correctly describes the interruption process?#
Options
Show answer
When Amazon EC2 reclaims a Spot Instance, it issues a two-minute interruption warning via Amazon EventBridge and the instance metadata service (spot/instance-action), then stops, hibernates, or terminates the instance according to the configured interruption behavior. The warning is automatic, the interruption behavior is configurable, and no manual request cancellation is needed before reclamation.
When EC2 reclaims a Spot Instance, it provides a two-minute interruption notice. The notice is delivered through Amazon EventBridge (the EC2 Spot Instance Interruption Warning event) and is also available in the instance metadata at spot/instance-action, which returns the action (stop, terminate, or hibernate) and the exact time the action will occur. The claim that the instance is terminated immediately with no warning is wrong because a warning is always given. The claim that the instance is always terminated—never stopped or hibernated—is wrong because you can configure the Spot Instance interruption behavior to stop or hibernate instead of terminate (for persistent Spot requests or applicable launch configurations). The claim that you must manually cancel the Spot Instance request before EC2 can reclaim the instance is wrong because reclamation is automatic; manual cancellation is not required for EC2 to reclaim capacity.
An application stores temporary cache files on the instance store volume of an Amazon EC2 instance (not on an EBS volume). Explain what happens to those cache files in two cases: first, when the instance is rebooted; second, when the instance is stopped and later started again. Then state one design implication for storing data on instance store.#
Show answer
Rebooting the instance keeps the instance store data, because a reboot does not move the instance to new hardware. Stopping the instance erases the instance store data, and it is not recoverable after a later start, because the instance store is ephemeral and tied to the physical host. Design implication: only put data on instance store that can be regenerated or is replicated elsewhere (for example, cache or scratch data), and keep durable state on EBS, EFS, or S3.
Instance store is ephemeral storage physically attached to the host. A reboot is an OS restart on the same host, so the data survives. Stopping the instance (or hibernating, terminating it, or a underlying hardware failure) releases the host, and the instance store contents are erased; starting the instance again does not restore them. Therefore the correct design is to use instance store only for disposable or replicated data and to keep durable data on EBS, EFS, or S3.
For an EC2 instance store (ephemeral) volume, which lifecycle actions cause the data on the volume to be lost, and which action preserves it?#
Show answer
Data is lost when the instance is stopped, hibernated, or terminated, or when the underlying host fails. Rebooting the instance preserves the data.
Instance store volumes are physically attached to the host, so their contents survive only a reboot. Stop and hibernate move the instance off its host (and hibernate also saves RAM state to the EBS root volume, not the instance store), terminate deletes the instance, and a host failure ends the physical storage. This is why instance store data must be treated as a cache or replicated copy, not durable state.
You need to change the instance type of a running, EBS-backed Amazon EC2 instance in a single region, keeping its root EBS volume. Put the following steps in the correct order, from first to last.#
Put these in order
Show answer
To change the instance type of an EBS-backed EC2 instance, first stop the instance and wait for the stopped state. Then modify the instance type attribute, start the instance, and wait for the running state. The type can only be changed while the instance is stopped, so this order is required.
An instance's type can only be changed while the instance is in the stopped state, so the stop request must be issued first and the caller must wait for the stopped state to be reached before the type change is accepted. Only after the new type is set can the instance be started, and the start is complete only when the running state is reached. Each adjacent pair here has a strict precedence imposed by the EC2 state machine: stop request before stopped state, stopped state before the attribute change, attribute change before start, and start before running.
Related interview questions
Job market
See aws salaries and hiring demand from live job postings.
The other 5 questions
This page shows 10 and marks what you pick. That's as far as a page can go. A free account opens the other 5 and keeps every answer. What you miss comes back until it's right: after a day, then at longer gaps.
Free · the whole bank · 100 marked answers per 30 days · written feedback on the paid plan