DEA-C01 Data Operations and Support Practice Question

Exhibit

Refer to the exhibit.

CloudFormation template snippet:
"MyTable": {
  "Type": "AWS::DynamoDB::Table",
  "Properties": {
    "TableName": "Orders",
    "AttributeDefinitions": [
      {"AttributeName": "OrderID", "AttributeType": "S"}
    ],
    "KeySchema": [
      {"AttributeName": "OrderID", "KeyType": "HASH"}
    ],
    "ProvisionedThroughput": {
      "ReadCapacityUnits": 5,
      "WriteCapacityUnits": 5
    }
  }
}

A data engineer creates an Amazon DynamoDB table using the CloudFormation snippet in the exhibit. The application writes 200 items per second to the table. The engineer notices that many write requests are being throttled. What is the MOST likely reason?

⚠ Common exam trap

DEA-C01 often tests the misconception that missing sort keys or attribute types cause throttling, when the primary cause is insufficient provisioned capacity or hot partitions due to poor partition key design.

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

✓

The provisioned write capacity is too low for the application's write rate.

The DynamoDB table is provisioned with a fixed write capacity, and the application writes 200 items per second. If the provisioned write capacity units (WCUs) are less than required, throttling occurs. Each write of an item up to 1 KB consumes 1 WCU, so 200 writes per second require at least 200 WCUs. If the table's provisioned write capacity is below this, requests will be throttled.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
The table does not have a sort key, causing hot partitions.
Why it's wrong here
A partition key alone does not create hot partitions; throttling here stems from the provisioned write capacity being below the 200 writes per second offered. A sort key spreads items within a partition, so it is the right design when range queries over a composite key are required, not for this capacity shortfall.
✗
The attribute type for OrderID should be numeric for better performance.
Why it's wrong here
DynamoDB attribute types do not affect write throughput or partition distribution; a numeric OrderID consumes the same capacity units as a string one. Numeric types are chosen when arithmetic or range comparisons on the attribute are needed, not to relieve throttling caused by insufficient provisioned capacity.
✗
The table name 'Orders' conflicts with an existing table.
Why it's wrong here
DynamoDB table names must be unique per region and account, so a conflicting name would make CloudFormation creation fail outright rather than throttle writes. Renaming is the correct action when a stack needs to coexist with an existing table, not when an existing table is being written to.
✓
The provisioned write capacity is too low for the application's write rate.
Why this is correct
Provisioned write capacity is set below the 200 items per second the application writes, so DynamoDB throttles excess requests once consumed capacity units are exhausted. DynamoDB rejects writes exceeding the table's provisioned WCU rather than queuing them, making insufficient capacity the direct cause of the throttling observed.

Go deeper

DEA-C01 Data Operations and Support Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question