A play creates an SVI-style interface that depends on VLAN 55. Which task ordering reflects a correctly constructed Ansible workflow?
Select an answer to reveal the explanation.
Short Explanation
Build the shelf (VLAN) before you mount the drawer (SVI)—facts and dependencies first, not random shuffle or ChatOps interruptions.
Full Explanation
When a play creates an SVI-style interface that depends on VLAN 55, correctly constructed Ansible workflow ordering ensures required facts or the VLAN object exist before the task that needs that VLAN id. That ordering works because network configuration has dependencies: the Layer-2 VLAN must be present (and any needed facts gathered) before an SVI or interface referencing VLAN 55 can converge cleanly. Municipal playbooks express that dependency as earlier tasks or explicit precondition tasks, not as hope.
Configuring the SVI first and creating VLAN 55 only if the interface task fails fails because reactive create-on-failure is fragile ordering and can leave partial failure states. Running unrelated Webex notification tasks before any network parameter modules fails conceptually: ChatOps noise does not satisfy VLAN prerequisites and delays the real dependency chain. Shuffling task order randomly each run to prove idempotency fails because random order breaks dependencies; idempotency is about repeated convergent results, not stochastic sequencing.
Exam caveat: some modules can create dependent objects implicitly, but exam-quality workflow construction still shows explicit ensure-VLAN-then-SVI structure so operators can see and trust the dependency. Operational check: in lab, run with VLAN 55 absent and confirm the play creates/ensures the VLAN before the SVI task; fail CI if task order places the SVI module earlier than the VLAN ensure task in the civic playbook.