GitHub Actions Tutorial — Introduction Exercises

3 minute read

Practice Exercises — Introduction

Test your understanding of GitHub Actions fundamentals with these hands-on exercises.

Exercise 1 — Name the Building Blocks

Task: A workflow file is triggered when you push code. It runs two parallel jobs — one for linting and one for testing. Each job uses actions/checkout@v4 and then runs a shell command. Both jobs run on GitHub-hosted Ubuntu runners.

Identify all six building blocks in this scenario:

  1. Event = ?
  2. Workflow = ?
  3. Jobs = ?
  4. Steps = ?
  5. Actions = ?
  6. Runner = ?
Show Solution
  1. Event: push
  2. Workflow: The YAML file in .github/workflows/
  3. Jobs: Two — lint and test (running in parallel)
  4. Steps: Each job has two steps — one uses: (checkout) and one run: (shell command)
  5. Actions: actions/checkout@v4 (the reusable pre-built action)
  6. Runner: ubuntu-latest (GitHub-hosted)

Exercise 2 — Calculate the Cost

Task: You have a private repository on the GitHub Free plan (2,000 minutes/month). Your CI workflow runs for 8 minutes on every push. Your team pushes an average of 15 times per day, 5 days a week.

Calculate:

  1. How many minutes per week?
  2. How many minutes per month (4 weeks)?
  3. Will you exceed the free tier?
  4. If you switched to macOS runners, how would the cost change?
Show Solution
  1. Per week: 8 min × 15 pushes × 5 days = 600 minutes/week (Linux, 1× multiplier)
  2. Per month: 600 × 4 = 2,400 minutes/month
  3. Yes — 2,400 exceeds the free tier of 2,000 minutes. You’d need to optimize or pay for overages.
  4. macOS: 8 min × 10 multiplier = 80 effective minutes per run. 80 × 15 × 5 × 4 = 24,000 minutes/month — far exceeding the free tier.

Optimization: Use path filters to skip CI on documentation-only pushes, or add concurrency cancellation to avoid running stale builds.

Exercise 3 — Match the Tool

Task: Match each scenario to the best CI/CD tool choice:

Scenario Best Tool
A. Open-source project on GitHub, needs free CI ?
B. Enterprise with 500+ Jenkins pipelines and custom shared libraries ?
C. Team using GitLab for code, issues, and CI in one platform ?
D. Startup on GitHub, wants simple deploy-on-merge ?
E. Company needing on-premises CI with no cloud access ?
Show Solution
Scenario Best Tool Why
A GitHub Actions Unlimited free minutes for public repos
B Jenkins Existing investment, complex shared libraries
C GitLab CI Already on GitLab, integrated platform
D GitHub Actions Simple YAML, native GitHub integration
E Jenkins Self-hosted with no cloud dependency

Exercise 4 — Find the Right Action

Task: Visit the GitHub Actions Marketplace (or answer from memory) and find actions for these tasks:

  1. Set up a Python 3.12 environment
  2. Build and push a Docker image to a registry
  3. Send a Slack notification
  4. Scan code for security vulnerabilities
  5. Cache pip dependencies
Show Solution
  1. Python setup: actions/setup-python@v5 with python-version: '3.12'
  2. Docker build & push: docker/build-push-action@v5
  3. Slack notification: slackapi/slack-github-action@v1 (official Slack action)
  4. Security scanning: github/codeql-action/analyze@v3 or aquasecurity/trivy-action@master
  5. Cache pip: actions/cache@v4 with path: ~/.cache/pip and a hash key based on requirements.txt

Exercise 5 — Version Pinning

Task: Explain the security implications of each version reference:

# Option A
- uses: actions/checkout@v4

# Option B
- uses: actions/checkout@main

# Option C
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11

Which would you use for: (a) a typical project, (b) a production deployment touching secrets?

Show Solution
Option Risk Use Case
A — @v4 Low risk. Points to the latest patch of v4. Author could update it, but major version changes are unlikely to be breaking. ✅ Typical projects — good balance of security and convenience
B — @main High risk. Points to whatever is currently on main. Could change at any time, potentially introducing malicious code. ❌ Never use in production
C — @sha Lowest risk. Points to an exact commit. Cannot change. You control when to update. ✅ Production deployments touching secrets

Best practice for production: Use SHA pinning (@sha) and periodically update to newer verified commits. Use tools like Dependabot to automate SHA updates.

← Back to: Chapter 1: Introduction

Next Chapter: Chapter 2: Getting Started →

Updated:

You may also enjoy