A DevOps engineer introduces GitHub Actions to a team new to CI/CD: "A GitHub Actions workflow is a YAML file in .github/workflows/. It defines: triggers (when to run — on push, on pull request, on a schedule), jobs (parallel units of work running on a runner), and steps (sequential commands within a job). A runner is a virtual machine that executes the job — GitHub provides hosted runners (Ubuntu, Windows, macOS) or you can run self-hosted runners for custom environments or cost reasons." What is a matrix strategy in GitHub Actions, and when would you use it?
Matrix strategy: define variables with multiple values; GitHub Actions creates one job run per combination. Example: strategy: matrix: node-version: [16, 18, 20] + os: [ubuntu-latest, windows-latest] = 6 parallel jobs testing all combinations. Use cases: testing against multiple language versions (Node, Python, Java), testing across operating systems, testing against multiple dependency versions, generating build artifacts for different platforms. GitHub Actions vocabulary: Workflow: a YAML file in .github/workflows/ that defines automation. Triggered by events. Trigger: the event that starts a workflow. Common: push (code pushed), pull_request (PR opened/updated/merged), schedule (cron syntax), workflow_dispatch (manual trigger with inputs), workflow_call (reusable workflow). Job: a set of steps running on a single runner. Jobs run in parallel by default; use needs: to sequence them. Step: a command (run:) or action (uses:) within a job. Steps run sequentially within a job. Runner: the VM executing a job. GitHub-hosted: ubuntu-latest, windows-latest, macos-latest. Self-hosted: your own machine or cloud VM. Action: a reusable unit. actions/checkout (clone repo), actions/setup-node, docker/build-push-action. Artifact: files uploaded from a workflow (e.g., build output, test reports) via actions/upload-artifact. In conversation: 'Matrix builds saved us hours. Before, we had three separate jobs for Node 16/18/20 with duplicated YAML. One matrix definition replaced all three and runs them in parallel.'
2 / 5
A tech lead explains branch protection to a developer who force-pushed to main: "Branch protection rules prevent exactly this. For main, we require: status checks must pass (CI must pass before merge), at least two reviews required, dismiss stale reviews when new commits are pushed, require up-to-date branch (must merge main before your PR can merge), and no force pushes allowed. CODEOWNERS lets us require specific teams to review specific directories — changes to .github/workflows/ require DevOps team approval." What is a CODEOWNERS file and how does it interact with branch protection?
CODEOWNERS: a file at .github/CODEOWNERS (or CODEOWNERS in root). Format: path pattern followed by owners (users or teams). Example: /src/api/ @backend-team / .github/workflows/ @devops-team / *.tf @infra-team. When a PR modifies a CODEOWNERS path: GitHub automatically requests review from the designated owners. With branch protection "Require review from Code Owners": the PR cannot be merged without approval from the path owner — even if regular required reviewers have approved. Branch protection vocabulary: Required status checks: CI jobs that must succeed before merge. Includes: unit tests, integration tests, lint, type check. Required reviewers: minimum number of approvals before merge. Dismiss stale reviews: new commits after approval invalidate the approval — reviewer must re-approve. Require branches to be up to date: the PR branch must be current with the base branch. Prevents merging code that doesn't account for recent changes. Signed commits required: all commits must be GPG or SSH signed. Force push protection: prevents overwriting git history on protected branches. Merge strategies: merge commit (default, preserves history), squash merge (squashes all PR commits into one), rebase merge (replays commits linearly). Ruleset: the newer replacement for branch protection — applies to branches and tags, with more flexibility and audit logging. In conversation: 'CODEOWNERS + required review from code owners is how we enforce that security-sensitive files (CODEOWNERS itself, workflow files, Terraform) can't be changed without the right team's approval.'
3 / 5
A security engineer explains secret management in GitHub Actions: "Never hardcode secrets in workflow files or check them into git. Use GitHub repository secrets — they're encrypted, never appear in logs, and are only exposed to specific workflow steps via environment variables. For AWS authentication, we now use OIDC token federation: instead of storing a static AWS access key, GitHub issues a short-lived OIDC token, and AWS IAM trusts GitHub's OIDC provider. No long-lived credentials stored anywhere — each workflow run gets a fresh token." What is OIDC token federation in the context of GitHub Actions, and why is it more secure than storing static credentials?
OIDC (OpenID Connect) token federation: GitHub acts as an OIDC identity provider. During a workflow run, GitHub issues a JWT token containing claims about the workflow (repository, branch, environment, commit). The cloud provider (AWS, GCP, Azure) trusts GitHub's OIDC provider and exchanges the JWT for a short-lived cloud credential. Benefits over static secrets: No long-lived credentials: no AWS access key to rotate, leak, or expire. Short-lived: tokens expire in minutes — stolen tokens are useless quickly. Fine-grained: IAM role trust policy can restrict by repository, branch, or environment. Audit trail: every credential exchange is logged. Setup: 1) Configure GitHub OIDC provider in AWS IAM. 2) Create IAM role with trust policy restricting to your repo. 3) In workflow: permissions: id-token: write. Use: aws-actions/configure-aws-credentials action with role-to-assume. Secret vocabulary: Repository secret: scoped to one repository. Organisation secret: shared across repositories within an org. Approved per-repository. Environment secret: scoped to a deployment environment (production, staging) — only available when the job targets that environment. Secret scanning: GitHub automatically scans for accidentally committed credentials (AWS keys, tokens, API keys) and alerts or blocks push (push protection). Push protection: blocks a push that contains a known secret pattern. In conversation: 'We've completely eliminated AWS access keys from GitHub. OIDC federation means a stolen workflow run token is useless outside AWS IAM's trust boundary, and expires in 15 minutes anyway.'
4 / 5
A PM explains GitHub Projects to an engineering team starting a new initiative: "GitHub Projects v2 is a flexible project board linked to your issues and PRs. You can view the same data as a board (Kanban), a table (spreadsheet), or a roadmap (timeline). Each item has custom fields: priority, status, estimate, team, target quarter. Milestones are time-boxed goals linked to issues — useful for release planning. Labels help categorize and filter: bug, feature, tech-debt, blocked. Iterations are time-boxed periods for sprint planning." What is the difference between a milestone and an iteration in GitHub?
Milestone: a named goal with a target date. Groups issues and PRs that need to be complete for a release/version/deliverable. Example: v2.0.0 release, Q3 feature launch. Progress shown as % of open/closed issues. Useful for: release planning, communicating delivery timelines, tracking feature completeness. Iteration: a repeating time-box in GitHub Projects v2. Creates recurring sprint periods (1 week, 2 weeks). Issues assigned to an iteration = committed for that sprint. Useful for: agile sprint planning, velocity tracking, burndown. GitHub Projects vocabulary: View: a saved perspective on project data. Board (Kanban), Table (spreadsheet), Roadmap (Gantt). Multiple views, same underlying data. Custom field: text, number, date, single select, iteration — add metadata to items. Item: any issue, PR, or draft item in the project. Status field: typically Todo, In Progress, Done (or custom workflow states). Label: tags on issues. Common: bug, feature, documentation, good-first-issue, help-wanted, blocked, tech-debt, security. Workflow automation: auto-close issues when PR merged, auto-move to Done when issue closed. Issue vocabulary: Assignee: the person responsible for the issue. triage: initial assessment of new issues — categorize, prioritize, assign. stale: an issue with no recent activity — often auto-labeled by bots and auto-closed if no response. In conversation: 'We use milestones for external commitments ("v2.0 launches March 15") and iterations for internal sprint planning. They serve different audiences: milestones are for stakeholders, iterations are for the engineering team.'
5 / 5
A DevOps engineer explains Dependabot and automated security updates: "Dependabot scans your dependency files for known vulnerabilities and outdated packages. When it finds a vulnerable dependency, it opens a PR with the security fix. We auto-merge Dependabot PRs for patch updates if CI passes — we review minor/major updates manually. The GitHub Dependency Graph shows all direct and transitive dependencies. CodeQL is a static analysis tool that scans your code for security vulnerabilities — SQL injection, XSS, insecure deserialization. It runs as a GitHub Actions workflow and blocks PRs with high-severity findings." What is the difference between Dependabot and CodeQL in GitHub's security tools?
Dependabot: scans dependency manifests (package.json, requirements.txt, pom.xml, Gemfile.lock, go.mod, Cargo.toml, etc.) against the GitHub Advisory Database (known vulnerabilities). Opens PRs to update vulnerable dependencies to safe versions. Also opens PRs for non-security version updates (Dependabot version updates). Auto-merging: safe for patch updates with passing tests; review required for minor/major. CodeQL: semantic code analysis engine. Treats code as data — queries identify vulnerability patterns. Languages: JavaScript/TypeScript, Python, Java, C/C++, Go, Ruby, C#, Swift. Finds: SQL injection, command injection, path traversal, XSS, SSRF, insecure deserialization. Runs as: GitHub Actions workflow (code-scanning.yml) or GitHub Advanced Security feature. GitHub security vocabulary: Security Advisory: a documented vulnerability. CVE (Common Vulnerability and Exposure) ID. Dependency Graph: GitHub's view of all direct and transitive dependencies and their known vulnerabilities. Secret scanning: detects accidentally committed secrets (API keys, tokens). Push protection: blocks pushes containing secrets before they enter git history. Security overview: org-level view of security posture across all repositories. GHSA (GitHub Security Advisory): GitHub's own advisory database. Severity: Critical, High, Medium, Low — based on CVSS score. In conversation: 'Dependabot + auto-merge for patches means our dependencies stay current with zero toil. CodeQL catches the security mistakes our developers make — things like accidentally logging user passwords or building SQL queries with string concatenation.'