DevOps / GitHub Actions Interview Questions
What are the key components of GitHub Actions — workflows, jobs, steps, actions, and runners?
GitHub Actions is built from five composable pieces that work together to automate your software development lifecycle.
- Workflow — A YAML file stored in
.github/workflows/. A workflow describes when automation should run (the trigger) and what it should do (one or more jobs). A repository can have many workflows running independently. - Job — A set of steps that execute on the same runner. All steps in a job share a filesystem and environment. By default, jobs in the same workflow run in parallel unless you declare dependencies with
needs:. - Step — An individual task inside a job. A step either runs a shell command (
run:) or calls a reusable action (uses:). Steps within a job run sequentially and share the job's working directory. - Action — A reusable unit of automation. An action can be a JavaScript program, a Docker container, or a composite shell script. You reference actions from the Marketplace (e.g.
actions/checkout@v4) or from your own repository. Actions receive inputs and can produce outputs for downstream steps. - Runner — The machine that actually executes a job. GitHub provides hosted runners (Ubuntu, Windows, macOS) that are provisioned fresh for every job. You can also register self-hosted runners on your own infrastructure for larger workloads, custom tooling, or network access to private systems.
The hierarchy is: one workflow contains many jobs; each job runs on a runner and contains many steps; each step optionally calls an action. Understanding this hierarchy explains almost every YAML property you will encounter in GitHub Actions.
More Related questions...