1.2 Prescribe Security Controls
Official task mapping
SAP-C02 task 1.2: Federated identity and encryption knowledge; cross-account controls and centralized audit design. This lesson applies the official task to an original design exercise; it is not an exhaustive exam syllabus.
Prerequisites
Review IAM evaluation, Identity Center and KMS. Be able to explain the relevant failure boundary and access/cost model before choosing a service.
Security boundaries
Federate workforce access through Identity Center and an appropriate identity provider. Workloads use scoped roles and temporary credentials. Cross-account role access requires the destination trust policy and caller permissions; third-party delegation may also require an external ID. An external ID is not a password or a substitute for restricting the trusted principal.
SCPs and permissions boundaries limit permissions; they do not grant access. Explicit denies can override an otherwise allowed request. Resource policies and KMS key policies must be included in the evaluation. Do not generalize one IAM policy type’s behavior to all principals.
Security groups are stateful allow rules; NACLs are stateless subnet rules with allow/deny and return-traffic implications. Encrypt sensitive data at rest and in transit. Distinguish AWS-managed from customer-managed KMS control, request costs and key lifecycle. ACM certificate exportability, renewal and Region depend on certificate type.
Identity and network control matrix
| Control | Applies to | Important evaluation detail |
|---|---|---|
| Identity policy | IAM user/group/role | Grants only within applicable limits |
| Resource policy | Supported resource | Principal and cross-account behavior matter |
| Role trust | AssumeRole entry | Trust is distinct from session permissions |
| Permissions boundary | Supported IAM identity | Maximum, not an independent grant |
| SCP | Member-account permission boundary | Management account and service-linked-role exceptions |
| Key policy | KMS key | Enables/delegates key access; include grants/IAM as applicable |
An IAM group is not a principal that assumes a role. Federated users and workload services can use roles. Explicit deny is decisive, but “allow beats implicit deny” is not enough to explain every cross-account/resource-policy path; use the linked evaluation lesson.
| Feature | Security group | Network ACL |
|---|---|---|
| Boundary | Supported network interfaces/resources | Subnet |
| State | Stateful response handling | Stateless; return ports must be permitted |
| Rules | Allow-only aggregation | Numbered allow/deny rules, first match |
| Appropriate use | Workload/service reachability | Subnet-level guardrails and selected explicit denies |
WAF protects supported associations, not a directly attached EC2 host. Its supported API/application resources extend beyond ALB/CloudFront. Layer-7 filtering is not a substitute for DDoS/network controls.
Encryption and finding workflow
Distinguish AWS-managed, customer-managed and imported KMS material. Customer-managed rotation is configurable for supported keys; it is not universally a fixed annual switch. Multi-Region keys have related material but independent policies and regional service behavior; replicating a key is not automatically a DR-ready application.
ACM public exportability and pricing depend on the certificate type. Imported versus issued, public versus private and integrated versus exported workflows have different renewal/deployment requirements; public ACM certificates are not universally nonexportable.
CloudTrail records selected activity; GuardDuty analyzes supported threat sources/protection plans; Inspector evaluates supported vulnerabilities; Security Hub/CSPM aggregates and assesses specified findings/posture. Enable regional/account coverage deliberately and assess runtime-agent prerequisites where applicable. A centrally visible finding does not mean all telemetry sources or remediation controls were enabled.
Scenario and rationale
An external auditor needs read-only access to security logs in a separate account for 30 days. Create a restricted role trusted to the auditor’s identified principal, with an external ID where appropriate, bounded session access and a narrowly scoped encrypted log bucket/key policy. Preserve organization-wide audit logging and revoke the delegation when the engagement ends.
Reject copied long-lived access keys: they are harder to rotate and constrain. Reject broad administrator access simply because logs span accounts. Granting S3 read alone is insufficient if the encrypted objects’ KMS permissions still deny access.
Practice drill
Write a policy-evaluation worksheet for three requests: allowed log read, denied object deletion and denied read from another bucket. List the caller identity policy, role trust, resource policy, key policy and applicable SCP/boundary. Explain each result before using policy simulation or Access Analyzer in an authorized account.
References
- Official Domain 1 task guide
- Policy evaluation logic
- External ID and confused deputy
- KMS key policies
Return to Domain 1. The drill is proposed study work, not a claim of a completed deployment.
Across the wiki
- Cloud Security Hub — cloud security posture (Security)
- GKE Security & Hardening — Workload Identity & Binary Authorization — cloud security posture (GCP)
- AWS Security — cloud security posture (Security)
- Azure Security — cloud security posture (Security)