Understand GitHub Copilot Data & Architecture
This skill area accounts for 10–15% of the exam. It covers how Copilot handles data, the flow from input to suggestion, proxy filtering, post-processing, the code suggestion lifecycle, and inherent LLM limitations.
Data Handling & Flow
Data Usage, Flow & Sharing
Understanding how GitHub Copilot handles data is essential for both the exam and for making informed decisions about deploying it in your organization. Refer to the GitHub Trust Center for authoritative details.
Three Categories of Data
- Prompts (input): Code context, comments, open files, and instructions assembled and sent to the model
- Suggestions (output / completions): The code completions returned by the model to the IDE
- Telemetry / engagement data: Whether you accepted or rejected a suggestion; usage patterns collected for product improvement (scope varies by plan)
Data Policies by Plan — Exam-Critical Table
| Data Policy Aspect | Free / Pro / Pro+ / Max | Business | Enterprise |
|---|---|---|---|
| Prompts retained for model training? | User opt-in/opt-out choice | No — never | No — never |
| Suggestions retained for model training? | User opt-in/opt-out choice | No — never | No — never |
| Telemetry / engagement data collected? | Yes (opt-out available) | Limited / no individual prompts | Limited / no individual prompts |
| Content exclusions available? | No | Yes | Yes |
| Data stored during request? | Transiently (not persisted) | Transiently (not persisted) | Transiently (not persisted) |
Business and Enterprise plans never use prompts or suggestions for model training. Free/Pro/Pro+/Max users can control this via their account settings (opt in or out) — Max is still an individual plan, so it follows the same data policy as Free/Pro/Pro+, not the Business/Enterprise policy. This is one of the most frequently tested data architecture facts.
Input Processing & Prompt Building
Copilot assembles a prompt from multiple context sources before sending it to the LLM. Knowing the priority and composition of these sources is testable.
Context Sources (Priority Order, Highest First)
- Selected code: Any code you have highlighted is treated as primary context
- Current file: Code immediately surrounding the cursor (both above and below) has the highest automatic influence
- Open tabs: Other files open in the IDE supply supplementary context; opening relevant files improves suggestions
- Repository / workspace structure: File paths and project layout help detect language, framework, and conventions
- Instructions files: Repository-level instructions (
.github/copilot-instructions.md) and path-specific instructions - Chat history: Previous messages in the current chat session (for Chat requests)
The prompt is constructed to fit within the model's context window (a finite token limit). Copilot prioritizes the most relevant context when the window would be exceeded — less relevant content is dropped.
What the Proxy Constructs
- The IDE extension collects the context sources above
- Strips any content matching exclusion rules
- Assembles a structured prompt with system instructions + code context + user request
- Sends the assembled prompt via an encrypted connection to GitHub's proxy service
Proxy Filtering & Post-Processing
GitHub operates a proxy service between the IDE client and the underlying LLM. This is architecturally significant — it is where data policies are enforced.
The Proxy's Role
- Acts as a gateway: the IDE never communicates with the LLM directly
- Enforces content exclusion rules before the prompt reaches the model
- Routes the prompt to the appropriate model (based on user/org model selection)
- Applies telemetry and data policy controls
Post-Processing Pipeline (output side)
- Duplication detection: Checks if the suggestion matches publicly available code; suppresses if configured to block
- Safety / toxicity filters: Filters harmful, offensive, or dangerous content
- Quality filters: Suppresses low-confidence or very short/unhelpful suggestions
- Formatting adjustments: Indentation and syntax are normalised to match the surrounding code context
- Multiple candidates: The proxy may return multiple suggestion candidates for cycling (Alt+] / Alt+[)
The proxy is where all data policy decisions happen: content exclusion enforcement, duplication detection, safety filtering, telemetry collection, and routing. The IDE extension is just a client; the model is just an inference engine. The proxy is the intelligent intermediary.
Lifecycle & Limitations
Code Suggestion Lifecycle (End-to-End)
Being able to trace a suggestion from user action to acceptance is a key exam topic. Study this flow carefully.
- Developer action: Types code, writes a comment, opens a file, or initiates chat
- Context gathering (IDE extension): Collects current file, selected code, open tabs, repo structure, instructions files
- Content exclusion check (IDE): Removes any content from excluded files/repos before sending
- Prompt assembly: Fits context into the model's token window; drops lower-priority context if needed
- Encrypted transmission: IDE extension sends the assembled prompt to GitHub's proxy over HTTPS
- Proxy processing: Routes to the selected model; applies data policies and telemetry controls
- LLM inference: The language model generates one or more candidate completions
- Post-processing (proxy): Applies duplication detection, safety filters, quality checks, formatting
- Response delivery: Filtered suggestions returned to the IDE extension
- Display: Ghost text appears (or Chat response shown) in the editor
- Developer decision: Tab to accept / Esc to dismiss / Alt+] to cycle / modify inline
- Telemetry: Acceptance/rejection recorded per plan data policy
Limitations of LLMs & Copilot
Inherent LLM Limitations
| Limitation | Practical Implication |
|---|---|
| No semantic understanding — pattern matching only | May produce syntactically correct but logically wrong code |
| Finite context window (token limit) | Cannot consider the full codebase at once; context is sampled |
| Training data cutoff | May suggest deprecated APIs, outdated security practices, or non-existent methods |
| Hallucinations | Generates non-existent function names, wrong library APIs, or fabricated facts — with full confidence |
| No runtime awareness | Cannot run code, call APIs, or verify its output is correct at runtime |
| Non-determinism | Same prompt can yield different results; not reproducible |
| Bias from training data | May reproduce insecure patterns, outdated idioms, or biased language from training corpus |
Copilot-Specific Limitations
- Suggestion quality varies significantly by programming language — popular languages (Python, JavaScript, TypeScript) have better training coverage than niche ones
- Chat rate limits vary by plan and can restrict usage mid-session
- Content exclusions do not apply to CLI, cloud agent, or Agent Mode
- May not follow complex architectural patterns without explicit instructions or examples
- Cannot guarantee suggestions are free of security vulnerabilities
Be able to trace the full suggestion lifecycle in order. Know that the proxy is the enforcement point for data policies, not the IDE or the model. Understand the difference between limitations that are inherent to all LLMs vs. limitations specific to Copilot's implementation.
Study Resources
- GitHub Trust Center Authoritative source on data handling, privacy, and security for GitHub Copilot.
- Copilot Plans & Features (GitHub Docs) Data retention policies across all plans — essential for exam data questions.
- What Is GitHub Copilot? (GitHub Docs) Architecture overview, capability descriptions, and platform support.
- GitHub Copilot Fundamentals Part 1 (Microsoft Learn) Learning path covering data flow, architecture, and plan differences.
- GH Certified — Practice Questions Community practice tests with data architecture and privacy questions.