A city Azure SQL team plans to enable GitHub Copilot against municipal schema in a shared repo. What security impact should leaders evaluate first?
Select an answer to reveal the explanation.
Short Explanation
Letting Copilot see your schema is like handing a consultant the building blueprints—useful, but city policy has to decide what leaves the building.
Full Explanation
The first security impact city Azure SQL leaders must evaluate is that schema and code context may be sent to the model service and therefore must be assessed against civic data-handling policy before enabling GitHub Copilot on a shared municipal repo. AI-assisted SQL tooling is useful, but enablement is a confidentiality and data-handling decision—not a free productivity toggle.
The claim that Copilot automatically encrypts all production columns with Always Encrypted fails by concept because Copilot does not replace or auto-apply Always Encrypted; encryption remains an explicit database security design. The claim that enabling Copilot replaces Row-Level Security fails because RLS is an access-control feature independent of AI coding assistants. The claim that Copilot disables auditing on any table it touches fails because auditing configuration is not turned off by Copilot enablement; suggesting otherwise invents a nonexistent control interaction.
Exam caveat: DP-800 AI-assisted development items emphasize policy, scope, and data exposure—not magical security side effects. Prefer answers about context leaving the environment and least privilege; reject distractors that claim Copilot auto-implements or disables core SQL security features.
Operational check: Complete a municipal data-handling review covering what schema/code may enter Copilot context, restrict enablement to approved repos, document residual risk for leadership, and keep Always Encrypted, RLS, and auditing governed separately from AI tooling decisions.