Free GH-300 practice test

Fairness is the Responsible AI principle most directly concerned with ensuring AI systems do not perpetuate or amplify biases related to race, gender, disability, or other attributes. Bias in training data that affects outputs is a fairness concern. Option C is incorrect: Reliability and Safety addresses whether the system behaves as expected and avoids causing harm, not specifically bias in outputs. Option B is incorrect: Privacy and Security pertains to protecting personal data and preventing unauthorized access. Option D is incorrect: Inclusiveness is about ensuring AI is designed to benefit all people and not exclude groups, which is related but is a broader design principle rather than the specific mitigation of training-data bias.

GitHub Copilot is a cloud-based service. The IDE extension sends code context to GitHub's servers over HTTPS (port 443), and the AI inference is performed server-side. Enterprise deployments must ensure that firewalls and proxies allow outbound HTTPS to GitHub's Copilot API endpoints (e.g., api.github.com, copilot-proxy.githubusercontent.com). Option C is incorrect: Copilot uses TCP/HTTPS, not UDP, for communication. Option A is incorrect: Copilot does not download a local model and does not function offline; all inference is cloud-based. Option B is incorrect: inference is not performed locally in the IDE plugin, and additional endpoints beyond just github.com may need to be allowlisted.

GitHub Copilot includes content filtering (responsible AI safeguards) that evaluates both the prompt and the potential output against content policies. Requests to generate harmful code — such as code enabling unauthorized access — are suppressed by these filters. Option A is incorrect: duplicate detection is concerned with matching public code for copyright/license reasons, not with blocking harmful intent. Option C is incorrect: token limits are a technical constraint on input length, not a safety mechanism for harmful content. Option D is incorrect: there is no 'context window reset' mechanism designed to clear dangerous context; this is not a real Copilot feature.

A and B are correct. Copilot usage metrics report aggregate activity: the number of inline code suggestions shown and the number accepted (which together give the acceptance rate), alongside other adoption and usage figures. C is wrong: the metrics do not expose the actual code content of accepted suggestions. D is wrong: the metrics are aggregate counts and rates; they do not include the text of developers' Copilot Chat prompts. E is wrong: Copilot does not log individual keystrokes per user session in its usage metrics.

Copilot Enterprise includes Copilot Chat integrated into GitHub.com. Developers can open the Copilot Chat panel while viewing a file in their browser and ask questions like 'explain this function' — Copilot has context of the file being viewed. gh copilot explain (CLI) works on shell commands, not arbitrary code files, and is not invoked via a URL. Knowledge bases index repos for organizational Q&A context but are not required to explain a specific file viewed in the browser. Inline completions are an IDE feature and do not activate on GitHub.com file views.

Copilot Enterprise exclusively offers: (A) knowledge bases for indexing internal org repositories, (D) Copilot Chat on GitHub.com customized with organizational context (including the ability to use knowledge bases in chat), and (C) pull request summarization on GitHub.com. These are GitHub.com-integrated features that require Enterprise. Copilot Chat in the IDE (F) is available on both Business and Individual plans. Organization-level policy controls (B) are available in Copilot Business. Audit log access (E) is also available in Copilot Business — it does not require Enterprise.

The 'duplication detection' (public code filter) setting that blocks suggestions matching public code is available starting with Copilot Individual. Individual users can toggle this setting in their personal settings. Copilot Business and Enterprise also include it, but they allow organization admins to enforce it as a policy. The feature is therefore not exclusive to Business or Enterprise, and it does exist — making options C and D incorrect.

The Copilot usage metrics dashboard shows aggregate data including suggestions shown vs. accepted (acceptance rate) and a breakdown of usage by programming language and editor. It does not expose the specific lines of accepted code with commit history — that level of detail is not tracked at the org metrics level. It does not attribute rejected suggestions to individual developers by name (which would raise privacy concerns). It also does not report on security vulnerabilities prevented, as that is not a tracked Copilot metric.

Correct: the model has a finite context window (token limit). The IDE client selects a limited amount of context — typically the active file plus snippets from related/open files — and anything not included, or that exceeds the token budget, cannot influence the suggestion. Why the others are wrong: exclusion of closed tabs is a context-budget and heuristics matter, not a security policy. The duplication detection filter blocks suggestions that match public code; it does not remove your local helper from the prompt. Copilot code completion context comes from the editor, not from a requirement that code be committed and pushed.

Correct: the proxy is the gateway between the IDE client and the model; it validates the Copilot token/entitlement, applies policy and filtering, and relays requests and responses. Why the others are wrong: any caching for latency happens in the client, not in a cloud proxy, and a cloud service cannot cache on the developer's machine. The proxy is not an audit store of prompt contents for administrators. Token prediction is performed by the model itself, not the proxy.

Correct: for Copilot Business/Enterprise, code completion prompts and suggestions are treated as transient and are not used to train the foundation models. Why the others are wrong: there is no 30-day retention window for using prompts to fine-tune a shared model for business plans. Accepted suggestions are never committed anywhere by GitHub; committing is entirely the developer's action. Audit logs record administrative and policy events (such as policy changes and seat assignments), not the contents of prompts or source files.

Few-shot examples demonstrate the target format concretely, which is the standard remedy when zero-shot instructions yield inconsistent structure. Repeating an instruction verbatim several times adds tokens without adding information about the template's exact shape. Inline completion is not inherently more deterministic and gives less room to specify formatting than chat. Vague meta-instructions like 'be consistent' provide no structural signal the model can imitate.

#selection narrows context to the highlighted lines, which is valuable in a very large file, and the selection alone may be insufficient when the defect originates elsewhere — adding #file or other references supplies the missing context. #selection does not pull in the whole file; that is precisely what distinguishes it from #file or #editor. #selection is available in the Chat view as well as inline chat. The final option is a true statement about prompt specificity, but the question asks specifically about statements regarding #selection behavior in this scenario; the two selection-scoping statements are the intended correct pair.

Copilot assembles the prompt from the current file (including code after the cursor, not just before it) and from neighboring open tabs, plus signals like file path and language. Browser history and open web pages are outside the IDE and are never read. Full remote commit history across all branches is not gathered for inline completion. Chat transcripts from a different workspace on a prior day are not carried into an unrelated completion request.

Refining the prompt to explicitly request mocking of the database dependency (and specifying the framework, e.g., Jest with jest.mock or Python's unittest.mock) guides Copilot to produce isolated, fast, and reliable unit tests. Copilot's generated tests are not sandboxed — they would attempt to connect to a real database if run. Switching AI models does not change the fundamental need to specify mocking intent in the prompt. /fix is designed to repair broken or erroring code, not to restructure test architecture from scratch; a targeted prompt is far more effective here.

Hallucination is a known limitation of large language models including GitHub Copilot — it can generate confident, syntactically plausible suggestions that reference APIs, methods, or parameters that do not exist. This is the most likely explanation when a suggested identifier cannot be found anywhere. While private methods exist, they are typically still discoverable in source code; a completely absent method is a stronger signal of hallucination. Updating the library is unlikely to introduce a method that has no documentation trail. Copilot does not cross-reference compatible libraries and present their APIs as belonging to your current library; that would be a different type of error (wrong library suggestion), but the scenario describes a completely unknown method, which aligns with hallucination.

#file allows the developer to reference a specific file by name and attach its full contents as context to the chat prompt, which is ideal when you want Copilot to see a particular file regardless of what is currently visible. #selection only includes the currently highlighted text. #editor includes the content of the currently active editor tab, which may not be payment_processor.py at the time of the prompt. #terminalLastCommand injects the most recent terminal command and its output, which is unrelated to reading source file contents.

The GitHub Copilot Metrics API (/orgs/{org}/copilot/metrics) requires the caller to authenticate with a token holding manage_billing:copilot (or at minimum read:org for some endpoints) and is available only to organizations on Copilot Business or Enterprise plans. Option C is incorrect — a copilot PAT scope does not exist; Copilot API access uses billing/org management scopes. Option B is incorrect — the API is a standard REST API accessible from any HTTP client, not restricted to GitHub Actions. Option D is incorrect — the Metrics API returns aggregated daily or summary statistics via REST (JSON over HTTPS), not real-time per-keystroke data over WebSockets.

Copilot Business organization administrators can enable or disable specific Copilot features — including Copilot Chat in the IDE — via the Policies section in Organization Settings → Copilot. Setting 'Copilot Chat in the IDE' to Disabled enforces this for all members regardless of their personal settings. Option C is incorrect — relying on individual developers to self-configure does not provide enforcement and can be overridden. Option B is incorrect — PAT scopes do not control access to Copilot Chat features; Copilot access is seat-based and policy-based, not token-scope-based. Option D is incorrect — uninstalling the extension from device images is an IT endpoint management approach, not a GitHub platform policy, and would not be effective for developers who install extensions themselves.

Organization-level content exclusions are configured by an organization administrator in the organization's GitHub Copilot policy settings under 'Content Exclusion'. This enforces the exclusion for all members and overrides individual user settings. Option D is incorrect — personal settings apply only to the individual user and cannot be mandated by admins for all members. Option C is incorrect — .copilotignore is not an official GitHub Copilot feature; content exclusion is managed through repository or organization settings, not a .copilotignore file. Option A is incorrect — repository visibility controls who can access the code, but does not instruct Copilot to exclude that content from suggestions.