Apply Modern Development Practices Study Guide — GH-900

Modern Development — Actions, Packages, CI/CD

This domain accounts for 18% of the GitHub Foundations exam — the second-largest domain — and tests your ability to understand, configure, and reason about GitHub's automation and DevOps tooling. Questions focus on what each feature does, how components relate to one another, default behaviors, tier availability, and when to choose one approach over another. Expect scenario-based questions where you must select the correct workflow trigger, runner type, package registry, or security feature for a described use case.

GitHub Actions Overview: Workflows, Jobs, Steps, Runners

GitHub Actions is GitHub's built-in CI/CD and automation platform. It allows you to automate software workflows directly in your repository.

Core Concepts

Workflow File Location and Structure

• Must be stored in .github/workflows/ in the repository root.
• File extension must be .yml or .yaml.
• A repository can have multiple workflow files.
• Each workflow file can contain multiple jobs.

name: CI
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: echo "Hello World"

Key YAML keywords

• on: — defines the trigger
• jobs: — contains all job definitions
• runs-on: — specifies the runner
• steps: — list of sequential steps within a job
• uses: — references an action
• run: — executes a shell command
• needs: — declares job dependency (makes jobs run sequentially)
• env: — sets environment variables
• with: — passes inputs to an action

Common traps:

• Jobs run in parallel by default; you must use needs: to enforce sequential order.
• A workflow file must be in the default branch to be triggered by most events (branch-scoped triggers may differ).
• Steps within a job always run sequentially, never in parallel.
• uses: and run: are mutually exclusive within a single step.

Workflow Triggers

Triggers (defined under on:) determine what event causes a workflow to execute.

Common Trigger Types

Trigger Decision Flow

How to choose the right workflow trigger for a given scenario

Cron Syntax for schedule

• Format: 'minute hour day-of-month month day-of-week'
• Example: '0 2 * * 1' = every Monday at 2:00 AM UTC
• Scheduled workflows only run on the default branch.

Common traps:

• workflow_dispatch allows manual runs but does not trigger automatically; it is not a replacement for push.
• repository_dispatch requires an authenticated POST request to the GitHub API; it cannot be triggered by a simple UI click.
• pull_request events from forked repositories run with read-only permissions and no access to secrets by default.
• schedule triggers do not guarantee exact timing; GitHub may delay them during high load.
• Multiple triggers can be listed under on: as an array: on: [push, pull_request].

Scenario: A team wants external Jenkins pipelines to trigger a GitHub Actions workflow after a successful build. Answer: Use repository_dispatch. Jenkins sends a POST request to the GitHub API with a custom event-type, and the workflow listens for on: repository_dispatch.