The Baseline You Need First

The Certified DevSecOps Professional does not teach you Linux, Git, Docker, HTTP, or cloud IAM. It assumes them, then hands you five broken systems and starts a clock. Practical DevSecOps' own stated prerequisite is deliberately modest — basic Linux command knowledge and a foundational grasp of application security concepts such as the OWASP Top 10, with no prior Dev or DevOps experience described as necessary. Every candidate who has published a first-hand account of sitting the exam describes a materially higher effective floor. This page is that effective floor, written out concretely: what each prerequisite actually has to mean when the exam is hands-on, how to check whether you really have it, and which page of this course to go to for each gap you find. It ends with a two-tier self-test and a hard question set with a full answer key, so you find the gaps here rather than at hour four of six.

Two prerequisite lists, and the gap between them

☺ Like you're 10: The people selling the course say you need very little. The people who have actually taken the exam say you need more. Both are telling the truth about different things.

Practical DevSecOps publishes a prerequisite line on the CDP's own page, and it is a short one: basic Linux command knowledge, a foundational understanding of application security concepts like the OWASP Top 10, and — stated explicitly — no prior experience with Dev or DevOps tools required. Read on its own, that is an encouraging sentence. It is also, in a narrow sense, accurate: the vendor's package bundles a large set of guided browser-based lab exercises, and a guided lab genuinely can walk someone through their first docker build.

Now read what candidates wrote afterwards. Sanjeev Jaiswal, reviewing the course and exam in 2020, recommended arriving with Docker, GitLab CI/CD, SSH and DevSecOps basics already in hand. Vinit Patil, writing in 2023, listed the surface his exam actually touched: GitLab CI/CD, SCA, SAST and DAST tooling, Docker, Ansible, InSpec, Linux hardening, and DefectDojo. And Tess Sluijter, in 2021, drew the sharpest line of all — she declined to describe the exam's contents, citing the non-disclosure agreement, but did say to expect scanning tools other than the ones used in the labs, more advanced features of the tools that were used, and programming languages the labs never covered. She compared the required mindset to the OSCP: the concepts match what you were taught, and you will still have to research on the spot.

That is the gap this page exists to close, and it has a clean explanation. The vendor's prerequisite line is a true statement about the course. It is a weaker statement about the exam. A guided lab hands you a working environment and a set of instructions; a graded challenge hands you a broken environment and a goal. The first tolerates a thin baseline because the scaffolding carries you. The second removes the scaffolding, changes the tools, and starts a clock.

Why the clock makes this a speed floor, not a reading floor

☺ Like you're 10: Knowing a thing and being able to do a thing fast are different. This exam only measures the second one.

The CDP's published shape is five challenges inside a six-hour window, scored out of 100 with 80 required to pass, followed by a separate 24-hour window to submit a written report. That is the whole of the arithmetic you need, and it is unforgiving: roughly seventy minutes per challenge, and the evidence you will need for the report has to be captured inside the same six hours, because the environment does not wait for you. Divide seventy minutes by the number of times you would normally open a browser tab to check a flag, and you have the argument for this entire page.

The consequence for your baseline is direct, and it is worth stating plainly before you read another section. Najim describes burning roughly three and a half hours on his first challenge and finishing the remainder under pressure; Patil planned a little over two hours per challenge and actually spent four on the first. Both of those stories end in a pass — because they had twelve hours. Under a six-hour clock, four hours on challenge one is the entire exam gone, and the only thing that reliably prevents it is not having to think about the substrate. If you are recalling chmod's octal digits, or working out why your YAML will not parse, or reading a manual page for jq, you are spending challenge-one time on material this page exists to make automatic.

How this page differs from the blueprint's first chapter

There is a page in this course that sounds like this one and is not: DevOps Foundations & the CDP Toolchain, which combines chapters 1 and 2 of the exam blueprint. That page is a fluency gate on the exam's specific toolchain and vocabulary — CAMS, continuous delivery versus continuous deployment, blue-green against canary against rolling, and the six tool categories the exam expects your hands to know. It assumes you can already drive a computer and teaches you the words the exam uses.

This page sits one layer below that. It is about the general skill the blueprint page itself takes for granted: not "which Ansible module makes this idempotent" but "can you read the file it wrote, own it correctly, and prove the service actually restarted." Read this one first if any row in the table above made you uncomfortable; read the blueprint chapter first if none of them did.

The map — what to check, and where to fix it

☺ Like you're 10: Eight areas. Skim this table, spot the ones that make you wince, and read those sections properly.

Every section below carries a one-line ⚖ Why the CDP leans on it marker, so you can triage before you read. Here is the whole map at a glance:

Linux and the shell

☺ Like you're 10: The exam happens inside a terminal. If the terminal itself is the hard part, nothing else gets a fair chance.

⚖ Why the CDP leans on it — Critical. This is the one prerequisite Practical DevSecOps names explicitly, and "basic" is doing a lot of work in that sentence. Patil's account names Linux hardening among the topics his exam touched, and you cannot harden a host you cannot read.

Here is a usable definition of the real bar, because "basic Linux" is not one. You should be able to sit down at an unfamiliar Linux host over SSH and, without documentation, answer four questions: what is running, as whom, listening on what, and what changed. Everything below is in service of those four.

Files, ownership and permissions

Permissions are where most security findings physically live, and where most candidates are slowest. You need the octal notation as a reflex, not a derivation — 644 and 600 and 755 should read as words, and chmod 777 should make you flinch before you have finished typing it. You also need the three things beyond the basic bits that scanners and hardening benchmarks care about: the setuid bit, world-writable files, and ownership drift after a deployment writes something as the wrong user.

# read a permission line without translating it in your head
ls -l /etc/shadow          # -rw-r----- root shadow  → owner rw, group r, world nothing
stat -c '%a %U %G %n' /etc/ssh/sshd_config

# the three hardening greps you should not have to look up
find / -perm -4000 -type f 2>/dev/null          # setuid binaries
find / -xdev -type f -perm -0002 2>/dev/null    # world-writable files
find /home -name '.*history' -o -name 'id_rsa'  # things that should not be readable

chmod 600 ~/.ssh/id_ed25519      # the ssh client refuses a private key any wider
chown -R app:app /srv/app        # ownership drift after a deploy is a real finding
umask 027                        # what new files inherit

Processes, services and logs

Nearly every "it does not work" moment in a hands-on exam resolves to one of three things: the service is not running, it is running as the wrong user, or it is not listening where you think. Being able to check all three in under ten seconds is worth more than any single tool flag you will memorise.

# what is running, and as whom
systemctl status nginx
ps -eo user,pid,cmd --sort=user | grep -v '\[' | head -30
id www-data

# what is listening
ss -tlnp                       # TCP, listening, numeric, with process
curl -sS -o /dev/null -w '%{http_code}\n' http://localhost:8080/

# what changed, and why it broke
journalctl -u nginx --since '10 min ago' --no-pager
journalctl -xe --no-pager | tail -40
systemctl daemon-reload && systemctl restart nginx && systemctl is-active nginx

Text surgery, transfer and session survival

Scanner output is text, log files are text, and configuration is text. The four tools below cover almost all of it, and the fifth entry on this list is the one nobody thinks to practise until they lose two hours of work to a dropped SSH connection.

# find the needle
grep -rn --include='*.py' -E '(password|secret|api[_-]?key)\s*=' .
grep -c 'CRITICAL' scan.txt

# reshape a line
awk -F: '$3 >= 1000 {print $1, $7}' /etc/passwd     # real users and their shells
sed -i.bak 's/^PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd_config
cut -d, -f1,3 findings.csv | sort | uniq -c | sort -rn

# move things around
scp -i key.pem report.md user@host:/tmp/
tar -czf evidence.tar.gz screenshots/ scan-output/
base64 -w0 small.png                                # when scp is not available

# survive a six-hour session
tmux new -s cdp        # detach with ctrl-b d, reattach with tmux attach -t cdp
script -a ~/cdp-session.log    # record everything you type and everything you see

Git, and why history is the security surface

☺ Like you're 10: Deleting a secret from a file does not delete it from Git. Git remembers everything, forever, on purpose.

⚖ Why the CDP leans on it — High. Challenges start from a repository, pipeline configuration lives in one, and the secrets-detection category is fundamentally a question about history rather than about the current checkout.

You do not need to be a Git expert. You need to hold one model in your head clearly enough that a whole category of findings stops being surprising: a commit is an immutable snapshot, a branch is just a moving pointer to one, and nothing you commit is ever really removed by a later commit that deletes it. That single fact explains why gitleaks and TruffleHog scan history rather than the working tree, why "I removed the key in the next commit" is not a remediation, and why the correct answer to a leaked credential is always rotate first — history rewriting is cleanup, not containment. The full treatment is in secrets management; the drill is in the leaked-credential triage drill.

# the shape of the repository, fast
git log --oneline --graph --decorate -20
git status --short --branch
git diff HEAD~1 -- .gitlab-ci.yml

# the pickaxe: every commit where this string appeared or disappeared
git log -p -S 'AKIA' --all
git log --all --full-history -- 'config/secrets.yml'

# search every blob ever committed, not just the checkout
git rev-list --all | xargs git grep -n 'BEGIN RSA PRIVATE KEY' 2>/dev/null

# what a specific commit actually did
git show a1b2c3d --stat
git blame -L 40,60 src/auth.py

One practical note from a published account rather than from theory. Sluijter's advice to CDP candidates was to clone the exam-related repository locally and pull updates regularly rather than relying on the browser view — a reminder that in a hands-on environment, your comfort with the plain command-line client is what you actually get to use. If your Git fluency currently lives entirely inside a graphical client or an IDE panel, that is a gap worth closing before you sit anything hands-on.

Pipeline YAML — the gate is the exit code

☺ Like you're 10: A scanner that runs and never stops a bad build is not a guard. It is a spectator with a clipboard.

⚖ Why the CDP leans on it — Critical. "Wire this scanner into the pipeline so it actually blocks" is the most repeated shape of task in this whole discipline, and it is a YAML-authoring skill before it is a security skill.

The blueprint's chapter 1 covers CI/CD terminology; this section covers the mechanics underneath it. Whichever platform you meet, five concepts carry everything: a stage orders work, a job is a unit that runs somewhere, an image decides what tools that job has available, artifacts carry files between jobs and out to you, and — the one that matters most — the job's exit code is the gate. A job that always exits zero cannot fail a build, no matter what it printed.

GitLab CI is the platform named most often across published CDP accounts, and Radzuan's description of the report he submitted specifically mentions including GitLab CI/CD YAML as evidence. Confirm the current lab platform against the vendor's syllabus rather than assuming, but learn the mechanics in a way that transfers: the names differ between platforms, the five concepts do not.

# .gitlab-ci.yml — a scanner wired as a real gate, not a spectator
stages: [build, test, security]

sca:
  stage: security
  image: aquasec/trivy:latest
  script:
    # --exit-code 1 is the entire difference between a gate and a report
    - trivy fs --exit-code 1 --severity HIGH,CRITICAL --format json -o trivy.json .
  artifacts:
    when: always          # keep the evidence even when the job fails
    paths: [trivy.json]
    expire_in: 1 week
  allow_failure: false    # the default, and worth writing down deliberately

# the same idea in GitHub Actions — different nouns, identical mechanics
jobs:
  sast:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: semgrep
        run: |
          docker run --rm -v "$PWD:/src" semgrep/semgrep \
            semgrep --config=auto --error --json --output /src/semgrep.json /src
      - uses: actions/upload-artifact@v4
        if: always()
        with: { name: semgrep, path: semgrep.json }

Two more mechanics are worth having cold because they cost time when they surprise you. Secrets come from the platform's secret store, injected as masked variables — never from the YAML file, which is committed, and never from a build argument, which lands in the image history. And running Docker inside a CI job is either a mounted socket or a Docker-in-Docker service, and the mounted-socket version hands the job root on the host it runs on. That trade-off is covered properly in security in CI/CD; you only need to recognise it on sight.

Containers, from the outside in

☺ Like you're 10: Almost every security tool you will use comes packaged as a container. If containers are unfamiliar, every tool is unfamiliar too.

⚖ Why the CDP leans on it — Critical. Not because the CDP is a container-security exam — Practical DevSecOps sells container and Kubernetes security as separate credentials in the same family, which suggests the CDP's centre of gravity is the pipeline rather than the cluster; check the current syllabus rather than taking that as settled. It is critical because containers are the delivery mechanism for the toolchain. Trivy, Semgrep, gitleaks, ZAP and Conftest are all things you will most often run as docker run.

There is one command shape that recurs so often it is worth committing to muscle memory on its own, because it is how you run any containerised scanner against code that lives on your machine:

# the canonical shape: bind-mount the work directory, scan it, throw the container away
docker run --rm -v "$PWD:/src" -w /src <scanner-image> <scanner-args> .

# three real instances of exactly that shape
docker run --rm -v "$PWD:/src" -w /src aquasec/trivy:latest fs --severity HIGH,CRITICAL .
docker run --rm -v "$PWD:/repo" zricethezav/gitleaks:latest detect --source /repo -v
docker run --rm -v "$PWD:/src" semgrep/semgrep semgrep --config=auto /src

Beyond that, the concepts you need are few and they are all about identity and reproducibility rather than about orchestration:

# the shape you should be able to write from a blank file
FROM golang:1.22 AS build
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -o /out/app ./cmd/app

FROM gcr.io/distroless/static-debian12@sha256:...   # pinned by digest, not by tag
COPY --from=build /out/app /app
USER 65532:65532                                     # nonroot, numerically
ENTRYPOINT ["/app"]

The full treatment — signing, provenance, SBOMs, dependency confusion — is Pip and Benny's territory in container & supply-chain security, with the runtime side in container runtime security. For this page, the bar is only that none of the six rows above requires a lookup.

HTTP and the web-application model

☺ Like you're 10: A dynamic scanner tells you what a website did when it was poked. If you cannot read the poke or the reply, the report is just a list of scary words.

⚖ Why the CDP leans on it — High. Dynamic analysis is one of the categories the exam guide expects to see represented, and the ZAP baseline run is named in this course's own toolchain. A DAST tool's entire output is a description of HTTP behaviour.

The fluency test here is simple: could you reproduce a scanner's finding by hand with curl? If yes, you can triage it, judge whether it is a false positive, and write it up. If no, you are relaying a tool's opinion, which is exactly what a grader is trying to distinguish you from.

# see the whole exchange, not just the body
curl -isS https://target.example/login | head -30

# just the headers a security scanner will comment on
curl -sS -D - -o /dev/null https://target.example/ \
  | grep -iE 'strict-transport|content-security-policy|x-frame|set-cookie|server'

# reproduce an authenticated finding by hand
curl -sS -X POST https://target.example/api/login \
  -H 'Content-Type: application/json' \
  -d '{"user":"alice","pass":"..."}' -c jar.txt
curl -sS -b jar.txt https://target.example/api/orders/1042    # now try 1043

# is this endpoint reachable at all, and from where?
curl -sS -o /dev/null -w '%{http_code} %{time_total}s %{url_effective}\n' -L http://target.example/

Four clusters of knowledge sit behind those commands, and all four show up in scanner findings:

• The response headers that are findings in themselves — a missing Strict-Transport-Security, an absent or permissive Content-Security-Policy, a Set-Cookie without Secure, HttpOnly or a sane SameSite, an over-broad CORS Access-Control-Allow-Origin, a Server banner advertising an exact version. These are the bulk of any baseline DAST run and they are all configuration, not code — which is precisely why static analysis cannot see them.
• How the application knows who you are — session cookie, bearer token, JWT, basic auth, or an OAuth-issued token. You do not need to implement any of them; you need to be able to capture one, replay it, and reason about what happens when you replay it as somebody else. That last move is how broken access control is demonstrated, and broken access control is the category that automated scanners are worst at and graders like most.
• Status codes as evidence — a 403 where you expected 200 proves an authorisation control exists; a 200 where you expected 403 is a finding you can write up in one line. A 302 to a login page is not the same as a denial, and treating it as one is a classic false-negative.
• The proxy model — that ZAP and Burp work by sitting between client and server, and that "the scanner could not reach the app" is nearly always a proxy, TLS-trust or network-path problem rather than a scanner defect.

The category-by-category treatment lives in SAST, DAST & SCA, the API-specific version in API security in depth.

The application-security vocabulary

☺ Like you're 10: There are five different words for "this software has a problem," and they mean genuinely different things. Mixing them up makes your write-up wrong even when your fix is right.

⚖ Why the CDP leans on it — Critical. This is the half of the vendor's own prerequisite line that carries real weight, and it is the vocabulary your written report will be graded in.

The five identifiers, and what each one is not

The OWASP Top 10, and the honest caveat about editions

The OWASP Top 10 is a broad awareness document, revised on a multi-year cycle. The 2021 edition is the one most tooling, compliance mappings and training material have historically been built against, and its ten categories are worth being able to name and — more importantly — recognise in code:

The deeper point is that the Top 10 is a vocabulary, not a checklist. It exists so that you and a grader can name the same thing the same way. Being able to look at a diff and say "that is injection because untrusted input reaches an interpreter, and the fix is parameterisation, not escaping" is the actual skill — see secure coding patterns for the fixes themselves.

Cloud IAM and identity

☺ Like you're 10: Who is allowed to do what, and how does a robot prove it is the robot it says it is?

⚖ Why the CDP leans on it — Medium–high, and hard to pin down precisely. How deep the CDP goes into any one cloud provider is not something the vendor publishes a domain weighting for, and this course's exam guide is explicit that no official percentage breakdown exists. What is not in doubt is that pipeline credentials have to come from somewhere, and IAM is where they come from and where they leak from.

The vocabulary is broadly consistent across providers even though the nouns differ, and you should be able to move between them without stalling:

Four things matter more than the naming:

• Least privilege is a list of actions, not an attitude. "Action": "s3:*" and "Resource": "*" are the two strings a reviewer scans for first, and a wildcard on either is a finding you can name in one sentence.
• A role has two policies and people conflate them. The permission policy says what the role may do; the trust policy says who may assume it. An over-broad trust policy is the more dangerous of the two and the less frequently reviewed.
• The right way for a pipeline to authenticate is federation, not a stored key. The CI platform presents a short-lived OIDC token, the cloud exchanges it for temporary credentials, and there is no long-lived secret to leak. Long-lived access keys pasted into CI variables are the pattern this replaces — the reasoning is in workload identity & pipeline IAM.
• Instance metadata is a credential endpoint. A server-side request forgery that reaches the metadata service can read the machine's role credentials, which is the mechanism behind the Capital One breach. Session-oriented metadata (IMDSv2 on AWS, and its equivalents elsewhere) exists specifically to break that chain, and "enforce the session-oriented version" is a remediation you should be able to state without hedging.

Posture scanning across a whole account — Prowler, ScoutSuite and the rest — is Sol's territory. For this page, the bar is that an IAM policy document is something you can read at a glance rather than something you have to decode.

YAML, JSON and jq — the format layer nobody lists

☺ Like you're 10: Everything you edit is YAML and everything a scanner gives back is JSON. Being fast at both is a real skill, and nobody puts it on a prerequisite list.

⚖ Why the CDP leans on it — High, and invisible. Pipeline config, policy config, Ansible, InSpec profiles and Kubernetes manifests are YAML. Scanner output is JSON, SARIF or XML. Radzuan's account of the report he submitted explicitly describes including configuration files and machine-readable output alongside the screenshots — so the format layer is not just how you work, it is part of what gets graded.

The YAML failures that cost minutes

YAML is indentation-sensitive and the error messages are unhelpful, which is a bad combination under a clock. Four failure modes account for most of it:

• Tabs are illegal for indentation. If your editor inserts them, YAML will not parse, and the message will not say "tab."
• Unquoted no, yes, on, off and y may be read as booleans in parsers following the older YAML 1.1 rules — the reason a country code of NO can silently become false. Quote anything that is meant to be a string and happens to look like something else, and quote version numbers too, since 1.10 is a number and 1.10.2 is not.
• Block scalars differ: | keeps newlines, > folds them into spaces. Using the wrong one in a multi-line script: block produces one enormous shell command.
• A list of maps needs its dashes lined up with the key, and a stray extra space turns a sibling into a child. This is the single most common "why is my pipeline not seeing this job" cause.

# validate before you push — three seconds, saves a pipeline round trip
python3 -c 'import sys,yaml; yaml.safe_load(open(sys.argv[1]))' .gitlab-ci.yml && echo OK
yamllint -d relaxed .gitlab-ci.yml
docker run --rm -v "$PWD:/w" -w /w mikefarah/yq '.stages' .gitlab-ci.yml

jq, and turning scanner noise into a report table

This is the highest-leverage single skill in this section. A raw scanner JSON file is unreadable; three lines of jq turn it into the summary table your report needs, and doing that live is far faster than screenshotting a wall of terminal output and hoping.

# Trivy: every HIGH and CRITICAL, as a tab-separated table
jq -r '.Results[]?.Vulnerabilities[]?
       | select(.Severity=="HIGH" or .Severity=="CRITICAL")
       | [.VulnerabilityID, .PkgName, .InstalledVersion, .FixedVersion // "none", .Severity]
       | @tsv' trivy.json

# ...and the counts, which is what a summary paragraph actually needs
jq -r '[.Results[]?.Vulnerabilities[]?.Severity] | group_by(.)
       | map({sev: .[0], n: length}) | .[] | "\(.sev)\t\(.n)"' trivy.json

# Semgrep: rule, file and line, sorted
jq -r '.results[] | [.check_id, .path, (.start.line|tostring)] | @tsv' semgrep.json | sort

# SARIF is a shared format across many tools — learn this shape once
jq -r '.runs[].results[]
       | [.ruleId, .level, .locations[0].physicalLocation.artifactLocation.uri] | @tsv' out.sarif

# anything, straight into the report as a CSV
jq -r '.Results[]?.Vulnerabilities[]? | [.VulnerabilityID,.PkgName,.Severity] | @csv' trivy.json > findings.csv

The prerequisite nobody calls a prerequisite: writing evidence

☺ Like you're 10: Fixing it is only half the exam. Proving you fixed it — after the computer is switched off — is the other half.

⚖ Why the CDP leans on it — Critical, and structurally different from every other exam most candidates have sat. The CDP's published shape includes a separate window after the challenges close for submitting a written report. This is not paperwork appended to a score you already earned; it is part of how the work is assessed.

Three published accounts converge on the same warning, from different angles. Mohammed's review contains the sharpest single operational note anyone has written about this exam: the lab environment is gone when your window closes, so take backups, screenshots and saved output as you go rather than planning to collect them afterwards. Sluijter's advice was the same instruction as a habit — document while you work, not at the end. And Radzuan described what the report itself needed to contain: step-by-step instructions, the configuration files themselves, screenshots, and machine-readable scanner output. Pereira's contribution is the preparation side of it — build your own cheatsheets of commands and snippets before the exam, so the writing during it is assembly rather than composition.

The reason this belongs on a baseline page rather than an exam-day page is that it cannot be switched on for six hours. It is a habit, and habits need weeks. Start now, in your own lab work, with a four-line entry written the moment each thing is fixed:

### Finding 2 — SCA gate does not block on CRITICAL

**What was wrong.** The `sca` job ran Trivy and always exited 0, so a
CRITICAL in the base image did not fail the pipeline.

**How I found it.** `git show HEAD:.gitlab-ci.yml` — no `--exit-code`,
and `allow_failure: true` on the job.

**What I changed.** `.gitlab-ci.yml`, `sca` job:
`trivy fs --exit-code 1 --severity HIGH,CRITICAL .` and removed
`allow_failure`. Full file at `evidence/gitlab-ci.after.yml`.

**How I proved it.** Pushed a commit reintroducing the vulnerable
dependency; pipeline failed at the `security` stage.
Job log: `evidence/pipeline-failed.txt`. Screenshot: `evidence/02-red.png`.
Re-ran after the fix: passed. Log: `evidence/pipeline-green.txt`.

What is not on this floor

☺ Like you're 10: A list of things people worry about that are not actually the problem — so you can stop spending time on them.

A baseline page that keeps adding requirements stops being useful. Four things get worried about and should not be:

• Production-grade programming. You need to read code in several languages well enough to see where untrusted input reaches something dangerous, and to apply a fix pattern. You do not need to build applications. Sluijter's warning that the exam may use languages the labs did not is a warning about reading breadth, not about writing depth — a competent reader of Python, JavaScript and one JVM or Go codebase can triage almost anything, because vulnerability patterns rhyme across syntax.
• Exploit development. The OSCP comparison Sluijter drew is about mindset — being willing to research something unfamiliar mid-task — not about writing exploits. Nothing in the published accounts describes needing offensive tooling skill of that kind. If you want the offensive perspective anyway, offensive security for DevSecOps is there, but do not treat it as a gate.
• Deep Kubernetes. Practical DevSecOps offers container and Kubernetes security as separate credentials in the same family, which points to the CDP being pipeline-centred. Treat that as a reasonable inference and confirm it against the current syllabus rather than as a settled fact — and if your own work is cluster-heavy, the Kubernetes security deep dive and the CKS are the right places for it, not this page.
• Memorising CVE numbers, tool version numbers or the vendor's slide decks. Petrosyan's critical review of the CDP describes the material as heavily operational and light on theory. Whatever else that says about the course, it tells you something useful about preparation: the exam rewards what you can do, and time spent memorising catalogue numbers is time not spent at a keyboard.

Score yourself — the baseline self-test

☺ Like you're 10: Tick only what you could genuinely do right now, with no browser tab open. The empty boxes are the useful part.

Two tiers, and they measure different things. Tier 1 is recognition — can you explain it, spot it, name it correctly in a report. Tier 2 is the keyboard floor, and every item has an implied stopwatch, because on a hands-on exam everything does. Read each item as a literal instruction. Your progress is saved in this browser.

Tier 1 — recognition

• ① System & shell
• Read a permission line like -rw-r----- and give its octal, without counting on your fingers
• Explain why a fix that works now can fail after a restart, and name the three usual causes
• Say what the setuid bit does and why hardening benchmarks care about it
• Name the four questions to answer on an unfamiliar host: what is running, as whom, listening where, what changed
• ② Git & the supply chain
• Explain why deleting a secret in a later commit does not remediate it
• State the correct remediation order for a leaked credential, and say why rewriting history is not first
• Explain the difference between an image tag and a digest, and why scanning :latest proves little
• Say why a file deleted in a later Dockerfile layer is still in the image
• ③ Pipelines
• Name the five concepts that carry any CI platform: stage, job, image, artifacts, exit code
• Give three distinct ways a scanner job can run and still fail to gate anything
• Explain why a secret belongs in the platform's secret store rather than in the YAML or a build argument
• Say what mounting the Docker socket into a CI job actually grants
• ④ AppSec & the web
• Distinguish CWE, CVE, CVSS, EPSS and KEV in one sentence each
• Explain why a CVSS score is not a risk rating, with a concrete example in each direction
• Name at least eight of the ten OWASP Top 10 categories — and say which edition you are naming
• List four response headers a baseline DAST run will comment on, and what each protects against
• Explain why static analysis structurally cannot find a missing security header
• ⑤ Identity & formats
• Explain the difference between a role's permission policy and its trust policy, and which is more dangerous when over-broad
• Describe how OIDC federation removes the need for a long-lived cloud key in CI
• Say why instance metadata plus SSRF is a credential-theft chain, and what breaks it
• Name three YAML constructs that silently change meaning: tabs, unquoted no, and | versus >
• ⑥ Evidence
• State what happens to your scrollback, screenshots and lab access when the challenge window closes
• Name the four parts of a usable evidence entry: what was wrong, how found, what changed, how proved

Tier 2 — the keyboard floor

• ⑦ On a host, no documentation
• Find every setuid binary and every world-writable file on a box, from memory
• Identify which process holds a port, stop it cleanly, and prove the port is free
• Disable SSH password authentication and prove it from a fresh connection
• Answer "when did this service last restart, and why" from the journal alone
• Start a detachable session and a session recording before you begin work — without thinking about it
• ⑧ Repository & pipeline
• Search every commit ever made for a string, not just the current checkout
• Add a scanner job to a pipeline file that genuinely fails the build, in under five minutes
• Make that job keep its output as an artifact even when it fails
• Validate a YAML file locally before pushing, rather than learning from a red pipeline
• ⑨ Containers & scanners
• Run any containerised scanner against your working directory using the bind-mount shape, from memory
• Write a multi-stage Dockerfile with a non-root USER and a digest-pinned base, from a blank file
• Reproduce a DAST finding by hand with curl, including replaying a session cookie
• ⑩ Output & evidence
• Turn a scanner's JSON into a severity-filtered table with jq, first attempt
• Produce a per-severity count from that same file without opening it in an editor
• Extract rule, file and line from a SARIF file without looking up its structure
• Write the four-line evidence entry for a fix in under three minutes, with the artefacts already saved
• Finish every task with an explicit verification command rather than an assumption

What your score means

Count the unticked boxes in each tier separately. The gaps are the signal; the totals are not comparable across tiers.

Ten questions a checklist cannot ask

☺ Like you're 10: Ticking a box is easy to fake, even to yourself. Answering out loud is not.

Answer each of these out loud, from memory, in a couple of sentences, before opening the key. The point is not to score them; it is to notice which ones came out thin. A thin answer here is a slow challenge there.

Closing the gaps you found

☺ Like you're 10: You now have a short list of wobbly bits. Fix those. Do not start over from the beginning.

Resist re-reading everything. You have a specific list, and specific lists are closed with specific drills — a recognition gap and a keyboard gap need genuinely different treatment.

Recognition gaps: explain it, then check yourself

Take the unticked Tier 1 item, explain it out loud from memory in one paragraph, then read the section above and mark what you got thin. That retrieval loop is the entire method. The glossary and flashcards handle the vocabulary items you keep dropping, and the self-check will tell you honestly whether the explanation stuck.

Keyboard gaps: reps against a clock, on something real

Speed is built one way only. Take the unticked Tier 2 item, do it ten times on a throwaway VM or container, and time the tenth. Then stop drilling in the abstract and put it in service of something: the capstone lab track takes a single pipeline through threat modeling, SAST and secrets, an SCA gate, container hardening and signing, IaC policy, a DAST run and compliance evidence — every motion on this page appears in it, attached to a reason. The leaked-credential triage, broken Terraform and dependency fire drills are the shorter, sharper version.

Where each area is actually taught

Then, and only then, start the exam material

Once these boxes are ticked, everything downstream gets cheaper — because an SCA gate becomes "a container, a flag and an exit code," a hardening task becomes "a config file, a reload and a proof," and a report becomes "the four lines I already wrote, tidied." That is the whole return on this work: not new knowledge, but the disappearance of the constant background translation cost that makes a six-hour window feel like four. The next stop is blueprint chapter 1, and the schedule that holds it all together is the CDP study plan.