How to Study for the Exam

Most people who fail a certification exam did not fail because the material was too hard. They failed because they studied the way they studied at school — reading front to back, highlighting, re-reading the highlights — and that method is almost perfectly mismatched to how this exam is scored. This page is the method, not the material. It is written for the Certified DevSecOps Professional (CDP) from Practical DevSecOps, and the CDP has a shape that makes the mismatch worse than usual: it is not a paper you answer, it is a live environment you fix and then a report you have to write about what you did. There is no multiple choice to hide behind, no partial credit for a lucky guess, and no way to bluff a screenshot of a scan that never ran clean. Everything below follows from that.

The exam decides the method — so start with the exam's shape

☺ Like you're 10: Before you decide how to practise, find out exactly what the test is going to ask you to do. This one asks you to fix things, and then to prove you fixed them.

Every study decision on this page is downstream of four facts about the CDP, and all four come from Practical DevSecOps' own pages rather than from this site. Their exam and certification page states that the exam is "an online, task-oriented exam where you attempt to solve 5 challenges (tasks) in a span of 6 hours," that "students must score at least 80 points (80%) to earn the DevSecOps certification," and that "after the exam, you have about 24 hours to submit the exam report on our internal portal." Their CDP course page repeats the same structure and describes the credential as a lifetime one, with no stated renewal period.

That is the whole published specification, and it is worth being precise about how little it contains, because the gaps change what a sensible study plan can look like:

Two consequences fall straight out of the table, and they are the spine of this page. First: because the exam grades a live environment, recognising the right answer is worth nothing — you have to be able to produce the fix with your hands. Second: because it also grades a report written afterwards, producing the fix is not enough either — you have to be able to prove it, in writing, to somebody who was not standing behind you. That second half is the part almost nobody trains for, and it is where candidates who genuinely knew the material still lose points.

Three tiers of knowing, and the exam pays for the third

☺ Like you're 10: Seeing something and thinking "yes, I know that" is the weakest kind of knowing. Doing it yourself is stronger. Doing it and being able to show someone else exactly how, afterwards, is strongest — and that's the one this exam pays for.

Almost every bad study session comes from confusing these three states with each other. Name them, and you can tell in ten seconds whether the last hour was worth anything.

The tiers are not a ladder you climb once per topic and then leave behind — they are three separate skills, and being at tier three on secrets detection tells you nothing about where you are on dynamic analysis. That is why the ledger a few sections down scores every chapter separately, and why a single strict definition of "done" matters more than any amount of enthusiasm.

A knowledge exam and a hands-on exam are different sports

☺ Like you're 10: One test reads your mind. The other watches your hands. You practise knowing by explaining; you practise doing by doing.

Plenty of good study advice on the internet was written for multiple-choice exams, and a fair bit of it actively harms a CDP candidate. It is worth laying the two side by side once so you can tell, when you read a study tip anywhere, which sport it belongs to. Both of these exist in this course's certifications line-up, which is why the distinction is not academic: the CDP and the CKS are hands-on, while the AWS Security – Specialty and CISSP are knowledge exams.

So what are the flashcards for, then?

Here is the honest position, because it is a fair question to ask of a hands-on candidate looking at a deck of cards. This course ships several knowledge-shaped instruments — 38 flashcards, a self-check across fourteen domains, an exam simulator with a clock on it. None of them is a rehearsal for the CDP, because none of them puts your hands on anything. They are diagnostics and fluency drills, and they earn their place for exactly two reasons.

• They make vocabulary free. On the day, you should never spend exam seconds working out the difference between an SBOM and a provenance attestation, or what --ignore-unfixed excludes. That recall needs to be reflexive so that your working memory is available for the actual problem. This is Remy's entire job, and it is why Know It Cold and the command & tool reference sit next to the deck.
• They find gaps faster than labs do. Ten self-check questions take four minutes and will tell you that you are shaky on compliance evidence. Discovering the same thing by working a lab takes an hour. Use the cheap instrument to aim the expensive one.

What they cannot do is tell you whether you can do the work. A card you answer correctly is tier-one evidence at best and tier-two evidence never. Treat a green self-check the way you would treat a green unit test on a system nobody has integration-tested: encouraging, and not the thing you ship on.

Retrieval is the whole engine

☺ Like you're 10: Pulling something out of your head with the book shut is what makes it stick. Reading it again just makes it feel familiar.

If you take one thing from this page, take this: the act of producing something from memory, with the source closed, is what moves it from recognised to owned. Re-reading is smooth and teaches almost nothing. A blank page — or better, a blank terminal — feels awful and teaches a great deal. Every technique on the rest of this page is a different wrapper around the same move: shut the tab, produce the thing, then check.

The reason it works is that difficulty during practice is not a bug. When retrieval is effortful, the memory gets strengthened; when it is effortless, nothing changes. This is why the study activity that feels most productive is usually the one doing least, and why the one that feels like failing is usually the one doing most. Expect the good sessions to feel bad.

What retrieval looks like at each tier

Building a plan when the vendor publishes no weights

☺ Like you're 10: Some exams publish a list saying "this topic is 25% of the test." This one doesn't. So instead of guessing at percentages, you measure your own gaps honestly and work on the biggest ones.

A CKS or AWS candidate can read a published curriculum with percentage weights next to each domain and allocate hours literally. A CDP candidate cannot: Practical DevSecOps publishes "5 challenges" and nothing about how those challenges are distributed across topics. Anybody who tells you the CDP is "30% SAST" is making it up, and a plan built on an invented weighting is a plan aimed at a target that does not exist.

What you have instead is two real things. The first is the vendor's own course syllabus, which is the closest thing to a specification of the pool — the exam is built around their training material, and their published prerequisites tell you what is assumed rather than taught. The second is this course's nine-chapter exam blueprint, which was built to mirror that spread. Together they give you a list of things you either can or cannot do. That list is your blueprint, and your gaps are your weights.

Turn every chapter into a verb

Syllabus lines are written as nouns — "Software Composition Analysis" — and nouns cannot be ticked off, because there is no moment at which you have finished a noun. Rewrite each one as something you either can or cannot do, under a clock, with proof:

Notice the shape every row shares: a verb, a real target, and a proof. If a rewrite has no verb, you have written a mood. If it has no proof, you have written a tier-two item on a tier-three exam.

Build a confidence ledger

Now make it queryable. A plain text file beats any app here, because you want to sort and count it without leaving the terminal you are already living in. One line per chapter, with a confidence score you update honestly after every session:

mkdir -p ~/cdp-prep && cd ~/cdp-prep

printf 'competency|chapter|conf|last\n' > ledger.psv

cat >> ledger.psv <<'EOF'
Toolchain fluency: docker, git, CI runner, the scanners|Ch 1-2 Foundations|0|never
Secure SDLC gates and DSOMM levels|Ch 3 Gates|0|never
SBOM generation and dependency CVE triage|Ch 4 SCA|0|never
SAST rules, false-positive triage, secrets detection|Ch 5 SAST|0|never
DAST against a live target, reading the output|Ch 6 DAST|0|never
IaC scanning and policy that blocks a bad plan|Ch 7 IaC|0|never
Controls as executable checks, machine-readable evidence|Ch 8 Compliance|0|never
Severity, exploitability, and defending a triage decision|Ch 9 Triage|0|never
Writing the evidence report itself|Cross-cutting|0|never
EOF

That last line is not filler. The report is a graded artefact, so it is a competency with a confidence score like any other, and treating it as one is the difference between a candidate who writes a report and a candidate who assembles one from notes they already had.

Score each line 0–3 on a scale that has nothing to do with feelings: 0 = never attempted; 1 = did it with notes or docs open; 2 = did it cold, but slowly; 3 = did it cold, inside its time budget, twice, on different days, and produced a usable evidence note both times. Only a 3 counts as done. Then the ledger answers the only question that matters at the start of a session:

cd ~/cdp-prep

awk -F'|' 'NR>1 && $3<=1 {printf "%-52s %-18s conf=%s  last=%s\n", $1, $2, $3, $4}' ledger.psv

awk -F'|' 'NR>1 {s[$2]+=$3; n[$2]++} END {for (c in s) printf "%-18s avg %.1f over %d line(s)\n", c, s[c]/n[c], n[c]}' ledger.psv | sort

The second command is the one that changes behaviour. Read the per-chapter averages and go where the number is lowest, regardless of which topic you happen to find interesting. Without published weights this is your prioritisation function: gap, not glamour.

The clock in every published write-up is wrong

☺ Like you're 10: People who took this exam wrote about it online. Their advice about how to do it is still good. Their advice about how long you have is now twice the real number.

This matters here, on a study-technique page, rather than only on an exam-day one — because how long the exam is determines how long your practice reps should be, and a rep timed to the wrong budget trains the wrong pace. If you go looking for first-hand accounts of the CDP (and you should — they are unusually plentiful for a vendor certification), you will find something odd. Every single one describes a 12-hour hands-on window. The current official specification says 6.

The most recent first-hand account this course could verify is from July 2024, so the change lands after that. A small corroborating detail: the vendor's own page still advertises 36 CPE points, which is exactly the old 12 + 24 arithmetic — a leftover from the retired format sitting on the same page as the new one. Take that as a reminder that vendor pages are not uniformly updated, and that your booking confirmation beats any marketing page.

Recomputing the rep budget from the real clock

So here is arithmetic you can actually train against — this page's own division of the official six-hour figure, not a vendor statement, so that your timer has a number on it rather than a vibe. Six hours is 360 minutes across five challenges, but do not divide 360 by 5 and call it 72 minutes of solving: evidence capture happens inside that window. Mikayel Mardanyan Petrosyan's review makes exactly that point in its criticism of the format — evidence-gathering and documentation come out of the hands-on time, so the usable slack is smaller than the headline number suggests.

So: five roughly 60-minute solving slots and a 60-minute reserve. The reserve is not comfort — it absorbs the evidence capture you do at the close of each challenge plus the one challenge that fights you. Time every practice rep against a 60-minute slot from the moment you finish reading the task, and you will arrive with a pace that fits the real window instead of one borrowed from a retired format.

Spacing, and a ladder you will actually keep

☺ Like you're 10: Things leak out of your head. If you grab them again just as they're about to leak, they stick much longer — and you have to do it less and less often.

Memory for anything you are not using daily decays, and it decays fastest right after you learn it. Reviewing something just as it is starting to fade resets the clock and flattens the curve, so each successive review can sit further away than the last. That is the whole idea, and it is the single most evidence-backed study technique available: review at increasing intervals, timed to just before you forget.

Ignore the elaborate algorithms. A fixed 1 / 3 / 7 / 21 ladder captures nearly all the benefit and needs no software: when you learn something, revisit it tomorrow, then three days later, then a week later, then three weeks later. Anything you fumble drops back to the start of the ladder. Anything you nail at +21 is done — trust it and stop spending time on it.

The cheapest implementation is a dated file. Add a line as you learn something; each morning, grep for today:

cd ~/cdp-prep

printf '%s|%s\n' "$(date -v+1d +%F)" "trivy: the two flags that turn a scan into a gate" >> reviews.psv
printf '%s|%s\n' "$(date -v+3d +%F)" "trivy: the two flags that turn a scan into a gate" >> reviews.psv

grep "^$(date +%F)|" reviews.psv || echo "nothing due today -- go do a fresh rep instead"

That date -v+1d form is BSD/macOS; on Linux the equivalent is date -d '+1 day' +%F. Either way the point is that scheduling a review must cost you one line, or you will quietly stop doing it by Thursday. The flashcards player does the same bookkeeping for vocabulary automatically — fumbles stay in rotation, knowns drop out — which is why it is the right home for terminology and the wrong home for anything with a verb in it.

How the drills on this site fit together

☺ Like you're 10: Each practice tool on this site answers a different question. Use the quick cheap ones to find out what's broken, and the slow expensive ones to fix it.

There are a lot of practice surfaces in this course and it is genuinely unclear from the outside which one you should be on. Here is the ordering, with the honest limit of each — because the fastest way to waste a month is to drill the instrument that cannot measure your actual gap.

Running a lab so it teaches you something

☺ Like you're 10: Before you press enter, say out loud what you think will happen. Then press enter and find out if you were right. The surprises are the lesson.

You can spend forty hours in a terminal and learn very little, and most people do. The reason is that typing commands from a page is a transcription exercise: your eyes move, your fingers move, and your model of the system is never once consulted, so it is never once corrected. Three rituals fix it, and none of them costs more than a couple of minutes per rep.

Ritual one — predict, then verify

Before every command that changes something or gates something, state the prediction — out loud, or better, written down. What will the exit code be? How many findings? Will the build fail? Then run it and check the prediction against reality. When you are right, you have confirmed your model cheaply. When you are wrong, you have found the exact spot where your understanding is broken, which is the only thing in a lab that was ever worth your time.

cd ~/cdp-prep

cat > prediction.txt <<'EOF'
Running trivy three ways, I expect:
 1. no --exit-code   -> exit 0, even with CRITICALs printed to screen
 2. --exit-code 1 --severity HIGH,CRITICAL -> exit 1, build should fail here
 3. adding --ignore-unfixed -> fewer findings, but NOT zero
EOF

trivy image nginx:1.25 ; echo "exit=$?"

trivy image --exit-code 1 --severity HIGH,CRITICAL nginx:1.25 ; echo "exit=$?"

trivy image --exit-code 1 --severity HIGH,CRITICAL --ignore-unfixed nginx:1.25 ; echo "exit=$?"

cat prediction.txt

The specific lesson buried in that example is one worth having on a flashcard: a scanner that prints scary output and exits 0 is not a gate, it is a report nobody is reading. Prediction three is the interesting one, because --ignore-unfixed suppressing everything is the single most common wrong mental model here — it drops findings with no available fix, which is a very different thing from dropping findings you would rather not deal with.

The same ritual generalises to every tool in the blueprint. Predict before you run:

gitleaks detect --source . --report-format json --report-path leaks.json ; echo "exit=$?"

semgrep --config auto --error . ; echo "exit=$?"

conftest test tfplan.json ; echo "exit=$?"

cosign verify \
  --certificate-identity-regexp '.*' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  ghcr.io/example/app:1.4.2 ; echo "exit=$?"

Every one of those has an exit code you should be able to predict before you press enter, and a failure mode you should be able to name. If you cannot, that is a ledger line sitting at confidence 1, whatever you told yourself last week.

Ritual two — break it on purpose

Reading that a policy blocks a bad plan is worth roughly nothing. Writing a deliberately bad plan and watching it get blocked, while the clock runs, is worth a lot — and a task-based exam is heavy on situations where something is already wrong. So end every lab by sabotaging it: reintroduce the misconfiguration and confirm the gate catches it again; commit a fake credential to a scratch branch and confirm the secrets scan fires; downgrade a dependency to a version with a known CVE and confirm the SCA step fails the build rather than warning politely. The broken Terraform drill, the leaked credential triage and the dependency fire drill are built entirely around this move, because "find and fix what is already wrong" is the shape of the exam. When something does not behave the way you predicted and you cannot see why, the triage playbook is the page for that, and reaching for it is not cheating — reaching for it instead of forming a hypothesis is.

Ritual three — close every rep with an evidence note

This is the ritual that is specific to this exam, and it is the one that separates a candidate who scrambles through the report window from one who assembles a document they already mostly have. First-hand accounts are unusually consistent about it. Ishaq Mohammed's review carries the bluntest warning of the lot: you lose access to the exam lab the moment the hands-on window closes, so keep taking backups, screenshots and saved output — because that is the only material you will ever have. Najib Radzuan is the most concrete about what the report has to carry: step-by-step instructions, the configuration files themselves (his examples are CI/CD YAML and Ansible playbooks), screenshots, and machine-readable output such as JSON or XML — not just prose. And Tess Sluijter, writing about the mindset rather than the mechanics, reduces the whole habit to three words: document as you go.

So make it mechanical. Four headings, written the moment a task closes, while your terminal history is still on screen:

mkdir -p ~/cdp-prep/evidence

cat >> ~/cdp-prep/evidence/ch5-secrets.md <<'EOF'

## The finding
gitleaks flagged an AWS access key in config/settings.py:14, introduced 2 commits back.

## Proof it was real
$ gitleaks detect --source . --report-format json --report-path leaks.json
1 finding, rule aws-access-token, commit 9f2c1ab. leaks.json attached.

## What I changed, and why
Rotated the key at the provider, moved the value to the secret store, and read it
at runtime from the environment. Did NOT add a .gitleaks allowlist entry -- that
would silence the detector rather than remove the secret.

## Proof it is fixed
$ gitleaks detect --source . --exit-code 1
no leaks found -- exit=0. Re-ran the pipeline: secrets stage green. Screenshot: 05b.png
EOF

Four headings, ninety seconds, every single rep. The headings are doing real work: proof it was real stops you writing up a finding you never actually reproduced, and proof it is fixed stops you writing up a change you never re-ran. Both of those are the difference between a claim and evidence, and on an exam scored partly on a report, that difference is points. It is also, not incidentally, exactly what compliance and governance means by evidence in a real organisation — a control that only ever existed as a green tick in someone's terminal is a rumour with good intentions.

Time-box every rep

A task-based exam is a speed exam wearing a knowledge exam's clothes. An untimed lab trains you to be correct eventually, which is a skill the six-hour window does not reward. Put a clock on every rep from the moment a chapter reaches confidence 2, using the 60-minute slot the earlier arithmetic gave you:

cat > ~/cdp-prep/drill <<'EOF'
#!/usr/bin/env bash
set -euo pipefail
task="${1:?usage: drill <task-slug> [minutes]}"
budget="${2:-60}"
log="$HOME/cdp-prep/times.psv"
start=$(date +%s)
finish() {
  elapsed=$(( $(date +%s) - start ))
  printf '%s|%s|%ss|budget %sm\n' "$(date +%F)" "$task" "$elapsed" "$budget" >> "$log"
  printf '\n[logged] %ss on %s (budget %sm). Now write the evidence note.\n' "$elapsed" "$task" "$budget"
}
trap finish EXIT
printf '>> %s -- %s minutes. Ctrl-C the moment the fix is verified.\n' "$task" "$budget"
sleep $(( budget * 60 ))
printf '\n[time] Budget gone. Stop. Write down what blocked you, then look it up.\n'
EOF
chmod +x ~/cdp-prep/drill

~/cdp-prep/drill sca-gate-fails-on-fixable-high 60

The log matters more than the timer. After a fortnight, sort times.psv and look at which slugs keep reappearing over budget — those are your slow tasks, and slow tasks, not unknown tasks, are what run most candidates out of clock.

Keep a mistake log

☺ Like you're 10: Write down every mistake in one place. After a few weeks you'll notice you keep making the same three — and those three are your whole revision list.

Individual mistakes are noise. Patterns of mistakes are the highest-value information you will generate during the whole plan, and you cannot see patterns without writing them down. One file, appended to the moment something goes wrong, never edited afterwards.

cat >> ~/cdp-prep/mistakes.md <<'EOF'

## 2026-08-14 · Ch 4 SCA · gate did not fail the build
- what I was asked: fail the pipeline on fixable HIGH and CRITICAL findings
- what I actually did: added the scan step, saw red output, moved on
- what was really wrong: I did not know the scanner exits 0 by default
- the fix in one line: --exit-code 1 --severity HIGH,CRITICAL --ignore-unfixed
- class: knowledge-gap
- redrill: 2026-08-17
EOF

"What was really wrong" is a different sentence from "what I did wrong," and forcing yourself to write it is what converts a mistake into a lesson. "I got it wrong" is not actionable. "I did not know the default exit code" tells you exactly what to read.

Classify it — the fix depends on the class

Once entries are classified, one command every Sunday tells you what kind of candidate you currently are:

grep -h '^- class:' ~/cdp-prep/mistakes.md | sort | uniq -c | sort -rn

grep -h '^- redrill:' ~/cdp-prep/mistakes.md | awk -v today="$(date +%F)" -F': ' '$2 <= today'

A log dominated by knowledge-gap means you are early — keep reading and building. Dominated by recall-lag means you know the material and need speed drills, not more reading. Full of wrong-target means you need a ritual, not more study. Heavy on unverified or undocumented means your technical work is fine and your reporting habit is the thing standing between you and eighty points. Four completely different prescriptions, which is why the classification is not busywork.

Four ways to waste a month

☺ Like you're 10: Copying someone else's steps feels like learning but isn't. Reading the whole manual feels careful but isn't. Both are ways of avoiding the scary bit: doing it yourself with nothing open.

Trap one — tutorial-following

You follow a well-written walkthrough. Every command works. Nothing errors. You finish with a scanning pipeline, a signed image and a warm sense of competence. Two days later you cannot produce any of it. This is the illusion of competence, and it is the most common failure mode in DevSecOps prep because a tutorial removes every decision, and decisions are the thing being examined. The tell is simple: if you did not have to decide anything, you did not learn anything. Three ways to convert a walkthrough into practice:

• Read it, close it, then do it. Skim once for the shape, shut the tab, reproduce it. Reopen only when properly stuck, and log a mistake when you do.
• Change the parameters. The walkthrough used one language and one registry; you use another. Everything that breaks is something the walkthrough was hiding from you — and given that first-hand accounts warn you to expect unfamiliar languages, this is not an optional flourish.
• Do it again from a clean start tomorrow. Rebuild speed is the real measure. A throwaway container or a fresh clone costs you a minute.

Trap two — over-reading the documentation

The opposite failure, and the one that catches conscientious people. Security tool documentation is enormous and much of it is genuinely good, so it is pleasant to read — and reading it can absorb unlimited time while producing nothing you can retrieve. Worse, on a hands-on exam where no assistant is permitted, it produces a specific bad habit: you learn to find things rather than to know them, and then you burn four minutes navigating during a task you should have typed from memory. Documentation has exactly two legitimate roles in this plan: answering a specific question you already have, after which you close the tab, and building your own condensed reference so you are not reading upstream docs at speed on the day. The discipline that keeps both honest: never open documentation without a question. If you cannot say what you are looking for, you are browsing, and browsing is entertainment.

Trap three — tool-collecting

This course's tooling landscape lists dozens of tools, and it is tempting to treat that as a memorisation target. It is not. A candidate who can name twenty-five scanners and drive six of them fluently is in far better shape than one who has read the marketing page for all twenty-five. Depth per category beats breadth across categories, because the exam gives you a problem, not a tool name — and because, as the write-ups warn, the specific tool in front of you may be one you have never opened. Pick one scanner per category, get to tier three with it, and only then broaden.

Trap four — looking for a shortcut that does not exist

What one useful session looks like

☺ Like you're 10: Small amounts, most days, at the same time. That beats one giant panic weekend, every time.

Study plans fail on scheduling, not on content. This page deliberately does not give you a calendar — the CDP study plan already maps the nine-chapter blueprint onto an actual week-by-week schedule, with a toolchain gate up front and mock exams placed so you do not burn all four early. What this page owns is the inside of a session, because a well-scheduled hour spent badly is still an hour spent badly.

Notice that only thirty of the sixty minutes are spent doing the thing, and that this is correct. The warm-up, the sabotage, the evidence note and the bookkeeping are not overhead around the real work — they are the parts that make the thirty minutes stick.

When you miss a week

You will. The rule is: do not restart, and do not try to make it up. Come back with a single thirty-minute retrieval session on whatever the ledger says is weakest, take the score hit honestly, and resume the normal week. Candidates who try to repay lost hours in one weekend usually abandon the plan entirely within a fortnight. A study plan you resume is worth ten study plans you abandon.

How to know you are actually ready

☺ Like you're 10: "I feel ready" is not evidence. "I did it twice, cold, in time, and wrote it up" is evidence. Only book on evidence.

Confidence is not a readiness signal — it is a mood, and it tracks how recently you read something rather than whether you can produce it. The exam has an objective bar, so measure yourself against an objective test.

• Two full-window rehearsals, on different days, inside the real six-hour clock. Not two afternoons of poking at labs — two sittings where you start the timer, work five challenges from the mock sets, and stop when the clock stops. The published pass mark is 80 out of 100, so set your personal bar higher than that: a bad day should still clear it.
• Every chapter has cleared confidence 2 in the ledger, and none sits at 0. With only five challenges, a single untouched topic can be a fifth of the paper. Coverage beats depth-in-one-place here more than on almost any other exam.
• Median rep time comfortably inside the 60-minute slot, read from your own times.psv rather than from memory — and with a plan for the one challenge that will overrun.
• You can produce a submittable report from your notes in under two hours. Time this once, on a mock. If it takes six hours, you are writing from scratch rather than assembling, and the fix is upstream in your rep habit, not in your writing speed.
• You have practised abandoning a challenge. Stopping at the sixty-minute mark, saving what you have with its evidence, and moving on is a skill, and the only way to acquire it is to rehearse it deliberately at least twice.
• You can pick up an unfamiliar scanner in a familiar category and get machine-readable output from it inside ten minutes, from its own --help.
• The mistake log has gone quiet, and what remains is recall-lag rather than knowledge-gap, with no unverified or undocumented entries in the last two sessions.

Signals that mean nothing

One useful sanity check on scale, offered with a caveat. The earliest published CDP review this course could verify — Sanjeev Jaiswal's, from May 2020 — describes roughly a month of preparation at one to two hours a day, with the labs repeated two or three times, and recommends arriving with Docker, CI/CD and SSH already familiar. Two later reviews quote near-identical prep numbers in near-identical phrasing, which suggests they are variations on Jaiswal's sentence rather than three independent data points — so treat it as one reported experience, from someone who already worked in the field, not as a norm. Your ledger is a far better estimator of your own remaining hours than anyone else's blog post is.

The last 72 hours

☺ Like you're 10: The three days before the exam are for polishing what you have, not for learning anything new. And sleep counts as studying.

Whatever you do not know 72 hours out, you will not know on the day — so stop trying. The final stretch has one job: arrive rested, fast and calm, with the mechanics rehearsed so that none of your attention goes to logistics.

Two logistics items are worth calling out because they are specific to this exam's shape rather than general exam advice. First, build your own cheatsheet of code and command snippets before the day — Diogo Pereira, whose July 2024 write-up is the most recent first-hand account this course could verify, names exactly that as his main preparation advice, alongside reading the vendor's PDF manuals next to the videos and planning the time split across exercises before starting. It is the natural companion to a no-assistant exam. Yours should be the invocations you keep fumbling in times.psv, not a copy of somebody else's. Second, plan where you will be for the 24 hours after the hands-on window closes, because the report deadline keeps running regardless of sleep, and a six-hour technical exam followed by an all-nighter is a bad way to produce a graded document. The mechanics of the day itself — registration, the two clocks, what to do when the environment misbehaves — belong to the CDP exam guide rather than to this page.

Where to point the method

☺ Like you're 10: This page is how to study. These pages are what to study.

One method, one exam, three tiers. If the vocabulary is not yet free, start with the flashcards and Know It Cold. If it is, open the blueprint and build the ledger tonight — it takes twenty-five minutes and it will tell you more about your next month than any amount of reading will. Then take the plan to the CDP study plan, work the challenge bank against a real clock, and when the objective signals turn green, read the exam guide and book it.