DOP-C02 Resilient Cloud Solutions Practice Question
A company has a critical application running on EC2 instances in an Auto Scaling group across two Availability Zones. The application uses an EBS volume for local caching. The company wants to ensure that if an instance fails, the cache data is not lost and the replacement instance can use it. Which solution meets this requirement?
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Use Amazon EFS instead of EBS for the cache
Amazon EFS is a regional, shared file system that can be mounted by EC2 instances across multiple Availability Zones. This ensures that cache data persists independently of instance lifecycle, so if an instance fails, a replacement instance can mount the same EFS file system and access the cached data without loss. Option A is incorrect because an EBS volume can only be attached to one instance at a time (except with Multi-Attach, which is limited to the same AZ) and is tied to a specific Availability Zone, making it unsuitable for an Auto Scaling group spanning two AZs. Additionally, automatically attaching a specific existing volume to new instances is not a standard Auto Scaling feature. Option B is incorrect because periodic snapshots are not real-time; data written between snapshots would be lost, and creating a new volume from a snapshot does not provide continuous access to the latest cache. Option C is incorrect because EBS Multi-Attach volumes can only be attached to instances within the same Availability Zone, so they cannot serve instances in both AZs of the Auto Scaling group.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Configure the Auto Scaling group to use a launch template that attaches the same EBS volume to new instances
Why it's wrong here
Configuring the Auto Scaling group to use a launch template that attaches the same EBS volume to new instances is invalid because an EBS volume is a block-device resource bound to a single instance within one Availability Zone. A launch template's block device mappings can specify a snapshot or a new volume, not a previously existing volume ID; even if manually attached, the volume could serve only one instance at a time, creating an unavailability window and preventing scale-out beyond a single node. Thus this approach cannot provide a shared, persistent cache across the ASG.
- ✗
Take periodic EBS snapshots and create a new volume from the snapshot for the replacement instance
Why it's wrong here
Taking periodic EBS snapshots and creating a new volume for the replacement instance suffers from the inherent staleness of snapshot-based recovery. A snapshot captures the volume state at a single upstream point, so any cache entries written after the last snapshot are permanently lost, leading to cache misses and potential inconsistencies. Moreover, provisioning a new volume from a snapshot is a heavyweight operation that does not scale to multiple instances and defeats the purpose of an instantly available shared cache.
- ✗
Use an EBS Multi-Attach volume and attach it to all instances in the Auto Scaling group
Why it's wrong here
Using an EBS Multi-Attach volume for all instances in the Auto Scaling group is unsuitable because Multi-Attach is limited to Provisioned IOPS volumes (io1/io2) and can only attach to up to 16 instances in the same Availability Zone. An Auto Scaling group commonly spans multiple AZs for high availability, and Multi-Attach volumes reside in a single AZ, making the cache a single-affinity failure domain. Additionally, without a cluster-aware file system, multiple instances writing to the same raw block device would corrupt data.
- ✓
Use Amazon EFS instead of EBS for the cache
Why this is correct
Amazon EFS is the correct choice because it provides a fully managed NFS file system that is regional by default, with mount targets in every AZ to deliver continuous shared access. Cache data written to EFS persists independently of any individual EC2 instance, so when an instance fails and is replaced, the new instance simply mounts the same file system and immediately has the full cache. It also scales automatically and supports concurrent access from many instances, making it the only viable shared, cross-AZ cache service among these options.
Go deeper
Related to this question
About these practice questions
One of 1,013 original DOP-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DOP-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DOP-C02 exam.