Last Attempt GH-500 Questions

Secret scanning is a feature provided by GitHub that scans the contents of your GitHub repositories for known types of secrets, such as API keys and tokens. It operates within the GitHub environment and does not scan external systems, services, or repositories outside of GitHub. Its primary function is to prevent the accidental exposure of sensitive information within your GitHub-hosted code.​

The config-file input is used with the github/codeql-action/init action to specify the path to a custom CodeQL configuration file. This configuration can define additional query packs, custom queries, directories to include or exclude, and other CodeQL analysis settings. GitHub's official workflow documentation shows config-file under the with: section of the CodeQL initialization step. The queries input is used to specify additional query suites or query packs directly, rather than referencing a configuration file. source-root and db-location are not the appropriate init inputs for supplying the configuration-file path. Therefore, when the CodeQL workflow must load settings from a separate YAML configuration file, config-file is the correct parameter.

GitHub explicitly notifies the commit author when that person accidentally commits a detected secret, regardless of the author's notification preferences. Repository administrators are also among the users eligible to receive secret-scanning security notifications, subject to their repository watch and email notification configuration. GitHub's current notification model can additionally notify security managers and users with explicitly granted security-alert access, but those choices are not represented accurately by the generic “security analyst” option. Write and Maintain roles alone do not make a user the default repository-wide recipient represented by this question. For incremental scans, users who have security-alert access receive notifications according to their configured notification preferences, while commit authors receive notification regardless. Therefore, among the supplied choices, the expected combination remains the committer and repository administrators: B and C.

Repository rulesets provide centralized enforcement of repository policies before changes can be merged. Rulesets can require workflows or status checks to succeed, and GitHub specifically supports security-oriented enforcement such as dependency review and code scanning merge protection. For dependency review, an organization can require the dependency review workflow through a ruleset so that vulnerable dependency changes prevent merging. Code scanning rulesets can likewise require acceptable code scanning results and define alert thresholds. “Security GuardRails” and “status enforcement” are not GitHub repository features with the functionality described here, while Insights is primarily used for repository statistics and reporting. Therefore, repository rulesets provide the policy mechanism needed to enforce these security gates before code reaches protected branches.