GitHub Advanced Security Practice Exam

What the GitHub Advanced Security exam covers

• GitHub Security Suites, Features, and Ecosystem78 questions
• Secret Protection128 questions
• Supply Chain Security118 questions
• Code Security218 questions
• Security Operations and Remediation121 questions
• GitHub Security Suites Administration90 questions

Free GitHub Advanced Security sample questions

A sample of 10 questions with answers and explanations. Sign up free to practice all 753.

1. Question 1GitHub Security Suites, Features, and Ecosystem

   While browsing the GitHub Advisory Database, a developer finds an entry describing a package that was found to contain intentionally malicious code rather than an accidental coding flaw. Which advisory category does this describe?

   • AAn unreviewed advisory still awaiting curation before it can be trusted
   • BA malware advisory, typically without a CVSS score, recommending removalCorrect
   • CA withdrawn advisory that GitHub has determined was reported in error
   • DA reviewed vulnerability advisory with a CVSS score and a suggested patch
   ✓ Correct answer: B

   Because there is no legitimate patched version for intentionally malicious code, malware advisories guide users to remove the affected package entirely rather than upgrade. They still receive a GHSA identifier and can trigger Dependabot alerts. GitHub's curation team reviews these reports before they are published to the database.

   Why the other options are wrong

   • AUnreviewed status describes a curation stage, not the malware category itself.
   • CA withdrawn advisory has been retracted, whereas this scenario describes an actively listed entry.
   • DA standard vulnerability advisory assumes an accidental flaw with a fix version, which does not match intentionally malicious code.
2. Question 2Secret Protection

   At Ridgeline Insurance, push protection flags a secret introduced three commits back in a local branch that has never been pushed successfully. The tip commit does not contain the secret. What should the developer do to remove it?

   • AInteractively rebase to edit that earlier commit and remove the secretCorrect
   • BCherry pick only the later commits onto a brand new working branch instead
   • CRun a soft reset to the commit before it, then push that branch again
   • DAmend only the tip commit, since that is the one actually being pushed
   ✓ Correct answer: A

   An interactive rebase lets the developer stop at the specific commit that introduced the secret, remove it there, and continue the rebase so the rewritten history no longer contains it. Amending only the tip commit would leave the secret intact in the earlier commit's snapshot.

   Why the other options are wrong

   • BCherry picking only the later commits still leaves the original commit containing the secret behind in the branch's history.
   • CA soft reset to the prior commit undoes more than intended and does not by itself remove the secret from history.
   • DAmending the tip commit only rewrites the newest commit, leaving the secret in the earlier commit where it was actually introduced.
3. Question 3Secret ProtectionSelect all that apply

   An engineer at Rangeley Systems bypasses a push protection block using the reason that keeps the resulting alert open. Which three parties are notified as a result? (Choose three.)

   • AOrganization owners and security managers who oversee the repositoryCorrect
   • BAdministrators of the repository where the push occurredCorrect
   • CExternal auditors registered with a regulatory body
   • DThe author of the commit that contained the secretCorrect
   • EEvery collaborator who has ever forked the repository
   ✓ Correct answer: A, B, D

   This notification chain is designed to make sure the people responsible for the code and the people responsible for security oversight both know a real secret was allowed through and remains tracked as an open alert. It does not extend to every historical fork owner or to outside regulatory bodies.

   Why the other options are wrong

   • CExternal regulatory auditors are not automatically notified by GitHub when a bypass occurs.
   • EForking a repository at some point in the past does not put someone on the notification list for a later bypass event.
4. Question 4Supply Chain SecuritySelect all that apply

   A workflow uses the pull_request trigger and includes a deployment step referencing a repository secret named DEPLOY_TOKEN. The permissions block in the workflow requests contents write access. When the triggering pull request was opened by Dependabot, which TWO behaviors occur by default? (Choose two.)

   • AThe workflow automatically switches its trigger to pull_request_target instead
   • BGITHUB_TOKEN is granted read-only access despite the requested permissionsCorrect
   • CThe workflow is skipped entirely and does not start at all
   • DSecrets beyond GITHUB_TOKEN, such as DEPLOY_TOKEN, are withheld from this runCorrect
   • EDependabot is granted permission to merge the pull request on its own
   ✓ Correct answer: B, D

   GitHub treats pull requests from Dependabot similarly to fork pull requests for token safety, so the generated token is downgraded to read-only and secrets like DEPLOY_TOKEN are not passed into the run. The workflow still executes under these restrictions, it does not skip, change its trigger, or grant Dependabot merge rights.

   Why the other options are wrong

   • AThe trigger type in the workflow file does not change automatically based on who opened the pull request.
   • CThe workflow still runs, just with restricted permissions and without the extra secret, it is not skipped entirely.
   • EDependabot is not granted any merge permissions as a result of these token restrictions.
5. Question 5Supply Chain Security

   The security team at Northwind Traders wants Dependabot to automatically open a pull request the moment a new vulnerability is disclosed for one of their npm packages. Which combination of settings must be active on the repository for this automatic security update to be generated?

   • ABranch protection rules requiring signed, verified commits must be enforced specifically on the default branch
   • BDependabot version updates must be scheduled to run daily for the npm ecosystem
   • CThe dependabot.yml file must list every npm dependency under the allow key
   • DBoth the dependency graph and Dependabot security updates must be enabledCorrect
   ✓ Correct answer: D

   The dependency graph builds the inventory of dependencies actually in use, and the Dependabot security updates setting authorizes Dependabot to open pull requests when an advisory matches something in that inventory. Neither a dependabot.yml file nor a version update schedule is required for this baseline behavior.

   Why the other options are wrong

   • ASigned commit enforcement is a branch protection concern unrelated to whether Dependabot can detect or fix vulnerabilities.
   • BA version update schedule only controls how often Dependabot checks for newer releases, it has no bearing on when a security fix is opened.
   • CThe allow key is an optional filter for version updates and does not need to list dependencies for security alerts to be detected.
6. Question 6Code SecuritySelect all that apply

   A DevOps engineer is selecting runners for a new code scanning workflow across several repositories. Which two factors should influence the choice? (Choose two)

   • AThe color scheme configured for the repository's public profile
   • BWhether the analyzed code or dependencies require a private networkCorrect
   • CThe number of contributors currently assigned to the repository
   • DThe number of issues currently open in the repository's tracker
   • EThe compute and memory demands of building the analyzed codebaseCorrect
   ✓ Correct answer: B, E

   A heavier or more complex build benefits from a runner sized to match its compute and memory demands, while code or dependencies restricted to an internal network call for a self-hosted runner placed inside that network. Factors such as contributor count, cosmetic profile settings, and open issue counts have no bearing on runner capability or placement. Focusing on actual technical demands leads to a more appropriate runner choice.

   Why the other options are wrong

   • AProfile color scheme is cosmetic and unrelated to runner selection.
   • CContributor count does not determine runner sizing or network placement needs.
   • DOpen issue count reflects project activity, not the technical demands driving runner choice.
7. Question 7Code Security

   An internal engineering dashboard ingests CodeQL scan output as flat rows for a custom reporting tool, while a separate process still needs to push standard alerts into GitHub's code scanning UI. Why can't the team simply reuse the dashboard's export file for both purposes?

   • AThe dashboard's file is already SARIF, but GitHub requires it to be compressed before any upload
   • BThe dashboard uses CSV output from database analyze, but code scanning uploads only accept SARIFCorrect
   • CThe dashboard's export lacks a codeql-database.yml file, which upload-results always requires too
   • DThe dashboard's export is a query pack manifest and cannot be uploaded under any command at all
   ✓ Correct answer: B

   database analyze can produce different output formats depending on the consumer, and a CSV export suited to a custom internal dashboard is not the format the code scanning upload accepts. To feed alerts into GitHub, the same scan needs to also be run, or reformatted, with the sarif-latest format so the upload-results step receives a proper SARIF file. There is no compression requirement, no dependency on a codeql-database.yml file at upload time, and the dashboard export is scan output rather than a pack manifest.

   Why the other options are wrong

   • AThe scenario describes a CSV export, not an already SARIF file needing compression; compression is not the actual requirement anyway.
   • CUploading SARIF results does not require a codeql-database.yml file to accompany it.
   • DThe dashboard's export is scan result data, not a query pack manifest, so this is not the actual reason it can't be reused.
8. Question 8Security Operations and Remediation

   An engineering organization wants to reduce how often push protection needs to catch a secret in the first place, rather than relying on it as the sole safety net. Which practice most directly addresses the root cause?

   • AAdd a manual review step focused on hardcoded secrets
   • BRetrieve credentials at runtime from a secrets manager insteadCorrect
   • CDisable push protection while alternatives are investigated
   • DIncrease push protection sensitivity to flag more generic strings
   ✓ Correct answer: B

   When workloads use mechanisms like workload identity federation or OpenID Connect to obtain short lived credentials from a vault or cloud secrets manager on demand, there is nothing static and sensitive left to accidentally commit, addressing the problem upstream of any scanning control. Tuning push protection sensitivity or adding manual review steps only improve detection of secrets that still exist in code.

   Why the other options are wrong

   • AAn added manual review step can help but is a detective control layered on top of the same underlying practice of embedding secrets in code.
   • CDisabling push protection removes a valuable detective safety net and does nothing to address why secrets end up in source in the first place.
   • DBroadening push protection sensitivity may catch more cases but still only detects secrets after someone has already tried to commit them.
9. Question 9GitHub Security Suites Administration

   A pharmaceutical company offboards a departing engineer and immediately removes their GitHub account access, 45 days after that engineer's last push to a GHAS enabled repository. Assuming no other GHAS enabled activity from them, what does the committer report show for the remaining period?

   • AThe engineer disappears from the report immediately, since removing account access also removes any past license consumption.
   • BThe engineer is instead replaced in the count by whichever teammate inherits their repository access role.
   • CThe engineer still appears as an active committer for the remaining 45 days of the rolling window.Correct
   • DThe engineer's prior pushes are erased from the calculation retroactively once their account is deactivated.
   ✓ Correct answer: C

   The active committer calculation is based on push history within a rolling 90 day window, and access removal does not retroactively edit that history. Since the engineer pushed 45 days ago, they continue to count for the remaining 45 days of the window even though their account access has already been revoked. Only once the full 90 days elapse since that last push does the license free up automatically.

   Why the other options are wrong

   • AAccess removal does not erase already recorded push history, the rolling window still runs its course.
   • BThere is no reassignment mechanism where one person's counted status transfers to a teammate who inherits their access.
   • DPush history within the rolling window is not retroactively erased by deactivating the associated account.
10. Question 10GitHub Security Suites Administration

    Who can view the enterprise-level security overview spanning all organizations in the enterprise?

    • AAny organization owner within any one of the organizations in the enterprise
    • BAny member granted the security-manager role in an organization
    • COnly the enterprise owner role, given its aggregated cross-org scopeCorrect
    • DAny repository administrator on a repository inside the enterprise
    ✓ Correct answer: C

    The enterprise-level security overview is a privileged, aggregated view spanning every organization the enterprise owns, so access is restricted to the enterprise owner role rather than organization owners or ordinary members. This mirrors how organization-level overview access is restricted to org owners and security managers at that scope. Cross-org aggregation demands the enterprise-owner role.

    Why the other options are wrong

    • AOrganization owners see their own org's overview, not the enterprise-wide aggregated view.
    • BThe security-manager role is scoped to an organization, not the cross-org enterprise overview.
    • DRepository administrators operate at the repo level, well below the enterprise overview's scope.

Related GitHub resources

• GitHub Advanced Security study guideKey concepts
• GitHub practice examsAll GitHub
• Certification pathWhere this fits
• Certification exam guides & tipsBlog
• Plans & pricingFree & paid
• GitHub Foundations practice examRelated
• GitHub Actions practice examRelated
• GitHub Copilot practice examRelated

GitHub Advanced Security practice exam FAQ