Courseiva
Develop a security and compliance planhardMultiple ChoiceObjective-mapped

AZ-400 Develop a security and compliance plan Practice Question

Your company uses GitHub Enterprise and wants to implement a secret scanning policy to detect and block secrets (e.g., API keys) in code pushes. The policy must allow exceptions for test repositories that use fake secrets. What is the recommended approach?

⚠ Common exam trap

A common mix-up: candidates confuse client-side pre-commit hooks (which are bypassable) with server-side push protection (which is enforced), or mistakenly think GitHub Actions can block a push before it completes.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

Configure secret scanning with custom patterns and use the 'secret_scanning_push_protection' setting with an allow-list for test repositories.

GitHub Enterprise's secret scanning push protection can be configured with custom patterns and an allow-list (via the `secret_scanning_push_protection` setting in the repository's security settings or through the API). This allows you to block pushes containing secrets across all repositories while explicitly exempting test repositories that use fake secrets, meeting the requirement for exceptions without manual intervention.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • Use a pre-commit hook to detect secrets and allow developers to bypass it.

    Why it's wrong here

    Pre-commit hooks are client-side scripts that run only on a developer's local machine and can be trivially bypassed with `git commit --no-verify`, so they do not provide a trustworthy, centrally enforced control for protecting the entire GitHub Enterprise organization against secret leakage.

  • Implement a GitHub Actions workflow that scans for secrets and fails the push.

    Why it's wrong here

    GitHub Actions workflows execute after a push has already been accepted by the server, meaning they can detect and report secrets but cannot prevent the secret from entering the repository history; to actually block the push, you need push protection enforced at the server level, not a post-push workflow.

  • Enable secret scanning for all repositories, then manually disable it for test repositories.

    Why it's wrong here

    Manually disabling secret scanning for test repositories is not scalable or safe because it creates an ongoing administrative burden and increases the risk that a real secret committed to a test repo will go undetected and unprotected, potentially leading to exposure or credential compromise.

  • Configure secret scanning with custom patterns and use the 'secret_scanning_push_protection' setting with an allow-list for test repositories.

    Why this is correct

    Secret scanning with custom patterns is a server-side, centrally enforced feature that can detect organization-specific secrets, and enabling the `secret_scanning_push_protection` setting blocks pushes containing matching secrets while an allow-list lets you exempt designated test repositories from the block without disabling detection—so real secrets are blocked, and test exceptions are managed predictably.

About these practice questions

Courseiva writes every AZ-400 question from scratch — 823 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This AZ-400 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-400 exam.