Compliance Misconception — AWS Security Specialty (SCS-C03)

Whether deploy-time gating via Service Catalog launch constraints satisfies a zero-tolerance PCI-DSS deployment consistency mandate, versus post-deployment detection-and-remediation via AWS Config rules which leaves an inherent non-compliant window.

Whether AWS Config organizational rules feeding Security Hub's PCI-DSS standard (configuration-compliance monitoring) or Amazon GuardDuty (threat detection) satisfies the requirement to alert on configuration deviations against a named compliance framework across all member accounts.

Whether to enforce per-tenant data isolation by attaching an inline session policy to the STS AssumeRole call versus applying IAM permission boundaries to the shared role — one scopes the effective credentials to the tenant context at issuance time, the other only caps the permission ceiling and requires an identity policy to grant anything, providing no session-level tenant isolation.

Should MFA enforcement be delegated to the IdP SAML assertion and trusted by STS, or enforced independently at the AWS authentication boundary before credentials are issued?

Whether STS AssumeRole with an inline session policy containing tenant-scoped resource conditions, or an IAM permission boundary attached to the shared execution role, satisfies both the anti-role-proliferation constraint and the compliance requirement for per-request authorization enforcement evidence.

When a compliance mandate explicitly names FIPS 140-2 Level 3 hardware key custody AND requires automated rotation without manual re-import, CloudHSM is the correct service boundary — standard KMS operates at Level 2 and KMS imported key material does not support automatic rotation, requiring manual re-import on every rotation cycle.

Whether the selected ELB security policy enforces TLS 1.2 as the minimum negotiated protocol version (blocking TLS 1.0 and 1.1 entirely) rather than only advertising TLS 1.2 among several accepted versions, and whether the backend target group path avoids any public-IP exposure.

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.

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.

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 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).

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.