Free GH-500 practice test: 30 questions with answers

CodeQL-based code scanning analyzes source code for vulnerabilities and can run on pull requests. Dependabot checks dependencies, secret scanning finds credentials, and audit logs record administrative events.

SARIF is the Static Analysis Results Interchange Format that code scanning accepts from external tools. CSV and PDF are not the upload format, and screenshots carry no structured results.

Dismissing an alert with a reason and comment records the decision for audit while keeping the scanning active. Deleting the workflow, merging ignoring the alert and disabling scanning remove oversight.

Custom queries are included through the CodeQL configuration used by the workflow. A README, commit messages and issue templates do not affect the analysis.

Compiled languages require the build to run inside the analysis, so build steps must be correct. Color schemes, collaborator counts and licenses do not affect the analysis.

Scanning pull requests and the default branch on a schedule catches issues early and continuously, and disciplined triage improves signal. Ignoring warnings, one-time scans and disabling workflows reduce coverage.

Requiring code scanning as a status check in branch protection prevents merges when the required scan fails or reports blocking results. Disabling checks, badges and archived branches do not enforce gating.

Path exclusions in the CodeQL configuration remove generated code from analysis, which reduces noise without hiding real issues in maintained code. Manual mass dismissal, deleting the workflow and renaming files are poor controls.

Organization-level code security configurations can apply defaults to new repositories, which keeps coverage consistent. Manual or memory-based enabling leaves gaps, and disabling defaults works against the goal.

Security overview aggregates alerts and coverage across repositories, which supports prioritization. The README, logo settings and profile order do not aggregate security data.

Security coverage views show which repositories have each feature enabled. Marketplace, gists and discussions do not report coverage.

Organization policies for repository visibility and forks control who can access or copy private code. Avatars, fonts and star counts do not control access.

Enterprise or organization-level policies apply consistently to repositories, which reduces configuration drift. Team-by-team choices, test-only changes and memory-based controls do not enforce consistency.

Coverage percentages and the open alert backlog by severity and age show whether security is applied and is being resolved. Stars, commit message lengths and emoji reactions do not measure security effectiveness.

The audit log records administrative and security setting changes with actor and time. Star history, release notes and contributor graphs do not record configuration changes.

Restricting app access and approving apps at the organization level limits which integrations can act on repositories. Default open access, shared personal tokens and public repositories all weaken control.

Dependabot security alerts identify vulnerable dependencies and show the patched version when one exists. Secret scanning finds credentials, code scanning analyzes code patterns, and branch protection controls merges.

Development dependencies still need review and passing checks, and maintainers should confirm the update does not break tests or builds. Ignoring updates, merging without checks and removing all dependencies are not sound.

The dependabot.yml file in the .github directory configures update ecosystems, schedules and grouping. Gitignore controls tracked files, Dockerfiles define images and LICENSE files state terms.

Dependency review checks show newly introduced vulnerable or license-problematic dependencies in the pull request before merge. Star counts, commit counts and wiki dates do not indicate vulnerability.

The dependency graph lists direct and transitive dependencies for supported ecosystems, which underlies alerts and reviews. The other items are not dependency data.

Dependabot opens update pull requests and generates alerts based on advisory data for the repository's dependencies. It does not merge automatically by default, it needs dependencies to scan, and it can be enabled by organizations as well.

Updating the parent or applying an override moves the transitive dependency to a fixed version, which resolves the alert. Ignoring it leaves the vulnerability in place, deleting lock files breaks reproducibility, and disabling the graph hides information.

Push protection blocks commits that contain detected secrets before they reach the repository. Dependabot and CodeQL analyze dependencies and code after the push, and review rules do not inspect for secrets.

Secret scanning alerts report detected secrets, including partner patterns that GitHub recognizes. SARIF is a code scanning format, the dependency graph lists packages, and advisories describe vulnerabilities rather than leaked secrets.

Secret scanning covers the repository history when enabled, which surfaces older exposed secrets. Waiting for new commits misses existing exposures, and recreating or renaming the repository does not remove history.

A leaked secret must be revoked or rotated at the issuing service, since removing it from code does not invalidate it. Closing without checking, publicizing the repository and ignoring old tokens all leave the credential usable.

Custom patterns define the regex for internal token formats and can be scoped to repositories, organizations or enterprises. Branch names, labels and comments do not configure detection.

Rewriting history removes the secret from future clones, but the credential must still be rotated because copies may already exist. Changing the message, documenting the secret and only changing visibility do not remove exposure.

Push protection prevents secrets from being pushed, and secure stores keep credentials out of code. Hardcoded keys, shared tokens in documents and disabled alerts all increase exposure.