Security and compliance permeate every domain of the AWS Certified Solutions Architect Professional (SAP-C02) exam. You will not find a single scenario-based question that does not involve security considerations — whether it is IAM design, encryption strategy, network security, or compliance requirements. The exam tests your ability to design security architectures that are both robust and operationally practical.
This guide covers advanced IAM patterns, encryption strategies, security services, compliance frameworks, and governance patterns at the depth required for SAP-C02 success. For a complete view of all exam domains, see our SAP-C02 exam guide.
Advanced IAM Patterns
IAM Policy Evaluation Logic
Understanding how AWS evaluates policies is fundamental to every security question on the SAP-C02. The evaluation follows this order:
- Explicit Deny — If any applicable policy explicitly denies the action, access is denied. Full stop.
- Organization SCP — If SCPs are in effect, the action must be allowed by the SCP (SCPs are a ceiling, not a grant).
- Resource-based policy — If the resource has a policy that grants access, the action may be allowed (with some nuances).
- Permission boundary — If a permission boundary is set, the action must be within the boundary.
- Session policy — If the request uses assumed-role session credentials with a session policy, the action must be allowed by the session policy.
- Identity-based policy — The IAM user or role must have an identity policy that allows the action.
The effective permission is the intersection of all applicable policies (except resource-based policies, which can independently grant access in some cases).
Permission Boundaries
Permission boundaries are an advanced IAM feature that sets the maximum permissions an IAM entity (user or role) can have. They do not grant permissions — they define a ceiling.
How they work:
- Attached as a managed policy to an IAM user or role
- Effective permissions = Identity-based policy INTERSECT Permission boundary
- Even if an identity policy grants
*, the permission boundary limits what is actually allowed
Use cases on the SAP-C02:
Delegated administration: Allow a development team to create IAM roles for their applications, but restrict those roles to only certain services. The team can create roles freely, but all roles they create must have the permission boundary attached — preventing privilege escalation.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:*",
"dynamodb:*",
"lambda:*",
"logs:*"
],
"Resource": "*"
}
]
}This boundary ensures that regardless of what identity policy is attached, the role can only access S3, DynamoDB, Lambda, and CloudWatch Logs.
Exam tip: Permission boundaries are the answer when the question describes a scenario where teams need to create IAM roles but must be prevented from granting permissions they should not have. The key phrase is “prevent privilege escalation” or “delegate IAM administration safely.”
Service Control Policies (SCPs) in Security Context
SCPs are covered in detail in our multi-account architecture guide, but their security implications deserve emphasis here:
- SCPs restrict all principals in member accounts, including root
- SCPs do NOT affect the management account
- SCPs do NOT affect service-linked roles
- Common security SCPs: deny region usage, deny disabling CloudTrail, deny public S3, deny leaving the organization
The relationship between SCPs, permission boundaries, and IAM policies:
| Policy Type | Who It Affects | What It Does | Grants Permissions? |
|---|---|---|---|
| SCP | All principals in the account (except management account) | Sets maximum permissions for the account | No |
| Permission Boundary | Specific IAM user or role | Sets maximum permissions for that entity | No |
| Identity Policy | Specific IAM user or role | Grants permissions | Yes |
| Resource Policy | Anyone accessing the resource | Grants or denies access to the resource | Yes |
Effective permission = SCP INTERSECT Permission Boundary INTERSECT Identity Policy (with resource policies evaluated additionally).
Session Policies
Session policies are inline policies passed when assuming a role (via AssumeRole, AssumeRoleWithSAML, or AssumeRoleWithWebIdentity) or when creating a federated user session.
- They further restrict the permissions of the assumed role
- Effective permissions = Role’s identity policy INTERSECT Session policy INTERSECT Permission boundary (if set)
- Useful for providing temporary, scoped-down access for specific tasks
Exam use case: A central role has broad permissions, but individual users assuming the role receive a session policy that limits them to their specific resources (e.g., their own S3 prefix or DynamoDB table).
Cross-Account Access Security
Cross-account role assumption requires trust on both sides:
- Trust policy on the role in the target account — specifies who can assume the role
- Identity policy on the principal in the source account — grants permission to call
sts:AssumeRole
Security best practices tested on SAP-C02:
- External ID: Prevents the confused deputy problem when third parties assume roles in your account. The external ID is a shared secret included in the trust policy condition and the AssumeRole call.
- MFA condition: Require MFA for cross-account role assumption by adding
aws:MultiFactorAuthPresentcondition to the trust policy. - Source IP restriction: Limit role assumption to specific IP ranges using
aws:SourceIpcondition.
IAM Identity Center (AWS SSO)
For human user access across a multi-account environment, IAM Identity Center is the recommended approach:
- Centralized user management with external IdP integration (SAML 2.0, SCIM)
- Permission sets define what users can do in each account (mapped from IAM policies)
- Multi-account assignments link users/groups to permission sets in specific accounts
- Supports both AWS Console and CLI access via temporary credentials
- Integrates with AWS Organizations for automatic account discovery
Encryption Strategies
AWS Key Management Service (KMS)
KMS is the central encryption service for the SAP-C02. Nearly every security question involves KMS in some form.
Key types:
| Key Type | Management | Use Case | Cost |
|---|---|---|---|
| AWS managed keys | AWS creates and manages (aws/service) | Default encryption for AWS services | Free (no monthly fee) |
| Customer managed keys (CMK) | You create and manage policies | Custom encryption with full control | $1/month + API calls |
| Custom key stores (CloudHSM) | You manage HSM cluster | Regulatory compliance requiring HSM | HSM cluster costs |
Key policies vs. IAM policies:
Every KMS key has a key policy. Unlike most AWS resources, KMS key access requires the key policy to allow access — IAM policies alone are insufficient. The default key policy grants the account root principal full access, which then allows IAM policies to work. If you modify the key policy, you must explicitly maintain access.
Cross-account KMS access pattern:
- Key policy in Account A grants Account B access to the key
- IAM policy in Account B grants the principal permission to use the key in Account A
- Both are required — missing either side blocks access
KMS key rotation:
- Automatic rotation: Available for symmetric CMKs. Rotates key material annually. Old key material is preserved for decryption.
- Manual rotation: Create a new key and update aliases. Required for asymmetric keys or when you need rotation more frequently than annually.
KMS and multi-region keys:
KMS supports multi-region keys (MRKs) — replica keys in different regions that share the same key material and key ID. This enables:
- Encrypting in one region, decrypting in another without cross-region API calls
- Simplified encryption for disaster recovery and multi-region architectures
- DynamoDB Global Tables encryption with the same key across regions
AWS CloudHSM
CloudHSM provides dedicated hardware security modules (HSMs) in the AWS cloud. Key differences from KMS:
| Feature | KMS | CloudHSM |
|---|---|---|
| Management | Shared, multi-tenant (managed by AWS) | Single-tenant, dedicated HSM (managed by you) |
| Key control | AWS manages HSM infrastructure | You manage keys and HSM cluster |
| FIPS compliance | FIPS 140-2 Level 3 (some operations) | FIPS 140-2 Level 3 (all operations) |
| Performance | Sufficient for most use cases | High-performance cryptographic operations |
| Key types | Symmetric and asymmetric | Symmetric, asymmetric, and more (HMAC, etc.) |
| Integration | Native integration with 100+ AWS services | Custom integration via PKCS#11, JCE, OpenSSL |
| Pricing | Per-key + per-API call | Per-HSM-hour (~$1.50/hour per HSM) |
When to use CloudHSM:
- Regulatory requirements mandating FIPS 140-2 Level 3 for all cryptographic operations
- Applications requiring custom cryptographic algorithms
- SSL/TLS offloading at scale
- Certificate authority (CA) private key protection
- Oracle TDE (Transparent Data Encryption) with customer-managed keys
Exam tip: If the question mentions “FIPS 140-2 Level 3,” “dedicated HSM,” or “single-tenant key management,” CloudHSM is the answer. If it mentions standard encryption needs with AWS service integration, KMS is the answer.
Encryption Patterns for AWS Services
S3 Encryption:
| Encryption Type | Key Management | Use Case |
|---|---|---|
| SSE-S3 | AWS manages keys entirely | Default encryption, simplest option |
| SSE-KMS | Customer managed KMS key | Audit trail via CloudTrail, key policy control |
| SSE-C | Customer provides encryption key with each request | Customer retains full key control, no AWS key storage |
| Client-side encryption | Customer encrypts before upload | Maximum control, end-to-end encryption |
EBS Encryption:
- Uses KMS keys (AWS managed or customer managed)
- Encrypted volumes produce encrypted snapshots
- Snapshots can be shared cross-account by sharing the KMS key
- Default encryption can be enabled per-region to enforce encryption on all new volumes
RDS/Aurora Encryption:
- Encryption at rest using KMS
- Must be enabled at creation (cannot encrypt an existing unencrypted database in place)
- To encrypt an unencrypted database: create encrypted snapshot copy, then restore from it
- Cross-region encrypted snapshot copies require a KMS key in the destination region
DynamoDB Encryption:
- Encryption at rest is always enabled (cannot be disabled)
- Options: AWS owned key (default, free), AWS managed key, or customer managed key
- Customer managed keys enable key policy control and CloudTrail logging of key usage
AWS Security Services
Amazon GuardDuty
GuardDuty is a threat detection service that continuously monitors for malicious activity:
- Analyzes CloudTrail events, VPC Flow Logs, DNS logs, EKS audit logs, S3 data events, and RDS login activity
- Uses machine learning, anomaly detection, and threat intelligence
- Generates findings categorized by severity (Low, Medium, High)
- Supports multi-account management via delegated administrator in AWS Organizations
- Auto-enables for new accounts in the organization
Exam use case: When the question describes detecting unauthorized API calls, cryptocurrency mining, compromised instances, or data exfiltration, GuardDuty is the answer.
AWS Security Hub
Security Hub provides a centralized view of security findings across multiple AWS services:
- Aggregates findings from GuardDuty, Inspector, Macie, Firewall Manager, IAM Access Analyzer, and third-party tools
- Runs automated compliance checks against standards (CIS AWS Foundations, PCI DSS, AWS Foundational Security Best Practices, NIST 800-53)
- Cross-region and cross-account aggregation
- Custom insights for organization-specific security metrics
- Automated remediation via EventBridge rules and Lambda functions or Systems Manager Automation
Exam use case: When the question asks for a “single pane of glass” for security findings, centralized compliance monitoring, or automated remediation across accounts, Security Hub is the answer.
AWS Config
Config tracks resource configurations and evaluates them against rules:
- Records configuration changes for supported AWS resources
- Config Rules evaluate whether configurations comply with policies
- Conformance packs bundle multiple rules for specific compliance frameworks
- Remediation actions can automatically fix non-compliant resources
- Aggregator collects Config data across multiple accounts and regions
Key Config Rules for SAP-C02:
encrypted-volumes— EBS volumes must be encrypteds3-bucket-public-read-prohibited— S3 buckets must not allow public readiam-root-access-key-check— Root user must not have access keyscloudtrail-enabled— CloudTrail must be enabledrds-storage-encrypted— RDS instances must have encryption enabled
AWS CloudTrail
CloudTrail records API calls and events across your AWS account:
- Management events: Control plane operations (creating resources, modifying security groups)
- Data events: Data plane operations (S3 object operations, Lambda invocations, DynamoDB item operations)
- Insights events: Unusual API call patterns (anomaly detection)
- Organization trail: Single trail that logs events for all accounts in the organization — logs delivered to a centralized S3 bucket in the log archive account
- Integrity validation: Log file digests verify that logs have not been tampered with
Exam tip: Organization trail is the answer for centralized audit logging across all accounts. Always store CloudTrail logs in a dedicated log archive account with restrictive bucket policies and SCPs that prevent deletion.
Amazon Macie
Macie uses machine learning to discover, classify, and protect sensitive data in S3:
- Automatically discovers PII, financial data, credentials, and other sensitive data
- Generates findings when sensitive data is exposed or at risk
- Integrates with Security Hub and EventBridge
- Multi-account management via Organizations
AWS Inspector
Inspector runs automated vulnerability assessments:
- Scans EC2 instances, container images in ECR, and Lambda functions
- Identifies software vulnerabilities (CVEs) and network exposure
- Agentless scanning using SSM Agent (no separate agent installation)
- Continuous scanning (re-evaluates when new CVEs are published or resources change)
IAM Access Analyzer
Access Analyzer identifies resources shared with external entities:
- Analyzes resource-based policies for S3, SQS, SNS, KMS, Lambda, IAM roles, and Secrets Manager
- Identifies unintended public or cross-account access
- Validates IAM policies against best practices
- Generates least-privilege policies from CloudTrail access activity
Compliance Frameworks and Data Sovereignty
AWS Compliance Programs
AWS maintains compliance certifications that customers inherit:
| Compliance Framework | Description | Key Services |
|---|---|---|
| PCI DSS | Payment card industry security standards | All in-scope services, encryption at rest and transit |
| HIPAA | Health data privacy and security | BAA-eligible services, PHI protection |
| SOC 1/2/3 | Service organization controls | Auditing, access control, monitoring |
| FedRAMP | US government cloud security | GovCloud, authorized services |
| GDPR | EU data protection regulation | Data residency, encryption, access controls |
| ISO 27001 | Information security management | Organization-wide security practices |
Shared responsibility model context: AWS is responsible for security “of” the cloud (physical infrastructure, hypervisor, managed service internals). The customer is responsible for security “in” the cloud (data encryption, IAM configuration, network security, OS patching for EC2).
Data Sovereignty Patterns
Region restriction:
- Use SCPs to deny API calls outside approved regions (condition on
aws:RequestedRegion) - Ensure data replication does not cross jurisdictional boundaries
- Use S3 bucket policies to prevent cross-region replication to unauthorized regions
Encryption for compliance:
- Customer managed KMS keys with strict key policies
- CloudHSM for regulatory requirements mandating dedicated key management
- Client-side encryption when data must be encrypted before reaching AWS
Access control for compliance:
- Permission boundaries for least privilege
- IAM Access Analyzer to detect unintended external access
- AWS Config rules for continuous compliance monitoring
- CloudTrail with integrity validation for audit trails
Security Architecture Patterns
Pattern 1: Centralized Security in Multi-Account
This pattern aligns with the multi-account landing zone:
- Security account: Delegated administrator for GuardDuty, Security Hub, Config aggregator, Macie
- Log archive account: CloudTrail organization trail, VPC Flow Logs, access logs — write-once, read-by-security-team
- SCPs: Prevent disabling security services, prevent deleting logs, restrict regions
- EventBridge rules: Forward high-severity findings to SNS/Lambda for automated remediation
- Cross-account IAM roles: Security team assumes roles in workload accounts for investigation
Pattern 2: Defense in Depth for a Web Application
- Edge layer: CloudFront with AWS WAF (SQL injection, XSS protection, rate limiting), Shield Advanced for DDoS
- Network layer: VPC with public/private subnets, NACLs, security groups, VPC Flow Logs
- Application layer: ALB with WAF integration, HTTPS enforcement, security headers
- Compute layer: EC2 instances in private subnets, SSM Session Manager (no SSH), Inspector for vulnerability scanning
- Data layer: RDS in isolated subnets, encryption at rest (KMS), encryption in transit (SSL), IAM database authentication
- Monitoring layer: GuardDuty, CloudTrail, Config, Security Hub aggregation
Pattern 3: Zero-Trust Network Access
- PrivateLink for service access without public internet
- VPC endpoints for AWS service access without NAT Gateways
- Systems Manager Session Manager for instance access without SSH bastion hosts
- Client VPN with IAM Identity Center integration for remote access
- Network Firewall for deep packet inspection
- All traffic encrypted in transit (TLS everywhere)
For related networking patterns, see our networking deep dive.
Exam Tips for Security Questions
- “Least privilege” is always part of the correct answer — look for the option that grants the minimum necessary permissions
- Permission boundaries are for delegated IAM administration and preventing privilege escalation
- KMS is the default encryption service; CloudHSM is for FIPS 140-2 Level 3 or dedicated HSM requirements
- Organization trail is the standard for centralized audit logging
- GuardDuty detects threats; Security Hub aggregates findings; Config monitors compliance; CloudTrail records API calls
- SCPs and permission boundaries restrict but do not grant — only identity and resource policies grant permissions
- External ID prevents the confused deputy problem in third-party cross-account access
- IAM Access Analyzer is the answer for finding unintended external access to resources
Frequently Asked Questions
What is the difference between permission boundaries and SCPs?
SCPs apply to all principals in an AWS account (or OU) and are managed through AWS Organizations. Permission boundaries apply to specific IAM users or roles and are managed within a single account. Both restrict rather than grant permissions, but they operate at different scopes — SCPs at the account level, permission boundaries at the entity level.
When should I use CloudHSM instead of KMS?
Use CloudHSM when you have regulatory requirements mandating FIPS 140-2 Level 3 compliance for all cryptographic operations, when you need single-tenant dedicated HSMs, or when your application requires custom cryptographic algorithms or high-performance cryptographic processing. For standard encryption needs with AWS service integration, KMS is simpler and more cost-effective.
How does GuardDuty differ from Security Hub?
GuardDuty is a threat detection service that generates findings by analyzing logs and network activity. Security Hub is an aggregation and compliance service that collects findings from GuardDuty and other security services, runs compliance checks, and provides a centralized dashboard. GuardDuty detects threats; Security Hub gives you a unified view.
Can IAM policies override an explicit Deny in an SCP?
No. An explicit Deny in an SCP cannot be overridden by any IAM policy, resource-based policy, or permission boundary. Explicit Deny always wins in the AWS policy evaluation logic, regardless of where the Deny originates.
What is the confused deputy problem?
The confused deputy problem occurs when a trusted third-party service (the deputy) is tricked into using its permissions on a resource it should not access. In AWS, this happens when a service assumes a role in your account without proper verification. The External ID condition in the trust policy mitigates this by requiring the third party to provide a shared secret when assuming the role.
How do I encrypt an existing unencrypted RDS database?
You cannot enable encryption on an existing unencrypted RDS instance directly. The process is: create a snapshot of the unencrypted database, copy the snapshot with encryption enabled (specifying a KMS key), then restore a new database instance from the encrypted snapshot. Finally, update your application to use the new encrypted instance endpoint.
What AWS services help with GDPR compliance?
For GDPR compliance on AWS, use a combination of: region restriction via SCPs (keep data in EU regions), KMS with customer managed keys for encryption, Macie for discovering personal data in S3, IAM Access Analyzer for detecting unintended data exposure, CloudTrail for audit logging, and AWS Config for continuous compliance monitoring. AWS also provides a GDPR-specific data processing addendum.
How does AWS Config differ from CloudTrail?
CloudTrail records API calls (who did what, when). AWS Config records resource configurations (what does the resource look like now, and has it changed). CloudTrail answers audit questions about actions. Config answers compliance questions about resource state. They are complementary — many organizations use both together for comprehensive governance.
Conclusion
Security and compliance are not isolated topics on the SAP-C02 — they are woven into every architecture decision. Understanding the interplay between SCPs, permission boundaries, IAM policies, and resource policies is essential for evaluating any scenario on the exam. Combined with encryption strategies, security service selection, and compliance patterns, security knowledge underpins your ability to design solutions that meet enterprise requirements.
These security patterns connect directly to multi-account governance, network security, and disaster recovery — topics you will see combined in complex exam scenarios.
Validate your security knowledge with Sailor.sh’s SAP-C02 mock exams. The exam’s security questions require you to evaluate nuanced scenarios involving multiple policy types, encryption requirements, and compliance constraints — and realistic practice questions are the most effective way to prepare.