Two parallel agents in a GitHub Actions workflow are both assigned to update a shared configuration file, config/settings.yaml. After both agents complete, the file contains only one agent's changes — the other agent's changes are silently overwritten. What is the PRIMARY architectural fix to prevent this overlapping-change conflict?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Think of it like two people editing the same Google Doc with no conflict detection — last save wins and the other person's work is gone. In multi-agent systems, parallel agents must never write to the same resource without coordination. The fix is ownership isolation or explicit locking: one agent, one file section, or a serialized write queue.
Full explanation below image
Full Explanation
When two agents write to the same file concurrently, a race condition occurs — whichever write completes last wins, silently discarding the other agent's changes. This is called an overlapping-change conflict, and it is one of the most common (and hardest-to-debug) problems in parallel agent orchestration.
Why B is correct: The correct fix is architectural — prevent the conflict at design time rather than reacting to it at runtime. Options include: (1) file locking (a mutex or semaphore that only one agent can hold at a time), (2) serialization (routing all writes through a single sequential step), or (3) resource partitioning (each agent owns a distinct key-space, section, or file). GitHub Actions itself supports job-level concurrency groups (concurrency:) to serialize workflows, and agent frameworks can use advisory locks via databases or cloud storage.
Why A is wrong: Disk I/O priority does not eliminate the race condition — it just changes which agent is more likely to win. The conflict still occurs; you just make it harder to reproduce.
Why C is wrong: Retries address transient failures (network timeouts, permission errors), not logical conflicts. A successful write that overwrites another agent's data does not produce an error that a retry would fix — it succeeds silently, which is exactly the problem.
Why D is wrong: Human-in-the-loop manual merging is a valid recovery pattern for exceptional cases, but it cannot scale as the primary prevention mechanism and defeats the purpose of automation. It also does not prevent the data loss — it just detects it after the fact.
The exam takeaway: parallel agents must have non-overlapping write domains. If shared state is unavoidable, serialize access to it.