DevOps Foundations & the CDP Toolchain

Nine chapters make up this course's CDP exam blueprint, and this page is chapters 1 and 2 combined. It isn't new theory — it's the fluency gate every later chapter assumes you've already cleared. If you can't produce a blue-green rollout from memory, tell continuous delivery from continuous deployment in one breath, or write a five-line Ansible playbook without searching for the syntax, that's what this page is for. It is deliberately not a re-teach of What is DevSecOps? — read that first for the cultural case; come here for the vocabulary and the tool commands your hands need to already produce without thinking.

Why chapters 1–2 exist: a fluency gate, not new material

☺ Like you're 10: This chapter doesn't teach a new trick — it checks that the tricks you already know are fast enough to use without stopping to think.

The Certified DevSecOps Professional (CDP) is a hands-on, task-based exam — five live challenges against a real environment, no multiple choice, and no chatbot or AI assistant allowed during the window. That format changes what "studying" means for the first two chapters of this blueprint. Chapters 3 through 9 build new, gradable skill — writing a policy-as-code rule, triaging a real CVE, standing up compliance evidence. Chapters 1 and 2 build nothing new; they establish that the vocabulary and the commands underneath all of that are already reflexes, not lookups. A candidate who has to pause mid-challenge to remember what maxUnavailable does, or to search for Ansible's module syntax, is losing exam time to material this page exists to make automatic beforehand.

Two things live here as a result: the workflow vocabulary the exam uses without defining it (CAMS, CI/CD terms, deployment strategies), and the six tool categories the exam assumes your hands already know. Pair this page with the CDP study plan for where it sits in a full prep schedule, and the CDP exam guide for exam-day logistics.

CAMS, cold: the vocabulary every later chapter assumes

☺ Like you're 10: Four words describe how a healthy team works together — you need to recognize all four on sight, not puzzle them out.

What is DevSecOps? already covered why CAMS — Culture, Automation, Measurement, Sharing, coined by John Willis and Damon Edwards, with Lean added later by Jez Humble to make CALMS — matters for security specifically. This page isn't repeating that case. It's confirming you can name all four cold, because chapters 3 onward use them as shorthand without re-explaining them every time.

The DORA metrics under "Measurement" are worth having cold on their own — a task-based exam is exactly the kind of setting where a challenge might ask you to identify which of the four a given pipeline change would improve, without spelling out "this is a DORA question."

CI/CD terminology the exam won't stop to define

☺ Like you're 10: "Keep merging small changes," "prove it's safe to ship," and "actually ship it automatically" are three different promises — mixing them up is the single most common vocabulary mistake in this space.

Three terms get used almost interchangeably in casual conversation and mean three specifically different things on an exam:

Underneath those three sits the anatomy of a pipeline itself, and a handful of terms attached to it: a trunk-based workflow (short-lived branches, frequent merges to main, feature flags hiding incomplete work behind a toggle instead of a long-lived branch) versus GitFlow (long-lived develop/release/hotfix branches) — trunk-based is what CI/CD-mature pipelines and this exam both assume, because GitFlow's long-lived branches are exactly what slow, painful integration looks like. An artifact repository (a container registry like GHCR or ECR, or a package registry like Artifactory or Nexus) stores the one immutable, versioned output of a build so every later stage — staging, then production — deploys the exact same bytes, never a rebuild. And promotion means moving that one artifact through environments (dev → staging → prod), not building it fresh at each stop.

# .github/workflows/ci.yml — trunk-based, with the CD gate made explicit
name: build-test-deploy
on:
  push:
    branches: [main]           # trunk-based: everything lands on main
  pull_request:
    branches: [main]

jobs:
  build-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: docker build -t app:${{ github.sha }} .
      - run: docker run --rm app:${{ github.sha }} pytest

  deploy-staging:
    needs: build-test
    runs-on: ubuntu-latest
    environment: staging        # no required reviewer — deploys automatically
    steps:
      - run: ./deploy.sh staging app:${{ github.sha }}

  deploy-prod:
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment: production     # protected environment = a required reviewer
    steps:
      - run: ./deploy.sh production app:${{ github.sha }}

That environment: production line is the whole distinction made concrete: with a required reviewer configured on the production environment in the repo's settings, this is continuous delivery — every green build is provably deployable, but a human still presses go. Delete the reviewer requirement and the identical YAML becomes continuous deployment. Nothing about the pipeline's stages changes; only whether a human sits between "proven safe" and "live."

Deployment strategies: blue-green, canary, and rolling

☺ Like you're 10: All three answer the same two questions differently — how much of the new version do real users see right now, and how fast can you take it back?

Every deployment strategy is really an answer to two questions asked together: how much of the new version is exposed to real traffic at any given moment, and how fast can that exposure be reversed if it's broken. The three the exam expects you to distinguish on sight answer those questions very differently.

The baseline toolchain: six tools your hands already know

☺ Like you're 10: These aren't tools this course teaches from scratch — they're the ones you're expected to already reach for without reading the manual.

The CDP's live-environment format means the toolchain fluency bar is a command you can type, not a concept you can describe. This course covers several of these tools in depth elsewhere — for the security-specific ones, read the in-depth page; for the general DevOps ones (Git, Docker, a CI runner), the bar this page sets is the depth this course expects, because they're prerequisite skill rather than DevSecOps-specific material.

Two of those six deserve a real snippet, since "idempotent" and "compliance as code" are words candidates recognize far more often than they can produce on demand:

# site.yml — idempotent: running this a second time changes nothing
- hosts: web
  become: true
  tasks:
    - name: ensure nginx is installed
      apt: { name: nginx, state: present }
    - name: ensure nginx is running and enabled
      service: { name: nginx, state: started, enabled: true }

# controls/nginx_hardening.rb — InSpec: an assertion about system state, not a task that changes it
control 'nginx-01' do
  impact 1.0
  title 'nginx must not run as root'
  desc 'The worker process should drop privileges after startup.'
  describe file('/etc/nginx/nginx.conf') do
    its('content') { should_not match(/^user\s+root;/) }
  end
end

Notice the shape of the difference between those two: Ansible's playbook is imperative-ish but idempotent — it changes a system toward a state, safely, however many times it runs. InSpec's control is purely declarative and read-only — it asserts a state and reports pass/fail, changing nothing. Chapter 7 (Infrastructure as Code Hardening) and chapter 8 (Compliance as Code at Scale) build directly on that distinction — Ansible is how you enforce a hardened baseline, InSpec is how you prove it's still true later, and confusing the two roles is a fast way to lose exam-challenge time to the wrong tool.

That's the whole gate: vocabulary and tool commands, fast and automatic. Chapter 3 starts building graded skill on top of it — Secure SDLC Gates & the DevSecOps Maturity Model is next. If any command in the toolchain table above needed a second thought, drill it against the command & tool reference and the Know It Cold page before moving on, then check the fluency against Mock Exam · Set 1. Ready to apply it against a real pipeline instead of a page? The capstone lab track starts from the same baseline this page assumes.