DevOps / GitHub Actions Interview Questions
What are composite actions and when should you choose them over reusable workflows?
A composite action is a custom action that groups multiple run: and uses: steps into a single reusable unit referenced with uses: inside a step — not as a job. It is defined by an action.yml file in a repository and runs within the calling job's runner, sharing its environment and filesystem.
# .github/actions/setup-env/action.yml name: 'Setup Build Environment' description: 'Install tools and restore cache' inputs: node-version: required: true default: '20' runs: using: 'composite' steps: - uses: actions/setup-node@v4 with: node-version: ${{ inputs.node-version }} - uses: actions/cache@v4 with: path: ~/.npm key: npm-${{ runner.os }}-${{ hashFiles('**/package-lock.json') }} - run: npm ci shell: bash
Usage in a workflow:
steps: - uses: actions/checkout@v4 - uses: ./.github/actions/setup-env with: node-version: '22' - run: npm test
| Dimension | Composite Action | Reusable Workflow |
|---|---|---|
| Referenced as | A step (uses:) | A job (uses:) |
| Runner | Caller's runner (shared) | Its own separate runner |
| Secrets access | Via inputs — not directly | Via secrets: block or secrets: inherit |
| Can call other workflows? | No | Yes (nested up to 4 levels) |
| Best for | Small setup sequences reused across steps | Entire pipeline stages shared across repos |
Choose a composite action when you want to extract a few repeated setup steps within a job. Choose a reusable workflow when you want to share a complete, self-contained pipeline job (with its own runner, concurrency, and environment) across multiple repositories.
More Related questions...