3.1.3. Potential Harms and Mitigation Strategies
💡 First Principle: Mitigation works by inserting human checkpoints and guardrails between Copilot's suggestion and real-world impact — review, testing, scanning, policy — so that a plausible-but-wrong output gets caught before it causes harm.
The exam pairs harms with mitigations. Know both halves:
| Potential harm | Mitigation strategy |
|---|---|
| Insecure code reaches production | Human review, security scanning, duplication/vulnerability filters, tests |
| Hallucinated API or logic | Verify against real docs; run and test the code |
| Biased / non-inclusive output | Review with awareness of bias; diverse review |
| Sensitive data leaks into prompts | Content exclusions; avoid pasting secrets; policy controls |
| IP / license concerns from matching public code | Enable "suggestions matching public code" filtering; review |
| Over-reliance erodes skill/oversight | Keep humans in the loop; treat Copilot as assistant, not authority |
Notice the pattern: mitigations are layers, not a single gate. No one control catches everything, which is why responsible operation combines human review with automated safeguards and policy.
💡 Key Point: The exam's preferred mitigation almost always adds human oversight or a safeguard, never removes one in the name of speed.
⚠️ Exam Trap: "Disable the security filter to reduce friction" or "skip review because Copilot is reliable" are classic wrong answers. Mitigations exist precisely because the output is fallible.
Reflection Question: Why is responsible mitigation described as layered defense rather than a single checkpoint, and what would you lose by relying on only one control?
