Determine Appropriate Data Security Controls

Exam Guide: Solutions Architect - Associate

🛡️ Domain 1: Design Secure Architectures

📘 Task Statement 1.3

🎯 Determining appropriate data security controls is about protecting data through its full lifecycle:

• Who can access it (governance)


• How it’s classified and retained


• How it’s encrypted (at rest + in transit)


• How keys/certificates are managed and rotated


• How data is backed up, replicated, and recovered

Secure Data Design Questions You Should Be Able To Answer

1 What data is this (classification)? Public, internal, confidential, regulated (PII/PHI/PCI).


2 Where does it live? S3, EBS, RDS, DynamoDB, EFS, backups, logs, analytics.


3 Who can access it? Which roles/accounts/services? How is access audited?


4 How is it protected at rest? Encryption + key policy + separation of duties.


5 How is it protected in transit? TLS, private connectivity, certificate management.


6 How do we recover it? Backups, replication, DR strategy (RPO/RTO).


7 How long do we keep it? Retention, lifecycle policies, legal hold, deletion strategy.

Knowledge

1 | Data Access And Governance

Data governance on AWS usually means:

• Strong IAM controls (least privilege)
  


• Resource policies (e.g., S3 bucket policies)
  


• Central guardrails (e.g., Organizations and SCPs in multi-account)
  


• Visibility and auditing (CloudTrail, S3 access logs, AWS Config)
  

“Prevent unintended public exposure” → tighten resource policies + block public access + least privilege.

2 | Data Recovery

Recovery is about meeting RPO/RTO and surviving failures:

• 
  Backups: point-in-time restore, snapshots


• 
  Replication: same region or cross-region


• 
  DR patterns: pilot light, warm standby, multi-site

“Need cross-region recovery” → replication + cross-region backups

3 | Data Retention And Classification

• Keep data only as long as needed (compliance + cost)


• Classify data and apply different controls based on sensitivity

Common AWS Tools And Patterns

1 S3 lifecycle policies: transition to IA/Glacier, expire objects

2 S3 Object Lock: WORM retention for compliance

3 Macie: to discover PII in S3 and helps classification efforts

4 | Encryption And Appropriate Key Management

1 AWS-owned keys: AWS manages everything, limited control for you

2 AWS-managed keys: aws/s3, aws/rds

3 Customer-managed KMS keys (CMKs): most control for you such as key policies, rotation and grants

Encryption is not just “turn it on”, it’s who controls the keys and who can use them.

Skills

A | Align AWS Technologies To Meet Compliance Requirements

Typical Compliance Driven Controls

• Encryption at rest + in transit


• Strong retention and immutability (WORM)


• Auditability and access logging


• Key separation of duties such as the security team manages keys and app team uses keys

“Regulated data” → customer-managed KMS keys, tight key policies, strong logging, retention controls.

B | Encrypt Data At Rest

AWS Key Management Service (AWS KMS)

Common “Encryption At Rest” Mappings:

1 S3: SSE-KMS or SSE-S3 depending on requirement

2 EBS: encrypted volumes + snapshot encryption

3 RDS/Aurora: enable encryption (KMS) at creation time

4 DynamoDB: encryption at rest by default; can use CMKs

5 EFS: encryption at rest with KMS

“Need control over key usage / audit / rotation” → SSE-KMS with customer-managed key.

C | Encrypt Data In Transit

ACM using TLS

• Use TLS for all client-to-service and service-to-service communication


• Use AWS Certificate Manager (ACM) to provision/manage certificates for:
  
  
  
  
  • ALB / NLB (TLS listeners)
  
  
  • CloudFront
  
  
  • API Gateway (custom domains)
  
  
  
  
  
  

“Manage and renew certs automatically” → ACM.

D | Implement Access Policies For Encryption Keys

KMS Access Is Controlled By

1 Key policies: primary control plane

2 IAM policies: additional control

3 KMS grants: often used by AWS services to use keys on your behalf

What To Design For:

• 
  Least privilege on kms:Encrypt, kms:Decrypt, kms:GenerateDataKey
  


• 
  Separation of Duties: admins manage key and apps can use key but can’t change it

“Only specific role can decrypt” → KMS key policy that allows decrypt to that role (and denies everyone else).

E | Implement Data Backups And Replications

Common AWS Patterns:

1 AWS Backup for centralized backup policies across services (where supported)

2 EBS snapshots + cross-region snapshot copy

3 RDS automated backups + read replicas / cross-region replicas (where supported)

4 S3 replication (CRR/SRR) for object-level replication

5 DynamoDB PITR + global tables (if multi-region active-active required)

“Centralized backup policy across accounts” → AWS Backup + Organizations

F | Implement Policies For Data Access, Lifecycle, And Protection

Examples:

1 S3 bucket policy: restrict access to specific roles/VPC endpoints, require TLS

2 S3 Block Public Access: prevent accidental public exposure

3 Lifecycle Policies: move older data to cheaper tiers, expire when allowed

4 Object Lock: enforce retention or WORM for compliance archives

“Must prevent deletion for X years” → S3 Object Lock

G | Rotate Encryption Keys And Renew Certificates

1 KMS Key Rotation: enable automatic rotation for customer-managed keys (where applicable)

2 Secrets Rotation: Secrets Manager rotation for credentials

3 Certificate Renewal: ACM renews eligible certificates automatically

“Rotate keys automatically without app changes” → KMS automatic rotation (customer-managed key) + envelope encryption patterns (handled by AWS services).

Cheat Sheet

Recap Checklist ✅

If you can explain these ideas in simple terms, you are well prepared for Task Statement 1.3:

1. [ ] Data is classified (public/internal/confidential/regulatory) and controls match sensitivity


2. [ ] Data at rest is encrypted (often using KMS, with CMKs when control is required)


3. [ ] Data in transit uses TLS, with certificates managed by ACM where applicable


4. [ ] KMS key access is least-privilege (key policy + IAM), with separation of duties


5. [ ] Backups meet RPO/RTO (snapshots, PITR, AWS Backup) and are tested


6. [ ] Replication is used when the requirement is multi-region recovery or resilience


7. [ ] Retention and lifecycle policies exist (archive/expire appropriately)


8. [ ] Keys are rotated and certificates are renewed (KMS rotation / ACM renewal)

AWS Whitepapers and Official Documentation

These are the primary AWS documents behind Task Statement 1.3.


You do not need to memorize them, use them to understand why AWS data security controls work the way they do.

Encryption and Key Management

AWS Key Management Service (KMS) Developer Guide

• Explains KMS keys, envelope encryption, key policies, grants, and rotation
  


• Core reference for “who can encrypt/decrypt” questions
  

KMS Key Policies

• The most important part of controlling key usage
  


• Helps with “only this role can decrypt” and separation-of-duties scenarios
  

AWS Certificate Manager (ACM)

• How to provision and renew TLS certificates
  


• Common for ALB/CloudFront/API Gateway custom domain encryption
  

Data Protection by Service

S3 Encryption Options

• SSE-S3 vs SSE-KMS vs client-side encryption concepts
  


• Useful for “which encryption option should we pick?” scenarios
  

S3 Block Public Access

• Prevents accidental public access via ACLs/bucket policies
  


• Often the correct control when the scenario is about preventing exposure
  

S3 Object Lock (WORM retention)

• Compliance retention and legal hold
  


• Tested when immutability/retention is required
  

Amazon RDS Encryption

• How encryption at rest works for RDS/Aurora and what it impacts (snapshots/replicas)
  

Backup, Recovery, Retention

AWS Backup

• Centralized backup policies, vaults, lifecycle, and cross-account patterns
  


• Common when exam asks for “backup at scale”
  

Disaster Recovery on AWS (concepts and patterns)

• Explains RPO/RTO and DR strategies (backup/restore, pilot light, warm standby, multi-site)
  


• Helps when the question is “which DR approach matches the requirement?”
  

Compliance and Security Mindset

AWS Well-Architected Framework – Security Pillar

• The “why” behind least privilege, data protection, and governance decisions
  


• Strong general framework for answering security design questions
  

AWS Shared Responsibility Model

• Clarifies what AWS provides vs what you must configure (especially for encryption and access)
  

🚀