Domain 1: Using GitHub Copilot Responsibly
- Accountability for merged code stays with the human developer and reviewers, not with Copilot; accepting and committing a suggestion makes you the owner of that code.
- Copilot suggestions are statistically plausible completions, not verified-correct implementations, so you must read and reason about every suggestion before accepting it, especially edge cases like unusual date formats or locales.
- Copilot can hallucinate plausible-but-fake APIs, method names, or CLI flags (for example a git flag that follows the naming style but was never implemented) because it predicts likely tokens rather than consulting real documentation.
- Training-data staleness means Copilot may keep suggesting deprecated libraries (such as Microsoft's ADAL after the recommended migration to MSAL) if its data predates the shift.
- Never place live credentials, hardcoded API keys, passwords, or real customer personal data in source or prompts; replace secrets with an environment variable or secret-manager reference.
- A code-referencing / public-code match should trigger review of the actual license terms and a decision to rewrite or add attribution before shipping.
- A substantive responsible-AI policy defines which tasks suit delegation, requires reviewers to check for bias and non-inclusive language, and keeps accountability with people; it is not a font-size rule or a daily accepted-suggestion quota.
- Human oversight in practice means requiring a person to review and explicitly approve every AI-assisted change before merge; standard pull request records already capture the accountability trail.
- Aggregate Copilot metrics at the team level to support learning, not leaderboards or manager-only individual tracking, which pressure developers and discourage honest use.
- For highly sensitive or regulated repositories, disabling Copilot can be the correct control; keep a central, auditable record of where and why it is disabled.
- Better context (descriptive names, comments, and visible type definitions) produces more accurate suggestions, while repeatedly regenerating the same prompt hoping for a better result does not.
- Escalate uncertainty about security-sensitive routines such as password hashing rather than guessing, and watch for path-traversal risks like writing a file using an unmodified client-supplied filename.
Domain 2: GitHub Copilot Features
- Copilot plans progress from Copilot Free (limited completions and chat, verified students and teachers get Copilot Pro free) to Pro, Pro+ (a considerably larger premium-request allowance and access to the newest premium models), Business, and Enterprise.
- Each Copilot Business seat includes the same base premium-request allowance as an individual Pro subscription; organization owners assign seats and can delegate seat management, but developers cannot self-assign a seat.
- The Copilot coding agent is an asynchronous, cloud-hosted agent: you delegate a GitHub issue to it (or launch it from chat), it runs on GitHub Actions, creates its own branch, pushes commits, and opens the pull request itself, then iterates when you leave review comments; the Agents panel and agent sessions view track its progress.
- Agent mode inside the IDE (VS Code and other editors) is autonomous and interactive: from a single natural-language goal Copilot plans the steps, edits across multiple files, runs terminal commands and tests, reads the resulting errors, and iterates until the task is done, choosing the relevant files itself rather than being pointed at them.
- Copilot Edits (edit mode) applies a natural-language change across a developer-chosen set of multiple files in one session and shows every proposed edit inline to accept or discard file by file; it is more scoped and directed than agent mode, which decides its own scope and can run commands.
- Copilot code review runs automated reviews on pull requests that appear alongside human comments, can be required through organization policy, and can enforce custom review standards (coding guidelines written in natural language) so its feedback matches the team's conventions.
- Copilot can generate a pull request summary that describes the change set and gives a file-by-file walkthrough; the description is inferred, so you review it against the actual diff before publishing.
- GitHub Spark builds and deploys full-stack micro-apps from a natural-language description with no local setup, generating the code, wiring up data, and hosting the result so an idea becomes a running app quickly.
- The standalone Copilot CLI runs independently of any editor and works over a plain SSH session, whereas the IDE's integrated terminal panel is an editor feature; the terminal chat participant answers using recent terminal commands and output.
- Official Copilot Chat surfaces include the IDE, github.com, the GitHub mobile app, and Windows Terminal, and each surface is governed by its own distinct organization policy toggle.
- MCP (Model Context Protocol) is an open standard that lets Copilot agent mode and the coding agent connect to external tool and context servers (for example a database, a design tool, or the GitHub MCP server) so the model can call live tools and pull in real data from beyond the repository.
- A Copilot Space bundles curated material (onboarding guides, repositories, docs, decision records) into one reusable, shareable context so a team gets consistent background without re-adding sources each time.
- A repository-level copilot-instructions.md file is applied automatically as background context for chat in that repository.
- Inline suggestion keys act on the visible ghost text: Tab accepts, Escape dismisses, and Alt+] cycles to the next suggestion; the persistent Chat view opens from the Chat icon in the Activity Bar.
- The audit log tracks administrative actions such as policy changes and seat assignments, not code content or keystrokes.
- An enforced enterprise policy fixes a setting for every member organization with no local override; getting started in a JetBrains IDE like IntelliJ IDEA begins with installing the official plugin from the Marketplace and signing in.
Domain 3: Copilot Data and Architecture
- Every request passes through GitHub's Copilot proxy even when a different underlying model handles generation, keeping the architecture consistent across model choices.
- The proxy layer screens prompts for toxic or offensive content before inference, so problematic input is caught early rather than after generation.
- The suggestion lifecycle runs prompt building, inference, then post-processing (including public-code matching and deduplication), then ranking by a quality/confidence score, with the top-ranked candidate shown as inline ghost text.
- Copilot generates suggestions from learned patterns and does not compile or execute code to verify correctness, so a suggestion can look reasonable yet fail to build or run.
- The context window is measured in tokens (sub-word units), and cost and resource use scale with token count, so unusual identifiers and dense minified code consume more tokens per character.
- When a prompt exceeds the token limit, Copilot truncates lower-priority context (distant lines, less-relevant tabs) while preserving the code closest to the cursor; it does not reject the request outright.
- Copilot Business and Enterprise usage is excluded from training GitHub's models by default; an Individual account has a personal opt-in toggle the user controls.
- Copilot's context comes from files that are opened, referenced, or supplied (recently closed files can linger for a period), not from automatic awareness of the whole repository.
- Suggestion quality tracks how well-represented a language is in training data: sparse languages like legacy COBOL yield weaker output, and a language absent from training data produces unreliable or invented syntax.
- A model reflects only what existed up to its knowledge cutoff, so newer releases and post-cutoff best practices fall outside its awareness.
- A comment or clear intent written just before the cursor becomes part of the context used to build the completion prompt, and a chat request pairs a natural-language question with the selected code.
- Typed feedback is a deliberate opt-in submission rather than passively collected telemetry.
- Organization and enterprise admins govern Copilot through policies that enable or disable individual features (Copilot Chat, the coding agent, MCP, Copilot in the CLI and mobile), set which repositories and members have access, and are inherited by every member organization when enforced at the enterprise level.
- Copilot exposes multiple underlying models (for example different OpenAI, Anthropic Claude, and Google Gemini models) that a user picks from a model selector; admins control which models are available through a model-selection policy, and every choice still routes through the same Copilot proxy.
- The suggestion-matching (public-code duplicate-detection) policy is an admin control that decides whether completions matching public code are blocked or allowed, and it sits alongside content exclusion as one of the organization-level Copilot policies.
- Plan tier shapes the data-handling architecture: Business and Enterprise exclude prompts and suggestions from training by default and add controls like content exclusions and the audit log, while Free and Pro rely on the individual account's personal data-sharing toggle.
Domain 4: Prompt Engineering and Context Crafting
- The three core components of a well-formed prompt are context (relevant background), intent (the desired outcome), and specificity (concrete inputs, constraints, or examples); omitting any one tends to yield vague responses.
- Zero-shot gives no example, one-shot provides exactly one worked example before asking Copilot to continue, and few-shot supplies several examples to pin down the pattern.
- Prompt files let a team save and reuse a well-crafted, on-demand prompt across members, while custom instructions apply ambient guidance to all interactions; a good prompt file specifies output format and expected inputs.
- Reference the exact file with a chat file reference (for example #file) to bring its real content into context instead of relying on the model guessing.
- Close unrelated files and keep relevant ones open, and add relevant imports and type hints, to reduce noise and prime Copilot toward the intended library and data shapes.
- Avoid contradictory instructions, such as requiring an unchanged signature while also adding new required parameters; decide which constraint actually applies and state it clearly before re-prompting.
- Long conversations consume more of the token budget and can dilute the most recent request, so restate or summarize the still-relevant points to re-anchor context, or start a fresh conversation seeded with just the useful conclusion.
- For debugging, describe both the expected and actual behavior plus the language or framework, since a bare stack trace and the word fix do not give the model enough context.
- Break a complex feature into one prompt per subsystem and carry forward the accepted results to keep the task manageable.
- Assigning a specialized persona (for example a security reviewer) surfaces domain-specific considerations a generic question would miss.
- When defining a pattern such as a regex, show both strings that should match and strings that should not to fix the boundary precisely.
- A single prompt can request both the generated code and an explanation of the reasoning behind it, and comparing retried responses on edge-case handling, tradeoffs, and complexity is a sound way to evaluate them.
- A repository-wide instructions file at .github/copilot-instructions.md is picked up automatically and prepended as ambient context to Copilot Chat, edits, and reviews in that repo, making it the place to state the stack, conventions, and do-not-do rules the model should always follow.
- Path-specific instruction files (.github/instructions/*.instructions.md) use an applyTo glob in their frontmatter so their guidance applies only to matching files, letting you give different rules to, say, test files versus production code.
- Prompt files are Markdown files with a .prompt.md extension stored in the workspace; each packages a reusable, runnable task (with optional frontmatter for mode, tools, and description) that any team member can invoke on demand, which is distinct from always-on instructions.
Domain 5: Developer Productivity with Copilot
- Copilot Chat can propose plausible reasons a query is slow (a missing index, an unneeded join), but these are hypotheses from the query structure that you must confirm against the real schema and execution plan.
- Generate test fixtures by describing the schema's field names and types and asking for fabricated values, which produces structurally accurate data without pulling real production data into a committed file.
- Copilot can translate code between languages by mapping source logic to idiomatic target constructs (for example TypeScript interfaces from Python type hints), but subtle behavioral differences still require human review.
- Refactors that change a contract must ripple to callers: switching from thrown exceptions to a result object, splitting a class, or extracting DB calls into a repository all change the public surface, and repository extraction can silently alter transaction and connection scoping.
- High line coverage does not equal branch coverage, because a conditional line can be marked covered by hitting only one branch; genuine edge cases (empty carts, negative totals, invalid quantities) must be exercised explicitly.
- For test generation, name the desired framework or keep an existing test file open to steer Copilot toward the right conventions (for example JUnit 5), and verify a cache test actually exercises eviction, not just get and set.
- Copilot can summarize a pull request, but keep changes focused and review the generated description against the actual diff, since explanations of legacy code intent are inferred and must be checked against real history.
- Asking Copilot Chat for a different way to implement the same behavior is a brainstorming technique for alternative approaches before committing to one.
- Use Copilot as a tutor by asking it to explain a new-language idiom in terms of a language you already know, which accelerates learning versus reading unfamiliar syntax alone.
- For security-sensitive suggestions, prefer a standard-library URL parser over manual string splitting, and use a generic invalid credentials message so an attacker cannot distinguish valid from invalid usernames.
- Verify scaffolded code before merging: check that a resolver's authorization matches the data type's access rules and field names match the schema, and that queue integration tests confirm both valid and malformed messages are handled.
- Run a suggested CLI one-liner and confirm it returns the expected result before relying on it, and request internationally varied fixtures (multiple countries and postal-code formats) plus a version-controlled seeding script for safe onboarding data.
Domain 6: Privacy, Content Exclusions, and Safeguards
- Content exclusion is a path-based, admin-managed control: a repository-root pattern of "/**" excludes every file, and completions appear in a file based solely on whether that file's own path matches a rule.
- Exclusion works only by file path, so an unexcluded file (for example pricing-notes.md) can still surface the same concepts, because rules have no awareness of files that describe the same idea in other words.
- Repository-level exclusion is a flat list of path patterns configured in that repository's Settings under Copilot, while organization-level configuration pairs each repository name with its own paths.
- Content-exclusion changes can take up to about 30 minutes to propagate, and reloading or restarting the editor forces Copilot to reconnect and fetch the current rules.
- The Copilot status icon or menu in the editor reflects whether the currently open file is excluded.
- Content exclusions are a path-based access control that stops Copilot from using a file as context or offering completions in it; they are not a data-retention promise, since the no-training and no-retention guarantees come from the Business/Enterprise plan rather than from an exclusion rule.
- Public code filtering (duplicate detection) compares a candidate suggestion against public code on GitHub and matches on roughly 150 characters; the organization or enterprise suggestion-matching policy sets it to Blocked (withhold matches) or Allowed.
- GitHub's IP indemnification is available only to Business and Enterprise customers, is scoped to claims involving Copilot-suggested code, and requires the public-code matching filter to stay enabled; disabling that filter removes the indemnification basis.
- With the public code filter set to Blocked, a matching suggestion is simply withheld and the developer never sees it, unlike an Allow-plus-code-referencing configuration that surfaces the match and its source.
- Developers and organizations own the code they accept from Copilot; GitHub claims no ownership over that output, but the accepting developer must still review it before shipping.
- Copilot Business and Enterprise exclude customer prompts and suggestions from training GitHub's models, and moving from an Individual seat replaces the personal data-sharing toggle with a plan-wide no-retention, no-training guarantee.
- Opting out of the product-improvement setting changes handling of future prompts only; it does not undo processing that already occurred under the prior setting.
- Copilot Chat inherits the same privacy treatment as code completions under each plan, following the Business/Enterprise no-training guarantee or the Individual personal setting.
- The built-in filter for hardcoded-credential patterns prevents Copilot from proposing text resembling an access-key format, and GitHub's Trust Center is the authoritative source for compliance reports and data-protection documentation; a network appliance blocking Copilot's required hosts causes simultaneous connection errors for all developers.
GitHub Copilot exam tips
- Copilot is a probabilistic assistant, not an oracle: on nearly every question, the safest answer preserves human review, verification, and accountability rather than blind trust in the output.
- Learn the plan matrix cold (Free, Pro, Pro+, Business, Enterprise) plus who owns seat assignment, which capabilities are policy-gated per surface, and that Business/Enterprise exclude data from training by default.
- Memorize the suggestion lifecycle order (prompt build, proxy screening, inference, post-processing/public-code match, ranking, display) and that everything flows through the Copilot proxy regardless of model.
- Distinguish similar-sounding controls: content exclusion (admin, path-based, shared) vs the personal per-language toggle, prompt files (reusable task) vs custom instructions (ambient guidance), and public-code filter Blocked vs Allow-with-referencing.
- For IP indemnification and privacy questions, remember the qualifying condition: Business/Enterprise only, and only while the public-code matching filter stays enabled.
Study guide FAQ
Who is accountable for code that Copilot generates?
The human developer who accepts and commits the code owns it, along with the reviewers who approve the pull request. Copilot produces plausible suggestions, but responsibility for correctness, security, and licensing stays with people.
Does GitHub use my code to train Copilot's models?
Copilot Business and Enterprise exclude customer prompts and suggestions from training GitHub's models by default. Individual accounts have a personal opt-in toggle the user controls.
What does the public code matching filter do, and why does it matter?
When set to Blocked it withholds any suggestion that closely matches public code, so you never see it. Keeping this filter enabled is also a requirement for GitHub's IP indemnification on Business and Enterprise plans.
How do content exclusions work?
They are admin-managed, path-based glob rules that stop Copilot from using matching files as context or offering completions in them. They match only by file path, can take up to about 30 minutes to propagate, and other files describing the same information are not automatically excluded.
Official exam sources
The domain names and weightings on this page follow the published exam blueprint. Each source below records what it confirmed and when it was read, so the split can be checked rather than taken on trust.
- Microsoft Learn - GitHub exam GH-300 study guideBlueprint revised August 7, 2026 · link and content verified 8 September 2026SIX skills areas: Use GitHub Copilot responsibly (15-20%); Use GitHub Copilot features (25-30%); Understand GitHub Copilot data and architecture (10-15%); Apply prompt engineering and context crafting (10-15%); Improve developer productivity with GitHub Copilot (10-15%); Configure privacy, content exclusions, and safeguards (10-15%). Pass mark 700. Count these from the per-section headings, not from the "Skills at a glance" summary, which carries a duplicated bullet - "Use GitHub Copilot features (25-30%)" followed by "GitHub Copilot features (25-30%)" - and would give seven. The page also has a Change log table comparing the skills "prior to August 7, 2026" with those "as of August 7, 2026"; that is a change log, not a second blueprint. Our six domains match Microsoft's six in order and substance, and our weights 19/29/13/13/13/13 sit inside every published range (Microsoft's midpoints total 95, so ours are scaled to 100).