DEA-C01 Data Operations and Support Practice Question

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 Glue job's checkpointing is disabled, so it restarts from the beginning each time it runs.

  Why it's wrong here

  Checkpointing in Glue for Kinesis tracks the last processed record to avoid reprocessing. If disabled, the job might start from the configured starting position each time. However, the scenario states the job is reprocessing old data, which is directly controlled by the starting position. Checkpointing is not the primary cause here.

• ✓

  The Glue job is configured with the starting position 'TRIM_HORIZON', which reads all available records from the beginning of the stream.

  Why this is correct

  In AWS Glue, when reading from Kinesis, you can specify the starting position. 'TRIM_HORIZON' means the job starts reading from the oldest record in the stream. If the job is reprocessing old data, this setting is likely the cause. Changing to 'LATEST' would start from new records.

• ✗

  The Kinesis stream has multiple shards, and the Glue job is not parallelizing reads across all shards, causing it to reread from one shard.

  Why it's wrong here

  Glue automatically parallelizes reads across shards based on the number of workers. Lack of parallelization would cause slow processing, not reprocessing of old data. The issue described is about starting position, not shard distribution. This option does not address the root cause.

• ✗

  The Glue job's bookmarking is enabled, causing it to track processed records and reprocess them if the job fails.

  Why it's wrong here

  Job bookmarks are used to track data processed from sources like S3, not Kinesis. For Kinesis, Glue uses starting position and checkpointing in the stream. Bookmarks would not cause reprocessing of old data; they prevent reprocessing. Thus, this is not the cause.

Go deeper

Related to this question