GH-500 - Configure and use Secret Protection (18% of the exam) - Section 2.3

Manage the secret alert lifecycle (creation, status, dismissal) and apply appropriate remediation actions when a secret is exposed.

Manage the full secret alert lifecycle from initial detection through closure, including status transitions and selecting the correct dismissal reason. Apply appropriate remediation actions when a secret is exposed, specifically revoking the compromised credential and rotating to a new one.

secret alert lifecycleremediationrevoke and rotatedismissal reasons

Practice question for this objective

Free sampleConfigure and use Secret Protectionmedium

An incident responder discovers a secret scanning alert for an exposed cloud access key that the validity check reports as active. They have limited time and must order the remediation steps so that the exposure stops causing harm at the earliest possible moment. Which sequence reflects the correct remediation priority?

Alert: provider cloud access key
Validity: active
Locations: commit a1b2c3 (3 weeks ago) on default branch
  • AResolve the alert as revoked first to clear it from the queue, then rotate the key, then notify the affected service owners that the credential changed.
  • BRotate or revoke the credential at the provider first so the exposed value can no longer authenticate, then resolve the alert as revoked, and rewrite history only if policy requires removing the value. Correct
  • CRewrite the git history to purge the commit first, then rotate the key, then resolve the alert once the value no longer appears in any commit on the branch.
  • DDisable secret scanning on the repository first to stop further alerts arriving, then rotate the key, then re-enable scanning and resolve the now-closed alert.
Order secret exposure remediation so that revoking or rotating the live credential comes first, before resolving the alert or rewriting history. An active exposed credential can be used by anyone who has copied it, so the first and most urgent step is to revoke or rotate it at the provider, which immediately removes the live risk; resolving the alert and any optional history rewrite follow because they do not by themselves invalidate the credential.

Why A is wrong: This puts bookkeeping ahead of remediation; resolving the alert while the key is still active leaves a live exposure and misrepresents the state, since the credential has not yet been invalidated.

Why B is correct: Invalidating the live credential is the action that immediately stops harm because the exposed value becomes useless; resolving the alert records the disposition, and history rewriting is an optional later step that does not reduce live risk.

Why C is wrong: History rewriting is slow and does not neutralise a key that anyone may already have copied; rotating must come first because the leaked value is live until it is invalidated at the provider.

Why D is wrong: Disabling detection blinds the team and does nothing to neutralise the exposed key; the priority is to invalidate the live credential, not to suppress the alerting that surfaced it.

See more GH-500 practice questions, answers explained.

Exam traps in Configure and use Secret Protection

Answers that look right on this material and are not. Each one is a distractor from a different question in the GH-500 bank for this domain.

  • Used in tests, because the token is being retired and will soon serve no production purpose.

    Why it is wrong: Used in tests is reserved for credentials that exist only inside test fixtures and never authenticate against a real system; this token is a live credential, so the reason would misrepresent its nature.

  • Dismiss the secret scanning alert as a false positive, then rewrite the repository history to purge the commit that introduced the key.

    Why it is wrong: Dismissing as a false positive is wrong because the key is a genuine exposed credential, not a misdetection, and dismissal records an inaccurate reason. Rewriting history also does not help once a secret is public, because it may already have been cloned, cached, or harvested.

  • False positive, because the value is harmless and therefore the detection should be treated as an incorrect match.

    Why it is wrong: False positive is tempting because the token is harmless, but that reason means the pattern matched something that is not actually a secret of that type. Here the detector matched a real token format, so the accurate reason is that it is used in tests, not a misdetection.

Examworthy is not affiliated with or endorsed by GitHub. Original, blueprint-aligned practice material only.