Manage task execution and roles →hardMultiple Choice

EX294 Manage task execution and roles Practice Question

A playbook includes a long-running task that should not block the rest of the playbook. The administrator wants to start the task and later check its status. Which method should be used?

⚠ Common exam trap

A common mix-up: candidates confuse `async` with `throttle` or `delegate_to`, thinking any concurrency-related keyword will make a task non-blocking, when only `async` with `poll: 0` achieves true background execution.

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

✓

Use the 'async' keyword with 'poll: 0' and then use async_status module.

Setting `poll: 0` with the `async` keyword launches the task in the background without waiting for it to complete, and the `async_status` module can then be used later to check the task's status by referencing its job ID. This allows the playbook to continue executing other tasks while the long-running task runs asynchronously.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Use the 'async' keyword with 'poll: 0' and then use async_status module.
Why this is correct
Fire-and-forget execution requires async with poll: 0, which returns immediately without blocking subsequent tasks. The async_status module then queries the job by its async job ID to retrieve completion state, satisfying the requirement to start the task and check its status later.
✗
Use 'delegate_to: localhost' and 'run_once'.
Why it's wrong here
'delegate_to: localhost' with 'run_once' only changes where and how many hosts execute the task; it still runs synchronously and blocks the play. It tempts for one-off local actions, but asynchronous execution with 'async' and 'poll: 0' is what allows later status checks.
✗
Use a separate playbook invoked with 'ansible-playbook' via command module.
Why it's wrong here
Invoking a second playbook through the command module still runs synchronously inside the current task, blocking the play until it finishes. It tempts for orchestrating separate workflows, but 'async' with 'poll: 0' and later 'async_status' is the mechanism for non-blocking execution and status polling.
✗
Use 'throttle' to limit execution.
Why it's wrong here
'throttle' caps how many hosts run a task concurrently; it does not detach the task from the play, so execution still blocks until completion. It tempts when limiting parallelism across many hosts, but asynchronous tasks with 'async' and 'poll: 0' are required to start work and check status later.

Visual reference

Go deeper

EX294 Manage task execution and roles Practice Question

Why each option matters

Option-by-option breakdown

Related to this question