GitHub Copilot (GH-300) · 13% practice allocation

GitHub GH-300: Understand GitHub Copilot Data and Architecture Practice Questions

5 free sample questions from the Understand GitHub Copilot Data and Architecture domain, with answers and explanations. The full GH-300 bank has 115 questions across 6 domains. Questions are scenario-based and written from the official GitHub exam guide.

An enterprise is troubleshooting intermittent Copilot failures behind a proxy that strips unknown HTTP headers and terminates long-lived connections after 30 seconds. Which TWO characteristics of Copilot traffic make these proxy behaviors problematic? (Select TWO.)

A. Copilot uses authorization headers carrying a short-lived Copilot token that must reach the service intact✓ Correct
B. Copilot depends on the proxy rewriting the Host header to the organization's enterprise slug
C. Copilot Chat streams responses over a persistent connection, so aggressive idle/connection timeouts truncate answers✓ Correct
D. Copilot requires the proxy to forward UDP traffic for model streaming
E. Copilot requires clients to keep an inbound WebSocket listener open for the model to call back

Explanation

Correct: authorization headers must pass through unmodified for the request to authenticate against the Copilot service, and chat/streaming responses rely on long-lived HTTP streaming that breaks when proxies impose short connection timeouts. Why the others are wrong: Copilot does not use UDP — all traffic is HTTPS over TCP. There is no requirement or benefit to rewriting the Host header to an enterprise slug; that would break TLS/SNI routing. The model never dials back into the client, so no inbound listener is required.

A security architect must document the end-to-end lifecycle of a Copilot code completion. Place the following in the correct order: (1) proxy applies filters, (2) IDE extension builds prompt from local context, (3) model generates candidate completions, (4) post-processing/filtering of the response, (5) suggestion rendered as ghost text in the editor.

A. 2 → 4 → 1 → 3 → 5
B. 1 → 2 → 3 → 5 → 4
C. 2 → 3 → 1 → 4 → 5
D. 2 → 1 → 3 → 4 → 5✓ Correct

Explanation

Correct: the extension assembles the prompt locally, the request passes through the Copilot proxy where pre-request filtering/authorization occurs, the model generates candidates, the response is post-processed and filtered (for example, duplication detection and toxic-language filtering), and finally the accepted candidate is shown as ghost text. Why the others are wrong: placing the proxy after generation is impossible because all traffic to the model traverses the proxy on the way out. Rendering before post-processing would expose filtered content to the user. Post-processing cannot occur before the model has generated anything.

Which THREE of the following are genuine limitations of LLM-based tools like GitHub Copilot that should be communicated to developers during onboarding? (Select THREE.)

A. Suggestions may be factually wrong or reference APIs that do not exist (hallucination)✓ Correct
B. Copilot can deterministically reproduce the same suggestion for the same prompt every time
C. Copilot guarantees that generated code is free of security vulnerabilities
D. Copilot validates suggestions against your project's unit tests before displaying them
E. The model's knowledge reflects its training data and may not include very recent library versions✓ Correct
F. Very large codebases cannot be fully considered because of context window limits✓ Correct

Explanation

Correct: hallucinated APIs, a training-data knowledge cutoff, and a finite context window are all real, well-documented limitations. Why the others are wrong: Copilot does not run your test suite before showing ghost text — the developer is responsible for verification. It offers no guarantee of secure code; suggestions can contain vulnerabilities and must be reviewed (vulnerability prevention filters reduce but do not eliminate common patterns). Generation is probabilistic, so identical prompts can produce different suggestions rather than deterministic output.

Which TWO signals does the Copilot completion client typically include when building a prompt for an inline suggestion? (Select TWO.)

A. The full commit history of the current branch
B. Code before the cursor (prefix) and, where supported, code after the cursor (suffix) for fill-in-the-middle✓ Correct
C. The file path and programming language of the active document✓ Correct
D. The developer's GitHub follower graph
E. The results of the last local build or test run

Explanation

Correct: inline completion prompts are built from the prefix and suffix around the cursor (enabling fill-in-the-middle behavior) plus metadata such as the file name/path and language identifier, often augmented with snippets from related open tabs. Why the others are wrong: Git commit history is not harvested for inline completion prompts. Build or test output is not captured and sent as completion context. Social graph data has no role in code completion prompts.

A developer working on a monorepo notices Copilot Chat gives better answers when they use the #file reference or open related files. From an architecture perspective, why does this help?

A. It escalates the request to a larger model tier with unlimited context
B. It causes GitHub to index the monorepo on the server so future prompts include the whole repository
C. It increases the relevance of the tokens in the assembled prompt within the limited context window✓ Correct
D. It temporarily expands the model's context window beyond its published token limit

Explanation

Correct: because context is token-limited, explicitly referencing the right files improves the signal-to-noise ratio of the prompt, giving the model the specific context it needs. Why the others are wrong: nothing a user does at request time raises the hard token limit of the model. Referencing files in chat does not trigger server-side repository indexing (indexing for Copilot's repository-wide search is a separate capability with its own configuration). Model selection is not automatically escalated by file references, and no tier offers unlimited context.

Test yourself across every GH-300 domain

The free GH-300 practice test mixes about 20 questions weighted like the exam. The full 115-question bank adds instant grading, flashcards and a timed mock exam.

Take the free GH-300 practice test Practice the full bank

Study this domain

Understand GitHub Copilot Data and Architecture study guide (GH-300) →

Other GH-300 domains

← All GitHub Copilot study resources