Task 2.3: Manage and respond to Secret Protection alerts

• ACreate a new key with the same permissions, move the job to it, then revoke the leaked key

  Correct

  Revoking quickly is the priority; switching the job to a new key first avoids the downtime.

• BRevoke the leaked key at once and issue a new one after the nightly job fails

  Incorrect

  That closes the exposure but causes the outage the lead wants to avoid.

• CRewrite the Git history to remove the key, then keep using it

  Incorrect

  Removing a secret from the code or history doesn't stop it being exploited; it must be revoked.

• DPlan the rotation with the payments team for next quarter, since the repository is private

  Incorrect

  An active production credential is high risk even in a private repository, so it calls for quick revocation.

Treat any committed secret as compromised. An active secret or a production credential is high risk, so revoking it is the priority; to avoid downtime, first generate a new secret with the same permissions, make the application use it, and then revoke the old one. Removing the secret from the code or the history doesn't prevent it from being exploited, and a planned, unhurried rotation fits only lower-risk secrets, such as inactive or test credentials.

• ACloud provider keys are always reported to the provider instead of the repository

  Incorrect

  Partner alerts apply to public repositories; these alerts are in the repository list.

• BValidity applies only to GitHub tokens unless validity checks are enabled

  Correct

  Without validity checks, only GitHub tokens get a validity status.

• CThe validity filter works only in the organization's security overview

  Incorrect

  The filter is available on the repository alert list.

• DCloud provider keys are always marked inactive after 30 days

  Incorrect

  There is no such rule; validity comes from checks with the provider.

The validity filter narrows alerts by the validity status of their secrets. By default GitHub checks the validity of GitHub tokens only; to get statuses for partner patterns, validity checks have to be enabled for the repository or through a security configuration.

• AOnly in the organization's audit log

  Incorrect

  Alerts are shown in the repository.

• BIn the Dependabot alerts list

  Incorrect

  Dependabot lists vulnerable dependencies.

• CIn the code scanning alerts list

  Incorrect

  Code scanning lists code findings.

• DIn the Generic alerts list

  Correct

  Generic patterns and AI-detected secrets have their own list.

GitHub separates secret scanning alerts into a Default list (supported and custom patterns) and a Generic list (generic patterns and AI-detected secrets such as passwords). You toggle to the Generic list from the default view.

• Aprops:data_sensitivity:high

  Correct

  props shows alerts for repositories with a given custom property value.

• Btopic:data_sensitivity-high

  Incorrect

  topic matches repository topics, not custom properties.

• Cteam:data_sensitivity-high

  Incorrect

  team shows alerts owned by members of a team.

• Drepo:data_sensitivity:high

  Incorrect

  repo filters by repository name.

The props qualifier displays alerts for repositories with a specific custom property value, for example props:data_sensitivity:high. Other qualifiers filter by repository topic, team, repository name, provider, secret type, validity or resolution.

• AMention the developer in the repository's README file

  Incorrect

  That doesn't assign the alert.

• BAdd the developer to the bypass list

  Incorrect

  The bypass list is about push protection.

• CAssign the alert to the developer

  Correct

  Alerts can be assigned to users with write access.

• DClose the alert as won't fix and reopen it

  Incorrect

  That doesn't assign anyone.

In the alert view, the Assignees control assigns a secret scanning alert to someone with write access to fix.

• AAs safe, if the repository is private

  Incorrect

  Private repositories don't make a committed secret safe.

• BAs compromised

  Correct

  Once committed, a secret should be considered compromised.

• CAs safe if nobody has cloned the repository

  Incorrect

  You can't be sure of that.

• DAs safe once the commit is deleted

  Incorrect

  Copies may remain in history and clones.

Once a secret has been committed to a repository, you should consider it compromised: verify its validity where possible, revoke or rotate it, update services that use it, and check the provider's logs for unauthorized activity.