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.

• ✗

  Configure the Glue job itself to retry on failure by setting the 'MaxRetries' parameter in the job definition.

  Why it's wrong here

  AWS Glue jobs do have a 'MaxRetries' parameter, but it does not support exponential backoff; it simply retries the job after a fixed interval. Additionally, the scenario is about orchestrating with Step Functions, so the retry logic should be at the Step Functions level to maintain visibility and control. Relying on Glue's built-in retries would not meet the exponential backoff requirement.

• ✓

  Add a 'Retry' field with 'MaxAttempts': 3, 'IntervalSeconds': 2, and 'BackoffRate': 2.0 to the task state.

  Why this is correct

  'Retry' with 'MaxAttempts': 3, 'IntervalSeconds': 2, and 'BackoffRate': 2.0 implements exponential backoff retries. The task will retry up to three times, with delays of 2, 4, and 8 seconds. This matches the requirement for exponential backoff and is the correct configuration for Step Functions.

• ✗

  Use a 'Parallel' state to run the Glue job multiple times simultaneously and take the first successful result.

  Why it's wrong here

  Running the job in parallel would cause multiple concurrent executions, which could lead to duplicate processing and increased costs. It does not implement retries with backoff; instead, it attempts to run the job multiple times at once. This approach is inefficient and does not align with the requirement to retry a single job sequentially with exponential backoff.

• ✗

  Add a 'Catch' field with 'ErrorEquals': ['States.TaskFailed'] and a 'Next' state that increments a counter and loops back.

  Why it's wrong here

  Using 'Catch' with a loop can implement retries, but it requires additional states and complex logic to track attempts and backoff. This approach is not as clean or efficient as using the built-in 'Retry' field. The 'Retry' field is specifically designed for this purpose and handles exponential backoff natively. Therefore, this option is not the best choice for the scenario.

Go deeper

Related to this question