I85PREP
⌘ K
JNCIA-DevOps study materials
JNCIA-DevOps study resources

JNCIA-DevOps: DevOps Culture and Practices

JNCIA-DevOps · Work through your exam, one topic at a time.

All guide sections

DevOps Culture and Practices

DevOps Culture and Practices

This domain tests the vocabulary and behaviors that make automation sustainable: CALMS, feedback loops, version control, collaboration, and blameless learning. Questions often probe the difference between a toolchain and an operating culture.

Core rules

  • CALMS stands for Culture, Automation, Lean, Measurement, and Sharing. Culture is the foundation; tools alone do not create DevOps.
  • Small, frequent changes reduce risk. Batch size is a risk multiplier: a large config change is harder to review, test, and roll back than several small ones.
  • Everything that defines infrastructure belongs in version control. Git commits, branches, pull requests, and code review create an audit trail and a peer-review gate.
  • CI/CD depends on feedback: automated tests, peer review, monitoring, and post-incident review. Blameless postmortems focus on system causes, not individual blame.
  • DevOps is shared ownership of outcomes, with operations concerns such as reliability, security, and rollback designed in early.

Worked example

A network team wants to change a BGP policy used by 40 routers. Instead of editing each device, they:

  1. Create branch bgp-policy-v2.
  2. Change the Jinja2 template and YAML variables in the repository.
  3. Open a pull request; a peer reviews the rendered diff and the rollback plan.
  4. Let CI render configs and run commit_check against a lab device.
  5. Merge, deploy in canary batches, monitor, and record the change.

Reasoning: the branch isolates work, the pull request creates review and history, CI catches errors before production, and canary deployment limits blast radius. The artifact is reproducible because template, data, and review are all versioned.

Traps

  • Treating DevOps as a tool purchase rather than a culture and feedback system.
  • Skipping code review because 'it is only a config change.'
  • Using blame in postmortems, which suppresses reporting.
  • Confusing continuous delivery (always deployable) with continuous deployment (every change auto-released).