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.

• ✗

  Wait state with a Retry field to pause and then retry.

  Why it's wrong here

  A Wait state delays execution for a specified time. It does not execute tasks and cannot retry a failed task. While you could combine a Wait state with a Catch to implement a custom retry loop, Step Functions provides native retry functionality on Task states, which is simpler and more appropriate. A Wait state alone cannot achieve the required retry logic.

• ✗

  Map state with a Retry field to iterate over the Glue job.

  Why it's wrong here

  A Map state is used to iterate over an array of items, running a set of steps for each item. It can have a Retry field, but that would retry the entire Map state, not a single Glue job. Since the requirement is to retry the Glue job specifically, a Map state is not appropriate unless the job is part of an iteration, which is not indicated.

• ✓

  Task state with a Retry field configured with MaxAttempts set to 3.

  Why this is correct

  In AWS Step Functions, a Task state can include a Retry field that specifies the number of retry attempts and the interval between them. Setting MaxAttempts to 3 will retry the task up to three times upon failure. This is the correct way to implement retry logic for a specific task, such as the AWS Glue job, within the state machine.

• ✗

  Parallel state with a Catch field to handle failures.

  Why it's wrong here

  A Parallel state is used to execute multiple branches concurrently. While it can have a Catch field to handle errors, it does not provide retry logic for individual tasks. Using Parallel would not directly implement retries for the AWS Glue job; it would complicate the workflow. Retries are configured on Task states, not Parallel states.

Go deeper

Related to this question