{
  "module": "S10 — Cloud Red Team Harnesses",
  "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": "How does a cloud red team harness differ from a network pentest harness?", "options": ["It uses the same tools but faster", "It is API-first, identity-first, with no port scanning. The attack surface is identities, permissions, and configurations — not ports and hosts", "It only scans cloud networks", "It runs nmap on cloud IP ranges"], "answer_index": 1, "rationale": "The cloud is not a network — it is an API. The attack surface is the identity layer (IAM users, roles, policies, trust relationships), not open ports. An AWS account has no ports to scan in the way nmap scans. Every action is an API call against the control plane." },
    { "id": "Q02", "bloom": "recall", "type": "multiple_choice", "prompt": "List the 5 phases of the cloud kill chain.", "options": ["Scan, exploit, pivot, exfiltrate, cover tracks", "Reconnaissance → Initial Access → Privilege Escalation → Lateral Movement → Impact", "Recon, scan, enumerate, attack, report", "Discover, assess, exploit, report, remediate"], "answer_index": 1, "rationale": "The cloud kill chain: Reconnaissance (enumerate via API), Initial Access (exposed service or credential), Privilege Escalation (IAM abuse), Lateral Movement (cross-account/cross-service pivots), Impact (demonstrated access, read-only proof, NOT actual exfiltration). Same phases as network kill chain, completely different execution." },
    { "id": "Q03", "bloom": "recall", "type": "multiple_choice", "prompt": "What are the 4 sections of the cloud red team client report?", "options": ["Intro, body, conclusion, appendix", "Executive summary, finding table, attack narrative, remediation roadmap", "Scope, methodology, results, payment", "Findings, evidence, remediation, sign-off"], "answer_index": 1, "rationale": "Executive summary (overall risk, business impact, 1 page non-technical), finding table (ID, severity, resource, compliance mapping, status), attack narrative (step-by-step story backed by evidence chain), remediation roadmap (prioritized actions mapped to findings and frameworks). Generated from the structured findings store, not hand-written." },
    { "id": "Q04", "bloom": "application", "type": "multiple_choice", "prompt": "An identity has iam:PassRole, lambda:CreateFunction, and lambda:InvokeFunction. What escalation path is available?", "options": ["None — these are read-only permissions", "PassRole + Lambda: pass a more privileged role to a new Lambda, invoke it, act through the execution role's permissions", "UpdateAssumeRolePolicy to modify trust", "CreatePolicy to grant full admin"], "answer_index": 1, "rationale": "PassRole + service creation: if an identity has PassRole and can create a service (Lambda), it can pass a more privileged role to the new service and act through it. Pass a role with s3:* to a new Lambda, invoke it, read every bucket. The role's permissions become accessible through the Lambda's execution context." },
    { "id": "Q05", "bloom": "application", "type": "multiple_choice", "prompt": "An identity has iam:CreatePolicy and iam:AttachRolePolicy. What can it achieve?", "options": ["Nothing useful", "Full admin: create a policy with *:*, attach it to its own role, granting unrestricted access", "Read access to one bucket", "The ability to list roles only"], "answer_index": 1, "rationale": "CreatePolicy + AttachRolePolicy: if an identity can create policies and attach them, it can grant itself ANY permission. Create a policy with *:* (full admin), attach it to its own role. The identity now has unrestricted access to the entire account." },
    { "id": "Q06", "bloom": "application", "type": "multiple_choice", "prompt": "A cloud red team harness identifies an escalation path from Identity-A to admin. How should this be reported?", "options": ["Assert 'Identity-A can escalate to admin' without proof", "Demonstrate it with evidence: the exact API calls (GetRole, Lambda creation, invocation, response) showing the escalation succeeds, in order, reproducibly", "Report it as a theoretical possibility", "Delete Identity-A to prevent escalation"], "answer_index": 1, "rationale": "Every escalation path must be DEMONSTRATED, not asserted. The evidence shows the exact API calls, in order, that achieve it: GetRole showing PassRole permission, Lambda creation showing role passed, invocation showing escalation succeeded, response showing elevated access worked. Reproducible, verifiable, client-presentable." },
    { "id": "Q07", "bloom": "application", "type": "multiple_choice", "prompt": "A finding shows an over-privileged IAM role. How is it mapped for the client's auditor?", "options": ["Described technically as 'iam:PassRole chain' — the auditor will figure it out", "Mapped to SOC 2 CC6.3, ISO 27001 A.9.2.5, and PCI DSS 7.2.1 — the compliance controls the finding violates", "Listed without framework reference", "Sent only to the engineering team"], "answer_index": 1, "rationale": "The compliance mapping translates technical findings to framework controls. An over-privileged IAM role violates SOC 2 CC6.3 (access authorization), ISO 27001 A.9.2.5 (access rights review), and PCI DSS 7.2.1 (access control system). The auditor does not understand iam:PassRole but does understand which control is at risk." },
    { "id": "Q08", "bloom": "application", "type": "multiple_choice", "prompt": "During impact demonstration, the harness proves it can read a sensitive S3 bucket. What is the correct action?", "options": ["Download all the data to prove the full extent of the breach", "Demonstrate read access via a single GetObject call (read-only proof, evidence-logged) — NOT actual exfiltration", "Delete the bucket to show impact", "Modify the data to prove write access"], "answer_index": 1, "rationale": "Impact is demonstrated as READ-ONLY PROOF. A single GetObject call that succeeds proves access without downloading data. The harness demonstrates the path EXISTS — it does not steal data or cause harm. Every call is evidence-logged and scope-checked. Actual exfiltration is never part of an authorized engagement." },
    { "id": "Q09", "bloom": "application", "type": "multiple_choice", "prompt": "The harness attempts an API call against an account not listed in the scope file. What happens?", "options": ["The call proceeds — scope is advisory", "The scope middleware blocks the call before execution — out-of-scope accounts are never touched", "The call proceeds but is logged for review", "The harness asks for permission"], "answer_index": 1, "rationale": "Scope enforcement is mandatory on every API call. The scope file defines authorized account IDs, allowed/denied regions, and service exclusions. An out-of-scope account call is blocked before execution. Destructive calls (DeleteRole, DeleteBucket, TerminateInstances) are blocked unconditionally unless explicitly approved. The scope file is the legal boundary." },
    { "id": "Q10", "bloom": "analysis", "type": "multiple_choice", "prompt": "Why is port scanning an anti-pattern in cloud engagements?", "options": ["It is too slow", "The cloud is not a network — it is an API. Port scanning finds nothing useful because the attack surface is the identity layer (IAM), not open ports. An AWS account has no ports to scan like nmap scans", "It triggers cloud provider bans", "It requires special permissions"], "answer_index": 1, "rationale": "Running nmap against cloud infrastructure wastes engagement time. The cloud's attack surface is not at the network layer — it is at the identity layer. Enumerate IAM policies, map roles, trace trust relationships, and query API endpoints instead. The tool suite changes entirely: nmap/httpx/nuclei become Prowler/ScoutSuite/Pacu/Stormspotter." },
    { "id": "Q11", "bloom": "analysis", "type": "multiple_choice", "prompt": "How does S10.2's privilege graph relate to S09.2's attack-path analysis?", "options": ["They are unrelated", "Same graph-based path-finding technique, applied to different layers. S09.2: assets as nodes, access as edges, paths from entry to target. S10.2: permission sets as nodes, escalation techniques as edges, paths from start perms to target perms", "S10.2 is simpler than S09.2", "S09.2 is for defense, S10.2 is for offense — no shared technique"], "answer_index": 1, "rationale": "The graph reasoning transfers; the domain changes. S09.2 models the cloud attack surface as a graph of assets and access relationships, finding paths from public entry points to sensitive targets. S10.2 models the IAM permission space as a graph of permission sets and escalation techniques, finding paths from starting permissions to target permissions. Both use BFS path-finding." },
    { "id": "Q12", "bloom": "analysis", "type": "multiple_choice", "prompt": "Why must the client report be generated from the structured findings store rather than hand-written?", "options": ["Hand-writing is too expensive", "Consistency: the evidence chain ensures every claim in the narrative is backed by a reproducible API call sequence, and the compliance mapping ensures every finding speaks the auditor's language. Hand-writing risks inconsistency between demonstrated and reported findings", "The harness cannot produce human-readable text", "It is required by the cloud provider"], "answer_index": 1, "rationale": "Generating the report from the structured findings store guarantees consistency. The narrative references real evidence records (each step cites the API calls that demonstrate it). The compliance mapping is applied uniformly. If the report were hand-written, it could drift from the actual evidence — claiming more or less than what was demonstrated. Generation from the store prevents this." },
    { "id": "Q13", "bloom": "analysis", "type": "multiple_choice", "prompt": "Why does the evidence schema include scope_ref on every record?", "options": ["For billing purposes", "It is the legal anchor — ties each evidence record to the specific scope entry that authorized the call. Without it, there is no proof the action was authorized, which undermines the engagement's legal standing", "To improve search performance", "It is required by the hash chain"], "answer_index": 1, "rationale": "The scope_ref is the load-bearing legal field. It ties each evidence record to the specific authorization in the scope file that permitted the call. In a legal proceeding or client review, the scope_ref proves every action was within the agreed boundaries. Without it, the evidence shows what was done but not that it was authorized — undermining the engagement's legal protection (established in S00.2)." },
    { "id": "Q14", "bloom": "analysis", "type": "multiple_choice", "prompt": "Why does the harness wrap Pacu/Stormspotter rather than running them directly?", "options": ["The tools are unreliable", "The wrapping adds scope enforcement (every API call checked against authorization), Pydantic-typed input/output, rate limiting, and evidence logging — making offensive tools safe to run under authorization. Running directly bypasses these controls", "Wrapping improves accuracy", "It is required by the cloud provider"], "answer_index": 1, "rationale": "Pacu and Stormspotter are powerful offensive tools. Running them directly means no scope enforcement (could touch out-of-scope accounts), no structured output, and no evidence logging. The harness wrapping (S02.2 pattern) adds: scope check before every call, Pydantic schemas for structured I/O, rate limiting per the RoE, and automatic evidence logging. The wrapping is what makes the tools safe and the output usable." },
    { "id": "Q15", "bloom": "analysis", "type": "multiple_choice", "prompt": "Why is IAM the primary attack surface in cloud environments rather than the network or compute?", "options": ["Networks are always encrypted in the cloud", "A cloud breach is almost always an IAM abuse: an over-privileged role used to access data, a trust relationship exploited to assume a more powerful identity, or a permission chain escalating to admin. The identity layer is where access is actually controlled", "Compute instances are immutable", "Network firewalls block all attacks"], "answer_index": 1, "rationale": "In the cloud, access is governed by IAM policies, not network boundaries. An adversary who abuses an over-privileged role, exploits a trust relationship, or chains permissions to escalate gains access to data and resources regardless of network controls. The network and compute are secondary — the identity layer is where access is actually controlled, and where cloud adversaries focus." }
  ]
}