AWS Certified Security Specialty
Last reviewed: May 2026
A scannable reference of architectural patterns the SCS-C03 exam tests. Read top-to-bottom, or jump to a section.
A potentially compromised EC2 instance in an Auto Scaling group requires investigation with minimal disruption.
Deregister from ELB target group, remove from Auto Scaling group, and apply a restrictive "forensic" security group that denies all traffic except for forensic workstation access.
Why: This isolates the instance from the network while preserving its volatile state (memory, running processes) for forensic analysis. Terminating immediately destroys evidence.
Automate a multi-step incident response workflow (e.g., snapshot, isolate, notify) triggered by a GuardDuty finding.
Use an EventBridge rule to capture the specific finding and trigger an AWS Step Functions state machine. The state machine orchestrates the sequence of actions with error handling and retry logic.
Why: Step Functions provide robust orchestration for multi-step workflows, ensuring reliability and state management, which is superior to a single monolithic Lambda function.
Detect runtime threats (e.g., cryptomining, privilege escalation) within running ECS Fargate or EC2 containers without deploying sidecar agents.
Enable Amazon GuardDuty ECS Runtime Monitoring. For EC2, deploy the GuardDuty security agent as a DaemonSet. For Fargate, use the automated agent configuration.
Why: This provides agentless (for Fargate) or centrally managed (for EC2) runtime threat detection, capturing in-container behavior without modifying application tasks.
Automatically remediate a specific AWS Security Hub finding, such as a publicly accessible S3 bucket.
Create an EventBridge rule that matches the specific finding type (e.g., `S3.1`) and triggers a Lambda function or SSM Automation document to perform the remediation.
Why: This is the native, event-driven pattern for Security Hub automated response, providing near real-time, targeted remediation.
An IAM access key has been exposed publicly. Contain the incident and assess the blast radius.
1. Deactivate the exposed access key. 2. Attach a deny-all inline policy to the user/role to invalidate active STS sessions. 3. Review CloudTrail logs for all API calls made with the key. 4. Eradicate any unauthorized resources or IAM principals created by the attacker.
Why: Deactivating the key stops future use. The deny-all policy is critical for revoking active sessions created *before* the key was deactivated. CloudTrail provides the audit trail for damage assessment.
Enhance GuardDuty threat detection with company-specific or industry-specific threat intelligence feeds.
Upload a plaintext file of malicious IP addresses/CIDRs to S3. Create and activate a new threat intel set in GuardDuty, pointing to the S3 file.
Why: This allows you to augment GuardDuty's managed threat intelligence with custom IOCs, generating findings when your resources communicate with these specified IPs.
Identify EC2 instances with network paths open to the internet on specific ports, considering all network configurations.
Enable Amazon Inspector and review its network reachability findings.
Why: Inspector performs a full network path analysis from IGWs to instances, evaluating security groups, NACLs, and route tables to determine actual reachability. This is more accurate than just checking individual security group rules.
Investigate the full scope of a security finding, visualizing all related entities and historical behavior.
Use Amazon Detective. Navigate to the entity profile (e.g., for an EC2 instance or IAM role) to view the behavior graph and timeline of related API calls, network connections, and GuardDuty findings.
Why: Detective automatically correlates logs from CloudTrail, VPC Flow Logs, and GuardDuty, providing contextual analysis that significantly speeds up root cause investigation compared to manual log correlation.
Store audit logs (e.g., CloudTrail, VPC Flow Logs) for long-term retention in a tamper-proof, queryable manner to meet compliance.
Deliver logs to an S3 bucket with S3 Object Lock in Compliance Mode enabled. Use Amazon Athena for querying.
Why: Object Lock in Compliance Mode prevents deletion or modification by anyone, including the root user, ensuring log immutability. Athena provides ad-hoc SQL query capabilities on the stored logs.
Centrally collect all management and data events for an entire AWS Organization.
In the management account, create a CloudTrail Organization Trail. To capture object-level data, use advanced event selectors to log specific event types (e.g., S3 PutObject, Lambda Invoke) for high-value resources.
Why: An organization trail automatically logs events for all member accounts. Advanced event selectors are critical for cost-effectively logging high-volume data events by targeting only necessary resources.
Perform complex, SQL-based analysis on CloudTrail events from the entire organization over multiple years.
Enable AWS CloudTrail Lake and create an organization-level event data store with the required retention period (up to 7 years). Use the built-in SQL query editor for analysis.
Why: CloudTrail Lake provides a managed, immutable data store and query engine purpose-built for CloudTrail events, eliminating the need to manage S3, Glue, and Athena for log analysis.
Monitor all DNS queries made by resources within a VPC for threat hunting or troubleshooting.
Enable Route 53 Resolver DNS Query Logging and configure it to send logs to CloudWatch Logs, S3, or Kinesis Data Firehose.
Why: This provides detailed visibility into DNS resolution activity within your VPCs, capturing the queried domain, source instance, and response, which is crucial for detecting DNS-based threats.
Centralize and normalize security logs from various AWS and third-party sources into a data lake using a standard schema.
Deploy Amazon Security Lake. It automatically collects and normalizes data into the Open Cybersecurity Schema Framework (OCSF) and stores it in Parquet format in S3.
Why: Security Lake automates the creation and management of a security data lake, reducing the operational overhead of building custom ETL pipelines for normalization.
Automate evidence collection for compliance audits against frameworks like SOC 2, PCI DSS, or HIPAA.
Use AWS Audit Manager. Select a pre-built framework, which automatically collects evidence from AWS services (CloudTrail, Config, Security Hub) and maps it to specific compliance controls.
Why: Audit Manager automates and centralizes the evidence collection process, significantly reducing the manual effort required to prepare for and conduct compliance audits.
Automatically discover and classify sensitive data (PII, PHI, financial) across all S3 buckets.
Enable Amazon Macie and configure automated sensitive data discovery jobs. Use managed data identifiers for common data types and create custom data identifiers for proprietary formats.
Why: Macie provides a managed, scalable solution for S3 data classification. To suppress findings for known non-sensitive data (e.g., test data), use Macie allow lists.
Enforce multiple security controls on an S3 bucket, such as requiring SSE-KMS with a specific key and denying HTTP requests.
Use a bucket policy with multiple `Deny` statements and condition keys: `aws:SecureTransport: false`, `s3:x-amz-server-side-encryption: "aws:kms"`, and `s3:x-amz-server-side-encryption-aws-kms-key-id: "key-arn"`.
Why: Bucket policies provide fine-grained, resource-level control. Using multiple condition keys in Deny statements is the standard way to enforce a layered security posture on a bucket.
Ensure all new EBS volumes are encrypted with a specific customer-managed KMS key, organization-wide.
Enable EBS encryption by default in the account settings for each Region, specifying the CMK. Apply an SCP that denies `ec2:CreateVolume` if the `encrypted` parameter is `false` as a preventive guardrail.
Why: The default setting provides convenience, while the SCP provides a hard enforcement guardrail, creating a defense-in-depth approach to data-at-rest encryption for EBS.
Encrypt large (> 4KB) data objects using AWS KMS.
Use envelope encryption. Call `KMS:GenerateDataKey` to get a plaintext data key and an encrypted data key. Use the plaintext key to encrypt the large object locally. Store the encrypted object and the encrypted data key together. Discard the plaintext key.
Why: The KMS Encrypt API has a 4KB limit. Envelope encryption allows for encrypting data of any size while the small data key is protected by KMS, reducing cost and latency compared to streaming data through KMS.
Use the same encryption key across multiple AWS Regions for DR or global application consistency.
Create a KMS multi-Region primary key in one Region and create replica keys in other Regions. Data encrypted with a key in one Region can be decrypted with the replica in another.
Why: Multi-Region keys share the same key material and key ID, enabling cross-region data portability without cross-region API calls for decryption.
Securely store and automatically rotate credentials (e.g., database passwords, API keys) used by applications.
Store credentials in AWS Secrets Manager. Configure automatic rotation using a custom or AWS-provided Lambda rotation function. Applications retrieve secrets at runtime via an IAM role.
Why: Secrets Manager is a purpose-built service for the entire secret lifecycle, including secure storage, access control, auditing, and automated rotation, reducing the risk of hardcoded or stale credentials.
Manage both public TLS certificates for websites and private certificates for internal microservice communication (mTLS).
Use AWS Certificate Manager (ACM) for free public certificates integrated with ELB/CloudFront. Create a private certificate authority using ACM Private CA to issue and manage private certificates for internal services.
Why: This separates public and private PKI, using the appropriate tool for each use case. ACM handles public cert lifecycle, while ACM Private CA provides a fully managed private PKI hierarchy.
Store data immutably for a fixed retention period, where not even the root user can delete it.
Enable S3 Object Lock on the bucket. Place objects under a retention period with Compliance Mode.
Why: Compliance Mode is the strongest WORM (Write-Once-Read-Many) control, preventing deletion by any user. Governance Mode can be bypassed by authorized principals.
Protect backups from deletion (e.g., due to ransomware or compromised credentials) for a mandatory retention period.
Enable AWS Backup Vault Lock in Compliance Mode with a minimum retention period.
Why: Vault Lock in Compliance Mode makes the backup vault WORM-compliant, preventing any user, including root, from deleting recovery points before the retention period expires.
Process highly sensitive data where the data must never be exposed to the OS, hypervisor, or AWS operators.
Use AWS Nitro Enclaves to create a cryptographically isolated compute environment. Use KMS attestation to ensure only verified enclaves can decrypt data.
Why: Nitro Enclaves provide the strongest level of data-in-use protection on AWS, using hardware-level attestation to create a trusted execution environment.
Use AWS services with encryption keys that are physically stored and managed in an on-premises HSM, outside of AWS.
Configure a KMS External Key Store (XKS) which proxies cryptographic operations from KMS to an external key manager.
Why: XKS allows customers to maintain control of their key material outside AWS to meet sovereignty or compliance requirements, while still integrating with KMS-aware AWS services.
Enforce a strict "no public S3 buckets" policy across an entire organization with preventive and detective controls.
Enable S3 Block Public Access at the organization level from the management account. Supplement with an SCP that denies actions like `s3:PutBucketPolicy` if the policy allows public access. Use AWS Config to detect drift.
Why: This layered approach provides a default block (org setting), a preventive guardrail that stops misconfigurations (SCP), and a detective control for continuous monitoring (Config).
Inspect all inter-VPC and internet-bound traffic using a centralized security appliance (e.g., AWS Network Firewall).
Create a dedicated inspection VPC. Use a Transit Gateway to connect all VPCs. Configure TGW route tables to send all traffic through the inspection VPC. Enable appliance mode on the TGW attachment for symmetric routing.
Why: This is the standard hub-and-spoke model for centralized traffic inspection, providing scalability and consistent policy enforcement without complex VPC peering meshes.
Protect a web application (on CloudFront/ALB) against OWASP Top 10, bots, and account takeover attacks.
Attach AWS WAF with AWS Managed Rules (e.g., `AWSManagedRulesCommonRuleSet`), the Bot Control managed rule group, and the Account Takeover Prevention (ATP) managed rule group.
Why: This layered approach uses multiple managed rule groups for broad protection (Common), automated traffic detection (Bot Control), and specialized login endpoint security (ATP).
Provide secure, private access to a SaaS API service from customer VPCs without exposing the service to the internet.
Create an AWS PrivateLink endpoint service backed by a Network Load Balancer (NLB). Customers create interface VPC endpoints in their VPCs to access the service.
Why: PrivateLink keeps traffic on the AWS private backbone, avoiding the public internet and eliminating the need for complex VPC peering, VPNs, or IP whitelisting. It is the standard, scalable pattern for private SaaS connectivity.
Restrict S3 bucket access so that content is only accessible through a CloudFront distribution.
Use CloudFront Origin Access Control (OAC). Update the S3 bucket policy to allow access only from the CloudFront distribution's service principal, conditioned on the specific distribution ARN.
Why: OAC is the current recommended method, superior to the legacy Origin Access Identity (OAI). It supports all S3 features, including SSE-KMS, and follows security best practices.
Provide secure, auditable shell access to EC2 instances in private subnets without opening SSH/RDP ports or managing bastion hosts.
Install the SSM Agent on EC2 instances. Use AWS Systems Manager Session Manager for access. IAM policies control who can start sessions. Session activity can be logged to CloudWatch Logs and S3.
Why: Session Manager provides secure, browser-based or CLI access through an encrypted tunnel, eliminating the need for inbound ports, bastion hosts, and SSH keys, while providing full auditability.
Implement DNS-level filtering to prevent VPC resources from resolving known malicious domains.
Configure Route 53 Resolver DNS Firewall with managed domain lists (for malware, C2) and custom block lists. Associate the firewall rule group with the VPCs.
Why: This provides a centralized, managed DNS filtering service at the VPC level, blocking malicious activity at the earliest point (DNS resolution) without requiring host-based agents.
Implement least-privilege network controls for a three-tier web application.
Create separate security groups for each tier. The ALB SG allows inbound 443 from `0.0.0.0/0`. The App SG allows inbound traffic only from the ALB SG. The DB SG allows inbound traffic only from the App SG on the database port.
Why: Using security group references as sources provides dynamic, IP-agnostic microsegmentation, ensuring each tier can only be accessed by its adjacent, authorized tier.
Grant fine-grained, pod-level AWS permissions to applications running on EKS, avoiding the use of shared node IAM roles.
Enable IAM Roles for Service Accounts (IRSA) on the EKS cluster. Create an IAM role with specific permissions for the application. Annotate the application's Kubernetes service account with the IAM role ARN.
Why: IRSA provides temporary credentials directly to pods based on their service account, implementing least privilege at the pod level and eliminating the security risk of overly permissive node roles.
Provide VPN-less access to internal web applications based on both user identity and device security posture.
Deploy AWS Verified Access. Integrate with the corporate IdP as a user trust provider and a device management solution as a device trust provider. Create per-application access policies.
Why: Verified Access is purpose-built for zero-trust access, evaluating each request against policies that consider both user and device context, eliminating reliance on network perimeter security.
Allow developers to create IAM roles but prevent them from creating roles that could escalate their own privileges.
Create a permissions boundary policy that defines maximum allowed permissions. In the developers' IAM policy, condition the `iam:CreateRole` permission to require attaching this specific boundary via the `iam:PermissionsBoundary` condition key.
Why: Permissions boundaries set the maximum permissions an IAM entity can have. This prevents privilege escalation by ensuring any role a developer creates is capped by the boundary, regardless of the identity policy they attach.
Prevent any user in any member account (including administrators) from performing high-risk actions, like disabling CloudTrail or deleting a common S3 bucket.
Apply a Service Control Policy (SCP) to the root or relevant OU that has a `Deny` statement for the restricted actions (e.g., `cloudtrail:StopLogging`, `s3:DeleteBucket`).
Why: SCPs are the ultimate guardrail in AWS Organizations. They set the maximum permissions for all principals in an account, and an explicit Deny in an SCP cannot be overridden by any IAM policy within the account.
Provide secure, auditable cross-account access for an application or user.
In the target account, create an IAM role with a trust policy that specifies the source account principal ARN. In the source account, grant the principal `sts:AssumeRole` permission on the target role. The application uses STS AssumeRole to get temporary credentials.
Why: This is the standard pattern for cross-account access. It uses temporary, short-lived credentials and is fully auditable in both accounts via CloudTrail.
Integrate IAM Identity Center with an external IdP (e.g., Okta, Azure AD) and automate user/group provisioning.
Configure the external IdP as the identity source in IAM Identity Center. Enable automatic provisioning via SCIM to sync users and groups. Assign permission sets to the synchronized groups.
Why: SCIM (System for Cross-domain Identity Management) provides automated, near real-time synchronization of identities, eliminating manual user management and ensuring AWS access is driven by the IdP.
Grant access to resources (e.g., EC2) based on tags, where principals can only manage resources tagged with their own team/department name.
Tag both IAM principals (users/roles) and resources (EC2 instances) with a common key (e.g., `Team`). Create a single IAM policy that allows actions with a condition comparing `aws:PrincipalTag/Team` to `aws:ResourceTag/Team`.
Why: Attribute-Based Access Control (ABAC) provides a scalable permissions model that doesn't require policy updates when new resources or teams are added. Permissions are determined dynamically based on tags.
A principal in Account B needs to read an S3 object in Account A that is encrypted with a KMS key also in Account A.
Three permissions are required: 1) The S3 bucket policy in Account A must allow the principal from Account B. 2) The KMS key policy in Account A must allow the principal from Account B for `kms:Decrypt`. 3) The principal in Account B needs an IAM policy allowing `s3:GetObject` and `kms:Decrypt`.
Why: Access to KMS-encrypted data requires permissions from both the data service (S3) and the encryption service (KMS). The KMS key policy is a resource policy and is critical for granting cross-account access.
Understand the final permission outcome when multiple policies (IAM, Resource, SCP, Boundary) apply.
The evaluation logic is: An explicit Deny in any policy always overrides any Allow. If no Deny exists, an explicit Allow in any applicable policy grants access. The effective permissions are the intersection of all applicable policies.
Why: This is a fundamental IAM concept. An explicit Deny is the most powerful statement and serves as a hard "no". Understanding this is key to troubleshooting access issues.
Prevent an IAM user or role from passing a highly privileged role to an AWS service (e.g., EC2), which would escalate its privileges.
Scope the `iam:PassRole` permission in the user/role's IAM policy. Restrict the `Resource` element to only the specific, least-privilege role ARNs that the entity is authorized to pass.
Why: `iam:PassRole` with a wildcard (`"Resource": "*"`) is a major privilege escalation risk. Scoping it to specific, less-privileged roles is a critical security control.
Challenge users with MFA only when a login attempt is considered risky (e.g., new device, unusual location).
Enable Advanced Security features in the Cognito User Pool and configure adaptive authentication with risk-based MFA enforcement.
Why: This provides a better user experience than requiring MFA for every login, while enhancing security by applying challenges only to anomalous sign-in attempts.
Allow on-premises servers using a private PKI to access AWS services without long-term AWS credentials.
Configure IAM Roles Anywhere. Create a trust anchor using the private CA certificate. Create profiles mapping certificates to IAM roles. Servers use their certificates to obtain temporary AWS credentials.
Why: This extends IAM roles to external workloads by leveraging existing PKI, eliminating the need to manage AWS access keys on-premises.
Prevent deployment of non-compliant resources defined in CloudFormation templates *before* they are provisioned.
Enable AWS Control Tower proactive controls. These use CloudFormation hooks to validate resource configurations against policies (written in cfn-guard) prior to provisioning.
Why: This is a "shift-left" control that prevents misconfigurations at the source, which is more effective than detecting and remediating them after they have been deployed.
