GitHub Mastery: Final Knowledge Test

GitHub Mastery: Final Knowledge Test

This assessment tests your mastery of Git, GitHub, and modern CI/CD workflows. Each scenario mirrors real situations you will encounter in production engineering teams. Work through each challenge, check your answers against the explanations, and use the knowledge map to identify any gaps before applying for roles that require GitHub expertise.

Section 1: Git Fundamentals

Challenge 1.1 — Accidental Staging

Scenario: You ran git add . and accidentally staged config/secrets.env. You have not committed yet.

Question: What is the exact command to unstage only that file while keeping it on disk and leaving all other staged changes intact?

Answer:

git restore --staged config/secrets.env

Explanation: git restore --staged removes a file from the staging area without modifying the working directory. The older equivalent git reset HEAD config/secrets.env also works, but git restore is the modern (2.23+) command. Do not use git checkout -- config/secrets.env — that discards working directory changes in addition to unstaging.

Follow-up: Add config/secrets.env to .gitignore immediately so it cannot be accidentally staged again:

echo "config/secrets.env" >> .gitignore
git add .gitignore
git commit -m "chore: ignore secrets file"

Challenge 1.2 — Branching Strategy Selection

Scenario: Your team releases every two weeks. When a critical bug is found in production, a hotfix must be deployed the same day without including any in-progress features from the current sprint.

Question: Choose between Trunk-Based Development and GitFlow. Justify your choice with a concrete workflow.

Answer: GitFlow (or a simplified variant: main + develop + hotfix branches).

Workflow:

main        ─────────────────────────── v1.5 ─── v1.5.1
              ↓                           ↑
develop   ─── feat/A ─── feat/B ─── ─── │
                                         │
hotfix                              ─────┘
(fixes critical prod bug, merges to main AND develop)

With GitFlow: production bugs are fixed on a hotfix/ branch cut from main, not develop. The fix merges to both main (for immediate deployment) and develop (so the fix is included in the next release).

With Trunk-Based Development, all developers commit to main. A hotfix would require a feature flag to isolate the in-progress features — possible but more complex for teams not already practicing trunk-based development.

Challenge 1.3 — Rebase vs Merge

Scenario: Your feature branch has 8 commits including "WIP", "fix typo", "address review comments". You are about to merge it to main.

Question: You want main's history to show one clean commit per feature. Which merge strategy do you choose in the GitHub UI? What does the resulting history look like?

Answer: Squash and Merge.

Before:
feature: A ─ B(WIP) ─ C(fix typo) ─ D(real work) ─ E(review) ─ F(review2) ─ G ─ H

After squash merge to main:
main: ... ─ [feature: add payment retry logic]
(All 8 commits collapsed to one, message = PR title + description)

The alternative — Create a Merge Commit — preserves all 8 commits plus a merge commit. Good if the commit history is meaningful; bad if it contains debugging or review-iteration commits.

Section 2: GitHub Actions

Challenge 2.1 — Trigger Syntax

Scenario: Your CI workflow must only run when a pull request is opened or updated targeting the main branch. It must not run for PRs targeting feature branches.

Question: Write the YAML on: block.

Answer:

on:
  pull_request:
    branches:
      - main       # Only PRs targeting main
    types:
      - opened
      - synchronize   # New commits pushed to the PR branch
      - reopened

Without branches: [main], the workflow would run for all PRs regardless of target.

Challenge 2.2 — Job Dependencies and Outputs

Scenario: You have three jobs: test, build, and deploy. deploy needs the Docker image tag from build. build should only run if test passes.

Question: Write the workflow structure showing needs, outputs, and how deploy consumes the image tag from build.

Answer:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test

  build:
    runs-on: ubuntu-latest
    needs: test        # Only runs if test succeeds
    outputs:
      image-tag: ${{ steps.tag.outputs.tag }}
    steps:
      - uses: actions/checkout@v4
      - name: Generate image tag
        id: tag
        run: echo "tag=${{ github.sha }}" >> "$GITHUB_OUTPUT"
      - run: docker build -t my-app:${{ steps.tag.outputs.tag }} .
      - run: docker push my-app:${{ steps.tag.outputs.tag }}

  deploy:
    runs-on: ubuntu-latest
    needs: build       # Only runs if build succeeds
    steps:
      - name: Deploy
        run: echo "Deploying image tag ${{ needs.build.outputs.image-tag }}"

Challenge 2.3 — OIDC Authentication

Scenario: Your CI pipeline currently uses AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY stored as GitHub secrets. You want to eliminate these long-lived credentials.

Question: What is the name of the protocol that replaces long-lived credentials in GitHub Actions? What permission must the workflow explicitly declare to use it?

Answer: OIDC (OpenID Connect). The workflow must declare:

permissions:
  id-token: write    # Required to generate the OIDC JWT
  contents: read

The workflow then uses:

- uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: arn:aws:iam::123456789:role/github-actions-deploy
    aws-region: us-east-1
    # No access key or secret key needed

GitHub generates a short-lived JWT for each workflow run. AWS validates the JWT against the GitHub OIDC provider and grants temporary credentials for the specified role. The credentials last only for the duration of the job.

Section 3: Security

Challenge 3.1 — Leaked Credential Response

Scenario: You discover that STRIPE_SECRET_KEY may have been exposed in a GitHub Actions log from 2 days ago.

Question: List the steps to respond correctly.

Answer (in order):

1. Rotate the credential immediately at the source — go to the Stripe dashboard and generate a new secret key. Do this before doing anything else. The old key is compromised; assume it has already been used.
2. Update the GitHub secret — replace STRIPE_SECRET_KEY in Repository Settings → Secrets with the new key.
3. Check Stripe's event log — look for any API calls made with the old key in the last 48 hours. Investigate any suspicious activity.
4. Audit the workflow log — find exactly how the key was exposed. Common causes: echo "${{ secrets.STRIPE_SECRET_KEY }}", passing secrets to an action that logs inputs, or run: env.
5. Fix the workflow — remove the code that caused exposure. GitHub automatically redacts exact secret matches, but encoding (base64, URL encoding) bypasses redaction.
6. Enable secret scanning — Settings → Security → Secret scanning → Enable push protection to prevent future credential commits.

Challenge 3.2 — Branch Protection

Scenario: You want to enforce that every commit to main has been code-reviewed and all CI checks pass. No developer — not even the repository owner — should be able to force-push.

Question: List the branch protection rules you need to enable.

Answer:

☑ Require a pull request before merging
  ☑ Require approvals: 1 (or 2 for higher-risk repos)
  ☑ Dismiss stale pull request approvals when new commits are pushed

☑ Require status checks to pass before merging
  ☑ Require branches to be up to date before merging
  Add: [your CI job names]

☑ Require signed commits

☑ Do not allow bypassing the above settings
  (This prevents repo admins from merging without review)

☑ Restrict who can push to matching branches
  (Limits direct pushes to specific teams if needed)

The key checkbox for your scenario is "Do not allow bypassing the above settings" — without this, repository admins can still force-push.

Section 4: Advanced Topics

Challenge 4.1 — Reusable Workflows

Scenario: You have 15 repositories that all need the same deploy workflow. Currently each repo has a copy of the deploy YAML.

Question: Describe the file location and uses: syntax to centralise this workflow in your organisation's .github repository.

Answer:

In my-org/.github:

.github/
└── workflows/
    └── deploy.yml   ← reusable workflow (must have 'on: workflow_call:')

Calling from any other repo:

jobs:
  deploy:
    uses: my-org/.github/.github/workflows/deploy.yml@main
    with:
      environment: production
      image_tag: ${{ needs.build.outputs.tag }}
    secrets:
      AWS_ROLE_ARN: ${{ secrets.PROD_AWS_ROLE_ARN }}

Pin to a tag (@v1) for production-critical workflows to prevent unexpected breakage from updates to the central template.

Challenge 4.2 — Deployment Environments

Question: You need staging to deploy automatically on every push to main, but production must require human approval and can only be triggered from the main branch. How do you configure this?

Answer:

• Staging environment: No required reviewers, no deployment branch restriction
• Production environment: Required reviewers (add team leads), deployment branch policy: main only, wait timer: 5 minutes

In the workflow:

deploy-staging:
  environment: staging     # No approval required — deploys immediately
  ...

deploy-production:
  environment: production  # Pauses for approval from required reviewers
  needs: deploy-staging
  ...

Scoring and Knowledge Map

Count how many challenges you answered correctly:

Areas to review if you struggled:

• Git commands: Advanced Git — Reflog and Cherry-Pick
• Actions syntax: GitHub Actions YAML Syntax and Triggers
• OIDC authentication: GitHub Actions Secrets and Environments
• Reusable workflows: GitHub Actions Reusable Workflows
• Branch protection: GitHub Branch Protection and Policies

Frequently Asked Questions

Q: What topics should I be confident with before a GitHub Mastery assessment?

A comprehensive test covers: Git fundamentals (branching, merging, rebasing, conflict resolution), GitHub flow and pull request workflows, Actions YAML syntax (triggers, jobs, steps, expressions), security features (Dependabot, secret scanning, CodeQL, branch protection), GitHub CLI usage, project management with Issues and Projects, and advanced topics like reusable workflows, environments with approvals, and OIDC authentication.

Q: What are the most commonly tested GitHub Actions concepts?

Expect questions on: the on: trigger syntax, how needs creates job dependencies, the difference between env and secrets, how outputs pass data between jobs, the purpose of actions/checkout, matrix builds, reusable workflows with workflow_call, and OIDC with id-token: write. Know the GitHub context objects (github.sha, github.ref, github.actor) and expression syntax ${{ }}.

Q: How do you prepare for hands-on GitHub certification exams?

GitHub offers the GitHub Foundations, GitHub Actions, and GitHub Advanced Security certifications. The most effective preparation is building real workflows: set up a CI pipeline with matrix testing, deploy to a staging environment with approvals, configure Dependabot and CodeQL, and write a reusable workflow. Hands-on practice beats memorising documentation — the exams test whether you can apply concepts, not just define them.

You have graduated from the GitHub Mastery Course — the future of collaboration is in your hands.