An administrator opens the Security settings of a private repository in an organisation that owns "Secret Protection" licences and wants to turn on push protection so that pushes containing recognised secrets are blocked. The push protection control appears greyed out. What must be true first for push protection to become available on this private repository?
- AA custom secret pattern must be defined for the repository, because push protection only blocks pushes that match an organisation-authored pattern.
- BThe default branch must have a branch protection rule requiring a review, because push protection enforces blocking only on protected branches.
- CThe repository must be made public, because push protection on private repositories is offered only at the organisation level and not per repository.
- DSecret scanning must be enabled for the repository, because push protection is built on the same detection engine and cannot run without it. Correct
Why A is wrong: Push protection blocks against the supported provider and partner patterns by default and does not require a custom pattern to function. Custom patterns extend coverage but are not a prerequisite, so this misstates the dependency.
Why B is wrong: Push protection evaluates the contents of any push regardless of branch protection rules, so a review requirement is unrelated. This is plausible because both are push-time controls, but they are independent mechanisms.
Why C is wrong: With a "Secret Protection" licence, push protection is available on private repositories at the repository level, so changing visibility is unnecessary and undesirable. The premise that it is organisation-only for private repositories is incorrect.
Why D is correct: Push protection uses secret scanning's detection of known secret patterns to decide what to block at push time, so the repository must have secret scanning enabled before push protection can be switched on. That dependency is why the control is greyed out.