Gate config changes with CI
Network changes shouldn't merge unreviewed. Write a CI workflow that checks out the repo and validates the configs on every pull request, the GitOps guardrail for network automation.
Scenario
Your team keeps network configs in Git. Today anyone can merge a change without it being checked, and
broken configs slip into main. Add a CI guardrail: a workflow that validates the configs on every
pull request, so a bad change fails the check before it merges.
Your job
Edit ci.yml (a GitHub Actions workflow) so that it:
- triggers on pull requests,
- runs on an Ubuntu runner, and
- checks out the repo and runs a validation step (validate / lint / test).
Example shape
on:
pull_request:
jobs:
validate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: make validate
How it's graded
This one is graded structurally: we check the shape of the pipeline (trigger, runner, checkout + validate step), not by running it. (Real execution isn't part of the free in-browser lab.)
What "done" looks like
A workflow that fires on pull_request, uses an Ubuntu runner, and has a job that checks out the code
and runs a validation command.
Teaches: CI as a merge gate, the GitOps pattern that keeps infrastructure-as-code and network automation safe to ship.
What gets checked
Your solution is verified against each of these:
- The workflow runs on pull_request
- A job runs on an Ubuntu runner
- The job checks out the repo and runs a validate/lint/test step
Solve it in your browser
No setup, no install. Write your solution in the editor and hit Check. The in-house engine renders and grades it instantly, then issues your proof the moment every check passes.
Solve in browser →Prefer your own lab?
- Build the fix locally. New to the tooling? See setting up your lab.
- Push your topology file, device configs, and any playbooks to a public repo (GitHub or GitLab).
- Submit the repo link. We review it by hand, confirm it works, and issue your proof page.