Field Notes — What Test-Takers Report

Every other page on this site teaches you the material or the method. This one asks a narrower question: what did individual people who actually sat the exam choose to publish afterwards? For the Certified DevSecOps Professional (CDP) the answer is unusually generous — this course found nine real, named, first-hand write-ups spanning 2020 to 2024, several of them on the authors' own domains rather than on a content farm. That is a thick record by certification standards, and most of it is genuinely useful. But it comes with a single, load-bearing defect that this page has to put before everything else: every single one of those accounts that states a duration describes a twelve-hour hands-on exam, and Practical DevSecOps' own current pages say six. Seven of the nine state one; the other two, to their credit, published no format numbers at all. The format was shortened after mid-2024, and nobody went back to edit the blog posts. So read these accounts for technique, which transfers completely — and never for the clock, which is now off by a factor of two in every one of them that mentions it.

Part One — a thick record with a broken clock

☺ Like you're 10: Lots of people wrote about this test, which is lucky. All of them wrote before it changed size, which is not.

The usual problem with a field-notes page is scarcity: a young credential, two or three write-ups, and an honest admission that there isn't much to go on. The CDP has the opposite problem. There is a real shelf of testimony here — nine accounts published between May 2020 and July 2024, from people in different countries with different day jobs, several of whom disagree with each other, and one of whom actively dislikes the product he passed. That variety is what makes the record trustworthy. What makes it dangerous is that all of it predates a silent format change, and the internet has not caught up.

What the vendor guarantees — the only part of this page that isn't testimony

Before a single blog post, anchor on the vendor. Practical DevSecOps' exam and certification page and its CDP course page agree with each other, which is the minimum bar for treating a number as current. Everything in the table below is their published claim, quoted so you can recognise it — not this course's assertion, and not a promise it is still accurate on the day you read this.

The finding that reframes everything else: the clock moved

Seven of the nine named accounts state a hands-on window, and an eighth source — an unattributed review — corroborates them. Line all eight up against today's specification and the pattern is not subtle: four years, several countries, complete agreement with each other and complete disagreement with the vendor's current page.

Two accounts are missing from that table for honest reasons. Sanjeev Jaiswal reviewed the course and exam in May 2020 but published no format numbers at all, so he neither corroborates nor contradicts. Tess Sluijter declined to give exam specifics on the grounds of the non-disclosure agreement — which, as it turns out, made hers the account that aged best, because she published almost no numbers to go stale. The one number she does give cuts in this table's favour rather than against it: she reports losing 11 hours of work when her GitLab was reprovisioned, which only makes sense inside a window longer than eleven hours. Writing in March 2021, the one author who refused to state the format quietly corroborates it anyway.

A corroborating detail nobody planted deliberately

There is a small piece of arithmetic that quietly confirms the change and dates it. Practical DevSecOps advertises 36 CPE points for the CDP. Twelve plus twenty-four is thirty-six. That figure is exactly the old format's total contact time, and it is still sitting on the current page beside a six-hour exam window. The most economical explanation is that the hands-on window was halved and the CPE line was never revisited. The latest first-hand account in the record is Diogo Pereira's, published 1 July 2024, still describing twelve hours — so the change lands somewhere after that date.

What the drift actually costs you if you miss it

This is not a pedantic correction. It is the difference between a plan and a wreck. Vinit Patil published the most careful time plan in the entire record: roughly two hours and fifteen minutes per challenge, plus a forty-five-minute documentation buffer. Against twelve hours that is sensible, even conservative. Against six it is a fantasy — two and a quarter hours per challenge is eleven and a quarter hours of work inside a six-hour window. And Patil's actual experience was worse than his plan: challenge one took four hours, including a deliberate break to reset his head. Under the current clock, that single challenge is the entire exam, minus the two hours you would need for the other four.

Ayoub Najim independently reports the same shape — he passed on his first attempt, but burned roughly three and a half hours on challenge one and finished the remainder under real pressure. Two people, two years apart, both losing the front third of a twelve-hour exam to the first task. Halve the window and that failure mode does not halve with it; it becomes the whole story. Everything in How to Study for the Exam about timed reps, and everything in the CDP study plan about rehearsing inside the real window, exists because of exactly this.

The nine accounts, and what each one is actually good for

These are ordered by publication date. Every one is a real, named, reachable write-up by a person describing their own sitting. None of the numbers in the third column should be treated as a specification.

Three of these are less independent than they look

Nine accounts is only nine accounts if they were written independently, and three of them share a suspiciously specific sentence template about preparation duration — the "it took me around N days, studying X hours a day for W weeks, repeating the labs two to three times" construction. Jaiswal's is the earliest (May 2020); Najim's (2023) and Patil's (2023) closely echo its phrasing. Their other content differs substantially, and Patil's hour-by-hour breakdown is unmistakably his own work, so all three remain usable and all three stay in the table above. But the honest reading is one template plus two variations, not three independent corroborations of a prep-duration figure.

What this course found and deliberately did not use

Being explicit about the discards is part of being trustworthy about the inclusions. Four categories of source turned up in the search and were left out on purpose.

Part Two — the techniques that survive the format change

☺ Like you're 10: Now the good bit. Everything the nine people said about how to work is still exactly right — and the shorter exam makes most of it matter more, not less.

Strip out every number and what remains is a remarkably consistent playbook, arrived at independently by people who mostly were not reading each other. Six habits recur. Every one of them is format-independent, and four of the six get more valuable when the window halves.

1. Read all five challenges before you touch anything

This is Najib Radzuan's lead tactic and the one with the clearest mechanism behind it: the challenges interconnect. Something you build in challenge two may be what challenge four expects to already exist, and discovering that at hour five is a different experience from knowing it at minute five. Spending the opening minutes reading rather than typing feels wasteful when the clock is visibly running — which is exactly why people skip it, and exactly why it pays.

Under a six-hour window the calculation gets sharper, not looser. A ten-minute read of all five is under 3% of the exam and converts an unknown pile into a ranked queue: which one is cheapest, which one is a prerequisite for another, which one you should attempt last because you are weakest there and partial work is better than none. The triage playbook is the drilled version of this; the challenge bank is where you rehearse it against material you have not seen.

2. Document as you go, because the environment dies with the clock

Two independent accounts converge on this and one of them states the mechanism outright. Ishaq Mohammed's warning is the most operationally useful sentence in the record: you lose access to the exam lab when your exam time ends, so keep taking backups, screenshots and saved output while you still can. Tess Sluijter reduces it to three words — document as you go — but the three words are not hers, and she says so: As John Strand always says: "Document as you go!" It is one of several concrete tactics she gives despite the NDA; its companion — clone your exam repository locally and pull updates regularly — is in her row of the table above.

Think about what that actually means against the published spec. You get roughly 24 hours afterwards to write the report. You do not get the environment back during those 24 hours. So every screenshot you did not take, every scanner output you did not save, every command you ran but cannot reproduce from memory is a point you cannot claim — no matter how correctly you fixed the thing. The fix and the proof of the fix are two separate deliverables, and only one of them has a second chance.

# The evidence habit, run at the close of every single sub-task — not at the end.
# Four artefacts per fix. If any one is missing, the fix is not finished.

EV=~/exam-evidence/challenge-2/task-3
mkdir -p "$EV"

# 1. THE FINDING — proof the problem was real, before you touched it
semgrep --config auto --json --output "$EV/01-before.json" ./src
#   screenshot the failing pipeline run / the vulnerable response / the open port

# 2. THE CHANGE — the actual artefact you wrote, not a description of it
cp .gitlab-ci.yml            "$EV/02-pipeline.yml"
cp policies/require-scan.rego "$EV/02-policy.rego"
git -C . diff > "$EV/02-change.patch"

# 3. THE PROOF IT WORKED — the same check, re-run, now clean or now blocking
semgrep --config auto --json --output "$EV/03-after.json" ./src
#   screenshot the pipeline FAILING on purpose if the task was to add a gate

# 4. THE NOTE — four sentences, written now, while it is still in your head
cat > "$EV/04-note.md" <<'NOTE'
Finding:   what was wrong, and how I proved it was wrong.
Evidence:  01-before.json, screenshot-01.png
Change:    what I altered and why this control and not another.
Proof:     03-after.json, screenshot-02.png — gate now blocks on fixable HIGH.
NOTE

# Sanity check before moving on: four things, or you are not done.
ls -1 "$EV"

3. Expect tools, features and languages the labs never showed you

Tess Sluijter's framing is the most quoted-worthy thing in the record and the one most likely to save your exam. Her expectation-setting is threefold: expect scanners other than the ones the course labs used; expect more advanced features of the ones they did use; and expect programming languages other than the ones you practised on. Her comparison is to the OSCP — the concepts are the same, but you research on the job.

That is a specific instruction about how to prepare, and it is not "learn more tools." It is learn the category well enough to drive an unfamiliar member of it. If you only know Semgrep, you know one SAST tool; if you understand what SAST does, what a ruleset is, how findings are triaged and how exit codes drive a pipeline gate, you can pick up a scanner you have never seen from its --help output. Same for SCA, DAST, IaC scanning and policy engines. Pipeline security, static analysis, dynamic analysis and SCA in depth are all written category-first for exactly this reason, and the tools hub is deliberately a catalogue of interchangeable options rather than a shrine to one favourite.

The language point is the one people under-rate. A SAST challenge against a Python codebase and the same challenge against a Java or Go codebase are different afternoons if you can only read one of them. You do not need fluency — you need to be able to open an unfamiliar repository, find where dependencies are declared, find where the build happens, and read a stack trace without panicking. If that sounds like a gap, the baseline page is where it gets closed. And if the OSCP framing appeals, the OSCP page and offensive security for DevSecOps cover the research-under-pressure mindset in more depth.

4. Build the cheatsheet before exam day, not during it

Diogo Pereira's central piece of advice is to prepare personal cheatsheets of code snippets in advance, and to read the vendor's PDF manuals alongside the videos rather than treating video as the primary channel. This is the highest-leverage habit on the page for a shortened exam, because a cheatsheet converts recall time into paste time — and recall time is what you no longer have.

The trap is building a cheatsheet that is really a textbook. A useful one is short, invocation-shaped, and contains only things you have actually run. The command and tool reference on this site is the raw material; your version should be a tenth of its length and written in your own hand, because the act of choosing what goes in is most of the value.

# A cheatsheet worth having: one screen per category, invocations only.
# Rule — nothing goes in that you have not personally run at least twice.

## SAST — fail the build on a real finding
semgrep --config auto --error --json --output sast.json .
semgrep --config p/owasp-top-ten --severity ERROR --error .

## SECRETS — history matters more than the working tree
gitleaks detect --source . --report-format json --report-path secrets.json
trufflehog git file://. --only-verified --json > verified-secrets.json

## SCA — a gate, not a report
trivy fs --scanners vuln --severity HIGH,CRITICAL --ignore-unfixed --exit-code 1 .
syft packages dir:. -o cyclonedx-json=sbom.json && grype sbom:sbom.json --fail-on high

## CONTAINER — same tool, image target, plus config
trivy image --severity HIGH,CRITICAL --exit-code 1 "$IMAGE"
trivy config --severity HIGH,CRITICAL --exit-code 1 ./deploy

## IaC — two engines, because the exam may not hand you your favourite
checkov -d . --compact --quiet --output json --output-file-path iac.json
tfsec . --format json --out tfsec.json --minimum-severity HIGH

## DAST — the baseline scan is the one that fits in an exam window
zap-baseline.py -t "$TARGET_URL" -J zap.json -r zap.html

## POLICY AS CODE — the gate that rejects, with a reason
conftest test deploy/ --policy policies/ --output json
opa eval -i input.json -d policies/ "data.main.deny" --format pretty

## COMPLIANCE — machine-readable output the report can quote
inspec exec profile/ --reporter cli json:compliance.json

## TRIAGE — get findings somewhere a report can cite them
curl -s -H "Authorization: Token $DD_TOKEN" -F "scan_type=Trivy Scan" \
  -F "file=@trivy.json" -F "engagement=$ENG_ID" \
  "$DD_URL/api/v2/import-scan/"

## THE THREE FLAGS THAT DECIDE WHETHER A GATE IS REAL
#   --exit-code 1 / --error   → the pipeline actually fails
#   --severity                → it fails on the right things
#   --ignore-unfixed          → it fails on things somebody can act on

5. Challenge one is the time sink in every account that breaks down its hours

Two of the nine published an hour-by-hour account, and both lost the front of the exam to the first task: Najim at roughly three and a half hours, Patil at four. Neither was incompetent — both passed. The pattern is about how the first task feels: unfamiliar environment, adrenaline, a natural reluctance to abandon the thing you have already sunk an hour into, and no data yet about how hard the other four are.

The countermeasure is a hard flag-and-move rule set before you start, because you will not set one fairly at hour two. Decide your per-challenge ceiling from the current six-hour window and your own documentation budget, write it on paper, and obey it. Partial work left in place is worth more than a fifth task you never opened — and with only five items, one abandoned challenge is twenty percent of the paper. How to Study for the Exam covers building that rule into your practice reps rather than inventing it on the day.

6. Support answers during the exam — but do not plan around it

Diogo Pereira reports hitting minor technical problems at the start of his sitting and having his time extended by an hour to compensate. That is a real, citable data point about a real thing candidates worry about: whether anyone is listening if the environment misbehaves. The vendor's package advertises 24/7 learner support through Mattermost, and at least one candidate's experience is consistent with that extending to exam-time incidents.

Two cautions. First, this is one account, and one account is an existence proof, not a policy — nothing in the vendor's published pages promises time compensation, so do not build a plan whose slack depends on getting an hour back. Second, Petrosyan notes that the Mattermost channel tends to answer privately rather than in the open, which means the community channel is less useful as a searchable archive than it looks. Know how to reach support before the clock starts — Exam Day — What to Expect covers the pre-flight checks that stop most of these problems happening at all — and assume you will not need to.

What the report actually has to contain

The vendor publishes a submission window and a portal, but no rubric. Najib Radzuan's account is the closest thing in the public record to a content list, and it is worth treating as a floor rather than a ceiling. He is explicit that screenshots and scan reports are both essential to a CDP report — not one or the other.

Everything in that table's right-hand column says the same thing: the report is built during the exam and merely typed up afterwards. Vulnerability management and triage and compliance as code at scale both cover producing machine-readable evidence as a matter of routine; the capstone lab track is where you practise producing it under something resembling exam conditions.

Part Three — the dissent, unsoftened

☺ Like you're 10: One of the nine people passed the test and then wrote a review saying he didn't think much of it. That review is the most useful one on this page, and we're not going to tidy it up.

Eight of the nine accounts are broadly positive. That is normal and slightly suspicious: people who pass write posts, people who fail mostly do not, and people who paid several hundred dollars have a quiet incentive to feel good about it. Mikayel Mardanyan Petrosyan passed the CDP in 2024 and then published a critical review anyway, which makes his the account with the least to gain and therefore the one worth reading most carefully. Reducing it to "one person didn't like it" would be dishonest, so here it is properly.

None of that is an argument against sitting the CDP. It is an argument for going in with accurate expectations: a hands-on, operational credential that will make you demonstrably competent at running a security toolchain, that will not by itself make you a security architect, and whose material you should treat as a starting point rather than a canon. The certifications page puts it in context against the alternatives, and the CDE page covers the next rung of the same ladder if you decide to keep climbing it.

The silences — what nobody reports, and why that matters

☺ Like you're 10: Sometimes what's missing from every review tells you something. But "nobody mentioned it" is not the same as "it doesn't happen."

Four things are conspicuously absent from the entire nine-account record, and each absence needs a different response.

Reading first-hand accounts critically — the general skill

☺ Like you're 10: Three habits that stop a blog post from lying to you by accident.

This page is really a worked example of a skill you will need for every certification you ever sit, and for a good deal of security work besides. Three habits do most of the work.

Date everything, and check what changed since. The CDP record is not wrong because its authors were careless — it is wrong because the exam moved underneath them. An undated claim is an unusable claim. When you find a write-up, find its publication date first and ask what the vendor has changed since. On this page the dates are printed beside every author for exactly that reason.

Separate observation from inference. "My exam ran twelve hours" is an observation and almost certainly true of that sitting. "The exam runs twelve hours" is an inference from a sample of one, and it is now false. The same distinction applies to sub-task counts, tool lists and difficulty ratings: what happened to one person is evidence about one person. How to Study for the Exam makes the same point about your own practice — one clean rep is an observation, not a readiness signal.

Count independent voices, not repetitions. Three posts sharing a phrasing template are one voice with an echo, as Jaiswal, Najim and Patil demonstrate above. And a claim that appears on twenty SEO pages with no named author behind any of them has a source count of zero, however confident the twenty pages sound. That is precisely how "a 36-hour exam" is still circulating years after the format it described was retired.

Once you have read the accounts themselves, come back to the practical pages. The CDP exam guide carries the vendor's current specification with the same warnings as this page; How to Study for the Exam turns the six habits above into a method; Exam Day — What to Expect takes the environment, the report portal and the pre-flight checks in detail; the baseline page closes the gap between what the vendor says it assumes and what these nine people found it actually assumes; and the challenge bank plus the capstone lab track are where you rehearse against a real clock — a real six-hour clock, which is the one thing none of the nine could tell you about.