Security And Governance Boundary — AWS Security Specialty (SCS-C03)

Whether to fix the CloudWatch Logs destination log group resource policy (precise, least-privilege) versus broadening the cross-account IAM role's trust or inline permissions — the latter unblocks nothing because CloudWatch Logs enforces its own resource-policy gate independently of IAM.

Fix the cross-account log delivery failure by correcting the precise policy layer blocking delivery — either the CloudWatch Logs destination resource policy missing the workload account's delivery principal, or the IAM role trust policy that no longer permits the CloudTrail service principal to assume the role — rather than broadening the IAM role's identity-based policies to compensate for the gap.

Whether to terminate the instance immediately for speed-of-recovery — permanently destroying volatile memory and disk forensic state — or execute a forensic-safe containment-first sequence (isolate via security group quarantine, snapshot EBS volumes, preserve volatile memory) before eradication, which is the only approach that satisfies evidence-integrity and chain-of-custody governance requirements.

Evidence capture and instance isolation must be sequenced before any destructive or mutating eradication action; an automated runbook that quarantines or stops the instance before acquiring a memory dump and EBS snapshot crosses the chain-of-custody governance boundary even if it reduces blast radius faster.

Whether to sequence containment first — isolating the instance and capturing an EBS snapshot before any eradication — or to prioritise operational speed by terminating and rebuilding, which destroys volatile memory and disk evidence and violates the chain-of-custody governance boundary.

Whether L7 exploit mitigation, geo-restriction enforcement, and DDoS cost-protection SLA eligibility all require CloudFront edge placement, because geo-restriction and Shield Advanced cost-protection SLAs are exclusively available at edge PoPs and cannot be satisfied by controls applied at the VPC or ALB layer.

Whether build-time vulnerability scanning via Inspector integrated with EC2 Image Builder, or runtime threat detection via GuardDuty, satisfies the pre-deployment AMI gate constraint under least-privilege compute governance.

Whether intra-VPC east-west L7 inspection is satisfied by a Network Firewall endpoint inserted into the VPC routing path, or requires a Transit Gateway hub-and-spoke centralized inspection architecture — hinging on scope boundary (single VPC vs. multi-VPC) as the disqualifying dimension.

When a scenario requires both L7 application-layer threat mitigation (OWASP Top 10) AND an SLA-backed DDoS cost-protection guarantee with DRT access, CloudFront + WAF alone is near-right because WAF covers L7 but does not provide volumetric DDoS cost absorption or DRT escalation; Shield Advanced must be added to satisfy the stated SLA and response-team constraint.

Which service enforces vulnerability assessment at AMI build time versus which services operate at runtime, and why substituting a runtime detection service (GuardDuty) or a runtime patching service (Patch Manager) for a build-time gate fails the PCI-DSS pre-deployment control requirement.

Whether stateful L3/L4 controls (security groups, NACLs) satisfy the PCI-DSS east-west IDS/IPS inspection mandate, or whether an L7-capable stateful inspection engine (Network Firewall with IPS rule groups) is required at a centralized enforcement point reached via Transit Gateway routing.

Whether Shield Advanced is required when the stated threat model is limited to L7 application-layer exploits and the compliance requirement is geo-restriction plus per-request audit logging — not volumetric DDoS protection or DRT SLA coverage.

Whether vulnerability compliance is enforced at build time by integrating Inspector into an EC2 Image Builder pipeline as a blocking gate (correct: produces an auditor-presentable scan report tied to each published AMI) or delegated to runtime GuardDuty or continuous Inspector scanning (compliance misconception: runtime detection cannot retroactively satisfy a pre-deployment gate requirement that PCI-DSS Requirement 6.3 demands).

Whether native stateful VPC security group rules satisfy the intra-VPC east-west zero-trust micro-segmentation requirement, making centralized AWS Network Firewall deployment unnecessary scope overreach given the explicit prohibition on centralized routing overhead.

Whether to attach WAF managed rules plus Shield Advanced directly to the CloudFront distribution or to overreach by routing WAF policy management through Firewall Manager, which is architecturally correct only for multi-account or multi-region governance and introduces unjustified operational complexity in a single-account deployment.

Whether to enforce the vulnerability control at build time via EC2 Image Builder and Inspector pipeline integration, or to overreach into runtime threat detection (GuardDuty) or post-deployment patching (SSM Patch Manager), given that the explicit constraint is a pre-deployment gate before any instance is launched.

Whether intra-VPC east-west L7 inspection is satisfied by deploying AWS Network Firewall in a dedicated subnet within the existing VPC via route table steering, or requires a Transit Gateway-based centralized inspection VPC.

Choose the service combination that satisfies continuous customer-resource compliance detection (AWS Config rules) AND organized audit-evidence collection (AWS Audit Manager), and disqualify options that substitute static AWS-side attestation retrieval (AWS Artifact) for either phase.