The Practice Challenge Bank

The CDP hands you a broken environment and a task list, not four bubbles to pick between. So this page does the same: eight self-contained challenges, one per blueprint domain, each built the way the real exam is built — a scenario that explains why the environment is in the state it's in, a numbered task list, a "done when" check you run yourself, a worked solution behind a spoiler, and a points-based rubric so you can score your own attempt honestly without anyone standing over your shoulder. There is no multiple choice on this page, on purpose. Work each one cold, timed, and unaided first — the worked solution is for after you've genuinely tried, not instead of trying.

How to drill this bank

☺ Like you're 10: Try it yourself first, with a timer running. Only peek at the answer once you're stuck or finished — peeking first teaches your eyes to recognize, not your hands to build.

Reading a worked solution feels like progress and mostly isn't — the CDP doesn't ask you to recognize correct YAML or a correct sed one-liner, it asks you to produce one, against a live environment, with the clock running and no chatbot allowed. Four rules keep this bank honest:

• Attempt cold. Empty terminal, no half-finished file left over from last time. That's how the exam starts you.
• Time-box it. Give each challenge 45–70 minutes on a first pass — the real exam runs 5 challenges in 6 hours, so that's roughly its own per-challenge pace, and a couple of these (dynamic analysis, IaC) run heavier than a couple of the others (foundations, DSOMM).
• Verify, don't eyeball. Every challenge has a "done when" line — a command whose output either confirms the fix or doesn't. "I think that's right" isn't a verification step; a re-run scan showing zero findings is.
• Score yourself with the rubric, then re-drill anything under 70. A challenge you score honestly and fail teaches more than one you skim and assume you'd have gotten.

The eight challenges at a glance

☺ Like you're 10: One puzzle per topic this course teaches — work them in any order, but don't skip the ones that sound boring, because those are usually the ones with the sneakiest traps.

The CDP itself doesn't publish a domain weighting the way, say, the CKS publishes percentages — see the CDP exam guide for why that matters on exam day. This bank instead maps one challenge onto each of the nine-chapter exam blueprint's eight content domains, so working the whole bank once is working the whole blueprint once.

Shift-left foundations — pipeline and gates

☺ Like you're 10: Before you can practice finding bugs, you need a pipeline that actually stops a bad commit from getting through — these two challenges build that stopping power.

C1 · Wire the shift-left gates into a pipeline that has none

You've inherited a repo whose CI runs unit tests and nothing else. No secrets scan, no static analysis, no dependency check — and nobody would notice if any of the three landed in main tomorrow.

Given — .github/workflows/ci.yml:

name: CI
on: [push, pull_request]
jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test

Your task:

1. Add a secrets-scan job that scans the full git history (not just the working tree) with gitleaks and fails the pipeline on any finding.
2. Add a sast job that runs Semgrep against the repo and fails on any ERROR-severity finding.
3. Add an sca job that scans the resolved dependency tree with Trivy for fixable HIGH/CRITICAL CVEs, and make all three new jobs required status checks alongside build-and-test.

Done when: a branch that adds a hardcoded AWS_SECRET_ACCESS_KEY string and reintroduces lodash@4.17.15 (a known-vulnerable version) fails both the secrets-scan and sca jobs; a clean branch passes all four.

name: CI
on: [push, pull_request]
jobs:
  secrets-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with: { fetch-depth: 0 }        # full history, not a shallow clone
      - uses: gitleaks/gitleaks-action@v2
        env: { GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} }
        # gitleaks-action exits non-zero on any finding by default

  sast:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: semgrep/semgrep-action@v1
        with: { config: auto }           # --error is the action's default behavior

  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test

  sca:
    needs: build-and-test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: aquasecurity/trivy-action@0.24.0
        with:
          scan-type: fs
          severity: HIGH,CRITICAL
          ignore-unfixed: true
          exit-code: 1

If this one exposed gaps in the vocabulary itself — gate vs. signal, shift-left, CALMS — that's exactly what chapters 1–2 of the blueprint are for. Tool references: gitleaks, Semgrep, Trivy.

C2 · Score a pipeline against DSOMM, then raise its level

The same repo's sast job (from C1, or an equivalent one already in place) runs on every push — but it's configured with continue-on-error: true, and no branch protection rule references it. It has been silently red for six weeks and nobody noticed.

Your task:

1. Using the OWASP DevSecOps Maturity Model (DSOMM)'s general framing — activities move from ad hoc, to automated-but-advisory, to automated-and-enforced-with-tracked-metrics — classify this SAST activity's current maturity level and state in one sentence what's missing to reach the next one.
2. Remove continue-on-error: true from the job, and configure branch protection so sast is a required status check on main.
3. Write a one-page maturity scorecard entry: activity, current level, evidence, target level, owner, target date.

Done when: a PR that deliberately reintroduces a Semgrep finding can no longer be merged (the required check is red and the merge button is disabled), and the scorecard entry exists as a committed file.

# remove continue-on-error from the job definition, then make it required:
gh api repos/OWNER/REPO/branches/main/protection \
  -X PUT \
  -H "Accept: application/vnd.github+json" \
  -f required_status_checks[strict]=true \
  -f 'required_status_checks[contexts][]=sast' \
  -f enforce_admins=true \
  -F required_pull_request_reviews='{"required_approving_review_count":1}' \
  -F restrictions=null

# Maturity scorecard — Static Application Security Testing

| Field | Value |
|---|---|
| Activity | SAST (Semgrep) on every push |
| Current level | Automated, advisory only — runs on every commit but cannot block a merge |
| Evidence | Workflow run history shows repeated red `sast` jobs on `main` with no merge impact |
| Target level | Automated + enforced — required status check, tracked over time |
| Change made | Removed `continue-on-error: true`; added `sast` to required status checks |
| Owner | Platform/AppSec |
| Target date | This sprint |

Background reading: Maturity Models: DSOMM, SAMM & BSIMM and the blueprint chapter. If the branch-protection step is what slowed you down, the policy-as-code drill is more reps on exactly that muscle.

Code and dependencies — what actually ships in the artifact

☺ Like you're 10: Two questions about anything you're about to ship: did you write something dangerous yourself, and did you drag in something dangerous that somebody else wrote?

C3 · Find the SQLi, and the key that's still in history

A small Flask service has a search endpoint built with string concatenation, and — three commits back — someone briefly committed a real-looking AWS access key before "fixing" it in the very next commit by deleting the line.

Given — app.py:

@app.route("/user")
def get_user():
    uid = request.args.get("id")
    query = "SELECT * FROM users WHERE id = " + uid
    return db.execute(query).fetchone()

Your task:

1. Run Semgrep against the app, identify the SQL injection, and fix it with a parameterized query.
2. Run gitleaks against the full git history, not just the working tree, and find the credential that was added and later deleted.
3. Treat the finding as a confirmed compromise (rotate it — deleting the line does not undo the exposure), then add a pre-commit hook so a new attempt to commit a fake key is blocked before it ever reaches a remote.

Done when: semgrep reports zero SQL-injection findings on the fixed file; gitleaks detect reports the historical finding with its commit SHA; and git commit with a newly staged fake AKIA… string is rejected by the hook before it's committed.

@app.route("/user")
def get_user():
    uid = request.args.get("id")
    query = "SELECT * FROM users WHERE id = ?"
    return db.execute(query, (uid,)).fetchone()

# 1. SAST
semgrep --config p/python --config p/sql-injection app.py
#   app.py:4 python.flask.security.injection.tainted-sql-string ...

# 2. secrets, full history (gitleaks scans the whole reachable history by default)
gitleaks detect --source . -v
#   Finding:     AKIA************FAKE
#   Secret:      aws-access-token
#   Commit:      a1b2c3d  (3 commits back)
#   File:        app.py

# 3. pre-commit gate
cat >> .pre-commit-config.yaml <<'EOF'
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.4
    hooks:
      - id: gitleaks
EOF
pre-commit install
echo 'aws_key = "AKIAIOSFAKEEXAMPLE12"' >> app.py
git add app.py && git commit -m "test"       # blocked by the hook, exit non-zero

Tool references: Semgrep, gitleaks, TruffleHog. More reps on the secrets half: the leaked-credential-triage drill.

C4 · Trace a transitive CVE and decide if it's reachable

A Java service's pom.xml pulls in log4j-core:2.14.1 transitively through an internal logging wrapper artifact — nobody on the team declared it directly, and nobody's looked at the dependency tree since the project started.

Given — relevant fragment of pom.xml:

<dependency>
  <groupId>com.acme.internal</groupId>
  <artifactId>logging-wrapper</artifactId>
  <version>1.3.0</version>
  <!-- transitively brings in log4j-core:2.14.1 -->
</dependency>

Your task:

1. Run an SCA scan and identify the CVE affecting the transitive dependency, its CVSS score, its EPSS score, and whether it's listed in CISA's Known Exploited Vulnerabilities (KEV) catalog.
2. Decide whether the finding needs a same-day fix or can wait for the normal release cadence, and justify the decision in one sentence.
3. Remediate by pinning log4j-core to a fixed version via a dependency-management override — without bumping the whole logging-wrapper artifact — regenerate the SBOM, and re-scan to confirm zero criticals.

Done when: mvn dependency:tree shows log4j-core resolving to the pinned fixed version, and a re-run SCA scan shows no CRITICAL findings for this dependency.

trivy fs --scanners vuln --severity CRITICAL,HIGH .
#   log4j-core 2.14.1  CVE-2021-44228 (Log4Shell)  CRITICAL  CVSS 10.0
#   fixed in: 2.17.1

<!-- force the transitive version without touching logging-wrapper -->
<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.apache.logging.log4j</groupId>
      <artifactId>log4j-core</artifactId>
      <version>2.17.1</version>
    </dependency>
  </dependencies>
</dependencyManagement>

mvn dependency:tree | grep log4j-core          # confirm it now resolves to 2.17.1
syft . -o cyclonedx-json=sbom.json             # regenerate the SBOM against the fixed tree
grype sbom:sbom.json                            # re-scan; should show zero criticals for log4j-core

Tool references: Trivy, Syft & Grype, Snyk, OWASP Dependency-Check. Background: Software Bills of Materials, Dependency & License Risk Management. More reps: the vulnerable-dependency fire drill.

Runtime and infrastructure — what the artifact touches once it's live

☺ Like you're 10: Scanning the code catches what you wrote wrong. These two challenges catch what happens once it's actually running somewhere, talking to the internet and sitting on real infrastructure.

C5 · Run an authenticated scan and separate signal from noise

A target application (OWASP Juice Shop or an equivalent deliberately-vulnerable app works well for practicing this one) sits behind a login form. An unauthenticated ZAP baseline scan only ever sees the login page itself — everything interesting is behind auth, and nobody's configured the scanner to get past it.

Your task:

1. Configure an authenticated ZAP scan using the ZAP Automation Framework, so the spider and active scan can reach pages behind the login form.
2. Run the full scan and triage the report: pick one genuine true-positive finding with real impact, and one low-value or informational finding, and explain in one sentence each why they land in different buckets.
3. Fix the true positive and re-run the scan to confirm the alert no longer fires.

Done when: the automation run's spider report shows pages reachable only after login (proving auth worked), and the confirmed true-positive alert is absent from the re-scan report.

# zap-automation.yaml
env:
  contexts:
    - name: target
      urls: ["http://localhost:3000"]
      authentication:
        method: form
        parameters:
          loginPageUrl: http://localhost:3000/#/login
          loginRequestUrl: http://localhost:3000/rest/user/login
          loginRequestBody: 'email={%username%}&password={%password%}'
      users:
        - name: tester
          credentials: { username: tester@example.com, password: "Testpass1!" }
jobs:
  - type: spider
    parameters: { context: target, user: tester, url: http://localhost:3000 }
  - type: activeScan
    parameters: { context: target, user: tester }
  - type: report
    parameters: { template: traditional-html, reportFile: zap-report.html }

docker run -v $(pwd):/zap/wrk/:rw -t zaproxy/zap-stable \
  zap.sh -cmd -autorun /zap/wrk/zap-automation.yaml

<!-- fix: encode output at render time instead of interpolating raw input -->
<p>No results for: {{ query | e }}</p>
<!-- plus a Content-Security-Policy header as defense in depth -->

Tool references: OWASP ZAP, Burp Suite. Background: the blueprint chapter, API Security in Depth.

C6 · Fix the Terraform plan before anyone applies it

A junior engineer's first Terraform PR provisions an S3 bucket, a security group, and an EBS volume — and would, if merged, leave all three publicly exposed or unencrypted. Nobody's run a scanner against it yet.

Given — fragment of main.tf:

resource "aws_s3_bucket" "logs" {
  bucket = "acme-app-logs"
}

resource "aws_security_group" "app" {
  name = "app-sg"
  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

resource "aws_ebs_volume" "data" {
  availability_zone = "eu-west-1a"
  size              = 40
}

Your task:

1. Run Checkov or tfsec against the plan and list the specific failing check IDs for all three resources.
2. Fix each: block public access and enable default encryption on the bucket, restrict SSH ingress to a named CIDR instead of the whole internet, and enable EBS encryption.
3. Add an OPA/Conftest policy as a CI gate that fails terraform plan in future if any new S3 bucket lacks a public-access block, so this class of finding can't regress silently.

Done when: a re-run of Checkov against the fixed file shows zero failures for these three resources, and a Conftest run against a deliberately-reintroduced public bucket in the plan JSON fails with your policy's message.

checkov -d . --compact
#   CKV_AWS_53/54/55/56  aws_s3_bucket.logs — public access block not configured
#   CKV_AWS_19           aws_s3_bucket.logs — bucket not encrypted
#   CKV_AWS_24           aws_security_group.app — 22 open to 0.0.0.0/0
#   CKV_AWS_3            aws_ebs_volume.data — not encrypted

resource "aws_s3_bucket" "logs" {
  bucket = "acme-app-logs"
}

resource "aws_s3_bucket_public_access_block" "logs" {
  bucket                  = aws_s3_bucket.logs.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" "logs" {
  bucket = aws_s3_bucket.logs.id
  rule {
    apply_server_side_encryption_by_default { sse_algorithm = "AES256" }
  }
}

resource "aws_security_group" "app" {
  name = "app-sg"
  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["203.0.113.0/24"]   # bastion / office CIDR, not 0.0.0.0/0
  }
}

resource "aws_ebs_volume" "data" {
  availability_zone = "eu-west-1a"
  size              = 40
  encrypted         = true
}

# policy/s3_public_block.rego
package terraform.s3

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_s3_bucket"
  not has_public_access_block(resource.address)
  msg := sprintf("S3 bucket %v has no aws_s3_bucket_public_access_block", [resource.address])
}

has_public_access_block(bucket_addr) {
  pab := input.resource_changes[_]
  pab.type == "aws_s3_bucket_public_access_block"
  contains(pab.change.after.bucket, bucket_addr)
}

terraform show -json tfplan > plan.json
conftest test --policy policy/ plan.json

Tool references: Checkov, tfsec, OPA & Conftest. More reps: the broken-Terraform-plan drill.

Proof and prioritization — closing the loop

☺ Like you're 10: Finding problems is only half the job. The other half is proving you fixed them to someone who wasn't watching, and deciding which ones actually deserve today's attention.

C7 · Turn a CIS checklist into automated, re-runnable evidence

An auditor's spreadsheet asks three questions about a fleet of Linux hosts: is root SSH login disabled, is auditd installed and running, and does the password policy meet CIS baseline requirements. Right now the answer comes from someone SSHing in once a quarter and eyeballing the config.

Your task:

1. Write an InSpec profile with controls for all three checks.
2. Run it against a target host and produce a machine-readable results artifact instead of a spreadsheet checkbox.
3. For each failing control, apply the remediation, then re-run to show green — producing evidence an auditor can accept without ever needing shell access to the host themselves.

Done when: inspec exec against the target produces a JSON results file with all three controls passing, and the JSON is retained as the audit evidence artifact.

# controls/ssh_and_auditd.rb
control 'cis-5.2.10' do
  impact 1.0
  title 'Ensure SSH root login is disabled'
  describe sshd_config do
    its('PermitRootLogin') { should cmp 'no' }
  end
end

control 'cis-4.1.1.1' do
  impact 1.0
  title 'Ensure auditd is installed and running'
  describe package('auditd') do
    it { should be_installed }
  end
  describe service('auditd') do
    it { should be_enabled }
    it { should be_running }
  end
end

control 'cis-5.4.1' do
  impact 0.7
  title 'Ensure password minimum length meets CIS baseline'
  describe file('/etc/security/pwquality.conf') do
    its('content') { should match(/^\s*minlen\s*=\s*(1[4-9]|[2-9]\d)/) }
  end
end

# remediate the failures first, then run
sudo sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sudo systemctl restart sshd
sudo apt-get install -y auditd && sudo systemctl enable --now auditd
echo "minlen = 14" | sudo tee -a /etc/security/pwquality.conf

inspec exec ./controls --target ssh://user@host \
  --reporter cli json:results.json

Tool references: InSpec, OpenSCAP, Wazuh. Background: the blueprint chapter.

C8 · 40 findings, one afternoon — which five do you fix

DefectDojo just aggregated the week's scan output — SAST, SCA, DAST, and a container scan — into roughly 40 open findings. You have one afternoon before the sprint planning meeting where you have to defend a short list. A sample of the pile:

Your task:

1. Deduplicate: identify the pair of findings that are the same underlying root cause reported by two different tools, and count it once.
2. Rank the deduplicated list and pick your top 5, using severity, EPSS, KEV status, and exposure together — not raw CVSS alone — with a one-line justification per item.
3. Assign a remediation SLA to each of your top 5, and for the one finding with no vendor fix available, propose a compensating control instead of an indefinite "accepted risk."

Done when: your top-5 list and SLAs are written down, and every item's justification references at least one factor beyond its raw CVSS score.

Tool references: DefectDojo. Background: the blueprint chapter.

Score a full sitting

☺ Like you're 10: Once you've done all eight puzzles, add up how you did — a bad score on one puzzle tells you exactly what to go re-study, which is more useful than one big number.

Each challenge's rubric scores out of 100, the same scale the real CDP report is graded on, with an 80/100 pass mark per the vendor's own published figures — see the CDP exam guide's standing caveat that you should re-verify that number on Practical DevSecOps' own page before you rely on it. Score each challenge honestly, then read the pattern rather than the total:

A single low score on one challenge is a study plan, not a failure — it tells you precisely which of the eight blueprint domains needs another pass before you book the real exam, which is a far more useful signal than an aggregate percentage across all eight would be.

The rest of exam prep: the CDP study plan maps the nine-chapter blueprint onto a week-by-week schedule; the CDP exam guide covers format, registration, and exam-day logistics; Know It Cold and the command & tool reference are the from-memory drills worth doing alongside this bank; the mock exam sets string challenges like these into a full timed sitting; and the troubleshooting triage playbook is what to reach for when a challenge isn't behaving the way you expected. For hands-on reps that chain several of these domains into one continuous pipeline rather than eight separate scenarios, work the capstone lab track.