A water utility must enable Copilot for regulated billing code without exposing every city repo. Which enablement scope is most appropriate?
Select an answer to reveal the explanation.
Short Explanation
Regulated billing code is a locked pump room—turn Copilot on for that repo, not by unlocking every door in city hall.
Full Explanation
Repo-scoped Copilot enablement for the regulated billing SQL project is the most appropriate scope when a water utility must enable Copilot for regulated billing code without exposing every city repository. Narrow enablement applies AI assistance where it is needed under policy while avoiding organization-wide exposure of unrelated municipal codebases.
Org-wide Copilot with no repository boundaries or policy fails by concept because it maximizes context exposure across the city estate and weakens governance. Public gist sharing of production billing procedures fails because it publishes regulated utility code outside controlled channels. Disabling source control so Copilot can edit files only on laptops fails because it destroys change control and auditability required for regulated billing systems.
Exam caveat: DP-800 governance answers prefer scoped enablement under policy. Reject unbounded org-wide enablement, public sharing of production procedures, and abandoning source control as enablement shortcuts.
Operational check: Enable Copilot only on the regulated billing SQL repository or approved group, verify other city repos remain out of scope, keep billing code in source control with pull-request review, and document the enablement decision for utility compliance stakeholders.