Learn GitHub Actions core architecture, production scenario-based questions, incident response, and real-world engineering solutions.
❓ Q1: What is GitHub Actions, and how does it process workflows under the hood?
Click on the dropdown below to reveal the technical answer.
Answer: GitHub Actions is an API-driven workflow automation and CI/CD platform integrated directly into GitHub. It allows you to automate tasks—such as building, testing, packaging, and deploying code—directly in response to repository events (e.g., code pushes, pull requests, release creation, or cron schedules).
❓ Q2: Can you list and explain the key architectural components of GitHub Actions?
Click on the dropdown below to reveal the technical answer.
Answer:
.github/workflows/.push, pull_request, schedule).needs.actions/checkout).❓ Q3: How do you configure workflow triggers, and what is the syntax for defining manual execution parameters?
Click on the dropdown below to reveal the technical answer.
Answer:
Workflow triggers are defined under the on: block. To configure manual execution, use the workflow_dispatch trigger:
on:
workflow_dispatch:
inputs:
environment:
description: 'Target Environment'
required: true
default: 'staging'
This enables an "Run workflow" button in the GitHub Actions UI.
❓ Q4: What is a matrix strategy in GitHub Actions, and in what scenarios would you use it?
Click on the dropdown below to reveal the technical answer.
Answer: A matrix strategy runs multiple jobs containing variations of input configurations in parallel:
strategy:
matrix:
os: [ubuntu-latest, windows-latest, macos-latest]
node-version: [16, 18, 20]
This is useful for cross-platform testing of libraries, applications, or packages across different language environments and OS distributions.
❓ Q5: How do GitHub-hosted runners compare to self-hosted runners? When is self-hosting required?
Click on the dropdown below to reveal the technical answer.
Answer:
❓ Q6: How do environments and environment protection rules help secure deployments to production?
Click on the dropdown below to reveal the technical answer.
Answer:
Environments describe target deployment destinations (e.g., production, staging). You can configure protection rules on environments:
main).❓ Q7: Why should we use OpenID Connect (OIDC) integration for cloud auth instead of storing static AWS credentials?
Click on the dropdown below to reveal the technical answer.
Answer:
Storing long-lived AWS IAM access keys in GitHub Secrets poses a significant security risk if the credentials are leaked.
OIDC establishes a trust relationship between GitHub and your cloud provider (e.g., AWS IAM). The workflow requests a short-lived, single-use JWT token from GitHub's OIDC provider. AWS validates the token signature and returns temporary credentials (valid for e.g., 1 hour) using sts:AssumeRoleWithWebIdentity, eliminating the need to store static cloud credentials in GitHub.
❓ Q8: How do we implement caching in GitHub Actions to speed up dependency installation times?
Click on the dropdown below to reveal the technical answer.
Answer:
Use actions/cache or built-in package manager integrations (like actions/setup-node cache option) to save dependency folders (e.g., node_modules or .m2 repository).
package-lock.json).❓ Q9: Since jobs run in isolated virtual environments, how do we pass build artifacts from a build job to a deploy job?
Click on the dropdown below to reveal the technical answer.
Answer: Jobs run in isolated environments and do not share disk space. To pass files:
actions/upload-artifact in the builder job to upload files (e.g., compiled binary, zip archive) to GitHub's storage.actions/download-artifact in the consumer/deployer job to fetch files back down into the local runner filesystem.❓ Q10: How do concurrency groups work, and how do you configure a workflow to automatically cancel in-progress runs when a new commit is pushed?
Click on the dropdown below to reveal the technical answer.
Answer: Concurrency groups allow restricting execution to only one job or workflow run at a time per group (e.g., per branch or per environment):
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true
Setting cancel-in-progress: true automatically terminates active, older builds if a new push triggers a newer build, saving runner minutes.
❓ Q11: How do you manage and inject encrypted secrets into our workflow runs securely?
Click on the dropdown below to reveal the technical answer.
Answer:
${{ secrets.API_TOKEN }}.❓ Q12: What is the difference between 'run' and 'uses' in a workflow step definition?
Click on the dropdown below to reveal the technical answer.
Answer:
run: npm install or run: echo "hello").uses: actions/checkout@v4).❓ Q13: What are composite actions, and why would we use them instead of repeating YAML code?
Click on the dropdown below to reveal the technical answer.
Answer: A composite action package groups multiple workflow steps into a single reusable action, allowing developers to dry-run and standardize common build/test operations across multiple repositories without duplicate yaml blocks.
❓ Q14: If a workflow fails, what is your systematic troubleshooting process?
Click on the dropdown below to reveal the technical answer.
Answer:
ACTIONS_STEP_DEBUG and ACTIONS_RUNNER_DEBUG set to true.❓ Q15: What are Reusable Workflows, and how do they differ from composite actions?
Click on the dropdown below to reveal the technical answer.
Answer:
Reusable Workflows allow you to define a complete workflow YAML file in a central repository and call it from other workflow files across multiple repositories (using uses: owner/repo/.github/workflows/reusable.yml@v1).
workflow_call event and accept defined inputs and secrets.❓ Q16: Can you summarize when to choose a Reusable Workflow over a Composite Action?
Click on the dropdown below to reveal the technical answer.
Answer:
| Feature | Reusable Workflows (workflow_call) | Composite Actions |
|---|---|---|
| Execution | Runs as a standalone job or multiple jobs. | Runs as a set of steps within an existing job. |
| Secrets | Secrets are explicitly passed using the secrets: keyword. | Inherits secrets directly from the host job's context. |
| Runners | Can declare custom runner types (runs-on) inside it. | Runs on the runner specified by the caller job. |
| Multi-job | Yes, can contain multiple dependent jobs. | No, only supports sequential steps. |
❓ Q17: What security measures must be put in place when operating self-hosted runners?
Click on the dropdown below to reveal the technical answer.
Answer:
USER runner).❓ Q18: How do you construct a pipeline that deploys to staging first, and then to production only if staging succeeds?
Click on the dropdown below to reveal the technical answer.
Answer:
Configure dependent jobs using the needs keyword and target environments:
jobs:
deploy-staging:
runs-on: ubuntu-latest
environment: staging
steps:
- run: echo "Deploying to Staging..."
deploy-prod:
runs-on: ubuntu-latest
needs: deploy-staging
environment: production
steps:
- run: echo "Deploying to Production..."
❓ Q19: How do you implement a manual approval gate for production deployments?
Click on the dropdown below to reveal the technical answer.
Answer:
production) in the GitHub Repository Settings.environment: production). When the workflow runs, execution pauses on this job and notifies reviewers to approve or reject the deployment.❓ Q20: What steps do you take to prevent credentials and secrets from leaking into the build runner logs?
Click on the dropdown below to reveal the technical answer.
Answer:
*** in stdout/stderr logs.❓ Q21: How do you sign build artifacts or container images within a GitHub Actions run to verify their authenticity?
Click on the dropdown below to reveal the technical answer.
Answer: Use Cosign (from Sigstore) to sign container images using GitHub's OIDC identity:
cosign sign --yes <image-digest> utilizing keyless signing. Cosign validates the runner's OIDC JWT identity and records the signature in the Sigstore transparency log (Rekor).❓ Q22: Explain the difference between Continuous Integration (CI) and Continuous Deployment (CD).
Click on the dropdown below to reveal the technical answer.
Answer:
❓ Q23: What are some popular CI/CD tools, and how do on-premises models compare to SaaS models?
Click on the dropdown below to reveal the technical answer.
Answer: Popular CI/CD tools can be grouped into two main deployment models:
These are installed and maintained on your own infrastructure, providing absolute control over network security and access:
These are fully managed cloud platforms where the provider hosts the build runners and infrastructure:
❓ Q24: What is a build pipeline, and what are its typical execution stages?
Click on the dropdown below to reveal the technical answer.
Answer: A build pipeline is an automated set of sequential processes that compiles raw source code, resolves dependencies, executes tests, runs code quality checks, and generates executable deployment packages (artifacts like binaries, JARs, or Docker images).
❓ Q25: How do you optimize a CI/CD pipeline for both speed and reliability?
Click on the dropdown below to reveal the technical answer.
Answer: Optimizing a CI/CD pipeline is essential to maintain fast feedback loops and prevent delivery bottlenecks:
node_modules, .m2 repository, pip cache) across pipeline runs to prevent downloading dependencies from scratch.