18 real GH-300 sample questions, each with a worked explanation and a rationale for every option, right and wrong. No account, no card. This is the reasoning the GH-300 tests: knowing why the tempting answer is wrong, not just spotting the right one.
The real GH-300 is 60 questions in 90 minutes, pass mark 700 / 1000. For a domain-by-domain breakdown and a study plan, read the GH-300 study guide. The full bank has 273 questions.
lock_openFree sampleUse GitHub Copilot featuresmedium
A developer opens an unfamiliar service file and wants Copilot to explain in prose how the retry logic works and why the team chose exponential backoff, without changing any code. Which Copilot surface best fits this need?
- AUse "Copilot Chat" to ask a natural-language question about the retry logic and receive a conversational explanation of the existing behaviour.check_circle Correct
- BUse "Agent Mode" so Copilot can autonomously run tools, trace the call graph and apply any refactors it judges necessary across the project.
- CUse "Edit Mode" to request a scoped multi-file rewrite of the retry logic that the developer can then review inline before accepting.
- DUse "Plan Mode" to have Copilot break the explanation task into ordered steps before it begins implementing the requested changes.
Recognise that Copilot Chat is the surface for conversational explanations of existing code when no edits are required. Copilot Chat handles question-and-answer interactions and explains existing code in natural language without applying edits, so it serves a pure explanation need where the other modes would alter files or scope a build that the developer did not request.
Why A is correct: Copilot Chat answers conversational questions and explains existing code in prose without modifying files, which matches a read-only explanation request exactly.
Why B is wrong: Agent Mode is built to take autonomous action and edit files, which exceeds and contradicts a read-only request to merely have the existing logic explained.
Why C is wrong: Edit Mode is designed to propose and apply code changes for review, but the developer wants an explanation and explicitly does not want any code changed.
Why D is wrong: Plan Mode scopes implementation work into steps, but no change is wanted here, so producing a build plan answers a question that was never asked.
lock_openFree sampleUse GitHub Copilot featuresmedium
A developer needs to rename a function and update every one of its call sites across four related files, and wants to inspect each proposed change before it lands rather than letting Copilot act on its own. Which surface is the best fit?
- AUse "Agent Mode" so Copilot autonomously decides which files to touch, runs commands and commits the rename without interrupting the developer.
- BUse "Edit Mode" to request the rename across the relevant files and review the proposed multi-file changes inline before accepting or discarding them.check_circle Correct
- CUse "Copilot Chat" to ask how to rename the function and then paste each suggested change into the affected files by hand.
- DUse inline ghost-text completions and accept the suggestion that appears as the developer types in each file in turn.
Choose Edit Mode for scoped multi-file edits that the developer wants to review before applying. Edit Mode is purpose-built for applying a defined change across a set of files while presenting every edit inline for acceptance or rejection, giving the developer review control that Agent Mode's autonomy and Chat's prose answers do not provide.
Why A is wrong: Agent Mode acts autonomously and is tempting for a cross-file edit, but the developer explicitly wants to review each change rather than let Copilot proceed unsupervised.
Why B is correct: Edit Mode applies scoped changes across multiple files and surfaces each edit for the developer to review, which matches a multi-file rename that must be inspected before landing.
Why C is wrong: Copilot Chat can describe the rename but does not apply scoped edits across files, so it leaves tedious manual copying that Edit Mode performs directly.
Why D is wrong: Inline completions assist single-line typing in the active file and cannot coordinate a deliberate rename across four files for structured review.
lock_openFree sampleUse GitHub Copilot featuresmedium
A platform team wants Copilot Chat to act on their internal systems during a conversation: querying a live database for the current schema and opening tickets in their issue tracker without leaving the editor. They plan to connect both systems through Model Context Protocol servers. Which statements about using these servers are accurate? Select TWO.
- AAn MCP server can expose both read tools and action tools, so Chat may both fetch the live schema and create a new ticket during one ongoing conversation.check_circle Correct
- BEach connected MCP server runs as trusted code with real access, so the team must vet the source of any third-party server before they grant it to Copilot.check_circle Correct
- CAn MCP server replaces a custom instructions file, because the standing repository conventions are loaded automatically the moment any server tool is first invoked.
- DOnce an MCP server is connected, content exclusions are applied to every tool call so no excluded file can ever travel to that external system.
- EAn MCP server certifies the correctness of any code it returns, so suggestions produced after a tool call need no further validation by the developer.
Recognise that MCP servers expose read and action tools to Copilot Chat and must be vetted as trusted, accessing code. Model Context Protocol servers publish tools and resources that Copilot Chat can call to read live data or perform actions, and because each server runs with real access to project tools, the team must vet a third-party server's source before granting it rather than assuming it replaces instructions, honours exclusions, or certifies output.
Why A is correct: MCP servers publish tools and resources that Copilot can invoke, and those tools may read data or perform actions such as opening a ticket, so both uses are supported.
Why B is correct: A connected MCP server executes with genuine access to project tools and data, so vetting its provenance and trust before enabling it is a required precaution.
Why C is wrong: Tempting because both extend Copilot, but an MCP server provides tools and data and does not inject standing repository conventions the way a custom instructions file does.
Why D is wrong: Tempting because exclusions sound protective, but they scope which files act as Copilot context and do not police what a connected MCP server can reach or transmit.
Why E is wrong: Tempting because the data feels authoritative, but an MCP server supplies tools and data and never certifies output, so the developer must still validate the result.
lock_openFree sampleUse GitHub Copilot responsiblyeasy
A developer accepts a GitHub Copilot suggestion that calls a date-parsing helper, and the function name and signature look entirely convincing. Which risk of generative AI tools does this scenario most directly illustrate?
- ABias, where the suggestion reflects skewed patterns in the training data and treats one group of inputs less fairly than another group.
- BVendor lock-in, where relying on Copilot ties the developer to a single tool and makes switching to another assistant prohibitively costly later.
- CLatency, where the suggestion arrives too slowly to be useful and interrupts the developer's flow while writing the date-parsing routine.
- DHallucination, where the model produces a confident, plausible-looking suggestion that may reference an API or behaviour that does not actually exist.check_circle Correct
Identify hallucination as the risk where a generative AI tool produces confident output that may reference things that do not exist. Hallucination occurs when a language model generates fluent, confident output that is not grounded in fact, such as a plausible function or API that does not exist, which is why a convincing suggestion still has to be validated rather than trusted on appearance.
Why A is wrong: Bias concerns unfair treatment learned from skewed data, but a plausibly named helper that may not exist is about fabricated output rather than unfairness.
Why B is wrong: Lock-in is a commercial concern about switching tools, which has nothing to do with whether a specific suggested helper actually exists or behaves correctly.
Why C is wrong: Latency is about response speed, not correctness, so it does not describe a suggestion that looks right but may reference something that is not real.
Why D is correct: Hallucination is exactly a confident, plausible output that may invent a non-existent API, so a convincing helper that might not exist is the textbook example.
lock_openFree sampleUse GitHub Copilot responsiblyeasy
GitHub Copilot returns a working code suggestion that compiles and passes a quick smoke test. Under responsible-use principles, who remains accountable for the correctness, security, and licensing of that code once it is committed?
- AThe developer who reviews and accepts the suggestion remains accountable for validating its correctness, security, and licensing before committing it.check_circle Correct
- BGitHub assumes accountability for the suggestion once it compiles cleanly, so the developer can commit accepted output without further review of it.
- CThe model provider becomes accountable because the underlying weights generated the text, leaving the developer responsible only for prompt wording.
- DNo party is accountable while the code is unreviewed, because automatically generated suggestions are treated as drafts that nobody has yet approved.
Recognise that the developer stays accountable for validating Copilot output for correctness, security, and licensing before use. GitHub Copilot is positioned as an assistant that augments rather than replaces the developer, so the principle of human oversight means the person who accepts and commits a suggestion is responsible for checking it, regardless of whether it compiled or passed a quick test.
Why A is correct: Responsible use treats Copilot as an assistant, so the developer who accepts a suggestion stays accountable for reviewing it, which matches the principle of human oversight.
Why B is wrong: It is tempting to assume the vendor carries the risk, but Copilot is an assistant and a clean compile does not transfer accountability away from the developer.
Why C is wrong: The provider trains the model, yet responsible-use guidance places review and acceptance with the developer, not solely on how the prompt happened to be phrased.
Why D is wrong: Treating output as an unowned draft is wrong, since committing it is a deliberate human act that keeps accountability firmly with the developer.
lock_openFree sampleUse GitHub Copilot responsiblyeasy
A team notices that GitHub Copilot consistently suggests variable names and code comments using gendered assumptions when generating user-profile code. Which responsible-AI concern does this pattern best represent?
- AHallucination, because the model is inventing variable names and comments that do not correspond to anything that exists in the codebase.
- BBias, because suggestions can reflect skewed or stereotyped patterns present in the data the model learned from and produce unfair output.check_circle Correct
- CLatency, because the model spends extra time generating profile code and so produces assumptions it would otherwise have left out of the output.
- DThroughput, because the model generates a high volume of profile suggestions and statistically some will contain assumptions about the end users.
Identify bias as the risk where Copilot output reflects skewed patterns learned from training data. Generative models learn statistical patterns from large bodies of existing code and text, so any skew or stereotype in that data can surface as biased suggestions, which is why fairness review of output matters when the code touches people.
Why A is wrong: Hallucination is about fabricated, non-existent facts, whereas the issue here is that real suggestions carry an unfair pattern rather than being invented.
Why B is correct: Bias is exactly when output reflects skewed patterns from training data, so recurring gendered assumptions in generated code is a clear example of it.
Why C is wrong: Latency is about response speed and is unrelated to the content of suggestions, so it cannot explain a recurring unfair assumption in the output.
Why D is wrong: Volume of suggestions does not explain a consistent skew, which points to learned patterns rather than the sheer number of completions produced.
lock_openFree sampleImprove developer productivity with GitHub Copiloteasy
A developer is writing a Python module and wants Copilot to generate a complete function body from a clear description before they write any code. Which prompting practice gives Copilot the best chance of generating an accurate first draft?
- AType only the keyword def on a blank line with no name or parameters, so Copilot is free to invent the whole function from scratch without constraints.
- BOpen a pull request first so Copilot code review can read the diff and then suggest the missing function body back inside the local editor for you.
- CAdd a content exclusion entry for the file, because Copilot only generates a full function body once the path has been declared as excluded in settings.
- DWrite a descriptive function signature and a short comment stating the inputs, the expected output, and an example, then let Copilot complete the body.check_circle Correct
Generate accurate code by giving Copilot a descriptive signature and a comment stating inputs, output, and an example. Copilot predicts completions from the context it is given. A descriptive signature plus a comment naming the inputs, expected output, and an example narrows the prediction toward the intended behaviour, which yields a more accurate first draft than an empty or contextless prompt.
Why A is wrong: Tempting as minimal effort, but with no name, parameters, or intent Copilot lacks context and is far more likely to produce an irrelevant or generic body.
Why B is wrong: Wrong surface: code review comments on existing diffs in a pull request and does not author a brand new function body in the editor before code exists.
Why C is wrong: Content exclusions stop named files being used as context; they do not trigger generation and would actually reduce the context available to Copilot.
Why D is correct: Correct: a clear signature plus a comment describing inputs, output, and an example gives Copilot the specific context it needs to generate an accurate body.
lock_openFree sampleImprove developer productivity with GitHub Copiloteasy
A developer has selected a long, deeply nested function in the editor and wants Copilot Chat to restructure it into smaller helper functions while keeping the behaviour the same. After Copilot returns the refactored code, what must the developer do before relying on it?
// selected: processOrder() with 4 nested loops
/refactor into smaller functions, keep behaviour
- AReview the refactored code and run the tests to confirm the behaviour is unchanged, since the developer stays accountable for correctness and security.check_circle Correct
- BNothing further, because a refactoring produced by Copilot Chat is guaranteed to preserve the original behaviour and so can be committed without any checks.
- CSwitch the account to Copilot Enterprise, because behaviour-preserving refactors are only validated automatically once an Enterprise seat has been assigned.
- DAdd the file to Model Context Protocol so an external server re-checks the refactor and certifies that the helper functions behave like the original code.
Always review and test a Copilot-suggested refactor, because the developer remains accountable for correctness and behaviour. Copilot suggestions, including refactors, are not guaranteed to be correct or behaviour-preserving. The developer is accountable for the code they commit, so reviewing the output and running the existing tests is the necessary step before depending on a Copilot refactor.
Why A is correct: Correct: Copilot output is a suggestion, so the developer must review it and run tests to verify the behaviour is preserved before relying on the refactor.
Why B is wrong: Tempting because the request asked to keep behaviour, but Copilot can introduce subtle changes, so trusting it without review breaks the developer's accountability.
Why C is wrong: Wrong: no plan tier auto-validates a refactor, and Enterprise adds organisation features rather than guaranteeing that suggested code keeps its behaviour.
Why D is wrong: Model Context Protocol supplies extra context to Copilot; it does not certify correctness, and the developer still has to review and test the result.
lock_openFree sampleImprove developer productivity with GitHub Copiloteasy
A developer has finished a public utility function and wants Copilot to draft a documentation comment describing its parameters and return value directly above the function in the editor. Which Copilot capability is the most direct fit for this task?
- APull request summaries, which Copilot writes on GitHub to describe the overall changes in a branch rather than documenting one function inside the editor.
- BAsking Copilot to generate a documentation comment for the function, which it drafts inline or in Chat covering the parameters and the return value.check_circle Correct
- CContent exclusions, which restrict which files Copilot may read as context and therefore cannot author a documentation comment above the function for the developer.
- DSeat administration in Copilot Business, which lets an admin assign licences through the REST API but does not draft any documentation for a function.
Use Copilot to generate documentation comments describing a function's parameters and return value, distinct from pull request summaries. Copilot can read a selected function and draft a documentation comment covering its parameters and return value, inline or through Chat. Pull request summaries describe a whole branch on GitHub, while content exclusions and seat administration are unrelated controls that do not author documentation.
Why A is wrong: Tempting because summaries are documentation, but they describe a whole pull request on GitHub, not a single function's parameters and return value in the file.
Why B is correct: Correct: Copilot can generate a doc comment for the selected function, describing its parameters and return value, which is exactly the task described.
Why C is wrong: Content exclusions only limit context sources; they perform no authoring and so cannot produce a documentation comment for the function.
Why D is wrong: Seat administration manages licences for an organisation; it has nothing to do with writing a documentation comment for a function in the editor.
lock_openFree sampleConfigure privacy, content exclusions, and safeguardsmedium
A platform team on Copilot Business keeps deployment secrets in a file named infra/secrets.env inside a repository, and wants to stop Copilot from using that file as context for code completions and IDE chat across the whole repository. Which control should the team configure to achieve this?
- AAdd the file path to the repository's Copilot content exclusion settings, so Copilot stops using the matched file as context for completions and chat in that repository.check_circle Correct
- BAdd the file path to the repository's .gitignore so Git stops tracking it, because untracked files are automatically withheld from every Copilot request as context.
- CSwitch on duplication detection for the repository, because blocking suggestions that match public code also prevents named local files from being read as context.
- DRegister the repository with a Model Context Protocol server, because an MCP connection lets Copilot decide which sensitive files to withhold from its context.
Recognise repository content exclusions as the control that stops named files being used as Copilot context for completions and chat. GitHub Copilot content exclusions are configured by path at the repository level on Copilot Business and Enterprise, and they prevent the matched files from being sent as context for code completions and IDE chat, which is distinct from Git tracking, duplication detection, or MCP.
Why A is correct: Repository content exclusions match files by path and stop Copilot using them as context for completions and IDE chat, which is exactly the repository-wide control the team needs.
Why B is wrong: .gitignore only controls what Git tracks and has no effect on what Copilot reads as context, so a tempting overlap with version control does not exclude the file.
Why C is wrong: Duplication detection screens suggestions against public source; it does not govern which local files are used as context, so it cannot exclude the secrets file.
Why D is wrong: Model Context Protocol connects Copilot to external tools and data and does not provide a file-exclusion list, so it is the wrong mechanism for withholding context.
lock_openFree sampleConfigure privacy, content exclusions, and safeguardsmedium
An organisation owner on Copilot Business must apply one set of content exclusion path rules to several repositories at once, including repositories that have not been created yet, without editing each repository individually. At which level should the owner configure the exclusions to meet this requirement?
- AAt the repository level in each repository's Copilot settings, because repository exclusions automatically cascade upward and become the organisation default for new repositories.
- BAt the organisation level in Copilot policy settings, because organisation content exclusions apply the same path rules across the org's repositories rather than being set one repository at a time.check_circle Correct
- CIn each developer's editor settings, because the local Copilot enable setting can be pushed to colleagues so the same files are excluded for everyone.
- DIn a personal account setting, because content exclusions defined on the owner's individual account propagate to every repository the owner can administer.
Identify organisation-level content exclusions as the way to apply common path rules across many repositories at once. Copilot content exclusions can be set at the organisation level by an owner, where the path rules apply across the organisation's repositories rather than requiring per-repository edits, making it the correct scope for covering many current and future repositories.
Why A is wrong: Repository exclusions are scoped to their own repository and do not cascade up to become an organisation default, so this misreads the direction of exclusion scope.
Why B is correct: Organisation-level content exclusions let an owner define path rules that apply across the organisation's repositories, which is the single place to cover many repositories including future ones.
Why C is wrong: Editor settings only toggle suggestions on the local machine for languages; they are not shared exclusion rules and cannot apply org-wide path exclusions.
Why D is wrong: Content exclusions are an organisation or repository control, not a personal account setting, so there is no personal-account propagation path for them.
lock_openFree sampleConfigure privacy, content exclusions, and safeguardsmedium
A developer wants Copilot inline completions switched off for Markdown files while staying enabled for all other languages in their IDE, and wants the change to affect only their own machine. Which setting should the developer adjust to control this?
- AThe repository content exclusion list, adding a pattern that matches every Markdown file, because exclusions are how an individual disables a single language in their editor.
- BThe organisation Copilot policy that governs feature availability, because turning the policy off for Markdown disables completions for that language across the whole organisation.
- CThe editor's per-language Copilot enable setting, which lets the developer disable inline completions for Markdown locally while leaving other languages enabled.check_circle Correct
- DThe duplication detection toggle for the editor, because disabling it for Markdown stops Copilot generating any inline completion in files of that type.
Map a personal per-language completion preference onto the editor's Copilot enable setting rather than exclusions or org policy. The IDE exposes a per-language Copilot enable setting that controls inline completions on the local machine, so a developer can disable suggestions for Markdown while keeping other languages active, which is a local editor preference distinct from content exclusions or organisation policy.
Why A is wrong: Content exclusions block files as context for everyone with access, not a personal per-language toggle, so they are the wrong tool for a single developer's editor preference.
Why B is wrong: An organisation policy applies to all members and is not a local per-machine choice, so it overreaches the developer's stated wish to change only their own machine.
Why C is correct: The editor's Copilot enable setting supports per-language control, so the developer can switch off completions for Markdown locally while keeping every other language enabled, matching the requirement.
Why D is wrong: Duplication detection screens suggestions against public code and is not a per-language on or off switch for completions, so it cannot disable Markdown suggestions locally.
lock_openFree sampleUnderstand GitHub Copilot data and architecturemedium
A developer typing in their editor with GitHub Copilot wants to understand what travels to the Copilot service when a ghost-text completion is requested. Which description of the data flow for an inline completion request is accurate?
- AThe editor uploads the developer's entire local repository to GitHub on every keystroke so the model can index the whole project before replying.
- BThe plugin compiles and executes the project locally, then transmits only the runtime output of the program to the Copilot proxy for completion.
- CThe request is answered entirely on the developer's machine by a bundled offline model, so no prompt data leaves the editor at any point.
- DThe editor builds a prompt from nearby code and open-file context, sends it through the Copilot proxy to the model, and returns a suggestion to the editor.check_circle Correct
Describe how an inline completion sends a context-built prompt through the Copilot proxy to a cloud model and returns a suggestion. For an inline completion the editor extension assembles a prompt from nearby code and open-file context, sends it through the Copilot proxy to the cloud-hosted model, and returns the suggestion; it neither uploads the whole repository per keystroke nor runs an offline model locally.
Why A is wrong: Copilot does not upload the whole repository on each keystroke; it assembles a bounded prompt of surrounding context, so describing a full-repo upload per keystroke overstates what is transmitted.
Why B is wrong: Copilot does not compile or run the project; it works from source text context rather than runtime output, so this confuses execution with the contextual prompt that is actually sent.
Why C is wrong: Inline suggestions are produced by a cloud-hosted model reached through the Copilot service, not a bundled offline model, so claiming nothing leaves the editor is incorrect.
Why D is correct: An inline request packages surrounding code and open-file context into a prompt, routes it through the Copilot proxy to the model, and returns the generated suggestion, which is the documented completion flow.
lock_openFree sampleUnderstand GitHub Copilot data and architecturemedium
A reviewer asks what GitHub Copilot uses to build the prompt that is sent to the model when a developer requests a completion inside an editor. Which best describes how that prompt is assembled?
- AFrom the contents around the cursor, the open file, and related context such as nearby open tabs, combined into a prompt sent to the model.check_circle Correct
- BFrom the developer's GitHub commit history across all repositories, which is gathered nightly and cached so the model reflects past authored code.
- CFrom a fixed marketing template that ignores the open file, so identical prompts are produced regardless of where the cursor sits in the project.
- DFrom the project's committed README and documentation files alone, which Copilot reads instead of the code currently open in the editor.
Explain that Copilot builds each prompt from cursor context, the open file, and related signals such as nearby open tabs. Prompt building draws on the text around the cursor, the contents of the open file and related context such as relevant open tabs to give the model enough signal to predict a useful suggestion; it does not use commit history, a fixed template, or documentation files alone.
Why A is correct: Copilot builds the prompt from the code around the cursor, the open file and related signals such as relevant open tabs, which is the documented context that shapes each suggestion.
Why B is wrong: Copilot does not mine a developer's organisation-wide commit history nightly to build prompts; it draws on current editing context, so this misstates the source of prompt material.
Why C is wrong: Prompts are not a fixed template that ignores the file; they vary with cursor position and surrounding code, so claiming identical prompts everywhere contradicts how context is gathered.
Why D is wrong: Copilot builds prompts from live editing context rather than reading only documentation files, so limiting the source to the README misdescribes how prompt material is gathered.
lock_openFree sampleUnderstand GitHub Copilot data and architecturemedium
A compliance lead at a company on Copilot Business asks whether the prompts and suggestions generated by their developers are used to train the underlying foundation models. What is the accurate position for Copilot Business and Copilot Enterprise?
- APrompts and suggestions are used for training by default, but each developer may file a support ticket to remove their data from the next training run.
- BPrompts and suggestions are not used to train the foundation models, which is a data-handling commitment of the Copilot Business and Copilot Enterprise tiers.check_circle Correct
- CPrompts are used for training while suggestions are excluded, because only the developer's input text carries enough signal to improve the models.
- DPrompts and suggestions are used for training only when content exclusions are configured, since exclusions redirect the data into the training pipeline.
State that Copilot Business and Enterprise do not use developer prompts or suggestions to train the foundation models. Under Copilot Business and Copilot Enterprise, GitHub does not use developer prompts or suggestions to train the foundation models; this is a default data-handling commitment, not an opt-out, and content exclusions are a separate context control unrelated to training.
Why A is wrong: The business tiers do not train on prompts by default with an opt-out by ticket; training is excluded outright, so this invents a retraction process that does not apply.
Why B is correct: GitHub commits that under Copilot Business and Copilot Enterprise prompts and suggestions are not used to train the foundation models, which is exactly the assurance the compliance lead is seeking.
Why C is wrong: Neither prompts nor suggestions are used for training on the business tiers, so splitting them and training on prompts alone misrepresents the guarantee that covers both.
Why D is wrong: Content exclusions stop named files being used as context; they do not feed data into training, so tying training to exclusions confuses two unrelated controls.
lock_openFree sampleApply prompt engineering and context craftingmedium
A developer asks Copilot Chat to write a function and gets a vague, unfocused answer. They want to improve the result by giving the request a clearer shape. Which way of structuring the prompt is most likely to produce a focused, usable response?
- AKeep the request to a single ambiguous word so that Copilot is free to infer the broadest possible interpretation of what is wanted.
- BPaste several unrelated requests into one message so that Copilot can choose whichever of the competing tasks it judges to be the easiest.
- CRepeat the same broad sentence three times in a row so the model treats the heavily emphasised instruction as the most important one.
- DState the goal, then the relevant inputs and constraints, then the expected output, so Copilot has a clear and ordered picture of the task.check_circle Correct
Structure prompts as goal, then context and constraints, then expected output to give Copilot the specifics needed for a focused response. A well-structured prompt sequences the goal, the relevant context and constraints, and the desired output. This ordering gives Copilot the concrete signals it needs to scope the task, so the response is targeted rather than the vague output produced by a one-word or scattered request.
Why A is wrong: Tempting because short prompts feel quick, but a single ambiguous word removes the goal, inputs, and constraints Copilot needs, so it tends to produce exactly the vague output described.
Why B is wrong: Bundling unrelated tasks confuses the intent and splits Copilot's focus, which produces a muddled answer rather than the clear single result the developer wants.
Why C is wrong: Repetition adds no new specifics and does not clarify goal or constraints, so the answer stays as unfocused as the original vague request.
Why D is correct: Correct: structuring a prompt as goal, then context and constraints, then desired output gives Copilot the specifics it needs to generate a focused, relevant response.
lock_openFree sampleApply prompt engineering and context craftingmedium
A developer is editing a service file and wants Copilot's inline suggestions to follow the helper functions and types defined elsewhere in the same project. Beyond the current file, what does Copilot most rely on to build context for these completions?
- AThe other relevant files the developer has open in the editor, including neighbouring tabs, which Copilot uses as nearby context for its suggestions.check_circle Correct
- BThe full commit history of the repository, which Copilot reads end to end so that every past change shapes each inline completion it offers.
- CThe organisation audit log, which records seat activity and is consulted to decide which helper functions appear in the developer's inline suggestions.
- DA connected Model Context Protocol server, which is required before Copilot can read any other file in the project for inline completion context.
Recognise that Copilot draws inline context from the active file plus other open files and neighbouring tabs in the editor. Copilot builds context for inline completions from the active file and the other relevant files the developer has open, including neighbouring tabs. Keeping related helpers and types open lets Copilot reference them, which is why opening project files improves suggestion relevance rather than relying on commit history or audit logs.
Why A is correct: Correct: Copilot widens context beyond the active file by drawing on other open files and neighbouring tabs, so helpers and types defined there inform its inline suggestions.
Why B is wrong: Tempting because history holds project knowledge, but Copilot does not scan the entire commit log for inline context; it draws on the code currently open in the editor.
Why C is wrong: The audit log tracks administrative events for Copilot Business and Enterprise and has no role in supplying code context to inline completions.
Why D is wrong: Model Context Protocol can add external context for some scenarios, but it is not required for Copilot to use already open project files when forming inline suggestions.
lock_openFree sampleApply prompt engineering and context craftingmedium
A developer notices that Copilot keeps suggesting code patterns from an old module they closed earlier and ignores the new helper module they actually want it to follow. Without changing any settings, what is the most direct way to steer the inline context towards the new module?
- AAdd a content exclusion rule for the new module so that Copilot is forced to treat its functions as the preferred source for inline suggestions.
- BOpen the new helper module in a neighbouring tab and keep it open while editing, so Copilot can use that relevant file as nearby context.check_circle Correct
- CSwitch the editor to a Copilot Business seat, since wider file context for inline suggestions becomes available only after the plan is upgraded.
- DOpen a pull request for the branch so Copilot code review can index the new module and then prioritise it within local inline completions.
Use open files and neighbouring tabs to steer Copilot's inline context towards the modules you want it to follow. Copilot forms inline context from the files currently open, including neighbouring tabs. Opening the new helper module and keeping it visible places its patterns in scope, so suggestions follow it. Content exclusions, plan tier, and code review do not control which open file shapes a completion.
Why A is wrong: Content exclusions stop named files being used as context; excluding the new module would remove it from suggestions rather than make Copilot follow it.
Why B is correct: Correct: because Copilot uses open files and neighbouring tabs as context, opening the desired module keeps its patterns in view and steers suggestions towards it.
Why C is wrong: Using open files as context is part of the core editor experience across plans and is not unlocked by moving to a Copilot Business seat.
Why D is wrong: Copilot code review analyses pull request diffs on GitHub and does not feed indexed modules back into the local editor's inline completion context.
Examworthy is not affiliated with or endorsed by GitHub. All questions are original, blueprint-aligned practice material. We never reproduce live exam items. GH-300 and related marks belong to their respective owners.
