Browse AWS Certification Guides

Determine Appropriate Data Security Controls for SAA-C03

Fuad Efendi March 28, 2026 5 min read

Cover encryption, KMS policy, TLS, backups, replication, and data-access controls for the SAA-C03 data-protection objective.

On this page

This task is about protecting data without breaking the workload. SAA-C03 wants you to choose the control set that matches the data, the compliance pressure, and the recovery requirement instead of throwing generic encryption language at the problem.

What AWS is explicitly testing

The current exam guide ties this task to data access and governance, recovery, retention and classification, encryption, key-management policy, backup and replication patterns, lifecycle controls, certificate renewal, and compliance alignment.

Separate the protection layers

When a data-protection question appears, break it into four parts:

  1. Where does the data live? Object, block, file, database, or stream.
  2. How is it protected at rest? SSE-S3, SSE-KMS, encrypted volume, database encryption, or a stronger custody model.
  3. How is it protected in transit? TLS through ACM, HTTPS, or private network path.
  4. How is it recoverable? Backup, replication, versioning, cross-Region copy, or lifecycle and archival design.

That model usually exposes the deciding control faster than reading the answer options top to bottom.

Classification and retention should change the answer

SAA-C03 does not expect a lawyer’s compliance memo, but it does expect you to notice when the data itself changes the architecture:

Data pressure Control direction Why
Normal business data with default at-rest protection needs Service-managed encryption default Strong baseline with low overhead
Sensitive data that needs key-use auditability or tighter authorization SSE-KMS or customer managed KMS key Adds policy control, rotation options, and CloudTrail visibility
Long-retention or write-once requirements Versioning, backup retention, or Object Lock pattern where appropriate Recovery and immutability are different from encryption
Cross-Region continuity or legal copy requirements Replication or cross-Region backup copy Protects against broader failure scope than one Region

Encryption is only one layer. If the requirement mentions retention, legal hold, point-in-time recovery, or accidental deletion, the answer usually needs lifecycle or recovery controls as well.

Protection chooser

Requirement Strongest first fit Why
Basic S3 encryption with minimal management SSE-S3 Low operational overhead
Key usage visibility and tighter control SSE-KMS Adds audit and key-policy control
Application must control encryption before data reaches the service Client-side encryption Stronger custody model than service-side encryption alone
Public certificate management for AWS-integrated services ACM Simplifies certificate issuance and renewal
Bucket-level recovery from accidental deletion Versioning plus lifecycle and backup strategy Protects object history and recovery options
Immutable retention requirement for S3 data S3 Object Lock with retention settings Strong fit for WORM-style protection scenarios
Stronger regional data protection Replication or cross-Region backup pattern Improves recovery posture beyond one Region

Map the control to the storage type

Data store Protection control AWS likes to test Watch for
S3 SSE-S3, SSE-KMS, versioning, lifecycle, replication, Object Lock Encryption alone does not solve deletion or retention requirements
EBS Volume and snapshot encryption Snapshots and copied volumes should preserve the encryption story
EFS File-system encryption and network path control File sharing does not remove the need for network and IAM design
RDS or Aurora Encryption at rest, backups, snapshots, Multi-AZ, replicas Availability features and data-protection features are related but not identical
DynamoDB Encryption, point-in-time recovery, backups, global-table strategy when required PITR and replication answer different recovery questions

KMS policy is a frequent trap

Many candidates know to “use KMS” but miss the control boundary. IAM permissions are part of the answer, but the key policy can still block the caller or service. If the symptom is “the workload has permission but cannot encrypt or decrypt,” the key policy deserves immediate attention.

KMS key policy shape you should recognize

This is the kind of resource-policy shape SAA-C03 expects you to interpret correctly:

 1{
 2  "Version": "2012-10-17",
 3  "Statement": [
 4    {
 5      "Sid": "AllowAccountAdministration",
 6      "Effect": "Allow",
 7      "Principal": {
 8        "AWS": "arn:aws:iam::111122223333:root"
 9      },
10      "Action": "kms:*",
11      "Resource": "*"
12    },
13    {
14      "Sid": "AllowAppRoleUseOfKey",
15      "Effect": "Allow",
16      "Principal": {
17        "AWS": "arn:aws:iam::111122223333:role/AppRole"
18      },
19      "Action": [
20        "kms:Encrypt",
21        "kms:Decrypt",
22        "kms:GenerateDataKey",
23        "kms:DescribeKey"
24      ],
25      "Resource": "*"
26    }
27  ]
28}

What to notice:

  • the key policy is its own authorization boundary
  • the application role is allowed to use the key, not administer it
  • SAA-C03 often tests whether you understand that IAM allow plus missing key-policy permission still fails

Encryption in transit still needs an explicit answer

At-rest controls are not a substitute for TLS. If the question mentions browsers, APIs, inter-service traffic, certificates, or secure transport, expect one of these patterns:

  • ACM-issued certificates on ALB, CloudFront, or other integrated services
  • HTTPS-only or aws:SecureTransport guardrails for S3
  • private connectivity patterns when the answer should avoid the public internet entirely

The exam likes combined answers such as SSE-KMS plus TLS plus versioning, because real data security is layered. It also expects you to prefer managed renewal and rotation where AWS provides them, such as ACM-managed certificate renewal and KMS key-rotation options on the appropriate key types.

Failure patterns worth recognizing

Symptom Strongest first check Why
The service has IAM permission but still cannot decrypt KMS key policy and grants Key authorization is separate from general IAM
Data is encrypted but accidental deletes are still a major risk Versioning, backup, retention, or Object Lock Encryption does not provide recoverability
Cross-Region copy exists but restore expectations are still unclear Replication versus backup objective Replication and backup are related but not interchangeable
Certificate-based endpoint is exposed publicly and still fails compliance review In-transit control design TLS, renewal, and certificate ownership may be the missing layer

Common traps

  • choosing encryption at rest while ignoring in-transit requirements
  • assuming a KMS-enabled service will work if the key policy is incomplete
  • using replication as if it automatically replaces backups
  • forgetting object lifecycle, retention, or versioning in data-protection scenarios
  • choosing a more complex encryption model when the real requirement is retention or recovery

Quiz

Loading quiz…

Move next into 2. Resilient Architectures to connect secure designs to loose coupling, failover, and recovery behavior.

1.2 Secure Workloads