GH-600 Public Study Guide

Markdown-only workbook for Exam GH-600: Developing in Agentic AI Systems.

Last updated: May 24, 2026.

This version is organized around the official GH-600 domains. Each domain explains the concepts, shows the GitHub implementation artifacts, and includes examples you should be able to read in YAML, Markdown, CLI output, PR timelines, and audit logs.

Public sharing note: this guide is not an exam dump and does not contain real exam questions or answer choices. It is a structured study workbook built from official Microsoft and GitHub documentation, with practical examples written for learning and review.

Primary source of truth:

• GH-600 Microsoft Learn study guide: https://learn.microsoft.com/en-us/credentials/certifications/resources/study-guides/gh-600
• GitHub Copilot cloud agent docs: https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent
• GitHub Copilot CLI docs: https://docs.github.com/en/copilot/reference/copilot-cli-reference/cli-command-reference
• GitHub Copilot CLI config directory: https://docs.github.com/en/copilot/reference/copilot-cli-reference/cli-config-dir-reference
• GitHub custom agents configuration: https://docs.github.com/en/copilot/reference/custom-agents-configuration
• GitHub customization cheat sheet: https://docs.github.com/en/copilot/reference/customization-cheat-sheet
• GitHub Actions workflow syntax: https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax
• GitHub Actions contexts: https://docs.github.com/en/actions/reference/workflows-and-actions/contexts
• GitHub audit log events: https://docs.github.com/en/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/audit-log-events-for-your-enterprise

Use the official GH-600 skills outline as the map, then use the linked GitHub Docs pages for exact syntax and product behavior.

1. Exam Map And Study Model

The exam domains:

The key is not just knowing definitions. GH-600 expects you to recognize implementation evidence:

2. Domain 1: Prepare Agent Architecture And SDLC Processes

What This Domain Tests

This domain asks whether you can decide where an agent belongs in a software delivery workflow. The right answer usually preserves GitHub-native accountability: issue, branch, PR, checks, review, merge.

Use an agent when:

• Inputs and outputs are clear.
• Work can be scoped to a repository, branch, issue, PR, or workflow.
• The result can be reviewed through a diff, artifact, log, or check.
• Tests/scans/reviews can validate the output.
• The agent can operate with least-privilege tools and permissions.

Do not rely only on an agent when:

• The task has unclear success criteria.
• The task is irreversible or production-sensitive.
• The agent would need broad secrets or broad external write access.
• The agent would approve its own output.
• Human judgment is required for policy, compliance, legal, security, or product decisions.

Planning Versus Execution

Planning is reviewable intent. Execution changes state.

Use planning first for:

• Large refactors.
• Security-sensitive work.
• Workflow/deployment changes.
• Cross-repository work.
• Multi-agent coordination.
• Any task where a human should approve scope before edits.

Example plan artifact:

# Agent plan

Goal: Update dependency review workflow.

Steps:
1. Inspect current workflow permissions.
2. Add dependency review gate.
3. Validate workflow syntax.
4. Open PR with risk notes.

Validation:
- Existing required checks still run.
- Dependency review runs on pull requests.
- PR requires human review.

What to notice:

• A plan is not validation.
• The plan becomes useful when it is stored in an issue, PR, comment, file, or workflow artifact.

SDLC Pattern

Safe GitHub-native agent work:

1. Task is defined in a prompt, issue, or PR comment.
2. Agent works on a branch.
3. Agent commits changes.
4. Agent opens or updates a PR.
5. Workflow checks run.
6. CodeQL, secret scanning, dependency review, and tests provide evidence.
7. Humans inspect diff, session logs, and artifacts.
8. Branch protection/rulesets gate merge.
9. Audit logs and PR history preserve accountability.

Autonomy Levels

Examples:

# Low-autonomy reviewer
tools:
  - read
  - search

# Medium-autonomy implementer
tools:
  - read
  - search
  - edit
  - execute

# Coordinator
tools:
  - read
  - search
  - agent

Domain 1 Traps

• "Tell the agent to be careful" is not a control.
• An agent-generated plan does not prove the implementation is safe.
• High autonomy requires enforceable controls: permissions, reviews, scans, rulesets, hooks, and logs.
• Do not let agents make unreviewed changes to protected or production-sensitive paths.

Domain 1 Implementation Examples

Define success criteria before giving the agent tools.

Weak task:

Improve the payment service.

Better task:

Update payment retry logic so transient gateway failures retry three times with exponential backoff. Add unit tests for success, permanent failure, and transient retry. Do not modify public API contracts. Open a draft PR and include validation output.

Why it is better:

• Scope is bounded.
• Output is testable.
• API compatibility is explicit.
• The PR is reviewable.
• Validation is required.

Inputs, outputs, and controls:

Autonomy selection:

Domain 1 Self-Check

• What makes a task suitable for an agent?
• What artifact proves the plan was reviewed?
• What GitHub control blocks unreviewed merge?
• What is the difference between agent guidance and enforceable policy?