Orchestrate multi-agent coordination: free practice questions

Correct: A human-in-the-loop (HITL) recovery step is a deliberate pause mechanism: it surfaces agent state and failure context to a human operator, who then makes an informed decision to resume, modify, or redirect the workflow. It preserves human oversight at critical recovery decision points without permanently replacing automation. — Wrong (A): Automatic retry with modified parameters is an automated recovery strategy (e.g., retry-with-backoff or parameter perturbation), not a human-in-the-loop pattern; HITL specifically requires human involvement. — Wrong (C): HITL does not permanently replace downstream automation; it is a conditional intervention at a specific decision point, after which automated agents typically resume. — Wrong (D): Automatic rollback to a checkpoint is a distinct recovery pattern (rollback recovery); HITL specifically defers the recovery decision to a human rather than executing it automatically.

Correct: Signed structured decision records appended at each handoff directly satisfy all three CAB requirements: agent identity addresses (1), decision criteria addresses (2), and the upstream agent reference chain addresses (3). An immutable store prevents post-hoc tampering, and the summary report makes the evidence accessible to reviewers. — Wrong (A): Verbose logging produces unstructured, high-volume output that does not map cleanly to the three specific CAB evidence requirements; it requires manual correlation across log lines and does not provide attributable agent-level decision records. — Wrong (C): A GitHub Release captures the end state but contains no per-agent decision attribution or handoff sequence, omitting requirements (1) and (3). — Wrong (D): Human approval logs address human-in-the-loop checkpoints but do not capture autonomous agent decision criteria or the inter-agent handoff sequence; they partially address (1) only for human approvers, not agents.

Correct: Tagging the final production version creates an immutable reference point; archiving the repository keeps it accessible without allowing new changes; retaining workflow run logs and artifacts ensures historical runs can be audited; and updating documentation provides context linking historical runs to the now-archived agent. This satisfies both auditability and continuity requirements. — Wrong (A): While Git history preserves code, simply deleting configuration without explicit archival and documentation makes it difficult for auditors unfamiliar with the repository to locate the correct version context. — Wrong (C): Retroactively modifying historical workflow YAML files corrupts the audit trail by misrepresenting what actually ran during historical executions — this is a serious compliance violation. — Wrong (D): Exporting only the last runtime state captures a single point-in-time snapshot and does not preserve the agent's full decision history or the ability to reproduce earlier runs.

Correct: In a hierarchical orchestration pattern, the coordinator agent's role is planning and synthesis — it breaks a complex goal into sub-tasks, assigns them to specialized subordinate agents, and integrates their individual outputs into a unified outcome. This is the defining characteristic of the orchestrator/coordinator role. — Wrong (A): Direct domain-specific task execution describes a worker or specialist agent, not a coordinator; coordinators delegate rather than execute domain tasks. — Wrong (C): Automated health monitoring and restart logic describes a watchdog or supervisor component, which is a distinct infrastructure concern from orchestration coordination. — Wrong (D): API proxying for rate-limit management is an infrastructure cross-cutting concern, not an orchestration pattern role; conflating it with coordination reflects a common architectural misunderstanding.

Correct: A blue/green deployment pattern for agents routes new incoming work to the replacement (streaming) agent while the existing (batch) agent is allowed to complete — or 'drain' — its current queue. This ensures zero disruption to in-flight requests and provides a clean cutover point. — Wrong (A): Halting the workflow and restarting from checkpoints introduces downtime and may not be feasible if checkpointing is not configured; it is disruptive by definition. — Wrong (C): Triggering re-runs of currently executing workflow runs cancels and restarts active work, which drops in-flight requests rather than preserving them. — Wrong (D): Random selection between agents without a routing strategy can result in the same work unit being processed by both agents (duplicated effort) or neither, and does not guarantee the old agent drains gracefully.