GitHub Foundations · 18% of the exam

Modern Development — Actions, Packages, CI/CD: free practice questions

5 sample questions from our 14-question bank for this domain — answers and explanations included. These are the same scenario-based style as the real GitHub exam.

1. A company uses GitHub Advanced Security (GHAS). A developer pushes a commit that inadvertently includes an AWS access key in a configuration file. Which GHAS feature will detect this exposure, and what is the immediate automated action GitHub takes by default?

  • A. Code scanning detects the key using CodeQL analysis and opens a security advisory in the repository.
  • B. Secret scanning detects the pattern matching an AWS access key and, for supported partners, automatically notifies the secret provider (AWS) to revoke the credential.✓ Correct
  • C. Dependabot security alerts detect the key because AWS SDKs are a known vulnerable dependency.
  • D. Secret scanning detects the key and automatically removes the commit from the repository's history.
Explanation

GitHub's secret scanning feature uses pattern matching to detect known secret formats — including AWS access keys — in commits. For AWS and other supported partner integrations, GitHub's 'push protection' and partner notification pipeline automatically alerts the secret provider (AWS) so the credential can be revoked before it is exploited. Code scanning / CodeQL (A) is designed to find code vulnerabilities and bugs, not credential strings. Dependabot security alerts (C) track known CVEs in dependencies — they have no mechanism for detecting hardcoded secrets. Secret scanning does NOT automatically rewrite or remove commits (D); history rewriting must be done manually by the repository owner using tools like git-filter-repo.

2. An organization wants to enforce that all GitHub Actions workflows across every repository may ONLY use actions from the organization's own verified internal actions repository, and must block all community Marketplace actions — including 'actions/checkout'. Where and how can an organization administrator configure this restriction?

  • A. In each repository's Settings → Actions → General, by setting the allowed actions to 'Local actions only'
  • B. In the organization's Settings → Actions → General, by selecting 'Allow select actions and reusable workflows' and specifying only the organization's internal action patterns while leaving the GitHub-owned actions checkbox unchecked✓ Correct
  • C. By creating a required status check that scans workflow YAML files for unauthorized action references before merging
  • D. In the enterprise Settings → Policies, by enabling 'Require organization-approved actions' for all repositories
Explanation

Organization administrators can govern which actions are permitted across all repositories from the organization's Settings → Actions → General page. Selecting 'Allow select actions and reusable workflows' lets them specify an allowlist pattern (e.g., 'my-org/*') and explicitly leave the 'Allow actions created by GitHub' checkbox unchecked, blocking even 'actions/checkout' and other GitHub-owned actions. Option A ('Local actions only') is a per-repository setting and would need to be applied to every repository individually — it also does not allow specifying an internal actions org. Option C describes a detective control (a CI check) not a preventive enforcement mechanism; it could be bypassed and does not enforce at the platform level. Option D describes a setting that does not exist by that name in GitHub Enterprise; the correct control is at the organization Actions policy level as described in B.

3. A security engineer wants Dependabot to automatically open pull requests whenever a direct npm dependency in the repository has a new patch or minor version available. They also want checks to run weekly rather than daily. Which file should they create, and where?

  • A. A file named dependabot.json in the repository root
  • B. A file named .github/dependabot.yml in the repository✓ Correct
  • C. A file named .github/workflows/dependabot.yml in the repository
  • D. A file named security-policy.yml in the .github directory
Explanation

Dependabot version updates are configured in '.github/dependabot.yml'. This file specifies the package ecosystem (e.g., npm), directory, and update schedule (e.g., weekly). 'dependabot.json' in the root is not a valid filename or location for Dependabot configuration. '.github/workflows/dependabot.yml' would be interpreted as a GitHub Actions workflow file, not a Dependabot configuration. 'security-policy.yml' is not a recognized configuration file for Dependabot; security policies are conventionally stored as SECURITY.md.

4. A team has a workflow that builds a Docker image and pushes it to the GitHub Container Registry (ghcr.io). After the push, they want a subsequent job in the same workflow to pull that image and run integration tests. What is the correct ghcr.io image reference format they should use?

  • A. docker.pkg.github.com/OWNER/REPOSITORY/IMAGE_NAME:TAG
  • B. ghcr.io/OWNER/IMAGE_NAME:TAG✓ Correct
  • C. registry.github.com/OWNER/IMAGE_NAME:TAG
  • D. packages.github.com/OWNER/IMAGE_NAME:TAG
Explanation

'ghcr.io/OWNER/IMAGE_NAME:TAG' is the correct format for the GitHub Container Registry. 'docker.pkg.github.com' was the legacy GitHub Packages Docker registry that has been superseded by ghcr.io and is no longer recommended for new projects. 'registry.github.com' and 'packages.github.com' are not valid GitHub registry hostnames — they are common distractors that sound plausible.

5. A company publishes a private npm package using GitHub Packages. A developer on the team tries to install the package locally using 'npm install' but receives a 401 Unauthorized error. What are TWO likely causes of this error? (Select TWO)

  • A. The developer has not configured their local ~/.npmrc file to point to the GitHub Packages registry for the package's scope.✓ Correct
  • B. The developer's personal access token does not have the 'read:packages' scope.✓ Correct
  • C. The package has not been published to the npm public registry.
  • D. The developer must be an organization owner to install private packages.
  • E. GitHub Packages does not support npm for private repositories.
Explanation

A 401 error when installing from GitHub Packages almost always means an authentication or registry configuration problem. (A) If the ~/.npmrc is not configured with the correct registry URL and auth token for the package's scope (e.g., @org-name), npm will either look at the public registry or fail to authenticate. (B) A PAT without 'read:packages' will be rejected by GitHub's registry with a 401. (C) is wrong — GitHub Packages is a separate registry; the package does not need to be on the public npm registry. (D) is wrong — any team member with appropriate repository access can install packages; org owner status is not required. (E) is wrong — GitHub Packages fully supports npm for both public and private repositories.

9 more questions in this domain

Practice the full bank with instant grading, flashcards, and a timed mock exam.

Start practicing free