GitHub Actions
GitHub's built-in CI/CD platform — automates testing, building, and deploying code directly from your repository using workflow YAML files.
GitHub Actions is the most widely adopted CI/CD tool in the software industry, largely because it is built directly into GitHub where most code already lives. Workflows are defined in YAML and triggered by repository events — pushes, pull requests, releases — and can run tests, build containers, deploy to cloud providers, or automate any scripted task. GitHub Actions has rapidly displaced Jenkins, CircleCI, and Travis CI as the default CI/CD choice, and fluency with it is now a baseline expectation in most engineering roles that involve any kind of deployment or automation.
Typical time to job-readiness: ~2 weeks.
Learning GitHub Actions
Beginner
Write your first workflow: trigger on push, run a test suite, and report pass/fail on pull requests. Understand the YAML structure — triggers (on:), jobs, steps, and runners. Use marketplace actions (actions/checkout, actions/setup-node) rather than writing everything from scratch.
Intermediate
Matrix builds for testing across multiple versions, secrets management, environment-based deployments (dev/staging/prod), caching dependencies for faster runs, and reusable workflows to avoid duplication.
Advanced
Custom Docker-based actions, self-hosted runners for cost or compliance requirements, OIDC authentication to AWS/GCP (no long-lived credentials), and optimizing workflow performance. DevOps interviews often ask you to design or debug a CI/CD pipeline — GitHub Actions is the most common context.
Key concepts
- Workflow YAML: trigger (on:), jobs (run in parallel by default), and steps (run sequentially within a job)
- Runners: GitHub-hosted (ubuntu-latest, windows-latest) or self-hosted for custom environments
- Actions: reusable steps from the marketplace (actions/checkout, actions/setup-node, docker/build-push-action)
- Secrets: stored at repo/org level, injected via ${{ secrets.MY_SECRET }} — never log them
- Environments: named deployment targets (staging, production) with required approvals and protection rules
- Matrix builds: test across multiple OS/language versions in parallel with a single job definition
Common interview topics
- Walk me through a GitHub Actions workflow you've written
- How do you manage secrets in GitHub Actions
- What is a matrix build and when would you use one
- How would you deploy to AWS from GitHub Actions without storing long-lived credentials
- How do you reuse workflow logic across multiple repositories