The GitHub Advanced Security certification (exam GH-500) checks that you can secure code, secrets, and dependencies on GitHub: configuring Secret Protection, supply chain security, and Code Security; triaging and fixing alerts; and rolling all of it out across an organization or enterprise with policies and automation. It's an intermediate-level exam for developers, DevOps engineers, security engineers, and administrators.

This guide covers the exam as of its July 2026 skills update, then gives you 100 original practice questions weighted like the real exam. Each one hides its answer and an explanation until you open it. Product names, defaults, and limits here were checked against GitHub's documentation in October 2026. The questions are written for practice; they aren't taken from the real exam.

The exam at a glance

  • Exam code: GH-500, for the GitHub Advanced Security certification. Level: intermediate.
  • Time: 100 minutes. If the exam isn't offered in your language, you can request 30 extra minutes.
  • Passing score: 700 or higher.
  • Delivery: proctored, scheduled through Pearson VUE from the Microsoft Learn certification page. Price depends on the country where you take it.
  • Languages: English, Spanish, Portuguese (Brazil), Korean, and Japanese.
  • Retakes: you can retake 24 hours after a first failed attempt; later retakes have longer waits.
  • Validity: 2 years. GitHub is moving its certifications to Microsoft's recertification process, and certifications that expire before that's in place are being extended by 6 months.
  • Free extras: an official practice assessment and an exam sandbox that shows the real question interface.

Microsoft doesn't publish a fixed number of questions. Check the official pages linked at the end before you book, since details change.

The six domains and their weights

Horizontal bar chart of GH-500 domain weights: security suites and ecosystem, Secret Protection, supply chain security, and security operations 15 to 20 percent each; Code Security and administration 10 to 15 percent each
Four domains share the top weight, so there's no single area to skip. The table below has the same numbers.
DomainExam weightPractice questions here
Describe GitHub security suites, features, and ecosystem15–20%18
Configure and use Secret Protection15–20%18
Configure and use supply chain security15–20%18
Configure and use Code Security10–15%13
Security operations: best practices, prioritization, and remediation15–20%18
GitHub security suites administration10–15%15

The July 2026 update rewrote every objective and renamed the domains to match GitHub's current products: Secret Protection (formerly secret scanning), supply chain security (formerly Dependabot and dependency review), and Code Security (formerly code scanning with CodeQL). One thing worth knowing: GitHub's documentation lists only two paid products, GitHub Secret Protection and GitHub Code Security. "Supply chain security" is an exam domain covering Dependabot and dependency review, not a third product you buy. New or expanded topics include security campaigns, delegated bypass and delegated dismissal, validity checks, EPSS-based prioritization, SBOM export, auto-triage rules, and security configurations for rollout at scale.

How to use these questions

Answer each question before opening its answer, and tally your misses per domain. Questions marked Choose two need both correct options. When a scenario asks for the best approach, favor the control that prevents the problem earliest and the role with the least privilege; that's usually the intended answer. If you get more than about 80% right, take the official practice assessment next.

Describe GitHub security suites, features, and ecosystem (15–20%)

Questions 1–18.

Three-column comparison: free features (dependency graph and Dependabot alerts on every plan; secret scanning, push protection, code scanning, CodeQL CLI, Copilot Autofix, and the dependency review action on public repositories), what GitHub Secret Protection adds, and what GitHub Code Security adds
What's free, what Secret Protection adds, and what Code Security adds, per GitHub Docs in October 2026.
  1. Which two paid products make up GitHub Advanced Security as of 2026?

    1. Secret Scanning Plus and Supply Chain Guard
    2. Dependabot Pro and CodeQL Enterprise
    3. GitHub Secret Protection and GitHub Code Security
    4. GitHub Shield and GitHub Audit
    Show answer

    Answer: C. GitHub sells Secret Protection and Code Security as separate products. The exam's "supply chain security" domain covers Dependabot and dependency review rather than a third product.

  2. Which GitHub plans can purchase Secret Protection or Code Security?

    1. GitHub Pro only
    2. GitHub Team or GitHub Enterprise
    3. Any personal account
    4. GitHub Free only
    Show answer

    Answer: B. You must be on a Team or Enterprise plan to buy either product.

  3. Which features are available free on public repositories? (Choose two.)

    1. Secret scanning and push protection
    2. Code scanning with CodeQL
    3. Security overview
    4. Custom secret patterns
    Show answer

    Answer: A and B. Public repositories also get the CodeQL CLI and Copilot Autofix. Security overview and custom patterns need a paid product.

  4. Which two supply chain features are included in every plan?

    1. Security campaigns and security overview
    2. Dependency review and custom auto-triage rules
    3. Dependency graph and Dependabot alerts
    4. Custom patterns and validity checks
    Show answer

    Answer: C. Dependency review on private repositories and custom auto-triage rules need Code Security.

  5. What is security overview for?

    1. Seeing how security risk and feature coverage are distributed across an organization's repositories
    2. Rotating secrets
    3. Editing CodeQL queries
    4. Publishing advisories
    Show answer

    Answer: A. It's the organization-level view for finding where alerts and gaps concentrate. It requires a paid security product.

  6. Custom secret patterns and AI-detected secrets belong to which product?

    1. Both, at no cost
    2. Code Security
    3. Neither; they're GitHub Pro features
    4. Secret Protection
    Show answer

    Answer: D. Secret Protection also includes delegated bypass, delegated alert dismissal, security campaigns, and security overview.

  7. Copilot Autofix, custom Dependabot auto-triage rules, and dependency review on private repositories belong to which product?

    1. GitHub Copilot Business
    2. Code Security
    3. Secret Protection
    4. GitHub Pro
    Show answer

    Answer: B. Code Security covers finding and fixing vulnerabilities in code and dependencies.

  8. What's the core idea of a prevention-first security strategy?

    1. Stop problems at the source, for example blocking a secret at push time, rather than relying only on later gates
    2. Scan production once a year
    3. Only review code after release
    4. Disable all alerts
    Show answer

    Answer: A. Gates such as merge rules still matter, but each issue prevented early is one fewer alert to triage.

  9. What are security campaigns for?

    1. Marketing security features
    2. Buying licenses
    3. Grouping related alerts and sharing them with developers so teams remediate security debt together
    4. Running CodeQL faster
    Show answer

    Answer: C. Campaigns can cover code scanning alerts and exposed secrets, with assigned owners and remediation targets.

  10. In a shift-left SDLC on GitHub, which control acts earliest?

    1. Security overview
    2. Push protection
    3. Dependabot alerts on the default branch
    4. Security campaigns
    Show answer

    Answer: B. Push protection blocks secrets before they reach the repository. Dependency review and code scanning act on pull requests; alerts and campaigns deal with what's already merged.

  11. What does Dependabot use to decide that a dependency is vulnerable?

    1. Only npm audit output
    2. Random sampling
    3. Copilot suggestions
    4. The repository's dependency graph matched against advisories in the GitHub Advisory Database
    Show answer

    Answer: D. Alerts are created when a new advisory is added or when the dependency graph changes. Only advisories reviewed by GitHub trigger alerts.

  12. How does secret scanning differ from code scanning?

    1. Secret scanning only runs on pull requests
    2. They're the same tool
    3. Secret scanning looks for credentials such as tokens and keys; code scanning analyzes code for vulnerabilities and errors
    4. Code scanning finds leaked passwords
    Show answer

    Answer: C. That split is why they're sold as different products: Secret Protection and Code Security.

  13. What's a good practice when dismissing a code scanning alert?

    1. Choose the most accurate dismissal reason and add a comment explaining why, for auditing
    2. Delete the repository
    3. Dismiss it only on one branch
    4. Dismiss without a reason to save time
    Show answer

    Answer: A. The reason can affect future analysis, and the comment is kept in the alert's timeline.

  14. Who is typically responsible for what in alert remediation?

    1. Alerts fix themselves
    2. Admins write every fix
    3. Only GitHub Support fixes alerts
    4. Developers fix code, security teams triage and prioritize, and admins configure features and policies
    Show answer

    Answer: D. Shared ownership is a core theme of the exam.

  15. What does delegated bypass mean for push protection?

    1. Bypass is disabled completely
    2. Only designated reviewers or roles can bypass, and they review and approve other contributors' bypass requests
    3. GitHub Support approves each bypass
    4. Anyone can bypass without a reason
    Show answer

    Answer: B. It turns bypassing into a reviewed request instead of a self-service choice.

  16. Why does supply chain security look at lock files, not just manifests?

    1. Lock files record exact versions, including transitive dependencies your project pulls in indirectly
    2. Lock files contain secrets
    3. Lock files are smaller
    4. Manifests are never parsed
    Show answer

    Answer: A. Dependency review shows changes to indirect dependencies from lock files too.

  17. When delegated alert dismissal is turned on, who can approve a dismissal request?

    1. Only the person who opened the alert
    2. GitHub Support
    3. Organization owners and security managers, or members of a custom role granted that permission
    4. Any collaborator
    Show answer

    Answer: C. People with write access must request dismissal instead of dismissing directly.

  18. Which statement about repository visibility and security features is correct?

    1. Private repositories get every feature free
    2. Public repositories get several detection features free; private and internal repositories need the paid products for them
    3. Security features only work on internal repositories
    4. Visibility doesn't affect availability
    Show answer

    Answer: B. That difference is a favorite exam topic, so learn which features are free on public repositories.

Configure and use Secret Protection (15–20%)

Questions 19–36.

  1. Where can push protection block a secret? (Choose two.)

    1. Pushes from the command line
    2. Files on a developer's laptop that are never pushed
    3. Messages in Slack
    4. Commits made in the GitHub web UI and file uploads
    Show answer

    Answer: A and D. It also covers REST API requests and, on public repositories, GitHub MCP server interactions.

  2. A developer's push is blocked by push protection. Which bypass reasons can they choose?

    1. "Urgent" or "Approved by manager"
    2. Bypass isn't possible
    3. "It's used in tests", "It's a false positive", or "I'll fix it later"
    4. Any free-text reason
    Show answer

    Answer: C. If delegated bypass is enabled, they submit a request instead of bypassing directly.

  3. A developer bypasses push protection choosing "I'll fix it later". What happens?

    1. An open secret scanning alert is created, the event is logged, and owners and security managers are notified
    2. The secret is deleted automatically
    3. The repository is locked
    4. Nothing is recorded
    Show answer

    Answer: A. Bypasses for "used in tests" or "false positive" create closed alerts instead. Every bypass is audited.

  4. Is push protection for users on by default?

    1. No, never
    2. Only for organization owners
    3. Only on GitHub Enterprise Server
    4. Yes, for your personal account it's on by default and stops you from pushing supported secrets to public repositories on GitHub.com
    Show answer

    Answer: D. It's separate from repository-level push protection, which admins configure.

  5. What does a secret's validity status of "active" mean?

    1. The secret is in a public repository
    2. GitHub checked with the provider and the credential still works
    3. The pattern is enabled
    4. The alert is open
    Show answer

    Answer: B. Other statuses are "inactive" and "possibly active" (unknown), used when the token can't be verified or isn't supported.

  6. Which tokens get validity checks by default?

    1. GitHub tokens; partner patterns require validity checks to be enabled
    2. All third-party tokens
    3. None
    4. Only AWS keys
    Show answer

    Answer: A. You can also run an on-demand check with the Verify secret button.

  7. A secret scanning alert shows an exposed cloud key that's still active. What should you do first?

    1. Delete the commit and do nothing else
    2. Close the alert as "won't fix"
    3. Rotate or revoke the credential with the provider, then remove it and close the alert
    4. Make the repository private
    Show answer

    Answer: C. Once exposed, a secret must be treated as compromised. Removing it from code doesn't make it safe.

  8. You remove a leaked token from the repository. What happens to its secret scanning alert?

    1. It turns into a Dependabot alert
    2. Nothing; you must close the alert manually
    3. It's deleted
    4. It closes automatically
    Show answer

    Answer: B. Secret scanning doesn't automatically close alerts when the token is removed.

  9. Which are valid reasons for closing a secret scanning alert? (Choose two.)

    1. Too expensive
    2. Low priority
    3. Revoked
    4. Used in tests
    Show answer

    Answer: C and D. The other reasons are false positive and won't fix.

  10. How do you stop secret scanning from alerting on a docs/ folder full of sample keys?

    1. Delete push protection
    2. Add the folder to .gitignore
    3. Add paths-ignore entries to .github/secret_scanning.yml
    4. Rename the folder
    Show answer

    Answer: C. Alerts in excluded paths are closed as "ignored by configuration", and those paths are also excluded from push protection.

  11. What are the limits of paths-ignore in secret_scanning.yml?

    1. Only the first 1,000 entries are used, and a file larger than 1 MB is ignored entirely
    2. Ten entries maximum
    3. Only one directory
    4. No limits
    Show answer

    Answer: A. Keep exclusions tight. Every excluded path is a place leaks can hide.

  12. Your company has an internal API key format that GitHub doesn't recognize. What should you use?

    1. A CodeQL query
    2. A .gitignore rule
    3. A Dependabot rule
    4. A custom secret pattern, defined with a regular expression
    Show answer

    Answer: D. Custom patterns can be defined at the repository, organization, or enterprise level, with Secret Protection.

  13. What do AI-detected secrets add?

    1. Faster CodeQL scans
    2. Detection of unstructured secrets, such as passwords, that don't follow a provider's fixed token format
    3. Automatic secret rotation
    4. License checks
    Show answer

    Answer: B. Provider patterns match known token formats; AI detection catches the more generic secrets they miss.

  14. Can a ruleset stop a pull request from merging while it has an open secret scanning alert?

    1. Yes, a branch ruleset can require secret scanning alerts to be resolved before merging
    2. Only with a GitHub App
    3. No, rulesets only cover code scanning
    4. Only on public repositories
    Show answer

    Answer: A. After the secret is fixed and the alert closed, merging is unblocked once a scan of the pull request's head commit completes.

  15. An alert shows a secret as "inactive". Is the job done?

    1. Ignore inactive alerts entirely
    2. Yes, close it immediately with no review
    3. Not yet: confirm the credential wasn't used without authorization while it was exposed
    4. Re-activate the secret
    Show answer

    Answer: C. An inactive secret can't be used now, but it may have been used before it was revoked.

  16. Who is notified when someone bypasses push protection?

    1. Every GitHub user
    2. Owners, security managers, and repository administrators watching the repository
    3. No one
    4. Only the person who bypassed
    Show answer

    Answer: B. Bypasses also appear in the audit log.

  17. What does Secret Protection add for private repositories?

    1. Dependency review
    2. Code scanning
    3. Nothing
    4. Secret scanning and push protection on private repositories, plus custom patterns, AI-detected secrets, delegated bypass, and campaigns
    Show answer

    Answer: D. On public repositories, secret scanning and push protection are already free.

  18. At which levels can Secret Protection be enabled?

    1. Only through the REST API
    2. Only per user
    3. Repository and organization levels, including through security configurations, and at enterprise level
    4. Only enterprise
    Show answer

    Answer: C. Security configurations make enabling it consistent across many repositories.

Configure and use supply chain security (15–20%)

Questions 37–54.

  1. Which two events create new Dependabot alerts?

    1. A new advisory is added to the GitHub Advisory Database, or the dependency graph changes
    2. A developer opens an issue, or a release is published
    3. Code scanning runs, or a secret leaks
    4. A workflow fails, or a branch is deleted
    Show answer

    Answer: A. Only advisories reviewed by GitHub trigger alerts.

  2. Where does the dependency graph get its data?

    1. From the Marketplace
    2. From commit messages
    3. From runtime telemetry
    4. From the repository's manifest and lock files
    Show answer

    Answer: D. It's the foundation for Dependabot alerts, dependency review, and SBOM export.

  3. In which format does GitHub export a repository's SBOM?

    1. CSV
    2. SPDX
    3. PDF
    4. SARIF
    Show answer

    Answer: B. Export it from the Dependencies tab with Export SBOM, or through the REST API. SARIF is the format for code scanning results.

  4. What does an exported SBOM not include?

    1. Dependents, meaning other projects that rely on yours
    2. Licenses
    3. Dependency versions
    4. Package identifiers
    Show answer

    Answer: A. An SBOM inventories what your project uses, not who uses your project.

  5. What's the difference between Dependabot security updates and version updates?

    1. Security updates require a paid license on public repositories
    2. They're identical
    3. Security updates open pull requests to fix vulnerable dependencies; version updates keep dependencies current on a schedule you set
    4. Version updates only work for Docker
    Show answer

    Answer: C. Version updates are configured in .github/dependabot.yml.

  6. How can you reduce the number of separate Dependabot pull requests?

    1. Pin every dependency forever
    2. Use groups in dependabot.yml to combine related updates into one pull request
    3. Disable Dependabot
    4. Raise the PR limit to 1,000
    Show answer

    Answer: B. Grouping cuts review noise without stopping updates.

  7. What does the GitHub preset rule "Dismiss low impact issues for development-scoped dependencies" do, and where is it on by default?

    1. Deletes dev dependencies
    2. Blocks dev dependencies
    3. Dismisses all alerts everywhere
    4. Auto-dismisses alerts that rarely matter for dev-only dependencies; it's on by default for public repositories and opt-in for private ones
    Show answer

    Answer: D. Preset rules are curated by GitHub and available for all repositories.

  8. The "Dismiss package malware alerts" preset is turned on. What's the risk?

    1. It disables Dependabot
    2. It slows down CI
    3. If a contributor adds a truly malicious package, its alert is auto-dismissed too
    4. None
    Show answer

    Answer: C. It's meant for internal packages that share a name with a malicious public one, and it's off by default.

  9. Why do auto-triage rules reduce notification noise?

    1. They run before notifications are sent, so alerts auto-dismissed on creation don't notify anyone
    2. They delete alerts
    3. They only run weekly
    4. They mute email entirely
    Show answer

    Answer: A. Custom rules can target severity, package name, CWE, and more, with Code Security.

  10. What does dependency review show on a pull request?

    1. Only file renames
    2. Secret scanning results
    3. Code coverage
    4. Added, removed, and updated dependencies, including from lock files, with known vulnerabilities, licenses, and age
    Show answer

    Answer: D. It lets reviewers catch a risky dependency before it's merged.

  11. In the dependency review action, what does fail-on-severity: high do?

    1. Ignores high-severity issues
    2. Fails the check when a pull request introduces a dependency with a vulnerability of high severity or worse
    3. Only logs a warning
    4. Sets the alert email priority
    Show answer

    Answer: B. Use it with a required check or ruleset so a failing review blocks the merge.

  12. You configure the dependency review action with both allow-licenses and deny-licenses. What's the problem?

    1. You can only include one of the two options
    2. Nothing
    3. Licenses can't be checked
    4. Both are deprecated
    Show answer

    Answer: A. Pick an allow list or a deny list, not both.

  13. What does fail-on-scopes let you control in the dependency review action?

    1. Which users can merge
    2. Which regions run the check
    3. Which dependency scopes, such as runtime or development, cause failures
    4. Which branches run the action
    Show answer

    Answer: C. For example, you might fail only on runtime dependencies.

  14. Several repositories should share one dependency review policy. What's the cleanest approach?

    1. Use a gist
    2. Store the policy in a configuration file and point each workflow at it with config-file
    3. Email the policy
    4. Copy the inputs into every workflow
    Show answer

    Answer: B. The config-file input can reference a file in another repository.

  15. Where is the dependency review action available?

    1. Only on private repositories
    2. Only for npm projects
    3. Only on GitHub Enterprise Server
    4. In all public repositories, and in private repositories with Code Security (or Advanced Security) enabled
    Show answer

    Answer: D. That makes it one of the free shift-left controls for open source.

  16. What does an EPSS score estimate for a vulnerability?

    1. The cost to fix it
    2. Its CVSS severity
    3. The probability that it will be exploited in the wild in the coming 30 days
    4. The number of affected repositories
    Show answer

    Answer: C. EPSS adds exploitation likelihood to severity, which helps you prioritize which alerts to fix first.

  17. Which file configures Dependabot version updates?

    1. .github/dependabot.yml
    2. .dependabot/config.yaml
    3. .github/workflows/dependabot.yml
    4. dependabot.json in the repository root
    Show answer

    Answer: A. It lists package ecosystems, directories, schedules, and options such as groups.

  18. Why can't a reviewer rely on the manifest diff alone when a pull request updates one dependency?

    1. Manifests are unreliable
    2. GitHub hides manifests
    3. Lock files don't change
    4. The update can also change many transitive dependencies, which only show in the lock file
    Show answer

    Answer: D. Dependency review covers indirect dependency changes in lock files for exactly this reason.

Configure and use Code Security (10–15%)

Questions 55–67.

  1. For a team new to code scanning, which setup does GitHub recommend starting with?

    1. No setup; scanning is automatic everywhere
    2. Default setup, moving to advanced setup only when you need more control
    3. Advanced setup with custom queries
    4. SARIF uploads only
    Show answer

    Answer: B. Advanced setup takes more effort to configure and maintain.

  2. Which three query suites are built in to CodeQL?

    1. default, security-extended, and security-and-quality
    2. low, medium, and high
    3. owasp, cwe, and cve
    4. fast, deep, and full
    Show answer

    Answer: A. default and security-extended are available with default setup for every supported language.

  3. What do you gain and give up with the security-extended suite instead of default?

    1. It disables security queries
    2. Fewer queries and faster scans
    3. More queries, at slightly lower precision, so potentially more false positives
    4. Nothing changes
    Show answer

    Answer: C. default is tuned for the most relevant issues with minimal false positives.

  4. Your organization uses a third-party static analysis tool. How do its findings appear as code scanning alerts?

    1. Convert them to CodeQL queries
    2. Generate a SARIF file and upload it to GitHub
    3. They can't
    4. Paste them into issues
    Show answer

    Answer: B. GitHub parses the SARIF results and shows them alongside CodeQL alerts.

  5. Which methods can upload a SARIF file? (Choose two.)

    1. A GitHub Actions workflow, for example with upload-sarif
    2. Attaching it to an issue
    3. The code scanning REST API or the CodeQL CLI
    4. Email to GitHub Support
    Show answer

    Answer: A and C. Pick the method that matches where your SARIF file is generated.

  6. Which SARIF version does GitHub code scanning support?

    1. Any JSON file
    2. SARIF 1.0
    3. SARIF 2.1.0
    4. SARIF 3.0
    Show answer

    Answer: C. GitHub supports a subset of SARIF 2.1.0.

  7. Your builds run in Jenkins, not GitHub Actions. How do you run CodeQL?

    1. Run the CodeQL CLI in your CI system and upload the results
    2. You can't
    3. Use Dependabot
    4. Only use default setup
    Show answer

    Answer: A. Code scanning works with GitHub Actions or with external CI systems.

  8. In an advanced setup workflow, how do you analyze several languages efficiently?

    1. Analyze only the first language
    2. One job per repository
    3. Run CodeQL twice in one step
    4. A matrix over the languages, so each one is analyzed in its own job
    Show answer

    Answer: D. Matrix builds are explicitly part of the exam's skills list.

  9. What happens when you dismiss a code scanning alert?

    1. It's deleted permanently
    2. It's dismissed in all branches and moves to the closed list, from which it can be reopened
    3. It's dismissed only on the current branch
    4. The query is removed from CodeQL
    Show answer

    Answer: B. Add a dismissal comment to keep a record of the reasoning.

  10. Which are valid code scanning dismissal reasons? (Choose two.)

    1. Not my code
    2. Used in tests
    3. False positive
    4. Too busy
    Show answer

    Answer: B and C. The third reason is won't fix. The reason you choose can affect whether a query keeps being used in future analysis.

  11. What does Copilot Autofix do for code scanning?

    1. Disables CodeQL
    2. Dismisses alerts automatically
    3. Suggests fixes for code scanning alerts, which developers review before applying
    4. Rewrites the whole repository
    Show answer

    Answer: C. It's free on public repositories and part of Code Security for private ones.

  12. A CodeQL alert shows data flow steps. What do they tell you?

    1. How fast the code runs
    2. How untrusted data travels from a source, such as user input, to a dangerous sink
    3. Which tests cover the code
    4. Which developer wrote the code
    Show answer

    Answer: B. Following the path shows where to add validation or sanitization.

  13. When should code scanning typically run?

    1. Only manually
    2. Only on tags
    3. Only once, at repository creation
    4. On pushes and pull requests, plus on a schedule to catch issues from newly added queries
    Show answer

    Answer: D. Scheduled scans catch problems found by updated queries even when the code hasn't changed.

Security operations: best practices, prioritization, and remediation (15–20%)

Questions 68–85.

Shift-left timeline: push protection at push time, dependency review and code scanning on the pull request, then alerts, security overview, and campaigns after merge
Each control placed as early as it can act. Many questions here ask which one fits where.
  1. What's the difference between a CVE and a CWE?

    1. They're the same
    2. A CWE is only for Windows
    3. A CVE identifies a specific publicly known vulnerability; a CWE identifies a category of software weakness
    4. A CVE is a fix
    Show answer

    Answer: C. Alerts often show both: the specific issue (CVE) and the kind of mistake behind it (CWE).

  2. What is a GHSA ID?

    1. The identifier for an advisory in the GitHub Advisory Database
    2. A CodeQL query ID
    3. A repository ID
    4. A GitHub Actions secret
    Show answer

    Answer: A. GitHub advisories can also reference CVE IDs.

  3. Your public project has a vulnerability. What's the repository security advisory workflow?

    1. Delete the repository
    2. Email all users first
    3. Open a public issue describing the exploit
    4. Create a draft advisory, fix it privately in a temporary private fork, then publish the advisory once a patch is released
    Show answer

    Answer: D. Private collaboration avoids exposing the vulnerability before a fix exists.

  4. What does private vulnerability reporting allow?

    1. Anonymous code commits
    2. Security researchers to report a vulnerability privately to the maintainers through the repository
    3. Hiding all alerts
    4. Private Dependabot updates
    Show answer

    Answer: B. It replaces ad-hoc emails and public issues with a private channel.

  5. A code scanning ruleset blocks a pull request. Which are valid reasons? (Choose two.)

    1. The PR description is too short
    2. A required tool's analysis is still in progress
    3. The author isn't an admin
    4. A required tool found an alert at or above the severity defined in the ruleset
    Show answer

    Answer: B and D. A third reason: a required tool isn't configured for the repository.

  6. Code scanning merge protection with rulesets does not apply to which of these?

    1. Pull requests with new commits
    2. Pull requests to protected branches
    3. Merge queue groups, and Dependabot pull requests analyzed by default setup
    4. Pull requests from forks
    Show answer

    Answer: C. Also, every line identified by an alert must exist in the pull request diff.

  7. At which levels can you configure code scanning merge protection with rulesets?

    1. Only organization level, on every plan
    2. Repository level, and organization level on Enterprise plans
    3. Only enterprise
    4. Only through the CLI
    Show answer

    Answer: B. Rulesets on public repositories are available on Free plans too.

  8. In a security campaign, who can alerts be assigned to?

    1. Only organization owners
    2. Anyone on the internet
    3. Only GitHub Support
    4. Users with write access, or Copilot cloud agent to generate fix pull requests
    Show answer

    Answer: D. Assignment makes ownership clear and lets automation draft fixes.

  9. You need to triage thousands of alerts across 300 repositories. What's the best starting point?

    1. Dismiss everything older than a year
    2. Open each repository one by one
    3. Filter alerts in security overview, then group the priority ones into security campaigns
    4. Disable scanning temporarily
    Show answer

    Answer: C. Overview finds the hotspots; campaigns organize the fix-up work.

  10. With delegated alert dismissal enabled, what must a developer with write access do to dismiss an alert?

    1. Request dismissal; an owner, security manager, or custom-role member approves or denies it
    2. Delete the alert
    3. Dismiss it directly
    4. Ask GitHub Support
    Show answer

    Answer: A. Reviewers are notified by email, and requesters are told the outcome.

  11. A team lead isn't an owner or security manager but should review dismissal requests. What's the right approach?

    1. Make them an organization owner
    2. Share an owner's password
    3. It's impossible
    4. Give them a custom role with the permissions to review dismissal requests and dismiss alerts
    Show answer

    Answer: D. Custom roles keep this least-privilege instead of granting full ownership.

  12. Why record a comment when dismissing an alert?

    1. Comments are required by Git
    2. The comment is kept in the alert timeline as justification for audits and reporting
    3. It speeds up CodeQL
    4. It notifies the CVE database
    Show answer

    Answer: B. You can also read or set it through the REST API (dismissed_comment).

  13. How can you tailor CodeQL detection to your organization's risk profile?

    1. Choose or customize query suites, and add query packs for your languages and frameworks
    2. Only use third-party tools
    3. Disable half the languages
    4. You can't
    Show answer

    Answer: A. Organization owners and security managers can also recommend a query suite for default setup.

  14. Who can recommend a CodeQL query suite for default setup across an organization?

    1. Repository readers
    2. Only GitHub
    3. Organization owners and security managers
    4. Any developer
    Show answer

    Answer: C. That keeps scanning depth consistent across repositories.

  15. Which alerts should you usually fix first?

    1. Whichever is oldest
    2. High-severity issues that are likely to be exploited, or exposed and still valid, especially in public-facing code
    3. Low-severity code style issues
    4. Alerts in archived repositories
    Show answer

    Answer: B. Combine severity, exploitability (for example EPSS), and exposure, such as a secret's validity status.

  16. What's the earliest preventive control for leaked credentials?

    1. SBOM export
    2. A security campaign
    3. A weekly report
    4. Push protection
    Show answer

    Answer: D. Prevent the leak, and there's nothing to rotate or remediate later.

  17. Which dependency control works before a vulnerable package is merged?

    1. Dependabot alerts on the default branch
    2. SBOM export
    3. Dependency review on the pull request
    4. Security overview
    Show answer

    Answer: C. Dependabot alerts cover what's already in the default branch.

  18. What's the main benefit of applying policies through rulesets instead of relying on people to remember checks?

    1. Rules are enforced consistently across repositories, with explicit and audited bypass permissions
    2. Rulesets replace code review
    3. Rulesets run faster
    4. Nothing
    Show answer

    Answer: A. Governance through rulesets and policies scales where reminders don't.

GitHub security suites administration (10–15%)

Questions 86–100.

  1. What is a security configuration?

    1. A YAML file in each repository
    2. A CodeQL query
    3. A firewall rule
    4. A collection of enablement settings for GitHub's security features that you apply to repositories across an organization or enterprise
    Show answer

    Answer: D. Applying one puts each repository into a managed relationship with that configuration.

  2. What does GitHub offer to help you secure an organization quickly without designing settings yourself?

    1. A random configuration
    2. The GitHub-recommended security configuration
    3. A paid consulting service only
    4. Nothing
    Show answer

    Answer: B. You can also create custom security configurations.

  3. What's the difference between security configurations and global settings?

    1. Security configurations control repository-level features; global settings control security features at the organization level
    2. Configurations only apply to forks
    3. Global settings only apply to one repository
    4. They're the same
    Show answer

    Answer: A. GitHub recommends using both together.

  4. What does enforcing a security configuration prevent?

    1. Dependabot updates
    2. Pushes to main
    3. Repository admins from overriding the configuration's settings
    4. Code scanning
    Show answer

    Answer: C. On an unenforced configuration, a repository admin can override a setting, which changes the repository's configuration status.

  5. Which permissions does the security manager role grant? (Choose two.)

    1. Billing management
    2. Deleting the organization
    3. The ability to configure security features at organization and repository level
    4. Read access to all repositories and write access to all security alerts in the organization
    Show answer

    Answer: C and D. It's designed to grant only what's needed to manage security features.

  6. Who can assign the security manager role?

    1. Any member
    2. Repository admins
    3. GitHub Support only
    4. Organization owners
    Show answer

    Answer: D. The role can be given to members or to whole teams.

  7. On GitHub Enterprise Server, what must an administrator do before users can see their dependencies?

    1. Install Copilot
    2. Nothing; it's always on
    3. Enable the dependency graph for the enterprise
    4. Upload an SBOM
    Show answer

    Answer: C. Dependabot alerts and updates are enabled separately, and vulnerability data from the GitHub Advisory Database is synced to the server.

  8. How do GitHub Enterprise Server instances get vulnerability data for Dependabot alerts?

    1. From the GitHub Advisory Database, synced to the server (with GitHub Connect)
    2. They scan the internet
    3. From npm audit only
    4. They don't support Dependabot
    Show answer

    Answer: A. Administrators can view the data and trigger a manual sync.

  9. Your security team wants new repositories to get the right security features automatically. What do you use?

    1. A wiki page
    2. A GitHub App only
    3. A weekly reminder email
    4. A security configuration set as the default for newly created repositories
    Show answer

    Answer: D. Defaults close coverage gaps before anyone has to remember to enable features.

  10. A security configuration that enables default setup didn't take effect on one repository. What's a likely cause?

    1. The repository is public
    2. The repository already uses advanced setup for code scanning
    3. Default setup is deprecated
    4. The repository has too many stars
    Show answer

    Answer: B. Repositories using advanced setup keep it, so resolve that before expecting the configuration to apply.

  11. Which tool is best for turning on security features across hundreds of repositories through automation?

    1. The REST APIs for security configurations and alerts, scripted or run from a workflow
    2. Email requests
    3. Editing each repository's README
    4. Clicking through each repository
    Show answer

    Answer: A. The exam expects you to know that large-scale enablement and governance are API-driven.

  12. How do you give a group of people the ability to review push protection bypass requests without making them owners?

    1. Share an owner account
    2. It's not possible
    3. Configure delegated bypass with them as reviewers, using a team or custom role
    4. Make them outside collaborators
    Show answer

    Answer: C. Delegated bypass decides who can bypass and who approves requests.

  13. An enterprise wants the same policies everywhere, with tightly controlled exceptions. What fits best?

    1. Per-repository manual settings
    2. Enterprise and organization rulesets and policies with explicit bypass permissions
    3. Disabling all security features
    4. One shared admin account
    Show answer

    Answer: B. Define enforcement boundaries centrally, and make every exception explicit and audited.

  14. Which role is best for a developer who should fix alerts in their team's repositories but not change security settings?

    1. Organization owner
    2. Enterprise owner
    3. Security manager
    4. Write access to the repositories, so they can push fixes and work on code scanning alerts
    Show answer

    Answer: D. Keep configuration rights with owners and security managers; give developers what they need to remediate.

  15. Before rolling security features out across an entire enterprise, what's a recommended step?

    1. Wait for every team to opt in
    2. Disable features on public repositories first
    3. Pilot with a small set of representative repositories, learn, then scale out
    4. Enable everything everywhere at once with no testing
    Show answer

    Answer: C. Piloting finds noisy settings and workflow issues before they hit everyone.

Final tips for exam day

  • Know what's free and what each product adds. Public repositories get secret scanning, push protection, code scanning, Copilot Autofix, and the dependency review action; every plan gets the dependency graph and Dependabot alerts. Security overview, campaigns, custom patterns, and custom auto-triage rules need a paid product.
  • Memorize the lists: push protection's three bypass reasons, secret alert close reasons (revoked, false positive, used in tests, won't fix), code scanning dismissal reasons (false positive, used in tests, won't fix), validity statuses, and the three built-in CodeQL query suites.
  • Know the exact files and limits: .github/secret_scanning.yml with paths-ignore (first 1,000 entries, 1 MB limit), .github/dependabot.yml with groups, SARIF 2.1.0, and SBOMs in SPDX.
  • Know who does what: security managers read all repositories and manage all alerts; owners and security managers approve delegated dismissals; delegated bypass reviewers approve push protection exceptions.
  • Prefer prevention: push protection, dependency review, and code scanning on pull requests come before alerts and campaigns. Exam scenarios reward the earliest effective control.

Official resources

Preparing for more GitHub certifications? See the GitHub Foundations (GH-900), GitHub Actions (GH-200), and GitHub Copilot (GH-300) practice guides.