DEA-C01 sample questions — 25 answered and explained

S3 can publish object events to Amazon EventBridge, which adds content-based filtering on event fields, many targets per event, and archive and replay.

Three requirements point to EventBridge: a Glue workflow target, filtering beyond prefix and suffix (object size), and re-delivering past events (archive and replay). Native S3 notifications cannot target Glue or replay, SNS cannot deliver to a Glue workflow and has no archive on standard topics, and a relay Lambda adds code without solving filtering or replay.

1. List the targets: Glue workflow, Lambda, SQS.
2. List the extras: filtering on object size and re-delivery of past events.
3. Eliminate S3-notification designs: prefix/suffix filters only and no archive.
4. Choose EventBridge notifications with rules and an archive.

Exam tip: Many targets, rich filters or replay for S3 events means EventBridge notifications, not plain S3 Event Notifications.

For a Kinesis event source mapping, concurrent invocations equal shards multiplied by the parallelization factor (default 1, maximum 10).

Four concurrent executions on four shards shows the mapping is processing one batch per shard. Raising the parallelization factor is the only option that adds concurrency without resharding. Reserved concurrency does not change how the mapping reads shards, enhanced fan-out speeds reads rather than processing, and a longer batching window adds delay.

1. Read the symptom: concurrency equals the shard count and iterator age grows.
2. Recall that the mapping runs one batch per shard unless the parallelization factor is raised.
3. Since shards cannot be added, raise the parallelization factor.

Exam tip: Kinesis-to-Lambda concurrency = shards x parallelization factor; reserved concurrency does not raise it.

A failing batch on a stream event source mapping blocks its shard until it succeeds or expires; bisecting, bounding retries and an on-failure destination isolate and divert poison records.

All three controls are needed together. Bisect on error narrows the failure to the bad record, maximum retry attempts (or maximum record age) stops the retries, and an on-failure destination (SQS, SNS or S3) keeps details of what was skipped. Leaving retries unlimited still blocks the shard, skipping bisect discards good records, and a function DLQ does not apply to stream invocations.

1. Identify the problem: one poison record blocks the shard through endless retries.
2. Isolate the record: bisect batch on function error.
3. Bound the retries: maximum retry attempts or maximum record age.
4. Keep the evidence: an on-failure destination on the event source mapping, not a function DLQ.

Exam tip: For poison records on a Kinesis-to-Lambda mapping: bisect on error, cap retries, and set an on-failure destination on the mapping.

A Kinesis event source mapping invokes when the batch size is reached, the batching window expires, or the payload reaches 6 MB; with a window of 0 it invokes as soon as records arrive.

The batch size is already larger than what arrives, so the limiting setting is the batching window. Setting it to 60 seconds (within the allowed delay) lets each invocation carry far more records. Raising the batch size alone changes nothing at a low arrival rate, and parallelization or enhanced fan-out increase invocations or cost.

1. Notice that batches are tiny even though batch size allows 100 records.
2. Recall that with a batching window of 0 Lambda invokes as soon as any records are available.
3. Use the allowed delay: raise the maximum batching window.

Exam tip: At low record rates, batch size alone does not batch; the batching window does.

Kinesis assigns each record to a shard by hashing its partition key; a low-cardinality key concentrates traffic on a few shards (hot shards).

Throttling on the same shards while total capacity is unused is the signature of a hot shard. Country codes are few and skewed, so the biggest countries hash to the same shards. A high-cardinality key spreads writes. More shards, enhanced fan-out and PutRecords batching all leave the skew in place.

1. Read the symptom: throttling on specific shards, aggregate capacity unused.
2. Inspect the partition key: country codes have low cardinality and skewed volumes.
3. Fix the distribution with a high-cardinality key, not more capacity.

Exam tip: Throttled shards with spare total capacity point to a low-cardinality partition key; fix the key, not the shard count.

When bursts exceed a store's write capacity and some delay is acceptable, a durable queue in front of the store levels the load.

The constraints rule out the easy fixes: the table stays provisioned, and peak provisioning wastes money. Auto scaling is too slow for a sudden burst, and DAX does not reduce write consumption because it writes through to the table. An SQS buffer stores the burst and lets a consumer write at a steady rate within the 30-minute tolerance.

1. Note the fixed constraints: provisioned mode, short sudden bursts, delay tolerated.
2. Reject auto scaling (too slow for sudden bursts) and DAX (writes still hit the table).
3. Reject peak provisioning on cost.
4. Use the delay tolerance: buffer with SQS and write at a controlled rate.

Exam tip: Short write bursts plus tolerated delay: buffer in SQS and drain at a set rate; DAX does not absorb writes and auto scaling is too slow for spikes.

Standard (shared-throughput) consumers share each shard's 2 MB/s and five GetRecords calls per second; enhanced fan-out gives each registered consumer a dedicated 2 MB/s per shard via push.

Throttling that started as consumers were added shows the shared per-shard read limits are the bottleneck. Enhanced fan-out gives every application its own throughput and push delivery. More shards leave the per-shard call limit shared, faster polling worsens throttling, and copying to per-application streams adds hops and operations.

1. Read the trigger: throttling began as more polling consumers were added.
2. Recall that polling consumers share per-shard read limits.
3. Give each consumer dedicated throughput: enhanced fan-out.

Exam tip: Several low-latency consumers on one stream means enhanced fan-out, not more shards.

Consuming a rate-limited data API means pacing requests below the limit and retrying throttled calls with capped exponential backoff and jitter.

HTTP 429 means "too many requests", a transient condition. Pacing the workers to the documented rate prevents most 429s, and exponential backoff with jitter spreads the rest so parallel workers do not retry together. Immediate retries and fixed pauses keep hitting the limit, and backoff without jitter keeps the workers synchronised.

1. Classify HTTP 429 as transient throttling, not a fatal error.
2. With parallel workers, add jitter so retries do not synchronise.
3. Pace requests to the documented limit so throttling is the exception.

Exam tip: For rate-limited APIs: pace to the limit, then retry with exponential backoff plus jitter.

Replay needs a service that retains records after they are consumed: Kinesis Data Streams (retention up to 365 days) and Kafka on Amazon MSK (per-topic retention with consumer offsets).

Kinesis and MSK both decouple retention from consumption, so a fixed consumer can rewind to a timestamp or offset. SQS retention covers only undeleted messages, SNS standard topics keep nothing, and Firehose only delivers.

1. Define the need: re-read already processed events from days ago.
2. Separate retention-until-consumed (SQS) from retention-regardless-of-consumption (Kinesis, Kafka).
3. Select the two log-style services: Kinesis Data Streams and Amazon MSK.

Exam tip: Replay requires a retained log: Kinesis Data Streams or Kafka on MSK, not a queue, topic or delivery stream.

Apache Iceberg gives S3 data-lake tables atomic, isolated commits through snapshot metadata, so concurrent writers and readers stay consistent, and every snapshot can be queried later.

Both symptoms point to missing table semantics: no atomic commit (half-written results) and no table history (point-in-time audit queries). Iceberg supplies both through its snapshot metadata layer, and Athena supports Iceberg reads, DML and time travel. S3 Versioning works per object, bookmarks track job input, and serialized writers still expose partial output.

1. Read the two symptoms: partial results during writes, and a need for historical queries.
2. Recognize that both require table-level snapshots, not object-level or job-level features.
3. Match snapshot-based ACID tables to Apache Iceberg.
4. Convert the dataset to an Iceberg table that Athena and Glue both support.

Exam tip: Concurrent writers, consistent readers and as-of queries on S3 data: an Apache Iceberg table.

Every Iceberg commit creates a snapshot. Time travel (FOR TIMESTAMP AS OF / FOR VERSION AS OF in Athena) reads an old snapshot without changing anything; rollback changes the current table state.

The snapshot from before the corrections still exists (snapshots are kept 30 days and the corrections were last week), so a time-travel query reproduces the report exactly. Rollback is the tempting near-twin because it also returns to the old snapshot, but it changes what every reader sees. Object version restores and catalog table versions do not represent Iceberg table state.

1. Confirm the old snapshot still exists: last week is inside the 30-day retention.
2. Separate reading history from changing the table: other teams must keep the corrections.
3. Choose a read-only time-travel query by timestamp or snapshot ID.
4. Reject rollback, which rewrites the current state.

Exam tip: Read the past with time travel; rollback changes the present for everyone.

Redshift DDL such as ALTER TABLE needs an AccessExclusiveLock, so it waits behind any open transaction on the table. You find the holder in the lock and transaction system views and end its session with PG_TERMINATE_BACKEND.

Two facts combine. First, the blocker is an idle, uncommitted transaction, and the lock views identify its process ID. Second, cancelling and terminating differ: PG_CANCEL_BACKEND stops a running query, and an idle session has none, while PG_TERMINATE_BACKEND ends the session and rolls back its transaction. Rebooting releases the lock too but interrupts everything, which the stem forbids.

1. Recognize that the ALTER TABLE needs an exclusive lock and waits for open transactions.
2. Identify the blocking process ID in STV_LOCKS or SVV_TRANSACTIONS.
3. Note the blocker is idle in a transaction, so cancelling a query will not help.
4. Terminate that one session with PG_TERMINATE_BACKEND, leaving the rest of the cluster running.

Exam tip: Idle transaction holding a Redshift lock: find its pid in the lock views and terminate the session; cancel only stops running queries.

AWS Transfer Family provides managed SFTP, FTPS, FTP and AS2 endpoints backed by S3 or EFS, so partners keep their file-transfer protocol while files land directly in the data lake.

The deciding constraint is the protocol: partners can only push over SFTP. Transfer Family is the managed SFTP endpoint backed by S3. DataSync, Transfer Acceleration and File Gateway all move data into S3, but over agents, HTTPS or NFS/SMB respectively. Once files land, S3 Event Notifications or EventBridge start the Glue job.

1. Note the protocol constraint: SFTP with SSH keys, pushed by external partners.
2. Note the operations constraint: fully managed, no file servers.
3. Match a managed SFTP endpoint backed by S3 to AWS Transfer Family.
4. Trigger the Glue job from the S3 upload event.

Exam tip: Partners that only speak SFTP into S3, no servers: AWS Transfer Family.

Transactional (OLTP) workloads with normalized schemas, foreign keys and multi-table transactions belong in a relational engine such as RDS or Aurora.

Every requirement is relational: multi-table ACID transactions, enforced foreign keys, and ad hoc joins on small, frequent reads and writes. Aurora MySQL provides all of them. DynamoDB transactions and Iceberg commits are both ACID, which makes them tempting, but neither enforces foreign keys or serves relational OLTP; Redshift is analytical.

1. Classify the workload: many small reads and writes per request, so OLTP.
2. List the relational requirements: cross-table ACID, foreign keys, joins.
3. Reject stores that offer ACID but no relational constraints.
4. Choose a relational engine such as Aurora MySQL.

Exam tip: ACID plus foreign keys plus joins on small transactional writes is a relational OLTP database; "ACID" alone does not mean relational.

Apache Iceberg adds table semantics to S3 files through a snapshot metadata layer: atomic commits with snapshot isolation, row-level changes, metadata-only schema evolution, hidden partitioning and time travel. It still needs maintenance such as compaction and snapshot expiry.

Schema evolution and atomic commits are both delivered by Iceberg's metadata layer. The distractors are common misconceptions: Iceberg uses column statistics for pruning but not indexes, does not remove the need for compaction, and has no row TTL.

1. Recall what plain Parquet lacks: atomic commits, safe schema changes, row-level changes, history.
2. Map Iceberg's snapshot metadata to atomic commits and column-ID-based schema evolution.
3. Reject features Iceberg does not provide: indexes, automatic compaction, row TTL.
4. Select metadata-only schema evolution and atomic commits.

Exam tip: Iceberg = ACID snapshots, schema evolution, row-level changes and time travel on S3; it is not an index, and it still needs compaction.

DynamoDB fits access by a known key at high scale. It is a poor fit for ad hoc attribute filtering, joins and foreign keys, and objects larger than its 400 KB item limit.

The shopping cart and device state are both accessed by a known key at scale, DynamoDB's core pattern. Each distractor hits one specific limit: ad hoc filters need scans, large files exceed the item size limit, and relational ledgers need joins and foreign keys.

1. For each workload, ask whether every access uses a known key.
2. Check item size against the 400 KB limit.
3. Check for joins, foreign keys or arbitrary filters.
4. Select the two known-key workloads.

Exam tip: DynamoDB: known-key access at scale; not ad hoc filters, joins, or large objects.

EventBridge Pipes connects a point-to-point source such as a DynamoDB stream, Kinesis stream or SQS queue to a target, with optional filtering and an enrichment step in between.

Two facts combine. DynamoDB Streams is a polled source, not a publisher to the event bus, so an EventBridge rule cannot see its records; and event source mappings are a Lambda feature, so a state machine cannot consume the stream directly. A Lambda event source mapping would work, but the function would need code to start the state machine. A pipe does the polling, filtering on eventName, Lambda enrichment and delivery to Step Functions as managed configuration.

1. Note the source: a DynamoDB stream, which must be polled rather than published to a bus.
2. Rule out a bus rule (stream records never reach the bus) and a state-machine event source mapping (Lambda only).
3. Compare the Lambda event source mapping with a pipe against the no-forwarding-code constraint.
4. Choose an EventBridge pipe with a filter, the Lambda enrichment and the state machine target.

Exam tip: Stream or queue source, filter, enrich, then deliver to a target with no glue code: that is EventBridge Pipes.

Steps are Amazon EMR's native unit of automated work. With the default step concurrency of 1 they run in order, and each step's ActionOnFailure decides what happens to the remaining steps and to the cluster.

Submitting the applications as steps gives ordered execution and a recorded status for each. The failure behaviour picks the setting: CONTINUE runs the next step anyway, TERMINATE_CLUSTER stops the work by shutting down a cluster that analysts need, and CANCEL_AND_WAIT cancels the pending steps and keeps the cluster waiting. Cron on the primary node has no dependency on success at all.

1. Use EMR steps for ordered, tracked work on an existing cluster.
2. List the failure requirements: stop later applications and keep the cluster running.
3. Map them to ActionOnFailure values: CONTINUE (keeps going), TERMINATE_CLUSTER (shuts down), CANCEL_AND_WAIT (cancels pending steps, cluster stays).
4. Choose CANCEL_AND_WAIT.

Exam tip: On a shared EMR cluster, chain steps with ActionOnFailure CANCEL_AND_WAIT to stop the chain on failure without terminating the cluster.

MWAA installs Python dependencies from a requirements.txt file referenced by its S3 object version, when workers and schedulers start. The pip output is published to CloudWatch Logs.

Two separate facts produce this symptom. Uploading a new requirements.txt does not change a running environment, because the environment is pinned to an object version; it must be updated to the new version, which restarts components and reinstalls packages. Even after that, pip can fail (for example a version conflict with Airflow's constraints), and the requirements_install log streams in the scheduler log group show it. Placing the file under dags/, re-parsing DAGs or resizing the environment does not install a missing module.

1. Read the symptom: DAGs parse, tasks fail with ModuleNotFoundError, so the package is missing on the workers.
2. Check that the environment references the newly uploaded requirements.txt object version, and update it if not.
3. Open the scheduler log group's requirements_install log streams to confirm pip installed the package without errors.
4. Fix any reported conflict, test in a staging environment, and rerun a failed task.

Exam tip: A new MWAA dependency needs an environment update to the new requirements.txt version, and the install logs tell you whether pip succeeded.

EventBridge Scheduler is a dedicated scheduling service that adds one-time schedules, time zones with daylight saving handling, flexible time windows, and per-schedule retry policies and dead-letter queues on top of what scheduled rules offer.

Scheduled rules evaluate cron and rate expressions in UTC and only recur. Scheduler adds one-time at() schedules (which can delete themselves after running) and time-zone-aware cron that follows daylight saving changes. Invoking Lambda or Step Functions is common to both, while event-pattern matching and delivery to another account's event bus belong to rules.

1. Separate the two jobs: rules match events on a bus; Scheduler runs things on a timetable.
2. Recall the scheduled-rule limits: UTC cron and rate, recurring only.
3. Pick what Scheduler adds: one-time schedules and named time zones.
4. Discard features both share (Lambda and Step Functions targets) and features of rules (patterns, cross-account buses).

Exam tip: Use EventBridge Scheduler when a schedule needs a local time zone or should run only once; rules are for matching events.

The Amazon Redshift Data API lets serverless code run SQL against Redshift over HTTPS: asynchronous, authenticated through IAM with temporary credentials or a Secrets Manager secret, and with no driver, connection or VPC networking on the caller's side.

Moving from JDBC changes two things in the design. Calls are asynchronous, so code must keep the statement Id and poll DescribeStatement or react to the completion event before fetching results. Authentication moves to IAM, with database access through temporary credentials or a Secrets Manager secret. The other statements describe JDBC-era concerns (connection pools, VPC placement) or an invented restriction on statement types.

1. Remember that Data API calls return immediately with a statement Id.
2. Plan for status checks (DescribeStatement) or completion events before reading results (GetStatementResult).
3. Grant the function IAM permission and choose temporary credentials or a Secrets Manager secret for database access.
4. Drop the JDBC-only concerns: drivers, connection pools and VPC attachment.

Exam tip: The Redshift Data API is asynchronous and IAM-authenticated: keep the statement Id, and forget drivers, pools and VPC wiring.

Security group rules can name another security group as the source instead of an IP range. The rule then matches any network interface that carries that group, so membership, not addresses, decides access.

Two requirements decide: IPs change constantly, and the subnets contain other servers. Referencing the application tier's security group handles both. A subnet CIDR survives IP churn but admits the batch servers; a self-referencing rule admits the wrong group; and an outbound rule on the client side does not create the inbound permission the cluster needs.

1. Note the two constraints: changing IPs and shared subnets.
2. Rule out IP-based sources: per-instance IPs churn and subnet CIDRs over-admit.
3. Use the application tier's security group as the inbound source on the Redshift port.

Exam tip: Reference a security group, not IPs, when the clients scale or share subnets with others.

Security groups are stateful: once a connection is allowed in one direction, its return traffic is allowed automatically. Network ACLs are stateless and need rules for both directions.

Removing every outbound rule stops connections the instance starts, but not replies to connections someone else started and an inbound rule allowed. Connection tracking handles those replies. A permissive network ACL does not override the security group, no hidden outbound rule is created, and an interface never falls back to the default security group.

1. Note who started the connection: the partner (inbound).
2. Recall that security groups track connections and permit their return traffic.
3. Contrast with network ACLs, which are stateless and need explicit return rules.

Exam tip: Security group: stateful, replies allowed. Network ACL: stateless, replies need a rule.

S3 Access Points are named network endpoints attached to a bucket, each with its own access point policy. The bucket policy delegates access control to the access points, so each application or team gets an independently managed policy.

The requirements are separate per-team policies, cross-account consumers, and no copies. Access points meet all three: each team gets an access point and policy, and the bucket policy needs only one statement delegating to access points owned by the account. Identity policies alone fail for the other accounts, Multi-Region Access Points solve multi-Region routing rather than per-team policy, and per-team buckets copy data.

1. List the constraints: per-team policy, cross-account teams, no data copies.
2. Pick the S3 feature that adds a separate policy per consumer on one bucket: access points.
3. Delegate access control from the bucket policy to the access points.

Exam tip: One bucket, many consumers, separate policies: an access point per consumer with bucket-policy delegation.

A Lambda function acts with the permissions of its execution role. Lambda assumes the role and supplies temporary credentials to the runtime, where the SDK default credential provider finds them.

The function needs an identity that can call DynamoDB. The execution role is that identity: the SDK picks up its temporary credentials with no code change. The resource-based policy is the tempting near-twin, but it works in the other direction, deciding who may invoke the function. The access-key options would work technically but use long-term user credentials where a role is the designed mechanism.

1. Ask which identity the function runs as: its execution role.
2. Distinguish the execution role (what the function can do) from the resource-based policy (who can invoke it).
3. Grant dynamodb:GetItem on the table to the execution role.

Exam tip: Execution role = what the function can call; resource-based policy = who can call the function.