Study SOA-C03 Encryption, Secrets, and Data Protection: key concepts, common traps, and exam decision cues.
This lesson is about protecting data and acting on security findings operationally. SOA-C03 expects CloudOps engineers to know where encryption applies, how secrets should be stored, and how services such as Security Hub, GuardDuty, Config, and Inspector feed remediation work.
Data classification: Process of labeling data according to sensitivity or handling requirements so controls can be applied appropriately.
Finding: Security or compliance issue reported by a service that identifies a risk, misconfiguration, or suspicious behavior.
AWS wants you to separate:
| Requirement | Strongest first service or control | Why |
|---|---|---|
| Encrypt data at rest with managed key control | AWS KMS-backed encryption | This is the core at-rest encryption lane across many AWS services. |
| Encrypt traffic to a service endpoint | ACM certificate or TLS configuration | This is encryption in transit, not key-storage work. |
| Store application secrets securely and rotate them | AWS Secrets Manager | Designed for secret lifecycle and access control. |
| Store configuration values that are not all secret material | Systems Manager Parameter Store when suitable | Strong fit for parameter storage, with secure-string support where needed. |
| Aggregate and review findings from multiple security services | AWS Security Hub | It is the findings aggregation and coordination layer. |
| Detect suspicious behavior or threats | Amazon GuardDuty | Threat-detection and anomaly finding, not general config auditing. |
| Detect configuration noncompliance | AWS Config | Configuration-state and compliance tracking. |
| Detect package or workload vulnerabilities | Amazon Inspector | Vulnerability assessment path, not key management. |
flowchart TD
A["Sensitive data or workload"] --> B{"What is the requirement?"}
B -->|"Protect stored data"| C["Use encryption at rest with KMS-backed controls"]
B -->|"Protect network path"| D["Use TLS and ACM-managed certificates where appropriate"]
B -->|"Protect secrets"| E["Use Secrets Manager or secure parameter storage"]
B -->|"Aggregate and triage findings"| F["Use Security Hub"]
F --> G["Remediate GuardDuty, Config, or Inspector findings"]
Strong exam answers usually keep these lanes separate:
| Pair | How to separate them |
|---|---|
| KMS vs ACM | KMS handles encryption keys; ACM handles certificates for TLS use cases. |
| Secrets Manager vs Parameter Store | Secrets Manager is stronger for secret rotation and secret-focused lifecycle management. |
| Security Hub vs GuardDuty | Security Hub aggregates findings; GuardDuty generates threat findings. |
| Config vs Inspector | Config tracks resource configuration compliance; Inspector focuses on vulnerability assessment. |
| Trap | Better thinking |
|---|---|
| “Encryption and secrets are the same topic, so the same service should solve both.” | Keys, certificates, and secret values are related but distinct operational concerns. |
| “Security Hub detects all threats itself.” | Security Hub primarily aggregates and organizes findings from multiple sources. |
| “GuardDuty is for compliance baselines.” | GuardDuty is threat-focused, while Config is the stronger compliance/configuration lane. |
| “If a value is sensitive, any plain-text config store is fine if the subnet is private.” | Secret storage is still an application security control problem, not just a network-location problem. |