Domain 1: Detection
- Amazon GuardDuty is an agentless service that uses machine learning and AWS threat intelligence to analyze CloudTrail management events, VPC Flow Logs, and Route 53 DNS query logs for malicious activity such as credential exfiltration and crypto-mining.
- GuardDuty protection plans (S3 Protection, EKS Protection, RDS Protection, Lambda Protection, and Malware Protection for EC2) are enabled independently; EC2 Malware Protection is NOT turned on automatically with the others and must be explicitly enabled.
- GuardDuty Malware Protection performs agentless scans of EBS volume snapshots (it creates a snapshot copy) to detect malware without installing an agent on the instance.
- Designate a delegated administrator in AWS Organizations and enable GuardDuty auto-enable so new member accounts are protected automatically; aws guardduty create-detector --enable turns it on and returns a detector ID.
- While a GuardDuty detector is suspended it stops monitoring data sources and generates no new findings, but existing findings and configuration settings are retained.
- Upload your own list of known-malicious IPs with aws guardduty create-threat-intel-set so GuardDuty raises findings on matching traffic; trusted IP lists suppress findings instead.
- AWS Security Hub centrally aggregates and normalizes findings from GuardDuty, Inspector, Macie, IAM Access Analyzer, and third-party tools using the AWS Security Finding Format (ASFF), and runs automated standards checks such as the CIS AWS Foundations Benchmark.
- Amazon Detective builds a behavioral graph from CloudTrail, VPC Flow Logs, and GuardDuty findings to support interactive root-cause investigation and scope analysis over time.
- Amazon Security Lake is the purpose-built service for a centralized security data lake; it normalizes data into the Open Cybersecurity Schema Framework (OCSF) and stores it in your S3.
- A spike in 403 (AccessDenied) errors from a single identity in CloudTrail can indicate credential misuse or unauthorized access probing and is a common detection signal.
- AWS CloudTrail records account-wide API calls (caller identity, source IP, timestamp, parameters, response); management events are logged by default while S3/Lambda/DynamoDB data events must be explicitly enabled and incur extra cost.
- Create an organization trail (multi-region) delivering to an S3 bucket in a dedicated log-archive account with S3 Object Lock; this enforces separation of duties and tamper resistance because source-account admins cannot modify the logs.
- Enable CloudTrail log file integrity validation to produce hourly digest files using SHA-256 hashing and digital signatures, letting you detect any post-delivery modification or deletion of log files.
- aws cloudtrail create-trail with --is-multi-region-trail creates a trail covering all regions; global service events (IAM, STS, CloudFront) are recorded via the global-events setting and only need one trail to capture them.
- Enable S3 object-level (data event) logging with aws cloudtrail put-event-selectors using a DataResources AWS::S3::Object entry.
- VPC Flow Logs capture IP traffic metadata (source/destination IP and port, protocol, packet/byte counts, ACCEPT or REJECT) for ENIs, subnets, or VPCs; they do NOT capture packet payloads.
- Create Flow Logs with aws ec2 create-flow-logs specifying --resource-type, --resource-ids, --traffic-type (ALL, ACCEPT, or REJECT), a destination (CloudWatch Logs group or S3), and --deliver-logs-permission-arn for the publishing IAM role.
- Amazon Athena queries CloudTrail logs and VPC Flow Logs stored in S3 using standard SQL with a serverless, pay-per-query model; you define a table schema over the S3 prefix without loading data.
- Detect root-account usage by creating a CloudWatch Logs metric filter (aws logs put-metric-filter) matching userIdentity.type = Root, attaching a CloudWatch alarm, and notifying an SNS topic.
- Route 53 Resolver query logging captures DNS queries made by instances inside a VPC, useful for detecting data exfiltration or command-and-control domains.
- Enable S3 server access logging with aws s3api put-bucket-logging (BucketLoggingStatus body); it provides detailed request-level records, complementary to CloudTrail S3 data events.
- Cost-effective log retention tiering: keep hot/searchable logs (e.g. 30 days) in Amazon OpenSearch Service and archive older logs in S3 queried on demand with Athena.
Domain 2: Incident Response
- Automated incident response pattern: an EventBridge rule matches a GuardDuty finding and invokes a Lambda function or SSM Automation runbook to isolate the instance (restrictive security group / quarantine subnet) and revoke or rotate stolen credentials.
- Forensic order of operations: capture a memory dump from the live instance and snapshot the EBS volumes BEFORE stopping or terminating, then attach volume copies to an isolated forensic workstation in a separate account.
- Filter automated responses to high-severity events by matching the finding's detail.severity field in the EventBridge rule's event pattern, avoiding noisy reactions to low-severity findings.
- Isolate a compromised instance with aws ec2 modify-instance-attribute --instance-id i-1 --groups sg-quarantine, applying a security group that denies all traffic so existing connections cannot exfiltrate data.
- Preserve evidence before it can be altered: keep CloudTrail delivery in a dedicated log-archive account with S3 Object Lock and versioning, so the record of what happened survives an attacker who reaches the workload account.
- Respond to an exposed access key by deactivating rather than deleting it first (aws iam update-access-key --status Inactive), which stops its use while leaving it available for investigation, then create a replacement and delete the original once nothing depends on it.
- Revoke in-flight temporary credentials for a role by attaching an inline deny policy with an aws:TokenIssueTime condition; STS sessions cannot be individually cancelled, so a time-based deny is what invalidates sessions already issued.
- Work the phases in order - containment, eradication, then recovery - and do not restore from a snapshot taken after the compromise began. Establishing the earliest evidence of access is what tells you which backups are trustworthy.
- Amazon Detective is the root-cause tool rather than the alerting tool: it builds a behavioural graph over CloudTrail, VPC Flow Logs and GuardDuty findings so an investigator can follow an identity or an instance across time rather than reading raw logs.
- Automate the repeatable parts with SSM Automation runbooks invoked from EventBridge, and keep a human decision point before destructive steps. Automatic isolation of a production instance is a judgement call, not a default.
- A compromised EC2 instance is isolated by replacing its security groups with one that denies all traffic while leaving the instance running, so volatile evidence in memory survives. Terminating it destroys exactly what the investigation needs.
- After the incident, feed the finding back into prevention: a Config rule or SCP that would have blocked the root cause, and a detection that would have caught it sooner. An incident that changes nothing will recur.
Domain 3: Infrastructure Security
- Security groups are stateful and operate at the instance/ENI level (return traffic is automatically allowed); network ACLs are stateless at the subnet level and require explicit inbound AND outbound rules, evaluated by rule number in order.
- Reference a security group as the source in another security group's rule for tiered designs - e.g. set the web tier's SG ID as the inbound source on the app tier SG so only web instances can reach the app tier.
- Add an inbound HTTPS rule with aws ec2 authorize-security-group-ingress --protocol tcp --port 443 --cidr <range>; security groups support only allow rules, while NACLs support both allow and deny.
- AWS WAF inspects HTTP/S requests and protects CloudFront, Application Load Balancers, API Gateway, and AppSync against SQL injection, XSS, and OWASP Top 10 threats; attach a web ACL with aws wafv2 associate-web-acl using the resource ARN.
- AWS Shield Standard is free and automatic for layer 3/4 DDoS protection; Shield Advanced is a paid tier adding enhanced detection, 24/7 Shield Response Team (SRT) access, and DDoS cost protection for scaling charges.
- Gateway VPC endpoints (S3 and DynamoDB only) add a route-table entry at no cost; Interface endpoints (AWS PrivateLink) provision ENIs with private IPs for most other services and incur hourly and data charges.
- Create a PrivateLink Interface endpoint for a service with aws ec2 create-vpc-endpoint --vpc-endpoint-type Interface and the SSM service name; create an S3 Gateway endpoint and add it to the private subnets' route tables for private S3 access.
- AWS Network Firewall provides stateful packet inspection and Suricata-compatible IPS rules; block a domain with aws network-firewall create-rule-group using a STATEFUL rule group with a DENYLIST RulesSourceList.
- Centralized inspection architecture: route inter-VPC (east-west) and egress traffic through a Transit Gateway to a dedicated inspection VPC running AWS Network Firewall endpoints, which scales inspection across many VPCs.
- Use AWS Systems Manager Session Manager (with the SSM Agent and least-privilege IAM) for secure shell access with no inbound SSH port, no bastion host, and full session logging to CloudWatch/S3.
- Add a NACL deny rule with aws ec2 create-network-acl-entry specifying --rule-number, --protocol, --port-range, --cidr-block, --rule-action deny, and --ingress; lower rule numbers are evaluated first.
- AWS PrivateLink lets SaaS providers expose a VPC endpoint service backed by a Network Load Balancer so consumers connect privately without VPC peering or internet exposure.
- Place application instances in private subnets and expose only a load balancer publicly; restrict security groups to the minimum required ports and source ranges (least privilege networking).
- AWS Firewall Manager centrally deploys and enforces WAF rules, Shield Advanced protections, security group policies, and Network Firewall rules across all accounts in an Organization.
Domain 4: Identity and Access Management
- IAM policy evaluation: an explicit Deny in ANY policy (identity-based, resource-based, SCP, permissions boundary, or session policy) always overrides any Allow; otherwise the request is denied by default unless explicitly allowed.
- Service Control Policies (SCPs) are guardrails that set the maximum permissions for member accounts but grant nothing on their own - an action is allowed only if BOTH the SCP and the identity-based policy permit it (the intersection).
- SCPs do not affect the Organizations management account; to constrain workloads with SCPs, run those workloads in member accounts placed in OUs.
- Permissions boundaries cap the maximum permissions an IAM user or role can have; set one with aws iam put-user-permissions-boundary, and use them to let admins delegate role creation safely without privilege escalation.
- AWS IAM Identity Center (successor to AWS SSO) provides centralized workforce SSO across accounts and apps, integrates with external IdPs via SAML 2.0/SCIM, and supports permission sets plus attribute-based access control (ABAC) using session tags.
- OIDC/SAML federation issues short-lived STS credentials via AssumeRoleWithWebIdentity or AssumeRoleWithSAML, eliminating long-lived access keys; GitHub Actions and similar CI use OIDC to assume roles.
- Retrieve temporary cross-account credentials with aws sts assume-role specifying the role ARN and a session name; the target role's trust policy must permit the calling principal.
- For cross-account S3 access, the bucket policy in Account B grants a specific IAM role/principal in Account A, and Account A's identity policy must also allow the S3 actions.
- Add an sts:ExternalId condition to a role's trust policy to prevent the confused-deputy problem when granting a third party access to your account.
- Secure the root user: enable MFA, do not create root access keys, lock the credentials away, and use least-privilege IAM roles/users for daily operations; root cannot be restricted by IAM policies or SCPs.
- Use IAM Roles for Service Accounts (IRSA) on Amazon EKS via an OIDC provider to grant per-pod, scoped IAM permissions instead of node-wide instance roles.
- Test access decisions before deployment with aws iam simulate-principal-policy to confirm whether a principal is allowed or denied a specific action.
- Enforce conditions in policies such as "aws:SourceIp" with IpAddress to restrict by network, or a Deny when s3:x-amz-server-side-encryption-aws-kms-key-id does not match a required KMS key ARN to mandate specific encryption.
- Prefer IAM roles for workloads and cross-account access over embedded long-lived keys; grant least privilege and rely on temporary STS credentials wherever possible.
Domain 5: Data Protection
- AWS KMS creates and manages encryption keys and integrates natively with S3 (SSE-KMS), EBS, RDS, Secrets Manager, and more; it enforces key policies and logs every Decrypt/Encrypt call to CloudTrail for auditing.
- A KMS key policy is the primary access control for a key; it must include a statement enabling IAM policies (granting the account root principal kms:*) before IAM identity policies can delegate access to the key.
- Enable automatic annual rotation of AWS managed/customer managed symmetric keys with aws kms enable-key-rotation --key-id <id>; KMS retains old key material so all previously encrypted data stays transparently decryptable.
- Use a KMS multi-Region key with replicas in each region (same key ID) so encryption/decryption happens in-region for low latency and cross-region portability of ciphertext.
- Grant temporary, scoped key permissions to a principal with aws kms create-grant specifying the grantee principal and allowed operations (e.g. Decrypt, Encrypt), useful for AWS services acting on your behalf.
- SSE-S3 uses AES-256 keys managed entirely by S3 with no customer control or audit trail; SSE-KMS uses KMS keys giving per-key policies, auditable Decrypt calls, and optional customer-managed keys.
- Set default bucket encryption with aws s3api put-bucket-encryption using a Rule that applies aws:kms and a KMSMasterKeyID so all new objects are encrypted automatically.
- Block public access at the account level with aws s3control put-public-access-block (all four settings true) and combine with least-privilege bucket and IAM policies to prevent accidental exposure.
- S3 Object Lock provides WORM protection in two modes: Compliance mode (absolute, cannot be removed even by root) and Governance mode (can be bypassed by privileged users); versioning must be enabled first.
- Apply a per-object retention lock with aws s3api put-object-retention using Mode=COMPLIANCE and a RetainUntilDate; for example, a 7-year retention period with versioning satisfies many regulatory requirements.
- Amazon Macie uses machine learning and pattern matching to discover and classify sensitive data (PII, financial data, credentials) across S3 buckets and reports findings to Security Hub.
- AWS Secrets Manager stores secrets encrypted with KMS and supports managed automatic rotation (built-in rotation for RDS and other databases); create one with aws secretsmanager create-secret.
- Protect data in transit by enforcing TLS/HTTPS for client connections and using VPN or Direct Connect with encryption for hybrid links; disabling certificate validation or using plain HTTP removes protection.
- Cryptographic erasure: scheduling deletion of (or disabling) the KMS key renders all data encrypted under it permanently unrecoverable, which is the fastest way to make large datasets inaccessible; use envelope encryption with the AWS Encryption SDK and data key caching for high-volume client-side encryption.
Domain 6: Security Foundations and Governance
- Service Control Policies (SCPs) enforce preventive guardrails across an Organization; attach one with aws organizations attach-policy --policy-id <id> --target-id <ou-or-account>.
- Protect logging integrity org-wide with an SCP that denies cloudtrail:StopLogging, cloudtrail:DeleteTrail, and organizations:LeaveOrganization for member-account principals.
- Restrict resource creation with an SCP, for example denying ec2:RunInstances unless the requested instance type matches an approved allow-list condition.
- AWS Config records resource configuration changes; start recording with aws configservice start-configuration-recorder, and reduce cost/noise by recording only specific in-scope resource types instead of all supported types.
- AWS Config managed rules (e.g. s3-bucket-public-read-prohibited) detect non-compliant resources; attach SSM Automation remediation with aws configservice put-remediation-configurations to auto-fix violations.
- If Config auto-remediation does not run, common causes are the automation assume role lacking permissions or the remediation being configured as manual rather than automatic.
- Deploy Config rules and remediations across an entire Organization using conformance packs, and aggregate compliance status centrally with a Config aggregator.
- AWS Control Tower sets up a multi-account landing zone with Account Factory and applies preventive (SCP-based) and detective (Config-based) guardrails to enrolled accounts to enforce a security baseline.
- AWS CloudFormation StackSets deploy and update stacks across multiple accounts and regions with drift detection, ideal for rolling out a standardized security baseline.
- AWS Security Hub aggregates findings across the Organization via a delegated administrator account and continuously runs security standards (CIS, AWS Foundational Security Best Practices, PCI DSS).
- Amazon Inspector continuously scans EC2, ECR container images, and Lambda for software vulnerabilities (CVEs) and network reachability; query results with aws inspector2 list-findings filtered by severity.
- IAM Access Analyzer identifies resources (S3 buckets, roles, KMS keys, etc.) shared with external principals and integrates its findings into Security Hub.
- Use AWS Firewall Manager to centrally deploy and manage WAF rules, Shield Advanced, and Network Firewall policies across all accounts, ensuring consistent protection on existing and new resources.
- Enforce a baseline on account provisioning by using Control Tower Account Factory with both detective and preventive guardrails rather than relying on manual post-creation configuration.
AWS SCS-C03 exam tips
- Read every scenario for the qualifier - 'most secure', 'most cost-effective', 'least operational overhead', or 'least privilege' - because several answers will be technically valid and only one fits the stated priority.
- Default to managed and automated solutions (GuardDuty, Security Hub, Config remediation, Session Manager, Secrets Manager rotation) over custom scripts or self-managed instances when the question stresses low operational overhead.
- Memorize IAM evaluation logic cold: explicit Deny always wins, SCPs only cap permissions and never grant, and the effective permission is the intersection of SCP, identity policy, permissions boundary, and resource policy.
- Know the multi-account governance stack and when to use each: SCPs for prevention, Config rules for detection/remediation, Control Tower for the landing zone baseline, StackSets for deployment, Security Hub for aggregation, and Firewall Manager for network protections.
- Watch for forensic sequencing in incident-response questions: always preserve evidence (memory dump, EBS snapshot) and isolate before terminating, and route GuardDuty findings through EventBridge to Lambda or SSM Automation for containment.
- C03 separates Detection from Incident Response, and the split is by task rather than by service. GuardDuty, Security Hub, Detective, Security Lake and the logging stack sit in Detection; containment, evidence handling, credential revocation and recovery sit in Incident Response.
Study guide FAQ
How long is the SCS-C03 exam and what score do I need to pass?
The exam is 170 minutes and contains 65 questions. Only 50 of those are scored - the other 15 are unscored trial questions that AWS does not identify, so answer every question. Scores are scaled from 100 to 1,000 and 750 passes. Scoring is compensatory, so you need the overall score rather than a pass in each domain.
What is the difference between GuardDuty, Inspector, Macie, and Security Hub?
GuardDuty detects active threats and malicious behavior from CloudTrail, VPC Flow Logs, and DNS logs. Inspector scans EC2, containers, and Lambda for software vulnerabilities. Macie discovers and classifies sensitive data in S3. Security Hub aggregates and normalizes findings from all of these (plus third parties) and runs compliance standards checks.
When should I use an SCP versus an IAM policy versus a permissions boundary?
SCPs are Organization-level guardrails that set the maximum permissions for member accounts but grant nothing themselves. IAM identity policies actually grant permissions to users and roles. Permissions boundaries cap what a specific user or role can be granted, which is ideal for safely delegating role creation. The effective access is the intersection of all of them, and any explicit Deny overrides everything.
How much hands-on AWS experience does the exam assume?
AWS recommends five years of IT security experience designing and implementing security solutions, plus two or more years of hands-on experience securing AWS workloads, with knowledge spanning the shared responsibility model, identity at scale, multi-account governance, incident response, vulnerability management, layer 3-7 firewall rules, logging strategies, encryption at rest and in transit, and disaster recovery controls. The exam is heavily scenario-based and often turns on exact service behaviour, so reading alone is rarely enough.
What changed between SCS-C02 and SCS-C03?
The biggest structural change is that the combined threat-detection-and-incident-response domain was split in two, and the separate logging and monitoring domain was folded into Detection. The current six domains are Detection 16%, Incident Response 14%, Infrastructure Security 18%, Identity and Access Management 20%, Data Protection 18%, and Security Foundations and Governance 14%.
Official exam sources
The domain names and weightings on this page follow the published exam blueprint. Each source below records what it confirmed and when it was read, so the split can be checked rather than taken on trust.
- AWS Certified Security - Specialty (SCS-C03) exam pagelink and content verified 8 September 2026Exam code SCS-C03. Recommended experience: five years of IT security experience designing and implementing security solutions, and two or more years of hands-on experience securing AWS workloads. Domain weightings are in the downloadable exam guide, not on this page.