Determine Appropriate Data Security Controls for SAA-C03

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:

Where does the data live? Object, block, file, database, or stream.
How is it protected at rest? SSE-S3, SSE-KMS, encrypted volume, database encryption, or a stronger custody model.
How is it protected in transit? TLS through ACM, HTTPS, or private network path.
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