GH-300 GitHub Copilot Study Guide

Independent AI-assisted resource — HUMAN REVIEW PENDING. The October 28, 2026 detailed refresh maps all 41 objectives in the retained teaching baseline and checks current public product evidence. See the current refresh record and sources-and-objectives record. The official blueprint is authoritative. Product/tenant execution and human review remain separate; limitations and source conflicts are stated below.

Study guide at a glance

Start here

Report an issue with GH-300

Blueprint checked2026-10-28

Review stateReview required

Guide-only active reading1 hr 45 min–2 hr 30 min

Prerequisites: GitHub fundamentals, a basic software-development workflow, and GitHub Copilot access for the hands-on labs.

Exam essentialsRead the objective map, key distinctions, and readiness checklist.

Deep understandingWork through every domain, including decisions, failure modes, and related items.

Hands-on labsBegin with Lab 1: Learn GitHub flow with Terraform, then use the remaining labs to produce evidence you can inspect and explain.

Official objective domains

• Use GitHub Copilot responsibly15–20%
• Use GitHub Copilot features25–30%
• Understand Copilot data and architecture10–15%
• Apply prompt engineering and context crafting10–15%
• Improve developer productivity10–15%
• Configure privacy, exclusions, and safeguards10–15%

The active-reading range uses 90–130 words per minute for technical material. Labs, troubleshooting, note-taking, spaced review, and prerequisite gaps add time; it is not a total preparation promise.

Responsible use, features, data architecture, context, productivity, safeguards, and governance

Prepared / refreshed: October 28, 2026
Exam: GH-300 GitHub Copilot
Current baseline: Skills measured as of August 7, 2026
Upcoming blueprint change: None announced on the official study guide checked October 28, 2026. The credential page remains the starting point for booking and current requirements.

Credential lifecycle — VERIFY CURRENT: That page describes the transition to Microsoft's recertification process, including a six-month extension for certifications that would expire before the new process is available. Check your individual credential record and the current notice; an extension is not a new exam-objective date.

Source-review blocker — October 28, 2026: The current exclusion how-to and September CLI availability announcement conflict. This refresh preserves the disagreement and supplies a harmless verification worksheet; exact client/plan behavior remains untested. The source gate stays blocked. Legacy PDF/API metadata is kept distinct from the current six-domain outline and booking page.

VERIFY CURRENT: Copilot changes rapidly. Recheck pricing, plans, models, feature availability, previews, UI paths, commands, quotas, credits, data handling, and retention in the linked official documentation. Those details are synchronized only to the last_verified date above and can change without an exam-blueprint revision.

This standalone guide maps the August 7, 2026 blueprint and uses Timothy Warner's current September course companion as supplementary learning. Corrections to older June material are retained explicitly as history, not as claims about the current repository.

The current official blueprint is the final authority:

• Microsoft GH-300 study guide
• GitHub Copilot documentation

Living-guide watch — October 28, 2026

Historical September policy announcement — VERIFY CURRENT: The August notice scheduled, no earlier than September 28, the unification of Copilot cloud agent, Copilot Chat on github.com, and Copilot Chat in GitHub Mobile under one policy that is enabled by default. The github.com experience moves to agent sessions, and chat data changes from 28-day retention to the life of the account. Administrators should review the unified setting rather than assuming the old policies or retention model remain separate. The same policy and billing announcement says the Default code-review effort becomes Balanced September 28 and documents upfront seat billing changes for card/PayPal customers while stating that plan prices do not change.

Model lifecycle checkpoint — VERIFY CURRENT (October 28): The current supported-model catalog no longer lists the four models named for October 2 retirement: Gemini 3.5 Flash, Gemini 3.6 Flash, Kimi K2.7 Code and Claude Opus 4.7. Compare the dated retirement notice with the current catalog and effective model policy. A plan name or suggested alternative does not establish that a specific client/account can use it; do not memorize this list as a permanent exam fact.

Policy checkpoint whose date has passed — October 22: GitHub's September 24 announcement gives administrators time to configure the default for eligible GA features. Beginning October 22, unconfigured features follow that default; explicit feature choices remain effective and previews are excluded. The default is enabled unless changed. Check both enterprise decisions and delegated organization settings using the default-availability documentation. This is a product-policy transition, not an announced exam revision.

Concern and study decision: These announcements are authoritative for current operations but are too volatile to treat as durable exam facts. Learn how policy inheritance, retention disclosure, model allowlists, budgets, seat lifecycle, and defaults affect governance. Verify the current model catalog, exact billing contract, settings labels, and effective dates rather than memorizing this snapshot.

How to use this guide

For a focused first pass, read Part 0's worked examples, complete Lab 6, then attempt Scenarios 9–13 before looking at their answers. Use Lab 7 to connect policy decisions to observable controls. The examples are original learning exercises; cloud, IDE, and enterprise-policy behavior must be checked in your own supported environment.

Begin with Part 0 to understand the complete exam map. Read Parts 1 and 2 slowly because they explain GitHub's operating model and how standards become enforceable. Parts 3 through 6 focus on current Copilot capabilities. Complete the labs rather than merely reading their steps. Finish with the exam distinctions and readiness checklist.

About related items: A Related item: callout adds prerequisite, operational, architectural, or adjacent context that makes the current topic easier to understand. It is useful supporting knowledge, not a claim that the item appears verbatim in the published exam objectives.

The most important mental model is:

Copilot instructions help produce a compliant change. GitHub Actions test the change. Ownership routes it to the right reviewers. Rulesets prevent the change from merging until the required evidence and approvals exist.

---

Part 0: Complete blueprint coverage

Current objective map

Domain	Weight	Main coverage
Use GitHub Copilot responsibly	15–20%	This part; Parts 4 and 5
Use GitHub Copilot features	25–30%	Parts 3, 4, and 6
Understand Copilot data and architecture	10–15%	This part and Part 5
Apply prompt engineering and context crafting	10–15%	This part and Parts 3–4
Improve developer productivity	10–15%	This part and labs
Configure privacy, exclusions, and safeguards	10–15%	Parts 5 and 6

The official page currently contains a duplicated “GitHub Copilot features” line in its high-level list. Treat the detailed objective groups and their published ranges as authoritative; do not treat the repeated label as an additional domain.

Responsible AI

Microsoft’s six current Responsible AI principles are:

1. Fairness: Examine generated logic and data for unequal treatment or biased assumptions.
2. Reliability and safety: Test output, handle failures, and constrain consequential actions.
3. Privacy and security: Protect secrets, personal information, proprietary material, and system access.
4. Inclusiveness: Consider accessibility and users with different abilities and circumstances.
5. Transparency: Make AI involvement and important limitations understandable.
6. Accountability: A human or organization remains answerable for accepted decisions and code.

These principles are defined in Microsoft's current Responsible AI overview. The exam application is practical: identify a risk, choose a mitigation, define validation evidence, and keep a human accountable for the outcome.

Risks and limitations

Copilot can produce:

• Plausible but incorrect code or explanations
• Insecure defaults and incomplete validation
• Outdated APIs or nonexistent functions
• Biased assumptions in logic, examples, or test data
• Code that resembles public code
• Tests that validate the generated implementation instead of the real requirement
• Excessive permissions or destructive commands
• Confident explanations that hide uncertainty

Mitigate these risks with precise scope, authoritative documentation, tests, static analysis, dependency review, security scanning, least privilege, human review, and production change controls.

Copilot confidence is not evidence. A passing validation command, inspected diff, security result, or authoritative reference is evidence.

Responsible operation

• Never submit unapproved sensitive information merely to obtain a better answer.
• Validate generated code in an isolated, appropriate environment.
• Review packages, licenses, network calls, permissions, and data flows.
• Preserve human approval for production deployment and destructive change.
• Report harmful or incorrect output through appropriate feedback channels.
• Keep responsibility with the person or team accepting the work.

Related item: Treat consequential Copilot use as a lightweight model-risk workflow: define the allowed task, data boundary, validation evidence, human decision owner, and rollback. This operationalizes responsible-AI principles without pretending every suggestion needs the same level of governance.

Data handling and architecture

At an exam level, understand this request lifecycle:

1. The user provides an explicit prompt or triggers a suggestion.
2. The client gathers applicable context, such as cursor location, surrounding code, open files, instructions, chat history, or explicit references.
3. Copilot constructs and transmits the request through its service.
4. Input processing and proxy filtering apply.
5. The selected model generates candidate output.
6. Post-processing and filters apply, including safety and public-code mechanisms where configured.
7. The client presents a suggestion, response, diff, or proposed tool action.
8. The developer accepts, rejects, edits, or validates the result.

GitHub's responsible-use description of inline suggestions documents the input-processing, model-generation, response, and filtering lifecycle for that surface. Other Copilot surfaces can add tools, retrieval, or agent orchestration, so do not assume every feature has an identical pipeline.

Do not describe “statistical analysis and pattern recognition” as a separate Copilot product-processing stage. It is a broad description of model behavior, not one of the named service stages the exam-oriented material emphasizes.

Prompt and context data

Context can include code, selections, filenames, repository instructions, prompt files, chat history, tool output, and retrieved resources. What is sent or retained depends on the feature, plan, client, policy, model host, and current terms.

VERIFY CURRENT: Review GitHub's current data-handling, model-hosting, retention, and BYOK documentation before making a customer claim. Do not generalize a zero-retention statement from one model/provider/GA feature to every preview feature or integration.

Limitations of finite context

An LLM cannot attend equally to unlimited information. Large irrelevant attachments can dilute important requirements. A client may select context automatically, use semantic retrieval, or compact conversation history. Compaction can preserve a summary while losing exact detail.

Keep durable decisions in repository artifacts such as issues, ADRs, instructions, tests, and code—not only in chat history.

Related item: Retrieval-augmented generation (RAG) and semantic retrieval can select relevant external context without retraining the model. Retrieval improves grounding, but stale, unauthorized, poisoned, or irrelevant sources can still produce a well-written wrong answer.

Prompt engineering and context crafting

A strong prompt normally contains:

Element	Question answered
Goal	What outcome is required?
Context	What code, system, or problem matters?
Constraints	What must or must not change?
Examples	What pattern should the response follow?
Validation	How will success be demonstrated?
Output format	Plan, patch, explanation, table, test, or command?

This structure operationalizes GitHub's current prompt-engineering guidance: start with the goal, provide relevant context and examples, split complex work, avoid ambiguity, iterate, and keep history relevant.

Example:

Review modules/key-vault for public exposure and excessive RBAC. Do not modify files. Compare the module with the repository instructions, cite file paths and line-level evidence, classify each finding by severity, and finish with the exact Terraform validation and security commands you recommend.

Zero-shot and few-shot prompting

• Zero-shot: Request the task without a worked example. It is efficient when the instruction and expected pattern are clear.
• Few-shot: Include one or more examples to demonstrate structure, naming, classification, or style. It helps when the desired pattern is difficult to describe precisely.

Examples consume context and can accidentally teach defects. Use the smallest representative set and explicitly state which features of the example matter.

Iterative prompt flow

For a substantial change:

1. Ask Copilot to explain the current system.
2. Request a plan without edits.
3. Correct assumptions and narrow scope.
4. Request implementation.
5. Inspect the diff and tool activity.
6. Run deterministic validation.
7. Ask for a review against the original requirements.
8. Perform final human review.

Specific, relevant context is more valuable than verbosity. “Surround” in older course terminology means providing useful surrounding context; it does not mean attaching everything.

Related item: Context engineering extends prompt writing to the whole information environment: instructions, selected files, tool results, examples, memory, and output contracts. The security boundary must cover every context source, not just the words typed by the user.

Improving developer productivity

Copilot can assist with:

• Code generation and boilerplate
• Refactoring and code explanation
• Documentation and comments
• Sample or synthetic data
• Legacy-code modernization
• Unit and integration tests
• Edge-case discovery and assertions
• Security and performance suggestions
• Learning unfamiliar languages, frameworks, or repositories

GitHub's Copilot best-practices guide describes both these productivity uses and the obligation to check Copilot's work. The productivity gain comes from reducing mechanical work and context switching—not from eliminating review.

Refactoring and modernization

Preserve behavior with characterization tests before a risky refactor. Ask Copilot to identify public interfaces, side effects, data formats, and compatibility constraints. Modernization should be incremental and measurable; generated “cleaner” code can still change behavior.

Use GitHub's refactoring walkthrough as a practice pattern, not a guarantee that a generated refactor preserves behavior.

Tests and assertions

Keep these distinct:

• A precondition/input assertion checks whether data is valid before processing.
• A test assertion compares actual behavior with expected behavior.

Generated tests need independent review. A model can reproduce the same misunderstanding in both implementation and test. Include normal cases, boundaries, invalid inputs, permissions, failure paths, and regression cases.

The official writing tests with Copilot tutorial provides unit- and integration-test examples while also distinguishing simple generation from complex cases that need more detailed prompting.

Security and performance suggestions

Treat Copilot findings as hypotheses. Confirm security claims with threat modeling, scanners, provider documentation, and review. Confirm performance claims with profiling or measurement. A change that is theoretically faster may reduce clarity or have no effect on the real bottleneck.

---

Worked examples: turn a suggestion into evidence

These synthetic examples connect responsible use, context, testing, and productivity. They can be completed with a small local Python repository; no production data is needed.

Example 1: Write the acceptance criteria before asking for code

Suppose an order subtotal is a nonnegative integer number of cents. Shipping costs 499 cents below a subtotal of 5,000 cents and is free at or above that threshold. Negative values, non-integers, and booleans are invalid. Currency conversion, tax, and discounts are outside this function's contract.

A useful request identifies the existing function, supplies this contract, asks for a small patch, and requires tests. A weak request such as “fix checkout” leaves the threshold and invalid-input behavior unstated. Establish expected results independently:

Input	Expected outcome	Defect it can expose
0, 4999	499 shipping cents	Wrong default or unit conversion
5000, 5001	0	Off-by-one threshold
-1	Reject	Missing domain validation
50.0, "5000", True	Reject	Accidental coercion; Python booleans count as integers in some type checks

If Copilot writes subtotal > 5000, a test copied from that implementation may bless the bug. Your requirement-derived 5000 case rejects it. Ask Copilot to explain the failing boundary, inspect its patch, run the tests, and review the diff for unrelated edits. Passing these cases supports this limited contract; it does not establish security or correctness for an entire checkout system.

Example 2: Supply a small, relevant context packet

For the same task, provide the shipping function, its caller's input type, existing test conventions, the acceptance table, and the exact failing assertion. Omit customer orders, credentials, and unrelated generated files. Ask the assistant to state any missing requirement before editing.

Compare two fresh sessions: a vague request and the same request with that packet. Keep the task and test oracle fixed; record missing assumptions, correction turns, unnecessary file edits, and final test results. Do not rank answers only by how confident they sound. Repeat on several tasks before drawing a productivity conclusion.

Christina Warren's context-engineering article helps explain why instructions, reusable prompts, and specialized agents serve different purposes. Use the canonical filenames in Part 2: the article's plural *.prompts.md spelling is not this guide's prompt-file convention. Joe Binder's context handling and routing article explains VS Code harness optimizations such as cached prompt prefixes and deferred tool definitions. Those implementation examples do not promise that every client sends identical context or that your workload achieves the article's internal performance results.

Example 3: Put each requirement in the right control

Requirement in the shipping task	Suitable mechanism	Evidence to inspect
Always use integer cents in this repository	Repository instructions	Supported client loads the intended instructions
Follow Python test conventions only in test files	Path-specific instructions	Matching path and supported application of the file
Reuse the boundary-review task on demand	Prompt file	Explicit invocation with current requirements and diff
Let a specialist inspect code without deploying	Custom agent with restricted tools	Actual available tools, identities, and approval controls
Block merges when the shipping test fails	Required status check in a ruleset	Failed check on the relevant commit prevents merge

Instructions guide generation. They cannot substitute for tool authorization, a passing test, or an enforced merge rule. A sub-agent's separate conversation context also does not, by itself, establish separate filesystem access or credentials. Inspect those boundaries before delegating.

Example 4: Measure whether the team benefits

In a synthetic pilot, median coding time falls from 40 to 25 minutes, but review and rework rise from 20 to 40 minutes. Total median-stage estimates rise from 60 to 65 minutes, so faster drafting alone is insufficient evidence of a better delivery process. These sums illustrate a budget; obtain actual end-to-end observations because sums of separate medians need not equal the median total.

Track comparable task cohorts, defect escapes, review effort, successful completion, and user experience alongside usage. The September 25 review-stage metrics release separates waiting for first review, review iteration, and waiting to merge. Its current stage timings count qualifying human reviews, exclude Copilot/bot review timings, and have no historical backfill. An empty array means no qualifying observations that day, not zero elapsed time. These metrics can locate a bottleneck; they cannot alone prove that Copilot caused a change.

Part 1: GitHub foundations

1. Git and GitHub are related but different

Git is the distributed version-control system on your computer. It stores snapshots of files as commits and tracks the relationships among those commits.

GitHub hosts Git repositories and adds collaboration and governance:

• Pull requests
• Reviews and approvals
• Issues and projects
• Teams and permissions
• GitHub Actions
• Rulesets and branch protection
• Security scanning
• Audit logs
• Copilot administration

You can use Git without GitHub. GitHub depends on Git concepts but adds the workflow around them.

2. The four local Git areas

When working locally, think in four areas:

Area	Meaning	Common command
Working tree	Files currently on disk	git status
Staging area/index	Changes selected for the next commit	git add
Local repository	Commits stored locally	git commit
Remote repository	Shared repository hosted on GitHub	git push and git pull

A commit does not automatically reach GitHub. git commit writes locally; git push publishes commits to a remote.

3. Commits, branches, and remotes

Commits

A commit is a snapshot plus metadata:

• Parent commit
• Author and committer
• Timestamp
• Message
• Tree of tracked content

A good commit is understandable, focused, and reversible. Avoid combining unrelated changes.

Branches

A branch is a movable reference to a commit. Creating a branch is inexpensive because Git does not copy the entire repository.

Typical commands:

git switch main
git pull --ff-only
git switch -c feature/add-private-key-vault

git pull --ff-only prevents Git from silently creating a merge commit during a routine update. Teams may choose a different policy, but you should understand what yours does.

Remotes

The conventional remote name is origin:

git remote -v
git push --set-upstream origin feature/add-private-key-vault

--set-upstream connects the local branch to its remote tracking branch. Future git push and git pull commands can then omit the branch name.

4. Branch versus fork

Branch	Fork
Another line of work inside the same repository	A separate repository derived from the original
Normally used by collaborators with write access	Common for external contributors or stronger isolation
Shares repository settings and Actions configuration	Has separate settings, permissions, and Actions considerations
Pull request usually targets another branch in the same repository	Pull request crosses from the fork into the upstream repository

For an internal platform team, feature branches are common. For open source or untrusted contributors, forks are common.

5. GitHub flow

GitHub flow is a lightweight change lifecycle:

1. Start from an updated default branch.
2. Create a feature branch.
3. Make focused changes.
4. Commit and push.
5. Open a pull request.
6. Run automated checks.
7. Review and revise.
8. Merge after requirements pass.
9. Delete the feature branch.

The official overview is GitHub flow.

Example:

git switch main
git pull --ff-only
git switch -c feature/diagnostic-settings

# Edit files
terraform fmt -recursive
git status
git diff

git add modules/monitoring variables.tf
git commit -m "feat: add diagnostic settings support"
git push -u origin feature/diagnostic-settings

If GitHub CLI is installed, you can open a pull request with:

gh pr create --fill

Remember that gh is GitHub CLI. The standalone copilot command is GitHub Copilot CLI. They are separate products.

6. Pull requests

A pull request is a proposal to merge one branch into another. It is not merely a request to copy files. It becomes the collaboration and evidence record for a change.

A useful pull request explains:

• Why the change is needed
• What changed
• How it was validated
• Security implications
• Deployment or rollback considerations
• Expected Terraform replacements or downtime
• Related issue or requirement

The pull request aggregates:

• Commits and file diffs
• Review conversations
• Approvals
• Status checks
• Copilot review comments
• Links to issues and deployments

Draft pull requests

A draft PR signals that the work is not ready for final review. Automated checks can still run, and early feedback can still be collected.

Review outcomes

Reviewers can:

• Comment without approving or blocking
• Approve
• Request changes
• Add suggested changes

Copilot code review provides recommendations and an approval assessment. In the current public preview, administrators can also enable Copilot to submit an approval that counts toward a repository's required-approval rule. The capability is off by default and governed at enterprise, organization, and repository scope. An assessment alone does not count as approval, and accountable people still own the policy and merge risk. See Copilot code review approvals.

7. Merge strategies

Strategy	Result	Useful when
Merge commit	Preserves branch commits and adds a merge commit	Branch history and grouping matter
Squash and merge	Combines the PR into one commit	Feature branches contain noisy incremental commits
Rebase and merge	Replays commits onto the base branch without a merge commit	A linear history is required and commits are already clean

No strategy is universally correct. The organization should choose and document a consistent approach.

For infrastructure repositories, squash merging is often convenient because it creates one easily reversible commit per PR. A mature team may preserve multiple commits when they represent meaningful, independently reviewable steps.

8. Merge conflicts

A merge conflict occurs when Git cannot safely reconcile competing changes. The developer must choose the correct final content, not merely remove conflict markers.

A safe routine is:

git fetch origin
git rebase origin/main

# Resolve files, then:
git add <resolved-files>
git rebase --continue

To abandon the rebase:

git rebase --abort

After rebasing a branch that was already pushed, updating the remote normally requires a guarded force push:

git push --force-with-lease

--force-with-lease is safer than --force because it refuses to overwrite remote work you have not observed.

9. Repository, organization, and enterprise hierarchy

flowchart TD
    E[Enterprise account] --> O[Organization]
    O --> T[Teams and roles]
    O --> R[Repositories]
    R --> B[Branches and pull requests]
    R --> A[Actions and environments]

Enterprise account

The enterprise is the top governance boundary. It can establish identity, security, Copilot, Actions, repository, and audit policies across organizations.

Organization

An organization is a container for shared repositories, teams, members, policies, billing, and audit data. Organization owners administer it.

Team

A team groups people for scalable access and ownership. Teams can be nested and assigned repository roles.

Examples:

• azure-platform
• terraform-maintainers
• security-reviewers
• application-developers

Repository roles

Common repository roles progress from least to most privilege:

• Read
• Triage
• Write
• Maintain
• Admin

Grant the lowest level needed. Avoid giving repository admin simply because a user needs to merge code.

See roles in an organization.

10. GitHub Actions and status checks

A GitHub Actions workflow is a YAML file under .github/workflows/. An event triggers the workflow; jobs run on runners; steps execute actions or commands.

Example Terraform PR checks:

name: Terraform pull request validation

on:
  pull_request:
  merge_group:

permissions:
  contents: read

jobs:
  terraform-quality:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: hashicorp/setup-terraform@v3
        with:
          terraform_version: 1.14.0

      - run: terraform fmt -check -recursive
      - run: terraform init -backend=false
      - run: terraform validate

The workflow checks the change, but it does not automatically block merging. A ruleset or branch-protection rule must require the resulting status check.

This example assumes Terraform configuration at the repository root and runs for every pull request, including documentation-only changes. Select the actual configuration directory and approved tool/action versions for your repository. merge_group also supplies the check when a merge queue is used. A workflow skipped by a path filter can leave its required check pending; a conditionally skipped job has different semantics. See troubleshooting required checks. Verify both code and documentation-only pull requests before requiring this workflow. The example has not been run against a Terraform project during this review.

Reusable workflows

A reusable workflow centralizes validation logic. It uses workflow_call:

on:
  workflow_call:

A consuming repository calls it as a job:

jobs:
  validate:
    uses: contoso-cloud/shared-workflows/.github/workflows/terraform-quality.yml@v2

Reusable workflows reduce copy-and-paste drift. Pin them to an approved tag or commit according to organizational policy. See reusing workflows.

11. CODEOWNERS

CODEOWNERS maps paths to accountable users or teams:

# Terraform files
*.tf @contoso/terraform-maintainers

# CI/CD workflows
.github/workflows/ @contoso/platform-engineering

# Copilot and agent configuration
.github/copilot-instructions.md @contoso/ai-governance
.github/agents/ @contoso/ai-governance

Important distinction:

CODEOWNERS requests the appropriate reviewers. It does not require their approval unless a ruleset or branch rule requires code-owner review.

12. Rulesets and branch protection

Rulesets protect branches and tags. A typical main ruleset may require:

• Changes through pull requests
• One or two approvals
• Code-owner approval
• Resolved conversations
• Passing Terraform and security checks
• Signed commits
• Linear history
• No force pushes
• No branch deletion

Required status checks prevent merging until the selected checks pass. See available rules for rulesets.

Rulesets are preferable to relying on developer memory. They convert an expectation into a platform control.

13. Environments and deployment approvals

GitHub environments represent targets such as dev, qa, and production. They can contain:

• Environment secrets and variables
• Required reviewers
• Deployment branch restrictions
• Wait timers
• Protection rules

A production workflow should authenticate to Azure through OIDC where possible instead of storing long-lived client secrets.

---

Part 2: How organizational standards work

14. Standards are a system, not one file

A mature GitHub standard has multiple layers:

Layer	Question answered	Example
Policy	What is allowed?	Copilot CLI enabled; unapproved models disabled
Guidance	What should people and Copilot do?	Prefer managed identities
Template	How should work begin?	Terraform repository template
Automation	Did the change satisfy a deterministic check?	terraform validate
Ownership	Who is accountable for review?	Terraform maintainers
Enforcement	Can a noncompliant change merge?	Required ruleset checks
Audit	What changed, who changed it, and what was used?	Audit-log events

Confusing these layers produces weak governance. An instruction is not an enforcement mechanism. A workflow is not mandatory unless a rule requires its result. A code owner is not an approval gate unless a rule requires that approval.

Related item: Policy as code lets an organization version, review, test, and automatically evaluate controls. It complements Copilot instructions: instructions steer generation toward the standard; policy tests provide deterministic evidence about the resulting change.

15. Copilot policy

Copilot policies control access to features, agents, and models. They are configured at enterprise and organization scopes.

An enterprise can:

• Enable a feature
• Disable a feature
• Enable it only for selected organizations
• Delegate the decision with Let organizations decide, where that option is available; an unconfigured feature can instead inherit the applicable default

An enforced enterprise feature policy constrains organizations. If the enterprise delegates, organizations can differ. VERIFY CURRENT: default availability distinguishes feature defaults from model defaults and locks Enabled everywhere / Disabled everywhere at the enterprise level. A setting called a default is not necessarily overridable. Distinguish explicit feature/model decisions, inherited values and delegated choices. Code-review effort is a separate setting with its own override contract.

For example, the September 23 code-review configuration release adds an enterprise default review effort that organizations and repositories can override, alongside expanded personal automatic-review settings. Setting review effort or automatically requesting a review does not itself require a review for merge. Inspect the separate ruleset, review outcome, and applicable approval feature described later in this guide.

Examples of policy-controlled capabilities include:

• Copilot CLI
• Agent mode
• Copilot cloud agent
• Copilot code review
• MCP usage
• Model availability
• Suggestions matching public code

See GitHub Copilot policies and policy conflicts.

16. Copilot customization mechanisms

Mechanism	Purpose	Invocation
Custom instructions	Persistent guidance	Automatically applied when supported
Prompt file	Reusable task request	Explicitly invoked
Custom agent	Specialized role with selected behavior and tools	Selected or delegated to
Agent skill	Packaged procedure, scripts, and resources	Loaded when relevant
MCP server	External tools and data	Agent calls exposed tools
Hook	Deterministic interception around agent activity	Triggered by defined events
Ruleset	Repository governance and merge enforcement	Evaluated by GitHub

Repository-wide instructions

Location:

.github/copilot-instructions.md

Good repository instructions describe durable facts and constraints:

# Azure Terraform repository instructions

- Reuse existing modules before adding direct resource blocks.
- Use managed identity instead of client secrets when supported.
- Do not enable public network access unless the requirement explicitly calls for it.
- Use typed variables with descriptions.
- Mark secret variables and outputs as sensitive.
- Run terraform fmt, terraform init -backend=false, and terraform validate.
- Explain resource replacements and expected downtime.
- Generate a plan only. Never apply infrastructure without explicit approval.

Avoid vague instructions such as "write good code." Prefer observable rules.

Path-specific instructions

Location pattern:

.github/instructions/*.instructions.md

Example:

---
applyTo: "**/*.tf"
---

- Prefer for_each when resource identity matters.
- Do not use provisioners without explaining why provider-native functionality is insufficient.
- Pin providers according to versions.tf.
- Do not add policy suppressions without a documented exception.

Path-specific instructions keep Terraform guidance from interfering with PowerShell, Python, or documentation.

Organization instructions

Organization owners can define broad instructions, but support is surface-specific. Current GitHub documentation says organization instructions are supported for:

• Copilot Chat on GitHub.com
• Copilot code review on GitHub.com
• Copilot cloud agent on GitHub.com

The September 22 JetBrains release additionally documents organization instructions in local and Copilot agent sessions in plugin 1.18.0. Verify the installed plugin, session type, and effective policy; this release does not establish support in every IDE.

Do not assume organization instructions automatically reach every developer's IDE. Repository instructions remain important. See organization custom instructions.

Prompt files

Prompt files are reusable tasks, not always-active rules:

.github/prompts/terraform-review.prompt.md

Example purpose:

Review the Terraform diff for replacements, public exposure, excessive permissions, unpinned providers, secret leakage, and missing diagnostic settings. Return findings by severity with file references.

Remember:

Instructions describe how Copilot should generally behave. Prompt files package something you deliberately ask it to do.

Custom agents

A custom agent specializes Copilot for a role such as:

• Terraform reviewer
• Security reviewer
• Test generator
• Documentation maintainer

An agent profile can define its identity, instructions, tools, and MCP servers. Restrict tool access to what the role requires.

Agent skills

An agent skill is a folder containing a SKILL.md and optionally scripts, references, examples, and templates. Skills package a repeatable capability. Timothy Warner's Cert Buddy demonstrates this well.

Review any skill before preapproving shell access. A skill with shell access can execute commands in the working environment.

MCP

Model Context Protocol connects Copilot to tools and data. An MCP server might expose:

• GitHub issues and pull requests
• Microsoft Learn documentation
• Jira or Azure Boards
• Databases
• Cloud APIs
• Browsers

MCP is a security boundary because it may expose actions, not just information. Evaluate:

• Authentication method
• Tool permissions
• Data exposed to the server
• Network destination
• Logging and retention
• Prompt-injection risk
• Whether write actions require approval
• Organization registry and allowlist policies

See About MCP and MCP management.

17. Turning a Terraform standard into an enforceable control

Suppose the standard is:

Azure resources must not expose public endpoints unless an approved exception exists.

Implement it across layers:

1. Policy: Limit risky agent and MCP capabilities.
2. Instruction: Tell Copilot to default to private access.
3. Template: Provide modules with secure defaults.
4. Automation: Run Checkov, Trivy, or organizational policy tests.
5. Ownership: Request security review when networking inputs change.
6. Enforcement: Require the security status check and code-owner approval.
7. Audit: Record exceptions and monitor policy changes.

flowchart TD
    P[Developer or Copilot change] --> C[Automated checks]
    C -->|Pass| R[Required review]
    C -->|Fail| F[Merge blocked]
    R -->|Approved| M[Ruleset allows merge]
    R -->|Changes requested| F

This is what "having Copilot follow organizational standards" should mean. Copilot improves the first attempt; deterministic controls and human accountability protect the result.

---

Part 3: Current GitHub Copilot CLI

18. Do not confuse the retired and current products

The old GitHub CLI extension used commands such as:

gh copilot suggest
gh copilot explain

That extension is retired. The replacement is the standalone, agentic GitHub Copilot CLI, launched with:

copilot

See replacement for the retired extension.

19. Installation on Windows

Current official options include WinGet and npm.

WinGet:

winget install GitHub.Copilot

npm, requiring Node.js 22 or later:

npm install -g @github/copilot

Windows requires PowerShell 6 or later. Verify the current requirements before installation in a controlled corporate environment. See installing Copilot CLI.

20. Authentication

For interactive use, launch the CLI and run:

/login

For noninteractive environments, supported token environment variables include:

• COPILOT_GITHUB_TOKEN
• GH_TOKEN
• GITHUB_TOKEN

Do not paste tokens into prompts, source files, transcripts, or command history. Copilot CLI can also fall back to an authenticated GitHub CLI token. Classic personal access tokens are not supported for Copilot CLI; consult the current authentication documentation for supported token types and permissions.

21. Trust and permissions

When Copilot CLI starts, it asks whether you trust the working directory. Trust means the agent may read, modify, and execute content beneath that location according to its permissions.

Configure deliberately:

• Trusted directories
• Allowed tools
• File-path permissions
• URL permissions
• MCP servers
• Sandbox behavior

Do not launch an agent from a broad or sensitive directory. Open the specific repository instead.

The following flags remove important confirmation boundaries:

--allow-all
--yolo

Use them only in a disposable, well-isolated environment whose contents and network access you understand.

Local sandboxing can restrict commands and tools:

/sandbox enable

See configuring Copilot CLI.

VERIFY CURRENT — permission mode is not a human decision: The October 26 assisted-permissions release adds an important distinction between manual, assisted and allow-all modes. Assisted mode can let an AI assessment approve eligible requests without a person. Enterprise controls over permitted modes and the chosen default are separate. Review actual tool/path/URL authority, mode and executed command evidence; do not treat an assisted approval as human authorization for terraform apply. No CLI mode was enabled or tested in this refresh.

22. Essential CLI commands

Commands change quickly, so /help is authoritative for the installed version.

Command	Purpose
/help	Show available commands
/login	Authenticate
/model	Inspect or change model selection
/plan	Develop an implementation plan before changing code
/review	Run code review against changes
/pr	Work with the pull-request lifecycle
/session	Display session information
/rename NAME	Give the current session a useful name
/resume	Choose and resume a previous session
/ide	Connect to or manage a VS Code workspace
/context	Inspect context-window use
/compact	Compress conversation history
/usage	Review session duration, edits, tokens, models, and credits
/chronicle	Search and analyze session history
/mcp	Inspect or manage MCP connections
/skills	Inspect available skills

From the shell:

copilot --continue
copilot --resume
copilot --resume SESSION-ID

Session data can be synced to a GitHub account by default. Understand the organization's retention and data-handling requirements before using it with customer code.

23. Plan Mode

Plan Mode asks Copilot to analyze and propose a structured plan before implementation. It creates a review gate, but it is not an authorization system by itself.

A strong Terraform planning prompt is:

Plan the addition of diagnostic settings for the existing Azure resources.
Do not edit files yet. Identify affected modules, required destinations,
provider-version constraints, replacement risk, permissions, tests, and
questions that must be answered before implementation.

Review whether the plan:

• Uses existing modules
• Respects repository boundaries
• Identifies unknown requirements
• Separates implementation from deployment
• Includes validation
• Recognizes security and replacement risk

24. Sessions and context management

A session preserves the conversation, actions, plans, and tracked files for a task. Sessions allow work to pause and resume.

Useful habits:

• Rename important sessions.
• Use one clear objective per session.
• Check /context during long work.
• Use /compact before irrelevant history displaces critical constraints.
• Start a new session when the objective materially changes.
• Review session data before sharing it.

/chronicle can generate standups, search prior work, suggest instruction improvements, and provide cost advice. See using Copilot CLI session data.

25. VS Code integration

Copilot CLI can connect to a matching trusted VS Code workspace. It can:

• Receive the active editor selection as context
• Display proposed changes as diffs
• Use current diagnostics
• Show and resume CLI sessions from the Sessions view

Use /ide to inspect or change the connection. If you bypass edit approval with --allow-all or --yolo, the normal VS Code diff approval can be skipped.

26. CLI safety checklist

Before a significant task:

• Confirm the repository and branch.
• Run git status.
• Confirm no customer secrets or unrelated files are accessible.
• Start in Plan Mode.
• Inspect enabled MCP servers and tools.
• Keep command and file approval enabled.
• Define allowed files and forbidden actions in the prompt.
• Require tests and diff review.
• Do not permit terraform apply unless explicitly authorized.

After the task:

• Review git diff.
• Run deterministic checks yourself.
• Inspect new dependencies and workflow permissions.
• Review the session for sensitive content.
• Commit only the intended files.

---

Enable IDE assistance, use Chat, and diagnose a missing suggestion

Follow the setup reference for your editor: verify a supported editor/version, install or enable its documented Copilot integration, and sign in with the GitHub account that has eligible access. Confirm organization feature policy separately from account entitlement. In a trusted disposable workspace, test a harmless inline completion and a small Chat question before enabling write-capable agent work. VERIFY CURRENT: editor-specific setup and controls; CLI authentication does not prove IDE setup is complete.

Use the IDE Chat reference for the selected client. Ask, Plan, Edit and Agent capabilities differ by editor/version and policy. Add the intended file or selection, inspect references, and start a fresh conversation when old context is misleading. Discover available slash commands in that client's command menu; CLI session commands are not automatically IDE Chat commands. Provide feedback through the supported response controls after inspecting what context and output it contains. Model choice, quotas, input size and available tools remain separate constraints; no fixed limit applies to all plans and clients.

For an absent or inappropriate suggestion, investigate in order:

1. Record editor/integration version, signed-in account, feature, repository and time.
2. Confirm entitlement, effective organization/enterprise policy, feature enablement and service state.
3. Check workspace/file context, supported surface and any configured exclusions; preserve the CLI documentation conflict described in Part 5.
4. Check network/authentication errors and usage limits before treating an empty result as proof of exclusion.
5. Compare an allowed nonsensitive control file, inspect references/tool activity, then review or reject output and retest.

An absent marker in generated prose does not prove a file was never read. Keep secrets outside the test and retain the exact observed evidence; the sequence is a diagnostic worksheet, not an executed IDE experiment.

---

Part 4: Agent modes, sessions, sub-agents, and MCP

27. Current feature distinctions

Feature	Where it operates	Typical output	Human control point
Inline suggestion	IDE editor	Suggested code at cursor	Accept or reject
Chat/Ask	IDE or GitHub.com	Explanation or recommendation	Evaluate response
Copilot Edits	IDE	Scoped edits	Review diffs
Agent Mode	Local IDE	Multi-file edits and terminal actions	Tool approval and diff review
Copilot CLI	Local terminal or supported remote environment	Plans, edits, commands, reviews	Permissions and session review
Copilot cloud agent	GitHub Actions-powered environment	Research, plan, branch changes, optional PR	Session, diff, and PR review
Custom agent	Multiple supported Copilot surfaces	Specialized behavior and tools	Agent selection and tool scope
Sub-agent	Separate bounded context delegated by a parent	Specialist result returned to parent	Parent integration and validation

Current exam wording uses Copilot Edits, even when older material says Edit Mode.

28. Agent Mode versus cloud agent

Agent Mode

• Runs through the local IDE experience.
• Reads and edits local workspace files.
• Can propose terminal commands.
• Iterates after tests or commands fail.
• Keeps the developer in an interactive loop.

Copilot cloud agent

• Runs in a GitHub Actions-powered environment.
• Can be delegated work through issues or Copilot prompts.
• Can research, plan, change a branch, and optionally open a pull request.
• Operates asynchronously.
• Requires repository and organization configuration.

Do not memorize the older rule that every cloud-agent session automatically creates a pull request. Current cloud workflows can research and plan without immediately opening one.

See Copilot cloud agent.

29. Custom agents versus sub-agents

A custom agent is a reusable specialist definition. It packages role-specific instructions and selected tools.

A sub-agent is a temporary delegated worker with a separate context. In Copilot CLI, invoking a custom agent performs the work through a sub-agent. Separate context prevents detailed specialist work from crowding the parent agent's main context.

Example:

Parent agent: Coordinates an Azure Terraform change.
Security sub-agent: Reviews network exposure and identities.
Testing sub-agent: Designs validation and policy tests.
Documentation sub-agent: Updates module usage documentation.
Parent agent: Reconciles the results and presents one coherent change.

Delegation does not eliminate validation. The parent can misunderstand or combine results incorrectly.

30. Agent skills

Skills are reusable capability packages. A good skill contains:

• A clear trigger and scope
• Required inputs
• Ordered procedure
• Deterministic scripts where appropriate
• Reference material
• Output contract
• Validation criteria
• Safety constraints

For example, an azure-terraform-review skill might:

1. Inspect changed .tf files.
2. Run formatting and validation.
3. Check identity and public-network settings.
4. Identify replacements.
5. Review provider compatibility.
6. Produce findings by severity.

The skill improves repeatability. A ruleset remains necessary if the organization must block unreviewed changes.

31. MCP threat model

An MCP server may read data, write data, execute an action, or all three. Before enabling one, ask:

1. Who operates the server?
2. How is it authenticated?
3. Which tools are exposed?
4. What scopes do its credentials possess?
5. Can untrusted repository content influence tool calls?
6. Is approval required before writes?
7. Where are prompts, inputs, and outputs logged?
8. Can the organization restrict it through a registry or allowlist?

Prefer read-only tools during research and planning. Separate write capability into a narrowly scoped tool with explicit approval.

Related item: Indirect prompt injection occurs when untrusted retrieved content tries to redirect the agent or its tools. Treat repository text, issues, webpages, and MCP results as data with a trust level; tool authorization and human approval must not depend on the retrieved content behaving honestly.

Enforce MCP boundaries on the actual client

Enterprise-managed settings and the MCP allowlist provide stronger applicable-client control than assuming a private registry alone constrains server configuration. Inspect each property's supported clients, server URL or command matching, deny rules and deployment evidence; a familiar server name does not identify trusted code.

The MCP integration contract is surface-specific. Cloud-agent MCP tools can run autonomously without a local approval dialog. If pre-write approval is mandatory, enforce it in the target service/workflow or omit the write-capable tool. A readOnlyHint is an eligibility annotation, not proof the implementation cannot mutate state. Server allowance, selected tools, effective credentials, downstream authorization and human approval are distinct gates. Do not assume every client supports remote OAuth, resources or prompts merely because another client does.

Related item — VERIFY CURRENT: Copilot Fusion's October 28 announcement illustrates routing/orchestration across enabled models. Compare output against the same independent test oracle, and record actual models, effort, latency and usage. A cascade or critique is not independent verification of a claim, and not every task necessarily uses several models. This is current implementation context, not a new August exam domain.

32. Copilot Spaces, Spark, and pull-request summaries

Spaces

Copilot Spaces collect reusable context such as:

• Repositories and code
• Issues and pull requests
• Notes and transcripts
• Images and uploaded files

Spaces ground conversations and can be shared. They provide context; they do not enforce engineering standards.

Spark

The blueprint still names GitHub Spark, so understand its historical purpose: creating and deploying full-stack applications from natural-language requests. The Spark workbench on github.com stopped accepting new users and app creation on August 4, 2026, and retired on August 31, 2026. Existing deployed apps may continue, but Spark's llm() calls stopped when GitHub Models retired. Treat Spark as blueprint vocabulary and lifecycle context, not as an available hands-on path. See the official Spark retirement notice.

Pull-request summaries

Copilot can generate an overview and key-change list from a PR diff. A summary accelerates orientation but does not prove correctness, security, or test coverage.

---

Part 5: Privacy, exclusions, public code, and safeguards

33. Keep the controls separate

Control	Purpose
Content filtering	Detect harmful, offensive, or insecure prompts or responses
Suggestions matching public code	Detect or block certain outputs matching public code
Content exclusion	Prevent selected content from informing supported Copilot features
Custom instructions	Guide Copilot behavior
Tool permissions	Limit what an agent can read, write, or execute
Rulesets	Prevent noncompliant Git changes from merging

These controls are not interchangeable.

34. Content exclusion

Supported content exclusions are configured through GitHub repository, organization, or enterprise Copilot settings. They use path patterns to identify excluded content.

Current documented effects include preventing affected content from informing supported inline suggestions, Chat responses, and Copilot code review.

Critical limitation

Current GitHub documentation states that content exclusion is not supported in:

• Edit and Agent modes in supported IDE Chat experiences

Documentation conflict — October 28, 2026: The current exclusion how-to lists Copilot CLI among unsupported surfaces, while the September 2 availability announcement says Business/Enterprise CLI and app exclusions are generally available. Preserve both statements; do not promise universal CLI protection or assume one page proves every client version. Confirm the exact plan/client/policy with GitHub and test only harmless fixtures. The IDE Agent mode limitation remains explicit in the how-to.

Therefore:

Content exclusion must not be treated as a universal secret-protection boundary.

Do not keep secrets in a repository and assume exclusion makes them safe. Use secret stores, remove unnecessary sensitive files from the workspace, and control agent access.

Related item: Data-loss prevention, repository classification, endpoint controls, and secret management operate outside Copilot's content-exclusion feature. Defense in depth is important because local agents, terminals, extensions, and external tools can have different file-access paths.

.copilotignore

Older June companion material described .copilotignore; the current repository quick reference inspected October 28 rejects that as the supported policy mechanism. Official GitHub content-exclusion documentation governs the actual administrative control. Do not memorize it as an enforceable GitHub control.

See excluding content from Copilot.

35. Suggestions matching public code

The current exam wording is suggestions matching public code filtering. Older material may say duplication detection or public-code filter.

Understand the intent:

• Detect certain suggestions that match public code.
• Block or allow them according to policy.
• When allowed, references may provide repository and licensing context.
• A match does not automatically determine whether use is legally appropriate.

Related item: Software-composition and license review can help track third-party code after it enters a repository. Public-code matching is a generation-time signal; dependency inventories, provenance, notices, and legal review address different lifecycle questions.

Important agent limitation: GitHub's responsible-use documentation warns that Copilot CLI and cloud agents can produce matches or near matches even when the standard policy is set to block. Agent results require human review and may surface match details differently.

36. Ownership and output limitations

Copilot output can be:

• Incorrect
• Insecure
• Incomplete
• Outdated
• Similar to public code
• Incompatible with the repository license or policy
• Based on misunderstood context

The developer remains responsible for validation. For enterprise work, also follow customer, employer, regulatory, and contractual rules.

37. Data and audit boundaries

Do not equate an enterprise audit log with complete prompt surveillance.

GitHub's Copilot audit documentation says audit logs can include:

• Plan, setting, and policy changes
• License assignment changes
• Agent activity on GitHub.com

It does not include every prompt sent during a local client session. A company that needs local agent telemetry may require a separate approved logging solution.

Related item: Observability and privacy can conflict. Collect only the telemetry needed for security, reliability, adoption, and investigation; define access, retention, redaction, and employee notice instead of assuming more prompt logging is always better.

---

Part 6: Copilot administration, audit, and REST APIs

38. Administration mental model

Copilot administration has four related but different data sets:

Data	Question answered
Policy	What features and models are permitted?
Seat assignment	Who is licensed?
Usage metrics	Which features are being adopted?
Audit log	Who changed a control or performed a recorded action?

Do not use usage metrics as if they were an audit log. Do not use seat assignment as proof of productive usage.

39. Policy inheritance and feature availability

An enterprise decision can constrain organizations. Organization owners manage delegated choices. Repository settings may further restrict repository-specific availability for capabilities such as cloud agents.

Scenario:

The enterprise disables Copilot CLI. An organization owner wants to enable it.

Result: the organization cannot override the enterprise decision.

Scenario:

The enterprise sets no policy for Copilot code review. Organization A enables it and Organization B disables it.

Result: availability can vary based on which organization grants the user's Copilot license and how policy conflicts are resolved.

40. Copilot code review policy and standards

Enabling the code-review policy makes the feature available. Repository instructions influence review behavior. Neither replaces branch-review requirements.

A mature design separates:

1. Feature policy: Users may request Copilot code review.
2. Review instructions: Copilot should focus on selected standards.
3. Workflow checks: Deterministic tests run.
4. Ruleset: Required checks and approvals must pass; policy decides whether the current preview permits Copilot-submitted approvals, while production and destructive changes retain accountable human authorization.

Example review instructions:

When reviewing Terraform:

- Flag public network access unless an exception is linked.
- Flag credentials, subscription IDs, and tenant IDs embedded in code.
- Identify resource replacements and destructive changes.
- Require typed variables and descriptions.
- Flag provider changes not explained in the pull request.
- Do not recommend suppressing a scanner finding without justification.

41. Seat-management REST API

The Copilot user-management API supports operations such as:

• Get organization Copilot seat information and settings
• List seat assignments
• Add or remove teams
• Add or remove users
• Get assignment details for a user

Representative endpoint pattern:

GET /orgs/{org}/copilot/billing/seats

Team assignment pattern:

POST /orgs/{org}/copilot/billing/selected_teams

These operations require appropriate organization permissions. Read operations normally require Copilot Business or organization administration read permission; write operations require the corresponding write permission. Some endpoints remain in preview.

Use the live Copilot user-management REST reference rather than memorizing preview status or API-version headers.

Exam-level reasoning:

• UI assignment is suitable for occasional manual administration.
• REST administration supports repeatable, large-scale seat lifecycle management.
• Team-based assignment is more scalable than maintaining individual lists.
• Removal can interact with billing cycles and alternate team-based access.

42. Audit logs

Useful filters include:

action:copilot
actor:Copilot
action:copilot.cfb_seat_assignment_created

action:copilot finds Copilot-related plan and administration events. actor:Copilot focuses on recorded agent activity.

GitHub documents 180-day enterprise audit-log retention and recommends streaming to a SIEM for longer retention and alerting. See reviewing Copilot audit logs.

Know what audit logs do not guarantee:

• They do not contain all local prompts.
• They are not the same as usage metrics.
• A seat event does not prove code quality.
• Long-term compliance retention may require streaming.

43. Usage and activity

Organization owners can review assigned seats, recent activity, and reports. last_activity_at can take time to update and depends on telemetry. Activity data is useful for adoption and seat reclamation but should be interpreted carefully.

A sound adoption review considers:

• Assigned versus active seats
• Feature usage by surface
• Acceptance and review behavior
• Cost and AI-credit use
• Training completion
• Security incidents and policy exceptions
• Developer outcome measures

Avoid treating lines of code generated as a success metric by itself.

Related item: Useful engineering outcomes include lead time, review rework, escaped defects, security findings, developer satisfaction, and time-to-understanding. Pair outcome measures with safeguards so productivity pressure does not reward accepting low-quality generated code.

---

Part 7: Hands-on labs

Lab 1: Learn GitHub flow with Terraform

Objective

Experience the complete branch-to-merge lifecycle.

Steps

1. Create a private practice repository containing a small Terraform module.
2. Protect main with a ruleset requiring a pull request.
3. Create feature/add-diagnostics.
4. Add a typed variable and a mock diagnostic-setting resource or example.
5. Run terraform fmt and terraform validate.
6. Commit and push.
7. Open a draft PR.
8. Review the diff and PR metadata.
9. Mark it ready for review.
10. Merge using squash merge.
11. Delete the branch.
12. Inspect the resulting history.

Validation questions

• What existed only locally before push?
• Which commit reached main after squash merging?
• What evidence remains in the pull request?
• What would have blocked the merge if validation failed?

Lab 2: Build a standards stack

Objective

Implement guidance, checking, ownership, and enforcement as separate controls.

Add

.github/copilot-instructions.md
.github/instructions/terraform.instructions.md
.github/CODEOWNERS
.github/workflows/terraform-quality.yml
.github/pull_request_template.md

Configure

• A rule requiring PRs to main
• One approval
• Code-owner review
• The Terraform quality status check
• Resolved conversations

Test

1. Ask Copilot to create an insecure storage account.
2. Observe whether instructions improve the proposal.
3. Deliberately violate formatting or a scanner rule.
4. Confirm that Actions finds the problem.
5. Confirm that the ruleset blocks merging.

Lesson

Instructions improve behavior; Actions and rulesets enforce outcomes.

Lab 3: Current Copilot CLI

Objective

Practice the standalone agentic CLI safely.

Steps

1. Install the current CLI from official documentation.
2. Open only the practice repository.
3. Run git status.
4. Launch copilot.
5. Authenticate with /login if required.
6. Inspect /help, /usage, and /context.
7. Use /plan for a Terraform change.
8. Approve only safe read operations.
9. Let the CLI edit one file.
10. Review the diff in VS Code.
11. Run /review.
12. Rename the session.
13. Exit and resume it with copilot --resume.
14. Inspect session history with /chronicle.

Safety test

Script and file-management task: In an authorized disposable lab folder, provide a tiny synthetic asset JSON file and ask the CLI to generate inventory.py that reads only that fixture and prints a sorted asset/count summary. Permit writes only inside the lab folder; require it to show the proposed script before execution. Inspect imports, paths and file operations, then compare the result with a hand-calculated answer. Ask for a renamed copy and inspect the diff before removing only lab-created files. A script that runs successfully but reads outside the approved fixture scope fails the task. Record unavailable CLI access as a tabletop plan; this refresh did not generate or run that CLI output.

Ask the CLI to explain which directories, tools, URLs, and MCP servers it can access. Verify the configuration rather than trusting the answer alone.

Lab 4: Content-exclusion boundaries

Objective

Learn what exclusions do and do not protect.

Steps

1. In a paid practice organization, configure a documented repository content exclusion.
2. Test inline suggestions and supported Chat behavior in the excluded file.
3. Test code review behavior.
4. Review GitHub's documented surface limitations and the CLI release/how-to conflict. Record client version, plan, configured policy and observed positive/negative fixture behavior; use a tabletop result if the environment is unavailable.
5. Do not place real secrets in the test.

Explain afterward

• Why is content exclusion different from .gitignore?
• Why is it different from an instruction?
• Which agentic surfaces do not honor it?
• What controls must protect actual secrets?

Lab 5: Agent, skill, and MCP distinctions

Objective

Use the Timothy Warner repository as a working example.

Steps

1. Inspect .github/copilot-instructions.md.
2. Inspect the path-specific instruction file.
3. Inspect one .prompt.md file.
4. Inspect the Cert Buddy .agent.md profile.
5. Inspect one skill's SKILL.md, resources, and validation script.
6. Inspect .vscode/mcp.json.
7. Invoke the Cert Buddy to create a CLI lab.
8. Identify which behavior came from instructions, the prompt, the agent, the skill, and MCP.

Important correction

When studying archived June material, replace retired gh copilot commands and unsupported .copilotignore assumptions. The current September companion uses the standalone CLI and configured exclusions; verify exact client behavior against the conflicting official exclusion sources above.

---

Lab 6: Boundary tests and context quality — 45–60 minutes

Create a disposable Python repository for the shipping contract in Part 0. Write the expected cases before using Copilot. Compare a vague request with a fresh-session request containing the context packet. Inspect each patch and run the same tests. Introduce the deliberate > versus >= mutation, then prove the threshold test fails. Include a type check that rejects True.

Deliverable: the contract, two prompts, reviewed diffs, actual test output, and a short explanation of which context helped. If Copilot is unavailable, compare two handwritten candidate implementations using the same oracle; this verifies the test design without claiming a Copilot result. Remove the disposable repository when finished according to your normal cleanup process.

Answer checkpoint: 5000 receives free shipping. The mutation must fail that case. A generated test that expects a fee at 5000 is wrong even if the generated implementation passes it. Treat a one-task comparison as a learning observation, not a productivity benchmark.

Lab 7: Policy, defaults, and merge controls — 30–45 minutes

Use a tabletop first. A fictional enterprise disables one feature explicitly, leaves another GA feature unconfigured, and delegates a third to an organization. Its default for eligible new features is enabled; a repository overrides the enterprise's default review effort. Work out the effective settings before and after the October 22–26 documented rollout. The release describes one-time assignment for eligible unconfigured features: changing the global default afterward does not rewrite those now-set feature policies. Explicit feature changes are separate. Contrast that dated migration rule with current default behavior for newly unconfigured settings. Then diagram the separate path from a pull request through tests, review, ruleset checks, and merge.

In an authorized disposable repository, optionally require one test check and verify a failing code change and a documentation-only change. Record which commit and event produced the check. Do not change enterprise-wide settings just to complete this exercise.

Answer checkpoint: explicit disablement remains effective; eligible unconfigured GA features follow the applicable default when the transition takes effect; delegated settings require inspection at organization scope. A review-effort override does not override a locked feature policy. A prompt instructing Copilot to run tests cannot enforce merge protection.

Lab 8: Setup, context and policy evidence worksheet

In a disposable repository or tabletop, map one inline-suggestion task, one IDE Chat question and one cloud-agent task to the client, account, plan, effective feature/model policy, context, tool and permission path. Diagnose a missing suggestion using the ordered process above. Compare a server's approved URL/command with an altered one, then a read-only versus write-capable tool under the same credential. State where a human decision is enforced and where calls can be autonomous. Retain observed facts separately from expected behavior; do not enable enterprise-wide settings or run destructive commands for the exercise.

---

Part 8: Exam distinctions to know cold

Pair	Correct distinction
Git versus GitHub	Git is version control; GitHub adds hosting, collaboration, automation, security, and governance
Commit versus push	Commit writes locally; push publishes to a remote
Branch versus fork	Branch is in the same repository; fork is a separate repository
Workflow versus required check	Workflow runs validation; rules make its status mandatory
CODEOWNERS versus required approval	CODEOWNERS requests reviewers; rules enforce their approval
Instruction versus policy	Instruction guides behavior; policy controls availability
Instruction versus prompt file	Instruction is persistent guidance; prompt file is an invoked task
Agent versus skill	Agent is a specialized worker; skill is a reusable capability package
Skill versus MCP	Skill packages procedure/resources; MCP connects tools and data
Agent Mode versus cloud agent	Agent Mode works in the local IDE; cloud agent works asynchronously in a GitHub-hosted environment
Custom agent versus sub-agent	Custom agent is a reusable specialist definition; sub-agent is a temporary delegated worker/context
Plan Mode versus authorization	Plan Mode creates a planning gate; it does not grant organizational approval
Content exclusion versus public-code filtering	Exclusion protects selected input context on supported surfaces; public-code filtering evaluates generated suggestions
Content filtering versus content exclusion	Filtering addresses unsafe responses; exclusion controls selected context
Audit logs versus metrics	Logs record actions and changes; metrics summarize adoption and usage
Seat assignment versus activity	Assignment grants access; activity indicates use
Copilot assessment versus approval	An assessment advises and does not satisfy merge requirements; an administrator-enabled preview can let Copilot submit a counting approval, while people remain accountable for policy and merge risk
Old gh copilot versus current copilot	The GitHub CLI extension is retired; the standalone agentic CLI is current
Edit Mode versus Copilot Edits	Copilot Edits is the current exam wording
Duplication detection versus suggestions matching public code	The latter is the current exam wording

---

Part 9: Scenario practice

Scenario 1

An enterprise owner disables Copilot CLI. An organization owner enables it.

Answer: The enterprise decision wins. The organization cannot override an explicit enterprise disablement.

Scenario 2

A repository includes .github/copilot-instructions.md telling Copilot to run terraform validate, but the validation never runs.

Answer: Instructions are guidance. Add a GitHub Actions workflow to run validation, then require its status through a ruleset.

Scenario 3

CODEOWNERS names the security team, but a PR merges without its approval.

Answer: CODEOWNERS alone requests review. Configure a rule requiring code-owner approval.

Scenario 4

A team excludes secrets.auto.tfvars through Copilot settings and then uses Agent Mode, assuming the file cannot be read.

Answer: Unsafe assumption. Current documentation says IDE Agent mode does not support content exclusion; support also varies by client and plan. The current CLI how-to conflicts with the September GA announcement, so exact client/plan/policy behavior remains a verification task; exclusion is not a secret-management boundary. Remove secrets from the workspace and use proper secret management and access controls.

Scenario 5

An administrator needs to assign Copilot to 500 users based on team membership.

Answer: Use team-based assignment and the Copilot user-management REST API rather than maintaining an individual manual list.

Scenario 6

A developer wants consistent Terraform security reviews on demand.

Answer: Use persistent Terraform instructions for the standards and a reusable prompt file or custom review agent for the review procedure. Back it with deterministic scanners and required checks.

Scenario 7

A long Copilot CLI session is losing earlier requirements.

Answer: Inspect /context, use /compact, restate critical constraints, or start a focused new session. Store durable requirements in repository instructions rather than relying only on chat history.

Scenario 8

The company wants to know who changed a Copilot policy and also which users have not used their assigned seats.

Answer: Use audit logs for policy changes and activity/seat reports or APIs for adoption and assignment. These are different data sources.

---

Scenario 9

Copilot generates a shipping function and tests; all tests pass, but the contract says orders of exactly 5,000 cents ship free and the code uses > 5000. What is missing?

Answer: An independent boundary oracle. Add the 5000 → 0 assertion from the requirement, observe failure, then fix and rerun. Agreement between generated code and generated tests is insufficient.

Scenario 10

A documentation-only pull request waits forever for a required workflow that filters for *.tf files. Should you rerun Copilot review?

Answer: Diagnose the workflow trigger. The path-filtered workflow never supplied the required result. Make the required check report reliably for relevant pull requests; include the merge-queue event if applicable. Another review does not create the missing test result.

Scenario 11

An organization cannot override an enterprise feature disablement, but a repository can override the enterprise's default review effort. Is this contradictory?

Answer: No. An enforced feature policy and an inherited effort default have different contracts. Check the documentation and setting type before applying an inheritance rule.

Scenario 12

An organization-instruction change is visible in one JetBrains session but absent in another IDE. What do you inspect first?

Answer: Client/plugin version, supported session surface, organization membership, effective policy, and loaded instructions. Do not infer universal IDE support from one release or assume repository instructions grant permissions.

Scenario 13

A metrics report has an empty review-stage array and high suggestion acceptance. Can you conclude that Copilot eliminated review delay?

Answer: No. The array has no qualifying observations; acceptance is a usage signal. Examine the reporting window, human-review coverage, comparable completed tasks, end-to-end time, and defect/rework outcomes.

Scenario 14

Inline suggestions work, but IDE Chat is absent. Should the team reinstall the CLI?

Answer: Diagnose the IDE path: supported integration/version, signed-in account, entitlement, effective Chat policy and client availability. CLI authentication and operation are a separate path. Retain exact error/context evidence and test a harmless allowed file before changing access.

Scenario 15

A cloud-agent MCP tool makes a write without a local permission dialog. Did a prompt asking for confirmation enforce the required approval?

Answer: No. Cloud MCP calls can be autonomous. Enforce a required pre-write decision in the target workflow/API or omit that tool; inspect effective credentials, arguments and actual execution. An allowlisted server or read-only hint is not proof of downstream business authorization.

Scenario 16

An unconfigured feature received its default during the October rollout. The global default later changes. Is that evidence that the already-set feature was disabled?

Answer: No. The dated rollout describes a one-time assignment. Inspect the feature's actual explicit/effective state and separate model policy; a review-effort override does not change a locked feature decision.

---

Part 10: Suggested study sequence

Session 1: GitHub flow and pull requests — 90 minutes

• Read Part 1 through merge strategies.
• Complete Lab 1.
• Explain branch, commit, push, PR, review, and merge without notes.

Session 2: Governance and enforcement — 90 minutes

• Finish Part 1.
• Read Part 2.
• Complete Lab 2.
• Explain why instructions do not enforce compliance.

Session 3: Copilot CLI — 90 minutes

• Read Part 3.
• Complete Lab 3.
• Practice sessions, Plan Mode, context inspection, and review.

Session 4: Agents and MCP — 75 minutes

• Read Part 4.
• Complete Lab 5.
• Explain agents, sub-agents, skills, prompt files, and MCP.

Session 5: Privacy and administration — 90 minutes

• Read Parts 5 and 6.
• Walk through Lab 4 conceptually or practically.
• Review policy inheritance, audit queries, and REST API purposes.

Session 6: Exam transfer — 60 minutes

• Review all distinction tables.
• Answer the scenarios without notes.
• Revisit the current Microsoft objective bullets.
• Use Cert Buddy for questions specifically on your weak areas.

---

Readiness checklist

You are ready when you can explain or demonstrate the following without relying on memorized slogans.

Responsible use, data, and prompting

• I can name and apply Microsoft's six Responsible AI principles.
• I can identify Copilot risks, harms, and appropriate mitigations.
• I validate output with evidence rather than model confidence.
• I can describe context gathering, prompt construction, proxy filtering, model generation, and post-processing.
• I understand that data handling and retention vary by feature, plan, provider, and preview status.
• I can distinguish zero-shot and few-shot prompting.
• I can write a prompt with goal, context, constraints, validation, and output format.
• I can manage finite context and keep durable decisions outside chat history.
• I can use Copilot for refactoring, documentation, modernization, tests, security, and performance without delegating accountability.

GitHub fundamentals

• I can describe working tree, staging area, local repository, and remote.
• I can create a branch, commit, push, and open a PR.
• I understand branch versus fork.
• I can explain merge, squash, and rebase strategies.
• I understand status checks, reviews, and merge conflicts.
• I can explain enterprise, organization, team, and repository scopes.

Standards and governance

• I can separate policy, instruction, automation, ownership, enforcement, and audit.
• I understand repository and path-specific instructions.
• I know organization instructions have surface limitations.
• I understand CODEOWNERS and required code-owner review.
• I know a workflow must become a required check to block merging.
• I can describe reusable workflows and rulesets.

Copilot CLI

• I know the old gh copilot extension is retired.
• I can install and authenticate the current copilot CLI.
• I understand trusted directories and permissions.
• I can plan, review, inspect context, and manage sessions.
• I understand the risk of --allow-all and --yolo.
• I can explain the conflicting current CLI exclusion guidance, verify exact client/plan behavior, and protect secrets independently of exclusions; IDE Agent limitations remain explicit.

Agents and customization

• I can distinguish Copilot Edits, Agent Mode, and cloud agent.
• I understand sessions and sub-agent context isolation.
• I can distinguish instructions, prompts, agents, skills, and MCP.
• I can explain why MCP is a security boundary.
• I understand Spaces, the retired github.com Spark experience, and PR summaries at the exam level.

Privacy and administration

• I distinguish content filtering, public-code matching, and exclusion.
• I do not treat .copilotignore as the supported administrative exclusion control.
• I understand policy inheritance.
• I know what the Copilot seat API manages.
• I can use action:copilot and actor:Copilot conceptually.
• I distinguish audit data, metrics, and seat assignment.
• I understand that audit logs do not contain every local prompt.

---

Historical June corrections and current companion review

The October 28 review of Timothy Warner's current README, course plan, quick reference and selected activities confirms a September 24 course companion targeting the August 7 blueprint. The seven items below document older June material; they are not a claim that current main still contains those defects. Selected public content was inspected, not every sample, quiz or product behavior. Apply these historical corrections when reading older copies:

1. Replace Plan Mode as the fourth IDE trigger with the current objective wording, Agent Mode. Plan Mode remains a useful agent and CLI planning feature.
2. Replace Edit Mode with the current exam term Copilot Edits.
3. Replace duplication detection and security warnings with the current objective wording suggestions matching public code filtering.
4. Replace old gh copilot suggest and gh copilot explain examples with the standalone copilot CLI.
5. Do not treat .copilotignore as the current supported GitHub content-exclusion control.
6. Recheck models, plans, pricing, AI credits, shortcuts, and feature availability in current documentation rather than memorizing the repository's quick-reference tables.
7. Add separate study for GitHub flow, permissions, Actions, CODEOWNERS, rulesets, environments, audit logs, and REST administration.

---

Primary references

Exam

• GH-300 study guide

GitHub foundations and enforcement

• About Git
• GitHub flow
• About organizations
• Roles in an organization
• Rules available in rulesets
• Reusable workflows

Copilot customization and policy

• Copilot policies
• Organization custom instructions
• Repository custom instructions
• Customization cheat sheet
• Agent skills
• Custom agents
• MCP

Copilot CLI

• Install Copilot CLI
• Configure Copilot CLI
• Use Copilot CLI
• Copilot CLI command reference
• CLI session data
• Connect Copilot CLI to VS Code

Agents, privacy, and administration

• Copilot cloud agent
• Content exclusion
• Responsible use of agents
• Copilot REST API
• Copilot user-management API
• Review Copilot audit logs

Because Copilot changes quickly, recheck the official GH-300 outline and live GitHub documentation shortly before scheduling the exam.

---

Places to learn

Targeted blog reading

Article	Author and date	Learning task and limits
Want better AI outputs? Try context engineering	Christina Warren; January 12, updated January 14, 2026	Free; allow 10–15 minutes with notes. Build the Part 0 context packet. Use official customization docs for filenames and supported surfaces; the article is a conceptual introduction, not a complete configuration reference.
Getting more from each token	Joe Binder; June 17, updated June 18, 2026	Free; allow 15–25 minutes with notes. Explain caching, deferred tool definitions, and routing. Scope claims to the documented client and date; internal measurements and rollout plans are not guarantees.

Both are public GitHub articles reviewed September 27. They supplement the blueprint and official product documentation. The exercises are original; no article code or exam questions are reproduced.

Courses and practice

Commercial durations and course-update dates below are historical catalog observations unless stated otherwise; the six-course Pluralsight path and current public companion were specifically rechecked October 28. September 27 checks did not inspect paid course interiors; blocked pages and application shells do not establish syllabus freshness. The September 24 event is now past, so verify recording or future-session access before purchasing.

This is a curated starting point, not a complete list, and it is not meant to be consumed in full. Start with the official paths, then pick what works for you. Copilot changes particularly quickly, so use the August 7, 2026 blueprint and current GitHub Docs to resolve disagreements with any course. Times are approximate consumption time at normal speed; labs, note-taking, review, and independent practice add time.

Resource	Access	Estimated time	Best use and caveat
Microsoft Learn — GitHub Copilot Part 1 and Part 2	Free	About 10–14 hours	Official starting point and objective-aligned modules
Microsoft — GH-300 Practice Assessment	Free Microsoft account	About 1–2 hours for an attempt and review	Repeatable official readiness check with rationales and learning links; start here before buying another assessment
Microsoft Partner Skilling Hub — LevelUp GH-300	Partner login required	10 hours	No additional cost for eligible Microsoft partners; use a work account associated with the partner organization
Microsoft Learn GH-300 video course	Free	About 5–7 hours	Official instructor-led reinforcement for visual learners
Microsoft Reactor — Secure by Design: Building Security into Every Commit with GitHub Copilot	Free	1 hour	Current first-party related depth for secure Copilot-assisted development and validation; not an end-to-end GH-300 course
GitHub Skills: Getting started	Free account; Copilot access may be required	About 1–2 hours with setup and notes (editorial estimate)	Initial repository exercise; verify current account and feature requirements
GitHub Skills: Customize Copilot	Public reading; account/Copilot access for execution	Less than 30 minutes (publisher estimate), plus setup	Instructions, skills and custom-agent practice; no workflow executed in this refresh
GitHub Skills: Integrate MCP	Public reading; own exercise repository and eligible account	Less than 1 hour (publisher estimate), plus setup	Prerequisite getting-started exercise; issue/PR writes are intended learner actions, not performed here
GitHub Copilot CLI for Beginners: First Steps	Public MIT learning material; installed CLI and eligible account for execution	About 45 minutes: 15 reading + 30 hands-on (publisher estimate), excluding setup	Compare interactive, plan and programmatic modes and session controls; verify current commands/permissions before use
Pluralsight — GH-300 GitHub Copilot path and practice exam	Subscription; practice access depends on plan/library	6 hours plus about 2–4 hours for assessment/review (review time estimated)	Six-course public path rechecked October 28, including an October 23 productivity course and practice exam; paid interiors unreviewed
Whizlabs — GitHub Copilot certification practice	Paid course	About 3–6 hours for 3 quizzes and review	Assessment supplement rather than primary instruction; the provider does not publish a total runtime
MeasureUp — GH-300 practice test	Paid test or subscription; free demo available	About 4–8 hours for simulation and review	Tier 6 assessment supplement with 114 questions, explanations, and references; use after learning to locate gaps
O'Reilly — GitHub Copilot interactive practice test	Subscription	About 2–4 hours for an attempt and review	O'Reilly's public certification-prep catalog lists a GitHub Copilot practice test; exact launch details appear after sign-in
O'Reilly — GH-300 GitHub Copilot Certification Exam Prep	Subscription	7 hours 12 minutes	Long-form video course published in May 2026; compare with the August blueprint
O'Reilly — GitHub Copilot Certification Crash Course with Tim Warner	Subscription or event access	5 hours 30 minutes (published agenda)	Earlier course occurrence associated with Tim's public companion repository
O'Reilly — Pass Your GitHub Copilot Certification Exam with Tim Warner	Subscription or event access	4 hours (September 24, 10 a.m.–2 p.m. EDT)	Past September 24, 2026 event that links the public repository; VERIFY CURRENT recording or future-session access and compare with the August 7 blueprint
Udemy — GH-300 hands-on certification prep	Purchase or subscription	16 hours 36 minutes plus exercises	Hands-on course updated August 2026; evaluate this individual course rather than the marketplace name
Timothy Warner — public O'Reilly course companion repository	Free	About 1–2 hours selected reading/activities, or 4–6 hours for a broader route (editorial estimates)	Current September 24 four-hour course companion; selected activities total 50 minutes; use current primary docs for volatile behavior

Tim's authorized paid catalog is also available through his Pluralsight author page; at this review, his directly verified certification path there was the GH-500 path rather than GH-300.

The repository's complete MIT license was present and inspected October 28: Copyright (c) 2025-2026 Tim Warner. The August 30 missing-file observation is historical. Tim and the repository are credited, this guide remains independently written, and paid presentations or assessment material are not reproduced. The exact restored copyright and permission notice is preserved below in the linked notices. See Third-party notices and the broader Places to learn catalog.