Question 434 of 520
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 should reference the registered variable, e.g., `result.status`, not just `status`.
- ✓
`register: result`, `until: result.status == 200`, `retries: 5`, `delay: 30`
Why this is correct
Correctly registers the result, retries until status 200, with 5 retries and 30-second delay.
- ✗
`until: result.status == 200`, `retries: 5`, `delay: 30`
Why it's wrong here
Missing `register: result`, so `result` is undefined.
- ✗
`register: result`, `retries: 5`, `delay: 30`
Why it's wrong here
Missing `until`, so the task will not retry based on condition; it would only run once.
About these practice questions
Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, 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.
Last reviewed: Jun 30, 2026
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.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.