SCS-C03 · D5 · 18%

Data Protection

Protect data in transit, at rest, and in use through ownership-aware encryption, key lifecycle decisions, secret handling, discovery, masking, and evidence.

Provider facts checked 2026-08-03

Objective coverage

Objective 5.1 · high

Protect data in transit

Select and troubleshoot TLS, certificate, private-path, service-to-service, and inter-resource encryption controls.

Lesson
d5-lesson
Practice pool
d5-questions
Application
scs-l06
Objective 5.2 · high

Protect data at rest

Choose encryption ownership, key material, rotation, grants, multi-Region strategy, access evidence, and recovery behavior.

Lesson
d5-lesson
Practice pool
d5-questions
Application
scs-l06
Objective 5.3 · high

Protect confidential data, credentials, secrets, and key material

Discover, classify, mask, store, rotate, scope, and monitor access to confidential material throughout its lifecycle.

Lesson
d5-lesson
Practice pool
d5-questions
Application
scs-l06, scs-l07

Decision frame

Data protection begins with the data and its lifecycle, not with an encryption checkbox. Identify classification, owner, subjects, locations, transformations, readers, writers, retention, recovery, deletion, and regulatory or contractual constraints. Then decide which controls protect confidentiality, integrity, availability, authenticity, and auditability in each state: in transit, at rest, in processing, in backups, and in logs.

Encryption is one control. Authorization, minimization, isolation, discovery, masking, retention, monitoring, resilient key management, and verified deletion remain necessary.

Objective map

ObjectiveRequired judgmentProof
5.1 Protect data in transitSelect TLS, certificates, private paths, mutual trust, and inter-resource encryptionApproved clients succeed, downgrade or bypass paths fail, and certificate lifecycle is observable
5.2 Protect data at restSelect ownership, key material, policy, grants, rotation, Region, backup, and recovery behaviorAuthorized decrypt works, unauthorized decrypt fails, and recovery is tested
5.3 Protect confidential data, credentials, secrets, and key materialDiscover, classify, minimize, mask, store, rotate, scope, monitor, and delete sensitive materialSensitive data and secrets follow an owned lifecycle with access evidence

Protect data in transit

Map every hop. Client-to-edge, edge-to-origin, service-to-service, database, queue, stream, administrative, hybrid, replication, and backup paths can have different TLS termination and trust owners. Use AWS Certificate Manager for supported public and private certificate integrations; use AWS Private CA when the organization needs managed private certificate authority capabilities. A private network path reduces exposure but does not automatically provide the required encryption or peer authentication.

Choose server authentication, mutual TLS, or application-level signing from the threat model. Verify certificate name, issuer trust, protocol and cipher policy, renewal, deployment, revocation expectations, and monitoring. Do not hardcode expiring certificates into images. Where a managed service supports enforced transport conditions, use them with service and resource policies. For hybrid links, distinguish the connectivity service from encryption: Direct Connect is not an automatic encrypted channel, while VPN and application TLS solve different layers.

Protect data at rest

AWS KMS commonly provides envelope-encryption key management for integrated services. Understand the ownership choices. AWS owned keys are managed for service use and offer the least customer control. AWS managed keys are visible in the account but have service-managed policy and lifecycle constraints. Customer managed KMS keys provide customer policy, grants, lifecycle, and audit control. Imported key material, custom key stores, and external key stores add ownership or control options but also add availability, durability, operations, and recovery responsibility. Multi-Region keys help specific cross-Region cryptographic designs; they are not a default disaster-recovery requirement.

Separate key policy from data policy. An S3 bucket policy might permit object access while the KMS key denies decrypt, or the key may allow decrypt while the bucket denies object access. Evaluate the caller, service integration, encryption context, grants, key state, Region, alias versus key identity, and cross-account ownership. Key administrators should not automatically be data users. Limit who can change key policy, schedule deletion, disable keys, create grants, import material, or alter rotation.

Rotation reduces exposure to a key version but does not revoke access already granted to a principal. Re-encryption, credential revocation, or data migration may be required for a compromise. Backups encrypted by a deleted or inaccessible key are not recoverable simply because the backup exists. Test restoration, cross-account copy, cross-Region recovery, and key availability together.

Secrets and confidential data

Use Secrets Manager when managed rotation, secret version staging, and supported integration are required. Systems Manager Parameter Store can hold configuration and secure strings with different feature and cost characteristics. Neither fixes a workload role that can read every secret. Scope secret access, key access, network path, rotation function, resource policy, and logging. Avoid placing secrets in source, images, environment output, command history, logs, tracing attributes, or infrastructure state that is broadly readable.

For data discovery, Amazon Macie can help identify sensitive data in Amazon S3. Classification still needs ownership and response. Use masking, tokenization, redaction, aggregation, or synthetic data based on the use case. Remove sensitive fields from telemetry unless they are necessary and governed. Data loss prevention depends on knowing sanctioned paths and business use; a detection with no owner or response does not protect data.

Decision patterns

NeedPreferKey tradeoff
Service default encryption with no customer policy requirementAWS owned or AWS managed key when supported and sufficientLess customer control and separation
Customer-controlled access and lifecycleCustomer managed KMS keyMore policy, monitoring, recovery, and cost responsibility
Customer-supplied key materialImported material only when requirement justifies itCustomer owns material durability and expiration consequences
Automatic application-secret rotationSecrets Manager with bounded rotation roleRotation design, dependency behavior, and per-secret cost
Low-complexity encrypted configurationParameter Store SecureString where features fitDifferent rotation and lifecycle capabilities
Identify sensitive S3 contentMacie plus owned classification responseDiscovery does not itself restrict or remediate access

Scenario drill

A regulated workload stores records in S3, processes them in Lambda, writes derived data to a database, and replicates backups to another account and Region.

  1. Classify the fields and identify owners, retention, recovery, and permitted processing.
  2. Map TLS and authorization for every transfer and service integration.
  3. Choose customer managed keys only where policy, separation, cross-account use, or audit requirements justify them.
  4. Design key policies and grants for services and roles without making key administrators data readers.
  5. Scope secret access and rotation for the database path.
  6. Test unauthorized access, backup copy, restore, Region recovery, key disablement alarms, and deletion controls.

Common traps

  • Treating private connectivity as encryption.
  • Granting data access through an overly broad key policy or grant.
  • Assuming key rotation revokes a compromised principal.
  • Choosing multi-Region keys whenever data is copied between Regions.
  • Encrypting backups without testing key availability during restore.
  • Storing secrets in environment output or logs because the value is encrypted elsewhere.
  • Running discovery without a classification owner and response workflow.

Self-check

  1. Compare AWS owned, AWS managed, customer managed, imported, and multi-Region keys.
  2. Trace a cross-account S3 decrypt request through bucket, identity, and key policies.
  3. Explain when Secrets Manager is preferable to Parameter Store and when it is not.
  4. Design a certificate renewal and failure-monitoring path for an internal service.
  5. Name the recovery test that proves an encrypted backup is usable.

Primary references