{
  "module": "S09 — Cloud Posture Harnesses",
  "course": "2A — Building AI Harnesses for Cybersecurity",
  "version": "1.0.0",
  "duration_minutes": 45,
  "total_questions": 20,
  "bloom_distribution": {
    "target": "20% recall / 40% application / 40% analysis-design",
    "actual": { "recall": 4, "application": 8, "analysis": 8 }
  },
  "passing_score_percent": 70,
  "questions": [
    { "id": "Q01", "bloom": "recall", "type": "multiple_choice", "prompt": "What is the cloud security harness's first job, and why?", "options": ["Assess risk, because risk drives prioritization", "Know what is deployed (asset inventory), because you cannot defend an asset you have not inventoried", "Generate reports, because reporting is the deliverable", "Run benchmarks, because CIS controls are the baseline"], "answer_index": 1, "rationale": "The discovery layer is the load-bearing foundation. Cloud posture tools fail at inventory first, then at assessment — a CSPM that does not know about a resource cannot flag it. Every downstream capability depends on an accurate, current inventory." },
    { "id": "Q02", "bloom": "recall", "type": "multiple_choice", "prompt": "What is the drift problem in cloud posture?", "options": ["Attackers drift between targets unpredictably", "Cloud infrastructure changes constantly and posture degrades silently — a midnight snapshot is stale by morning", "Logs drift out of order causing false alerts", "Network packets drift between availability zones"], "answer_index": 1, "rationale": "Terraform apply, console clicks, autoscaling, IAM updates change posture continuously. Drift mechanisms (console drift, IaC divergence, permission creep, ephemeral resource exposure) do not look like attacks, so traditional tools miss them. The inventory must be continuously reconciled, not periodically snapshotted." },
    { "id": "Q03", "bloom": "recall", "type": "multiple_choice", "prompt": "Name the native discovery service for AWS, Azure, and GCP.", "options": ["CloudTrail, Azure Monitor, GCP Logging", "Security Hub + Config, Resource Graph + Defender for Cloud, Security Command Center", "GuardDuty, Sentinel, Chronicle", "Inspector, App Service, Firebase"], "answer_index": 1, "rationale": "AWS: Security Hub (aggregated findings) + AWS Config (resource state and changes). Azure: Resource Graph (Kusto-queryable estate) + Defender for Cloud (posture findings). GCP: Security Command Center (asset inventory + findings, Premium adds posture management)." },
    { "id": "Q04", "bloom": "recall", "type": "multiple_choice", "prompt": "What AI security posture capability does Microsoft Defender for Cloud now provide?", "options": ["AI-generated vulnerability reports only", "Native AI security posture: discovers AI workloads, builds an AI BOM, tracks reachable AI endpoints, maps attack paths across Azure/AWS/GCP", "A chatbot for cloud security questions", "Automated AI model training for threats"], "answer_index": 1, "rationale": "Defender for Cloud now discovers AI workloads, builds an AI bill of materials, tracks externally reachable AI endpoints, and maps attack paths across all three clouds from a single pane. For AI-heavy estates this is the most efficient starting point — discovery and AI tagging are built in, not layered on." },
    { "id": "Q05", "bloom": "application", "type": "multiple_choice", "prompt": "A harness discovers a model endpoint with endpoint_publicly_reachable=true. Why does this tag matter?", "options": ["It doesn't — all model endpoints are public", "It distinguishes an internal tool from a public attack surface, tagged at inventory time so attack-path analysis starts with exposure already known", "It is used for billing purposes only", "It disables the endpoint automatically"], "answer_index": 1, "rationale": "The endpoint_publicly_reachable tag is the difference between a model endpoint that is an internal tool and one that is a public attack surface. Tagging at inventory time (not assessment time) means the attack-path analysis begins with the exposure already classified — a public AI endpoint is a different risk class than a private one serving the same model." },
    { "id": "Q06", "bloom": "application", "type": "multiple_choice", "prompt": "An attack graph contains: Public API Gateway → Lambda (assumes Role-A) → Role-A (over-privileged, can-write to RDS). What is this?", "options": ["Three separate findings", "An attack path — a chain from an externally reachable entry point to a sensitive target through IAM escalation and trust edges", "A false positive chain", "A compliance report"], "answer_index": 1, "rationale": "This is an attack path: a traversal from an entry point (public API Gateway) through internal resources (Lambda, Role-A) to a high-value target (RDS database). The harness finds these via BFS over the graph, not by listing individual findings. Fixing Role-A's over-permissive trust breaks every path through it." },
    { "id": "Q07", "bloom": "application", "type": "multiple_choice", "prompt": "A posture assessment lists 47 misconfigurations. Attack-path analysis finds 3 of them form a breach path to regulated data. What should be remediated first?", "options": ["All 47 equally", "The 3 on the critical attack path — fixing one node breaks the path; fixing the other 44 changes nothing about actual risk", "The easiest 10 to fix", "The ones alphabetically first"], "answer_index": 1, "rationale": "Remediation priority is path-derived, not finding-derived. Fixing a single node on a critical path breaks the path. Fixing 10 nodes not on any path changes nothing about actual risk. Attack-path analysis turns 47 findings into 3 priorities — that is the harness's value." },
    { "id": "Q08", "bloom": "application", "type": "multiple_choice", "prompt": "A CloudTrail event shows AttachRolePolicy on a production IAM role. What does the event-driven monitor do?", "options": ["Nothing — it is not security-relevant", "Re-fetches the role's current state, assesses it against CIS benchmark controls, and updates the attack graph — the IAM change may add or remove attack paths", "Deletes the role to be safe", "Sends a daily summary next week"], "answer_index": 1, "rationale": "AttachRolePolicy is a security-relevant IAM event (shifts privilege boundaries). The monitor re-fetches the resource state, runs a benchmark assessment, and updates the attack graph in seconds. The privilege change may create a new escalation edge — the graph must reflect it before it is exploited." },
    { "id": "Q09", "bloom": "application", "type": "multiple_choice", "prompt": "A finding is scored as 'critical, on active attack path, publicly exposed.' How is it routed?", "options": ["Weekly posture review batch", "Daily report batch", "Pages immediately — exploitable, high impact, reachable", "Logged only, no alert"], "answer_index": 2, "rationale": "Findings are scored by exploitability (on active path), business impact (data classification), and reachability (publicly exposed). A critical finding on an active attack path that is publicly exposed meets all three urgency criteria — it pages immediately, not batches." },
    { "id": "Q10", "bloom": "application", "type": "multiple_choice", "prompt": "A harness generates a remediation for a public S3 bucket in production. No human has approved. What happens?", "options": ["The fix is applied automatically", "The fix is proposed only — attached to a ticket with full context, staged, but NOT applied until a human approves. Production always requires approval", "The bucket is deleted", "The finding is discarded"], "answer_index": 1, "rationale": "The approval gate rule: production and no approver equals propose-only. The harness generates the fix, attaches it to a ticket with ARN, control, current/expected config, remediation command, and attack-path context — but does not apply it. Automated remediation that breaks production is worse than the misconfiguration it was fixing." },
    { "id": "Q11", "bloom": "application", "type": "multiple_choice", "prompt": "The CISO report shows 'top 5 attack paths' and the engineer report shows per-finding detail. Are these derived from different data?", "options": ["Yes — each audience gets its own separate scan", "No — both are views over the SAME finding store, differing in projection not storage. The CISO's top 5 paths are the same paths the engineer sees in detail", "Yes — the CISO report is manually written", "No — the auditor writes both"], "answer_index": 1, "rationale": "Multi-audience reports are generated from one finding store. Engineer, CISO, and auditor views differ in what they project (per-finding detail vs risk summary vs compliance evidence), not in what they store. This ensures consistency — no drift between what the engineer fixes and what the CISO reports." },
    { "id": "Q12", "bloom": "application", "type": "multiple_choice", "prompt": "An account has 50,000 resources and 10,000 CloudTrail changes per day. Why is event-driven monitoring more efficient than full-estate scanning?", "options": ["It uses less memory", "It only re-assesses the 10,000 changed resources (single-resource assessments), not all 50,000. Filtered to security-relevant events, the number is even smaller", "It skips encryption checks", "It runs on cheaper hardware"], "answer_index": 1, "rationale": "The event-driven loop is selective. Not every change triggers re-assessment — only security-relevant events (IAM, public exposure, AI workloads). The estate is not re-scanned wholesale; only changed resources are re-fetched and benchmark-checked. This scales to large accounts without periodic full-scan overhead." },
    { "id": "Q13", "bloom": "analysis", "type": "multiple_choice", "prompt": "Why must the asset inventory be continuously reconciled rather than periodically snapshotted?", "options": ["Snapshots are too expensive to store", "Cloud drift makes a week-old inventory stale. New buckets, changed roles, deleted resources are all missed. A breach path that appears Tuesday and is exploited Wednesday is invisible to a Monday snapshot", "Snapshots cannot be encrypted", "Reconciliation is required by CIS"], "answer_index": 1, "rationale": "The drift problem: cloud infrastructure changes constantly through mechanisms that do not look like attacks (console drift, IaC divergence, permission creep). A periodic snapshot misses everything that changed between captures. Continuous reconciliation diffs against last-known inventory on every change, catching drift at change time." },
    { "id": "Q14", "bloom": "analysis", "type": "multiple_choice", "prompt": "Why is the attack graph built from the asset inventory rather than a separate scan?", "options": ["Separate scans are too slow", "Discovery and path analysis share the same data model, so attack paths update automatically as the inventory updates. Drift in the inventory propagates to the path analysis without a second pipeline", "The graph cannot be built separately", "It is required by the cloud provider"], "answer_index": 1, "rationale": "The key design decision: the graph is built from the asset inventory, not from a separate scan. This means a new resource, a changed trust relationship, or a deleted asset immediately reflects in the attack graph. There is no lag between 'inventory knows' and 'path analysis knows' — they are the same system." },
    { "id": "Q15", "bloom": "analysis", "type": "multiple_choice", "prompt": "Why does the harness filter CloudTrail events rather than re-assessing on every API call?", "options": ["To save storage costs", "Not every API call changes the attack surface. Filtering to security-relevant events (IAM, public exposure, AI workloads) makes the loop efficient — 10k changes/day filtered to the subset that actually shifts posture", "The harness cannot process all events", "Filtering is required by NIST CSF"], "answer_index": 1, "rationale": "A cloud account generates thousands of API calls per day. Most are operational (DescribeInstances, ListBuckets) and do not change the attack surface. Filtering to security-relevant events — those that shift privilege boundaries or exposure — makes continuous monitoring feasible. The loop is efficient because it is selective, not exhaustive." },
    { "id": "Q16", "bloom": "analysis", "type": "multiple_choice", "prompt": "Why is 'propose-only' the correct default for automated remediation in production, even when the fix is deterministic and well-understood?", "options": ["Deterministic fixes are unreliable", "Automated remediation that breaks production is worse than the misconfiguration it was fixing. Even a correct fix can have unexpected interactions in a live system. Human approval is the safety control that catches edge cases the remediation library does not anticipate", "Propose-only is faster", "It is required by the cloud provider SLA"], "answer_index": 1, "rationale": "A deterministic fix (e.g., set BlockPublicAccess on an S3 bucket) is correct in isolation but may break a production workflow that depends on the current configuration (a pipeline reading from the public bucket). Human approval catches these context-dependent interactions. The rule is non-negotiable: production always requires approval." },
    { "id": "Q17", "bloom": "analysis", "type": "multiple_choice", "prompt": "Compare a scheduled-only monitor (nightly assessment) vs an event-driven monitor for a misconfiguration introduced at 9 AM and exploited at 2 PM.", "options": ["Both catch it equally", "Scheduled misses it — the assessment runs at midnight, after the 2 PM breach. Event-driven catches it: the change event triggers re-assessment in seconds, surfacing the finding before it compounds into an exploitable path", "Scheduled catches it faster", "Neither catches it"], "answer_index": 1, "rationale": "The latency gap is the core argument for event-driven monitoring. A scheduled assessment has a latency of hours to days. A misconfiguration that appears and is exploited between assessments is invisible. Event-driven monitoring has latency of seconds — the change triggers immediate re-assessment, and the finding is surfaced before it can be exploited." },
    { "id": "Q18", "bloom": "analysis", "type": "multiple_choice", "prompt": "Why does the harness not implement CIS benchmark controls from scratch?", "options": ["CIS controls are proprietary", "Native CSPM tools (Security Hub, Defender for Cloud, SCC) already implement the control checks. The harness's job is to map the findings, correlate them with attack paths, and prioritize remediation — not reimplement existing checks", "CIS controls are too complex", "The harness lacks permissions"], "answer_index": 1, "rationale": "The native discovery services already implement CIS, NIST, and PCI controls. Reimplementing them duplicates work and risks divergence. The harness adds value on top: it takes the CSPM findings, correlates them with the attack graph, and prioritizes by exploitability and business impact. A benchmark finding on a critical path is remediated before one on an isolated resource." },
    { "id": "Q19", "bloom": "analysis", "type": "multiple_choice", "prompt": "An engineer picks up a remediation ticket. Why does the ticket include 'attack-path membership'?", "options": ["For statistical tracking", "It drives prioritization — a finding on a critical attack path is remediated before a finding of equal severity that is not on any path. The context tells the engineer WHY this finding matters now", "It is required by JIRA", "It is decorative"], "answer_index": 1, "rationale": "The attack-path context is the framing that drives prioritization. Two findings of equal CVSS severity may have vastly different real risk: one is on a path to regulated data, the other is on an isolated resource. The ticket's attack-path membership tells the engineer which to fix first — the one that breaks a breach path." },
    { "id": "Q20", "bloom": "analysis", "type": "multiple_choice", "prompt": "How does the CISO report differ from the engineer finding list, and why is the difference in projection not in data?", "options": ["They use completely different data sources", "Both derive from the same finding store. The CISO report projects risk score, trend, top 5 paths, business-impact framing. The engineer report projects per-finding detail. Same data, different views — no drift between what is reported and what is fixed", "The CISO report is manually curated", "The engineer report is a subset of the CISO data"], "answer_index": 1, "rationale": "Multi-audience reports are projections over one finding store. If they were maintained separately, they would drift — the CISO's 'top 5 critical paths' could differ from the engineer's finding list, causing misalignment between strategy and execution. Deriving both from the same store ensures the executive view and the operational view are always consistent." }
  ]
}