What's changed: New GH-300 Chapter 2 (IDE & CLI = enable, inline/Chat/Plan Mode, Copilot CLI, content exclusion; advanced = Edit Mode/Agent Mode/MCP, agent sessions/sub-agent delegation, code review, instructions/prompt files, PR summaries/Spaces/Spark, Chat commands/limits; org settings = policy mgmt/Code Review policy/feature availability (IDE+github.com)/audit logs/REST API subscriptions)
2.3Organization-wide Settings and Policies
Understand organization-wide policy management, enabling Copilot Code Review policies, managing feature availability across IDEs and github.com, using audit log events, and managing subscriptions via the REST API.
When an org adopts Copilot, admins govern "who can use which features, and how" via policies. GH-300 tests org-wide settings, policies, auditing, and subscription management. Policies are set at the enterprise/organization level and can enable/disable features individually (some span both the IDE and github.com).
2.3.1Policy management and feature availability
Admins manage the availability of each Copilot feature (chat, code review, CLI, external connections) via org policy. For example, enabling the Copilot Code Review policy rolls out review assistance to org standards. Features can be controlled across the IDE and github.com, aligning the user experience with org policy. Safety-related settings like duplication detection and content exclusion (Chapter 6) are also org-level controls.
2.3.2Audit logs and subscription management
Governance needs visibility. Audit log events let you track operations like policy changes and access—seeing "who changed what, when." Subscription (seat) management is available via the UI and the REST API, so you can automate seat assignment/removal and usage retrieval—ideal for large orgs to manage seats with onboarding/offboarding and run inventories programmatically.
Common: (1) Orgs manage feature availability via policy (e.g., enabling the Copilot Code Review policy). (2) Feature control spans both the IDE and github.com. (3) Audit log events track "who changed what, when." (4) Subscription (seat) management via the REST API = automate assignment/removal/usage. (5) Policies are set at the enterprise/organization level.
Watch out: (1) Feature availability (policy) and individual settings are separate layers—if disabled org-wide, individuals can’t use it. (2) Audit logs track "changes," not store code content. (3) REST API seat management is under the same governance as the UI—it doesn’t silently widen permissions. (4) Enabling the Code Review policy does not replace human review (it assists).
2.3.3Section summary
- Orgs manage feature availability via policy (e.g., Copilot Code Review); spans IDE and github.com
- Audit log events track operations (who/when/what)
- Subscription (seat) management via REST API = automate assignment/removal/usage
- Policies are enterprise/org level; the Code Review policy does not replace human review
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. An org admin wants to enable/disable specific Copilot features across both the IDE and github.com. What do they use?
Q2. In a large org you want to automate Copilot seat assignment/removal and usage retrieval with onboarding/offboarding. What do you use?
Q3. You want to track "who changed which policy, when" in the org. What do you use?
Q4. You want to roll out Copilot code-review assistance to org standards. What is appropriate?
Q5. For Copilot Chat being unavailable in an org, what should you check before individual settings?
Q6. Which is a correct statement about audit log events?