Mock Exam · Set 1 — five challenges, one live environment, six hours

This is the closest a static page can get to sitting the real Certified DevSecOps Professional exam: 5 challenges, 100 points, an 80-point bar, and one unbroken 6-hour block, all against a single shared fictional target — a small reporting SaaS this page calls Orbit — the way the real CDP hands you one live environment rather than five disconnected quizzes. Each challenge below gives you the exact vulnerable artifact (a manifest, a source file, a Terraform module, a host config) to reproduce yourself, a set of scored tasks with a done-when check, and a full worked solution folded behind a summary so you can grade honestly instead of guessing. This page only simulates the 6-hour challenge window — the separate 24-hour report window that follows it in the real exam is covered on the CDP exam page, not here. If you haven't built the underlying skill yet, start with the study plan and the exam blueprint first; this paper measures whether you can execute it under a clock, not whether you've read about it.

How this paper works, and where it sits in your prep

☺ Like you're 10: This is a full practice concert, not five separate practice songs — the same five skills you've drilled separately, now back to back, on a clock that doesn't wait for you.

Practical DevSecOps doesn't publish a percentage breakdown across its five live challenges — the CDP exam page already makes that point, and this paper takes it seriously rather than inventing a precision the vendor itself doesn't claim. So every challenge below is weighted the same: 20 points each, split across four 5-point tasks per challenge. The five challenges are Software Composition Analysis, Static Analysis & Secrets Detection, Dynamic Analysis (DAST), Infrastructure as Code Hardening, and Compliance as Code — the same five areas the exam page names as what the real challenges likely draw on. This is Set 1 of four; Sets 2, 3, and 4 are separate, unseen papers, held back on purpose so you have fresh material for later rehearsals instead of re-solving today's answers from memory.

Before you start — build each target yourself

☺ Like you're 10: There's no download link for "the broken workshop" — you build the mess yourself, from the exact instructions in each challenge, so the fix you find is a fix you actually earned.

Unlike the real CDP, this page has no vendor-hosted environment behind it — it can't, being a static site. What it gives you instead is the exact vulnerable artifact for every challenge: a requirements.txt, a source file, a Terraform module, a host config. Recreate each one in a scratch directory as you reach it, so the finding you produce and the fix you apply are both real, not read. Confirm every tool below actually runs before you start the clock — a missing binary mid-challenge is time you don't get back:

# --- ninety seconds before the clock starts ---------------------------
trivy --version          # or: dependency-check.sh --version      -- SCA
semgrep --version         && gitleaks version && trufflehog --version   # SAST & secrets
docker run --rm zaproxy/zap-stable zap-baseline.py -h | head -1   # DAST
checkov --version          && tfsec --version && conftest --version   # IaC
inspec version              && oscap --version                  # compliance-as-code

# anything that 404s here is a tool you install now, not mid-challenge
mkdir -p ~/orbit-mock1/{sca,sast,dast,iac,compliance} && cd ~/orbit-mock1

Exam conditions for this sitting

☺ Like you're 10: Same rules as the real thing — one timer, no pausing, and no peeking at the worked solution until you're actually stuck or actually done.

One timer, started once. 6 hours. You don't pause it to install a missing tool, fix a typo'd Terraform block, or answer a phone call — losing ten minutes to your own laptop is exactly the kind of friction the real exam won't refund either. No peeking at a worked solution before you've either solved the task or burned its budget. Reading the answer first turns a diagnostic into a comprehension exercise — you'll feel productive and learn nothing about your own pacing, then repeat the same stall on exam day. Skim all 5 challenge briefs before touching a terminal — five minutes spent up front is the highest-return five minutes of the whole sitting, because it tells you which challenge you're already strong on and which one is going to eat the clock.

Your time budget across the 6-hour window

☺ Like you're 10: Give every station in the workshop its own fair slice of the six hours, plus a little extra at the end just for double-checking your work.

Six hours is 360 minutes. Reading and orientation take 15, a verification-and-note-taking buffer at the end takes 45, and the remaining 300 split unevenly across the five challenges — DAST gets the largest share because authenticating a spider and manually confirming an IDOR genuinely takes longer than diffing a Terraform block, the same real-world asymmetry the exam page's own tactics section describes.

Challenge 1 — Software Composition Analysis (20 points)

☺ Like you're 10: Before you touch a single line of Orbit's own code, check every part it borrowed from someone else against the recall list.

Scenario. Orbit's reporting-service is a small Flask app. Recreate its dependency manifest exactly as shown, and a config loader that reads an uploaded YAML file:

# requirements.txt
Flask==2.0.1
PyYAML==5.3.1
requests==2.25.1
setuptools==59.6.0
gunicorn==20.1.0

# app/report_config.py
import yaml

def load_report_config(uploaded_file):
    # Called from POST /reports/import — no auth check runs before this line.
    return yaml.load(uploaded_file.read(), Loader=yaml.Loader)

$ dependency-check.sh --project orbit-reporting --scan . --format JSON --out dc-report/
# or: trivy fs --scanners vuln --severity HIGH,CRITICAL .

PyYAML:5.3.1
  CVE-2020-14343  CVSSv3: 9.8 (CRITICAL)  fixed in: >=5.4
  → yaml.load() without an explicit safe Loader permits arbitrary code execution
    from a crafted YAML file.

setuptools:59.6.0
  CVE-2022-40897  CVSSv3: 7.5 (HIGH)  fixed in: >=65.5.1
  → ReDoS in package_index.py's HTML parsing.

$ grep -rn "yaml.load" app/
app/report_config.py:6:    return yaml.load(uploaded_file.read(), Loader=yaml.Loader)

# requirements.txt
-PyYAML==5.3.1
+PyYAML==6.0.1

# app/report_config.py
-    return yaml.load(uploaded_file.read(), Loader=yaml.Loader)
+    return yaml.safe_load(uploaded_file.read())

<!-- suppression.xml -->
<suppress>
  <notes>CVE-2022-40897 — ReDoS in setuptools' package_index.py HTML parsing.
    Build-time-only code path; never invoked at runtime in the production image.
    Accepted risk, ticket ORBIT-482, review by next quarterly dependency sweep.</notes>
  <packageUrl regex="true">^pkg:pypi/setuptools@.*$</packageUrl>
  <cve>CVE-2022-40897</cve>
</suppress>

$ dependency-check.sh --project orbit-reporting --scan . --suppression suppression.xml --failOnCVSS 9
# exits 0 — the critical is fixed, the high is suppressed with a reason on file

Challenge 2 — Static Analysis & Secrets Detection (20 points)

☺ Like you're 10: Read Orbit's own code the way a proofreader would, and check whether anyone ever left a key lying around in the drafts.

Scenario. Recreate Orbit's billing module:

# app/billing.py
def get_invoice(customer_id):
    query = "SELECT * FROM invoices WHERE customer_id = '" + customer_id + "'"
    return db.execute(query).fetchall()

Then simulate a leaked credential: commit a file, leak a fake-but-realistic AWS key inside it, then remove it in a later commit — which is exactly the mistake that leaves it recoverable from git history:

$ git init orbit-billing && cd orbit-billing
$ printf 'AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE\nAWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY\n' > deploy/staging.env
$ git add -A && git commit -m "add staging deploy env"
$ git rm deploy/staging.env && git commit -m "remove staging env from repo"
# the key is gone from the working tree, but it's still sitting in the commit six lines up

$ semgrep --config=auto app/billing.py

app/billing.py:3
  python.lang.security.audit.formatted-sql-query.formatted-sql-query
  Detected possible SQL injection using string concatenation. Use parameter
  binding instead.

$ trufflehog git file://. --only-verified

Found verified result 🐷🔑
Detector Type: AWS
Verified: true
Commit: a1b2c3d "add staging deploy env"
File: deploy/staging.env
Raw: AKIAIOSFODNN7EXAMPLE

-    query = "SELECT * FROM invoices WHERE customer_id = '" + customer_id + "'"
-    return db.execute(query).fetchall()
+    return db.execute(
+        "SELECT * FROM invoices WHERE customer_id = %s", (customer_id,)
+    ).fetchall()

# 1. rotate first — the key stops working immediately, regardless of git history
$ aws iam update-access-key --access-key-id AKIAIOSFODNN7EXAMPLE --status Inactive
$ aws iam delete-access-key --access-key-id AKIAIOSFODNN7EXAMPLE
$ aws iam create-access-key --user-name orbit-staging-deploy

# 2. purge second — now the history rewrite is cleanup, not the only safeguard
$ git filter-repo --path deploy/staging.env --invert-paths
# coordinate a force-push and tell every clone to re-fetch — a rewritten history
# doesn't self-propagate to clones nobody warned

# .github/workflows/security.yml
jobs:
  sast-and-secrets:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with: { fetch-depth: 0 }   # secrets scan needs full history, not a shallow clone
      - run: semgrep ci --config=auto --error
      - uses: gitleaks/gitleaks-action@v2

Challenge 3 — Dynamic Analysis / DAST (20 points)

☺ Like you're 10: Stop reading the blueprints — go attack the finished, running building the way a real intruder would, from the outside, with no floor plan.

Scenario. Run Orbit's app locally (any small Flask/Node app with a login form and an /api/invoices/<id> route reproduces this well enough) at http://localhost:5000, and give it exactly one bug on purpose: the invoices endpoint never checks that the requested invoice actually belongs to the logged-in session.

# app/api.py — the bug: no ownership check before returning the record
@app.get("/api/invoices/<int:invoice_id>")
@login_required
def get_invoice_api(invoice_id):
    invoice = Invoice.query.get_or_404(invoice_id)
    return jsonify(invoice.to_dict())   # returns it regardless of whose session this is

$ docker run --rm -v $(pwd):/zap/wrk/:rw -t zaproxy/zap-stable zap-baseline.py \
  -t http://localhost:5000 -r zap-baseline-report.html -I

env:
  contexts:
    - name: "orbit"
      urls: ["http://localhost:5000"]
      authentication:
        method: "form"
        parameters:
          loginPageUrl: "http://localhost:5000/login"
          loginRequestUrl: "http://localhost:5000/login"
          loginRequestBody: "email={%username%}&password={%password%}"
        verification:
          method: "response"
          loggedInRegex: "\\QDashboard\\E"
          loggedOutRegex: "\\QPlease log in\\E"
      users:
        - name: "customer-a"
          credentials: { username: "a@orbit.test", password: "$ORBIT_TEST_PW" }
jobs:
  - type: spider
    parameters: { context: "orbit", user: "customer-a" }
  - type: activeScan
    parameters: { context: "orbit", user: "customer-a" }

$ curl -s -H "Cookie: session=$CUSTOMER_A_SESSION" \
  http://localhost:5000/api/invoices/1042 | jq '.customer_id'
1041
# customer A's own session, requesting invoice 1042 — which belongs to customer 1041, not A

@app.get("/api/invoices/<int:invoice_id>")
@login_required
def get_invoice_api(invoice_id):
    invoice = Invoice.query.get_or_404(invoice_id)
    if invoice.customer_id != current_user.customer_id:
        abort(403)
    return jsonify(invoice.to_dict())

$ curl -s -o /dev/null -w "%{http_code}\n" -H "Cookie: session=$CUSTOMER_A_SESSION" \
  http://localhost:5000/api/invoices/1042
403

Challenge 4 — Infrastructure as Code Hardening (20 points)

☺ Like you're 10: Catch the mistake in the building's blueprint before the building actually gets built — a misconfigured plan is cheaper to fix than a misconfigured bucket that's already public.

Scenario. Recreate Orbit's storage-and-network module:

# infra/main.tf
resource "aws_s3_bucket" "reports" {
  bucket = "orbit-customer-reports"
  acl    = "public-read"
}

resource "aws_security_group" "app" {
  name = "orbit-app-sg"

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

$ checkov -d infra/ --framework terraform

Check: CKV_AWS_20 "S3 Bucket has an ACL defined which allows public READ access"
  FAILED for resource: aws_s3_bucket.reports
Check: CKV_AWS_19 "Ensure the S3 bucket has server-side encryption enabled"
  FAILED for resource: aws_s3_bucket.reports
Check: CKV_AWS_21 "Ensure the S3 bucket has versioning enabled"
  FAILED for resource: aws_s3_bucket.reports
Check: CKV_AWS_24 "Ensure no security groups allow ingress from 0.0.0.0/0 to port 22"
  FAILED for resource: aws_security_group.app

resource "aws_s3_bucket" "reports" {
  bucket = "orbit-customer-reports"
}

resource "aws_s3_bucket_public_access_block" "reports" {
  bucket                  = aws_s3_bucket.reports.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

resource "aws_s3_bucket_server_side_encryption_configuration" "reports" {
  bucket = aws_s3_bucket.reports.id
  rule {
    apply_server_side_encryption_by_default { sse_algorithm = "aws:kms" }
  }
}

resource "aws_s3_bucket_versioning" "reports" {
  bucket = aws_s3_bucket.reports.id
  versioning_configuration { status = "Enabled" }
}

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
-   cidr_blocks = ["0.0.0.0/0"]
+   cidr_blocks = ["203.0.113.0/24"]   # the office/VPN egress range, not the whole internet
  }

# policy/ssh_exposure.rego
package terraform.security

deny[msg] {
  some i
  input.resource_changes[i].type == "aws_security_group"
  rule := input.resource_changes[i].change.after.ingress[_]
  rule.from_port <= 22
  rule.to_port >= 22
  rule.cidr_blocks[_] == "0.0.0.0/0"
  msg := sprintf("%s opens SSH to the whole internet", [input.resource_changes[i].address])
}

$ terraform show -json tfplan.binary > plan.json
$ conftest test plan.json -p policy/
FAIL - plan.json - terraform.security - aws_security_group.app opens SSH to the whole internet
# ...fix applied, re-plan, re-test...
$ conftest test plan.json -p policy/
0 tests, 0 failures, 0 exceptions

Challenge 5 — Compliance as Code (20 points)

☺ Like you're 10: Handing an auditor "trust me" isn't proof. Handing them a checklist that a computer ran, with a timestamp, is.

Scenario. Orbit's staging host needs two CIS Ubuntu controls proven and, right now, fails both: SSH allows root login, and password aging isn't enforced.

$ inspec exec dev-sec/linux-baseline -t ssh://deploy@staging-host \
  --reporter cli json:results/staging-host.json

  ×  sshd-01: SSH root login should be disabled
     ×  PermitRootLogin is expected to cmp == "no"
        expected: "no"
             got: "yes"
  ×  os-05: Password maximum age should be 90 days or less
     ×  PASS_MAX_DAYS is expected to cmp <= 90
        expected: <= 90
             got: 99999

Profile Summary: 39 successful controls, 2 control failures, 0 controls skipped

$ ssh deploy@staging-host 'sudo sed -i "s/^#\?PermitRootLogin.*/PermitRootLogin no/" /etc/ssh/sshd_config && sudo systemctl reload sshd'
$ ssh deploy@staging-host 'sudo sed -i "s/^PASS_MAX_DAYS.*/PASS_MAX_DAYS   90/" /etc/login.defs'
$ inspec exec dev-sec/linux-baseline -t ssh://deploy@staging-host --reporter cli
Profile Summary: 41 successful controls, 0 control failures, 0 controls skipped

$ oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis_level1_server \
  --results results.xml --report report.html --results-arf arf.xml \
  /usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xml

$ saf convert inspec2hdf -i results/staging-host.json -o hdf/inspec.json
$ saf convert oscap2hdf -i arf.xml -o hdf/oscap.json
$ saf validate threshold -i hdf/inspec.json -F threshold.yml   # gates the pipeline on the result

Score yourself

☺ Like you're 10: Add up your points, compare to the 80 line, then look at which questions cost you — that second part is the part that actually helps.

Mark after a short break, not immediately — adrenaline makes for generous self-grading. Award full points only when the done-when check in the table above genuinely passed, half when the artifact exists and is broadly right but the check didn't pass clean, and zero for anything unattempted. "I knew how to do that one" earns nothing that a passing check doesn't already prove.

Computing your result. The points total 100, so your raw score is your percentage, and the bar is 80. That leaves 20 points spendable — a full challenge's worth. Then do the more useful arithmetic and total each challenge separately, because an 80 built from four clean challenges and one zero is a genuinely worse outcome than an 80 spread evenly, even though the number is identical — the first candidate has a hard blind spot, the second has an even, shallow gap.

What each miss means

☺ Like you're 10: There are three different reasons to lose a point, and each one needs a different fix — guessing the wrong one wastes a week of studying the wrong thing.

Sort your zeros and halves into three piles before you decide what to re-study. A task you didn't recognize at all is a genuine knowledge gap — go read the chapter linked above, then redo that exact task cold in two or three days. A task where you knew the shape but burned the clock hunting for flag syntax or a field name is a speed problem, not a knowledge one, and the cure is Know It Cold and the command & tool reference, not another read of the chapter. A task that broke in a way you couldn't diagnose — a scan that errored, a tool that returned nothing — is a triage gap, and the triage playbook is built for exactly that. And one thing sits outside all three: count how many tasks you left completely untouched. More than three or four, and the honest diagnosis is pacing, not knowledge — you never got to spend points you actually had.

After this sitting

☺ Like you're 10: Only re-practice the parts you actually got wrong, and save the next full concert for a couple of weeks from now.

Resist re-drilling everything — the entire value of a scored paper is that it tells you where not to spend your next week. Take your one or two weakest challenges, work only those sections of the practice challenge bank and the matching capstone lab part, and leave the challenges you cleared alone — re-solving something you already proved you can do is comfort, not preparation. When you're ready for the next fresh sitting, move to Set 2; leave Set 3 and Set 4 sealed until closer to your real exam date. For the logistics of the actual day — registration, the two-clock structure, and what the report window expects — the CDP exam page covers all of it.

That's the paper. Build each artifact yourself, start one timer, and let the five challenges above take you through a six hours that should feel noticeably less comfortable than working through the blueprint chapters untimed. Score it honestly, note your weakest challenge, and spend the next stretch of your schedule exactly there — then come back for Set 2 when you're ready, or head to the course home to pick up wherever the blueprint left off.