How to Use This Quick Reference
This independent Quick Reference supports preparation for the AWS Certified Security – Specialty (SCS-C03) exam. Use it to make fast decisions in scenario questions: which AWS control fits the requirement, where the control is enforced, and what common distractor looks similar but is wrong.
Scenario Decoder
| If the scenario says… | First AWS choice to consider | Why |
|---|
| “Who called this API?” | AWS CloudTrail | API audit history |
| “What changed in this resource?” | AWS Config | Configuration timeline and compliance |
| “Detect malicious or suspicious activity” | Amazon GuardDuty | Managed threat detection findings |
| “Aggregate security findings across accounts” | AWS Security Hub | Central security posture and findings |
| “Investigate a GuardDuty finding” | Amazon Detective | Entity relationship and activity investigation |
| “Find sensitive data in S3” | Amazon Macie | S3 data discovery/classification |
| “Find public or cross-account access” | IAM Access Analyzer | External access and policy analysis |
| “Scan EC2/ECR/Lambda for vulnerabilities” | Amazon Inspector | Vulnerability management |
| “Encrypt with customer control over keys” | AWS KMS customer managed key | Key policy, rotation, grants, audit |
| “Dedicated HSM control” | AWS CloudHSM | Customer-managed HSM cluster |
| “Protect HTTP apps from SQLi/XSS/bots” | AWS WAF | Layer 7 web filtering |
| “Network firewalling across VPC traffic” | AWS Network Firewall | Stateful/stateless network inspection |
| “Private access to AWS services” | VPC endpoints / AWS PrivateLink | Avoid public internet path |
| “Centralize preventive controls across accounts” | AWS Organizations SCPs | Guardrail maximum permissions |
| “Automate response to findings” | Amazon EventBridge + Lambda / SSM Automation | Event-driven remediation |
flowchart TD
A[Security scenario] --> B{Need prevention, detection, or response?}
B -->|Prevention| C{Identity, network, or data?}
C -->|Identity| D[IAM policy, SCP, boundary, resource policy]
C -->|Network| E[SG, NACL, WAF, Network Firewall, endpoint]
C -->|Data| F[KMS, S3 controls, Secrets Manager, Macie]
B -->|Detection| G{What signal?}
G -->|API| H[CloudTrail]
G -->|Config drift| I[AWS Config]
G -->|Threat finding| J[GuardDuty / Inspector / Macie]
B -->|Response| K[EventBridge, Lambda, SSM, isolation, key rotation]
Identity and Access Management
Policy Type Decision Table
| Control | Scope | Grants permissions? | High-yield use | Common trap |
|---|
| IAM identity-based policy | User, group, role | Yes | Allow a principal to call AWS APIs | Does not by itself grant access to resources that require resource-side trust |
| Resource-based policy | Resource, such as S3 bucket, KMS key, SQS queue, Lambda function | Yes | Grant same-account or cross-account access to a resource | Principal and condition mistakes cause unintended exposure |
| Trust policy | IAM role | Allows role assumption | Define who can assume a role | Trust policy does not define what the role can do after assumption |
| Permissions boundary | IAM user or role | No | Set maximum permissions for delegated IAM creation | Boundary does not grant access |
| Session policy | STS session | No | Further restrict temporary credentials | Cannot expand the role’s base permissions |
| SCP | AWS Organizations account / OU | No | Prevent actions across member accounts | SCPs do not apply to the management account and do not grant permissions |
| ACL | Legacy/resource-specific | Sometimes | S3 legacy access patterns | Prefer bucket policies and S3 Object Ownership where possible |
| AWS RAM | Shared resources | No IAM permission grant by itself | Share supported resources across accounts | Recipient still needs IAM permissions to use shared resource |
| IAM Identity Center | Workforce access | Via permission sets | Central human access to AWS accounts/apps | Not for application-to-application authorization |
IAM Evaluation Essentials
| Rule | Exam impact |
|---|
| Explicit deny wins | Any applicable explicit deny overrides allows |
| No allow means deny | Default is implicit deny |
| Guardrails limit maximum access | SCPs, permissions boundaries, and session policies do not grant permissions |
| Resource policies matter for cross-account | The resource account must trust/allow the external principal |
| KMS is special | Cross-account KMS access usually requires both key policy permission and caller-side IAM permission |
| Service-linked roles are service-managed | Do not treat them like normal customer-managed roles |
| Temporary credentials inherit restrictions | STS sessions can be constrained with session policies, tags, MFA, and duration settings |
Which IAM Mechanism Should You Choose?
| Requirement | Choose | Notes |
|---|
| EC2 application needs AWS API permissions | IAM role attached as instance profile | Avoid long-term access keys on instances |
| Lambda needs to call DynamoDB | Lambda execution role | Function assumes the role automatically |
| ECS task needs S3 access | ECS task role | Do not use the container instance role for app permissions |
| EKS pod needs AWS API access | IAM Roles for Service Accounts / pod identity pattern | Use OIDC-based trust instead of node role over-permissioning |
| Third-party SaaS needs account access | Cross-account role with external ID | Mitigates confused deputy risk |
| Human workforce access to many accounts | IAM Identity Center permission sets | Centralized account assignment and federation |
| One account must read another account’s S3 bucket | Bucket policy plus caller IAM permission as needed | Validate principal, conditions, and encryption key access |
| Deny all accounts from disabling security services | SCP | Preventive organization guardrail |
| Delegate IAM role creation but cap permissions | Permissions boundary | Attach boundary to roles users create |
| Restrict an assumed role session further | Session policy | Applied when calling STS |
Condition Keys Worth Recognizing
| Condition key | Use case |
|---|
aws:PrincipalOrgID | Allow only principals from your AWS Organization |
aws:SourceArn | Restrict service-to-service calls to a specific source resource |
aws:SourceAccount | Prevent cross-account confused deputy with AWS service principals |
sts:ExternalId | Third-party cross-account role assumption protection |
aws:MultiFactorAuthPresent | Require MFA for sensitive actions |
aws:RequestedRegion | Restrict actions by AWS Region |
aws:SecureTransport | Require HTTPS/TLS |
aws:SourceIp | Restrict by public source IP |
aws:SourceVpce | Restrict access through a specific VPC endpoint |
aws:PrincipalTag / aws:ResourceTag | ABAC authorization |
kms:ViaService | Allow KMS key use only through a specific AWS service |
kms:EncryptionContext:* | Bind KMS use to expected encryption context |
s3:x-amz-server-side-encryption | Enforce S3 upload encryption header |
KMS, Encryption, and Key Management
AWS KMS Decision Table
| Requirement | Choose | Why |
|---|
| Default service-managed encryption with minimal control | AWS owned key or AWS managed key | Least operational overhead |
| Customer controls policy, rotation, grants, audit | Customer managed KMS key | Best exam answer when key control is required |
| Same encrypted data used in multiple Regions | Multi-Region KMS key | Related keys with same key material across Regions |
| Dedicated FIPS-validated HSMs managed by customer | AWS CloudHSM | Customer controls HSM users, keys, clustering |
| KMS key material backed by CloudHSM | KMS custom key store | KMS API with CloudHSM-backed key material |
| Key material controlled outside AWS | External key store | KMS integrates with external key manager |
| Temporary delegated KMS access | KMS grant | Common for AWS services using a key on your behalf |
| Audit key usage | CloudTrail KMS events | KMS API activity appears in CloudTrail |
KMS Policy and Access Model
| Component | What it does | Exam note |
|---|
| Key policy | Primary authorization document for a KMS key | A key policy must allow the principal or allow IAM policies to be used |
| IAM policy | Grants caller permission to use KMS APIs | Not enough if key policy does not permit it |
| Grant | Delegated, often temporary permission to use a key | Used heavily by integrated AWS services |
| Encryption context | Non-secret authenticated metadata | Must match on decrypt when required |
| Key rotation | Rotates key material for supported KMS keys | Does not re-encrypt old data immediately |
| Key deletion | Scheduled destructive action | Usually a distractor if recovery is needed |
Envelope Encryption
| Term | Meaning |
|---|
| Data key | Symmetric key used to encrypt actual data |
| Encrypted data key | Data key encrypted by a KMS key |
| KMS key | Key encryption key used to protect data keys |
| Envelope encryption | Encrypt data locally with data key; protect data key with KMS |
High-yield point: KMS commonly does not encrypt large payloads directly. AWS services request data keys, encrypt data locally, and store the encrypted data key with the ciphertext.
S3 Encryption Choices
| Requirement | Choose | Notes |
|---|
| Simple server-side encryption with Amazon-managed keys | SSE-S3 | Low overhead |
| Server-side encryption with KMS audit and control | SSE-KMS | Key policy, CloudTrail KMS events, grants |
| Additional dual-layer server-side encryption | DSSE-KMS | Use when scenario requires two independent encryption layers |
| Customer provides key material per request | SSE-C | AWS does not store the key; operationally heavy |
| Encrypt before uploading to S3 | Client-side encryption | App controls encryption before AWS receives data |
| Prevent unencrypted uploads | Bucket policy condition on encryption headers | Use explicit deny |
| Prevent public buckets/account-wide | S3 Block Public Access | Account and bucket-level protection |
| Immutable retention protection | S3 Object Lock | Requires versioning; governance/compliance retention concepts |
KMS Key Policy Pattern
Use kms:ViaService when the key should be used only through a specific AWS service.
{
"Sid": "AllowAppRoleUseThroughS3",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/AppRole"
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:GenerateDataKey"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:ViaService": "s3.us-east-1.amazonaws.com"
}
}
}
Data Protection and Secrets
S3 Security Controls
| Requirement | Control |
|---|
| Block accidental public access | S3 Block Public Access |
| Disable ACL-based ownership surprises | S3 Object Ownership, bucket owner enforced |
| Cross-account controlled access | Bucket policy with explicit principals and conditions |
| Access S3 privately from VPC | Gateway endpoint for S3, plus bucket/endpoint policies |
| Separate access patterns by app/team | S3 Access Points |
| Audit object-level API activity | CloudTrail data events for S3 |
| Detect sensitive data | Amazon Macie |
| Restrict access to organization only | aws:PrincipalOrgID in resource policy |
| Require TLS | Deny when aws:SecureTransport is false |
| Require SSE-KMS | Deny PutObject without expected encryption header |
| Protect from deletion/ransomware | Versioning, Object Lock, AWS Backup where applicable |
S3 Bucket Policy Snippets
Require HTTPS:
{
"Sid": "DenyInsecureTransport",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::example-bucket",
"arn:aws:s3:::example-bucket/*"
],
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
}
Require SSE-KMS on object upload:
{
"Sid": "DenyUploadsWithoutSSEKMS",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::example-bucket/*",
"Condition": {
"StringNotEquals": {
"s3:x-amz-server-side-encryption": "aws:kms"
}
}
}
Restrict bucket access to a VPC endpoint:
{
"Sid": "DenyAccessOutsideExpectedEndpoint",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::example-bucket",
"arn:aws:s3:::example-bucket/*"
],
"Condition": {
"StringNotEquals": {
"aws:SourceVpce": "vpce-0123456789abcdef0"
}
}
}
Secrets and Parameter Storage
| Requirement | Choose | Why |
|---|
| Rotate database credentials automatically | AWS Secrets Manager | Native rotation patterns and Lambda rotation |
| Store application config hierarchy | AWS Systems Manager Parameter Store | Good for parameters and SecureString values |
| Store encrypted secret with KMS | Secrets Manager or Parameter Store SecureString | KMS protects secret material |
| Retrieve secrets in ECS/EKS/Lambda | Service integration with IAM role | Avoid hardcoded secrets |
| Audit secret access | CloudTrail | Monitor GetSecretValue and related APIs |
| Cache secrets in application | Secrets Manager caching client/pattern | Reduces repeated calls and latency |
Network and Infrastructure Security
Control Selection Matrix
| Control | Layer/scope | Allows deny rules? | Stateful? | Use for |
|---|
| Security group | ENI/instance | No, allow only | Yes | Workload-level inbound/outbound access |
| Network ACL | Subnet | Yes | No | Coarse subnet stateless filtering |
| AWS WAF | HTTP/HTTPS layer 7 | Yes | N/A | SQL injection, XSS, HTTP rate limits, managed web rules |
| AWS Shield Standard | Edge DDoS protection | Managed | N/A | Baseline DDoS protection |
| AWS Shield Advanced | Enhanced DDoS features | Managed | N/A | Advanced detection, response, cost protection features |
| AWS Network Firewall | VPC network traffic | Yes | Stateful and stateless rules | Central inspection, egress filtering, domain/IP rules |
| Route 53 Resolver DNS Firewall | DNS queries | Yes | N/A | Block malicious or unauthorized domains |
| Gateway Load Balancer | Appliance insertion | Appliance-dependent | Appliance-dependent | Third-party firewall/IDS/IPS appliances |
| VPC endpoint policy | Endpoint access | Yes | N/A | Restrict AWS service access through endpoint |
| AWS PrivateLink | Private service connectivity | Policy/SG dependent | N/A | Private access to services without public IP routing |
Security Group vs NACL
| Feature | Security group | Network ACL |
|---|
| Attachment | ENI | Subnet |
| Rule type | Allow only | Allow and deny |
| Evaluation | All rules | Ordered by rule number |
| State | Stateful | Stateless |
| Return traffic | Automatically allowed | Must be explicitly allowed |
| Best use | Instance/app access control | Subnet guardrail, explicit deny, broad filtering |
| Common trap | Cannot create deny rule | Ephemeral ports must be handled |
VPC Endpoint Choices
| Need | Choose | Notes |
|---|
| Private access to S3 or DynamoDB | Gateway endpoint | Route table target plus endpoint policy |
| Private access to most AWS APIs | Interface endpoint | Elastic network interfaces with private IPs |
| Expose your service privately to consumers | AWS PrivateLink endpoint service | Usually fronted by Network Load Balancer |
| Restrict service access from VPC | Endpoint policy + resource policy | Use both sides where supported |
| Keep traffic off public internet | VPC endpoint | Does not automatically mean broad access is safe |
Common Network Architectures
| Scenario | Pattern | Watch for |
|---|
| Centralized egress inspection | Transit Gateway to inspection VPC with AWS Network Firewall or appliances | Symmetric routing and route table design |
| Centralized ingress to web apps | CloudFront + AWS WAF + ALB | WAF is HTTP-aware; SGs still protect ALB |
| Private application access | Internal ALB/NLB, PrivateLink, VPN, or Direct Connect | Match connectivity to consumer type |
| Hybrid encrypted connectivity | Site-to-Site VPN | Direct Connect is dedicated connectivity; use VPN when IPsec encryption is required |
| DNS filtering | Route 53 Resolver DNS Firewall | Blocks DNS lookups, not direct IP connections |
| Detect VPC traffic patterns | VPC Flow Logs | Metadata only, not packet payload |
| Inspect packets/application protocols | Network Firewall or appliance | Flow Logs are not inspection tools |
Logging, Monitoring, and Detection
Logging Source Selection
| Question asks for… | Choose | Key detail |
|---|
| API calls, identity, source IP, time | AWS CloudTrail | Management events are baseline audit trail |
| S3 object-level or Lambda invoke activity | CloudTrail data events | Must be selected for high-volume data-plane activity |
| Unusual API activity patterns | CloudTrail Insights | Detects unusual management API activity |
| Long-term queryable audit lake | CloudTrail Lake | SQL-style event analysis |
| Resource configuration history | AWS Config | Records configuration changes |
| Compliance against rules | AWS Config rules / conformance packs | Managed or custom rules |
| Logs, metrics, alarms | Amazon CloudWatch | Operational observability |
| Event-driven automation | Amazon EventBridge | Routes service events/findings |
| Network metadata | VPC Flow Logs | Accept/reject, addresses, ports, bytes; not payload |
| Load balancer request records | ELB access logs | Client/request visibility |
| DNS query logging | Route 53 Resolver query logs | DNS activity in VPC |
| Firewall alerts/flows | AWS Network Firewall logs | Send to supported log destinations |
Detection Service Selection
| Service | Detects / analyzes | Does not primarily do |
|---|
| Amazon GuardDuty | Threat findings from AWS telemetry | Block traffic by itself |
| AWS Security Hub | Aggregated findings and security standards | Deep investigation by itself |
| Amazon Detective | Investigation graph and related activity | Preventive enforcement |
| Amazon Inspector | Vulnerabilities in EC2, ECR images, Lambda | Network intrusion detection |
| Amazon Macie | Sensitive data and S3 exposure | General malware detection |
| IAM Access Analyzer | External access, unused access, policy validation | Runtime threat detection |
| AWS Config | Configuration drift and rule compliance | API forensic detail |
| AWS Trusted Advisor | Account best-practice checks | Central incident investigation |
| AWS Audit Manager | Evidence collection for audits | Real-time threat blocking |
CloudTrail High-Yield Points
| Point | Exam use |
|---|
| Organization trail | Centralize CloudTrail across AWS Organizations |
| Log file validation | Detect tampering with delivered log files |
| S3 log bucket protection | Use bucket policy, encryption, versioning, restricted write access |
| CloudWatch Logs integration | Near-real-time alarms and metric filters |
| EventBridge integration | Trigger automated response from API events |
| Data events | Required for S3 object-level visibility and similar data-plane activity |
| Insights events | Useful for unusual API volume/error patterns |
| CloudTrail is regional/global-aware | Configure to capture required Region and global service events |
Incident Response Playbooks
Compromised IAM Access Key
| Step | Action |
|---|
| 1 | Identify key owner and activity in CloudTrail |
| 2 | Deactivate or delete the access key |
| 3 | Rotate credentials and remove hardcoded secrets |
| 4 | Review IAM policies, group membership, role assumptions, and recent changes |
| 5 | Check GuardDuty, Security Hub, CloudTrail, and affected services |
| 6 | Add preventive controls: MFA, least privilege, SCPs, access analyzer, key age monitoring |
Compromised EC2 Instance
| Goal | Preferred action |
|---|
| Preserve evidence | Snapshot EBS volumes before destructive cleanup |
| Isolate network | Replace security group with quarantine SG or adjust NACL/route controls |
| Keep investigation access | Use SSM Session Manager if available; avoid opening SSH broadly |
| Capture volatile data | Collect memory/process/network data before stop/terminate if required |
| Identify root cause | Review CloudTrail, VPC Flow Logs, instance logs, Inspector findings |
| Rebuild safely | Launch from known-good AMI; patch; rotate instance role credentials if needed |
| Automate containment | EventBridge rule on GuardDuty finding invoking Lambda/SSM Automation |
Suspicious S3 Public Exposure
| Step | Action |
|---|
| 1 | Enable or verify S3 Block Public Access at account/bucket level |
| 2 | Review bucket policy, access points, ACLs, and Object Ownership |
| 3 | Use IAM Access Analyzer for public/cross-account findings |
| 4 | Review CloudTrail data events if enabled; enable for future object access audit |
| 5 | Use Macie if sensitive data exposure is possible |
| 6 | Add Config rules/SCPs to prevent recurrence |
Ransomware or Destructive Deletion Risk
| Requirement | Control |
|---|
| Recover previous objects | S3 Versioning |
| Prevent deletion/overwrite during retention | S3 Object Lock |
| Centralized backup/recovery | AWS Backup |
| Detect mass delete API calls | CloudTrail + EventBridge/CloudWatch alarms |
| Limit destructive permissions | IAM least privilege, permissions boundaries, SCPs |
| Separate backup account | Multi-account backup isolation pattern |
Governance and Multi-Account Security
Organizations and Account Controls
| Requirement | Choose | Notes |
|---|
| Group accounts by environment/business unit | OUs | Attach SCPs at OU level |
| Prevent risky APIs across accounts | SCP | Deny guardrails are common exam answers |
| Centralize security service administration | Delegated administrator | Used by services such as GuardDuty, Security Hub, Inspector, Macie |
| Standard account vending/baselines | AWS Control Tower | Landing zone and guardrails |
| Share resources across accounts | AWS RAM | For supported resource types |
| Centralize logs | Log archive account pattern | Protect log buckets from modification |
| Centralize security operations | Security tooling account pattern | Aggregate findings and automate response |
SCP Patterns
| Goal | SCP approach | Caution |
|---|
| Deny disabling CloudTrail/Config/GuardDuty | Explicit deny for stop/delete/disable APIs | Ensure break-glass/admin process is designed |
| Restrict Regions | Deny actions outside approved Regions using aws:RequestedRegion | Exclude global services as needed |
| Prevent public S3 changes | Deny APIs that remove block public access or set public policies | Test carefully |
| Enforce approved instance types | Deny EC2 run APIs outside allowed types | Service-specific conditions required |
| Protect security roles | Deny IAM changes to named roles/policies | Avoid locking out operations accidentally |
High-yield trap: an SCP attached to an OU can make an administrator appear “broken” even when IAM policies allow the action. Check SCPs when an allowed IAM principal still receives AccessDenied.
Application and Compute Security
EC2
| Requirement | Choose |
|---|
| Avoid SSH keys and open inbound ports | AWS Systems Manager Session Manager |
| Grant app AWS permissions | Instance profile with IAM role |
| Reduce credential exposure | IMDSv2 |
| Patch management | Systems Manager Patch Manager |
| Vulnerability findings | Amazon Inspector |
| Encrypt boot/data volumes | EBS encryption with KMS |
| Restrict metadata access from apps | IMDSv2 hop limit/configuration and local controls |
Lambda
| Requirement | Choose |
|---|
| Function permissions to AWS services | Execution role |
| Allow another AWS service/account to invoke function | Lambda resource-based policy |
| Protect environment variables | KMS encryption and least-privilege access |
| Private VPC resource access | Lambda VPC configuration |
| Control deployment trust | Code signing for Lambda |
| Detect vulnerable dependencies | Amazon Inspector for Lambda where applicable |
| Trigger remediation | EventBridge rule invoking Lambda |
Containers
| Requirement | ECS | EKS |
|---|
| Workload AWS permissions | Task role | IRSA / pod identity pattern |
| Node/host permissions | Container instance role | Node instance role |
| Image vulnerability scanning | Amazon Inspector / ECR scanning | Amazon Inspector / ECR scanning |
| Secrets injection | Secrets Manager / Parameter Store | Secrets Manager/Parameter Store via integration or CSI pattern |
| Network isolation | Security groups, VPC design | Security groups for pods where used, Kubernetes network policies |
| Audit/control plane | ECS events/CloudTrail | EKS control plane logs, CloudTrail, Kubernetes RBAC |
Confused Deputy and Cross-Service Access
Confused Deputy Pattern
Use both source ARN and source account when allowing an AWS service principal to access your resource.
{
"Sid": "AllowEventBridgeFromExpectedRule",
"Effect": "Allow",
"Principal": {
"Service": "events.amazonaws.com"
},
"Action": "sns:Publish",
"Resource": "arn:aws:sns:us-east-1:111122223333:security-topic",
"Condition": {
"ArnEquals": {
"aws:SourceArn": "arn:aws:events:us-east-1:111122223333:rule/security-rule"
},
"StringEquals": {
"aws:SourceAccount": "111122223333"
}
}
}
Cross-Account Access Checklist
| Check | Why it matters |
|---|
| Principal account IAM allows the action | Caller must be authorized to request the API |
| Resource account policy trusts the principal | Resource must allow external access |
| KMS key policy allows use | Encrypted resources often fail here |
| SCPs permit the action in both accounts | Guardrails can block otherwise valid access |
| Conditions match request context | Source VPC endpoint, Org ID, MFA, tags, Region |
| Resource ownership is understood | S3 ownership/ACL settings can change access behavior |
| Logs are centralized | Cross-account activity should be auditable |
Common SCS-C03 Traps
| Trap | Correct reasoning |
|---|
| “SCP allows the action” | SCPs never grant permissions; they only set maximum permissions |
| “GuardDuty blocks the attack” | GuardDuty detects and creates findings; use EventBridge/remediation to act |
| “Security group deny rule” | Security groups are allow-only; use NACL, Network Firewall, or policy denies |
| “NACL return traffic is automatic” | NACLs are stateless; configure inbound and outbound rules |
| “CloudTrail shows packet payloads” | CloudTrail shows API activity, not network packet contents |
| “VPC Flow Logs show full packets” | Flow Logs show metadata, not payload |
| “KMS IAM policy alone is always enough” | Key policy must permit access or delegate to IAM |
| “Bucket policy controls KMS decrypt” | KMS key policy/IAM must also allow KMS use |
| “Public subnet means public access” | Needs route to internet gateway and public IP/relevant routing |
| “PrivateLink replaces IAM” | Private connectivity does not remove authorization requirements |
| “WAF protects all TCP traffic” | AWS WAF protects supported HTTP/HTTPS integrations |
| “Inspector detects active intrusions” | Inspector finds vulnerabilities; GuardDuty detects threats |
| “Macie scans all AWS data stores” | Macie is focused on S3 sensitive data discovery |
| “Secrets Manager and Parameter Store are identical” | Secrets Manager emphasizes secret rotation and lifecycle |
| “Config is a log search tool” | Config tracks resource configuration and compliance |
| “Stopping an instance preserves all evidence” | Volatile memory/process data can be lost |
| “Deleting a compromised key is the first forensic step” | Usually deactivate quickly, preserve audit trail, then rotate/delete as appropriate |
Fast Review Checklist
Before exam day, be able to answer these without hesitation:
- Which policy type grants access, and which only limits access?
- When does a cross-account request need both identity-side and resource-side permission?
- Why does KMS require key policy analysis in addition to IAM?
- Which service detects API activity, config drift, vulnerabilities, sensitive S3 data, and threats?
- When do you choose WAF, Network Firewall, security groups, NACLs, or DNS Firewall?
- How do you enforce private S3 access through a VPC endpoint?
- How do you prevent service confused deputy risk?
- What is the safe sequence for compromised IAM keys and EC2 instances?
- Which service centralizes findings, and which service investigates them?
- Which controls are preventive, detective, and responsive in a multi-account AWS environment?
Next Step
Use this Quick Reference as a decision checklist while practicing mixed AWS Certified Security – Specialty (SCS-C03) scenarios. For each missed question, classify the miss as IAM/policy evaluation, KMS/encryption, logging/detection, network control selection, governance, or incident response, then revisit the matching table above before continuing with more original practice questions.