GH-600 Study Guide: How to Prepare for GitHub's Agentic AI Developer Exam

Microsoft's audience profile for this exam describes someone with subject-matter expertise in operating, integrating, supervising, and governing AI agents inside production-grade SDLC workflows, using GitHub as the system of record and control plane. That person's responsibilities, as the study guide states them, include operating agent workflows inside the SDLC, supervising autonomous behavior with GitHub's own controls, evaluating and tuning agent outputs using scans and artifacts, configuring custom agents, and coordinating multi-agent execution safely. They work alongside architects, platform engineers, DevOps engineers, application developers, product managers, and security engineers.

On experience, the study guide expects familiarity with the software development lifecycle, GitHub workflows and controls, code quality, security, and review practices, and hands-on time with coding agents including GitHub Copilot, MCP servers, and agent customization such as custom instructions, custom agents, tools, and Copilot setup steps. On logistics: the exam is proctored, scheduled through Pearson VUE, runs two hours, costs US$165 (price varies by country or region), is offered in English, and needs a scaled score of 700 or higher to pass. A failed attempt can be retaken 24 hours later; Microsoft's own pages don't publish a question count or a pass rate, so this guide doesn't invent one.

Every fact on this page is checked against two pages fetched directly while writing it: Microsoft Learn's "Study guide for Exam GH-600: Developing in Agentic AI Systems," and its "GitHub Certified: Agentic AI Developer" page, both at learn.microsoft.com, read on October 26, 2026. Where either page changes a weight, a price, or a domain, this page should change too; nothing here is sourced from a third-party practice-exam site or a forum post.

This domain is about where an agent fits in your development process, not just whether it works. Microsoft's study guide breaks it into three pieces: fitting agents into the SDLC (identifying which steps an agent should perform, spotting common anti-patterns, and defining inputs, outputs, and success criteria up front); separating planning from execution (configuring an agent to produce a structured plan, validating that plan, and preventing the agent from acting until the plan is checked and approved); and configuring observability and control (setting the right degree of autonomy, producing inspectable artifacts in your normal tooling, and building in human intervention without slowing delivery to a crawl).

This week's drill: pick one real task you'd hand to a coding agent. Before you let it touch anything, make it write the plan first, as plain text: which files it will touch, the order of steps, and what "done" looks like. Read that plan and approve or reject it before a single edit happens. That's the exact boundary this domain tests: a plan the agent produces, and a human (or a rule) that checks it before execution starts.

This domain is about what an agent remembers and for how long. It covers choosing between short-term, long-term, and external memory and scoping memory to what's task-relevant, with rules for when memory expires, gets pruned, or resets; persisting state and managing context drift, meaning capturing progress and decisions as durable artifacts so an agent can resume work without repeating steps or contradicting earlier decisions, and catching drift during a long run; and keeping memory and state consistent across tools and environments, so agents share state without conflicting or stale context.

This week's drill: before you start a multi-step task with an agent, create a short state file (plain text is fine) that records the goal, the decisions made so far, and what's left. Update it after each step instead of relying on the agent's own memory of the conversation. Close the session, reopen it days later, and see whether that file alone is enough to pick up exactly where you left off.

This domain covers running more than one agent at once without them fighting each other. Microsoft's study guide groups it into operating multi-agent workflows (applying an orchestration pattern, isolating agents for parallel execution, and detecting and resolving conflicts like overlapping code changes or contradictory outputs); configuring observability across agents (producing artifacts fit for review and audit, and documenting handoffs and decisions); detecting and responding to multi-agent failures (spotting stalled or degraded executions and applying recovery patterns, including rollback and human-in-the-loop); and managing the lifecycle of agents inside a workflow without disrupting it.

This week's drill: give two coding agents the same repository, each in its own branch, each with an overlapping change (the same file, different edits). Let both finish, then resolve the merge conflict yourself and write one sentence on which overlap you'd prevent next time, by scoping one agent to a different file, or sequencing the two tasks instead of running them in parallel.