Task 3.4: Configure policies, permissions, and integrations

• AA custom security configuration with dependency review set to Enforced

  Incorrect

  Security configurations enable dependency review; they don't require the action's workflow to pass.

• BA branch ruleset with "Require workflows to pass before merging" pointing at the workflow

  Correct

  A ruleset can require the central dependency review workflow for targeted repositories.

• CAn enterprise policy that allows repository admins to enable dependency review

  Incorrect

  Policies decide who may enable features; they don't run or require workflows.

• DDependabot security updates for every repository, so that dependency review runs on their pull requests

  Incorrect

  Security updates open pull requests; they don't enforce a review workflow on other pull requests.

To enforce the dependency review action across an organization, add the action to one repository and configure it, then create an active branch ruleset for the organization with the rule "Require workflows to pass before merging", selecting that repository, branch and workflow file. Pull requests can then merge only after the workflow passes.

• ANo; the policy blocks everyone below enterprise owner from changing Dependabot alert settings

  Incorrect

  The policy targets repository administrators only.

• BNo; the security manager must have bypassed the policy with an exemption

  Incorrect

  There's no exemption; security managers simply aren't restricted.

• CYes; the policy restricts only repository administrators

  Correct

  Owners and security managers can enable security features whatever this policy says.

• DYes; the policy takes effect only after the next billing cycle

  Incorrect

  Policies apply immediately.

The enterprise policy for Dependabot alerts lets you allow or disallow members with admin permissions for repositories to enable or disable Dependabot alerts. It only affects repository administrators: organization owners and security managers can always enable security features, regardless of the policy.

• AStop watching the repository for security alerts

  Incorrect

  That silences every alert in the repository, including those that matter.

• BAn auto-triage rule that auto-dismisses them

  Correct

  Rules are applied before notifications are sent, so alerts dismissed when they're created don't notify.

• CTurn off Dependabot alerts for the whole repository

  Incorrect

  That removes all the alerts, not just the notifications for these.

• DAdd an ignore condition for the tool in dependabot.yml

  Incorrect

  ignore controls which updates Dependabot opens pull requests for, not alerts or their notifications.

Auto-triage rules are applied before alert notifications are sent, so alerts that are auto-dismissed when they're created don't send notifications. When notifications become too many, GitHub recommends rules that auto-dismiss low-risk alerts rather than silencing the repository or turning alerts off.

• ARepository only

  Incorrect

  Organization and enterprise levels exist too.

• BNone; Dependabot alerts have no API

  Incorrect

  There is a REST API for them.

• CEnterprise only

  Incorrect

  Repository and organization levels exist too.

• DRepository, organization and enterprise

  Correct

  All three are supported.

You can list all Dependabot alerts for a repository, organization or enterprise with the REST API, filter them, and get or update a single alert. Managing Dependabot alerts with the REST API is in public preview.

• Abody

  Incorrect

  There's no such field for this.

• BresolutionNote

  Incorrect

  There's no such field for this.

• CdismissComment

  Correct

  The dismissal comment is in the dismissComment field.

• DdismissalJustification

  Incorrect

  There's no such field.

When you dismiss a Dependabot alert you can add a comment. You can retrieve or set it with the GraphQL API, which exposes it in the dismissComment field.

• ADependabot secrets

  Correct

  Dependabot uses Dependabot secrets.

• BActions secrets only

  Incorrect

  Dependabot has its own secret type.

• CEnvironment secrets

  Incorrect

  Those are for deployment environments.

• DCodespaces secrets

  Incorrect

  Those are for codespaces.

GitHub has three types of secrets: Dependabot secrets, Actions secrets and Codespaces secrets. Dependabot secrets hold the credentials Dependabot uses, for example for private registries configured at organization or repository level.