Amazon Web Services
Expert
SCS-C02
AWS Certified Security - Specialty
The AWS Certified Security - Specialty (SCS-C02) validates advanced expertise in securing workloads and architectures on the AWS Cloud. This specialty certification is designed for experienced security professionals with at least five years of IT security experience and two or more years of hands-on experience securing AWS workloads.
The exam covers six domains: Threat Detection and Incident Response (14%), Security Logging and Monitoring (18%), Infrastructure Security (20%), Identity and Access Management (16%), Data Protection (18%), and Management and Security Governance (14%). Candidates must demonstrate deep knowledge of AWS security services including IAM, AWS Organizations, AWS Config, CloudTrail, GuardDuty, Security Hub, Inspector, Macie, KMS, CloudHSM, WAF, Shield, Network Firewall, Secrets Manager, and Certificate Manager.
Key skills tested include designing incident response procedures, configuring threat detection using GuardDuty and Security Hub, implementing network security with VPC configurations and firewalls, designing and implementing IAM policies and federation, implementing encryption and key management strategies, and automating security controls. The SCS-C02 version was released in June 2023 with updated coverage of zero-trust architectures, cloud-native security, and modern threats.
Updated Sep 2024
Cybersecurity
65
Вопросы
6
Пробные тесты
75%
Проходной балл
44
Просмотры
0
Всего попыток
0%
Ср. балл
0%
Процент сдачи
0
Обсуждения
SCS-C02 Practice Exam 1
Comprehensive practice exam covering AWS security topics including threat detection and incident response, security logging and monitoring, infrastructure security, identity and access management, data protection, and management and security governance across 65 specialty-level questions.
65 Q
170 минут
75%
SCS-C02 Practice Exam 2
Comprehensive practice exam covering AWS security topics including threat detection and incident response, security logging and monitoring, infrastructure security, identity and access management, data protection, and management and security governance across 65 specialty-level questions.
65 Q
170 минут
75%
SCS-C02 Practice Exam 3
Comprehensive practice exam focusing on network and infrastructure security at scale across AWS environments, covering threat detection, incident response, infrastructure protection, identity and access management, data protection, and security governance with 65 specialty-level questions.
65 Q
170 минут
75%
SCS-C02 Practice Exam 4
Practice exam focused on identity, federation, and access management patterns covering threat detection, incident response, security logging, infrastructure protection, identity management, and data protection for AWS Security Specialty professionals.
65 Q
170 минут
75%
SCS-C02 Practice Exam 5
Practice exam focusing on data protection, encryption strategies, and key management across AWS security domains including threat detection, logging, infrastructure security, IAM, and governance.
65 Q
170 минут
75%
SCS-C02 Practice Exam 6
Practice exam focused on security governance, compliance, and audit covering threat detection with GuardDuty and Security Hub, forensic analysis, incident response coordination, automated evidence preservation, and real-time threat monitoring for security specialty professionals.
65 Q
170 минут
75%
Разблокировать весь контент за SCS-C02
6 Пробный(е) тест(ы) + Карточки для запоминания — Доступ на 3 месяца
€39.99
€26.99
Экономия 30%
или входит в подписку Monthly / Полный набор
Предпросмотр (10 / 120)
How does AWS CloudTrail work and what is the difference between management events and data events?
AWS CloudTrail is a governance, compliance, and auditing service that records API calls and account activity across your AWS infrastructure. Management events, also called control plane operations, capture actions that create, modify, or delete AWS resources such as creating an EC2 instance, modifying an IAM policy, or configuring a VPC. These are enabled by default in every AWS account and provide a 90-day event history viewable in the CloudTrail console at no charge. Data events, also called data plane operations, capture resource-level operations performed on or within a resource, such as S3 GetObject and PutObject calls, Lambda function Invoke calls, and DynamoDB GetItem and PutItem operations. Data events are high-volume and are not recorded by default because they can generate millions of entries. You must explicitly enable data events on specific resources or for all resources of a given type by creating a trail with data event selectors. Data events incur additional charges based on the number of events recorded.
What is Amazon GuardDuty and what are its primary data sources for threat detection?
Amazon GuardDuty is an intelligent threat detection service that continuously monitors AWS accounts and workloads for malicious activity. It analyzes three primary data sources: VPC Flow Logs, which capture network traffic metadata for detecting port scanning, unusual outbound connections, and communication with known malicious IPs; AWS CloudTrail Management Events, which track API calls to detect unauthorized access attempts, privilege escalation, and suspicious configuration changes; and DNS Logs, which monitor DNS queries to identify communication with command-and-control servers or cryptocurrency mining domains. GuardDuty also supports optional data sources including S3 Data Events for detecting suspicious bucket-level activity, EKS Audit Logs for Kubernetes threat detection, RDS Login Activity for database access anomalies, Lambda Network Activity for serverless threat monitoring, and Runtime Monitoring for OS-level threat visibility on EC2 and container workloads. GuardDuty uses machine learning, anomaly detection, and integrated threat intelligence feeds from AWS and third-party partners like CrowdStrike and Proofpoint to generate findings without requiring any infrastructure to deploy or manage.
What are the main categories of GuardDuty finding types and how are they structured?
GuardDuty finding types follow a structured naming convention: ThreatPurpose:ResourceType/ThreatFamilyName.DetectionMechanism!Artifact. The main threat purpose categories include Backdoor (compromised resource communicating with C2 servers), CryptoCurrency (resource involved in mining activity), PenTest (API calls from known penetration testing tools like Kali Linux), Persistence (user creating new access methods after compromise), Policy (account behavior violating recommended security practices), Recon (reconnaissance activity like port probing or failed login attempts), Stealth (actions to hide attack evidence such as disabling logging), Trojan (resource exhibiting trojan-like behavior), UnauthorizedAccess (suspicious access patterns from unusual locations or known bad IPs), and Impact (resource being used for DDoS attacks or data destruction). Resource types include EC2, IAMUser, S3, Kubernetes, RDSLoginEvent, Lambda, and Runtime. Each finding has a severity level from 0.1 to 8.9, classified as Low (1.0-3.9), Medium (4.0-6.9), or High (7.0-8.9). High-severity findings like UnauthorizedAccess:EC2/RDPBruteForce or CryptoCurrency:EC2/BitcoinTool.B require immediate investigation and response.
What are CloudTrail organization trails and how do they enable centralized logging across all accounts?
A CloudTrail organization trail is created in the management account of an AWS Organization and automatically applies to all member accounts without requiring individual trail configuration in each account. When you create an organization trail, CloudTrail creates the same trail in every member account and begins delivering log files from all accounts to a single S3 bucket in the management account or a designated logging account. This ensures comprehensive audit coverage because member account administrators cannot disable or modify the organization trail. The S3 bucket policy must grant cross-account write permissions for CloudTrail from all organization accounts. Best practice is to deliver logs to a dedicated security or logging account rather than the management account, using a bucket policy that allows the organization principal to write objects. Organization trails capture management events by default across all Regions and can be configured to include data events and Insights events. This centralized approach simplifies compliance auditing, security investigations, and forensic analysis across the entire organization.
How do you configure GuardDuty for multi-account management using AWS Organizations?
In a multi-account environment, GuardDuty is managed through a delegated administrator model integrated with AWS Organizations. The management account designates a security-focused member account as the delegated administrator, which avoids granting direct access to the management account. The delegated administrator can then enable GuardDuty across all existing organization member accounts and configure auto-enable settings so that any new accounts joining the organization are automatically enrolled. The delegated administrator has full visibility into findings from all member accounts through a centralized console, can manage suppression rules that apply organization-wide, and can configure publishing destinations for aggregated findings. Findings from all accounts can be exported to a centralized S3 bucket in the security account using an encrypted publishing destination configured with a KMS key. For cross-Region coverage, GuardDuty must be enabled in each Region independently, though the delegated administrator designation carries across Regions within the organization. Best practice is to combine GuardDuty with AWS Security Hub for aggregated findings across Regions and accounts, using a dedicated security tooling account that acts as both the GuardDuty delegated admin and the Security Hub delegated admin.
How does CloudTrail log file integrity validation work and why is it important for security?
CloudTrail log file integrity validation uses cryptographic hashing to ensure that log files have not been modified, deleted, or forged after delivery. When enabled, CloudTrail creates a SHA-256 hash for each log file and delivers a digest file every hour that contains the hashes of all log files delivered during that period. Each digest file is signed using an RSA private key unique to each Region, and the digest file itself references the previous digest file, creating a cryptographic chain. You can validate log file integrity using the AWS CLI command aws cloudtrail validate-logs, which verifies the digital signature of each digest file and compares the recorded hashes against the actual log files in S3. If any log file has been tampered with, deleted, or replaced, the validation process detects the discrepancy and reports it. This chain-of-custody mechanism is critical for forensic investigations, regulatory compliance such as PCI DSS and HIPAA, and legal proceedings where you must prove that audit logs have not been altered. Always enable log file integrity validation on production trails and store digest files in a separate S3 bucket with restricted access.
What is AWS Security Hub and what compliance standards does it support?
AWS Security Hub is a cloud security posture management service that provides a comprehensive view of security alerts and compliance status across AWS accounts. It aggregates, organizes, and prioritizes findings from multiple AWS services (GuardDuty, Inspector, Macie, Firewall Manager, IAM Access Analyzer, Systems Manager Patch Manager) and supported third-party partner products using the AWS Security Finding Format (ASFF). Security Hub supports several compliance standards that run automated checks against your resources: AWS Foundational Security Best Practices (FSBP), which contains AWS-curated controls across dozens of services; CIS AWS Foundations Benchmark v1.2.0 and v1.4.0, providing industry-standard hardening recommendations; PCI DSS v3.2.1 for payment card industry requirements; and NIST SP 800-53 Rev. 5 for federal information system security. Each standard contains individual controls that evaluate resources and produce pass/fail findings with remediation guidance. Security Hub computes an overall security score as a percentage of passed controls versus total enabled controls. In multi-account environments, the delegated administrator can view aggregated findings and scores across all member accounts, and cross-Region aggregation allows consolidating findings from multiple Regions into a single aggregation Region for unified visibility.
What are CloudTrail Insights and CloudTrail Lake, and how do they enhance security analysis?
CloudTrail Insights automatically detects unusual API activity patterns by establishing a baseline of normal API call volumes and rates over a seven-day period, then alerting when activity deviates significantly from that baseline. Insights can detect anomalies such as unexpected spikes in resource provisioning, bursts of IAM API calls that may indicate credential compromise, or unusual patterns of data access that could signal data exfiltration. When an anomaly is detected, CloudTrail generates an Insights event that includes the baseline activity rate, the anomalous activity rate, and the time window of the unusual behavior, enabling rapid investigation. CloudTrail Lake is a managed data lake that lets you run SQL-based queries on CloudTrail events without setting up separate infrastructure. You create an event data store that aggregates events from one or multiple accounts and Regions, with configurable retention up to seven years. CloudTrail Lake supports both CloudTrail management and data events, Config configuration items, and events from non-AWS sources via integrations. You write standard SQL queries to search, filter, and analyze events for incident investigation, compliance reporting, and operational troubleshooting.
What are VPC Flow Logs, what information do they capture, and how can they be analyzed?
VPC Flow Logs capture information about IP traffic going to and from network interfaces in your VPC, providing visibility into network communication patterns and potential security issues. Flow logs can be created at the VPC level, subnet level, or individual network interface level. Each flow log record contains fields including the source and destination IP addresses, source and destination ports, protocol number, number of packets and bytes transferred, start and end timestamps, and the action taken (ACCEPT or REJECT). You can publish flow logs to three destinations: CloudWatch Logs for real-time monitoring and metric filters, S3 for long-term storage and batch analysis, and Kinesis Data Firehose for streaming to analytics services. For analysis, you can query flow logs stored in S3 using Amazon Athena with SQL queries to identify top talkers, rejected connections, traffic patterns across availability zones, and communication with known malicious IP addresses. CloudWatch Logs Insights provides an interactive query language for real-time flow log analysis. Flow logs do not capture packet payloads and do not affect network throughput or latency. Custom flow log formats allow you to select specific fields and add metadata like vpc-id, subnet-id, and instance-id.
How can Security Hub custom actions and EventBridge be used to automate security response?
Security Hub custom actions provide a mechanism to send specific findings to Amazon EventBridge for automated or semi-automated remediation. You create a custom action in Security Hub with a descriptive name and an ARN, then create an EventBridge rule that matches the custom action ARN as the source event. When a security analyst selects findings in the Security Hub console and triggers the custom action, EventBridge routes the finding details to configured targets such as Lambda functions, SNS topics, Step Functions state machines, or Systems Manager Automation documents. For example, you could create a custom action called "Isolate EC2 Instance" that triggers a Lambda function to replace the instance security group with a forensics isolation group that blocks all inbound and outbound traffic. Another common pattern is creating an automated action for "Block IP in WAF" that adds a suspicious IP address from a finding to a WAF IP set block list. For fully automated responses without human intervention, you can create EventBridge rules that match specific GuardDuty finding types directly, bypassing the custom action step entirely. This enables real-time automated remediation such as revoking compromised IAM credentials when an UnauthorizedAccess finding is generated, or quarantining an EC2 instance when cryptocurrency mining is detected.
Карточки для запоминания
карточек по ключевым концепциям 120 SCS-C02
или входит в подписку Monthly / Полный набор
110 ещё карточек доступно после разблокировки
Доступные языки
English
Japanese
Korean
Simplified Chinese
Spanish
Portuguese
Темы экзамена
1
9 Q
Threat Detection and Incident Response
Design and implement incident response plans, detect security threats, and respond to compromised resources.
2
12 Q
Security Logging and Monitoring
Design and implement monitoring and alerting, troubleshoot security logging, and design a logging solution.
3
13 Q
Infrastructure Security
Design edge security, network security for VPCs, and secure compute workloads. Troubleshoot connectivity issues.
4
10 Q
Identity and Access Management
Design and implement IAM policies, manage permissions and roles, design identity federation and SSO solutions.
5
12 Q
Data Protection
Design key management, implement encryption, design policies for data at rest and in transit, manage secrets.
6
9 Q
Management and Security Governance
Develop a strategy for centralized security management, audit AWS environments, and implement compliance frameworks.
SCS-C02 Cheat Sheet
Краткий справочник - 7 разделов
AWS Certified Security - Specialty (SCS-C02)
The SCS-C02 exam validates your expertise in securing workloads and architectures on the AWS platform. This Specialty-level certification is designed for security professionals who perform a security role and have at least two years of hands-on experience securing AWS workloads. The exam tests your ability to design and implement security solutions, detect and respond to security events, manage identity and access, protect data at rest and in transit, and implement governance frameworks to maintain compliance across AWS environments.
Exam Details
| Exam Code | SCS-C02 |
| Duration | 170 minutes |
| Number of Questions | 65 questions (50 scored + 15 unscored) |
| Passing Score | 750 / 1000 |
| Cost | $300 USD |
| Validity | 3 years |
| Question Types | Multiple choice (single & multiple select), scenario-based |
| Testing Options | Pearson VUE testing center or online proctored |
| Recommended Experience | 5+ years IT security experience, 2+ years hands-on AWS security |
| Certification Level | Specialty |
Domain Weights
| Domain | Weight |
|---|---|
| Domain 1: Threat Detection and Incident Response | 14% |
| Domain 2: Security Logging and Monitoring | 18% |
| Domain 3: Infrastructure Security | 20% |
| Domain 4: Identity and Access Management | 16% |
| Domain 5: Data Protection | 18% |
| Domain 6: Management and Security Governance | 14% |
Study Tips
- Domains 2, 3, and 5 carry the most weight at 18%, 20%, and 18% respectively; prioritize infrastructure security, logging and monitoring, and data protection in your study plan
- GuardDuty, Security Hub, and Detective are tested heavily across Domains 1 and 2; understand how they integrate with each other and with EventBridge for automated remediation
- KMS is the single most important service for this exam; master key policies, grants, key rotation, cross-account key sharing, multi-Region keys, and the differences between AWS managed, customer managed, and custom key stores
- IAM is foundational to every domain; understand policy evaluation logic, permissions boundaries, SCPs, session policies, and the difference between identity-based and resource-based policies
- Know VPC security inside and out for Domain 3: security groups, NACLs, VPC endpoints, PrivateLink, Network Firewall, and WAF rule configurations
- Encryption at rest and in transit is tested everywhere; know which services support encryption natively, which require KMS, and how to enforce encryption through policies
- Understand cross-account security patterns including sharing KMS keys, assuming roles, and centralizing logs across an AWS Organization
- Practice with real AWS scenarios; the exam is heavily scenario-based and expects you to pick the most secure and operationally efficient solution
Question Strategy Tips
- Read the last sentence of each question first to identify what is being asked, then read the full scenario with that context in mind
- Look for keywords like "least privilege", "encrypt in transit", "automated remediation", "centralized logging", or "cross-account" which point toward specific AWS services
- The Security Specialty exam heavily favors defense-in-depth approaches; if an answer only addresses one layer of security, it is likely incomplete
- When two answers seem correct, choose the one that provides the most automation and least manual intervention while maintaining the strongest security posture
- AWS-native services are almost always preferred over third-party solutions unless the question specifically mentions a third-party requirement
- Pay close attention to whether the question mentions a single account or multi-account Organization setup because the correct answer often differs significantly
- Flag complex questions and return later; do not spend more than 2.5 minutes per question on the first pass
- Use the full 170 minutes; security scenarios require careful reading to identify all constraints and requirements
Key Differences from Solutions Architect & SysOps Exams
- Security Specialty goes much deeper into encryption, key management, and data protection than any Associate or Professional exam
- Unlike Solutions Architect which focuses on architecture design, Security Specialty focuses on securing those architectures with defense-in-depth controls
- SysOps tests operational monitoring while Security Specialty tests security-specific monitoring, threat detection, and incident response automation
- Security Specialty requires deep knowledge of IAM policy evaluation logic, condition keys, and advanced federation patterns that are only lightly covered in other exams
- This exam expects you to understand compliance frameworks, audit trails, and governance controls at a level not tested in other AWS certifications
- Incident response and forensics workflows are unique to this exam; know how to isolate compromised instances, preserve evidence, and automate containment
Recommended Preparation Path
- Step 1 - Foundation: Ensure you have a solid understanding of AWS networking and IAM by completing the Solutions Architect Associate (SAA-C03) before attempting the Security Specialty exam
- Step 2 - Deep Dive: Study each domain in depth, focusing on KMS key management, IAM policy evaluation, VPC security controls, and security monitoring services
- Step 3 - Hands-On Labs: Build security architectures with GuardDuty, Security Hub, CloudTrail, KMS, WAF, and Network Firewall; practice incident response runbooks with Lambda and Step Functions
- Step 4 - Practice Exams: Take multiple full-length practice exams under timed conditions. Review every wrong answer thoroughly and understand why the correct answer provides the strongest security posture
- Step 5 - Weak Areas: Identify your weakest domains from practice exams and dedicate additional study time to those areas before scheduling the real exam
Exam Day Checklist
- Arrive 15 minutes early for testing center or start your online proctored check-in 30 minutes before the scheduled time
- Bring two forms of valid identification (one with photo) for testing center; clear your workspace for online proctoring
- You have 170 minutes for 65 questions, which gives you approximately 2 minutes and 37 seconds per question
- Use the "Flag for Review" feature liberally on questions you are unsure about; you can return to them later
- Read every word in the scenario carefully as questions often contain critical constraints in the middle of the text
- Your score is calculated on a scale of 100-1000; you need 750 to pass, which means you need to answer approximately 72-75% correctly
- Results are typically available within 1-5 business days through your AWS Certification account
- If you do not pass, you can retake the exam after 14 days; there is no limit on the number of attempts
- Request accommodations in advance if English is not your first language (extra 30 minutes available for non-native speakers)
Recommended AWS Whitepapers & Resources
- AWS Security Best Practices: Comprehensive guide to securing AWS environments covering identity management, detective controls, infrastructure protection, and data protection; directly relevant to all six domains
- Security Pillar - AWS Well-Architected Framework: Deep dive into security design principles including least privilege, defense in depth, and automating security best practices
- AWS KMS Best Practices: Key management strategies, key policies, grants, encryption context, and multi-Region key patterns; essential for Domain 5
- AWS Security Incident Response Guide: Incident response workflows, forensics procedures, and automated containment strategies; critical for Domain 1
- AWS Logging Best Practices: Centralized logging architectures, cross-account log aggregation, and security monitoring patterns; important for Domain 2
- AWS Compliance Resources: Understanding shared responsibility model, compliance programs, and audit frameworks; relevant to Domain 6
Domain 1: Threat Detection and Incident Response (14%)
This domain focuses on designing and implementing threat detection mechanisms and incident response procedures on AWS. You must understand how to use AWS security services to detect threats, automate responses, and perform forensic analysis. Key services include GuardDuty, Security Hub, Detective, EventBridge, Lambda, and Step Functions for building automated security workflows.
Amazon GuardDuty
GuardDuty is a managed threat detection service that continuously monitors for malicious activity and unauthorized behavior across your AWS accounts. It uses machine learning, anomaly detection, and integrated threat intelligence to identify threats.
| Feature | Description | Key Details |
|---|---|---|
| Data Sources | Analyzes multiple AWS data sources automatically | CloudTrail events, VPC Flow Logs, DNS logs, S3 data events, EKS audit logs, RDS login activity, Lambda network activity, EBS volume data |
| Finding Types | Categorized threat findings | Recon, UnauthorizedAccess, Trojan, CryptoCurrency, Backdoor, PenTest, Impact, Persistence, PrivilegeEscalation, Stealth |
| Severity Levels | Findings rated by severity | Low (1.0-3.9), Medium (4.0-6.9), High (7.0-8.9), Critical (9.0-10.0) |
| Malware Protection | Scans EBS volumes for malware | Triggered by GuardDuty findings; creates snapshot, scans replica; no agent required |
| Trusted/Threat IPs | Custom IP lists for tuning | Trusted IP list (whitelist) and threat IP list (additional threat intel); uploaded via S3 |
| Suppression Rules | Filter out expected findings | Auto-archive findings matching criteria; reduces noise from known activity |
AWS Security Hub
Security Hub provides a comprehensive view of your security posture across AWS accounts. It aggregates findings from multiple AWS services and third-party tools, and runs automated compliance checks against security standards.
| Feature | Description | Key Details |
|---|---|---|
| Security Standards | Automated compliance checks | CIS AWS Foundations, AWS Foundational Security Best Practices, PCI DSS, NIST 800-53 |
| Finding Aggregation | Centralized findings from multiple sources | GuardDuty, Inspector, Macie, Firewall Manager, IAM Access Analyzer, Config, third-party integrations |
| ASFF Format | AWS Security Finding Format | Standardized JSON format for all findings; enables consistent processing and automation |
| Cross-Region Aggregation | Aggregate findings across Regions | Designate an aggregation Region; findings from linked Regions flow to the aggregator |
| Custom Actions | Trigger automated responses | Send findings to EventBridge for custom remediation workflows via Lambda or Step Functions |
Amazon Detective
- Purpose: Automatically collects and analyzes log data to help investigate security findings and identify root causes of potential security issues
- Data Sources: Ingests CloudTrail logs, VPC Flow Logs, GuardDuty findings, and EKS audit logs to build a behavior graph
- Behavior Graph: Uses machine learning to create a unified interactive view showing relationships between resources, IP addresses, and API calls over time
- Integration: Directly accessible from GuardDuty findings with one-click investigation; pivots from a finding to the full context of related activity
- Exam Tip: Detective is for investigation and root cause analysis after a finding, while GuardDuty is for initial threat detection; they complement each other
Incident Response Workflows
| Phase | Actions | AWS Services |
|---|---|---|
| Detection | Identify security events and anomalies | GuardDuty, Security Hub, CloudWatch Alarms, Config Rules |
| Containment | Isolate affected resources to prevent spread | Modify security groups (deny-all), disable access keys, revoke IAM sessions, quarantine instances |
| Evidence Preservation | Capture forensic data before changes | EBS snapshots, memory dumps, CloudTrail log preservation, VPC Flow Log capture |
| Investigation | Determine scope, impact, and root cause | Detective, CloudTrail Lake queries, Athena analysis, CloudWatch Logs Insights |
| Eradication | Remove threat and restore secure state | Terminate compromised instances, rotate credentials, patch vulnerabilities, update security groups |
| Recovery | Restore normal operations | Restore from clean backups, re-deploy from IaC, validate security controls, monitor for recurrence |
Automated Remediation Patterns
- GuardDuty + EventBridge + Lambda: GuardDuty finding triggers EventBridge rule which invokes Lambda to automatically isolate a compromised EC2 instance by replacing its security group with a deny-all group
- Config Rule + SSM Automation: Non-compliant resource detected by Config triggers SSM Automation document to remediate automatically, such as enabling S3 bucket encryption or disabling public access
- Security Hub + Step Functions: Security Hub custom action sends finding to EventBridge which triggers Step Functions orchestrating a multi-step remediation workflow including approval gates
- CloudWatch Alarm + SNS + Lambda: CloudWatch alarm on suspicious metric triggers SNS notification and Lambda function for immediate automated response
- IAM Access Key Compromise: Automated workflow to disable exposed access key, attach deny-all policy to the user, revoke active sessions, create CloudTrail Lake query for audit, and notify security team
- Exam Tip: Always prefer automated remediation over manual processes; the exam rewards solutions that minimize human intervention while maintaining security
EC2 Instance Forensics
- Step 1 - Tag: Tag the compromised instance with incident details, timestamp, and investigator information for tracking
- Step 2 - Isolate: Replace security group with a forensics security group that blocks all inbound and outbound traffic except from the forensics workstation
- Step 3 - Snapshot: Create EBS snapshots of all attached volumes immediately to preserve disk state as evidence
- Step 4 - Memory: If possible, capture memory dump before stopping the instance; SSM Run Command can execute memory capture tools
- Step 5 - Metadata: Capture instance metadata, security group rules, IAM role, network interfaces, and route tables
- Step 6 - Analyze: Mount EBS snapshot on a clean forensics instance in an isolated VPC; analyze logs, file system, and processes
- Exam Tip: Never terminate a compromised instance before creating snapshots and capturing evidence; isolation first, then evidence collection, then analysis
Domain 2: Security Logging and Monitoring (18%)
This domain focuses on designing and implementing logging and monitoring solutions that provide security visibility across your AWS environment. You must understand how to collect, centralize, and analyze logs from multiple AWS services, set up alerts for security events, and monitor for anomalous activity. CloudTrail, CloudWatch, VPC Flow Logs, and AWS Config are the core services tested in this domain.
AWS CloudTrail
CloudTrail records API calls and account activity across your AWS infrastructure. It is the primary audit trail for all actions taken in your AWS environment and is essential for security analysis, compliance auditing, and operational troubleshooting.
| Feature | Description | Key Details |
|---|---|---|
| Management Events | Control plane operations | CreateBucket, RunInstances, CreateUser; logged by default; read/write separation available |
| Data Events | Data plane operations | S3 GetObject/PutObject, Lambda Invoke, DynamoDB GetItem; NOT logged by default; high volume |
| Insights Events | Anomalous API activity detection | Detects unusual API call rates and error rates; uses baseline analysis over 7 days |
| Organization Trail | Trail for all accounts in Organization | Created in management account; applies to all member accounts; logs to centralized S3 bucket |
| CloudTrail Lake | SQL-based event query engine | Query events with SQL; retention up to 7 years; supports cross-account event data stores |
| Log Integrity | Validate log file authenticity | Log file validation with SHA-256 digest files; detect tampering; critical for forensics |
CloudTrail Security Best Practices
- Enable in All Regions: Create a trail that applies to all Regions to capture API activity everywhere, including Regions you do not actively use
- Enable Log File Validation: Always enable log file integrity validation to detect any tampering with CloudTrail logs after delivery
- Encrypt with KMS: Use a customer managed KMS key (SSE-KMS) to encrypt CloudTrail logs in S3; control access via key policy
- Restrict S3 Bucket Access: Apply a bucket policy that prevents deletion and limits access to only the CloudTrail service and authorized security personnel
- Enable MFA Delete: Enable MFA Delete on the CloudTrail S3 bucket to prevent accidental or malicious log deletion
- Send to CloudWatch Logs: Configure CloudTrail to deliver logs to CloudWatch Logs for real-time monitoring, metric filters, and alerts
- Exam Tip: If a question asks about detecting unauthorized API calls or account compromise, the answer almost always involves CloudTrail with CloudWatch Logs metric filters or CloudTrail Lake queries
Amazon CloudWatch for Security
| Feature | Security Use Case | Key Details |
|---|---|---|
| Metric Filters | Create metrics from log patterns | Filter CloudTrail logs for unauthorized calls, root login, console sign-in without MFA, IAM policy changes |
| Alarms | Alert on security metric thresholds | Trigger SNS notifications or Lambda functions; composite alarms for complex conditions |
| Logs Insights | Interactive log querying | SQL-like queries across log groups; analyze patterns, identify anomalies; supports multiple log groups |
| Anomaly Detection | ML-based anomaly identification | Automatically establishes baseline and detects deviations; useful for unusual API activity patterns |
| Cross-Account Observability | Monitor multiple accounts centrally | Monitoring account views metrics, logs, and traces from source accounts via OAM links |
VPC Flow Logs
- Capture Levels: VPC level (all ENIs in VPC), subnet level (all ENIs in subnet), or ENI level (specific network interface); logs are not real-time, typically 10-15 minute delay
- Log Destinations: CloudWatch Logs (for metric filters and alarms), S3 (for Athena queries and long-term storage), or Kinesis Data Firehose (for real-time processing)
- Custom Format: Select specific fields to log including source/destination IP, ports, protocol, packets, bytes, action (ACCEPT/REJECT), and VPC/subnet/ENI identifiers
- Traffic Mirroring: For deeper packet inspection, use VPC Traffic Mirroring to copy actual network traffic to monitoring appliances; captures full packet data not just metadata
- Security Analysis: Use Athena to query Flow Logs in S3 for patterns like rejected connections from known bad IPs, unusual outbound traffic, or port scanning activity
- Exam Tip: Flow Logs capture metadata only (source/dest IP, port, protocol, action) and not packet contents; for packet inspection use Traffic Mirroring or Network Firewall
AWS Config for Security Monitoring
| Feature | Description | Key Details |
|---|---|---|
| Config Rules | Evaluate resource configurations | AWS managed rules, custom rules (Lambda); trigger on config changes or periodic schedule |
| Conformance Packs | Collection of Config rules as single entity | Deploy compliance rule packs across accounts; templates for PCI, HIPAA, NIST frameworks |
| Remediation Actions | Auto-fix non-compliant resources | Link SSM Automation documents to Config rules; automatic or manual remediation |
| Configuration Timeline | Historical record of resource changes | Track who changed what and when; compare configurations over time; compliance auditing |
| Aggregator | Multi-account multi-Region view | Aggregate compliance data from all accounts in Organization; centralized compliance dashboard |
Centralized Logging Architecture
- Log Archive Account: Dedicated AWS account for centralized log storage; all accounts forward logs here; restricted access with MFA delete on S3 buckets
- CloudTrail Organization Trail: Single trail in management account logs all API activity across every member account to centralized S3 bucket
- CloudWatch Cross-Account: Use CloudWatch cross-account observability or subscription filters to forward logs from member accounts to central monitoring account
- S3 Access Logging: Enable server access logging on all critical S3 buckets; send access logs to the centralized log archive bucket
- Kinesis Data Firehose: Stream logs from multiple accounts through Kinesis Data Firehose to S3, OpenSearch, or third-party SIEM for real-time analysis
- Log Retention: Use S3 Lifecycle policies to transition logs to Glacier for long-term retention; comply with regulatory requirements for log retention periods
- Exam Tip: Questions about centralized logging across Organizations almost always involve an Organization CloudTrail trail plus a dedicated log archive account with restricted access
Key Security Metric Filters
- Root Account Usage: Filter for userIdentity.type = "Root" to detect any root account API calls; should trigger immediate alarm
- Console Sign-In Without MFA: Filter for ConsoleLogin events where additionalEventData.MFAUsed = "No"
- IAM Policy Changes: Filter for CreatePolicy, DeletePolicy, AttachRolePolicy, DetachRolePolicy, PutRolePolicy events
- Security Group Changes: Filter for AuthorizeSecurityGroupIngress, RevokeSecurityGroupIngress, CreateSecurityGroup events
- NACL Changes: Filter for CreateNetworkAcl, DeleteNetworkAcl, CreateNetworkAclEntry events
- CloudTrail Changes: Filter for StopLogging, DeleteTrail, UpdateTrail to detect attempts to disable audit logging
- Failed Authentication: Filter for ConsoleLogin events where responseElements.ConsoleLogin = "Failure" to detect brute force attempts
Domain 3: Infrastructure Security (20%)
This is the highest-weighted domain on the exam at 20%. It focuses on designing and implementing network security controls, edge security, and secure connectivity for AWS workloads. You must understand VPC security mechanisms, web application protection, DDoS mitigation, and private connectivity options. Key services include VPC security groups, NACLs, WAF, Shield, Network Firewall, CloudFront, PrivateLink, VPN, and Direct Connect.
VPC Security Controls
| Control | Description | Key Details |
|---|---|---|
| Security Groups | Stateful firewall at ENI level | Allow rules only (no deny); return traffic auto-allowed; reference other SGs by ID; default denies all inbound |
| NACLs | Stateless firewall at subnet level | Allow and deny rules; numbered rule evaluation; ephemeral ports needed for return traffic; default allows all |
| Network Firewall | Managed stateful/stateless firewall | Deep packet inspection, IDS/IPS, domain filtering, Suricata-compatible rules; deployed per AZ in firewall subnet |
| VPC Endpoints | Private connectivity to AWS services | Gateway endpoints (S3, DynamoDB; free), Interface endpoints (PrivateLink; most services; ENI in subnet) |
| Endpoint Policies | Control access through VPC endpoints | IAM resource policy on endpoint; restrict which principals and resources can be accessed through the endpoint |
| DNS Firewall | Filter DNS queries from VPC | Block or allow DNS resolution for specific domains; prevent DNS exfiltration; managed domain lists available |
Security Groups vs NACLs
| Attribute | Security Groups | Network ACLs |
|---|---|---|
| Scope | Instance (ENI) level | Subnet level |
| State | Stateful (return traffic auto-allowed) | Stateless (must explicitly allow return traffic) |
| Rules | Allow rules only | Allow and deny rules |
| Evaluation | All rules evaluated | Rules evaluated in number order; first match wins |
| Use Case | Primary instance-level firewall | Subnet-level deny rules; block specific IPs |
AWS WAF (Web Application Firewall)
| Feature | Description | Key Details |
|---|---|---|
| Web ACLs | Collection of rules for web traffic filtering | Associate with ALB, CloudFront, API Gateway, AppSync, Cognito; rules evaluated in priority order |
| Managed Rule Groups | Pre-built rule sets by AWS and partners | Core Rule Set, SQL injection, XSS, known bad inputs, IP reputation, Bot Control, Account Takeover Prevention |
| Rate-Based Rules | Block IPs exceeding request threshold | Set threshold per 5-minute window; auto-block and auto-unblock; combine with scope-down statements |
| IP Sets | Lists of IP addresses for allow/block | IPv4 and IPv6; up to 10,000 addresses per set; reusable across multiple rules |
| Logging | Full request logging for analysis | Send to CloudWatch Logs, S3, or Kinesis Data Firehose; includes matched rules and actions taken |
AWS Shield & DDoS Protection
- Shield Standard: Automatic protection against common Layer 3 and Layer 4 DDoS attacks at no additional cost; included for all AWS customers on CloudFront, Route 53, and Global Accelerator
- Shield Advanced: Enhanced DDoS protection with 24/7 access to the AWS Shield Response Team (SRT), real-time attack visibility, financial protection against scaling charges, and automatic application layer mitigation
- Shield Advanced Resources: Protects EC2, ELB, CloudFront, Global Accelerator, and Route 53; must explicitly add resources to protection
- SRT Support: Shield Response Team can write WAF rules on your behalf during active attacks; requires pre-authorized IAM role access
- Health-Based Detection: Create Route 53 health checks for protected resources; Shield Advanced uses health check status to improve detection accuracy and reduce false positives
- Exam Tip: Shield Advanced is required when questions mention 24/7 DDoS response team support, cost protection during attacks, or automatic WAF rule creation during incidents
AWS Network Firewall
- Architecture: Deployed in a dedicated firewall subnet per AZ; traffic routed through firewall endpoints via VPC route tables; inspect traffic between subnets, to/from internet, and to/from other VPCs
- Stateless Rules: Simple packet-level filtering based on source/destination IP, port, and protocol; processed first; can pass, drop, or forward to stateful engine
- Stateful Rules: Connection-tracking rules supporting 5-tuple, domain name filtering, and Suricata-compatible IPS rules; inspect full connection context
- Domain Filtering: Allow or block traffic to specific domain names using TLS SNI inspection; useful for controlling egress to specific external services
- Firewall Manager: Deploy Network Firewall policies across multiple accounts and VPCs in an Organization from a central administrator account
- Exam Tip: Use Network Firewall when questions mention deep packet inspection, IDS/IPS, Suricata rules, or domain-based egress filtering; it is the preferred answer over third-party appliances
CloudFront Security
| Feature | Description | Key Details |
|---|---|---|
| OAC | Origin Access Control for S3 | Replaces OAI; supports SSE-KMS, all S3 Regions; restricts S3 access to CloudFront only |
| Field-Level Encryption | Encrypt specific POST fields at edge | Asymmetric encryption at edge; only authorized apps can decrypt; protects sensitive data end-to-end |
| Signed URLs/Cookies | Restrict access to content | Signed URLs for individual files; signed cookies for multiple files; use trusted key groups (RSA key pairs) |
| Geo Restriction | Block or allow by country | Allowlist or denylist by country code; uses third-party GeoIP database |
| Security Policy | TLS version and cipher control | Choose minimum TLS version (1.0, 1.1, 1.2); select cipher suites; TLSv1.2_2021 recommended |
Private Connectivity Options
| Option | Description | Key Details |
|---|---|---|
| AWS PrivateLink | Private access to services via ENI | No internet gateway needed; traffic stays on AWS network; expose services across accounts and VPCs securely |
| Site-to-Site VPN | Encrypted tunnel over internet | IPSec encrypted; two tunnels per connection for HA; up to 1.25 Gbps per tunnel; quick to set up |
| Direct Connect | Dedicated private network connection | 1, 10, or 100 Gbps; consistent latency; not encrypted by default; add VPN over DX for encryption |
| Transit Gateway | Hub for connecting VPCs and on-premises | Centralized routing; supports VPN, Direct Connect, VPC peering; route table segmentation for security |
| Client VPN | Remote user VPN access | OpenVPN-based; mutual TLS or Active Directory auth; split-tunnel or full-tunnel; authorize by network CIDR |
Infrastructure Security Best Practices
- Defense in Depth: Layer security controls at every level: edge (CloudFront + WAF + Shield), VPC (NACLs + security groups), subnet (public/private separation), instance (host firewall + patching), application (input validation + authentication)
- Minimize Public Exposure: Place resources in private subnets; use ALB or CloudFront as the public entry point; access AWS services via VPC endpoints instead of internet gateway
- Network Segmentation: Use separate VPCs or subnets for different trust levels; use Transit Gateway route tables to isolate network segments; implement zero-trust network architecture
- Egress Control: Use NAT Gateway for controlled internet access from private subnets; Network Firewall for domain-based filtering; VPC endpoints to eliminate need for internet access to AWS services
- Patch Management: Use Systems Manager Patch Manager for automated patching; define patch baselines; use maintenance windows; scan for compliance without installing
- Exam Tip: When a question mentions protecting web applications, the answer almost always involves CloudFront + WAF + Shield; for network inspection, use Network Firewall; for blocking specific IPs, use NACLs or WAF IP sets
Domain 4: Identity and Access Management (16%)
This domain focuses on designing and implementing authentication and authorization controls for AWS resources. You must understand IAM policy evaluation logic, federation patterns, cross-account access, permissions boundaries, service control policies, and advanced identity management using IAM Identity Center, Cognito, and Roles Anywhere. IAM is foundational to every aspect of AWS security.
IAM Policy Types & Evaluation
| Policy Type | Description | Key Details |
|---|---|---|
| Identity-Based | Attached to users, groups, or roles | Managed (AWS or customer) and inline; specify what actions the principal can perform |
| Resource-Based | Attached to resources (S3, KMS, SQS) | Specify who can access the resource; enables cross-account access without assuming roles; inline only |
| Permissions Boundary | Maximum permissions for an IAM entity | Sets upper bound; effective permissions = intersection of identity policy AND boundary; used for delegation |
| SCPs | Organization-wide permission guardrails | Applied to OUs or accounts; restrict maximum permissions; do NOT grant permissions; do not affect management account |
| Session Policies | Limit permissions for a session | Passed when assuming role or federating; effective permissions = intersection of role policy AND session policy |
| Endpoint Policies | Control access through VPC endpoints | Resource policy on VPC endpoint; restrict which actions and resources accessible through the endpoint |
IAM Policy Evaluation Logic
- Step 1: Evaluate all applicable SCPs; if any SCP denies, the request is denied regardless of other policies
- Step 2: Check for explicit deny in any applicable policy; an explicit deny always overrides any allow
- Step 3: Check resource-based policies; if a resource-based policy grants access to the caller, access is allowed (same account only)
- Step 4: Check identity-based policies; if they grant access, check permissions boundaries
- Step 5: Check permissions boundaries; effective permissions are the intersection of identity policy and boundary
- Step 6: Check session policies if applicable; further restricts the effective permissions
- Default: If no policy explicitly allows the action, the request is implicitly denied
- Exam Tip: Remember the evaluation order: explicit deny wins first, then SCPs, then the intersection of all applicable allow policies and boundaries; understanding this logic is critical for the exam
IAM Identity Center (SSO)
| Feature | Description | Key Details |
|---|---|---|
| Identity Sources | Where users are managed | Identity Center directory, Active Directory (AD Connector or AWS Managed AD), or external IdP (SAML 2.0, SCIM) |
| Permission Sets | Define access level for accounts | Collection of IAM policies; assigned to users/groups for specific accounts; creates roles in target accounts |
| Multi-Account Access | SSO across Organization accounts | Single portal for accessing all assigned accounts; automatic role creation; centralized access management |
| ABAC Support | Attribute-Based Access Control | Pass user attributes as session tags; use in IAM policy conditions; scale permissions without policy changes |
Amazon Cognito
- User Pools: User directory for sign-up and sign-in; supports MFA, email/phone verification, password policies, account recovery; returns JWT tokens (ID, access, refresh)
- Identity Pools: Exchange tokens for temporary AWS credentials; supports authenticated (Cognito, SAML, OIDC, social) and unauthenticated guest access; maps users to IAM roles
- Lambda Triggers: Customize authentication flow with Lambda functions at each stage: pre-sign-up, pre-authentication, post-authentication, pre-token-generation, custom message, and migrate user
- Advanced Security: Adaptive authentication with risk-based MFA; compromised credentials detection; IP-based and device-based tracking
- Exam Tip: User Pools for authentication (who are you), Identity Pools for authorization (what can you access); use together for web and mobile applications that need AWS resource access
Cross-Account Access Patterns
| Pattern | Mechanism | Key Details |
|---|---|---|
| AssumeRole | STS cross-account role assumption | Trust policy in target account grants access; caller must have sts:AssumeRole permission; temporary credentials |
| Resource-Based Policy | Grant access directly on resource | S3 bucket policy, KMS key policy, SNS/SQS policy; no role assumption needed; caller retains original permissions |
| Identity Center | Centralized SSO access | Permission sets define access; automatic role creation; best for human users accessing multiple accounts |
| Organizations Delegation | Delegated admin for services | Delegate service administration to member accounts; Security Hub, GuardDuty, Config delegated admin |
IAM Roles Anywhere
- Purpose: Enables on-premises workloads to obtain temporary AWS credentials using X.509 certificates from your PKI infrastructure
- Trust Anchor: Register your Certificate Authority (CA) as a trust anchor; supports ACM Private CA or external CAs
- Profile: Define which IAM role to assume and optional session policies; restrict permissions based on certificate attributes
- Use Case: Replace long-term access keys for on-premises servers, containers, or IoT devices with temporary role-based credentials
- Exam Tip: When a question mentions on-premises workloads needing AWS access without long-term credentials, Roles Anywhere with X.509 certificates is the preferred answer
IAM Best Practices for Security
- Least Privilege: Grant only the minimum permissions required; use IAM Access Analyzer to identify unused permissions and right-size policies over time
- No Long-Term Keys: Use IAM roles instead of access keys wherever possible; for on-premises, use Roles Anywhere; rotate any remaining keys regularly
- Enforce MFA: Require MFA for all human users; use IAM condition key aws:MultiFactorAuthPresent for sensitive operations; enforce MFA for console and CLI access
- Permissions Boundaries: Use permissions boundaries when delegating IAM admin tasks to developers; prevents privilege escalation by capping maximum permissions
- IAM Access Analyzer: Enable in all Regions; detects resources shared externally (S3, IAM roles, KMS keys, Lambda, SQS); validates policies against best practices; generates least-privilege policies from CloudTrail
- Condition Keys: Use conditions like aws:SourceIp, aws:SourceVpc, aws:PrincipalOrgID, aws:RequestedRegion to add contextual restrictions to policies
- Exam Tip: Always look for the answer that implements least privilege, uses temporary credentials, and enforces MFA; the exam strongly penalizes answers that use long-term credentials or overly permissive policies
Domain 5: Data Protection (18%)
This domain focuses on implementing data encryption, key management, and data classification strategies to protect data at rest and in transit on AWS. You must understand AWS KMS in depth including key policies, grants, key rotation, and cross-account key sharing. Additional services covered include CloudHSM, ACM, Secrets Manager, SSM Parameter Store, and Macie for data discovery and classification.
AWS KMS (Key Management Service)
KMS is the most critical service for the Security Specialty exam. It provides centralized key management for encryption across virtually all AWS services. Understanding key types, key policies, grants, and encryption context is essential.
| Feature | Description | Key Details |
|---|---|---|
| AWS Managed Keys | Created by AWS services automatically | Alias aws/service-name; auto-rotated every year; cannot manage key policy; free |
| Customer Managed Keys | Created and managed by you | Full control of key policy; optional automatic rotation (every year); can disable or schedule deletion; $1/month |
| Key Policies | Resource-based policy on KMS key | Required for all KMS keys; defines key administrators and key users; must explicitly grant access; default policy enables IAM policies |
| Grants | Temporary, delegated key access | Programmatic; used by AWS services to encrypt/decrypt on your behalf; grant tokens for eventual consistency |
| Encryption Context | Key-value pairs for additional auth | Non-secret metadata; must match on encrypt and decrypt; logged in CloudTrail; use for audit and access control |
| Multi-Region Keys | Replicated keys across Regions | Same key material in multiple Regions; encrypt in one Region, decrypt in another; for global applications and DR |
KMS Key Rotation
- Automatic Rotation: Enabled per key; rotates key material every year; old key material retained for decryption; key ID and ARN do not change; transparent to applications
- Manual Rotation: Create a new KMS key with new key material; update alias to point to new key; old key retained for decrypting old data; requires application changes if not using aliases
- Imported Key Material: Automatic rotation not supported; must manually rotate by importing new material into a new key; use aliases for transparent rotation
- Exam Tip: If a question asks about key rotation with zero application changes, the answer is automatic rotation (for customer managed keys) or alias-based manual rotation
Cross-Account KMS Key Sharing
- Step 1: Key policy in the owning account must grant kms:Decrypt (and other needed actions) to the IAM principal in the consuming account
- Step 2: IAM policy in the consuming account must grant the principal permission to use the KMS key in the owning account
- Step 3: Both key policy AND IAM policy must allow access; key policy alone is sufficient only if it directly grants to the principal (not just enables IAM)
- Grants: Alternative to key policies for temporary cross-account access; programmatic, can be revoked; used by AWS services internally
- Exam Tip: Cross-account KMS questions are very common; remember that BOTH the key policy in the key account AND the IAM policy in the user account must allow access
AWS CloudHSM
| Attribute | KMS | CloudHSM |
|---|---|---|
| Management | Shared multi-tenant HSMs managed by AWS | Dedicated single-tenant HSMs; you manage the cluster |
| Key Control | AWS manages HSM infrastructure | Full customer control; AWS cannot access keys; FIPS 140-2 Level 3 |
| Integration | Native integration with 100+ AWS services | Custom key store in KMS, SSL/TLS offload, Oracle TDE, code signing |
| Use Case | General encryption; most workloads | Regulatory compliance requiring dedicated HSM; PKCS#11, JCE, CNG |
| Custom Key Store | N/A | Link CloudHSM cluster to KMS; use KMS API but keys stored in your HSMs |
Encryption at Rest by Service
| Service | Default Encryption | Key Details |
|---|---|---|
| S3 | SSE-S3 by default (Jan 2023+) | SSE-S3, SSE-KMS (audit trail), SSE-C (customer-provided key), DSSE-KMS; bucket default encryption setting |
| EBS | Optional; account-level default setting | AES-256; uses KMS key; enable default encryption per Region; encrypted snapshots; cannot remove encryption |
| RDS | Optional at creation; cannot change after | KMS encryption; encrypted snapshots; read replicas encrypted with same or different key; cannot encrypt existing DB |
| DynamoDB | Encrypted by default | AWS owned key (free), AWS managed key, or customer managed key; can change key type after creation |
| EFS | Optional at creation | KMS encryption for data at rest; TLS for data in transit via mount helper; cannot enable after creation |
Secrets Management
| Service | Use Case | Key Details |
|---|---|---|
| Secrets Manager | Database credentials, API keys, secrets | Automatic rotation via Lambda; native RDS/Aurora/Redshift rotation; cross-account access; versioning; $0.40/secret/month |
| SSM Parameter Store | Configuration data, non-rotating secrets | Standard (free, 10K limit, 4KB) and Advanced (paid, 100K limit, 8KB); SecureString type uses KMS; hierarchical |
| ACM | TLS/SSL certificates | Free public certificates; auto-renewal; integrate with ALB, CloudFront, API Gateway; ACM Private CA for internal certs |
Amazon Macie & Data Classification
- Purpose: Fully managed data security and privacy service that uses machine learning and pattern matching to discover and protect sensitive data in S3
- Managed Data Identifiers: Pre-built detectors for PII (names, addresses, SSN), financial data (credit card numbers), credentials, and health data across 100+ sensitive data types
- Custom Data Identifiers: Define your own regex patterns and keywords to detect organization-specific sensitive data like internal IDs or proprietary formats
- S3 Inventory: Provides a complete inventory of S3 buckets with encryption status, public access settings, and sharing configuration across your Organization
- Findings: Generates findings for sensitive data discoveries and policy violations; sends to Security Hub and EventBridge for automated workflows
- Exam Tip: When a question asks about discovering PII or sensitive data in S3, the answer is always Macie; for preventing sensitive data from being uploaded, combine Macie with S3 event notifications and Lambda
Data Protection Best Practices
- Encrypt Everything: Enable encryption at rest for all services; use customer managed KMS keys for audit trail and fine-grained access control via key policies
- Enforce TLS: Use aws:SecureTransport condition in S3 bucket policies; enforce HTTPS on ALB listeners; require TLS 1.2+ minimum on CloudFront distributions
- S3 Bucket Security: Enable S3 Block Public Access at account level; use bucket policies to enforce encryption; enable versioning and MFA Delete; use Object Lock for compliance
- Key Management: Use separate KMS keys per application or data classification; enable automatic rotation; monitor key usage via CloudTrail; use key policies for access control
- Secrets Rotation: Use Secrets Manager with automatic rotation for all database credentials; rotate at minimum every 90 days; use Lambda rotation functions
- Exam Tip: Questions about enforcing encryption often have answers involving S3 bucket policies with deny on PutObject when encryption header is missing, or SCP denying unencrypted operations
Domain 6: Management and Security Governance (14%)
This domain focuses on implementing governance frameworks, compliance controls, and security management strategies across AWS Organizations. You must understand how to use AWS Organizations, Control Tower, SCPs, Config rules, and other governance services to enforce security policies at scale. This domain also covers audit management, compliance frameworks, and account management best practices.
AWS Organizations
| Feature | Description | Key Details |
|---|---|---|
| OUs | Organizational Units for grouping accounts | Hierarchical structure; nest OUs up to 5 levels; apply SCPs at any level; accounts inherit parent OU policies |
| SCPs | Service Control Policies | Maximum permissions guardrails; do NOT grant permissions; deny overrides allow; do not affect management account |
| Delegated Admin | Delegate service administration | Designate member accounts as delegated admins for Security Hub, GuardDuty, Config, Macie, Firewall Manager |
| Tag Policies | Enforce standardized tagging | Define allowed tag keys and values; enforce consistency across accounts; support cost allocation and access control |
| Backup Policies | Centralized backup management | Define backup plans at Organization level; apply across accounts; ensure consistent data protection |
Common SCP Patterns
- Deny Region: Restrict API calls to specific AWS Regions; use aws:RequestedRegion condition key; exempt global services (IAM, STS, CloudFront, Route 53)
- Deny Root User: Block all actions by root user in member accounts except specific break-glass scenarios; use aws:PrincipalArn condition
- Deny Leaving Org: Prevent accounts from leaving the Organization; deny organizations:LeaveOrganization action
- Deny CloudTrail Changes: Prevent disabling or modifying the Organization CloudTrail; deny cloudtrail:StopLogging, DeleteTrail, UpdateTrail
- Deny Unencrypted: Block creation of unencrypted resources; deny ec2:RunInstances when ebs:Encrypted is false; deny s3:PutObject without encryption headers
- Deny Public S3: Block S3 public access at Organization level; deny s3:PutBucketPublicAccessConfiguration changes; enforce S3 Block Public Access
- Exam Tip: SCPs are tested heavily; remember they do NOT affect the management account, they do NOT grant permissions, and explicit denies always win
AWS Control Tower
| Feature | Description | Key Details |
|---|---|---|
| Landing Zone | Pre-configured multi-account environment | Sets up Organizations, OUs, shared accounts (Log Archive, Audit); baseline security configuration |
| Guardrails | Pre-packaged governance rules | Preventive (SCPs), Detective (Config rules), Proactive (CloudFormation hooks); mandatory, strongly recommended, elective |
| Account Factory | Automated account provisioning | Standardized account creation with pre-configured VPC, guardrails, and SSO access; customizable templates |
| Dashboard | Compliance visibility | View compliant and non-compliant accounts, OUs, and guardrails; centralized governance monitoring |
| Customizations | Extend with custom blueprints | CfCT (Customizations for Control Tower); deploy additional resources via CloudFormation at account creation |
AWS Config for Compliance
- Managed Rules: Over 300 pre-built rules for common compliance checks including s3-bucket-server-side-encryption-enabled, ec2-instance-no-public-ip, iam-root-access-key-check, and restricted-ssh
- Custom Rules: Write custom evaluation logic using Lambda functions or Guard DSL; trigger on configuration changes or on a periodic schedule
- Conformance Packs: Collection of Config rules and remediation actions packaged as a single entity; deploy pre-built packs for PCI DSS, HIPAA, CIS Benchmarks, NIST 800-53
- Organization Rules: Deploy Config rules across all accounts in an Organization from the management or delegated admin account
- Remediation: Attach SSM Automation documents to Config rules for automatic or manual remediation of non-compliant resources
- Exam Tip: Config evaluates compliance continuously; use conformance packs for framework-level compliance and individual rules for specific security checks
AWS Firewall Manager
| Policy Type | Description | Key Details |
|---|---|---|
| WAF Policies | Deploy WAF rules across accounts | Apply WAF Web ACLs to ALBs, CloudFront, API Gateway across all member accounts automatically |
| Shield Advanced | Centralized DDoS protection | Enable Shield Advanced across all accounts; manage protected resources centrally |
| Security Group Policies | Audit and enforce SG rules | Common security groups applied across accounts; audit rules for overly permissive access; auto-remediate |
| Network Firewall | Deploy Network Firewall policies | Centrally manage Network Firewall rules and deployments across Organization VPCs |
| DNS Firewall | Deploy DNS filtering policies | Manage Route 53 Resolver DNS Firewall rules across all VPCs in the Organization |
Audit & Compliance Services
| Service | Purpose | Key Details |
|---|---|---|
| AWS Audit Manager | Automate evidence collection for audits | Pre-built frameworks for SOC 2, PCI DSS, HIPAA, GDPR; automatic evidence from Config, CloudTrail, Security Hub |
| AWS Artifact | Access AWS compliance reports | Download SOC reports, PCI DSS attestation, ISO certifications; accept AWS agreements (BAA, NDA) |
| Trusted Advisor | Best practice recommendations | Security checks: open ports, IAM usage, MFA, S3 permissions, root account; full checks require Business/Enterprise Support |
| IAM Access Analyzer | Identify external resource access | Analyzes resource policies for external sharing; validates policies; generates least-privilege policies from CloudTrail |
| Inspector | Vulnerability scanning | Agentless EC2 scanning, Lambda code scanning, ECR image scanning; automatic CVE detection; SBOM export |
Multi-Account Security Architecture
- Management Account: Owns the Organization; apply SCPs to OUs; minimal workloads; secure with restricted access and MFA on root
- Security Tooling Account: Delegated administrator for Security Hub, GuardDuty, Macie, Inspector; centralized security monitoring and response
- Log Archive Account: Centralized CloudTrail, Config, VPC Flow Logs storage; restricted access; immutable logging with S3 Object Lock and MFA Delete
- Network Account: Shared networking services; Transit Gateway, VPN, Direct Connect; centralized Network Firewall and DNS management
- Workload Accounts: Separate accounts per environment (dev, staging, prod) or per application; isolated blast radius; apply appropriate SCPs per OU
- Shared Services Account: Common services like Active Directory, CI/CD tooling, artifact repositories; accessed via RAM or cross-account roles
- Exam Tip: Multi-account architecture questions are very common; know the purpose of each account type and how they interact through Organizations, delegated admin, and cross-account roles
Governance Best Practices
- Preventive Controls: Use SCPs to prevent prohibited actions; use IAM permissions boundaries for delegated admin; enforce encryption and region restrictions at the Organization level
- Detective Controls: Enable Config rules and conformance packs across all accounts; use Security Hub for centralized compliance scoring; monitor with GuardDuty and CloudTrail
- Responsive Controls: Automate remediation of non-compliant resources using Config remediation actions, EventBridge rules, and Lambda functions; minimize manual intervention
- Shared Responsibility: Understand what AWS secures (infrastructure, physical, hypervisor) versus what you secure (data, OS, network config, IAM); this model is foundational to the exam
- Continuous Compliance: Treat compliance as continuous rather than point-in-time; use Audit Manager for ongoing evidence collection; Config for real-time evaluation; Security Hub for scoring
- Exam Tip: Governance questions favor automated, Organization-wide solutions over manual, per-account approaches; use Control Tower guardrails, Organization Config rules, and Firewall Manager policies