What's changed: New GH-300 Chapter 6 (privacy settings & exclusions = content exclusion/editor settings, output ownership and limits [public-code match/licensing]; safeguards & troubleshooting = enabling duplication detection/security warnings, diagnosing suggestion/exclusion issues [exclusion/policy/seat/language], safeguards are not perfect)
6.1Privacy Settings and Content Exclusions
Understand configuring content exclusions and editor settings, and the ownership and limitations of Copilot’s output (whose it is, matches with public code, licensing caveats).
Using Copilot safely in an org requires understanding what not to send to the AI (privacy) and how to treat its output (ownership/licensing). GH-300 tests configuring content exclusions, editor-side settings, and the ownership and limitations of output.
6.1.1Content exclusions and editor settings
Content exclusion keeps specific files or repositories out of Copilot’s context and suggestions (introduced in Chapter 2). It protects sensitive config files, code that policy forbids sending to AI, and third-party confidential code. Admins set exclusions at the repo/org level; excluded files get no suggestions and aren’t used as context. The editor also has settings for enabling/disabling Copilot and target languages, combined with org policy (Chapter 2) to control scope.
6.1.2Ownership and limitations of output
For code that adopts a generated suggestion, ownership and responsibility generally rest with the user/organization that adopted it. Note that Copilot output may match/resemble public code, sometimes requiring licensing care. To address this, duplication detection (next section) can block/warn on suggestions matching public code. Don’t leap to "AI produced it, so it’s free to use"—mind licensing and provenance and follow org policy, which is responsible use.
Common: (1) Content exclusion = keep specific files/repos out of context/suggestions (admin-set at repo/org level; no suggestions appear). (2) Control scope via editor settings + org policy. (3) Ownership/responsibility for adopted code rests with the user/organization. (4) Output may match public code—mind licensing; duplication detection can block/warn.
Watch out: (1) Content exclusion is admin-set and not freely removable by users—it can explain missing suggestions. (2) "AI-generated, so unconditionally free" is false—mind public-code matches and licensing. (3) Exclusion stops context/suggestions but doesn’t retroactively remove already-committed code. (4) Editor settings (individual) and org policy are separate layers (if org-disabled, individuals can’t enable).
6.1.3Section summary
- Content exclusion = keep specific files/repos out of context/suggestions (admin-set at repo/org level)
- Control scope via editor settings + org policy
- Ownership/responsibility for adopted code is the user/org; output may match public code—mind licensing
- Exclusion is admin-set, not freely removable, and not retroactive
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. You must reliably keep files with secrets or specific repos out of Copilot’s context/suggestions. What do you use, and who sets it?
Q2. Who generally holds ownership and responsibility for code that adopts a Copilot suggestion?
Q3. Which is a correct licensing caveat about Copilot output?
Q4. If org policy disables Copilot, can an individual enable it via editor settings?
Q5. Which correctly describes the effect of content exclusion?
Q6. Which setting layers are relevant when you don’t want Copilot used only for files of a certain language?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.