Exam Day — What to Expect

Most "exam day" advice on the internet is about a proctor. Hold your passport up to the webcam, pan the room slowly, clear the desk, don't mutter. None of that is what you are walking into here. The Certified DevSecOps Professional (CDP) from Practical DevSecOps is a hands-on, browser-based practical exam: you are given access to a live environment, a set of challenges to solve in it, a clock, and — when that clock stops — a second, longer clock during which you write up what you did and submit it for marking. There is no question paper, no answer sheet, no flag-and-move, and nothing published about a webcam. What there is instead is a laboratory that disappears at a known instant, and a written report that has to survive without it. This page is about running that day well, and about the specific ways people have lost points on it who genuinely knew the material.

Start here: this is not a proctored paper, and that changes everything

☺ Like you're 10: Before you plan for a test, find out what kind of test it is. This one has no questions to tick and, as far as anyone has published, no person watching you through a camera.

Practical DevSecOps describe the exam on their own exam and certification page as "an online, task-oriented exam where you attempt to solve 5 challenges (tasks) in a span of 6 hours," add that "students must score at least 80 points (80%) to earn the DevSecOps certification," and state that "after the exam, you have about 24 hours to submit the exam report on our internal portal." Their CDP course page says the same in one sentence — "The exam consists of 5 challenges to be solved within 6 hours, followed by a 24-hour window to complete and submit the report for evaluation" — and describes the credential itself as a lifetime one.

Now read those sentences for what they do not contain. No question count beyond five challenges. No mention of a proctoring vendor, a webcam, an identity check, a room scan, or a permitted-items list. No documentation allowlist, because you are working in a real environment with real tools rather than answering questions about them. That absence is the defining feature of this exam day, and every practical decision below follows from it.

What the vendor publishes, in one table

Two of those rows deserve to be read next to each other. The pass mark is 80%, and the exam has five items. Whatever the internal points breakdown turns out to be, an exam with five challenges and a high-eighty-percent bar does not leave much room to write one of them off. This is not a sixty-four-percent-and-skip-two exam. It is also worth noticing that Practical DevSecOps' more advanced certification, the Certified DevSecOps Expert (CDE), is published as a longer exam at a lower bar — their pages list it as a 24-hour hands-on window at 70% — which makes the CDP's 80% the higher pass mark of the two. Read that as a warning against treating the CDP as the gentle warm-up act.

Where a conventional exam-day checklist stops applying

If you have sat a Linux Foundation or PSI-delivered exam, you already carry a mental checklist. Most of it does not transfer. Here is the honest mapping, so that you neither prepare for a room scan nobody has reported nor assume a freedom you have not confirmed.

Two clocks, and the second one is the one people forget

☺ Like you're 10: There are two timers, not one. The first is for fixing things. The second starts when the first ends, and it is for writing about what you fixed. Both of them count towards your score.

The most useful mental model for this exam is that it has two graded windows in series, and that they grade different things. The six-hour window grades what you can do with your hands against a live environment. The twenty-four-hour window grades what you can prove, in writing, to a marker who was not standing behind you. A candidate who solves all five challenges and writes a thin report has not banked the work; a candidate who writes beautifully about work they cannot evidence has nothing to write about in the first place.

What makes this genuinely dangerous rather than merely inconvenient is the join between the two. The environment does not stay up for the report window. Ishaq Mohammed, writing up his own attempt on his site in May 2020, put it as plainly as anyone has: you do not have access to the exam lab once your exam time is over, so — in his words — "keep taking backups, screenshots and output results." His twelve hours are now six — the format changed, and the next section is entirely about that — but the operational rule survives the change unaltered, and it is the single most valuable sentence anybody has published about this exam.

The clock in every published account is double the real one

☺ Like you're 10: People who took this exam wrote helpful notes about it. But the exam got shorter after they sat it, so all their timings are wrong — twice as long as yours. Their tips still work. Their maths does not.

This is the accuracy trap that dominates CDP preparation, and it is worth stating bluntly before you read a single word of anybody's experience. Every verifiable first-hand write-up of this exam describes a twelve-hour hands-on window. The current published specification says six. The write-ups span 2020 to mid-2024 and agree with each other; the vendor's current pages disagree with all of them. The format was shortened, and the accounts were not retroactively updated — nor would you expect them to be.

One further detail corroborates the change and helps date it. The vendor's own CDP page still advertises 36 CPE points for the certification — which is exactly 12 + 24, the arithmetic of the retired format. That leftover, sitting on a page whose next paragraph says six hours, is the kind of internal inconsistency you get when a format is shortened and not every page is revised. The most recent verified first-hand account, Diogo Pereira's, is dated July 2024 and still describes twelve hours, so the change lands after that.

Why this is not a footnote

Because the transferable content of those write-ups is technique, and the non-transferable content is arithmetic — and the arithmetic is the part that reads most like actionable advice. Two concrete examples make it obvious.

• Vinit Patil planned roughly two hours and fifteen minutes per challenge with a forty-five-minute documentation buffer, and reported that challenge one actually took him about four hours — he took a break to reset — with challenges two and three at around ninety minutes each, leaving roughly four hours for the last two. Under a six-hour clock, his challenge one alone would have consumed the entire exam with four challenges untouched.
• Ayoub Najim reported burning about three and a half hours on challenge one and finishing the rest under pressure. He passed. Under the current clock, three and a half hours on one challenge leaves two and a half hours for four challenges and all of the evidence capture.

Both are honest accounts of real exams, and neither is a warning its author could have written for you, because neither of them sat your exam. The lesson to carry forward is not "budget less time" as a vague resolution. It is that the challenge-one time sink is the documented failure mode of this exam, it happened to at least two people who published about it, and the window it happens inside is now half as long.

Booking — what you are actually buying, and when to sit it

☺ Like you're 10: You usually buy the exam as part of a course, and the course comes with one go at it. A second go costs extra. So pick your day carefully rather than grabbing the first free slot.

Registration runs through Practical DevSecOps' own site. The CDP is most often bought as part of their training package, and their course page describes that package as including three years of video access, sixty days of browser-based labs, more than a hundred guided lab exercises, a PDF manual, checklists, round-the-clock learner support through Mattermost — and a single exam attempt. Their exam retake page prices a retake separately.

The volatile numbers — attributed, and not to be trusted from this page

Some figures on a certification page are stable for years and some move constantly. These are the moving ones, quoted so you can recognise them rather than so you can plan a budget around them.

The one figure in that neighbourhood that is not volatile is the validity: the vendor describes the credential as a lifetime one, and states no renewal period. This page will not invent one, and neither should any recruiter's job spec you read.

Choosing a date — pick a day you can afford to lose entirely

Six hours is a working day. The report window that follows it is another one. The scheduling question is therefore not "when do I have six hours free" but "when do I have six hours of uninterrupted concentration followed by a realistic slot to write several thousand words with a clock running." Three rules that cost nothing to follow:

• Do not sit it the day before something that matters. The report deadline keeps running while you sleep. A six-hour technical exam followed by an all-nighter is a bad way to produce a graded document, and it is entirely avoidable at booking time.
• Start early in your own day. A window that begins at 09:00 ends at 15:00 and leaves you the whole evening for a first draft while everything is fresh. A window that begins at 16:00 ends at 22:00 and hands your report to a version of you that has been concentrating since lunchtime.
• Sit it while the labs are still live. The package includes a bounded lab-access period. Booking the exam for a date when you can still return to a practice environment afterwards — to check a syntax you half-remember writing — is worth more than it sounds.

The week before — a machine, a connection, and a kit

☺ Like you're 10: The exam lives in your web browser, so the only equipment you have to get right is the browser, the internet, and a place to keep your screenshots.

Practical DevSecOps deliver the labs and the exam through the browser — their course package describes "browser-based labs", and every first-hand account works inside that environment rather than on a downloaded VM. That is good news for setup, because there is no exam client to install and no virtualisation to configure. It also means your entire technical exposure on the day is a browser and a network link, so those are the two things worth rehearsing.

The machine

• Use a machine you control. A locked-down corporate laptop with aggressive endpoint security, a mandatory VPN, or an outbound proxy that mangles WebSocket traffic is the classic cause of a browser-based lab behaving strangely. If your only machine is a work machine, open the practice labs on it well before exam day and confirm the terminal in the browser actually works.
• Rehearse in the browser you will use. Practice in the same browser, same profile, same extensions. Then, on the day, disable the extensions — ad blockers and script blockers are a genuinely common cause of an in-browser terminal or console failing to connect, and diagnosing that at minute four of a six-hour clock is a waste of six minutes you cannot spare.
• Give yourself screen space. Nothing published restricts what displays you may use. A second screen for your notes and evidence folder, with the lab on the primary, is the single largest quality-of-life difference available to you — and it is exactly the setup a proctored exam would forbid, which is why it is worth saying out loud.
• Sort out your keyboard layout and clipboard now. Browser terminals and copy-paste have a long history of disagreeing with each other. Find out how yours behaves during practice, not during the exam.

The connection

Raw speed is rarely the problem. A browser-based terminal is an interactive stream, so stability is what hurts: a link that stutters for four seconds every couple of minutes will cost you more real time across six hours than a link that is merely slow. Measure it rather than guessing, at the same time of day you have booked.

ping -c 20 1.1.1.1

curl -o /dev/null -s -w 'dns=%{time_namelookup}s connect=%{time_connect}s ttfb=%{time_starttransfer}s total=%{time_total}s\n' https://www.practical-devsecops.com/

mtr --report --report-cycles 50 1.1.1.1

Then sample it across a window long enough to be representative, and count the gaps rather than eyeballing a graph:

# one latency sample per second for 30 minutes, then count the drops
for i in $(seq 1 1800); do
  printf '%s ' "$(date +%H:%M:%S)"
  ping -c 1 -W 2 1.1.1.1 2>/dev/null | awk -F'time=' '/time=/{print $2; ok=1} END{if(!ok) print "PACKET-LOSS"}'
  sleep 1
done | tee ~/cdp-link-check.log

grep -c 'PACKET-LOSS' ~/cdp-link-check.log

If that count is anything but zero, fix it before the day: plug into ethernet, move the router, or move the booking. And on the day itself take the obvious precautions — pause cloud sync and backups, defer OS updates, close the video calls, and have a phone-tethering fallback ready that you have actually tested once.

What may be on your desk

Here is the part of a conventional exam-day page that inverts completely. No published Practical DevSecOps policy restricts what is on your desk, and no first-hand account describes one. Every account treats notes and personal cheatsheets as normal — Diogo Pereira, whose July 2024 write-up is the most recent verified first-hand account, names building personal cheatsheets of code snippets as his main piece of preparation advice, alongside reading the vendor's PDF manuals next to the videos and planning the time split across exercises before starting.

So the desk question changes shape. It stops being "what am I allowed" and becomes "what will I actually reach for, and can I reach it in under ten seconds." A pile of half-organised bookmarks is not an asset under a clock. Build the kit deliberately:

Nutty's evidence kit — build it before the day, not during it

The report is graded, the environment disappears, and the capture has to happen inside the six hours. That combination means your evidence workflow should be muscle memory before you start, not something you invent at hour one. Set the whole thing up on your own machine the week before and rehearse a full lab in it.

mkdir -p ~/cdp-exam/{c1,c2,c3,c4,c5}/{shots,output,config} ~/cdp-exam/report

cat > ~/cdp-exam/report/NOTE-TEMPLATE.md <<'EOF'
## Challenge N — <one-line title>

**The finding.** What is wrong, where, and how I know it is real.
**Proof it was real.** Command run + output/screenshot showing the vulnerable state.
**What I changed, and why.** The diff or config, plus the reasoning for this fix over others.
**Proof it is fixed.** The re-run, the exit code, the blocked build, the clean scan.
**Residual risk / what I would do next.** Honest, short.
EOF

cp ~/cdp-exam/report/NOTE-TEMPLATE.md ~/cdp-exam/report/c1.md

ls -R ~/cdp-exam | head -20

Two habits on top of the folders, both of which have to be automatic:

# 1. record the terminal session so no command is ever lost to scrollback
script -q -f ~/cdp-exam/c1/output/session.log

# 2. tee every scan, so the machine-readable artefact exists whether or not you remember to save it
trivy image --format json --output ~/cdp-exam/c1/output/sca-before.json myapp:latest
semgrep --config auto --json --output ~/cdp-exam/c1/output/sast-before.json .
zap-cli report -o ~/cdp-exam/c1/output/dast-before.html -f html

# 3. after the fix, the same commands again with -after names — the pair IS the evidence
trivy image --format json --output ~/cdp-exam/c1/output/sca-after.json myapp:latest

The naming convention matters more than the tooling. Before and after, per challenge, in a folder named for that challenge. A marker reading your report should be able to follow a claim to a file without asking you a question, and you should be able to find that file at hour twenty of the report window without opening it to check what it is.

The first fifteen minutes

☺ Like you're 10: Do not start fixing the first thing you see. Read all five problems first, so you know which ones you are good at and which one is going to be trouble.

The opening of the window is the highest-leverage quarter-hour of the whole exam, and it is almost entirely spent not solving anything. Two of the published accounts converge on the same first move, and it is the one most candidates skip because it feels like stalling.

Najib Radzuan's advice, from his August 2020 review and study guide, is to "Read all the questions 1st to give your rough idea" — and his reason is the interesting part: he describes the challenges as interconnecting rather than standing alone, so what you learn in challenge four can change how you approach challenge two. Diogo Pereira independently advises planning the time allocation across the exercises before starting. Same move, two candidates, four years apart.

A start-of-window sequence

Two notes on the ordering decision itself. First, bank the cheap points early: if reading the five tells you that challenge three is squarely in something you have done twenty times, do challenge three first and put a solid, fully evidenced result in the bag before anything has a chance to go wrong. Second, do not let "start with the hardest while you are fresh" logic win here. That is sound advice on an exam where you can afford to lose an item. On five challenges at eighty percent, with two documented cases of challenge one eating an implausible share of the clock, the risk of opening with the hardest thing is that it takes the whole exam and you never find out you could have done the other four.

How the environment behaves

☺ Like you're 10: The exam runs inside a website. The tools are real. And when the six hours end, the whole thing switches off and you cannot go back in.

The environment is browser-based and, by every account, a real working environment rather than a simulation: the tools you would use at work, running against targets you can actually break and fix. The published prerequisites are modest — the vendor states basic Linux command knowledge and a foundational understanding of application security concepts like the OWASP Top 10 — and the tools named across the accounts are the ordinary DevSecOps toolchain. Vinit Patil's write-up names GitLab CI/CD, SCA, SAST and DAST tooling, Docker, Ansible, InSpec, Linux hardening and DefectDojo; Ishaq Mohammed describes "5 challenges with sub-challenges for each." That is the shape to expect: not five isolated puzzles, but five areas each with several things to do inside them.

Access ends with the clock — the one rule to build the day around

Copying things out is harder than you expect

Mikayel Mardanyan Petrosyan, in a critical May 2024 review written after passing, reports that a newer version of the platform's interface blocked text selection — "copying content was impossible in some cases" — and dropped dark mode. That is one candidate's experience of one version of a UI that has changed before and will change again, so do not treat it as the current state of the platform. Treat it as a risk to have a plan for, because the plan costs nothing:

• Write output to files inside the environment first, then move the files, rather than selecting text on screen. tee, --output flags and redirection do not care whether the page allows selection.
• Screenshot generously. A screenshot is immune to a copy restriction, costs a second, and is what a report wants anyway. Storage is not your constraint here; recoverability is.
• Keep your own working notes outside the exam UI, in your own editor, on your own machine, where you can definitely copy from them.
• Do not rely on scrollback. A recorded session (script) or a redirected log survives a browser tab closing; a terminal buffer does not.

Expect tools you have not practised on

This is the framing that most changes how people prepare, and it comes from Tess Sluijter, who declined to give specifics about the exam content citing the NDA but was willing to describe the shape of it. Her March 2021 write-up says to expect other tools — SAST, DAST and so on — than the ones used in the labs, more advanced features of the tools that were used, and different languages than the ones practised on. She compares the required mindset to the OSCP: the concepts are the same, but you will need to do research on the job.

That is a genuinely different exam-day posture from "have I memorised the flags." It means the skill under test is partly transfer — recognising that this unfamiliar scanner is a SAST tool, that it therefore has a config file, a ruleset, a severity threshold and a machine-readable output format, and that --help will tell you what they are called here. It also means the in-environment fallbacks are worth rehearsing until they are reflex, because they are what you will actually be doing when the tool is one you have never opened:

somescanner --help | head -40

somescanner scan --help

man somescanner 2>/dev/null | head -60

ls /etc/somescanner* /usr/share/somescanner* 2>/dev/null
find / -maxdepth 4 -name '*somescanner*' 2>/dev/null | head

somescanner --version && somescanner scan --format json --output /tmp/out.json .

Nothing there is clever. It is the habit of reaching for the tool's own documentation instead of a search engine, and the reason it matters on this exam specifically is that a chatbot is not available to translate for you. This site's troubleshooting & triage playbook is the drill for it, and the practice challenge bank is where to rehearse it against a clock. If you want to make the transfer skill explicit in practice, do one lab deliberately with the "wrong" scanner — swap the one the lab expects for a comparable tool you have never used, and make it produce the same evidence.

Time management inside a six-hour window

☺ Like you're 10: Six hours sounds like a lot. It is five problems, plus taking all the photographs, plus writing notes — so it is not.

Here is the arithmetic nobody enjoys. Six hours is 360 minutes. Five challenges is 72 minutes each if they were equal, which they are not. Now subtract the fifteen-minute opening, a closing sweep, and — the part almost everyone forgets — the evidence capture, which happens inside these same 360 minutes and not afterwards. What is left is comfortably under an hour of actual problem-solving per challenge.

That last point is Petrosyan's structural criticism of the exam, and whatever you think of the rest of his review, this observation is sound and worth internalising: evidence-gathering and documentation happen inside the hands-on window, so the usable slack is smaller than the headline number suggests. A candidate who reads "six hours for five challenges" and hears "seventy-two minutes each" has mis-budgeted before they have started.

The ceiling, decided in advance

A per-challenge ceiling is the only mechanism that reliably prevents the documented failure mode. Pick a number during the orientation window — something in the region of fifty-five to sixty minutes, adjusted to what your own rehearsals actually take — and when a challenge hits it and you are not visibly two edits from done, you stop, write down exactly where you are, save whatever partial evidence exists, and move on. Mid-thought. Without negotiating.

Two things make this bearable rather than agonising. The first is that a challenge you leave at minute fifty-five is not abandoned — you have a written note saying precisely what remains, so returning to it later costs a fraction of what starting it cost. The second is that leaving it is a decision you made calmly at minute fifty-five, whereas continuing is a decision you will be making again at minute seventy, ninety and a hundred and ten, each time under worse conditions and with less information.

# a day-log you keep on your own machine, one line per event, appended as you go
log() { printf '%s  %s\n' "$(date +%H:%M)" "$*" | tee -a ~/cdp-exam/report/daylog.txt; }

log "window opened"
log "read all 5 — order chosen: C3, C1, C5, C2, C4 — ceiling 55m"
log "C3 start"
log "C3 before-evidence captured (shots/03-before.png, output/sast-before.json)"
log "C3 fix applied — pipeline gate now fails on fixable HIGH"
log "C3 verified — exit code 1, after-scan clean; note written"
log "C3 done at 51m — under ceiling"
log "C1 start"
log "C1 CEILING HIT at 55m — moving on. Remaining: policy blocks plan but message is wrong"

That log is doing three jobs at once, which is why it is worth the two seconds a line costs. It enforces the ceiling by making elapsed time visible. It becomes the spine of your report — the chronology is already written. And if something goes wrong and you need to raise it with the vendor, you have times.

The reset break

Vinit Patil describes taking a break during his four-hour challenge one to reset. Under a twelve-hour clock that is a reasonable move; under six it is expensive, but the underlying problem it solves is real — an engineer who has been stuck on the same thing for fifty minutes is usually not making progress, and staring harder is not a technique.

The cheap version of the same reset is the ceiling itself. Moving to a different challenge is a break: it is a genuine context switch, it is productive, and it very often returns you to the stuck problem an hour later with the answer already obvious. If you would rather stand up and walk around for five minutes, do it deliberately at a block boundary rather than as an escape from frustration — and remember that nothing published suggests the clock stops for anything.

Verify, then evidence, then move

The sequence inside a block matters and is easy to get wrong under pressure. It is fix → verify → evidence → note → move, and the two steps people collapse are the middle ones.

• Verify means the system says so, not that you believe so. Re-run the scan and show it clean. Trigger the pipeline and show the build fail on the right condition. Apply the plan and show the policy block it. Read the exit code. "I changed the config" and "I changed the config, and here is the run proving it took effect" are different claims, and only the second one is worth points on an exam that grades a report.
• Evidence means the artefact is on your machine. Not visible on screen, not in scrollback — saved, named, in the right folder. This is the step the clock steals if you let it, and it is the one you cannot repeat later.

The report — the graded half that happens after the exam

☺ Like you're 10: When the six hours end you have not finished. You still have to write the story of what you did, with pictures, and hand it in by the next day.

The vendor states that "after the exam, you have about 24 hours to submit the exam report on our internal portal," and that the report is what gets evaluated. Every first-hand account treats it as a substantial piece of work rather than a formality. It is the part of this exam that has no equivalent on a Linux Foundation performance test, and it is where candidates who did the technical work correctly still lose the marks for it.

What the accounts say a report has to contain

The most concrete published description comes from Najib Radzuan, who lists what he put in his: step-by-step instructions, the configuration files themselves — he names GitLab CI/CD YAML and Ansible playbooks — screenshots, and machine-readable output such as JSON or XML. His emphasis falls squarely on the last two, which he reminds the reader are "both very important" to a CDP report.

Read that as a specification of four artefact types, all of which have to be captured inside the six-hour window:

If your evidence folders contain all four types for every challenge, the report window is an assembly-and-polish job. If they contain only screenshots, it is a writing job with gaps in it. If they contain only your memory, it is not a job that can be done well.

Write it in the window, assemble it after

The four-line note from Nutty's template is not a nice-to-have; it is the report, written in pieces, at the only time the material for it is available. By the end of the six hours you should be holding five short notes and five folders. The twenty-four hours are then spent turning notes into prose, checking that every claim points at a file, and formatting.

# at the end of the window, before you close anything — does the evidence actually exist?
cd ~/cdp-exam

for c in c1 c2 c3 c4 c5; do
  printf '%-4s shots=%-3s output=%-3s config=%-3s note=%s\n' "$c" \
    "$(ls "$c"/shots 2>/dev/null | wc -l)" \
    "$(ls "$c"/output 2>/dev/null | wc -l)" \
    "$(ls "$c"/config 2>/dev/null | wc -l)" \
    "$( [ -s "report/$c.md" ] && echo yes || echo MISSING )"
done

du -sh ~/cdp-exam

Run that with twenty minutes left on the clock, not with twenty seconds. A zero in any column is a question you can still answer while the environment is up, and cannot answer at all once it is down.

The template friction, and how to not meet it at midnight

Petrosyan reports a specific, small, entirely avoidable annoyance: the report template was shared as a Google Docs link that turned out to be a Word document, which was awkward to work with on Linux. Whether that is still how it arrives is unknown, and it is exactly the kind of detail that changes between cohorts. The point is not the format; it is that the moment to discover what format your report has to be in is the day you book, not the evening after a six-hour exam.

• Find the template and the submission route before exam day. Open it, look at its headings, and shape your note template to match them so that assembly is copy-paste rather than restructuring.
• Confirm the file format and how it is submitted. If it is a word processor document and you live in a terminal, have a working editor for it installed and tested — not downloaded at hour twenty-two.
• Check how images are meant to be embedded. Forty screenshots is a lot of dragging if the format fights you, and a lot less if you know in advance.
• Submit with hours in hand. "About 24 hours" is what the vendor says; portals have queues, uploads fail, and a deadline you meet at the last minute is one you did not really meet.

When something goes wrong

☺ Like you're 10: Things break. Tell someone straight away, write down the time, and keep going on something else while you wait.

Three things are worth knowing before you need them: support does respond during the exam, its answers are not public, and none of it stops the clock unless someone decides it should.

Support responds — a real data point

Diogo Pereira describes his own exam as "quite good and relaxed since I was very well prepared," and reports hitting minor technical issues at the start — after which Practical DevSecOps extended his time by one hour to compensate. That is the most useful thing anybody has published about failure handling on this exam, and it establishes three facts worth acting on. Support is reachable during the window. Genuine platform problems have been compensated for. And the compensation happened because he raised it at the start, not because he mentioned it afterwards.

It is one candidate's experience and not a published policy, so do not plan a schedule that assumes an extension. Do, however, plan the behaviour that made it possible: report a problem the moment you are confident it is a problem and not you, in writing, with times.

Support answers privately — so keep your own record

Petrosyan notes that the Mattermost support channel answers privately rather than in the open. As a criticism of a learning community that is a fair complaint; as an exam-day fact it has a practical consequence. Nothing about your exchange with support is visible to anyone else, and no shared thread exists that you can point at later. So take your own record: screenshot the message you sent, note the time you sent it, note the time of the reply, and put both in your day log. If a dispute about lost time ever arises, that log is your entire case.

A triage table for the day

After you submit

☺ Like you're 10: Someone reads your report, then emails you. If you passed, the certificate comes within a few days — and it does not expire.

Practical DevSecOps state that "students who passed the exam will receive their certificate by email within 72 hours." That is a stated turnaround after evaluation, not a promise about how fast marking begins. In practice it has sometimes been much quicker: Joshua Jebaraj's 2020 write-up reports his certificate arriving the next day. Treat 72 hours as the figure to plan around and anything faster as a pleasant surprise.

Three things about what comes next:

• The credential is described as a lifetime one. No renewal period is published, and this page will not invent one. If a job specification tells you the CDP expires, check it against the vendor's page rather than the specification.
• A retake is priced separately — the vendor's retake page lists US$100 at the time of writing. No attempt cap or waiting period was found published, which is not the same as there being none. Confirm before you plan around it.
• The exam is under NDA. Sluijter explicitly declined to give specifics about content, citing it. That is the norm across the accounts and it is why even the most detailed write-ups describe shape and technique rather than challenges. Extend the same courtesy when it is your turn — and note in passing that this is precisely why the published corpus is thinner on content than on process, and why a page like this one can be specific about logistics and cannot be specific about what you will be asked.

And if you did not pass: the report you wrote is the most honest study document you will ever own, because it is a record of exactly what you could and could not evidence under a clock. Read it against your confidence ledger, rebuild the two weakest areas against the capstone lab track and the practice challenge bank, and re-sit while the environment is still fresh in your hands.

What this page refuses to guess

☺ Like you're 10: Here is a list of things nobody has published. If another website tells you the answer confidently, it is probably making it up.

An exam-day page is judged on the questions it answers and on the ones it declines to. These are the open ones, and the honest answer to each is the same: your own booking materials outrank anything on this site.

Where to go from here

☺ Like you're 10: This page is the day itself. These pages are everything that has to happen before it.

None of this is the hard part. The hard part is the nine chapters, the reps, and being able to make a gate fail on the right condition with nobody to ask. But exam-day process is the cheapest place on the whole journey to lose an exam you had already earned — and on this one, unusually, the process risk is not a proctor's rulebook. It is a laboratory that switches off on schedule and a report that has to be written without it. Prepare for that specific thing, work the exam-prep checklist, and confirm every number here against the vendor's own exam page before you book.