Data classification and encryption controls

Exam alignment: DOP-C02 Domain 6 — IAM at scale, automated security controls and data protection, security monitoring and auditing.

Learning objective

Design, automate, and troubleshoot data categories, ownership, at-rest and in-transit encryption, S3 controls, database encryption, TLS, backups, and retention across accounts and Regions while preserving least privilege, data protection, operational evidence, and controlled recovery.

Professional scenario

A growing organization implements data categories, ownership, at-rest and in-transit encryption, S3 controls, database encryption, TLS, backups, and retention inconsistently. Security controls differ by account, long-lived credentials remain active, findings are not owned, and a broad remediation could disrupt production.

Core concepts

• The lesson focuses on data categories, ownership, at-rest and in-transit encryption, S3 controls, database encryption, TLS, backups, and retention.
• Security is a shared responsibility implemented through identity, preventive controls, detective controls, and response.
• Least privilege considers action, resource, condition, session, account boundary, and time.
• Defense in depth uses independent controls so one failure does not expose the workload.
• Security automation must be scoped, idempotent, observable, reversible where possible, and exception aware.
• Evidence should show the control objective, configuration, execution, result, owner, and review date.

Security architecture walkthrough

1. Define the asset, data, threat, control objective, and accountable owner.
2. Map identities, trust boundaries, accounts, Regions, and data flows.
3. Select preventive, detective, and corrective controls.
4. Implement the control as versioned configuration or automation.
5. Test allowed, denied, failed, and exception scenarios.
6. Monitor coverage, findings, delivery failures, and control drift.
7. Respond with bounded remediation and preserve evidence.
8. Review effectiveness, cost, and residual risk.

Decision guide

Requirement	Preferred direction	Why
Human workforce access	Federation and IAM Identity Center	Central lifecycle and temporary sessions
AWS workload access	Workload role and STS credentials	Avoids embedded long-lived keys
Maximum account permissions	SCP guardrail	Limits available permissions without granting access
Delegated IAM administration	Permissions boundary plus controlled policy	Limits delegated principals
Security violation	Detect, enrich, validate, and safely remediate	Avoids blind destructive automation

Failure modes and troubleshooting

• An IAM allow is overridden by an explicit deny or another policy boundary.
• A security service is enabled in some accounts or Regions but not others.
• A key, secret, certificate, or policy is rotated without updating dependent applications.
• High-cardinality or sensitive data is placed into logs, findings, tags, or event payloads.
• Automatic remediation acts on an approved exception or stale finding.
• A central security role has broad access without separation of duties or audit.

Security and operational controls

• Use temporary credentials and workload identity wherever supported.
• Separate administration of identities, keys, logs, findings, and remediation.
• Protect security tooling and audit archives in dedicated accounts.
• Require approval for destructive, irreversible, or high-blast-radius actions.
• Do not expose secrets or regulated data in templates, logs, findings, or pipelines.

Hands-on lab

Goal: Build and validate a controlled security or compliance example for this topic.

Tasks

1. Write the control objective and threat or failure being addressed.
2. Draw identities, accounts, resources, policies, keys, and evidence flows.
3. Create a minimal policy, rule, workflow, or architecture.
4. Test one allowed and one denied or noncompliant case.
5. Introduce one controlled permission, delivery, or remediation failure.
6. Diagnose the first failed policy or service boundary.
7. Verify final access, encryption, compliance, and evidence.
8. Document exception, rollback, cleanup, and owner.

Validation

• The intended identity can perform only the required operation.
• An unintended identity or path is denied.
• Coverage across required accounts and Regions is measurable.
• The control produces protected evidence.
• Remediation does not exceed the intended scope.

Cost control: Prefer policy simulation and small sandbox resources. Security services, findings, logs, scans, keys, firewalls, and data classification can create ongoing cost.

Cleanup

1. Remove test identities, policies, rules, findings, jobs, and resources.
2. Schedule deletion of temporary keys and secrets only after dependency checks.
3. Do not disable required organization security services or audit trails.

Exam traps

• Assuming an SCP or permissions boundary grants access.
• Using IAM users and static access keys for workloads.
• Enabling encryption without validating KMS key-policy and service permissions.
• Treating a security finding as verified compromise without investigation.
• Enabling every control globally without staged rollout, exceptions, or cost analysis.

Key takeaways

• data categories, ownership, at-rest and in-transit encryption, S3 controls, database encryption, TLS, backups, and retention.
• Effective security combines identity, prevention, detection, response, and evidence.
• Automation must reduce risk without creating a larger operational blast radius.

Review questions

1. What asset and control objective are protected?
2. Which identity performs the operation?
3. Which policy layers determine effective access?
4. Where is encryption applied and who controls the key?
5. How is account and Region coverage verified?
6. What produces the finding or audit evidence?
7. What validates current state before remediation?
8. What is the exception and rollback process?

Answers

1. A named workload, identity, network path, key, secret, dataset, or audit record with a measurable objective.
2. A federated human session, workload role, service role, or scoped automation role.
3. Identity policy, resource policy, SCP, permissions boundary, session policy, trust policy, and applicable key policy.
4. At the service and data layer, with ownership separated according to the operating model.
5. Through organization inventory, delegated-administrator views, coverage findings, Config, and deployment evidence.
6. CloudTrail, Config, service logs, Security Hub findings, GuardDuty, Inspector, Macie, Access Analyzer, or pipeline results.
7. A fresh resource, policy, identity, finding, and business-exception check.
8. Documented owner, reason, scope, approval, expiry, rollback, and retest.