Free DEA-C01 practice questions

Choosing between streaming and batch ingestion depends on how quickly data must be available. Real-time event capture with multiple independent consumers is the core Kinesis Data Streams use case.

Kinesis Data Streams ingests events as they occur and makes them readable by multiple consumers within seconds, matching both the latency and the fan-out requirement. Glue and daily S3 uploads are batch mechanisms that add minutes-to-hours of latency, and DMS is designed for database replication, not application-generated event streams.

1. Identify the latency requirement: data must be usable within seconds, which rules out batch services.
2. Identify the consumption pattern: several applications read the same events independently, which requires a durable, replayable stream rather than a queue that removes messages after one read.
3. Map the requirements to Kinesis Data Streams, which retains records for a configurable window and supports multiple consumers per stream.

Exam tip: When events must reach multiple consumers within seconds, ingest with Kinesis Data Streams, not a batch service.

Choosing a data store starts with the access pattern. Key-value lookups by a known key at massive scale with millisecond latency are the canonical use case for Amazon DynamoDB, a fully managed NoSQL database that partitions data automatically and scales horizontally.

The workload is defined by three signals: key-value shape, extreme throughput (millions of operations per second), and consistent single-digit millisecond latency. DynamoDB is engineered for exactly this profile — it distributes data across partitions by partition key and maintains predictable latency regardless of table size. Redshift and Athena are analytical engines where individual queries take seconds; RDS is relational and constrained by instance size for write throughput. None of the alternatives can meet the latency guarantee at the stated scale.

1. Identify the access pattern: always a lookup by session ID, which is a pure key-value read/write pattern.
2. Match the latency and scale requirement: consistent single-digit milliseconds at millions of requests per second rules out analytical stores and vertically scaled relational databases.
3. Select DynamoDB with the session ID as the partition key so requests spread evenly across partitions.

Exam tip: Key-value access by a known key with single-digit millisecond latency at any scale means DynamoDB.

Amazon MWAA is managed open-source Apache Airflow, which makes it the natural landing zone for teams that already have an Airflow investment they want to preserve.

The deciding constraint is the existing asset: 200 Python DAGs with custom operators and plugins. MWAA runs genuine Apache Airflow, so the team uploads DAGs to an S3 bucket, declares dependencies in requirements.txt, ships plugins in plugins.zip, and the code runs essentially unchanged while AWS operates the scheduler, workers, metadata database, and web server. Step Functions would force a full rewrite into Amazon States Language, Glue workflows only chain Glue-native components, and EventBridge Scheduler is a trigger mechanism rather than an orchestrator.

1. Identify the existing investment: Python DAGs, custom operators, and plugins that the team wants to keep.
2. Map that requirement to MWAA, the only AWS service that runs real Apache Airflow code.
3. Eliminate Step Functions (different workflow language), Glue workflows (Glue-only scope), and EventBridge Scheduler (triggering, not orchestration).

Exam tip: When a scenario mentions existing Airflow DAGs that must be preserved, the answer is Amazon MWAA.

IAM roles for EC2 replace long-term access keys with temporary credentials that AWS delivers and rotates automatically through the instance metadata service.

Attaching an IAM role via an instance profile is the AWS-recommended way for code on EC2 to obtain credentials. The AWS SDKs and CLI automatically retrieve short-lived credentials from the instance metadata service and refresh them before expiry, so nothing static is stored on disk. The distractors all keep long-term IAM user keys alive somewhere - rotating or encrypting a long-term key is strictly worse than not having one at all.

1. Create an IAM role with a trust policy allowing the EC2 service to assume it and a permissions policy granting the needed S3 access.
2. Attach the role to the instances as an instance profile.
3. Remove the access keys from the configuration file and delete or deactivate the IAM user's keys so they can no longer be used.

Exam tip: Compute that runs on AWS should authenticate with an IAM role, never with stored long-term access keys.

Kinesis Data Streams offers two capacity modes: provisioned, where you manage shard counts, and on-demand, where AWS scales throughput automatically based on observed traffic.

On-demand mode is designed for unpredictable or spiky workloads and eliminates shard capacity management, directly satisfying the least-operational-overhead constraint. Manual splitting is reactive and labor-intensive, static over-provisioning is wasteful, and moving to SQS changes the streaming semantics without solving the capacity-management problem.

1. Recognize the workload profile: unpredictable traffic with sudden large spikes.
2. Note the explicit constraint: the team does not want to manage shard capacity.
3. Select on-demand capacity mode, which scales automatically and bills per data volume rather than per provisioned shard.
4. Remember that a stream can be switched between provisioned and on-demand modes without downtime.

Exam tip: For unpredictable or spiky Kinesis workloads where nobody wants to manage shards, choose on-demand capacity mode.