Question 1

Is GitHub Actions free for private repositories?

Accepted Answer

There is a free tier — 2000 minutes/month on private repos for the Free plan, 3000 for Pro, 50,000 for Enterprise. Beyond that, Linux runners are $0.008/minute, Windows is 2× that, macOS is 10× (in 2026). For most early-stage Indian startups (under 5 engineers, light CI load), the free tier is enough. At 10+ engineers shipping daily, you will exceed it and either pay per-minute or move to self-hosted runners on EKS/GKE.

Question 2

How much does a GitHub Actions / DevOps engineer earn in India?

Accepted Answer

₹6-22 LPA in 2026 for engineers with CI/CD as a primary skill. The range depends heavily on what you pair it with: junior CI/CD engineers ₹6-10 LPA, mid-level DevOps with GitHub Actions + Kubernetes + AWS ₹14-18 LPA, senior platform engineers building internal developer platforms ₹20-22+ LPA. Companies hiring: Razorpay, Swiggy, Zerodha, Postman, CRED, Freshworks, Zomato. Fintech and ML-heavy shops pay at the top end.

Question 3

Should I use GitHub Actions or Jenkins for a new project in 2026?

Accepted Answer

GitHub Actions, unless you have an existing Jenkins investment with custom plugins you'd have to rewrite. The integration with PRs, secrets, environments, and the Marketplace ecosystem makes Actions the default for greenfield projects. Jenkins still wins for very complex multi-cluster pipelines with heavy custom-plugin requirements, but those use cases are rare in product startups.

Question 4

How do I handle very long-running builds (1+ hour) in GitHub Actions?

Accepted Answer

Default GitHub-hosted runners have a 6-hour job limit, 35-day workflow limit. For builds approaching that, options are: (a) split into multiple jobs that pass artifacts (parallel where possible), (b) use larger runners (4-64 vCPU) which complete in proportionally less wall time, (c) move to self-hosted runners on Kubernetes (no time limit, much faster spin-up). Heavy ML training jobs are the most common offender — most teams move those to a dedicated GPU runner pool.

Question 5

What's the most common GitHub Actions security mistake?

Accepted Answer

Using `pull_request_target` and checking out the PR head SHA. This runs untrusted code with full repo secrets and was the root cause of multiple high-profile CI compromises in 2022-23. Runner-up: not pinning third-party Actions to SHAs, which exposes you to tag-rewrite supply-chain attacks like the 2025 `tj-actions/changed-files` incident. Both are well-documented in the official GitHub security hardening guide and should be the first audit you run on any new repo. A close third is leaving `permissions:` unset at the workflow level, which gives every job write access by default — easy fix, big blast-radius reduction.

Question 6

Can I run GitHub Actions on ARM-based runners in 2026?

Accepted Answer

Yes. GitHub rolled out Linux ARM64 runners (`ubuntu-24.04-arm`, `ubuntu-22.04-arm`) to general availability in 2024-25, and they are widely used in 2026. ARM runners are about 30-40% cheaper per minute than equivalent x86 runners and noticeably faster for Node, Go, Rust, and JVM workloads (which all have first-class ARM toolchains now). The main caveat: any native code dependency must be available for ARM (`node-canvas`, certain prebuilt npm modules). Most teams use ARM for Linux Docker image builds (cross-arch via `docker/build-push-action` and QEMU is slow) and stay on x86 only where a dependency forces it. Self-hosted ARM is also straightforward on AWS Graviton instances via ARC.

Question 7

What is GitHub Actions and what problems does it solve?

Accepted Answer

GitHub Actions is GitHub's native CI/CD and automation platform, launched in 2018 and reaching general availability in 2019. It solves the integration friction that plagued earlier CI systems: instead of running Jenkins on your own infrastructure or wiring up CircleCI as an external app, the CI lives in the same place as the code, the issues, the PRs, and the package registry. Workflows are defined in YAML files under `.github/workflows/`, triggered by GitHub events (push, pull_request, schedule, manual dispatch), and run on GitHub-hosted virtual machines or your own self-hosted runners. The platform also ships a Marketplace of reusable Actions — pre-built building blocks like `actions/checkout`, `actions/setup-node`, `aws-actions/configure-aws-credentials` — so you compose pipelines instead of writing shell scripts from scratch. For most Indian startups in 2026, it is the cheapest, fastest path from `git push` to a deployed application. As of 2026, surveys consistently put GitHub Actions as the most-used CI tool among Indian engineering teams, having overtaken Jenkins between 2022 and 2024, and Razorpay, Swiggy, Postman, CRED, Zerodha, Freshworks, and Zomato all run substantial production pipelines on it.

Question 8

What is the basic structure of a GitHub Actions workflow file?

Accepted Answer

A workflow is a YAML file with three required top-level keys: `name` (display label in the Actions UI), `on` (the events that trigger this workflow), and `jobs` (the units of work). Each job runs on a `runs-on` runner image, has a `steps` list of either `uses:` actions or `run:` shell commands, and can declare `needs:` to wait for other jobs. Workflows live in `.github/workflows/` at the repo root — anything in that folder is automatically picked up by GitHub. A single repo can have many workflow files; they run independently and have their own triggers. Common organization: one workflow per concern (`ci.yml`, `deploy.yml`, `security.yml`, `release.yml`) rather than one giant file with conditional steps — keeps the YAML readable and the Actions UI navigable.

Question 9

What are the most common workflow triggers?

Accepted Answer

The `on:` key accepts a single event, a list, or a map of events with filters. The five triggers you will see in 90% of pipelines: (1) `push` — runs on every push, filterable by branches/tags/paths, (2) `pull_request` — runs on PR open/sync/reopen, the workhorse for CI gates, (3) `schedule` — cron-based, for nightly builds, dependency updates, stale-issue cleanup, (4) `workflow_dispatch` — manual trigger with optional inputs, the standard way to do click-to-deploy, (5) `workflow_call` — makes the workflow reusable from other workflows. Less common but useful: `release` (fires on release publish for changelog automation), `issues` (auto-label, auto-close stale), `repository_dispatch` (external webhooks from a CMS, marketing tool, or third-party service). `schedule` runs in UTC and may be delayed during GitHub's peak hours — never rely on the exact minute for time-sensitive jobs.

Question 10

What is the difference between a job and a step?

Accepted Answer

A job is a unit of work that runs on a single runner machine. All steps inside a job share the same filesystem, environment variables, and runner. A step is a single command — either `uses:` (invokes a reusable Action) or `run:` (executes a shell command). Jobs run in parallel by default; steps inside a job run sequentially. If you need to share data across jobs you must use `artifacts` (upload/download files) or `outputs` (small string values) — the filesystem is wiped between jobs. This is the most common newcomer mistake: assuming `cd /tmp && do-thing` in job A is visible in job B.

Question 11

What are GitHub-hosted runners and what's available?

Accepted Answer

GitHub-hosted runners are fresh VMs that GitHub spins up for each job. The defaults: `ubuntu-latest` (currently Ubuntu 24.04), `windows-latest`, `macos-latest`. Linux runners are 2-vCPU/7 GB by default — fine for most builds, slow for big monorepos. In 2026 GitHub also offers larger runners (4/8/16/32/64 vCPU) and ARM64 runners (`ubuntu-24.04-arm`) at extra cost. macOS runners are 5-10× more expensive — only use them if you actually need to build for Apple platforms. Each job gets a clean VM, which is a feature, not a bug: you cannot accidentally pollute the environment from a previous run.

Question 12

How do you pass data between steps?

Accepted Answer

Two mechanisms: (1) environment variables via `$GITHUB_ENV` — append `KEY=value` to that file and the variable is available in all subsequent steps, (2) step outputs via `$GITHUB_OUTPUT` — append `name=value` to that file inside a step that has an `id:`, then reference it as `${{ steps..outputs. }}`. Note: the older `::set-output` and `::set-env` workflow commands were deprecated in 2020 for security — never use them in new code.

Question 13

How do you use secrets in a workflow?

Accepted Answer

Define secrets in repo or organization Settings → Secrets and variables → Actions, then reference them as `${{ secrets.MY_SECRET }}` inside the workflow. GitHub masks secret values in logs automatically — if `DEPLOY_KEY` is `abc123`, every occurrence of `abc123` in step output is replaced with `***`. Critical safety rules: (1) Never echo secrets to stdout — masking is not foolproof if you transform the value (base64, jq, etc), (2) Workflows triggered by `pull_request` from a fork do NOT receive secrets by default — this is the central security boundary that prevents random forks from stealing your production keys, (3) Use `secrets` scoped to environments (e.g. production has a different DEPLOY_KEY than staging) so a staging compromise does not leak prod credentials.

Question 14

What is the difference between `uses` and `run` in a step?

Accepted Answer

`run:` executes a shell command (bash on Linux/macOS, PowerShell on Windows by default). `uses:` invokes a reusable Action — either a public one from the Marketplace (`actions/checkout@v4`), a local one in the same repo (`./.github/actions/my-action`), or a Docker container. Actions encapsulate complex logic so you don't reimplement it: `actions/setup-node` handles installing the right Node version, configuring npm, and caching dependencies in 3 lines vs the 30 lines of bash it would replace.

Question 15

How do you check out the source code in a workflow?

Accepted Answer

Use `actions/checkout@v4`. It is the most-used Action in the entire ecosystem — almost every workflow's first step. By default it does a shallow clone (depth 1) of the commit that triggered the workflow. Common options: `fetch-depth: 0` to get full git history (required for tools like `lerna` or `nx affected`), `ref: ` to check out a different branch, `token:` to use a custom PAT (e.g. when you need to push back to the repo from inside the action — the default `GITHUB_TOKEN` cannot trigger other workflows, so an external PAT is needed).

Question 16

How do you control when a workflow or job runs using `if` conditions?

Accepted Answer

Add an `if:` key at the workflow, job, or step level. Conditions use GitHub's expression syntax — limited variants of JS-like booleans. Common examples: `if: github.event_name == 'push'`, `if: github.ref == 'refs/heads/main'`, `if: success() && needs.test.result == 'success'`. The functions `success()`, `failure()`, `cancelled()`, `always()` are the standard way to handle step-level error flow. A step set to `if: always()` runs even if a previous step failed — essential for upload-artifacts-on-failure or notify-slack-on-failure patterns.

GitHub Actions Interview Questions

What is GitHub Actions and what problems does it solve?

What is the basic structure of a GitHub Actions workflow file?

What are the most common workflow triggers?

What is the difference between a job and a step?

What are GitHub-hosted runners and what's available?

How do you pass data between steps?

How do you use secrets in a workflow?

What is the difference between `uses` and `run` in a step?

How do you check out the source code in a workflow?

How do you control when a workflow or job runs using `if` conditions?

What is the `GITHUB_TOKEN` and how is it different from a Personal Access Token?

How do you store and reuse a build artifact across jobs?

How do you authenticate to AWS from GitHub Actions without long-lived keys?

What is a matrix build and when should you use it?

How do you cache dependencies to speed up workflows?

What is a reusable workflow and how does it differ from a composite action?

What are the three types of custom GitHub Actions you can write?

How do you handle workflow concurrency to avoid race conditions?

What are GitHub Environments and why use them?

How does the security model handle PRs from forks?

What is `permissions:` and why should you set it explicitly?

What are self-hosted runners and when do you need them?

How do you trigger a workflow from another workflow?

How do you pin third-party Actions for security?

How would you set up a multi-stage CI/CD pipeline (lint → test → build → deploy)?

How do you architect GitHub Actions for a large monorepo at scale?

How do you securely use third-party Actions from the Marketplace?

How does GitHub Actions compare to CircleCI, Jenkins, and Buildkite?

How do you implement progressive deployment (canary / blue-green) with GitHub Actions?

How do you debug a flaky GitHub Actions workflow that fails intermittently?

Companies Hiring GitHub Actions

Salary Insights

Frequently Asked Questions