EC2 & Compute

Correct answer: .

Instance store volumes are physically attached ephemeral storage. Their contents survive an OS reboot but are lost whenever the instance is stopped, hibernated, or terminated, because the instance may be moved to different underlying hardware. There is no automatic backup to S3, and no automatic migration to EBS; both would require the engineer to set up copies explicitly. This is why instance store suits only temporary data such as caches, buffers, and scratch space, while anything that must persist belongs on EBS or S3. A common exam trap is confusing reboot (data survives) with stop (data lost).

Source: AWS EC2 docs: Amazon EC2 instance store — lifetime of instance store data

Correct answer: .

Spot Instances offer the deepest discounts on EC2 compute, commonly up to around 90% versus On-Demand pricing, in exchange for the possibility that AWS reclaims the capacity with a two-minute warning. A transcoding job that is fault tolerant and restartable is the textbook Spot workload: an interruption costs only a retry, not lost data. On-Demand is flexible but the most expensive of the sensible options here. Reserved Instances reward steady, predictable usage over one or three years, not a nightly batch job. Dedicated Hosts exist for licensing and compliance needs and carry premium pricing, solving a problem this company does not have.

Source: AWS EC2 docs: Instance purchasing options — Spot Instances

Correct answer: .

A standard auto-assigned public IPv4 address is not static: it is released when the instance stops and a new one is assigned when it starts again, which is why the instance receives a new public IPv4 address. The address is only retained across a stop/start cycle if an Elastic IP address is explicitly allocated and associated with the instance, so the option claiming the address is retained only describes the Elastic IP case, which the question rules out. The instance does not lose public connectivity permanently; it simply receives a different public address once it is running again, so the option suggesting permanent loss of connectivity confuses temporary reassignment with permanent loss. AWS never automatically converts a dynamic public IP into an Elastic IP; Elastic IPs must be deliberately allocated from the EC2 console or API and then associated, so the option describing an automatic conversion describes something AWS does not do on its own.

Source: AWS EC2 documentation: Elastic IP addresses — public IPv4 address behaviour on instance stop/start

Correct answer: .

Burstable instances like t3.medium accumulate CPU credits while running below their baseline performance and spend them to burst above it; in Standard mode, once credits are exhausted, CPU performance is throttled back down to the baseline. Switching the credit specification to Unlimited mode lets the instance burst above baseline for as long as needed, with AWS billing any surplus usage beyond what earned credits cover, which directly solves the described problem. A Spread placement group only changes which underlying hardware instances land on for fault isolation; it has no effect on CPU credit behaviour. Enabling EBS optimization dedicates bandwidth to EBS volume traffic and improves storage throughput, but does not touch CPU credit throttling. Changing an Auto Scaling group's health check type from EC2 to ELB affects how unhealthy instances are detected and replaced, which is unrelated to a single instance's CPU performance ceiling.

Source: AWS EC2 documentation: Burstable performance instances — Unlimited mode

Correct answer: .

IMDSv1 allows a simple, unauthenticated GET request to the instance metadata endpoint, which is exactly what many server-side request forgery (SSRF) exploits abuse to retrieve an instance's temporary IAM role credentials through a vulnerable application. Requiring IMDSv2, by setting HttpTokens to required, forces every metadata request to first obtain a session token via a PUT request with a hop limit, which most SSRF techniques cannot replicate because they typically cannot issue arbitrary PUT requests or control the token's TTL and hop count, closing off this specific credential-theft path. Switching to a Dedicated Host changes billing and hardware tenancy for licensing purposes and has no bearing on metadata credential exposure. Detailed CloudWatch monitoring only increases the frequency of metric collection for observability; it does not prevent or detect credential theft on its own. A cluster placement group only affects network latency and throughput between instances in the same Availability Zone and is unrelated to metadata security.

Source: AWS EC2 documentation: Instance metadata service version 2 (IMDSv2)

Correct answer: .

A Spread placement group strictly places each instance on distinct underlying hardware, each with its own separate power source and network path, and it supports up to 7 running instances per group per Availability Zone, which is exactly the level of per-instance hardware isolation this scenario needs for a small number of critical instances. A Cluster placement group instead packs instances close together within a single Availability Zone to minimise network latency and maximise throughput, which increases rather than decreases the chance that a single hardware or rack failure affects multiple instances. A Partition placement group divides instances into a smaller number of partitions, where each partition can contain many instances, and is designed for large distributed systems such as Hadoop, Cassandra, or Kafka that can tolerate losing an entire partition, not for guaranteeing per-instance isolation among only 5 critical instances. Relying on AWS's default placement gives no guarantee about hardware separation at all, leaving the outcome entirely up to AWS's internal placement decisions.

Source: AWS EC2 documentation: Placement groups — spread placement groups

Correct answer: .

An Auto Scaling group's health_check_type defaults to EC2, meaning it only reacts to EC2 status check failures at the hardware, network, and OS level; an instance that is otherwise healthy but whose application process has crashed will keep running and keep failing to serve traffic until an operator explicitly changes the health check type to ELB, which makes the Auto Scaling group also honour the target group's health checks and replace instances that fail them. The fourth option describes ELB-type behaviour, which is not the default the question specifies. The second option is false because an Application Load Balancer only routes traffic and reports target health; it never restarts processes running inside an instance's operating system. The third option misunderstands how health checks interact with scaling: a failing health check does not, by itself, trigger a scale-out event, since scale-out is driven by scaling policies, not health check type.

Source: AWS documentation: Amazon EC2 Auto Scaling — health checks for Auto Scaling instances

Correct answer: .

Launch Configurations are immutable once created, so they cannot be edited to add settings, which rules out editing the existing Launch Configuration outright, and they also lack support for several newer Auto Scaling capabilities, including mixed instances policies that combine On-Demand and Spot purchase options across multiple instance types in a single group. Launch Templates are the modern replacement: they support versioning so changes can be iterated on safely, expose the full range of current EC2 launch parameters, and are required to configure a mixed instances policy, making migration to a Launch Template correct. The claim that Launch Configurations already support mixed instances policies is simply factually wrong, since Launch Configurations were never extended to support them. Creating a second, separate Spot-only Auto Scaling group could technically work operationally, but it abandons the stated goal of keeping this within one Auto Scaling group and needlessly duplicates and fragments the infrastructure instead of solving the underlying limitation.

Source: AWS documentation: Amazon EC2 Auto Scaling — launch templates versus launch configurations

Correct answer: .

A Dedicated Host is a physical server fully dedicated to a single AWS account, and unlike other tenancy options it exposes the host's identifier along with its exact number of sockets and physical cores, plus the ability to target specific instances to specific hosts, which is precisely what socket- or core-bound licensing terms and compliance reporting require. Dedicated Instances also run on hardware dedicated to a single account, but the account has no visibility into or control over the underlying host's identity, sockets, or cores, so they cannot support socket-bound license reporting even though they satisfy general single-tenant isolation. Default shared tenancy explicitly allows hardware to be shared with other AWS customers, which immediately disqualifies it for hardware-bound licensing. A cluster placement group only affects the network placement of instances for low-latency, high-throughput communication and has no relationship to tenancy, hardware visibility, or licensing at all.

Source: AWS documentation: Dedicated Hosts versus Dedicated Instances

Correct answer: .

Standard Reserved Instances allow limited modifications during their term, such as changing Availability Zone, scope, network platform, or instance size within the same instance family and generation, but they can never be exchanged into a different instance family, which rules out the m5-to-c6g move described here. Only Convertible Reserved Instances support mid-term exchange into a different configuration, including a different instance family, operating system, or tenancy, provided the new RI's value is equal to or greater than the value being exchanged, which is exactly why Convertible RIs carry a smaller discount than Standard RIs in exchange for that flexibility. The option suggesting the Standard RI can simply be exchanged for a c6g.large RI is wrong specifically because this purchase is a Standard RI, not a Convertible one. The claim that both RI types can freely change instance family overstates what Standard RIs can do, since their modification options never include changing family. The claim that no RI type ever supports a mid-term change is wrong because Convertible RIs exist precisely to support this kind of mid-term family change before the original term ends.

Source: AWS documentation: Reserved Instances — modifying Standard RIs and exchanging Convertible RIs

Correct answer: .

Instance-store-backed instances use local host disk as their root volume, and because that root volume cannot be detached from the underlying hardware and reattached elsewhere, the EC2 console and API only offer reboot or terminate for these instances; stop and start are simply not available. The option describing a normal stop is wrong because that behavior applies only to EBS-backed instances, whose root volume persists on EBS storage independent of the host and can be reattached after the instance migrates to new hardware. Automatic conversion to an EBS volume does not happen on its own; producing an EBS-backed equivalent would require manually creating a new AMI and launching from it. Hibernation is also unavailable here because hibernating requires an encrypted EBS root volume to save the instance's RAM contents to, and an instance-store-backed instance has no such volume to write to.

Source: AWS EC2 documentation: Stop and start Amazon EC2 instances — instance store root volume restrictions

Correct answer: .

AWS documents different default DeleteOnTermination behavior for a non-root data volume depending on how it is attached at launch: attaching it through the console defaults to preserving the volume (DeleteOnTermination false), while attaching the same kind of volume at launch through the CLI or API defaults to deleting it (DeleteOnTermination true) unless the block device mapping explicitly overrides that value. So an engineer who launches via the CLI and does not set the attribute ends up with the volume deleted on termination, which surprises people who assume the console's more forgiving default applies everywhere. The claim that non-root volumes are never deleted automatically ignores this CLI default entirely. Root and data volume DeleteOnTermination settings are independent attributes, so a data volume's behavior does not automatically mirror whatever was chosen for the root volume. There is no rule tying deletion behavior to whether a volume originated from a snapshot; only the attach method and explicit configuration matter.

Source: AWS EC2 documentation: Preserve data when an instance is terminated — default deletion behavior for EBS volumes

Correct answer: .

A Cluster placement group packs instances close together within a single Availability Zone specifically to minimize inter-instance network latency and maximize throughput for tightly coupled workloads such as HPC and MPI simulations, which means it cannot span multiple Availability Zones at all; spanning multiple AZs to increase resilience instead describes a Spread placement group's design goal. Because a Cluster placement group intentionally packs instances close together on related hardware, it does the opposite of guaranteeing isolation from a single hardware failure — that isolation guarantee describes a Spread placement group, not a Cluster one. Enhanced networking is a capability of supported instance types paired with the right driver, and it can be enabled with or without any placement group; a Cluster placement group is not a prerequisite for it, though combining enhanced-networking-capable instances with a Cluster placement group is a common way to get the full latency and throughput benefit.

Source: AWS EC2 documentation: Placement groups — cluster placement strategy

Correct answer: .

Hibernation saves an instance's RAM contents to its EBS root volume and then leaves the instance in the stopped state, and because compute usage is not billed for a stopped instance, AWS does not charge for instance usage or for the data transfer involved in writing RAM to the root volume while hibernated; what does continue to be billed is ordinary EBS storage, which now includes the extra space consumed by the saved memory contents, so the true cost is not zero. Billing the full On-Demand rate throughout is wrong because stopped and hibernated instances are never charged for compute time. Claiming zero charges overlooks the ongoing EBS storage cost for the volume holding both the root filesystem and the RAM snapshot. There is no discounted hibernation-specific instance rate comparable to Spot pricing; the only cost incurred is the standard EBS storage charge.

Source: AWS EC2 documentation: Hibernate your Amazon EC2 instance — billing during hibernation

Correct answer: .

The DisableApiTermination attribute blocks calls to the underlying TerminateInstances API, and because the console's terminate action and standard CLI or SDK terminate calls all route through that same API, both of those paths are blocked exactly as the attribute is designed to do. Amazon EC2 Auto Scaling, however, terminates and replaces instances during scale-in events and unhealthy-instance replacement through its own internal management logic, which is not restricted by this instance attribute, so a scale-in event can still remove a termination-protected instance from the group. The dedicated control for preventing that specific behavior is Auto Scaling's own instance scale-in protection feature, which must be enabled separately on a per-instance basis. That the console-based terminate action is blocked follows directly from it calling the same underlying API as a direct request. Claiming termination protection has no exceptions overstates what the attribute actually does; it guards specifically against direct API-driven termination, not every termination pathway on the platform.

Source: AWS EC2 documentation: Change instance termination protection — DisableApiTermination considerations

Correct answer: .

A lifecycle hook's default heartbeat timeout is 3600 seconds, or one hour; if nothing calls RecordLifecycleActionHeartbeat or completes the lifecycle action before that hour elapses, Auto Scaling stops waiting and proceeds using the hook's configured default result, so an installation still running at the one-hour mark is cut off from the Pending:Wait state well before a 3-hour job would finish. Stretching the wait beyond the default requires the instance to actively send heartbeats, each of which resets the countdown, and doing this repeatedly can extend the total wait up to a documented maximum of 48 hours — but that requires deliberate heartbeat calls, which this scenario explicitly says are not happening. There is no Auto Scaling lifecycle hook setting with a default heartbeat timeout of 4 hours, so that option describes a number that doesn't exist in the service. Lifecycle hooks are also not indefinite by default; without heartbeats or a completion call, they always resolve once the heartbeat timeout expires, and nothing about merely creating the hook causes an immediate termination.

Source: AWS documentation: Amazon EC2 Auto Scaling — lifecycle hooks (Pending:Wait/Terminating:Wait, heartbeat timeout)

Correct answer: .

A warm pool sits alongside an Auto Scaling group as a separate pool of pre-initialized instances that are not counted as part of the group's desired capacity while they remain in the pool; only when a scale-out event draws an instance out of the warm pool into the group, known as a warm start, does that instance begin counting toward desired capacity. This separation is the entire point of the feature: it lets instances finish a lengthy boot process ahead of time so the group can absorb demand quickly, without inflating the counted, InService fleet beforehand. Instances are never counted twice; the warm pool and the group's InService fleet are tracked as distinct populations precisely so cost and capacity accounting stay separate until a warm start occurs. There is also no requirement to reduce desired capacity to zero before creating a warm pool — its default size is simply calculated from the difference between the group's maximum capacity and its current desired capacity, so both coexist normally from the start.

Source: AWS documentation: Amazon EC2 Auto Scaling — warm pools (core concepts)

Correct answer: .

EC2 Fleet, and its predecessor Spot Fleet, is designed exactly for this scenario: a single request can define multiple instance types, span multiple Availability Zones, and blend On-Demand and Spot purchase options, and when the fleet includes Spot Instances it can automatically request replacement Spot capacity after an interruption, optionally using Capacity Rebalancing to proactively replace instances flagged as being at elevated risk of interruption before they're reclaimed. A single Launch Template tied to one instance type only describes the launch configuration for one kind of instance and has no fleet-level logic for spanning types, Availability Zones, or purchase options by itself. A Standard Reserved Instance is a billing commitment for one specific instance type in one specific Availability Zone (or Region, if regional) and neither launches instances nor mixes purchase options. A Dedicated Host reserves a single-tenant physical server for an account's own instance placement and has no mechanism for combining instance types, Availability Zones, or Spot and On-Demand purchasing within a single launch request.

Source: AWS EC2 documentation: EC2 Fleet and Spot Fleet — features and benefits

Correct answer: .

On-Demand Capacity Reservations created for immediate use carry no term commitment at all — they can be created, modified, or canceled at any time — which matches a short, three-day, no-commitment requirement, and Capacity Reservations are explicitly supported alongside Cluster placement groups, letting instances that need guaranteed capacity also gain a Cluster placement group's low-latency, high-throughput packing. Spread and Partition placement groups, however, are not supported with Capacity Reservations at all, so pairing a Capacity Reservation with either one is not a configuration AWS allows, ruling out those combinations regardless of how appealing the isolation or distribution properties might otherwise be. A one-year Standard Reserved Instance fails on two counts here: it locks in a full one-year term that doesn't fit a three-day event, and separately, Capacity Reservations, not Reserved Instances, are the construct that can't be combined with Dedicated Hosts — Dedicated Hosts have their own distinct host-allocation mechanism that doesn't combine with either reservation type in this way.

Source: AWS EC2 documentation: EC2 Capacity Reservations — placement group and Dedicated Host limitations

Correct answer: .

Automatic instance recovery is specifically designed so the recovered instance keeps its instance ID, private IP address, public IPv4 address, and any Elastic IP, along with its instance metadata, placement group, and attached EBS volumes — the only things lost are the contents of volatile memory and, for CloudWatch action-based recovery, instance store data. A manual stop and start does not offer the same guarantee for the public IPv4 address: because a standard public IPv4 address isn't static, starting a stopped instance normally assigns it a new one unless an Elastic IP is explicitly associated first, which is the key practical difference between the two approaches. Instance store data is lost in both a manual stop and, for CloudWatch action-based recovery, automatic recovery — it is not preserved by a manual stop as the second option claims. Neither approach changes the instance's private IP address, and automatic recovery specifically keeps the instance within its original Availability Zone rather than moving it elsewhere.

Source: AWS EC2 documentation: Automatic instance recovery — characteristics of recovered instances

Correct answer: .

The Nitro System splits traditional hypervisor responsibilities across dedicated hardware components: Nitro Cards handle networking, EBS storage I/O, and security functions outside the main host CPU, the Nitro Hypervisor itself is reduced to a thin layer mainly responsible for CPU and memory allocation, and the Nitro Security Chip acts as a hardware root of trust that continuously monitors and protects the system's hardware and firmware. This offloading is precisely why Nitro-based instances can deliver nearly all of a host's compute and memory to the customer's workload while still providing high-throughput networking and low-latency EBS performance. Claiming the hypervisor was removed entirely is inaccurate — the Nitro Hypervisor still exists, just minimized rather than eliminated. The improvement is also not a mere software upgrade; it required purpose-built Nitro Card hardware alongside the software changes. Nitro-based instance types remain ordinary shared or dedicated-tenancy instances depending on what a customer selects at launch; using the Nitro System has no automatic effect on tenancy or Dedicated Host billing.

Source: AWS documentation: AWS Nitro System overview (aws.amazon.com/ec2/nitro)

Correct answer: .

Session Manager connects to managed nodes through the SSM Agent running on the instance together with an IAM role attached to it, using an outbound-only connection to the Systems Manager service, so it needs no inbound SSH or RDP port open, no bastion host, no SSH key management, and no public IP address on the target, while still giving administrators centralized, IAM-policy-based access control and optional session logging to CloudTrail, S3, or CloudWatch Logs. EC2 Instance Connect still relies on SSH over port 22, since it merely pushes a short-lived public key rather than eliminating the SSH connection itself, so it does not satisfy the requirement to avoid inbound SSH access entirely. A bastion host in a public subnet is a workable pattern but still requires a running host, managed inbound access, and typically SSH keys, which is exactly the operational overhead the team wants to avoid. IMDSv2 only hardens how an instance queries its own metadata endpoint from within itself; it plays no role in providing remote shell access to engineers.

Source: AWS Systems Manager documentation: Session Manager overview

Correct answer: .

Amazon EC2 runs user data shell scripts and cloud-init directives only during the initial boot cycle when an instance is first launched; making a script run on every subsequent reboot or start requires explicitly opting into that behavior, for example by adding cloud-init's scripts-user "always" configuration on Linux, which the engineer's script did not include, so it correctly ran once at launch and then stayed dormant on the later reboot. This is a deliberate default rather than a permanent limitation, since once persistence is configured the same script can run on every start. User data is not cleared by a reboot either; it remains stored as an instance attribute and is simply not re-executed unless configured to be. The claim that only a full stop and start, and never a reboot, re-reads user data is also inaccurate, because without the persistence configuration, neither a reboot nor a stop and start re-runs the script — both follow the exact same first-boot-only default.

Source: AWS EC2 documentation: Run commands when you launch an EC2 instance with user data input — user data execution

Correct answer: .

A Compute Savings Plan is a commitment to a fixed dollar amount of compute usage per hour for a 1- or 3-year term, and in exchange its discount automatically applies to EC2 usage regardless of instance family, instance size, operating system, tenancy, or Region, and even extends to AWS Fargate and Lambda usage, which is exactly the flexibility this company's shifting architecture needs; it also reserves no physical capacity, so the discount is never tied to any particular Availability Zone. A zonal Reserved Instance is the opposite fit: it reserves capacity for one specific instance type in one specific Availability Zone, so any change in instance family or Region breaks the match and forfeits the discount unless the Reserved Instance is separately modified or exchanged. An On-Demand Capacity Reservation guarantees available capacity rather than providing a billing discount, so despite its flexible term it does not address the stated one-year discount requirement at all. A Dedicated Host reservation is a hardware tenancy construct aimed at licensing and compliance needs, and it carries no automatic cross-family billing discount comparable to a Savings Plan.

Source: AWS documentation: Savings Plans — Compute Savings Plans vs Reserved Instances

Correct answer: .

gp3 decouples baseline performance from volume size: every gp3 volume gets 3,000 IOPS and 125 MiB/s included at no extra charge regardless of how large it is, and additional IOPS (up to 16,000) and throughput (up to 1,000 MiB/s) can be provisioned independently for extra cost. gp2, by contrast, still ties baseline IOPS to volume size at a rate of 3 IOPS per GiB, with smaller volumes able to burst above that baseline using burst credits up to a ceiling of 3,000 IOPS. The option describing gp2 as offering a fixed 3,000-IOPS/125-MiB/s baseline regardless of size assigns gp3's own signature decoupled-from-size design to the wrong volume type. The option claiming both types scale baseline performance with size ignores gp3's explicit, size-independent baseline entirely. The option describing gp2 as offering a fixed 16,000-IOPS baseline invents a figure that doesn't match gp2's actual size-scaled formula, and gp3 clearly does support a baseline, contradicting the claim that it has none.

Source: AWS EBS documentation: Amazon EBS volume types — General Purpose SSD (gp3 vs gp2) baseline performance

Correct answer: .

io2 volumes are designed for 99.999% durability (an annual failure rate of about 0.001%), a full order of magnitude better than io1's 99.8%-99.9% durability (0.1%-0.2% annual failure rate), while both remain the same Provisioned IOPS SSD category built for sustained, low-latency, high-IOPS workloads like mission-critical databases, so io2 is the volume type suited to maximizing durability without changing architecture. The option favoring io1 for its IOPS ceiling gets the comparison backwards: io2 supports a higher maximum IOPS ceiling than io1 where it's available, not the reverse, and IOPS ceiling isn't the durability question being asked anyway. The option claiming gp3 now matches Provisioned IOPS SSD durability is incorrect: gp3, like gp2, remains rated at 99.8%-99.9% durability, the same tier as io1, not io2's 99.999%. The option proposing st1 is wrong on two counts: Throughput Optimized HDD is rated at 99.8%-99.9% durability, not 99.999%, and it is designed for large sequential throughput workloads such as big data and log processing, not low-latency transactional database access.

Source: AWS EBS documentation: Amazon EBS volume types — durability comparison (io2 vs io1)

Correct answer: .

AWS's HDD-backed volume types, Throughput Optimized HDD (st1) and Cold HDD (sc1), are both explicitly documented as unsupported for use as a boot volume, because they're built for large, sequential throughput workloads like big data, log processing, and infrequently accessed storage rather than the small, random I/O a boot volume needs at startup; only the SSD-backed types, gp2, gp3, io1, and io2, are supported as boot volumes. The option claiming sc1 is fully supported, and even recommended, for boot volumes directly contradicts this restriction. The option conditioning boot-volume support on launching from an instance-store-backed AMI confuses two unrelated concepts: instance-store-backed AMIs don't use EBS root volumes at all, so an sc1 boot volume wouldn't apply to them either. The option suggesting Fast Snapshot Restore unlocks sc1 as a boot volume is wrong because FSR only removes the first-access latency penalty on a volume created from a snapshot; it has no effect on which volume types are eligible to serve as a boot volume.

Source: AWS EBS documentation: Amazon EBS volume types — boot volume support table (st1/sc1 excluded)

Correct answer: .

EBS Multi-Attach is supported only on Provisioned IOPS SSD volumes (io1 and io2), and an enabled volume can be attached to up to 16 instances built on the Nitro System, but every attached instance must be in the same Availability Zone as the volume; Multi-Attach also doesn't provide its own write-ordering or locking, so ordinary file systems like XFS or EXT4, which assume only one server accesses them at a time, still need a cluster-aware file system layered on top to stay consistent under concurrent writes. The option claiming any volume type, including gp3, supports Multi-Attach is wrong because General Purpose SSD volumes don't support the feature at all. The option describing cross-AZ or cross-Region sharing is wrong because Multi-Attach is explicitly confined to a single Availability Zone; there's no mechanism for instances in different zones or Regions to share one Multi-Attach volume. The option restricting Multi-Attach to being enabled only via RunInstances at launch has it backwards: Multi-Attach specifically cannot be enabled during instance launch through the console or the RunInstances API, and must instead be enabled on the volume itself, separately from any single instance's launch.

Source: AWS EBS documentation: Attach an EBS volume to multiple EC2 instances using Multi-Attach — considerations and limitations

Correct answer: .

Amazon EBS snapshots are incremental: the very first snapshot of a volume copies all of the volume's used blocks, but every snapshot taken after that stores only the blocks that have changed since the most recent snapshot, so a snapshot taken after only a small fraction of a 500 GiB volume changed will typically consume only a small amount of additional storage, not another full 500 GiB. The option claiming the second snapshot always duplicates the entire volume ignores this incremental design entirely and would make frequent snapshotting far more expensive than it actually is. The option claiming the second snapshot is entirely free and consumes no storage overstates the benefit: incremental snapshots still store the changed blocks and are billed for that storage, they simply avoid re-storing unchanged data. The option tying snapshot size to the volume's provisioned IOPS confuses a performance setting with a storage-usage question; IOPS provisioning has no bearing on how much data a snapshot needs to store.

Source: AWS EBS documentation: Amazon EBS snapshots — incremental snapshots

Correct answer: .

Sharing an AMI backed by encrypted snapshots across accounts requires two separate steps: granting the target account launch permissions on the AMI itself, and separately updating the key policy of the customer managed KMS key used to encrypt the underlying snapshots so the target account is granted the permissions it needs (such as Decrypt, CreateGrant, and DescribeKey) to actually use that key when launching instances from the shared AMI; a customer managed key is required for this because AWS managed keys are tied to a single account and can never be shared across accounts. The option claiming launch permissions alone are sufficient ignores that the destination account still has no way to decrypt the underlying snapshot data without explicit key access. The option claiming encrypted AMIs can never be shared across accounts is simply wrong; this is a well-documented, supported workflow, provided the key policy is configured correctly. The option suggesting a switch to an AWS managed key would enable cross-account sharing gets it backwards, since it's the AWS managed key that cannot be shared across accounts, while the customer managed key is exactly what makes controlled cross-account access possible.

Source: AWS Security Blog: How to share encrypted AMIs across accounts to launch encrypted EC2 instances; AWS KMS documentation on cross-account key policy grants

Correct answer: .

EBS encryption by default is an account-and-Region-level setting that only changes behavior for resources created after it's turned on: once enabled, every newly created EBS volume and every new snapshot copy in that Region is automatically encrypted, but volumes and snapshots that already existed before the setting was enabled remain exactly as they were, unencrypted, until the administrator takes a separate, explicit action such as creating an encrypted snapshot copy of an existing volume and building a new encrypted volume from it. The option claiming existing resources are automatically re-encrypted in the background describes a retroactive migration this setting does not perform. The option claiming it applies to existing volumes but not existing snapshots invents an inconsistency that doesn't exist: the setting is forward-looking for both resource types equally, exempting neither existing volumes nor existing snapshots. The option claiming the setting never affects snapshots at all is also wrong, since new snapshots created after the setting is enabled are covered by it, just not retroactively for anything that already existed beforehand.

Source: AWS EBS documentation: Amazon EBS encryption — encryption by default

Correct answer: .

Without Fast Snapshot Restore, a volume created from a snapshot lazily loads each block from the snapshot's data in Amazon S3 the first time it's accessed, which causes exactly the first-touch latency penalty this team is seeing until every block has eventually been read at least once; enabling FSR for a specific snapshot in a specific Availability Zone means any volume subsequently created from that snapshot in that zone is fully initialized at creation and delivers all of its provisioned performance immediately, with no lazy-loading period at all. The option proposing Provisioned IOPS volumes is wrong because any of the standard EBS volume types can be created from a snapshot; the choice of io1/io2 versus gp2/gp3 doesn't change whether lazy-loading happens. The option proposing Multi-Attach is unrelated, since Multi-Attach is about sharing one volume across multiple instances, not about eliminating a single volume's first-access latency. The option proposing default encryption is also unrelated: encryption and decryption happen transparently regardless of whether a block has been lazily loaded yet, and enabling encryption by default does nothing to change the lazy-loading behavior itself.

Source: AWS EBS documentation: Amazon EBS fast snapshot restore (FSR)

Correct answer: .

Deregistering an AMI removes its registration so it can no longer be used to launch new instances, but by default it has no effect on the EBS snapshots that were created to back that AMI (or on any S3 files backing an instance-store-backed AMI); those snapshots continue to exist and continue to incur standard storage charges until someone deletes them separately, which is exactly the surprise this engineer ran into. The option assuming this must be a billing error is wrong because this is expected, documented behavior, not a mistake. The option describing an automatic 30-day grace period invents a mechanism that doesn't exist; there's no time-based automatic snapshot deletion tied to deregistering an AMI. The option tying continued charges to whether the AMI was shared with another account is also wrong: whether snapshot deletion is automatic has nothing to do with sharing status; deleting the snapshot is always a separate, manual step regardless of whether the AMI was ever shared.

Source: AWS EC2 documentation: Deregister an Amazon EC2 AMI — snapshot retention behavior

Correct answer: .

Copying an AMI to another Region produces an identical but fully independent target AMI with its own distinct AMI ID in that destination Region, and each of its supporting EBS snapshots is likewise copied to its own distinct target snapshot; because the copy is independent, changing or deregistering the source AMI afterward has no effect on the copy, and the reverse is true as well. The option claiming deregistering the source automatically deregisters the copy invents a dependency between source and copy that doesn't exist; once the copy completes, the two are managed entirely separately. The option claiming the copy shares the same AMI ID as the original is wrong because AMI IDs are Region-specific identifiers, not globally unique across Regions, so the copy always receives its own new ID in the destination Region. The option requiring the original to be deregistered before the copy can be used has the relationship backwards; the copy is independently usable as soon as its own status becomes available, regardless of what later happens to the source.

Source: AWS EC2 documentation: Copy an Amazon EC2 AMI — cross-Region copy creates an independent AMI

Correct answer: .

AWS's instance type naming convention encodes several independent pieces of information in a compact string: the leading letter identifies the instance family (for example, "m" for general purpose, "c" for compute optimized, "r" for memory optimized), the following number identifies the generation of that family, and additional letters appended before the size (such as "a" for AMD-based processors, "g" for AWS Graviton/Arm-based processors, or "n" for enhanced networking) describe optional processor or capability variants; the final component after the period, such as "large", specifies the instance's size within that type. This means "m6a.large" is a 6th-generation, general-purpose, AMD-based instance at the "large" size. The option claiming "m6a" only encodes vCPU count and that size determines instance family reverses which part of the name carries which meaning. The option claiming the number encodes core count and the trailing letter encodes a Region confuses generation numbering and processor-variant letters with concepts (exact core counts, Region availability) the instance type name doesn't directly encode at all. The option describing the name as encoding OS licensing and pricing model is wrong because neither of those is part of the instance type string; both are chosen separately at launch time.

Source: AWS documentation: Amazon EC2 instance types — instance type naming conventions

Correct answer: .

EBS-optimized instances provide dedicated bandwidth between an EC2 instance and its attached EBS volumes, separate from the instance's general network traffic, and while some older-generation instance types required explicitly enabling this feature (sometimes at an additional hourly charge), nearly all current-generation instance types, including those built on the Nitro System, are EBS-optimized by default at no extra cost, so this migrating team doesn't need to take any special action to get full EBS performance. The option claiming EBS optimization was deprecated is wrong; the capability is very much still present, it has simply become the default rather than an opt-in extra on modern instance types. The option insisting it must still be explicitly enabled and paid for on every instance type ignores exactly the default-and-free behavior that current-generation types now provide. The option claiming it's bundled into gp3 pricing confuses two independent things: EBS optimization is a property of the EC2 instance's dedicated network bandwidth to EBS, not a property or pricing feature of any particular EBS volume type.

Source: AWS EC2 documentation: Amazon EBS–optimized instances — default EBS optimization on Nitro-based instances

Correct answer: .

CloudWatch alarm-based recovery for EC2 does not support every instance uniformly: instances that use instance store volumes are ineligible (the recover option is grayed out for them because instance store data can't survive the underlying migration to new hardware that recovery performs), and separately, recovery is not supported for instances running with Dedicated Host tenancy or for bare-metal instance types, since both bypass the standard virtualized recovery path recovery depends on; only a defined subset of instance types and configurations actually support the action. The option claiming uniform support across the whole fleet ignores all three of these documented restrictions. The option claiming only bare-metal instance types are affected understates the restriction, since instance store volumes and Dedicated Host tenancy each independently disqualify an instance too. The option claiming only Dedicated Host tenancy is supported has it backwards: Dedicated Host tenancy is one of the configurations recovery does not support, not the one configuration it's designed around.

Source: AWS EC2 documentation: Recover your instance / Configure CloudWatch action-based recovery — instance store, Dedicated Host, and bare-metal restrictions

Correct answer: .

A Nitro Enclave is purpose-built for exactly this scenario: it's created by partitioning CPU cores and memory from a Nitro-based parent EC2 instance into an isolated virtual machine that has no persistent storage and no external network connectivity of its own, communicating with its parent instance solely over a local vsock channel, and it can produce a cryptographic attestation document, signed by the Nitro Hypervisor, containing measurements of the enclave's code that an external service such as AWS KMS can evaluate as a condition before authorizing a decryption operation. A second, ordinary EC2 instance in a private subnet with no internet route can restrict inbound and outbound internet access, but it still has persistent EBS storage, a full general-purpose OS a compromised process could tamper with, and no built-in mechanism to cryptographically attest its own code integrity to KMS. Dedicated Host tenancy only changes which physical server underlies an instance for licensing or compliance purposes; it says nothing about that instance's storage persistence, network isolation, or ability to attest its code. An Auto Scaling warm pool's pooled instances are simply stopped EC2 instances waiting to be activated; they still have persistent EBS storage and no attestation capability, and the lack of an active network path is only a temporary side effect of being stopped, not a designed security property.

Source: AWS Nitro Enclaves documentation: Nitro Enclaves concepts — enclave isolation and cryptographic attestation