AWS Security Specialty (SCS-C03) common mistakes
AWS Security Specialty (SCS-C03) · Understand the traps and how to avoid them.
Evaluates an authorization scenario by finding a single Allow and stopping there, instead of walking the whole evaluation chain (SCP, resource policy, identity policy, permissions boundary, session policy).
Most questions present one layer's policy and offer distractors describing a different layer as if it overrode the others; candidates reach for the most familiar policy type rather than the most restrictive one in the chain.
What to do instead
Before choosing an answer, list every policy type in the request path and apply the rule: effective permission is the intersection of all boundaries with the union of identity-policy and resource-policy allows, and any explicit Deny anywhere wins. Practice by writing out the chain for cross-account AssumeRole, S3 bucket access, and KMS use.
Selects an SCP as the mechanism that grants a team access to a newly launched service, or as the mechanism that restricts activity in the organization's management account.
SCPs look like IAM policies and appear at the top of the hierarchy, so they read as 'the most powerful policy' and therefore as a way to grant or to cover every account.
What to do instead
Memorize the three hard facts: SCPs filter permissions but never grant them; they do not affect the management account; and they do not affect service-linked roles. Use SCPs only for guardrails on member accounts, and combine them with IAM identity policies for actual grants.
Enables a CloudTrail trail and then assumes every S3 object-level read and write, or every DynamoDB item operation, will appear in the logs for investigation.
The default trail records management events only; data events are a separate, opt-in, higher-volume category that many candidates have never had to turn on in practice.
What to do instead
When an investigation hinges on object-level access, specify selecting data events (S3 object-level, Lambda invoke, DynamoDB) on the trail, and route them to a separate bucket or log group for cost control. Also remember CloudTrail does not record data-plane reads for every service by default.
Treats CloudTrail log file integrity validation (digest files) as a control that stops logs from being deleted or altered, and answers questions about log tampering with 'enable log file integrity validation'.
The name suggests protection, but the feature is detective: it only lets you prove afterwards whether a delivered log file was changed.
What to do instead
Separate prevention from detection: prevent deletion/tampering with S3 Object Lock in compliance mode on the log bucket, a bucket policy denying s3:DeleteObject and s3:PutBucketPolicy to all but the trail's principals, and a dedicated log-archive account; use digest files only to verify integrity after the fact.
Picks a single detection service for every scenario, e.g. answering 'GuardDuty' for finding unencrypted S3 buckets or missing patches, or 'Inspector' for detecting cryptocurrency mining on an instance.
GuardDuty, Security Hub, Inspector, Macie, Config, and Detective all sound like 'the security service' and candidates memorize one name instead of the question each one answers.
What to do instead
Map scenario language to a service: anomalous API/network behaviour and threat findings = GuardDuty; sensitive data discovery in S3 = Macie; vulnerability and patch coverage on EC2/ECR/Lambda = Inspector; configuration compliance over time = Config; aggregation and standards scoring = Security Hub; investigation of a finding's actors and API calls = Detective.
Contains a compromised EC2 instance by terminating it, or by stopping it and calling the job done, without preserving volatile and disk evidence.
Termination feels like the fastest way to stop the attacker, and candidates treat containment as the goal rather than preserving evidence for the analysis phase of an incident response lifecycle.
What to do instead
Contain by replacing the security group with an isolation group that has no inbound/outbound rules (or by moving the instance to a quarantine subnet with a restrictive NACL), keep the instance running, capture an EBS snapshot and, where needed, memory via SSM, restrict the instance profile, then follow preparation/detection/containment/eradication/recovery/post-incident in order.
Assumes an IAM identity policy in the caller's account is sufficient for cross-account use of a KMS key, and writes answers that add only an IAM policy on the key or only a key policy.
IAM is the default mental model for permissions, and candidates forget that a KMS key policy is the root of trust for that key and cannot be bypassed by IAM unless the key policy delegates to IAM.
What to do instead
For cross-account KMS use, require both: the key policy in the key-owner account must allow the external principal (or allow the account with kms:CreateGrant and the right condition keys), and the caller's identity policy must allow the KMS actions. Remember the key policy must permit IAM policies in the owning account before any identity policy on that key has effect.
Diagnoses an 'Access Denied' on a cross-account S3 read or a presigned-URL failure as a Block Public Access problem and prescribes turning off account-level Block Public Access.
Block Public Access is the most recognizable S3 access control, so any unexplained denial gets attributed to it, even when the failure comes from the bucket policy principal, Object Ownership/ACL settings, or a KMS key policy.
What to do instead
Work through the actual dependency order: is the request signed (presigned URLs expire and are bound to the signing credentials), does the bucket policy name the right principal and account, does Object Ownership disable ACLs, does the object use a customer-managed KMS key whose key policy allows the caller, and only then check which Block Public Access setting applies. Note that Block Public Access does not block IAM-authorized cross-account access through a bucket policy.
Applies security group reasoning to a network ACL, or a network ACL rule set to a security group - for example opening only inbound 443 in a NACL and expecting return traffic to flow.
Both look like firewall rule lists in the console, and the stateful/stateless distinction and the ephemeral-port requirement only matter in edge cases candidates rarely configure by hand.
What to do instead
Anchor on two facts: security groups are stateful and allow-only, so return traffic is automatic; NACLs are stateless and support allow and deny, so return traffic requires an outbound rule covering ephemeral ports 1024-65535. Also remember security groups can reference other security groups while NACLs cannot, and NACLs evaluate rules in numbered order.