GH-300 - Use GitHub Copilot responsibly (18% of the exam) - Section 1.2

Identify potential harms of AI usage and the strategies that mitigate them.

Identify the potential harms of using AI assistants - insecure code, licence and attribution issues, exposure of sensitive context, and automation bias - and choose the mitigation that addresses each, such as review, testing, content exclusions, and duplication detection.

AI harmsMitigation strategiesAutomation biasInsecure suggestions

Practice question for this objective

Free sampleUse GitHub Copilot responsiblymedium

A team measures throughput and finds developers merge GitHub Copilot suggestions far faster than hand-written code, but their post-release defect rate has climbed over the same period. A lead wants a mitigation that targets the most likely cause rather than simply slowing everyone down. Which approach best addresses the underlying harm?

ADisable inline completions for the whole team and permit only Copilot Chat, since chat answers are checked more carefully before code lands.
BMove the organisation from Copilot Business to Copilot Enterprise so the stronger models reduce the number of defective suggestions reaching the branch.
CRequire a focused human review and test pass on accepted suggestions, since the rising defects point to automation bias rather than raw speed. Correct
DTurn on the duplication detection filter for the organisation so suggestions matching public code are blocked before they can introduce the defects.

Recognise automation bias from a fast-acceptance, rising-defect pattern and apply human review and testing as the targeted mitigation. Automation bias is the tendency to over-trust automated output. The remedy is keeping a human reviewer and tests in the loop on accepted suggestions, because no model tier, surface, or filter substitutes for verifying correctness before merge.

Why A is wrong: This is tempting because chat feels more deliberate, but the surface is not the cause and removing completions blunts a useful tool without addressing the unchecked acceptance behaviour.

Why B is wrong: A plan change is appealing as a quick fix, but no plan validates correctness for the developer, and the defects stem from unreviewed acceptance, not from model tier.

Why C is correct: The pattern of fast merges plus rising defects is the signature of automation bias, where developers trust fluent output without scrutiny, so a review and test gate targets the real cause.

Why D is wrong: Duplication detection sounds protective, but it only addresses verbatim public-code matches and licence risk, not the correctness defects caused by accepting suggestions without review.

See more GH-300 practice questions, answers explained.

Exam traps in Use GitHub Copilot responsibly

Answers that look right on this material and are not. Each one is a distractor from a different question in the GH-300 bank for this domain.

Merge the function on the strength of Chat's review, since an explicit no-issues result from Copilot serves as the security sign-off for the authentication change.
Why it is wrong: A Chat review is an assistive opinion, not a security sign-off, so merging sensitive auth code on its say-so skips the validation the accountable developer owes.
Configuring content exclusions on the affected repositories, which prevents those repositories from emitting any suggestion that resembles public source code.
Why it is wrong: Content exclusions stop named files being used as context and have scope limits; they do not screen suggestions against public code for matches.
Rely on Copilot's duplication detection to block matches against public code, treating that filter as the team's defence against insecure suggestions being accepted.
Why it is wrong: Duplication detection can block suggestions matching public code, but it judges similarity rather than security, so it does not catch insecure patterns the developer might accept.

Examworthy is not affiliated with or endorsed by GitHub. Original, blueprint-aligned practice material only.