⚙️ Reading Config Files
3 exercises — read YAML and configuration files and describe them in plain English. Essential for documentation, onboarding, and code reviews.
0 / 3 completed
Describing config files — key phrases
- "This setting tells the application to listen on / use / enable…"
- "This value is read from an environment variable, so it can differ between environments."
- "The service will restart automatically / wait for X before starting…"
- "Data is persisted in a named volume, meaning it survives container restarts."
- "The workflow triggers when code is pushed to / a pull request is opened against…"
1 / 3
Read this CI/CD pipeline configuration. Which plain-English description is most accurate?
name: Deploy to Production
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install dependencies
run: npm ci
- name: Run tests
run: npm test
- name: Build
run: npm run build
- name: Deploy
run: ./scripts/deploy.sh
env:
SSH_KEY: ${{ secrets.SSH_KEY }}Option B is the most complete and accurate description. It identifies: (1) the tool (GitHub Actions), (2) the trigger (push to main branch), (3) the runtime (Ubuntu), (4) the sequential steps in plain English, and (5) explains the secret mechanism ("SSH key from repository secrets"). Option A omits the trigger, deployment step, and the purpose. Option C misidentifies the file type as "a deployment script" — it is a workflow file. Option D is close but "installs npm" is wrong —
npm ci installs project dependencies, not npm itself. When describing CI/CD configs, always clarify: what triggers it, what environment it uses, and what each step achieves in business terms.