DevOps / GitHub Actions Interview Questions
1. What is GitHub Actions and what problems does it solve?
GitHub Actions is a native CI/CD and workflow-automation platform built directly into GitHub. Instead of connecting an external tool such as Jenkins or CircleCI, you define automation logic in YAML files stored alongside your code. GitHub executes those files on cloud-hosted (or your own self-hos...
2. 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 ha...
3. How is a GitHub Actions workflow file structured, and where must it be placed?
Every workflow file must be placed inside the .github/workflows/ directory at the root of your repository and must use the .yml or .yaml extension. GitHub automatically detects any file in that directory and registers it as a workflow. The top-level keys of a workflow file are: name: — A human-re...
4. What are workflow triggers (on:) and which event types does GitHub Actions support?
The on: key defines which GitHub events cause a workflow to run. You can listen to a single event, a list of events, or an event with filters. GitHub provides more than 35 distinct event types across three broad categories. Repository events fire when something happens in your repo: push — a comm...
5. What is the difference between push, pull_request, and workflow_dispatch triggers?
These three triggers cover the most common CI/CD use-cases but serve very different purposes. Here is a direct comparison: GitHub Actions Trigger Comparison Trigger When it fires Typical use-case Key options push A commit is pushed to a branch or a tag is created Deploy to staging/production afte...
6. What are jobs in GitHub Actions, and how do they run in parallel by default?
A job is a named collection of steps that runs on a single runner from start to finish. Every job gets a fresh, isolated virtual machine (or container), so jobs do not share filesystem state, environment variables, or processes with each other unless you explicitly pass data via artifacts or outp...
7. What are steps, and what is the difference between run: and uses: in a step?
Steps are the individual tasks that make up a job. They run sequentially in the order listed, share the job's working directory and environment variables, and each step can read outputs produced by earlier steps. Every step has an optional name: for display in the logs and can set a conditional i...
8. What are runners, and what is the difference between GitHub-hosted and self-hosted runners?
A runner is the server (physical or virtual) that picks up a queued job and executes its steps. GitHub manages a global pool of hosted runners; alternatively you can register your own machines as self-hosted runners for full control over the environment. GitHub-Hosted vs Self-Hosted Runners Dimen...
9. What is the GitHub Actions Marketplace and how do you find and use actions from it?
The GitHub Actions Marketplace ( github.com/marketplace?type=actions ) is a public catalogue of reusable actions published by GitHub, major vendors, and the open-source community. At the time of writing it hosts tens of thousands of actions covering everything from language setup ( actions/setup-...
10. How do you use the actions/checkout action and what does it do?
actions/checkout clones your repository onto the runner so subsequent steps have access to your source code. Without it, the runner's working directory is empty — no source files, no scripts. It is almost always the first step in any CI job. The simplest usage just checks out the default branch a...
11. How do you pass environment variables and secrets to a GitHub Actions workflow?
Environment variables and secrets are surfaced inside a workflow through the env: map and the secrets context respectively. They can be declared at three scopes: workflow-level (available to every job), job-level (available to all steps in that job), or step-level (available only to that step). E...
12. What is the difference between the env:, secrets:, and vars: contexts in GitHub Actions?
All three hold key-value configuration but differ in storage location, security characteristics, and intended use. env vs secrets vs vars Contexts Context Where it is defined Encrypted at rest? Visible in logs? Typical use env: Inline in the workflow YAML (workflow/job/step scope) No — plain text...
13. How do you cache dependencies in GitHub Actions using actions/cache?
actions/cache saves and restores a directory between workflow runs so that package managers like npm, Maven, or pip do not re-download the same dependencies on every run. A cache hit can reduce a 3-minute install step to a few seconds. The action requires two inputs: path (the directory to cache)...
14. How do you use matrix builds in GitHub Actions to test across multiple environments?
A matrix strategy tells GitHub Actions to spawn multiple parallel job instances from a single job definition, varying one or more parameters across those instances. This is ideal for testing against several language versions, operating systems, or configuration combinations without duplicating YA...
15. How do you control job execution order in GitHub Actions using needs:?
needs: declares that a job must wait for one or more other jobs to succeed before it starts. This turns the default parallel fan-out into a directed acyclic graph (DAG) of dependencies, allowing you to model pipelines like build → test → deploy. jobs: build: runs-on: ubuntu-latest steps: - uses: ...
16. How do you share data between steps within a job using step outputs?
Steps within the same job communicate by writing key-value pairs to the special file at the path stored in $GITHUB_OUTPUT . Any subsequent step in the same job can then read that value via ${{ steps.
17. How do you share build artifacts between jobs using actions/upload-artifact and actions/download-artifact?
Because each job in a workflow runs on a separate, isolated runner, files created in one job are not visible to another job by default. actions/upload-artifact and actions/download-artifact bridge this gap by storing files in GitHub's artifact storage during the workflow run. jobs: build: runs-on...
18. What are reusable workflows in GitHub Actions and how do you call them?
A reusable workflow is a standard workflow file that exposes a workflow_call trigger, making it callable from other workflows. This lets you centralise a common CI/CD pattern (e.g. build-and-push, deploy-to-kubernetes) in one place and have many repositories or workflows invoke it without copy-pa...
19. 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. # ....
20. How do you set up a Docker container service for integration tests using services: in GitHub Actions?
The services: block on a job starts Docker containers as side-cars alongside the job's steps. This lets you spin up a real PostgreSQL, Redis, or any other service that your integration tests need — without mocking — using the same Docker images you would use in production. jobs: integration-tests...
21. How do you use conditional steps with if: in GitHub Actions?
The if: key on a job or step controls whether it executes. It accepts a GitHub Actions expression that evaluates to true or false . When false , the step is skipped and shown as greyed-out in the run log — the job does not fail. Common patterns: steps: # Run only on pushes to main - name: Deploy ...
22. What are the key GitHub Actions expression contexts and what information does each provide?
Contexts are namespaced objects available inside ${{ }} expressions throughout a workflow. Each context exposes a different slice of information about the run, the repository, or the execution environment. GitHub Actions Contexts Context Key properties Example use github ref , sha , event_name , ...
23. How do you use concurrency groups to cancel outdated workflow runs in GitHub Actions?
The concurrency: key limits how many workflow runs (or jobs) with the same group name can be active simultaneously. Setting cancel-in-progress: true automatically cancels any run in the same group that is already in progress when a new one starts — perfect for preventing stacked deploys or redund...
24. What is the GITHUB_TOKEN and what permissions does it have?
GITHUB_TOKEN is a short-lived, automatically generated token that GitHub injects into every workflow run. It is scoped to the repository where the workflow runs, expires when the job finishes, and requires no manual secret configuration. You access it via ${{ secrets.GITHUB_TOKEN }} or the enviro...
25. How do you trigger one GitHub Actions workflow from another using workflow_run?
workflow_run fires a workflow when a named workflow completes (or starts). This lets you chain independent workflows without merging them into one file — useful for separating CI (fast, runs on all PRs) from CD (slow, only runs after CI passes on main). # .github/workflows/deploy.yml on: workflow...
26. How do you write a custom JavaScript action for GitHub Actions?
A JavaScript action consists of two files at minimum: action.yml (the action metadata) and an entry-point JavaScript file. It runs directly on the runner (no container spin-up), which makes it fast. The @actions/core and @actions/github npm packages provide the toolkit for reading inputs, setting...
27. How do you write a custom Docker container action for GitHub Actions?
A Docker container action packages its logic and dependencies in a Docker image, giving complete control over the execution environment. It is ideal when your action requires a specific OS, binary tools not available on the runner, or a compiled language without a portable pre-built binary. actio...
28. How do you implement a complete CI/CD pipeline for a container image in GitHub Actions — build, push to a registry, and deploy?
A typical container CI/CD pipeline in GitHub Actions has three stages: build the image, push it to a registry, and trigger a deployment. Here is a production-ready example using GitHub Container Registry (GHCR): name: Build and Deploy Container on: push: branches: [ main ] permissions: contents: ...
29. How do you implement path filtering so a workflow only runs when specific files change?
GitHub Actions supports built-in path filtering on push and pull_request triggers via the paths: and paths-ignore: filters. When set, the workflow only fires if at least one file in the commit diff matches the given glob pattern. on: push: branches: [main] paths: - 'backend/**' # any file under b...
30. How do you debug failing GitHub Actions workflows — enabling debug logging and using tmate?
When a workflow fails and the log output is not enough to diagnose the problem, GitHub Actions provides two main debugging mechanisms: enhanced log verbosity via repository secrets, and live interactive SSH access to the runner via the tmate action. 1. Enable debug logging by adding two repositor...
31. How do you implement branch protection rules with required GitHub Actions status checks?
Branch protection rules enforce that certain GitHub Actions jobs must pass before a pull request can be merged into a protected branch. This creates a hard gate preventing broken code from landing on main. Step 1 — Name your status check in the workflow. Each job name becomes a status check. Name...
32. How do you handle large monorepos with multiple services in GitHub Actions?
Large monorepos present two main problems: every commit triggers all CI jobs even when only one service changed, and a single workflow file becomes unmanageably large. The solution combines path filtering, dynamic matrices, and workflow decomposition. Strategy 1 — Per-service workflow files with ...
33. What are OpenID Connect (OIDC) tokens in GitHub Actions and how do they replace long-lived cloud credentials?
GitHub Actions can obtain a short-lived OpenID Connect (OIDC) JWT token for each workflow run. Cloud providers (AWS, Azure, GCP) can be configured to accept this token as proof of identity and issue temporary cloud credentials in exchange — eliminating the need to store long-lived API keys or acc...
34. How do you prevent secret exposure and follow security hardening best practices in GitHub Actions?
GitHub Actions workflows run code triggered by events — including potentially untrusted content from pull requests — so hardening them against secret exposure and code injection is essential. 1. Pin third-party actions to a full commit SHA. A mutable version tag like @v3 can be silently updated t...
35. What are the key differences between GitHub Actions, Jenkins, and GitLab CI?
All three are CI/CD platforms but differ significantly in architecture, hosting model, and integration depth. Here is a direct comparison across the dimensions that matter most for a team choosing between them: GitHub Actions vs Jenkins vs GitLab CI Dimension GitHub Actions Jenkins GitLab CI Host...
