Amazon EC2 — Instances & Purchasing Options

By Pritesh Yadav 23 min read

Amazon EC2 gives you virtual servers (instances) that you can buy in several ways, and the exam loves to test which pricing model fits a given workload. On-Demand is flexible but priciest per hour; Reserved Instances and Savings Plans give big discounts for a 1- or 3-year commitment; Spot is up to ~90% off but can be taken back at any time. You also need to know how EC2 differs from Lambda and containers, what an AMI and user data do, and why instance store data disappears while EBS data persists.

Most confused here: Reserved Instances vs Savings Plans vs Spot vs Dedicated Hosts vs Dedicated Instances; On-Demand vs Spot interruption behavior; instance store (ephemeral) vs EBS (persistent); Auto Scaling (adds/removes instances) vs ELB (distributes traffic); EC2 vs Lambda vs Fargate.

Q1 A company runs a steady production database on EC2 that must stay on 24/7 for the next three years, and they want the lowest possible price while keeping the exact same instance type the whole time. Which purchasing option fits best?

  1. Spot Instances
  2. Standard Reserved Instances (3-year term)
  3. On-Demand Instances
  4. Convertible Reserved Instances (1-year term)
Answer: B
Why B is correct: Standard Reserved Instances give the largest discount when you commit for a long, fixed term, and a 3-year commitment is cheaper than 1-year. Because the workload never changes instance type, the "Standard" RI (which offers the deepest discount but less flexibility to change attributes) is the cheapest match.
Why the other options are wrong:
  • A — Spot can be reclaimed by AWS at any time, so it is unsuitable for an always-on production database.
  • C — On-Demand has no commitment and is the most expensive per hour for a steady, predictable workload.
  • D — Convertible RIs allow changing instance family but discount less than Standard, and a 1-year term saves less than 3-year.
Common trap: Picking Convertible because it sounds "better" — flexibility costs money, and the question says the type never changes, so Standard is cheaper.

Q2 A data-processing job can be paused and restarted at any time and saves its progress frequently to S3. The team wants the cheapest possible compute and can tolerate the servers being shut down by AWS with little notice. Which option is most appropriate?

  1. Dedicated Hosts
  2. On-Demand Instances
  3. Spot Instances
  4. Standard Reserved Instances
Answer: C
Why C is correct: Spot Instances use spare AWS capacity at up to ~90% off On-Demand, but AWS can reclaim them with only a short warning. A fault-tolerant, interruptible batch job that checkpoints its work is the textbook fit for Spot.
Why the other options are wrong:
  • A — Dedicated Hosts are the most expensive option, used for licensing or compliance needs, not cost savings.
  • B — On-Demand works but is far more expensive than Spot for an interruption-tolerant job.
  • D — Reserved Instances require a 1- or 3-year commitment, which is overkill for a flexible batch job and not the cheapest here.
Common trap: Confusing "can tolerate interruption" with needing a commitment — the keyword "can be paused/restarted" points straight to Spot, not Reserved.

Q3 A company wants a discount on compute in exchange for a 1- or 3-year commitment to a steady dollar-per-hour spend, but wants the freedom to move between instance families, sizes, and even between EC2, Fargate, and Lambda over time. Which option best matches?

  1. Compute Savings Plans
  2. Standard Reserved Instances
  3. Spot Instances
  4. Dedicated Instances
Answer: A
Why A is correct: Compute Savings Plans give RI-level discounts in return for committing to a steady spend (measured in $/hour), and they automatically apply across instance families, sizes, regions, and even Fargate and Lambda. That maximum flexibility is exactly what the scenario asks for.
Why the other options are wrong:
  • B — Standard RIs are locked to a specific instance attribute set and cannot apply to Fargate or Lambda.
  • C — Spot has no commitment and offers no Fargate/Lambda commitment discount; it can also be interrupted.
  • D — Dedicated Instances are about physical isolation of hardware, not a flexible commitment discount.
Common trap: Thinking only Reserved Instances give commitment discounts — Savings Plans cover Lambda/Fargate too, which RIs cannot.

Q4 A regulated bank must run certain EC2 workloads on physical servers fully dedicated to its account so it can meet a server-bound software license that is priced per physical socket and core. Which option satisfies this requirement?

  1. Dedicated Instances
  2. Reserved Instances
  3. Dedicated Hosts
  4. Spot Instances
Answer: C
Why C is correct: Dedicated Hosts give you a whole physical server allocated to your account and let you see and use the underlying sockets and cores. That visibility is what makes them the right choice for "bring your own license" software priced per physical core or socket.
Why the other options are wrong:
  • A — Dedicated Instances run on hardware isolated to your account but do not give you visibility or control of the physical socket/core layout needed for that license model.
  • B — Reserved Instances are a billing/pricing commitment, not a hardware-isolation feature.
  • D — Spot is shared spare capacity that can be reclaimed — the opposite of dedicated hardware.
Common trap: Mixing up Dedicated Hosts and Dedicated Instances — both isolate hardware, but only Dedicated Hosts expose the physical socket/core info that per-core licensing requires.

Q5 An EC2 instance uses an instance store (ephemeral) volume for temporary scratch data. The application owner is surprised to find the scratch data gone. Which action would cause the instance store data to be permanently lost?

  1. Rebooting the instance from the console
  2. Detaching and reattaching an Elastic IP
  3. Creating an AMI snapshot of the instance
  4. Stopping and then starting the instance
Answer: D
Why D is correct: Instance store volumes are physically attached to the host the instance runs on. When you stop and start an instance, it usually moves to a different host, so all instance store data is wiped. A simple reboot keeps it on the same host and preserves the data.
Why the other options are wrong:
  • A — A reboot does not move the instance to new hardware, so instance store data survives a reboot.
  • B — Changing an Elastic IP only affects networking, not the storage on the host.
  • C — Creating an AMI is a read operation that captures an image; it does not erase the live instance store.
Common trap: Treating "reboot" and "stop/start" as the same — reboot keeps the host (data safe), stop/start moves the host (instance store wiped).

Q6 A team needs data on their EC2 server to survive even if the instance is stopped, started, or terminated, and they want to be able to take backups of that data. Which storage choice meets this?

  1. Instance store volumes
  2. An Amazon EBS volume
  3. The instance's RAM
  4. The root device of a Spot Instance only
Answer: B
Why B is correct: Amazon EBS (Elastic Block Store) volumes are network-attached and persist independently of the instance lifecycle, so data survives stop/start, and you can take point-in-time EBS snapshots stored in S3 for backups.
Why the other options are wrong:
  • A — Instance store is ephemeral and is wiped when the instance stops or terminates.
  • C — RAM is volatile memory; everything in it is lost on stop or restart.
  • D — The purchasing model (Spot) does not change storage persistence rules; the storage type does.
Common trap: Believing the root volume is always persistent — it depends on the storage type (EBS persists, instance store does not), not on which purchasing option you chose.

Q7 A developer wants new EC2 instances to automatically install software and run a setup script the first time they boot, with no manual login. Which EC2 feature provides this?

  1. User data
  2. An Elastic IP address
  3. A security group rule
  4. An IAM role
Answer: A
Why A is correct: User data is a script you supply at launch that the instance runs automatically on first boot, making it the standard way to install packages and configure software without logging in.
Why the other options are wrong:
  • B — An Elastic IP is a static public IP address; it does nothing for software setup.
  • C — A security group controls inbound/outbound network traffic, not boot-time configuration.
  • D — An IAM role grants the instance AWS permissions but does not run setup scripts.
Common trap: Confusing user data (a boot-time script) with an AMI (a pre-baked image) — user data customizes at launch, while an AMI bakes the configuration in ahead of time.

Q8 A company wants to launch many identical EC2 instances quickly, each with the same operating system, patches, and pre-installed application already baked in. What should they create and reuse?

  1. A launch into a placement group
  2. An EBS snapshot schedule
  3. A CloudFormation drift report
  4. An Amazon Machine Image (AMI)
Answer: D
Why D is correct: An Amazon Machine Image (AMI) is a template that contains the OS, configuration, and any pre-installed software. Launching from a custom AMI gives you identical, ready-to-run instances quickly and consistently.
Why the other options are wrong:
  • A — A placement group controls how instances are physically placed for networking/performance, not their software contents.
  • B — EBS snapshots back up a single volume's data; they are not a full launch template with OS and apps.
  • C — A drift report compares deployed infrastructure to a template; it does not create reusable server images.
Common trap: Picking EBS snapshot — a snapshot is just disk data, while an AMI is the complete bootable template needed to launch identical instances.

Q9 An application receives unpredictable traffic and the team wants to automatically add EC2 instances during busy periods and remove them when traffic drops, to control cost. Which service does this?

  1. Elastic Load Balancing
  2. Amazon CloudFront
  3. Amazon EC2 Auto Scaling
  4. AWS Savings Plans
Answer: C
Why C is correct: EC2 Auto Scaling automatically changes the number of running instances based on demand or schedules, adding capacity when busy and removing it when idle. That is exactly what "add and remove instances automatically" describes.
Why the other options are wrong:
  • A — Elastic Load Balancing spreads incoming traffic across existing instances but does not create or delete instances.
  • B — CloudFront is a content delivery network for caching content closer to users, unrelated to scaling instance counts.
  • D — Savings Plans is a pricing/billing model, not a scaling mechanism.
Common trap: Confusing Auto Scaling with a load balancer — Auto Scaling changes how many instances exist; ELB only distributes traffic across whatever instances already exist.

Q10 A web tier has several EC2 instances and the team needs incoming user requests spread evenly across the healthy instances so no single server is overwhelmed. Which service handles this?

  1. EC2 Auto Scaling
  2. Elastic Load Balancing
  3. Amazon Route 53 health-check failover only
  4. AWS Global Accelerator pricing tier
Answer: B
Why B is correct: Elastic Load Balancing (ELB) automatically distributes incoming traffic across multiple healthy targets such as EC2 instances, and it routes around instances that fail health checks. That is the core job of a load balancer.
Why the other options are wrong:
  • A — Auto Scaling adjusts how many instances run; it does not distribute requests across them.
  • C — Route 53 is DNS-level routing; while it can do failover, ELB is the purpose-built service for spreading traffic across instances in a tier.
  • D — Global Accelerator improves global network paths and is not the standard answer for evenly balancing a local web tier.
Common trap: Mixing the two scaling-related services — remember: ELB balances traffic, Auto Scaling balances the number of servers. They are often used together but do different jobs.

Q11 A team runs short event-driven functions that respond to file uploads and complete in a few seconds. They want no servers to manage and to pay only for the milliseconds the code runs. Which compute service fits best?

  1. Amazon EC2 with On-Demand pricing
  2. Amazon EC2 Spot Instances
  3. Amazon EC2 Dedicated Hosts
  4. AWS Lambda
Answer: D
Why D is correct: AWS Lambda is serverless: you upload code, it runs in response to events, scales automatically, and you pay only for the compute time used (measured in milliseconds). Short, event-driven tasks with no server management are the ideal Lambda workload.
Why the other options are wrong:
  • A — EC2 On-Demand still means you manage servers and pay while instances run, even when idle.
  • B — Spot still involves managing EC2 instances and can be interrupted; it is not serverless per-millisecond billing.
  • C — Dedicated Hosts are the most server-management-heavy and costly option, the opposite of serverless.
Common trap: Choosing EC2 because it is the "compute" service in the topic — short, event-driven, no-server-management workloads point to Lambda, not EC2.

Q12 A company already containerizes its applications with Docker and wants to run those containers on AWS without provisioning or managing any EC2 servers. Which option provides serverless container compute?

  1. Amazon ECS on EC2 launch type
  2. AWS Fargate
  3. Amazon EC2 with user data installing Docker
  4. Amazon EC2 Auto Scaling group of Docker hosts
Answer: B
Why B is correct: AWS Fargate is the serverless way to run containers — it runs your containers (with ECS or EKS) without you provisioning, patching, or scaling the underlying EC2 instances. The scenario explicitly wants containers with no server management, which is Fargate's purpose.
Why the other options are wrong:
  • A — The ECS EC2 launch type still requires you to manage the EC2 instances that host the containers.
  • C — Installing Docker on EC2 yourself means you fully manage the servers.
  • D — An Auto Scaling group of Docker hosts still leaves you managing EC2 instances.
Common trap: Thinking ECS or EKS by itself is serverless — those are orchestrators; only the Fargate launch type removes the need to manage EC2 hosts.

Q13 A small application server is mostly idle but occasionally needs a brief burst of CPU. The team wants a low-cost instance that handles these short spikes using accumulated credits. Which EC2 instance family is designed for this?

  1. Compute optimized (C-family)
  2. Memory optimized (R-family)
  3. Burstable performance (T-family)
  4. Storage optimized (I-family)
Answer: C
Why C is correct: Burstable T-family instances (like T3) provide a baseline level of CPU and accumulate CPU credits while idle, which they spend during short bursts. This makes them cheap and ideal for workloads that are usually quiet with occasional spikes.
Why the other options are wrong:
  • A — Compute optimized instances are for sustained high-CPU work and cost more than needed for an idle server.
  • B — Memory optimized instances target large in-memory datasets, not bursty low CPU.
  • D — Storage optimized instances are for high disk throughput/IOPS workloads, unrelated to CPU bursting.
Common trap: Assuming "occasional CPU burst" means compute-optimized — sustained high CPU is C-family; short, infrequent bursts on a cheap instance is the burstable T-family.

Q14 A finance workload analyzes a very large in-memory dataset and frequently runs out of RAM on general-purpose instances. Which EC2 instance family is the right fit?

  1. Memory optimized
  2. Compute optimized
  3. Burstable performance
  4. General purpose
Answer: A
Why A is correct: Memory optimized instances provide a high ratio of RAM to CPU, which is exactly what a large in-memory dataset (such as an in-memory database or analytics cache) needs to avoid running out of memory.
Why the other options are wrong:
  • B — Compute optimized favors CPU power, not large memory, so it would still run short on RAM.
  • C — Burstable instances are small and aimed at low, occasional CPU use, not big memory needs.
  • D — General purpose is balanced and is the family they are already outgrowing.
Common trap: Matching "large dataset" to storage-optimized — large data sitting in RAM means memory optimized; large data on fast disks would be storage optimized.

Q15 When AWS needs to reclaim a Spot Instance because capacity is needed elsewhere or the Spot price changes, what does AWS provide before reclaiming it?

  1. A guarantee that the instance will never be interrupted
  2. A full refund of all charges for that hour
  3. An automatic migration to On-Demand pricing
  4. A two-minute interruption notice
Answer: D
Why D is correct: AWS gives a short interruption notice (about two minutes) before reclaiming a Spot Instance, allowing the application to save work or drain connections. This is why Spot suits fault-tolerant, checkpoint-friendly workloads.
Why the other options are wrong:
  • A — The whole point of Spot is that interruptions can happen; there is no no-interruption guarantee.
  • B — Spot does not refund an hour's charges when reclaiming; you simply pay for what you used.
  • C — AWS does not automatically convert a reclaimed Spot Instance to On-Demand pricing.
Common trap: Believing Spot silently disappears with no warning — there is a brief notice, which is what makes graceful shutdown handling possible.

Q16 A company wants its EC2 instances to run on hardware that is physically isolated from other AWS customers for compliance, but it does not need visibility into sockets/cores or to bring its own per-core license. Which is the simplest fit?

  1. Dedicated Instances
  2. Dedicated Hosts
  3. Reserved Instances
  4. Spot Instances
Answer: A
Why A is correct: Dedicated Instances run on hardware dedicated to a single customer account, giving the physical isolation that compliance may require, without the extra management and cost of controlling specific physical hosts.
Why the other options are wrong:
  • B — Dedicated Hosts also isolate hardware but add host-level visibility and management overhead the scenario doesn't need, at higher cost.
  • C — Reserved Instances are a pricing commitment, not a hardware-isolation feature.
  • D — Spot uses shared spare capacity and can be reclaimed, providing no isolation.
Common trap: Choosing Dedicated Hosts for any "isolation" wording — if you don't need socket/core visibility or per-core licensing, Dedicated Instances are the simpler, cheaper isolation option.

Q17 A startup is unsure how many EC2 instances it will need over the next few months and is still testing different instance types weekly. It wants no long-term commitment and the freedom to change anything. Which purchasing option fits this exploratory phase?

  1. 3-year Standard Reserved Instances
  2. On-Demand Instances
  3. Compute Savings Plans
  4. Spot Instances
Answer: B
Why B is correct: On-Demand has zero commitment and lets you start, stop, and change instance types freely while paying only for what you use. That flexibility is ideal during early testing when needs are unknown.
Why the other options are wrong:
  • A — A 3-year Reserved commitment is the opposite of "no long-term commitment."
  • C — Savings Plans still require a 1- or 3-year spend commitment, which the startup isn't ready for.
  • D — Spot is cheap but can be interrupted, making it unreliable for steady testing of how the app behaves.
Common trap: Reaching for a discount model too early — commitments only pay off once usage is predictable; during unknown/testing phases On-Demand is the safe default.

Q18 A team commits to a Compute Savings Plan for a steady $10/hour of compute. During one hour they run instances worth $13 of compute usage. How is the extra $3 of usage billed?

  1. The extra usage is billed at standard On-Demand rates
  2. The extra usage is free until the commitment renews
  3. The entire hour is rebilled at On-Demand rates
  4. The instances are automatically stopped at the $10 limit
Answer: A
Why A is correct: A Savings Plan applies its discount up to your committed spend; any usage beyond the commitment is simply charged at normal On-Demand rates. So the first $10 gets the discounted rate and the extra $3 is billed On-Demand.
Why the other options are wrong:
  • B — Usage above the commitment is never free; you pay On-Demand for the overage.
  • C — The committed portion keeps its discount; AWS does not rebill the whole hour at On-Demand.
  • D — Savings Plans are a billing construct and never stop your instances.
Common trap: Thinking a commitment is a hard cap — it is a discounted floor of spend, and you can always run more (paying On-Demand for the excess).

Q19 A company runs a predictable, steady fleet but specifically wants a discount that can be sold on the Reserved Instance Marketplace if its plans change. Which option allows reselling on that marketplace?

  1. Compute Savings Plans
  2. EC2 Instance Savings Plans
  3. Standard Reserved Instances
  4. Convertible Reserved Instances
Answer: C
Why C is correct: Standard Reserved Instances can be listed and sold on the Reserved Instance Marketplace if you no longer need them, giving an exit option. This resale ability is a distinguishing feature of Standard RIs.
Why the other options are wrong:
  • A — Savings Plans commitments cannot be sold on the Reserved Instance Marketplace.
  • B — EC2 Instance Savings Plans are also Savings Plans and are not resellable on that marketplace.
  • D — Convertible RIs offer flexibility to change attributes but cannot be sold on the Reserved Instance Marketplace.
Common trap: Assuming all commitment discounts behave the same — only Standard RIs can be resold; Savings Plans and Convertible RIs cannot.

Q20 A general-purpose web application has a balanced need for CPU, memory, and networking and no special requirements. Which EC2 instance family is the most appropriate starting point?

  1. Storage optimized
  2. Accelerated computing (GPU)
  3. General purpose
  4. Memory optimized
Answer: C
Why C is correct: General purpose instances provide a balanced mix of CPU, memory, and networking, which is the right default for typical web and application servers that have no extreme resource skew.
Why the other options are wrong:
  • A — Storage optimized targets heavy disk throughput/IOPS workloads, not balanced web apps.
  • B — Accelerated computing uses GPUs for machine learning or graphics, which is overkill and costly here.
  • D — Memory optimized is for memory-heavy workloads, more than a balanced web app needs.
Common trap: Over-engineering the choice — when a workload is balanced with no special demand, general purpose is the correct, cost-effective default.

Q21 A workload steadily uses the same instance family in one region for 1 year and wants the deepest possible discount, accepting that it will not change instance family. The team prefers a discount that locks to that instance family but still flexes across sizes within it. Which option best fits?

  1. Compute Savings Plans
  2. EC2 Instance Savings Plans
  3. On-Demand Instances
  4. Spot Instances
Answer: B
Why B is correct: EC2 Instance Savings Plans give a higher discount than Compute Savings Plans in exchange for committing to a specific instance family in a region, while still letting you change instance size, OS, and tenancy within that family. That matches "lock to the family, deepest discount, flex on size."
Why the other options are wrong:
  • A — Compute Savings Plans are more flexible (any family, Fargate, Lambda) but offer a smaller discount than EC2 Instance Savings Plans.
  • C — On-Demand has no commitment and no discount, so it cannot be the deepest-discount choice.
  • D — Spot is cheap but interruptible and offers no steady, committed discount for a continuous workload.
Common trap: Treating the two Savings Plan types as identical — Compute SP = max flexibility, smaller discount; EC2 Instance SP = locked to a family, bigger discount.

Q22 An administrator stops an EBS-backed EC2 instance for the night to save money. Which statement about billing while it is stopped is correct?

  1. You stop paying for everything, including storage
  2. You continue paying full On-Demand compute charges
  3. Stopping is not allowed for EBS-backed instances
  4. You still pay for the attached EBS volumes, but not for instance compute hours
Answer: D
Why D is correct: When an EBS-backed instance is stopped, you are no longer charged for the compute (instance hours), but the EBS volumes still exist and store your data, so you keep paying for that storage until you delete the volumes.
Why the other options are wrong:
  • A — Storage is not free while stopped; EBS volumes still incur charges.
  • B — Stopped instances do not incur compute charges, so you are not paying full On-Demand rates.
  • C — EBS-backed instances absolutely can be stopped; that is one of their key advantages.
Common trap: Assuming "stopped" means "no charges at all" — compute stops billing, but persistent EBS storage keeps billing until removed.

Q23 A media company needs the absolute cheapest way to run a fleet of stateless web servers behind a load balancer, and the application is built so that losing a few servers at any moment causes no harm. Which approach maximizes savings while staying resilient?

  1. Run the entire fleet on 3-year Dedicated Hosts
  2. Run the fleet on On-Demand Instances only
  3. Run a single large Reserved Instance for the whole fleet
  4. Run the fleet on Spot Instances within an Auto Scaling setup
Answer: D
Why D is correct: Spot Instances are the cheapest, and because the app is stateless and tolerates losing servers, Spot interruptions cause no harm. Combining Spot with Auto Scaling and a load balancer keeps enough healthy capacity even as individual Spot instances come and go.
Why the other options are wrong:
  • A — Dedicated Hosts are the most expensive option, the opposite of "absolute cheapest."
  • B — On-Demand is reliable but far costlier than Spot for an interruption-tolerant fleet.
  • C — A single Reserved Instance is one server, not a resilient fleet, and provides no fault tolerance.
Common trap: Avoiding Spot because of interruptions — for stateless, fault-tolerant fleets behind ELB and Auto Scaling, Spot is both cheapest and resilient.

Q24 A solutions team is comparing where to run a long-running, always-on backend process that needs full control of the operating system. Why would they choose EC2 over AWS Lambda?

  1. EC2 gives OS-level control and suits steady long-running processes, while Lambda is for short event-driven tasks
  2. Lambda is cheaper for any always-on workload
  3. Lambda functions have no execution time limit
  4. EC2 cannot run continuous processes, so Lambda is required
Answer: A
Why A is correct: EC2 gives you full control of the operating system and is well suited to steady, always-on, long-running workloads. Lambda is designed for short, event-driven functions and has a maximum execution time per invocation, so a continuous backend process belongs on EC2.
Why the other options are wrong:
  • B — For always-on workloads, paying per-millisecond Lambda runs continuously can be more expensive than a steady EC2 instance, and Lambda also doesn't give OS control.
  • C — Lambda has a maximum execution duration per invocation, so it does have a time limit.
  • D — EC2 is perfectly capable of running continuous processes; that is a core use case.
Common trap: Assuming serverless is always cheaper and better — for steady, always-running workloads needing OS control, EC2 is the right tool; Lambda shines for short, bursty, event-driven tasks.

Continue reading