AWS Security Specialty common mistakes
AWS Security Specialty · Understand the traps and how to avoid them.
On a suspected compromised EC2 instance, the candidate's first action is to terminate or stop the instance, or to immediately rotate credentials without capturing evidence.
Remediation instincts from operations work take over, and stopping feels 'safer than leaving it running'. Candidates forget that stopping/terminating destroys volatile memory and the instance's running state, which is often the only place the compromise mechanism (process, injected code, in-memory credentials) is visible.
What to do instead
Memorise the order: contain first, without destroying evidence. Replace the instance's security groups with a forensic group that allows no ingress or egress (isolation), enable termination protection, capture volatile data (memory via SSM/AVML, or at minimum an EBS snapshot of attached volumes), then perform remediation on a rebuilt instance. Practice ranking answer choices by 'does this action destroy state I cannot recreate?'
Assuming GuardDuty, Security Hub, or Macie will block or remediate the activity they detect - for example expecting GuardDuty to stop traffic to a malicious IP or Security Hub to disable a leaked access key.
The names and finding severities suggest enforcement, and in other security products 'detect' and 'block' are bundled. In AWS these are detection and aggregation services only; nothing they produce changes a resource's configuration or permissions.
What to do instead
Treat detection findings as events, not controls. The remediation pattern is: finding → EventBridge rule matching the finding type/severity → Lambda or SSM Automation document that applies the fix (disable key, attach isolation SG, revoke public bucket ACL). When a question says 'automatically', look for an EventBridge rule plus a target - not a detection service alone. Macie classifies sensitive data; Security Hub aggregates and scores findings; neither enforces.
Answering that S3 object-level (GetObject/PutObject) activity is recorded by CloudTrail by default, or that a trail created in the console captures everything needed for an investigation.
CloudTrail is described as 'logging all API activity', so candidates assume full coverage. In reality a trail captures management events by default; data events (S3 object-level, Lambda Invoke, DynamoDB item-level) must be explicitly enabled per trail per event type and are billed separately, which is exactly why they are usually missing when an investigation needs them.
What to do instead
Learn the layer split: CloudTrail management events = control plane (CreateBucket, PutBucketPolicy, AssumeRole); CloudTrail data events = data plane and are off unless enabled; VPC Flow Logs = network metadata; S3 server access logs = bucket-level requests. When asked how to determine whether a specific object was read, the answer must include enabling data events - and when asked about near-real-time reaction, route the trail to EventBridge rather than polling the S3 log bucket, since delivery to S3 is not instantaneous.
Designing a cross-account centralized log archive where the trail and the destination S3 bucket live in the same account, or in different accounts but with only an IAM policy on the trail side and no bucket policy and KMS key policy in the log-archive account.
Candidates focus on the CloudTrail resource and forget that delivery is a write performed by the CloudTrail service principal into a bucket owned by someone else, which is authorised by the bucket policy, not by the trail owner's IAM. If the bucket uses SSE-KMS, a second authorisation layer is needed.
What to do instead
Remember that centralised logging needs three cooperating policies: (1) the bucket policy in the log-archive account granting cloudtrail.amazonaws.com s3:PutObject (plus s3:GetBucketAcl) scoped with aws:SourceArn to the specific trail and s3:x-amz-acl conditions; (2) the KMS CMK policy in the log-archive account allowing the CloudTrail service principal from the trail's account to GenerateDataKey/Decrypt; (3) the key and bucket must be in the same Region as the trail. Combine with an Organization trail created from the management account so new accounts are covered automatically, and block CloudTrail modifications in member accounts via SCP.
When asked to block a single malicious source IP from reaching an EC2 instance, the candidate edits the instance's security group and adds an inbound deny rule for that address.
Firewall experience from on-premises and other clouds makes 'deny' feel like a basic capability, and security groups are the first tool reached for. Security groups are allow-only, and this constraint is the single most frequently tested infrastructure detail.
What to do instead
Map the tools by capability: security groups are allow-only and stateful (return traffic is automatically permitted); NACLs support explicit deny rules, are stateless, and are evaluated in numbered order - so a deny rule for a single IP belongs on the subnet's NACL. When you write a NACL rule, also add the corresponding inbound and outbound rules for ephemeral ports (1024-65535) on both sides, or the legitimate traffic breaks too. For edge protection use AWS WAF IP sets or Shield, not SGs.
Treating an SCP as a way to grant permissions, or expecting an SCP applied at the organization root to restrict activity in the management account or in service-linked roles.
SCPs are visually attached like IAM policies and contain Allow statements, which reads as 'this is how you give accounts access to a service'. The mental model of 'policy = permission' is wrong here: an SCP is a guardrail that filters what identity-based policies can do.
What to do instead
State the rule as: effective permissions = SCP ∩ permissions boundary ∩ identity-based policy ∩ resource-based policy, minus any explicit deny anywhere. An SCP with an Allow list grants nothing on its own; a Deny in an SCP overrides every Allow below it. Remember SCPs do not affect the management account and do not apply to service-linked roles. Use SCPs for region lockout, blocking CloudTrail/Config deletion, and blocking root usage - never as the mechanism for granting access.
Granting a role in account A access to a KMS-encrypted resource in account B by editing only the IAM policy on the role in account A (or only the resource policy on the bucket/queue), assuming the access will then work.
Candidates generalise the 'cross-account needs both sides' rule inconsistently - sometimes applying it to KMS when the missing piece is actually the key policy, and sometimes forgetting that KMS keys are a separate authorisation boundary in front of the encrypted resource. Adding an S3 bucket policy does not grant access to the objects if the key policy does not also allow the caller to Decrypt.
What to do instead
For KMS, the key policy is the primary control: an IAM policy alone is never sufficient unless the key policy explicitly delegates to IAM (the default key policy does this only for the key's own account). Cross-account access requires the key policy to name the external account/principal (or a grant), plus the caller's identity policy allowing kms:Decrypt/GenerateDataKey, plus the resource policy on the bucket/queue where one exists. Answer choices that mention only one of these three are wrong.
Describing a permissions boundary as a way to give a role extra permissions, or as a substitute for an SCP that applies account-wide.
Boundaries are attached to a user or role like any other policy and use the same JSON syntax, so they look additive. Candidates also blur them with SCPs because both are 'maximum permission' constructs.
What to do instead
Recall the scope distinction: a permissions boundary caps the maximum permissions of one IAM user or role (identity-based policies only), does not grant anything, and does not apply to resource-based policies or to service-linked roles; an SCP caps all principals in an account or OU except the management account. The classic use case for a boundary is delegating role creation - allow iam:CreateRole but require that every created role carries a specific boundary, so a developer cannot escalate to admin.
Selecting SSE-S3 for a requirement that says the organisation must audit every use of the encryption key, rotate keys under its own control, or enforce separation of duties between key administrators and data users.
All S3 encryption options are presented as 'encryption at rest', so candidates pick the simplest one and move on. The distinguishing properties - who owns the key, whether key usage appears in CloudTrail, whether key policy can enforce separation of duties - are what the question is actually testing.
What to do instead
Choose by requirement: SSE-S3 (AES-256, AWS-managed, no CloudTrail record of key use, no key policy) fits baseline 'encrypt at rest' compliance; SSE-KMS fits auditability, independent key policies, grants, and per-key rotation control; SSE-C fits the rare case where the customer retains the key entirely and accepts that AWS never stores it; client-side encryption fits 'AWS must never see plaintext'. If the requirement mentions auditing key usage, cross-account key sharing, or separate key administrators, the answer is SSE-KMS with a customer managed key. Also note that enabling default bucket encryption does not retroactively re-encrypt existing objects - they must be copied or rewritten.
Expecting AWS Config to prevent a non-compliant resource from being created, or to fix it automatically as soon as it is flagged.
Config rules report 'noncompliant' with a red status that reads like enforcement, and the word 'rule' implies blocking. In practice evaluation happens after the change, and remediation is a separate, opt-in configuration.
What to do instead
Separate the three governance tools by verb: CloudTrail records who called what API; AWS Config records resource configuration state and evaluates rules against it (detective, regional, aggregated across accounts/Regions with a Config aggregator); SCPs prevent the API call. For automatic correction, the Config rule must have a remediation action attached that runs an SSM Automation document under an IAM role. For automatic prevention, use an SCP deny or a CloudFormation/Bucket policy guardrail - Config alone never blocks anything.