Free DEA-C01 practice questions

Kinesis Data Streams is a retained, multi-consumer stream; Firehose is delivery only, SQS is a competing-consumer queue, and SNS standard topics deliver only to current subscribers.

Two requirements decide it: every application reads every event independently, and a consumer added later must read events from earlier in the day. A Kinesis data stream keeps records for its retention period regardless of consumption, so any number of consumers read the same data at their own positions and a new one can start from the oldest retained record. SNS plus SQS meets the first requirement but not the second, a shared SQS queue meets neither, and Firehose exposes no read API at all.

1. Note the latency (seconds) and that every application needs every event.
2. Note the late-joining consumer: it needs events that were published before it existed.
3. Eliminate designs without retention a new reader can rewind into (SNS, SQS, Firehose).
4. Choose the retained multi-consumer stream: Kinesis Data Streams.

Exam tip: Many independent readers plus a late joiner that needs past events means a retained stream, not a queue, topic or delivery stream.

The access pattern picks the store. Known-key reads and writes at very high request rates with predictable latency are the DynamoDB use case; durability and serverless operations narrow it further.

Three constraints decide. Known-key access at millions of requests per second with consistent single-digit-millisecond latency rules out relational engines, which funnel writes through one writer. "Every acknowledged write must survive" rules out a cache, because ElastiCache replicates asynchronously. "No servers or capacity to manage" with traffic that swings from near zero to peak is what DynamoDB on-demand mode is for. On-demand instantly absorbs up to double a table's previous peak, so for a planned jump far beyond earlier traffic you set warm throughput in advance rather than managing capacity units. Aurora Serverless v2 is the tempting answer because it is serverless and durable, but it is still a single-writer relational database.

1. Identify the access pattern: every read and write is by session ID, a pure key/value pattern.
2. Apply the scale and latency requirement: millions of writes per second at single-digit milliseconds excludes single-writer relational engines.
3. Apply the durability requirement: a cache with asynchronous replication can lose acknowledged writes.
4. Apply the operations constraint: on-demand capacity removes capacity planning for spiky traffic.

Exam tip: Key/value access at any scale with durable writes and no capacity planning means DynamoDB on-demand; a cache is not a system of record and a relational writer does not scale out writes.

Orchestrating a multi-step pipeline means waiting for long-running jobs, retrying and routing failures, and keeping a record of each run. The orchestrator that does all of that without paying for idle time is serverless Step Functions with the run-a-job integration.

Two of the options remove the timeout, but the constraints decide. EventBridge chaining is serverless and idle-free, yet it has no notion of a run, so there is no single inspectable record and no declarative failure branch across steps. A provisioned MWAA environment provides all the orchestration features but bills per environment-hour, including while idle. A self-reinvoking Lambda only moves the polling problem around. A Step Functions Standard workflow with the Glue startJobRun.sync integration waits natively for the job, attaches Retry and Catch to each state, records every execution's history, and charges per state transition, so it is the only option that meets every requirement.

1. List the requirements: wait for long jobs, per-step retries, a failure branch, one record per run, no idle cost.
2. Rule out options that are still hand-written orchestration (polling or self-reinvoking Lambda).
3. Check the event-driven chain against 'one record per run' and the provisioned Airflow environment against 'nothing billed while idle'.
4. Choose the serverless orchestrator whose .sync integration waits for the job without paid polling.

Exam tip: When a Lambda function is polling a long job, the fix is Step Functions with the .sync integration, not a longer or self-chaining function.

Workloads that run on AWS compute should authenticate with an IAM role. For EC2, the role is attached through an instance profile and the SDKs fetch short-lived credentials from the instance metadata service, refreshing them before they expire.

The review rules out long-term credentials entirely, so the fix must both supply a replacement identity and remove the old one. The instance profile supplies temporary credentials that AWS rotates for you; deleting the IAM user's access keys removes the long-term credential. Storing the keys in Secrets Manager or Parameter Store protects them at rest but they remain long-term keys. The near-twin that attaches the role but keeps rotating the user's keys still leaves a long-term credential behind.

1. Identify the requirement: no long-term credentials for this workload, not merely better-protected ones.
2. Recall that IAM user access keys are long-term however they are stored or rotated.
3. Choose the option that gives the instances a role (temporary credentials) and removes the keys.

Exam tip: Protecting or rotating an access key is not the same as removing it: compute on AWS should use a role, with no user keys left behind.

Kinesis Data Streams has two capacity modes: provisioned (you choose and change the shard count) and on-demand (AWS scales shards with traffic).

The deciding constraint is that nobody wants to plan or change capacity. On-demand mode removes shard management entirely. Alarm-driven UpdateShardCount and peak sizing both keep provisioned mode, so someone still forecasts or automates capacity, and MSK provisioned adds broker management.

1. Identify the workload: unpredictable traffic with no capacity planning wanted.
2. Compare provisioned options: both still require choosing or automating a shard count.
3. Pick the mode in which AWS manages shards: on-demand.

Exam tip: Unpredictable traffic and no shard management means Kinesis on-demand capacity mode.