Exam focus at a glance
This Quick Reference supports candidates preparing for the GitHub GitHub Copilot (GH-300) exam, code GH-300. Expect scenario questions about using GitHub Copilot effectively, selecting the right Copilot surface, applying responsible AI practices, and administering Copilot in an organization.
| Area | What to know for GH-300 | Common exam angle |
|---|
| Copilot surfaces | Inline suggestions, Copilot Chat, GitHub.com experiences, CLI assistance, IDE integrations | Choose the best surface for a task |
| Prompting | Clear intent, constraints, examples, context, iteration | Improve vague prompts |
| Context | Open files, selected code, repository context, chat references, exclusions | Diagnose poor or unsafe output |
| Plans and administration | Personal vs organization/enterprise management, seat assignment, policy controls | Pick admin-controlled option |
| Privacy and data handling | Business/Enterprise protections, public-code matching, content exclusions | Distinguish privacy controls from security scanning |
| Responsible AI | Human review, hallucination risk, bias, license awareness, secure coding review | Identify unsafe overreliance |
| Developer workflows | Generate, explain, refactor, test, document, debug, review | Use Copilot without skipping validation |
| Troubleshooting | Auth, license, IDE extension, policy, network, exclusions, context | Resolve “Copilot is not working” scenarios |
Copilot surface selection matrix
| Use case | Best Copilot surface | Why | Exam trap |
|---|
| Complete current line, function, or boilerplate | Inline code completion in IDE | Fastest for local coding flow | Not ideal for architectural explanations |
| Ask about selected code | Copilot Chat in IDE | Uses selected code and workspace context | Chat still needs precise instructions |
| Explain an unfamiliar function | Copilot Chat with selected code | Natural language explanation, examples, edge cases | Explanation may be incomplete or wrong |
| Generate unit tests | Copilot Chat or inline suggestions near test file | Can follow nearby test patterns | Generated tests may assert implementation, not requirements |
| Refactor code | Copilot Chat with selected block and constraints | Allows step-by-step transformation | Must rerun tests and review behavior changes |
| Debug an error message | Copilot Chat with error, stack trace, relevant code | Can reason over symptoms and code | Do not paste secrets from logs |
| Learn a shell command | GitHub Copilot in the CLI | Suggests or explains commands | Always inspect destructive commands |
| Understand repository-level code | Copilot Chat with workspace/repository context where supported | Can reason across project files | Depends on permissions, indexing, exclusions, and feature support |
| Summarize or work with PRs on GitHub.com | GitHub Copilot features on GitHub.com where available | Useful for review context | Not a substitute for code review |
| Enforce organization policy | Copilot Business or Enterprise admin settings | Centralized governance | Personal settings do not control an organization |
Plans and feature distinctions
Feature packaging can change, but GH-300 scenarios usually test the distinction between individually managed Copilot use and organization-managed Copilot use.
| Plan category | Primary audience | Key management model | High-yield distinction |
|---|
| Personal Copilot plan | Individual developer | User manages subscription/settings | Good for personal productivity; limited centralized governance |
| Copilot Business | Organizations | Admin-managed seats and policies | Designed for business control, privacy expectations, and policy enforcement |
| Copilot Enterprise | Enterprises using GitHub at scale | Enterprise/org-level management plus deeper GitHub.com context features | Adds enterprise-oriented GitHub.com and repository knowledge capabilities where enabled |
Business vs Enterprise exam cues
| If the scenario says… | Prefer… | Reason |
|---|
| “An organization needs centralized seat assignment and policy control” | Copilot Business or Enterprise | Admin governance, not personal subscription |
| “Developers need Copilot experiences integrated with GitHub.com and enterprise repository knowledge” | Copilot Enterprise | Enterprise-level GitHub context features |
| “A single developer wants suggestions in an IDE” | Personal plan or assigned business seat | Depends on whether use is personal or organization-managed |
| “Company policy must block matching public-code suggestions” | Organization/enterprise policy | Centralized setting is the governance answer |
| “Sensitive files must not be used as Copilot context” | Content exclusions | Exclusion controls context sent to Copilot, not repository access |
Core terminology
| Term | Meaning | GH-300 reminder |
|---|
| Prompt | User instruction or question to Copilot | Better prompts produce better, more constrained output |
| Context | Code, comments, selected text, open files, repo data, or chat references Copilot can use | Wrong or insufficient context causes poor answers |
| Inline suggestion | Code completion generated while editing | Best for local implementation flow |
| Copilot Chat | Conversational interface for coding questions and tasks | Good for explanation, refactoring, tests, debugging |
| Completion | Suggested code or text output | Must be reviewed before acceptance |
| Hallucination | Plausible but false output | Verify APIs, commands, security claims, and dependencies |
| Public-code matching | Detection of suggestions that match public code | Blocking reduces risk of accepting matching public snippets |
| Content exclusion | Admin/user-configured exclusion of specified content from Copilot context where supported | Not the same as access control or secret scanning |
| Seat assignment | Admin grants Copilot access to users | User still needs correct IDE/auth setup |
| Responsible AI | Using AI with human oversight, fairness, privacy, security, and accountability | “Copilot said so” is never sufficient validation |
| User engagement data | Usage/interaction data about Copilot use | Different from source code content; know the distinction |
| Prompt injection | Malicious or misleading instructions embedded in content | Treat untrusted instructions in issues, docs, or comments carefully |
Prompting quick reference
Strong prompt pattern
Use this structure when asking Copilot Chat for substantial work:
Goal: What you want built, changed, explained, or tested.
Context: Relevant files, selected code, framework, language, versions, constraints.
Requirements: Behavior, edge cases, performance, security, style, compatibility.
Output format: Code only, step-by-step explanation, test cases, checklist, diff-style plan.
Validation: Ask for risks, assumptions, and how to test the result.
Prompt improvement examples
| Weak prompt | Stronger prompt | Why stronger |
|---|
| “Fix this” | “Explain why this Python function fails for an empty list, then provide a minimal fix and two pytest cases.” | Includes language, failure condition, output, validation |
| “Write tests” | “Generate Jest tests for calculateDiscount. Cover zero quantity, expired coupon, maximum discount, and invalid input. Follow the style in this test file.” | Defines framework, function, edge cases, style |
| “Make it secure” | “Review this Express route for injection, authz, input validation, and error disclosure. Return prioritized findings and patched code.” | Names security categories and expected output |
| “Refactor” | “Refactor this method to reduce duplication without changing public behavior. Keep method names stable and list any assumptions.” | Prevents unwanted API changes |
| “Explain repo” | “Using the selected files, explain request flow from controller to database. Include key classes and where validation occurs.” | Narrows scope and requested structure |
Inline completion prompting
For code completion, comments and naming often matter more than long chat prompts.
## Create a function that validates a password.
## Requirements:
## - at least 12 characters
## - at least one uppercase letter
## - at least one lowercase letter
## - at least one digit
## - at least one symbol
## Return True or False; do not raise exceptions.
def is_valid_password(password: str) -> bool:
| To improve inline suggestions | Do this |
|---|
| Ambiguous output | Add a precise function name and docstring/comment |
| Wrong framework | Open nearby files using the correct framework |
| Wrong style | Provide examples in the same file |
| Missing edge cases | List edge cases before the function |
| Unsafe implementation | Add explicit security constraints |
Context rules and decision points
| Context source | How it helps | Risk or limitation |
|---|
| Current file | Strong signal for inline completions | May overfit to local mistakes |
| Open tabs / workspace context | Helps follow project patterns | Feature support varies by IDE/surface |
| Selected code | Best way to focus Copilot Chat | Selection may omit required dependencies |
| Comments and docstrings | Guide intent | Bad comments produce bad code |
| Test files | Teach expected behavior and style | Weak tests can reinforce bugs |
| Repository context on GitHub.com | Helps with repo-aware answers where supported | Depends on permissions, indexing, plan, and exclusions |
| Terminal output | Useful for debugging | Logs may contain secrets or private data |
| Issues/PR descriptions | Useful for intent | Treat untrusted text as potentially misleading |
High-yield context traps
| Trap | Correct understanding |
|---|
| “Copilot knows my whole codebase automatically” | It uses available context, which depends on surface, permissions, feature support, and exclusions |
| “More context is always better” | Relevant context is better; unrelated files can degrade answers |
| “Content exclusion removes repository access” | It limits Copilot context; it is not repository authorization |
| “Copilot output is verified because it compiles” | Compilation does not prove correctness, security, licensing, or maintainability |
| “Chat can safely process any log” | Logs may contain secrets, tokens, customer data, or internal URLs |
Admin and governance reference
| Admin task | Where it belongs | What to remember |
|---|
| Assign Copilot access | Organization or enterprise administration | A license/seat must be assigned before use |
| Configure public-code matching policy | Copilot policy settings | Common answer for reducing matched public-code suggestions |
| Configure content exclusions | Organization/enterprise/repository-related settings where supported | Prevents selected content from being used as Copilot context |
| Enable or restrict features | Admin policy controls | Feature availability may depend on plan and policy |
| Manage user access at scale | Teams, organizations, enterprise accounts | Prefer centralized controls for business scenarios |
| Review usage/adoption | Admin reporting where available | Usage metrics are not code quality metrics |
| Educate developers | Internal secure AI guidelines | Governance includes human process, not only settings |
Governance decision table
| Requirement | Best control | Not enough by itself |
|---|
| Prevent Copilot from using sensitive paths as context | Content exclusions | Telling users “be careful” |
| Reduce chance of accepting public-code matches | Block matching public-code suggestions | Manual review only |
| Keep Copilot use limited to approved users | Seat assignment and access policies | IDE extension installation alone |
| Protect secrets in repositories | Secret scanning and secure SDLC controls | Copilot policy alone |
| Detect vulnerable dependencies | Dependabot/dependency review/security tooling | Asking Copilot if dependencies are safe |
| Enforce code quality | Code review, tests, branch protections, CI | Accepting Copilot suggestions without review |
| Standardize acceptable AI use | Organization policy and training | Individual preference settings |
Privacy, security, and responsible AI
Privacy and data handling distinctions
| Concept | What it means | Exam reminder |
|---|
| Prompt | The instruction and context sent to Copilot | Do not include secrets or unnecessary sensitive data |
| Suggestion | Copilot-generated output | Review before accepting |
| Accepted code | Code the developer commits | The organization is responsible for it |
| Business/Enterprise protection | Organization-oriented data handling and admin controls | Prefer these in company governance scenarios |
| Public-code matching setting | Allows or blocks suggestions detected as matching public code | It is not a full license-compliance system |
| Content exclusion | Excludes configured content from Copilot context where supported | It is not retroactive code removal from all systems |
| Feedback | User feedback about suggestions | Can be separate from source code content |
Responsible use checklist
Before accepting Copilot output, verify:
- Correctness against requirements, not just syntax.
- Security: authn/authz, validation, injection, error handling, secrets, crypto misuse.
- Licensing and provenance concerns for substantial or matching code.
- Maintainability: readability, project conventions, dependency choices.
- Test coverage: positive, negative, edge, regression, and failure paths.
- Performance and scalability assumptions.
- Accessibility and internationalization where relevant.
- Whether generated comments accurately describe the code.
Security review prompts
Review the selected code for security issues.
Focus on input validation, authorization, injection, secret exposure,
error handling, insecure dependencies, and unsafe defaults.
Return findings with severity, evidence, and a safer code example.
Threat-model this API endpoint.
List assets, trust boundaries, likely attacker goals, abuse cases,
required controls, and test cases to verify the controls.
Developer workflow reference
| Workflow | Effective Copilot use | Validation step |
|---|
| New function | Provide signature, requirements, edge cases, style constraints | Run tests and inspect edge handling |
| API integration | Provide endpoint contract, auth method, error model, retry expectations | Verify with official API docs |
| Refactoring | Ask for behavior-preserving change and list assumptions | Compare tests before/after |
| Debugging | Provide exact error, stack trace, relevant code, recent changes | Reproduce and confirm root cause |
| Documentation | Ask for concise docs based on actual code | Ensure docs do not invent behavior |
| Code explanation | Select code and ask for flow, dependencies, side effects | Confirm against source |
| Performance improvement | Ask for bottleneck hypotheses and measurement plan | Benchmark before changing |
| Test generation | Provide requirements and edge cases | Ensure tests can fail for wrong behavior |
| PR support | Use summaries and review assistance where available | Human reviewer remains accountable |
| CLI command help | Ask for command and explanation | Inspect flags before execution |
Testing with GitHub Copilot
Test-generation decision table
| Goal | Prompt Copilot with | Watch for |
|---|
| Unit tests | Function/class, expected behavior, test framework | Tests that mirror implementation bugs |
| Regression tests | Bug description, failing input, expected output | Test that passes without catching the bug |
| Edge cases | Boundaries, null/empty, invalid input, limits | Missing negative cases |
| Mocking | External services, expected calls, failure modes | Over-mocking internal behavior |
| Integration tests | Components, environment assumptions, database/API setup | Flaky tests and hidden dependencies |
| Security tests | Abuse cases, injection payloads, authz scenarios | Unsafe payload handling in test logs |
| Property-style tests | Invariants and valid input ranges | Too broad or impractical generated data |
Better test prompt
Generate pytest tests for `normalize_username`.
Requirements:
- trim surrounding whitespace
- lowercase ASCII letters
- reject empty result
- reject names longer than 30 characters
- preserve digits, hyphen, and underscore
Include positive, negative, and boundary cases.
Do not change production code.
Testing traps
| Trap | Correct action |
|---|
| Copilot generated many tests, so coverage is adequate | Review assertions and map tests to requirements |
| Tests pass, so code is secure | Add security-focused tests and review |
| Generated mocks are fine by default | Ensure mocks represent real service behavior |
| Copilot can infer all edge cases | Provide known edge cases explicitly |
| Snapshot tests prove behavior | Confirm snapshots capture meaningful output |
GitHub Copilot in the CLI
Use Copilot CLI assistance for command suggestions and explanations, especially when the task is command-line focused.
gh extension install github/gh-copilot
gh copilot suggest "find large files in this repository"
gh copilot explain "git reset --soft HEAD~1"
| CLI scenario | Good practice |
|---|
| Command may delete, overwrite, or publish data | Ask for explanation before running |
| Command includes secrets or tokens | Do not paste the secret; replace with placeholders |
| Command uses production resources | Verify flags, target, and environment |
| Command is unfamiliar | Ask Copilot to explain each option |
| Command came from generated output | Cross-check with official tool help or documentation |
IDE and feature troubleshooting
| Symptom | Likely cause | Practical response |
|---|
| No suggestions appear | Not signed in, no assigned seat, extension missing, unsupported file, policy disabled | Verify authentication, license, extension, policy, file type |
| Chat unavailable | Plan/policy/IDE support issue | Check feature enablement and supported surface |
| Suggestions are irrelevant | Poor context, wrong open files, vague comments, generated code drift | Add precise comments, open relevant files, select code |
| Copilot ignores repository files | Repo context not available, permissions missing, content excluded, feature unsupported | Confirm permissions, surface, and exclusions |
| Suggestions stopped in one file | File may be excluded, too noisy, unsupported, or policy-restricted | Try another file and check exclusion policy |
| Authentication loops | IDE/GitHub auth state or SSO issue | Reauthenticate and confirm org access |
| Slow responses | Network/proxy/service/extension issue | Check connectivity, update extension, retry later |
| Unsafe-looking code | Model output issue or weak prompt | Reject, refine prompt, run security review |
| Public-code match warning/block | Matching filter policy triggered | Use another approach or write original code |
| Copilot suggests deprecated API | Model/context limitation | Verify against current docs |
Common GH-300 traps
| Exam statement | Best response |
|---|
| “Copilot replaces code review” | False. Human review remains required |
| “Generated code is automatically secure” | False. Review and test security |
| “Content exclusions are the same as repository permissions” | False. Exclusions control Copilot context |
| “Blocking public-code matches guarantees license compliance” | False. It reduces one risk but does not replace legal review |
| “Business use should rely on each user’s personal settings” | Usually false. Use centralized policies |
| “Copilot can only write new code” | False. It can explain, test, refactor, debug, document, and assist CLI work |
| “A vague prompt is fine because Copilot infers everything” | False. Specific context and constraints improve output |
| “Passing tests prove Copilot’s answer is correct” | Not necessarily. Tests may be incomplete or generated from the same flawed assumptions |
| “It is safe to paste production logs into chat” | Only after removing secrets and sensitive data |
| “Copilot Chat always has full repository knowledge” | False. Context depends on product surface, permissions, plan, indexing, and exclusions |
Quick prompt recipes
Explain code
Explain the selected code for a new maintainer.
Cover purpose, inputs, outputs, side effects, dependencies,
error handling, and any risky assumptions.
Refactor safely
Refactor the selected code to reduce duplication and improve readability.
Do not change public behavior, function names, return types, or error semantics.
List assumptions and recommend tests to run.
Generate tests
Create unit tests for the selected function using the existing project test style.
Include normal cases, edge cases, invalid input, and one regression test
for the described bug. Explain why each test matters.
Debug
Given this error and selected code, identify the most likely root cause.
Provide a minimal fix, explain why it works, and list how to verify it.
Secure coding review
Review this code for security issues.
Prioritize findings by severity and exploitability.
Provide safer code only where a concrete issue exists.
Last-minute checklist
- Know when to use inline suggestions, Copilot Chat, GitHub.com features, and CLI assistance.
- Distinguish personal Copilot use from Copilot Business or Enterprise governance.
- Understand seat assignment, policy controls, public-code matching, and content exclusions.
- Remember that context quality drives answer quality.
- Use prompts with goal, context, constraints, output format, and validation.
- Treat generated code as a draft requiring review, tests, and security checks.
- Do not paste secrets, private customer data, or unnecessary sensitive logs.
- Validate commands before running them, especially destructive CLI commands.
- For business scenarios, choose centralized admin controls over individual preferences.
- For testing scenarios, ensure generated tests map to requirements and edge cases.
Practical next step
Use this Quick Reference to drill scenario questions: for each GH-300 practice item, identify the Copilot surface, the needed context, the governance control, and the validation step before choosing an answer.