The traps that sink strong engineers

1. “Return traffic is allowed automatically” — security groups vs network ACLs

The trap. Treating network ACLs like security groups.

The reality. Security groups are stateful: allow a connection inbound and the response is permitted outbound automatically. Network ACLs are stateless: every direction is evaluated independently, so a NACL that allows inbound 443 must also allow outbound traffic on the ephemeral port range (commonly 1024–65535) or the response never leaves. Security groups are also allow-only — there is no deny rule — while NACLs have both allow and deny, evaluated in rule-number order.

The exam tell. "The connection is established but no response is received", "we added an inbound rule and it still fails", or any requirement to block a specific IP address — which only a NACL can do.

2. SCPs do not grant anything

The trap. Writing an SCP to give a member account a permission, or expecting an SCP to protect the management account.

The reality. An SCP sets the maximum available permissions for principals in member accounts. The effective permission is the intersection of the SCP and the identity policy: if the SCP allows and IAM does not, access is denied. SCPs also do not apply to the management account, and do not restrict the service-linked roles AWS uses.

The exam tell. An option that says "attach an SCP allowing…" is almost always wrong. "Even the account administrator must not be able to" is right. And if the scenario happens in the management account, the SCP answer is the distractor.

3. IAM alone cannot authorise use of a KMS key

The trap. Granting kms:Decrypt in an identity policy and expecting it to work.

The reality. Every KMS key has a key policy, and it is mandatory — it is the primary authority for the key. IAM policies can only grant key use if the key policy delegates to IAM (the default key policy for a customer managed key does, for principals in the key's own account). Cross-account use always requires the key policy to name the other account and an identity policy in that account. Grants are the third mechanism, for temporary, programmatic delegation.

The exam tell. "The role has kms:Decrypt but still receives AccessDenied", or any cross-account encryption scenario. Also: AWS managed keys have key policies you cannot edit and cannot be shared cross-account — so any such requirement forces a customer managed key.

4. A presigned URL cannot exceed the signer’s permissions

The trap. Believing a presigned URL is a magic grant, or that it works once the signer's access is revoked.

The reality. A presigned URL carries the signer's identity and permissions, for a limited time. If the signer could not read the object, the URL cannot either; if the signer's permissions are revoked — or the temporary credentials used to sign it expire — the URL stops working, even inside its stated expiry. A URL signed with a long-lived IAM user key can outlive your intentions, which is the reason to sign with a narrowly scoped role.

The exam tell. "Allow a third party with no AWS account to upload one file" (correct use), or "the URL grants more than the application role has" (impossible).

5. Explicit deny always wins

The trap. Debugging an access failure by adding more allows.

The reality. Evaluation begins at an implicit deny, gathers every applicable policy, and returns Deny if any of them denies — identity policy, resource policy, SCP, RCP, permission boundary, session policy, or VPC endpoint policy. Nothing outranks an explicit deny, including AdministratorAccess.

The exam tell. A principal who clearly has the permission is still denied. Stop looking for a missing allow and start looking for the Deny: organization policies first, then boundaries and session policies, then resource and key policies.

6. Macie finds sensitive data; it does not protect it

The trap. Choosing Macie as the answer to "prevent PII from being exposed" or "redact the sensitive fields".

The reality. Macie discovers and classifies sensitive data in Amazon S3 and produces findings. It does not redact, move, encrypt, or block. Remediation is a separate step — a bucket policy or Block Public Access to stop exposure, a transformation job or masking to remove the data, a Lambda triggered by the finding to quarantine the object.

The exam tell. "Identify which buckets contain…" → Macie. "Ensure the data is never exposed" → a preventive control, with Macie at most as the discovery half of a two-part answer. For masking in logs and notifications, the C03 answers are CloudWatch Logs data protection policies and SNS message data protection.

7. GuardDuty reads logs you have not enabled

The trap. Answering "we must first enable CloudTrail, VPC Flow Logs and DNS logging so GuardDuty can analyse them".

The reality. GuardDuty consumes CloudTrail management events, VPC flow data and DNS query data independently of your own log configuration — you do not have to enable or pay to store those logs for GuardDuty to work. (You may still want them for your own investigation, which is a different requirement.) Its optional protection plans extend coverage: S3 protection, EKS and runtime monitoring, malware protection, RDS protection.

The exam tell. "Detect threats with the least operational overhead" or "without building a logging pipeline" — the single-step answer is "enable GuardDuty".

8. Config records state; CloudTrail records calls

The trap. Using them interchangeably, or reaching for CloudTrail to answer a configuration question.

The reality. CloudTrail answers who did what, when, and from where — a stream of API calls. AWS Config answers what did this resource look like — configuration items over time, with rules, conformance packs and remediation. CloudTrail cannot tell you the standing configuration between calls; Config cannot tell you which principal made a change outside its recording.

The exam tell. "At 14:00 last Tuesday, was it encrypted?" → Config. "Which principal deleted it?" → CloudTrail. Also note CloudTrail's own trap below.

9. CloudTrail does not log object-level access by default

The trap. Assuming CloudTrail already shows who read a particular S3 object or invoked a particular Lambda function.

The reality. Management events are recorded by default; data events (S3 object-level activity, Lambda invocations, and others) are not — you enable them explicitly, with advanced selectors to control volume and cost. Without them, a data-exfiltration investigation has no object-level evidence.

The exam tell. "We need to know which objects were downloaded" or "there is no record of the read". The answer is enabling data events, usually on an organization trail, not "check CloudTrail".

10. Object Lock compliance mode cannot be shortened by anyone

The trap. Assuming the account root user, or the bucket owner, can override retention "in an emergency" — or choosing governance mode when the requirement says nobody may override.

The reality. Governance mode can be bypassed by a principal holding s3:BypassGovernanceRetention. Compliance mode cannot be bypassed, shortened or removed by any user, including the account root user, until the retention period expires. A legal hold is separate and indefinite until removed by someone with permission. S3 Glacier Vault Lock is the equivalent for a vault policy, locked permanently once you confirm it.

The exam tell. "Cannot be deleted even by the root user", "regulatory retention", "WORM", "tamper-proof". Choose compliance mode — and note that Object Lock requires versioning.

11. Cross-account access needs permission on both sides

The trap. Writing one half of the pair and expecting it to work.

The reality. For a role assumption, the trust policy on the role in account A must allow the principal in account B, and the principal in account B must be allowed to call sts:AssumeRole on that role. For resource access without assumption, the resource policy (bucket policy, KMS key policy, Secrets Manager resource policy) must allow the external principal and that principal's identity policy must allow the action. Trusting an entire account in a trust policy delegates the decision to that account's administrators — name a specific role when the requirement is tight.

The exam tell. An option that changes only the bucket policy, or only the role policy, in a cross-account scenario. Also "add an external ID" for third-party access, which defends against the confused-deputy problem.

12. aws:PrincipalOrgID is not aws:SourceIp

The trap. Conflating the identity perimeter with the network perimeter, or using an IP condition as an authentication control.

The reality. aws:PrincipalOrgID restricts by who is asking — any principal in your organization, without listing accounts. aws:SourceIp restricts by the public IP the request came from, and it does not match requests that arrive through a VPC endpoint — for those you need aws:SourceVpc or aws:SourceVpce. Related: aws:PrincipalAccount and aws:PrincipalOrgPaths for finer identity scoping, and aws:ResourceOrgID for the mirror direction.

The exam tell. "Only principals in our organization" → PrincipalOrgID. "Only from our corporate network" → SourceIp, with the VPC-endpoint caveat waiting to catch you. An IP condition is never the answer to "no long-lived credentials" or "authenticate the caller".

13. IMDSv1 is an SSRF amplifier

The trap. Treating instance metadata as an internal detail rather than a credential endpoint.

The reality. The instance metadata service hands out the instance profile's temporary credentials to anything that can make an HTTP request from the instance. With IMDSv1 that is a simple GET, so a server-side request forgery bug in your application can read the role's credentials and use them from anywhere. IMDSv2 requires a session token obtained with a PUT and limits the response hop count, which defeats the common SSRF and proxy paths. You can require IMDSv2 on launch, enforce it with a Config rule or an SCP condition, and verify it with Inspector.

The exam tell. "Credentials from the instance role were used from an external IP address", "an SSRF vulnerability", "harden metadata access". The answer is requiring IMDSv2 (and reducing the hop limit), not rotating the role.

14. KMS key deletion is a scheduled waiting period

The trap. Believing a key can be deleted immediately, or that deleting a key is a clean way to revoke access.

The reality. You schedule key deletion with a waiting period of 7 to 30 days (the default is 30), during which the key is unusable but recoverable by cancelling the deletion. After it elapses the key material is gone and every ciphertext encrypted under it is permanently unrecoverable. If you only need to stop use, disable the key or change the key policy or grants — reversible actions.

The exam tell. "Immediately prevent use of the key" → disable it or amend the key policy, not delete. "We need to be able to undo this" → the waiting period. "The data must become unreadable" → deletion, with the data-loss consequence stated.

15. Shield Advanced is not automatic

The trap. Assuming that subscribing to Shield Advanced protects everything you own.

The reality. AWS Shield Standard is automatic and free for all customers. Shield Advanced is a paid subscription, and after subscribing you must add the specific resources to protection — CloudFront distributions, load balancers, Global Accelerator accelerators, Route 53 hosted zones, Elastic IPs. Only then do you get the enhanced detection, the response team engagement, and DDoS cost protection. Firewall Manager is how you apply it consistently across an organization.

The exam tell. "We subscribed to Shield Advanced but the attack was not mitigated" — the resource was never protected. Also watch the WAF boundary: application-layer attacks are a WAF answer.

16. You cannot encrypt an existing resource in place

The trap. Looking for an "enable encryption" switch on an existing RDS instance or EBS volume.

The reality. Encryption at rest is set at creation. For RDS: snapshot, copy the snapshot with encryption and a KMS key, restore, cut over. For EBS: snapshot, copy the snapshot encrypted, create a new volume, attach. Enabling EBS encryption by default fixes the future, not the past. S3 is the exception that confuses people — there you can change the default encryption for new objects and re-encrypt existing ones by copying them.

The exam tell. An existing unencrypted production database or volume plus a compliance deadline. The key is the snapshot-copy-restore sequence; "enable encryption on the instance" is the distractor.

17. Automatic key rotation does not re-encrypt your data

The trap. Expecting rotation to re-encrypt existing ciphertext, or expecting imported key material to rotate itself.

The reality. KMS automatic rotation creates new backing key material while the key id, ARN and aliases stay the same; old material is retained so existing ciphertext remains decryptable, and nothing is re-encrypted. Rotation therefore does not help if the concern is that old ciphertext must be unreadable — that requires re-encrypting the data. Imported key material does not support automatic rotation at all: you rotate it by importing new material, and it can be given an expiry date, after which the key is unusable until new material is imported.

The exam tell. "Rotate the key annually with no application changes" → automatic rotation on a customer managed key. "We must generate the key material ourselves" → imported material, and the rotation story changes completely.

18. Not every VPC endpoint is the same kind

The trap. Answering "create a VPC endpoint" without saying which, or forgetting that the endpoint has its own policy.

The reality. Gateway endpoints exist for Amazon S3 and DynamoDB and work through route tables, at no hourly cost. Everything else — Secrets Manager, KMS, Systems Manager, CloudWatch Logs, STS, partner services — uses an interface endpoint backed by PrivateLink, which is an elastic network interface with a security group and a private DNS name. An endpoint policy is a separate control from the resource policy, and it is a good place to require that only your organization's resources are reachable through it.

The exam tell. "Private access to Secrets Manager" is an interface endpoint; "private access to S3" is gateway (or an interface endpoint if the traffic comes from on premises). "Restrict what can be reached through the endpoint" is the endpoint policy.

19. Block Public Access is not the same as cross-account access

The trap. Enabling Block Public Access and thinking the bucket is now private, or disabling it to allow a partner account.

The reality. Block Public Access overrides bucket policies and ACLs that would grant access to anonymous or any-AWS-principal requests, and it can be enforced at the account level. It does not block access granted to a named principal in another account — that is cross-account access, which is governed by the bucket policy and the other side's identity policy. So you can and should keep Block Public Access on while sharing with a partner account.

The exam tell. "Our partner must read the bucket, and it must never be public" — both are true at once. An option that disables Block Public Access to enable partner access is the trap.

20. Detection without a response path is decoration

The trap. Choosing an answer that ends at a finding when the requirement was to act — or expecting GuardDuty to block something.

The reality. GuardDuty, Inspector, Macie, Config and Security Hub all report. None of them blocks an API call or quarantines a resource. The action comes from a path you build: EventBridge on the finding, then a Systems Manager Automation document, a Step Functions runbook, a Lambda function, or Config automatic remediation. Likewise, revoking a role's access is not "delete the credential" — temporary credentials cannot be deleted; you deny requests whose aws:TokenIssueTime precedes the cut-off, and you fix the policy that granted the access.

The exam tell. "Automatically contain", "without manual intervention", "in near real time". The key names both halves: the detector and the thing that acts on it.

Access is denied — where is the deny?

Interactive decision tree — outcomes:

• An SCP (or RCP) on the organization

  The most common cause of "the administrator is denied". Check the SCPs on the account and every OU above it, and the RCPs if the resource is a supported type. Remember the exception that makes a good distractor: SCPs do not apply to the management account.

• The resource policy

  A bucket policy, KMS key policy, Secrets Manager resource policy, SQS policy or role trust policy with an explicit Deny — or simply without the Allow that cross-account access requires. Resource policies are also where organization conditions such as aws:PrincipalOrgID are usually enforced.

• A permission boundary

  Boundaries cap the effective permissions of the principal they are attached to, so a developer-created role cannot exceed them and a delegated administrator cannot escalate. Invisible from the identity policy, which is what makes this a good exam item.

• A session policy

  Passed at AssumeRole time, narrowing that one session only. If access works when the role is assumed one way and fails another, look at what the calling code passes — and at the session duration while you are there.

• The KMS key policy or a missing grant

  Reading an encrypted object needs permission on the key as well as the data. The key policy is the primary authority; IAM only works where the key policy delegates to it. Cross-account and AWS-managed-key scenarios are where this bites hardest.

• The identity policy

  The ordinary case: the action or the resource ARN is not covered. Confirm with the IAM policy simulator, and generate the right policy from observed CloudTrail activity with IAM Access Analyzer rather than widening to a wildcard.

• Both sides, not one

  Cross-account access needs the resource (or trust) policy to allow the external principal and that principal's identity policy to allow the action. An answer that changes only one side is incomplete — and for third-party access, an external ID in the trust policy is what defends against the confused deputy.

• The VPC endpoint policy — or a network condition

  An endpoint policy is a separate gate on what can be reached through the endpoint. Also check the conditions on the resource policy: aws:SourceIp does not match requests arriving via a VPC endpoint, so a policy written for a corporate IP range will deny traffic that now takes the private path. Use aws:SourceVpc or aws:SourceVpce instead.