Develop a security and compliance plan →hardMultiple ChoiceObjective-mapped

AZ-400 Develop a security and compliance plan Practice Question

Exhibit

{
  "alert": {
    "type": "secret_scanning",
    "secret_type": "Azure DevOps Personal Access Token",
    "secret": "abc123...",
    "repository": "contoso/MyApp",
    "push_protection_bypass": false
  }
}

Refer to the exhibit. You receive a secret scanning alert for an Azure DevOps PAT in a GitHub repository. The push_protection_bypass is false. What does this mean and what action should you take?

⚠ Common exam trap

A common mix-up: candidates confuse `push_protection_bypass` with the secret being pushed successfully; candidates often assume `false` means the secret was allowed through, but it actually means the push was blocked.

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

✓

The secret was blocked from being pushed; you should revoke the PAT and investigate the incident.

When `push_protection_bypass` is `false`, it means the secret was blocked from being pushed by GitHub's push protection feature. The alert indicates the secret was detected and prevented from entering the repository, so the correct action is to revoke the compromised PAT and investigate the incident to prevent future occurrences. Option D correctly identifies that the secret was blocked and prescribes the appropriate remediation steps.

Answer analysis

Option-by-option breakdown

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

✗
The secret was pushed but push protection was bypassed; you need to revoke the PAT and use git filter-branch to remove it from history.
Why it's wrong here
The alert's push_protection_bypass field is false, which directly contradicts the claim that push protection was bypassed; GitHub blocked the push entirely, so the secret never entered the repository history. Revoking the PAT is advisable, but git filter-branch is unnecessary because there is no commit containing the secret to rewrite.
✗
The secret was pushed successfully; you need to rotate the PAT and audit the commit history.
Why it's wrong here
A push_protection_bypass value of false means the push was blocked, not successful; the secret was never committed to the repository history. While rotating the PAT is a prudent precaution, auditing the commit history for the secret is moot since the push was rejected and the secret is not present in any commit.
✗
The secret was pushed and push protection was not bypassed; you need to open a support ticket with GitHub to remove the secret.
Why it's wrong here
Since push protection was not bypassed (push_protection_bypass: false), the push was blocked and the secret never made it into the repository, so there is no secret for GitHub support to remove. Opening a support ticket would be an unnecessary step; the correct action is to revoke the exposed PAT and investigate the alert.
✓
The secret was blocked from being pushed; you should revoke the PAT and investigate the incident.
Why this is correct
The GitHub Secret Scanning push protection alert (with push_protection_bypass: false) confirms the push was rejected before any commit landed in the repository, so the PAT never exists in the commit history. Nevertheless, the PAT was transmitted to GitHub in the blocked push payload and should be treated as exposed, so revoking it is the immediate security action. Investigating the alert helps determine who attempted the push, which repo/branch was targeted, and whether the PAT was compromised elsewhere.

Visual reference

Go deeper

AZ-400 Develop a security and compliance plan Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question