Microsoft GH-600 Developing in Agentic AI Systems Exam Practice Test

The mcp-servers property connects a custom agent to the Model Context Protocol servers required for its planned work. MCP configuration makes defined external tools and services available to the agent in a controlled, declarative manner.

Adding a broad natural-language instruction such as “Use all available tools” does not configure a server connection, authenticate a tool, or define which external capabilities are available. It is also poor least-privilege design because it encourages unrestricted tool use without establishing a technical permission boundary.

Setting tools: [] removes all configured tools and would prevent the agent from using required capabilities. Deleting the tools line could cause the agent to inherit or expose a broader default tool set than intended. Repository-wide instructions can guide behavior, but they do not replace the agent-specific configuration needed to associate MCP servers with that agent.

A well-designed configuration identifies only the MCP servers necessary for the role, supplies secrets through approved environment mechanisms, and limits the resulting tools to the agent’s defined task.

Study-guide topics: MCP integration, agent tool configuration, and least-privilege environment access.

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

The API key should be stored as a secret in the Copilot environment and referenced by name from the MCP configuration. This keeps the secret value out of repository files, agent prompts, pull requests, and ordinary workflow output while allowing the MCP server to receive the required credential at runtime.

A plaintext key in a configuration file is unacceptable because repository history, forks, logs, and code review systems can expose it. A Codespaces user secret is scoped to a user development environment and does not provide the intended runtime secret for the Copilot agent environment. A GitHub Actions secret is useful for workflow expressions, but the scenario requires the key to be available to the MCP server configuration itself.

The prefixed environment-secret approach creates a clear boundary: the configuration references an identifier, while the secret value is resolved only in the authorized execution environment. This supports rotation without changing tracked configuration content.

Study-guide topics: MCP authentication, secrets management, secure environment configuration, and credential isolation.

The first statement is Yes . When an MCP server is configured for a repository, GitHub Copilot cloud agents can use the enabled MCP tools autonomously during assigned tasks. GitHub specifically notes that Copilot does not request interactive approval before invoking configured MCP tools, making careful tool allowlisting and credential protection important.

The second statement is No . For repository-level MCP integration, Copilot cloud agent currently supports MCP tools , but it does not support MCP resources or MCP prompts exposed by the server. Resources and prompts are available in other MCP-capable Copilot experiences, such as IDE chat, but they are not consumed by the cloud coding agent in this configuration.

The third statement is Yes under the planned configuration. Litware requires agent1 to access all available tools . GitHub custom-agent configuration supports this by omitting the tools property or specifying tools: [ " * " ]. Likewise, an MCP server can use " * " to expose all of its tools. Consequently, newly introduced MCP1 tools fall within that wildcard authorization and become available without individually adding each tool name.

Study Guide Reference Topics: MCP tool integration, custom-agent tool configuration, autonomous tool invocation, MCP capability boundaries, and least-privilege agent execution.

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.

A fine-grained PAT restricted to product-api provides an enforceable repository-level authorization boundary for agent1. GitHub fine-grained personal access tokens can be limited to selected repositories and assigned only the repository permissions required by the workload. Consequently, even if agent1 attempts to access billing-service or infra-terraform, the credential does not authorize access to those repositories. GitHub specifically recommends fine-grained PATs when repository access must be restricted to particular repositories.

This directly aligns with the GH-600 objective to configure an agent ' s scope to a specific repository and define execution boundaries through repository context and permissions. Microsoft Learn defines execution context as including the repository an agent can access and emphasizes that repository scope is the first boundary limiting agent behavior.

Option A provides behavioral guidance but is not a security authorization boundary. Option B controls the permissions available to the workflow token but does not, by itself, establish the required cross-repository credential restriction. Option D only prevents certain push operations; it does not stop agent1 from reading or otherwise accessing the other repositories.

Study Guide Reference Topics: Implement Tool Use and Environment Interaction → execution context and boundaries; repository-specific agent scope; tool permissions; least-privilege authentication.

Copilot memory is an organization-level capability. Configuring it through the organization’s Copilot settings establishes the governance boundary, availability, and policy controls consistently for the developers and repositories covered by that organization.

Personal settings are unsuitable because they create inconsistent behavior between developers and do not provide centralized administration. A repository-level configuration can supply repository instructions and scoped context, but it does not replace the organization-level control that enables and governs the memory capability. An individual agent profile defines role behavior, tool access, prompts, and delegation settings; it is not the tenant-level location for enabling Copilot memory.

Organization configuration is particularly important when agents must retain approved context, recurring preferences, and workflow guidance across sessions without each developer configuring behavior independently. Central governance also allows administrators to maintain predictable controls over which organizational information is available to Copilot.

Study-guide topics: organizational governance, persistent context, and centralized agent configuration.

The intended distinction is between delegating analytical work and allowing the agent to provide the final approval of its own work. Approving all Git commits would remove independent review of changes that include security-sensitive remediation and compatibility modifications across multiple projects.

Human validation of assessment.md is similarly important because the assessment determines the scope and direction of the upgrade. Incorrectly classified dependencies, missed projects, or an incomplete vulnerability analysis can propagate into the implementation plan. Microsoft’s guidance explicitly recommends reviewing the assessment for missing projects, problematic dependencies, and application-specific concerns before proceeding.

Generating the assessment and checking whether a task file exists are appropriate automated activities. An agent can also inspect the plan’s dependency relationships and flag potential ordering problems. Such assistance does not transfer final accountability for accepting the plan.

The wording should not be interpreted as prohibiting automated assessment validation. Agents can run valuable consistency checks; the unsafe delegation is treating those checks as sufficient independent approval of their own conclusions.

Study-guide topics: human oversight, independent validation, and approval boundaries. Reference: Microsoft Learn—Best practices for GitHub Copilot upgrade .

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

The agent session log is the appropriate starting point when the reported problem concerns an agent’s interaction, execution sequence, or tool activity within the development environment. It provides information closer to the failing behavior than repository-level workflow usage statistics.

A useful investigation establishes what the agent was asked to do, which operations it attempted, what responses those operations returned, and where progress stopped or diverged from the intended result. Session diagnostics can help distinguish an instruction problem from an unavailable tool, a rejected operation, or an execution error. VS Code also provides detailed chat debugging facilities for inspecting interactions and diagnosing failures.

GitHub Actions usage metrics primarily describe workflow consumption. Runner logs are relevant when evidence points to a hosted workflow or runner problem. The token permissions block becomes relevant when the failure concerns authorization to a GitHub resource. None should be assumed to be the root cause before examining the reported execution.

The PDF selects B; the underlying Dev1 incident description is not included, so this selection assumes a session-level agent issue.

Study-guide topics: diagnostic evidence, tool-call inspection, and failure localization. Reference: VS Code—Debug chat interactions .

Target

Selection

Dropdown 1

' search '

Dropdown 2

' read '

The visible configuration describes an implementation planner. Providing search and read supports the information-gathering work needed to produce a technically grounded plan: locating relevant code and inspecting its contents. The listed documentation tools supplement repository context with external technical reference material.

This tool selection also establishes a practical boundary between planning and implementation. A planner can explain proposed changes and produce Markdown in its response without needing permission to modify repository files. Granting editing or command-execution capabilities would expand its authority beyond the visible planning role.

The distinction between generating Markdown and saving a Markdown file is important. The selected tools support producing a plan in conversation. If the requirements instead demanded that the planner write that plan directly into the repository, an appropriate file-writing capability or a separate persistence step would be necessary.

Tool names must also resolve to capabilities available in the configured environment. Merely listing a documentation tool does not install or authenticate its MCP server.

Study-guide topics: tool selection, least-privilege planning, and environment capabilities. Reference: VS Code—Use tools with agents .

The tasks.md file is the execution-tracking document for the upgrade scenario. It records individual tasks, their validation criteria, and their completion status. Microsoft’s upgrade walkthrough specifically directs users to review this file when checking the status of every upgrade step.

A task can include several concrete verification activities, such as restoring dependencies, building the solution, correcting compilation errors, running the test suite, and rerunning tests after fixes. Reviewing these entries reveals whether implementation has merely been attempted or has satisfied the defined checks.

The assessment identifies upgrade issues and scope; it does not serve as the live record of completed work. A plan describes intended actions and ordering, which also differs from evidence that execution and testing succeeded.

The phrase “before App1 is upgraded” requires temporal care. Before execution, tasks.md identifies the steps and checks that must be performed. It cannot prove that future tests have already passed. Completion and test results become available as the agent executes and updates the tasks.

Study-guide topics: execution validation, task status, and acceptance criteria. Reference: Microsoft Learn—Execute and verify a Copilot upgrade .

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

Repository custom agent profiles belong in .github/agents/ and use Markdown files with agent configuration and instructions. When the intended changes concern the agents’ roles, available tools, or operating guidance, these profiles are the appropriate implementation point.

An agent profile provides a durable definition that can be shared with other repository contributors. Keeping that definition under version control makes changes reviewable and enables the team to associate a particular agent configuration with the code revision used during evaluation. This is useful when diagnosing why an agent’s behavior changed after its instructions or capabilities were modified.

Editor settings and MCP connection settings address different concerns. They can affect the environment in which an agent operates, but they do not replace the agent’s own profile. Changing a server connection is appropriate for transport or authentication requirements; changing an agent profile is appropriate for agent behavior and capability selection.

The source selects C. Its applicability depends on the omitted planned changes actually concerning custom agent configuration.

Study-guide topics: agent profiles, configuration management, and SDLC traceability. Reference: GitHub—Creating custom agents .

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

The filter action:artifact.destroy selects the audit event associated with manual deletion of a workflow artifact. It directly targets the activity described in the scenario, allowing the investigator to examine the recorded actor and associated event details.

A repository filter narrows the search to a particular repository but does not distinguish artifact deletion from other recorded operations. It can usefully accompany the action filter when investigating a specific project. A workflow-run action concerns workflow execution rather than the manual removal of its stored artifacts. The generic operation:remove option does not select the documented artifact deletion event.

The investigation should correlate the deletion event with its timestamp and repository information, then inspect the actor recorded for that event. This identifies the account associated with the action; additional context may be needed when an application or automated identity performed it.

Artifact retention and audit logging serve separate purposes. Retention controls how long outputs are normally preserved, while the audit log records relevant administrative and user activity. Searching the audit log does not restore deleted content.

Study-guide topics: accountability, evidence preservation, actor attribution, and audit trails. Reference: GitHub—Organization audit log events .

Repository memory is supported by citations to the code that establishes the remembered fact. When a fact appears relevant to a new task, Copilot checks its supporting citations against the current branch before relying on it. This validation prevents an observation from an earlier repository state from being treated automatically as current truth.

The branch check is particularly important when work spans release branches, experimental changes, or pull requests that were never merged. A memory may have been accurate when created but no longer describe the code now being edited. If its supporting code is absent or no longer supports the claim, the remembered fact should not influence the task.

Option A incorrectly describes memory as permanently retained information requiring only manual intervention. Option B substitutes pull-request disposition for validation of the underlying evidence. Option C incorrectly treats repository knowledge as usable only by its original contributor.

The governing mechanism is evidence validation at the point of use, not an assumption that all previously stored information remains authoritative.

Relevant curriculum topics are task-relevant memory, stale-context prevention, and maintaining state consistency across branches and sessions.

Audit log streaming is the correct choice because it exports audit events to an external destination where the organization can apply its required two-year retention policy. This captures agent-initiated activity as part of the organization’s auditable GitHub events.

Standard audit-log retention in GitHub may not meet a long-term evidence requirement on its own. Streaming allows the organization to store and search the exported events in a SIEM, data lake, or logging platform with retention controls aligned to compliance policy.

Log forwarding is not the required GitHub audit mechanism in this scenario. Enabling Git events can increase event visibility, but it does not independently provide the requested long-term retention of all relevant agent-initiated actions.

The external destination should preserve actor details, timestamps, repository identifiers, action types, and correlation information needed to reconstruct agent activity during an investigation.

Study-guide topics: accountability, audit log streaming, retention, and agent activity traceability.

The configuration must be changed on the agent that performs the delegation. Orchestrator is responsible for coordinating the workflow, so its allowed subagent list must include Summarizer. Adding the new agent to that list makes it an available delegation target alongside Planner, Implementer, and Reviewer.

An agent’s agents property identifies the custom agents it can invoke as subagents. The tools property serves a different purpose: it identifies available capabilities such as reading files, editing code, or invoking agents. Adding a custom agent’s name to the tools list does not register that agent as a callable subagent. The agent invocation tool must also be available; the scenario already establishes that Orchestrator delegates to other subagents.

Changing Reviewer’s configuration would enable a relationship originating from Reviewer, rather than the requested direct invocation by Orchestrator. A handoff also represents a different interaction pattern from having the orchestrating agent invoke a subagent and receive its result.

Availability does not force execution on every task. Orchestrator’s instructions should indicate when a summary is required and what information it should contain.

Study-guide topics: delegation permissions, orchestrator responsibilities, and specialized subagents. Reference: VS Code—Subagents .

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

The correct answer is the GITHUB_TOKEN permission configuration . GitHub uses the automatically generated GITHUB_TOKEN to authenticate workflow operations against the repository, and its authorization scope can be reduced through repository defaults and the workflow permissions key. Permissions can be set globally for a workflow or narrowed further at the individual job level. GitHub recommends granting only the minimum access necessary for the task.

For example, a workflow that only needs repository content access and pull-request modification can explicitly grant appropriate contents and pull-requests permissions rather than broad write access. Importantly, once individual permissions are specified, unspecified permission categories are set to none, providing a concrete least-privilege security boundary. Repository or organization policy can also establish restrictive default GITHUB_TOKEN permissions.

copilotignore concerns which content Copilot should exclude, while copilot-instructions.md provides behavioral and coding guidance; neither is an authorization mechanism. /context reports information about the Copilot CLI context and does not control repository privileges.

Study Guide Reference Topics: Implement Guardrails and Accountability; least-privilege authorization; tool and execution permissions; repository security boundaries; controlled agent access.

Unassigning and reassigning the issue is GitHub’s documented retry action for an issue-driven agent session that remains stuck and times out. The troubleshooting guidance states that a persistently stuck session times out after an hour. At 70 minutes with no continuing activity, the scenario therefore calls for a fresh execution trigger rather than indefinite waiting.

Reassignment reissues the task through its original issue context. This makes C the appropriate selection among the available actions. The issue should contain current requirements so that the retry begins with the intended scope rather than repeating an outdated assignment.

Option B is incorrect because a draft pull request should not be merged simply to restart implementation, and Copilot does not respond to new mentions on merged or closed pull requests. Option D authorizes repository workflow execution rather than restarting the agent.

For operational precision, reassignment is a documented retry mechanism, not a universal guarantee that every retry reuses the same pull request. Where preserving a particular pull-request branch is essential, an authorized @copilot comment on that open pull request directly targets it.

Relevant curriculum topics are timeout recovery, task reinitialization, and preserving execution continuity.

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.

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

Workflow artifacts provide the required combination of retained execution evidence and file transfer between jobs. The agent-run job uploads trace.json and plan.md, associating both files with the workflow run. Reviewers can access the resulting artifact through the run’s GitHub Actions interface, while downstream jobs download it to their own execution environments.

This is necessary because separate jobs do not automatically share a local filesystem. Declaring a dependency establishes execution order but does not transfer the generated files. The review and deployment stages therefore need explicit artifact downloads in addition to their appropriate job dependencies.

Committing transient traces and plans introduces repository changes solely to transport run-specific evidence. A network share adds external infrastructure and does not directly satisfy the requirement for standard Actions artifact access. Dependency caching is intended for reusable inputs such as downloaded dependencies; it is not the appropriate mechanism for authoritative outputs from a particular agent run.

Artifacts preserve the plan and trace that informed the review, allowing subsequent deployment activity to use the corresponding files. Relevant curriculum topics are inspectable agent artifacts, observability, and human intervention.

Statement

Answer

agent1 and agent2 jobs will run in parallel.

Yes

If the agent2 job fails, the workflow will fail.

Yes

GitHub Actions jobs run in parallel by default when no needs dependency establishes an execution order. Therefore, if agent1 and agent2 are independent jobs in the same workflow, they can begin concurrently when runners are available.

A job failure normally causes the workflow to be marked as failed. The workflow can be configured differently through conditional execution, continue-on-error, or dependent job logic, but no such exception is indicated here. An agent2 failure therefore results in a failed workflow outcome under standard behavior.

The environment: agent-sandbox setting identifies an environment associated with agent1. It does not itself create a dependency between agent1 and agent2, nor does it establish workspace isolation between them. Parallel execution requires separate coordination controls if both jobs can modify shared external resources or deploy to the same target.

Study-guide topics: parallel execution, job dependencies, workflow failure propagation, and execution environments. Reference: GitHub Actions—Workflow syntax .

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

Statement

Selection

When the developer uses the default profile on main, the workspace release-notes agent will appear in the agents dropdown.

Yes

When the developer is on branch1, the workspace version of the release-notes agent will be available in the agents dropdown.

No

When the developer switches to profile1, the user profile release-notes agent will appear in the agents dropdown.

No

The first statement is Yes because the workspace agent definition exists in the conventional .github/agents directory on main. Assuming a valid agent definition with no visibility restriction, Visual Studio Code discovers it and makes it available for selection. The default value of user-invocable is true.

The second statement is No because workspace discovery depends on the files present in the checked-out workspace. Switching to branch1, where the definition does not exist, removes that workspace-defined agent from the applicable configuration. Its existence on the repository’s default branch does not make it globally available across every branch.

The third statement is No because the profile-level definition explicitly sets user-invocable: false. That setting hides the agent from the dropdown even though its definition exists in the active profile. It controls manual selection rather than deleting the agent or necessarily preventing programmatic or subagent invocation.

The scenario therefore separates three independent factors: workspace file presence, active profile configuration, and agent visibility metadata.

Relevant curriculum topics are evaluating development-environment context, configuring custom agents, and controlling how agents are invoked.

Answer area

Correct selection

To draft and open the pull request, use

GitHub Copilot coding agent assigned to an issue

To automate the pull request review before the human review, use

GitHub Copilot code review on the pull request

The workflow requires two distinct capabilities: implementing the requested change and reviewing the resulting change. Assigning the issue to the Copilot coding agent supplies the implementation task. The agent can inspect the repository, modify code, add or update tests, and open a pull request for review. This matches the requirement to turn an assigned issue into a proposed implementation. GitHub—Use Copilot cloud agent on GitHub .

Copilot code review examines the pull request and produces review feedback. It therefore belongs after the implementation has produced a reviewable diff and before the workflow requests the intended human review. The automation must request or configure this review at the appropriate stage; assigning an issue alone does not establish the complete review sequence.

CI, automated code review, and human review provide complementary checks. CI validates executable requirements such as tests and lint rules. Automated review highlights potential code issues. Human reviewers retain responsibility for assessing the proposed change and satisfying applicable approval requirements. GitHub—Copilot code review .

Study-guide topics: agent integration into the SDLC, issue-to-pull-request workflows, automated validation, and human review.

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