Mock Exam · Set 4 — the final dress rehearsal

This is the last paper before you book the real thing. Five challenges, one unbroken 6-hour sitting, a hundred points, an 80-point bar — and unlike the practice bank, nothing below has been drilled anywhere else on this site. If you've worked the study plan, the practice challenge bank, and sat Sets 1–3, this page is the only remaining question worth asking: not do you know the material, but can you produce it, cold, against a live environment, on a clock that doesn't pause and without a chatbot to lean on. Sit it exactly like exam day — same clock, same allowlist, same evidence discipline — and the score you get back is the most honest readiness signal this course can give you.

What makes Set 4 different from Sets 1–3

☺ Like you're 10: The earlier papers taught you the shape of the test. This one only tells you one thing: are you ready, yes or no.

Every mock exam on this site measures something slightly different, and using them out of order wastes the one that matters most. The earlier sets built the skill of sitting a timed, multi-challenge paper without flinching — pacing, triage, the discipline of moving on from a challenge that's fighting you. Set 4 assumes you already have that skill and spends its whole budget on a harder question: with the format no longer a surprise, does your actual technical output — under the clock, cold, with the real allowlist — clear 80 out of 100? A high score on an earlier set that you'd partly seen before proves less than it feels like it does. A high score here, on five challenges you are reading for the first time in this sitting, is close to the strongest evidence this course can hand you that you're ready to pay for the real attempt.

Pre-flight — build the environment the night before

☺ Like you're 10: Set up every tool the day before, so the only thing you're doing once the clock starts is the actual work.

None of the five challenges below need a specific cloud account — a laptop with Docker, a throwaway kind cluster for Challenge 4, and the tools each challenge names is enough. Install everything the night before and confirm it runs cleanly; a broken tool install eats real minutes off a clock that doesn't pause for it.

# --- the night before ---------------------------------------------------
pip install semgrep gitleaks-cli 2>/dev/null; brew install gitleaks trufflehog 2>/dev/null
brew install trivy syft grype checkov kube-score conftest opa 2>/dev/null
docker pull zaproxy/zap-stable
docker pull owasp/juice-shop     # or any deliberately-vulnerable target you already run
kind create cluster --name cdp-mock4
kubectl get nodes                # Ready before you go to bed
kubectl create ns kyverno && kubectl apply -f https://github.com/kyverno/kyverno/releases/latest/download/install.yaml

# --- ninety seconds before the clock starts ------------------------------
mkdir -p ~/cdp-mock4/{c1,c2,c3,c4,c5,evidence} && cd ~/cdp-mock4
git init && git config user.email "you@example.com"   # C1 needs real git history to scan
kubectl config use-context kind-cdp-mock4
date   # write down the actual start time — you will need it for the report window

Exam conditions for this sitting

☺ Like you're 10: A dress rehearsal only tells you something true if you run it under the real rules — same clock, no shortcuts, no peeking at the answers.

One timer, started once, six hours, no pausing. Not for a broken container, not for a coffee, not for a laptop update. If your own tooling eats twenty minutes, that's a real finding about your setup discipline, not an excuse to reset the clock — the real exam won't reset it either.

Nothing open except what the real exam permits. Practical DevSecOps doesn't publish a fixed allowlist the way a vendor like Linux Foundation does for its own exams, but the CDP's own stated policy is explicit on one point: no AI assistants or chatbots during the challenge window — see the exam guide. Hold yourself to that here too. Official docs for the tools named in each challenge are fair game; this course's own pages, your notes from Sets 1–3, and any assistant are not.

No peeking at the worked solutions until you're done or truly stuck past the flag-and-move line. Each challenge's answer key is folded behind a summary specifically so opening it mid-attempt is a deliberate act, not an accident.

Read all five briefs first, five minutes, before touching a terminal. Mark each one cheap, medium, or expensive in your head. This paper does not arrive in difficulty order — the challenge you find easiest might be the one you're reading last.

Your 6-hour time budget

☺ Like you're 10: Give each puzzle its own slice of the six hours, and when a slice runs out, write down where you got stuck and move to the next one.

Five challenges in 360 minutes averages 67 minutes each once the 15 minutes of reading and the 10-minute evidence sweep at the end are carved out — but the challenges aren't equal, so the budget isn't either. Challenges 2 and 3 (dependency triage across a real transitive tree, and configuring authenticated DAST from scratch) run heavier than 1, 4, and 5.

The flag-and-move rule. If a challenge passes roughly 15 minutes past its budget with no passing done-when check, stop. Write one line about where you stalled, leave your partial work in place, and move to the next challenge. Twenty points sitting untouched at Challenge 5 because you spent ninety extra minutes chasing a clean result on Challenge 2 is the single most common way a candidate who knows the material still fails the clock.

The paper — 5 challenges, cold

☺ Like you're 10: Five brand-new puzzles, one per topic this course cares about most. Start the clock, read them all once, then go.

Every scenario below is new — none of it reuses the practice bank's C1–C8. Work each one in your own environment, verify with the stated done-when check before you consider it closed, and only open a worked solution after you've genuinely attempted the challenge or the flag-and-move threshold has passed.

Challenge 1 · The convert job and the token that got "removed" (20 pts)

A small Node/Express file-processing service, media-api, resizes uploaded images by shelling out to ImageMagick. Three commits back, someone briefly hardcoded a live-looking Twilio auth token into a .env.local file while testing an SMS-notification feature, then "cleaned it up" in the very next commit by deleting the line.

Given — routes/convert.js:

const { exec } = require("child_process");

app.post("/convert", (req, res) => {
  const { filename, width } = req.body;
  exec(`convert uploads/${filename} -resize ${width} out/${filename}`, (err, stdout) => {
    if (err) return res.status(500).send(err.message);
    res.send({ ok: true });
  });
});

Your task:

1. Run Semgrep against the service, identify the command-injection sink, and rewrite it so a filename like x.jpg; rm -rf / or a width like 100; curl evil.tld cannot execute arbitrary shell.
2. Run gitleaks or TruffleHog against the full git history and locate the deleted Twilio token, with its commit SHA.
3. Treat the token as compromised — deleting the line does not undo the exposure — and add a pre-commit hook plus a required, merge-blocking CI job so a new secret can't reach a shared branch again.

Done when: semgrep reports zero command-injection findings on the fixed route; gitleaks detect --source . -v reports the historical Twilio finding with its commit SHA; and a test commit adding a fake SK…-style token is rejected by the pre-commit hook before it's committed.

const { execFile } = require("child_process");
const path = require("path");

app.post("/convert", (req, res) => {
  const { filename, width } = req.body;
  if (!/^[\w.-]+\.(jpe?g|png|gif)$/i.test(filename)) return res.status(400).send("bad filename");
  const w = Number(width);
  if (!Number.isInteger(w) || w < 1 || w > 4000) return res.status(400).send("bad width");

  const src = path.join("uploads", filename);
  const dst = path.join("out", filename);
  // execFile with an argv array — no shell is invoked, so there is no string to inject into
  execFile("convert", [src, "-resize", String(w), dst], (err) => {
    if (err) return res.status(500).send("conversion failed");
    res.send({ ok: true });
  });
});

# 2. secrets, full history
gitleaks detect --source . -v
#   Finding:  SK********************FAKE
#   Secret:   twilio-api-key
#   Commit:   4e91a2c  (3 commits back)
#   File:     .env.local

# 3. pre-commit + CI 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 'TWILIO_TOKEN=SKfakefakefakefakefakefakefakefake' >> .env.local
git add .env.local && git commit -m "test"     # rejected, non-zero exit

Tool references: Semgrep, gitleaks, TruffleHog. Background: the blueprint chapter, Secure Coding Patterns.

Challenge 2 · A transitive CVE with a CISA KEV listing (20 pts)

A Java service, reporting-engine, depends on an internal wrapper artifact, report-formatting-lib:2.1.0, which transitively pulls in commons-text:1.9 — nobody declared it directly, and nobody's looked at the resolved tree since the wrapper was added eighteen months ago.

Given — the wrapper's templating utility, called from several report endpoints with user-editable template strings:

import org.apache.commons.text.StringSubstitutor;

public class TemplateRenderer {
    public String render(String template, Map<String, String> values) {
        return StringSubstitutor.createInterpolator()
            .setVariableResolver(new MapLookup(values))
            .replace(template);   // template can contain user-editable ${...} expressions
    }
}

Your task:

1. Run an SCA scan, identify the CVE affecting the transitive commons-text dependency, and record its CVSS score, its EPSS score, and whether it appears in CISA's KEV catalog.
2. Decide whether the finding is reachable, based on the snippet above, and justify the decision in one sentence.
3. Remediate by pinning commons-text to a fixed version via a dependency-management override — without bumping the whole report-formatting-lib artifact, which the reporting team hasn't vetted this sprint — regenerate the SBOM, and re-scan to confirm zero criticals.

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

trivy fs --scanners vuln --severity CRITICAL,HIGH .
#   commons-text 1.9   CVE-2022-42889 (Text4Shell)   CRITICAL   CVSS 9.8
#   fixed in: 1.10.0

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.apache.commons</groupId>
      <artifactId>commons-text</artifactId>
      <version>1.10.0</version>
    </dependency>
  </dependencies>
</dependencyManagement>

mvn dependency:tree | grep commons-text     # confirm resolves to 1.10.0
syft . -o cyclonedx-json=sbom.json          # regenerate SBOM against the fixed tree
grype sbom:sbom.json                         # re-scan; zero criticals for commons-text

Tool references: Trivy, Syft & Grype, Snyk. Background: the blueprint chapter, Software Bills of Materials.

Challenge 3 · Authenticated DAST against a JSON API, not a login form (20 pts)

Unlike a browser app with a login page, orders-api is a pure JSON REST API secured with short-lived Bearer JWTs issued by a separate /auth/token endpoint. An out-of-the-box ZAP baseline scan reaches /health and nothing else — there's no HTML for the spider to follow links from, and every real endpoint returns 401 without a token.

Your task:

1. Obtain a token via a scripted call to /auth/token, and configure the ZAP Automation Framework to attach it as an Authorization: Bearer … header on every request in the scan — form-based authentication doesn't apply here, since there's no HTML login form to submit.
2. Seed the scan from the API's OpenAPI spec (openapi.yaml) rather than the spider alone, since a JSON API has no crawlable links for a spider to discover on its own.
3. Run the scan and triage the report: identify one genuine true positive with real impact, and one low-value/informational finding, then fix the true positive and re-run to confirm it's gone.

Given — the relevant endpoint, which builds a dynamic sort clause from a JSON body field:

@app.route("/orders/search", methods=["POST"])
def search_orders():
    body = request.get_json()
    sort_field = body.get("sort", "created_at")
    query = f"SELECT * FROM orders ORDER BY {sort_field}"
    return jsonify(db.execute(query).fetchall())

Done when: the automation run's report shows the OpenAPI-seeded endpoints were reached with a 200/normal response (proving the bearer-token auth worked, not just a wall of 401s), and the confirmed true-positive alert is absent from the re-scan.

# zap-automation.yaml
env:
  contexts:
    - name: orders-api
      urls: ["http://localhost:8080"]
  parameters:
    failOnError: true
jobs:
  - type: script
    parameters:
      action: add
      type: httpsender
      engine: "Oracle Nashorn"
      name: bearer-auth
      file: /zap/wrk/bearer-auth.js       # fetches a fresh token and adds the header

  - type: openapi
    parameters:
      apiUrl: http://localhost:8080/openapi.yaml
      targetUrl: http://localhost:8080
      context: orders-api

  - type: activeScan
    parameters: { context: orders-api }

  - type: report
    parameters: { template: traditional-json, reportFile: zap-report.json }

// bearer-auth.js — ZAP HttpSender script, runs before every request in scope
function sendingRequest(msg, initiator, helper) {
    var token = TOKEN_CACHE.get("orders-api");
    if (!token) {
        // one real login call, cached for the rest of the scan
        token = doLogin();
        TOKEN_CACHE.put("orders-api", token);
    }
    msg.getRequestHeader().setHeader("Authorization", "Bearer " + token);
}
function responseReceived(msg, initiator, helper) {}

ALLOWED_SORT_FIELDS = {"created_at", "total", "status"}

@app.route("/orders/search", methods=["POST"])
def search_orders():
    body = request.get_json()
    sort_field = body.get("sort", "created_at")
    if sort_field not in ALLOWED_SORT_FIELDS:
        return jsonify({"error": "invalid sort field"}), 400
    query = f"SELECT * FROM orders ORDER BY {sort_field}"   # safe: sort_field is now from a closed allow-list
    return jsonify(db.execute(query).fetchall())

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

Challenge 4 · A Kubernetes manifest, and a policy so it can't regress (20 pts)

A junior engineer's first Kubernetes PR ships the checkout Deployment as a privileged, host-networked container with no resource limits and a mutable tag. Nobody's run a scanner against it, and there's no admission policy in the cluster that would have stopped it anyway.

Given — fragment of checkout-deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata: { name: checkout }
spec:
  template:
    spec:
      hostNetwork: true
      containers:
        - name: checkout
          image: acme/checkout:latest
          securityContext:
            privileged: true

Your task:

1. Scan the manifest with Checkov's Kubernetes framework or kube-score, and list the specific failing checks (privileged container, host networking, mutable tag, missing resource limits, missing non-root/read-only-filesystem settings).
2. Fix the manifest: remove privileged and hostNetwork, pin the image to a digest instead of :latest, add a hardened securityContext (non-root, read-only root filesystem, all capabilities dropped), and add resource requests/limits.
3. Add a Kyverno ClusterPolicy in enforce mode that blocks privileged pods and mutable :latest tags cluster-wide, then prove it by deploying a deliberately bad pod and showing the admission webhook rejects it.

Done when: Checkov reports zero failures for the fixed manifest, and kubectl apply of a test pod with privileged: true is rejected with an admission-webhook error referencing your policy.

checkov -f checkout-deployment.yaml --framework kubernetes --compact
#   CKV_K8S_16   Container should not be privileged
#   CKV_K8S_9    hostNetwork should not be set
#   CKV_K8S_43   Image should use a digest, not a mutable tag
#   CKV_K8S_10/11/12/13   CPU/memory requests and limits not set
#   CKV_K8S_23   Should not run as root

apiVersion: apps/v1
kind: Deployment
metadata: { name: checkout }
spec:
  template:
    spec:
      containers:
        - name: checkout
          image: acme/checkout@sha256:9f1a2b...        # digest, not :latest
          securityContext:
            runAsNonRoot: true
            runAsUser: 10001
            readOnlyRootFilesystem: true
            allowPrivilegeEscalation: false
            capabilities: { drop: ["ALL"] }
          resources:
            requests: { cpu: "100m", memory: "128Mi" }
            limits:   { cpu: "500m", memory: "256Mi" }

# kyverno-policy.yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata: { name: disallow-privileged-and-latest }
spec:
  validationFailureAction: Enforce
  rules:
    - name: no-privileged
      match: { any: [{ resources: { kinds: ["Pod"] } }] }
      validate:
        message: "Privileged containers are not allowed."
        pattern:
          spec:
            containers:
              - =(securityContext): { =(privileged): "false" }
    - name: no-latest-tag
      match: { any: [{ resources: { kinds: ["Pod"] } }] }
      validate:
        message: "Images must not use the :latest tag."
        pattern:
          spec:
            containers:
              - image: "!*:latest"

kubectl apply -f kyverno-policy.yaml
kubectl run bad-pod --image=nginx:latest --overrides='{"spec":{"containers":[{"name":"bad-pod","image":"nginx:latest","securityContext":{"privileged":true}}]}}' --dry-run=server
#   Error from server: admission webhook "validate.kyverno.svc-fail" denied the request:
#   Privileged containers are not allowed.

Tool references: Checkov, Kyverno, OPA & Conftest. Background: the blueprint chapter, Kubernetes Security Deep Dive.

Challenge 5 · Twenty-five findings, and one control an auditor is waiting on (20 pts)

DefectDojo just aggregated this week's scan output — container, SCA, SAST, DAST, and an IaC pass over the cluster's RBAC — into roughly 25 open findings. You have the rest of the afternoon before sprint planning, where you need to defend a short list, and an auditor is waiting on evidence that no service account outside an approved list holds cluster-admin.

* The scanner assigns this misconfiguration a generic severity score, not a CVSS score pulled from an actual CVE record — Redis running with no auth isn't a vulnerability with a CVE ID, it's a deployment choice. EPSS, which predicts exploitation probability for known CVEs specifically, doesn't apply to it at all.

Your task:

1. Deduplicate the pile, then rank the rest and pick your top 3, weighing severity, EPSS, KEV status, and exposure together rather than raw CVSS alone — one-line justification per pick.
2. Assign each of your top 3 a remediation SLA.
3. Write a Rego/Conftest policy that continuously proves the RBAC finding stays fixed — no ClusterRoleBinding grants cluster-admin to a subject outside an approved allowlist — run it against the live cluster's bindings, and produce the JSON result as the auditor's evidence artifact.

Done when: your top-3 list and SLAs are written down with a justification that references at least one factor beyond raw CVSS for each item, and conftest test -o json against the cluster's current ClusterRoleBindings produces a results file with your RBAC control passing.

# policy/rbac_cluster_admin.rego
package kubernetes.rbac

allowlist := {"eks-admin-group", "platform-team-sa"}

deny[msg] {
  crb := input.items[_]
  crb.roleRef.name == "cluster-admin"
  subj := crb.subjects[_]
  not allowlist[subj.name]
  msg := sprintf("ClusterRoleBinding %v grants cluster-admin to unapproved subject %v", [crb.metadata.name, subj.name])
}

# fix the finding first, then generate evidence against the corrected state
kubectl delete clusterrolebinding ci-cluster-admin-binding
kubectl create clusterrolebinding ci-deploy-scoped --clusterrole=deploy-only --serviceaccount=ci:ci-runner

kubectl get clusterrolebindings -o json > evidence/crbs.json
conftest test --policy policy/ evidence/crbs.json -o json > evidence/rbac-control-result.json
cat evidence/rbac-control-result.json   # 0 failures — this is the auditor's evidence artifact

Tool references: DefectDojo, OPA & Conftest. Background: the blueprint chapter, Compliance as Code at Scale.

Score yourself

☺ Like you're 10: Grade honestly after a break, add up the five numbers, and look hardest at whichever one is lowest — that's the one still telling you something useful.

Mark after stepping away for at least fifteen minutes — scoring your own work while still adrenalised from the clock produces generous nonsense. For each challenge, use the same rubric bands this course's practice bank uses, since it's the same 100-point scale the real CDP report is graded against:

The bar is 80. Because the paper totals 100, your raw score is your percentage. If a single domain scored under 14, that's not noise the total can hide — go back to the specific blueprint chapter and deep-dive linked under that challenge above, then re-run that exact scenario cold in 48 hours before you touch anything else.

The readiness checklist — book it, or one more pass?

☺ Like you're 10: A close-enough total isn't the same as being ready. Check every box honestly before you spend real money on the real exam.

A score by itself can lie to you — a 78 built from four strong domains and one near-zero is a completely different candidate from a 78 spread evenly across all five, and only one of them is one unlucky challenge draw away from failing the real thing. Work through every row below honestly. Any single "no" means the honest answer is one more study pass, not the real exam.

That's the final paper. Set the timer, close every tab except the tools' own docs, and let the five scenarios above tell you something the earlier sets couldn't — because this time, you're reading them for the first time. Score it honestly, run every row of the readiness checklist, and let the answer — not the total alone — decide whether today is the day you book the real CDP.