Automatic Task Retries Using until Loop
An Ansible playbook that deploys a web application includes a task that uses the `uri` module to call an external API. The task occasionally fails due to API rate limiting. Which combination of keywords should be added to the task to automatically retry up to 5 times with a 30-second delay between attempts, and only fail if all retries are exhausted?
Quick Answer
The combination of register, until, retries, and delay is correct because each keyword handles one distinct part of the retry logic Ansible needs to poll an unreliable API correctly. register: result captures the full response of the uri module call so its status field can be inspected afterward; until: result.status == 200 tells Ansible what success actually looks like, so it keeps retrying as long as the condition is false rather than stopping after the first attempt; retries: 5 caps how many times that loop can run so it does not retry forever; and delay: 30 spaces those attempts out so the task is not hammering a rate-limited API immediately after each failure. Leaving any one of these out breaks the pattern - without register there is nothing to check the condition against, without until the task does not loop at all, and without retries or delay it either loops indefinitely or retries too aggressively. Whenever an exam scenario describes a task that should keep trying until some condition is met, with a defined number of attempts and a pause between them, that is the register, until, retries, delay pattern, and the task only fails once the retry count is exhausted without the until condition ever being satisfied.
⚠ Common exam trap
Red Hat often tests the requirement that `register` must be used with `until` to reference the captured result, and that `retries`/`delay` are meaningless without `until` — candidates frequently omit `register` or forget to prefix the variable with `result.` in the condition.
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
✓
`register: result`, `until: result.status == 200`, `retries: 5`, `delay: 30`
It combines `register` to capture the API response, `until` to check that `result.status` equals 200 (the HTTP success code), `retries: 5` to attempt the task up to five times, and `delay: 30` to wait 30 seconds between retries. This ensures the task only fails after all five retries are exhausted, which is the exact behavior needed to handle transient API rate limiting.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
`register: result`, `until: status == 200`, `retries: 5`, `delay: 30`
Why it's wrong here
The `until` condition tests the registered variable's attribute, so `status == 200` fails because `result` holds the response object and the status sits at `result.status`. It is tempting because it mirrors the retry, delay and retries keywords correctly, and would work if the condition referenced the registered result's status field.
- ✓
`register: result`, `until: result.status == 200`, `retries: 5`, `delay: 30`
Why this is correct
The `until` keyword loops the task until `result.status == 200`, satisfying the rate-limit constraint by re-polling the API. `retries: 5` caps attempts, while `delay: 30` inserts the required 30-second pause between them. `register` captures each response so the condition can be evaluated, and the task fails only once retries are exhausted.
- ✗
`until: result.status == 200`, `retries: 5`, `delay: 30`
Why it's wrong here
Retries with delay only re-run the task when the until condition evaluates false, and a 200 status check cannot distinguish rate-limit responses from success states the API returns. This combination is correct when polling until a specific documented status or value appears.
- ✗
`register: result`, `retries: 5`, `delay: 30`
Why it's wrong here
Registering the result captures the API response but does not evaluate it, so the task still fails on the first rate-limit error; retries and delay alone never trigger without an until condition. Registering output is genuinely needed when later tasks must reference returned data, such as a token or resource ID.
Go deeper
Related to this question
About these practice questions
One of 392 original EX294 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on EX294
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. An Ansible automation team is designing a playbook to manage network devices. They need to ensure that the playbook can handle transient network failures by retrying failed tasks a specific number of times with a delay between retries. Which approach should they use?
medium- A.Set `max_fail_percentage` in the play to 0 and use `ignore_errors: yes` with a rescue block.
- B.Use the `throttle` keyword to limit concurrent tasks and rely on idempotency.
- C.Set `serial: 1` on the play to ensure only one host is processed at a time and rely on idempotency.
- ✓ D.Use the `until` loop with `retries` and `delay` parameters on the task.
Why D: The `until` loop with `retries` and `delay` parameters is the correct approach because it allows a task to be retried a specified number of times with a configurable pause between attempts, directly addressing transient network failures. This is a built-in Ansible feature for handling intermittent issues without additional error-handling constructs.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This EX294 practice question is part of Courseiva's free Red Hat certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the EX294 exam.