Microsoft GH-600 - Developing in Agentic AI Systems

Separate branches isolate each agent’s proposed changes and allow the team to inspect them independently. Adding a required status check for file-level overlap detects conflicting modifications before either pull request is merged, preventing one agent’s work from silently overwriting another’s changes.

A read-only tool configuration prevents both agents from making required changes, so it avoids conflict by eliminating implementation capability rather than controlling it. CODEOWNERS approval adds review accountability for a specific file but does not automatically detect overlap between independent agent outputs. A single concurrency group serializes entire workflows and reduces throughput even where the agents work on unrelated files.

The selected solution maintains parallel development while creating a merge-time control for the actual risk: overlapping file changes. It also produces reviewable evidence of the overlap check in pull request status results.

Branch isolation does not eliminate semantic conflicts, such as incompatible API assumptions. Teams should therefore combine overlap detection with normal pull request review and integration testing.

Study-guide topics: parallel agent coordination, branch isolation, merge controls, and conflict detection.

Selecting release/1.4 as the base branch establishes the correct repository context before the agent begins its assignment. GitHub documents that Copilot creates its working branch from the selected base branch. This ensures that the initial code, dependency declarations, and branch-specific files correspond to the release being repaired.

That distinction matters because a hotfix developed against main may depend on APIs, package versions, or build behavior that do not exist in the maintained release. Choosing the release branch at task creation removes the need for the agent to infer or subsequently correct its starting point. The task should also require validation using the release’s applicable checks.

Option A controls concurrency rather than branch selection. Option B governs review requirements for changes to main; it does not determine where the agent starts. Option C supplies a natural-language instruction but is less direct than configuring the actual base branch before execution.

The selected answer configures the execution environment through the platform’s supported task controls.

Relevant curriculum topics are branch-based scope, execution-context selection, and environment-specific constraints.

Signal

Execution context

The eyes emoji reaction appears on the issue.

The agent acknowledges the assignment and will create the draft pull request.

The pull request timeline shows Copilot started work.

The agent session is actively running and generating live logs.

A draft pull request exists, but GitHub Actions checks are not running.

A human must manually approve and run the workflows.

The eyes reaction signals that Copilot has acknowledged the issue assignment. It is an early lifecycle indicator that the coding agent accepted the work and will begin its workflow.

A pull-request timeline event showing that Copilot started work indicates an active session. This is the appropriate place to observe ongoing status updates and session activity while the agent creates or revises the draft pull request.

When the draft pull request exists but its workflows have not started, the likely state is pending manual authorization. GitHub can require a user with write access to approve and run workflows associated with the pull request, especially where the workflow originates from an untrusted context or requires explicit approval.

These indicators are complementary: issue reactions establish acknowledgement, timeline events show active execution, and inactive checks can identify an approval gate rather than an agent failure.

Study-guide topics: asynchronous coding agents, execution signals, workflow approval, and pull-request observability.

===============

A preToolUse hook is a possible cause because it evaluates a proposed tool invocation before execution. Such a hook can inspect the tool name and arguments, identify a prohibited operation, and deny permission. A shell command containing recursive, forced deletion of an infrastructure directory is an appropriate target for this type of preventive rule.

The decisive evidence is the statement that the command was blocked because a destructive operation was detected. This describes a decision about the proposed command rather than a failure to reach a network destination. Copilot firewall controls address network access; they do not ordinarily classify local filesystem deletion commands. A postToolUse hook runs after a tool operation and therefore does not provide the same pre-execution interception.

An application installation policy governs application access or installation rather than this command-level decision. The surrounding script can treat a denied operation as a task failure and escalate it for human review, producing the displayed exit status.

The answer identifies a plausible enforcement mechanism; the log does not establish its exact implementation.

Study-guide topics: preventive guardrails, tool authorization, destructive-action detection, and escalation. Reference: GitHub Copilot—Hooks reference .

===============

Target

Value

Run tests command

npm test

Prepare CodeQL action

init

Run CodeQL action

analyze

The Node.js unit-test command is npm test, which invokes the project’s configured test script. This supplies the functional validation component of the pull-request workflow.

CodeQL requires initialization before analysis. The github/codeql-action/init action prepares CodeQL for the languages and source code being evaluated. The github/codeql-action/analyze action then performs analysis and publishes the resulting security findings.

build is not the requested unit-test command, although some projects may need an additional build step. upload-sarif is not the normal replacement for the CodeQL analyze action in a standard CodeQL workflow because analysis produces and submits the results.

The completed workflow should run under the pull_request event and grant the security-events permission needed to upload CodeQL results.

Study-guide topics: automated testing, CodeQL analysis, pull-request checks, and quality gates.

===============

Target 1 → E. needs

Target 2 → A. [spec_analyzer, risk_reviewer]

Target 3 → B. concurrency

The relevant completed section is:

plan_merger:

runs-on: ubuntu-latest

needs: [spec_analyzer, risk_reviewer]

steps:

- name: Merge executor outputs into a single plan

run: ./executors/plan_merger.sh

- name: Publish merged plan

run: echo " publish plan artifact "

concurrency:

group: multiagent-${{ github.ref }}

The plan_merger job must use needs: [spec_analyzer, risk_reviewer] . GitHub Actions jobs run in parallel by default when no dependency exists. Therefore, spec_analyzer and risk_reviewer can execute concurrently, implementing the fan-out phase. The needs array then establishes the fan-in dependency: plan_merger does not start until both upstream jobs complete successfully. GitHub explicitly defines jobs. < job_id > .needs as the mechanism for declaring jobs that must complete before another job runs.

The final blank is concurrency , because the following line already defines group: multiagent-${{ github.ref }}. GitHub ' s concurrency key groups workflow jobs or runs under a shared key so that overlapping executions for the same reference can be controlled. This is separate from the parallelism of the two specialized analyzer jobs.

This architecture directly implements a multi-agent orchestration pattern: independent specialized executors operate concurrently, their outputs converge at a deterministic coordination point, and execution boundaries are managed explicitly. The GH-600 study guide specifically requires candidates to apply orchestration patterns, configure parallel agent execution, and detect or prevent conflicts among concurrently operating agents.

Study Guide Reference Topics: Orchestrate Multi-Agent Coordination; fan-out/fan-in orchestration; parallel execution; dependency management; agent isolation and conflict control.

Branch protection rule (main) – Require pull request before merging

Enabled

Workflow trigger for validation checks

on: pull_request

The branch protection setting must be Enabled . GitHub branch protection can require all changes to main to arrive through a pull request and can additionally require a defined number of approving reviews. For this scenario, the repository should require a pull request before merging and configure the required number of approvals to one . This creates a controlled merge boundary while leaving the coding agent free to create its own working branches and submit pull requests. A bypass for direct pushes would violate the requirement because it would provide a path for changes to reach main without review.

The validation workflow should use on: pull_request . GitHub Actions runs workflows for pull_request activity, with opened, synchronize, and reopened among the default triggering activities. Consequently, validation begins when the agent opens the pull request and reruns as the proposed change is updated.

This design separates autonomous low-risk actions —branch creation and PR creation—from the higher-risk operation of modifying the protected default branch. That is precisely the guardrail model tested by GH-600: maximize useful agent autonomy while requiring controlled authorization for consequential changes.

Study Guide Reference Topics: Implement Guardrails and Accountability; human-in-the-loop workflows; protected execution paths; explicit authorization; autonomous branch and pull-request operations.

===============

The required change concerns one agent’s behavior, making its custom agent profile the appropriate scope. The file .github/agents/agent1.agent.md defines instructions for agent1. Its Markdown instruction body can specify the required JSON structure, mandatory properties, allowed values, and prohibition of explanatory prose or Markdown fences.

Repository-wide instructions apply more broadly and could alter the behavior of agent2 and agent3, contrary to the requirement. The setup workflow prepares the execution environment rather than defining the agent’s response contract. A file under .github/instructions uses instruction applicability rules; naming it after an agent does not automatically bind it exclusively to that agent.

The evaluation finding should be converted into a precise behavioral requirement and tested against representative inputs. For example, checks should distinguish valid JSON from text containing a JSON fragment and should reject missing fields or unexpected properties.

An agent instruction improves adherence but is not a mathematical guarantee of schema compliance. Production consumers should validate the returned object before using it. Relevant curriculum topics are revising instructions based on evaluation results and specifying expected output constraints.

Target

Correct selection

apply_auto.if

${{ needs.plan.outputs.risk == ' low ' }}

The automatic execution job must explicitly require the low-risk classification. The expression ${{ needs.plan.outputs.risk == ' low ' }} reads the risk value published by the prerequisite plan job and permits automatic application only when that value matches low. Medium-risk and high-risk plans therefore cannot enter this automatic execution path.

The complementary reviewed path should handle non-low classifications and reference an environment configured with required reviewers. The condition routes work according to risk; the environment protection rule supplies the actual approval barrier. Merely naming a job “manual” or displaying an approval message does not require human authorization.

The alternatives always(), success(), and failure() describe execution status rather than the plan’s risk classification. Checking only for medium would also fail to cover high-risk changes. The plan-producing job must publish the risk as an output, and each execution job must obtain the corresponding plan artifact before applying it.

This design applies human intervention where the task’s operational impact warrants it while allowing routine low-risk work to proceed automatically.

Relevant curriculum topics are risk-based autonomy, explicit authorization, and controlled execution paths.

The architecture requires isolation between webhook deliveries and continuity within each delivery. Creating an independent session for each event prevents an earlier event’s conversation history, decisions, or tool results from influencing an unrelated task. The orchestrator should then retain that session while progressing from planning to approved execution.

Within the question’s displayed interface, tool_choice= " none " expresses the required planning restriction: generate a plan without invoking tools. After an actual approval checkpoint, " auto " represents allowing tool selection during execution. The approval must be enforced by the orchestrator; telling the model to execute an “approved plan” does not establish that a human approved it. A delivery identifier can associate the session, plan, approval, and execution records with the same operational event.

The displayed code should be treated as an interface abstraction. The documented Copilot Python SDK uses session creation and session messaging methods, rather than establishing the shown session.chat.completions.create interface as its standard API. Consequently, the visible selection is defensible, but hidden code targets cannot be certified from this screenshot.

Relevant curriculum topics include task-scoped memory, preventing conflicting context, and preserving state across execution phases.