Amazon Web Services Updated DVA-C02 Exam Questions and Answers by avery

On Amazon ECS, the fundamental scheduling unit is a task, which is launched from a task definition. A single task definition can include multiple containers that are intended to run together (often called a “sidecar” pattern). When two containers must share data locally—such as an application container writing log files and a separate log/metrics collector container reading those files—the recommended approach is to place both containers in the same task definition and use a shared task volume.

ECS supports defining volumes at the task level (for example, a Docker volume or bind mount depending on the launch type and configuration), and then mounting that volume into multiple containers inside the same task. Because the containers are co-located by ECS scheduling (same task, same underlying host or Fargate environment), they can safely share the mounted directory for file-based handoff. This design keeps the containers tightly coupled for lifecycle management (start/stop together) and avoids cross-task coordination complexity.

Options A and D refer to “pod specifications,” which are Kubernetes concepts, not ECS-native constructs (unless using ECS with EKS/Kubernetes, which is not stated). Option B is not feasible because ECS does not mount a single shared local volume across two separate tasks in the general case; separate tasks can be placed on different hosts, and task-scoped volumes are not shared between tasks by default. If cross-task sharing were required, you would typically use a network filesystem (like EFS) or an external log pipeline (CloudWatch Logs, FireLens, etc.), but the requirement explicitly says each application container needs to share data with another container, which aligns with the sidecar-in-same-task pattern.

Therefore, the correct solution is C: define both containers in one ECS task definition and mount a shared volume into both containers.

The solution that will meet the requirements is to write data to Amazon ElastiCache. This way, the application can write session data to a fast, scalable, and reliable in-memory data store that can be served reliably across multiple requests. The other options either involve writing data to persistent storage, which is slower and more expensive than in-memory storage, or writing data to the root filesystem, which is not shared among multiple EC2 instances.

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/access-control-overview.html#access-control-resource-ownership

Why Option C is Correct:Implementing a connection pool in the Redis client reduces connection overhead and avoids frequent connection establishment, which helps to reduce latency and connection failures.

Why Other Options are Incorrect:

Option A: Exponential backoff retry strategies help with transient failures but do not resolve latency caused by frequent connection establishment.

Option B: Storing scores in application memory adds complexity and risks inconsistency.

Option D: Adding more nodes is unnecessary unless the cluster is under heavy load. Latency due to connection failures is better addressed at the application level.

AWS Documentation References:

Amazon ElastiCache Best Practices