"How does a cloud red team harness differ from a network pentest harness?"	"API-first (every action is an API call against the control plane, not a network packet). Identity-first (IAM is the primary attack surface, not compute). NO port scanning (an AWS account has no ports to scan). The attack surface is identities, permissions, and configurations — not ports and hosts."	c2a::s10::recall
"What is the attack surface boundary in a cloud engagement vs a network pentest?"	"Network pentest: network boundary (hosts, ports, services). Cloud engagement: identity layer (IAM users, roles, policies, trust relationships). Port scanning is irrelevant in the cloud — enumerate IAM policies, map roles, query API endpoints instead."	c2a::s10::recall
"Name the cloud offensive tools and their purposes."	"Prowler (CIS benchmarks, AWS/Azure/GCP config checks), ScoutSuite (multi-cloud audit, visual attack surface), Pacu (AWS exploitation framework, IAM escalation, post-exploitation), Stormspotter (Azure attack graph builder), GCP IAM Recommender (over-privileged service accounts)."	c2a::s10::recall
"List the 5 phases of the cloud kill chain."	"(1) Reconnaissance — enumerate public assets/identities/permissions via API. (2) Initial Access — exposed service or compromised credential. (3) Privilege Escalation — IAM abuse (PassRole, CreatePolicy). (4) Lateral Movement — cross-account/cross-service pivots. (5) Impact — demonstrated data access (read-only proof, NOT exfiltration)."	c2a::s10::recall
"How is scope enforcement defined in a cloud engagement?"	"Account boundaries (authorized account IDs), region constraints (allowed/denied regions, e.g. never touch GovCloud), service exclusions (destructive calls like DeleteRole/DeleteBucket/TerminateInstances blocked unconditionally unless explicitly approved). The scope file is the legal boundary; middleware enforces it on every API call."	c2a::s10::recall
"Why is IAM the primary attack surface in cloud environments?"	"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 from low-privilege to admin. The network/compute/storage are secondary — the identity layer is where access is actually controlled."	c2a::s10::analysis
"Explain the iam:PassRole + service creation escalation path."	"If an identity has iam:PassRole AND can create a service (Lambda/EC2), 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 the Lambda, read every bucket. The role's permissions become accessible through the service's execution context."	c2a::s10::application
"Explain the CreatePolicy + AttachRolePolicy escalation path."	"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. Requires: iam:CreatePolicy, iam:AttachRolePolicy."	c2a::s10::application
"How does the harness model privilege escalation as graph traversal?"	"Nodes = permission sets. Edges = escalation techniques (transitions to more privileged states). BFS from starting identity's permissions to target (s3:GetObject on sensitive bucket OR *:* admin). Output = the exact chain of techniques from initial access to target. Same graph-based reasoning as S09.2 attack-path analysis, applied to IAM."	c2a::s10::analysis
"What does Pacu's iam__privesc_scan module do?"	"Enumerates the current identity's permissions and identifies available IAM escalation paths. Pacu implements many escalation techniques as modules. The harness wraps Pacu, feeds its output into the privilege graph, and produces a structured escalation-path report — adding chain reasoning, scope enforcement, and evidence logging that the tool alone doesn't provide."	c2a::s10::recall
"Why must escalation paths be DEMONSTRATED, not theoretical?"	"The client doesn't trust 'Role-A could escalate to admin.' 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. A theoretical path is an assertion; a demonstrated path is proof."	c2a::s10::analysis
"What cloud-specific fields does the cloud evidence schema add to the S02.3 hash chain?"	"cloud_provider (aws/azure/gcp), account_id, region, api_call (e.g. s3:GetObject), resource_arn (exact resource acted on), actor_arn (which identity made the call). Plus the base fields: timestamp, request/response, scope_ref, previous_hash/record_hash (tamper-evidence), retention class."	c2a::s10::recall
"Why does the evidence schema require account_id, region, and resource_arn?"	"Precision. Not just 'a call was made' but 's3:GetObject was made against arn:aws:s3:::client-sensitive-data in us-east-1 from account 123456789012 at this timestamp, authorized by this scope entry, producing this response.' Makes the evidence reproducible and verifiable — the auditor or client can confirm exactly what happened."	c2a::s10::analysis
"What is the compliance mapping, and why does it matter?"	"Translates technical findings to SOC 2 / ISO 27001 / PCI DSS control references. An over-privileged IAM role isn't just 'a misconfiguration' — it's a violation of SOC 2 CC6.3, ISO 27001 A.9.2.5, PCI DSS 7.2.1. Matters because the AUDITOR doesn't understand iam:PassRole but does understand which control is at risk. Makes findings immediately actionable for compliance."	c2a::s10::application
"Map 'iam_over_privilege' to SOC 2, ISO 27001, and PCI DSS."	"SOC 2: CC6.3 (the entity authorizes/modifies/removes access to data). ISO 27001: A.9.2.5 (review of user access rights). PCI DSS: 7.2.1 (establish an access control system for systems components). The mapping makes the finding actionable for the compliance team without manual translation."	c2a::s10::recall
"What are the 4 sections of the cloud red team client report?"	"(1) Executive summary — overall risk, business impact, remediation roadmap (1 page, non-technical). (2) Finding table — ID, severity, resource, compliance mapping, status. (3) Attack narrative — step-by-step story backed by evidence chain. (4) Remediation roadmap — prioritized actions mapped to findings + frameworks."	c2a::s10::recall
"Why is the client report generated from the structured findings store, not hand-written?"	"The evidence chain ensures every claim in the narrative is backed by a reproducible API call sequence. The compliance mapping ensures every finding speaks the auditor's language. Hand-writing risks inconsistency between what was demonstrated and what is reported. Generation from the store guarantees consistency — the narrative references real evidence records."	c2a::s10::analysis
"Why is running nmap against cloud infrastructure an anti-pattern?"	"The cloud is not a network — it is an API. Port scanning finds nothing useful and wastes engagement time. An AWS account has no ports to scan in the way nmap scans. Cure: API-first, identity-first offensive architecture (S10.1) — enumerate via provider APIs, attack the IAM layer."	c2a::s10::analysis
"How does the harness handle impact demonstration without actual exfiltration?"	"Impact is demonstrated as READ-ONLY PROOF: a GetObject call that succeeds proves access without downloading data. Resource exposure is mapped (which buckets are readable), not exfiltrated. Persistence vectors are IDENTIFIED, not implemented. The harness demonstrates the path EXISTS — it does not steal data or cause harm. Every call is evidence-logged and scope-checked."	c2a::s10::application
"How does S10.2's privilege graph relate to S09.2's attack-path analysis?"	"Same graph-based path-finding technique, applied to different layers. S09.2: nodes are cloud assets (resources/identities/data stores), edges are access relationships, paths go from public entry points to sensitive targets. S10.2: nodes are permission sets, edges are escalation techniques, paths go from starting permissions to target permissions. The graph reasoning transfers; the domain changes."	c2a::s10::analysis