{
  "module": "C2 — Build a Smart Contract or Cloud Security Harness",
  "course": "2A — Building AI Harnesses for Cybersecurity",
  "version": "1.0.0",
  "duration_minutes": 35,
  "total_questions": 15,
  "bloom_distribution": {
    "target": "20% recall / 40% application / 40% analysis-design",
    "actual": { "recall": 3, "application": 6, "analysis": 6 }
  },
  "passing_score_percent": 70,
  "questions": [
    { "id": "Q01", "bloom": "recall", "type": "multiple_choice", "prompt": "What are the two tracks for Capstone C2?", "options": ["Red team and blue team", "Smart contract audit (EVMbench-aligned) and cloud posture + red team", "Web and mobile", "Static and dynamic analysis"], "answer_index": 1, "rationale": "Smart contract audit harness (EVMbench-aligned, Detect/Patch/Exploit vs DVD or forked mainnet) or cloud posture + red team harness (Detect/Remediate/Exploit vs isolated AWS). Same C1 architecture, different domain." },
    { "id": "Q02", "bloom": "recall", "type": "multiple_choice", "prompt": "What are the three modes for the smart contract track?", "options": ["Scan, fuzz, exploit", "Detect, Patch, Exploit", "Recon, attack, report", "Static, dynamic, manual"], "answer_index": 1, "rationale": "Detect (Slither/Mythril/LLM reasoning), Patch (generate fix, verify re-detect clean + Foundry tests pass), Exploit (working PoC on forked mainnet). The three modes together are the benchmark." },
    { "id": "Q03", "bloom": "recall", "type": "multiple_choice", "prompt": "What are the three modes for the cloud track?", "options": ["Scan, patch, monitor", "Detect, Remediate, Exploit", "Audit, harden, verify", "Discover, assess, report"], "answer_index": 1, "rationale": "Detect (Prowler/IAM analyzer — posture violations), Remediate (apply fix, verify re-scan clean), Exploit (controlled red-team action proving exposure is real). Same three-mode structure, cloud-specific tools." },
    { "id": "Q04", "bloom": "application", "type": "multiple_choice", "prompt": "Your smart contract harness scores 90% Detect, 25% Patch, 20% Exploit on an EVMbench subset. What is your assessment?", "options": ["It's a strong audit harness — 90% Detect is excellent", "It's a detection engine, not an audit harness. It finds bugs but cannot fix or exploit them. The Patch and Exploit pipelines need major work. All three scores must be reported together — 80% across all three is a genuine harness", "It's broken — all three should match", "It's acceptable if the 90% Detect is on Critical-severity bugs"], "answer_index": 1, "rationale": "A harness scoring high on Detect but low on Patch and Exploit is a detection engine, not an audit harness. All three scores must be reported together. 85% Detect / 30% Patch / 30% Exploit finds bugs but cannot fix or exploit them. 80% across all three is a genuine tool." },
    { "id": "Q05", "bloom": "application", "type": "multiple_choice", "prompt": "You are building the cloud track. You skip the authorization document and start building. What is the risk?", "options": ["None — the auth doc is a formality", "For cloud, an exploit action against the wrong account or without blast-radius limits is a REAL INCIDENT. The auth doc defines account ID, regions, resources, exploit blast-radius limits, and teardown. Skipping it means an Exploit-mode action could hit the wrong target or fail to tear down", "The benchmark will be invalid", "The report will be missing a section"], "answer_index": 1, "rationale": "The authorization document is not a formality, especially for cloud. An exploit action in the wrong account or without blast-radius limits is a real security incident. The auth doc defines the account, regions, resources, authorized actions, blast-radius limits, and teardown procedure. Write it before you build." },
    { "id": "Q06", "bloom": "application", "type": "multiple_choice", "prompt": "Your smart contract harness generates a patch that removes the vulnerability but breaks two Foundry tests. What is the patch quality score?", "options": ["Pass — the vulnerability is gone", "Fail — patch quality requires BOTH that the vulnerability is removed AND behavior is preserved (test suite passes). A patch that breaks tests fails the second gate. Re-generate the patch", "Partial pass — 50%", "Inconclusive — run more tests"], "answer_index": 1, "rationale": "Patch quality has two gates: (1) re-run detection — finding gone, no new findings. (2) Foundry test suite — behavior preserved, all tests pass. A patch that removes the bug but breaks tests fails gate 2. Both gates must pass. This is the S11.4 trap — fixing the specific PoC but breaking behavior." },
    { "id": "Q07", "bloom": "application", "type": "multiple_choice", "prompt": "You test your smart contract harness only against a toy contract you wrote yourself with one obvious bug. Your benchmark is 100% Detect. Is this publishable?", "options": ["Yes — 100% is 100%", "No — a harness tested only on toy examples is a hypothesis. The benchmark is only falsifiable if run against a real lab target (DVD, forked mainnet, EVMbench subset) that others can replicate. A toy example is not comparable or reproducible", "Yes, if you document the toy contract", "Only if the bug was Critical severity"], "answer_index": 1, "rationale": "A real lab target is non-negotiable. A harness tested only on toy examples is a hypothesis. The benchmark is falsifiable because anyone can run the same target — DVD challenge, forked mainnet block, or EVMbench subset — and compare. A self-written toy contract is not reproducible by others, so the score is not falsifiable and not publishable." },
    { "id": "Q08", "bloom": "application", "type": "multiple_choice", "prompt": "Your cloud harness remediates an over-permissive IAM policy by removing all permissions. The re-scan is clean but the application breaks. What happened?", "options": ["The remediation succeeded — re-scan is clean", "The remediation failed — remediation success requires the fix resolves the finding (re-scan clean) WITHOUT breaking the application. Removing all permissions is over-remediation. The fix must tighten the policy to least-privilege while preserving the app's needed access", "The exploit mode failed", "The scanner has a bug"], "answer_index": 1, "rationale": "Cloud remediation success has two criteria: (1) the finding is resolved (re-scan clean). (2) the application still functions (remediation did not break it). Removing all permissions makes the re-scan clean but breaks the app. The correct remediation tightens the IAM policy to least-privilege — granting only the permissions the app needs, revoking the over-permissive ones." },
    { "id": "Q09", "bloom": "application", "type": "multiple_choice", "prompt": "You publish your C2 benchmark as '90% Detect on EVMbench' with no Patch or Exploit scores. What anti-pattern is this?", "options": ["The tool-dump report", "Reporting only Detect recall — hides weaknesses in Patch and Exploit. Clients cannot assess whether the harness can fix or exploit what it finds. All three scores must be reported together", "Severity inflation", "Scope creep"], "answer_index": 1, "rationale": "Reporting only Detect recall hides that the harness may not be able to patch or exploit the bugs it finds. All three EVMbench scores must be reported together. 90% Detect with 30% Patch/Exploit is a detection engine, not an audit harness. The same anti-pattern from S12." },
    { "id": "Q10", "bloom": "analysis", "type": "multiple_choice", "prompt": "Why does the C1 architecture (scope, memory, tools, evidence, triage, report) port to both smart contract and cloud domains?", "options": ["It doesn't — each domain needs a from-scratch build", "The skeleton is domain-independent. Scope enforcement, cumulative memory, evidence chains, and triage are needed in any security harness. What changes is the tool suite (Slither vs Prowler), the target (contract vs AWS account), and the benchmark (EVMbench vs CIS). The skills transfer directly", "Because the LLM is general-purpose", "Because both use Python"], "answer_index": 1, "rationale": "The architecture is domain-independent. Scope enforcement (OOS calls blocked), cumulative memory (each finding enriches state), evidence chains (tamper-evident, trace-ID-linked), and triage (signal/noise filtering) are needed in any security harness. What changes is domain-specific: the tools (Slither/Mythril vs Prowler/IAM analyzer), the target (contract source vs AWS account), and the benchmark (EVMbench vs CIS posture). This is why C1 is the integration capstone — build it once, apply it anywhere." },
    { "id": "Q11", "bloom": "analysis", "type": "multiple_choice", "prompt": "Why are the benchmark scores described as 'falsifiable' and why does that matter for publishing?", "options": ["It sounds good in a report", "Anyone can run the same target (DVD challenge, forked mainnet block, isolated AWS account) and compare their scores. 'Our harness scores 80/72/68 on EVMbench' is a claim competitors can verify or refute. This converts 'trust us' into 'here is the scored evidence, run it yourself.' Falsifiability is what makes it publishable and a portfolio asset", "It is required by the benchmark spec", "It reduces legal liability"], "answer_index": 1, "rationale": "Falsifiable means anyone can run the same target and compare. The DVD challenges, forked mainnet blocks, and EVMbench subsets are public and reproducible. A score of 80% Detect / 72% Patch / 68% Exploit is a claim a competitor can verify or refute by running the same benchmark. This converts 'trust us, we're good' into 'here is the scored evidence, run it yourself.' That is what makes it publishable on LinkedIn, GitHub, and Deepthreat.ai as a portfolio asset." },
    { "id": "Q12", "bloom": "analysis", "type": "multiple_choice", "prompt": "Compare the evidence shape across the smart contract and cloud tracks. What is the same and what differs?", "options": ["Everything differs — they are different domains", "The evidence CHAIN is identical: finding → evidence (sha256 hash) → tool call → trace ID. What differs is the RAW OUTPUT: a PoC transaction and state change for smart contracts; a remediation diff, re-scan result, or exploit chain for cloud. The tamper-evident structure ports; the content is domain-specific", "Nothing is the same", "Only the report format is the same"], "answer_index": 1, "rationale": "The evidence chain is identical across domains: finding links to evidence (with sha256 hash for tamper-evidence) links to tool call links to log line (trace ID). What differs is the raw output captured in the evidence record — a PoC transaction and state change for smart contracts, a remediation diff or exploit chain for cloud. The tamper-evident structure (hash, trace ID, chain linkage) ports from C1 unchanged. This is why the architecture transfers." },
    { "id": "Q13", "bloom": "analysis", "type": "multiple_choice", "prompt": "Why does the one-page summary distill BOTH the benchmark scores AND the client report, rather than just the scores?", "options": ["To make it longer", "The scores prove the harness is measurable (falsifiable benchmark); the report link proves it is deliverable (client-ready output). Together they prove the harness is both effective AND shippable. Scores alone are a number; the report shows the actual findings, PoCs, and evidence. The one-page summary is the complete portfolio claim", "The report is required by the format", "To fill space on the GitHub README"], "answer_index": 1, "rationale": "The one-page summary distills both because they prove different things. The benchmark scores prove the harness is measurable — a falsifiable number anyone can compare. The client report link proves the harness is deliverable — actual findings, PoCs, evidence, and a report a client could receive. Together: effective (scores) AND shippable (report). Scores alone are a number; the report is the proof. The one-page summary is the complete portfolio claim: 'here is my measurable, shippable security tool.'" },
    { "id": "Q14", "bloom": "analysis", "type": "multiple_choice", "prompt": "Why is Damn Vulnerable DeFi (DVD) a good lab target for the smart contract track?", "options": ["It is easy", "Each challenge is a deliberately vulnerable DeFi protocol with a KNOWN solution. The harness attempts Detect (find the vuln), Patch (fix it), and Exploit (build the PoC). Because the solution is known, you can score the harness objectively — did it find what was known? Did its patch work? Did its PoC succeed? Reproducible and falsifiable", "It runs fast", "It has good documentation"], "answer_index": 1, "rationale": "DVD challenges are deliberately vulnerable DeFi protocols with known solutions. This makes them ideal for benchmarking: the harness attempts Detect, Patch, and Exploit, and you score it objectively against the known solution. Did it find the known vulnerability? Did its patch remove it and preserve behavior? Did its PoC drain the funds as the known solution does? Because the challenges are public and reproducible, anyone can run the same benchmark and compare — falsifiable." },
    { "id": "Q15", "bloom": "analysis", "type": "multiple_choice", "prompt": "What is the overarching deliverable of Capstone C2 and how does it relate to Course 2A as a whole?", "options": ["A working script", "A shippable, measurable, publishable security harness with a falsifiable benchmark score. Not a prompt, not a script — a tool a client could receive (report), a benchmark a competitor could verify (scores), and a portfolio piece you can publish (one-page summary). This is the culmination of Course 2A: harness fundamentals (Course 1) + security pillars (2A) → a publishable security tool", "A benchmark score only", "A client report only"], "answer_index": 1, "rationale": "The deliverable is a shippable, measurable, publishable security harness with a falsifiable benchmark score. It is the culmination of Course 2A: Course 1 gave harness fundamentals (context engineering, tool design, memory, scope); Course 2A's security pillars (offensive, AppSec, cloud, smart contracts) gave the domain depth. C1 assembled the architecture; C2 applied it to a specialized domain. The result: a tool a client could receive, a benchmark a competitor could verify, and a portfolio piece you can publish. The harness is the engine, the benchmark is the proof, the published summary is the portfolio." }
  ]
}