Design Secure Architectures

Think of AWS security as three independent layers, each answering a different question. Identity decides who can do what — that's IAM policies and SCPs. Network decides where traffic is allowed to flow — security groups, NACLs, and VPC design. Data decides what can be read and what's allowed to leave — KMS encryption, resource policies, and VPC endpoints. A correct answer puts the right control at the right layer, and the classic trap is a question that offers a network fix for an identity problem, or the other way around.

IAM starts from default-deny: a request only succeeds when something explicitly allows it and nothing explicitly denies it. And an explicit Deny always wins — place one in any policy (identity, resource, SCP, or permission boundary) and it overrides every Allow. Keep in mind that SCPs and permission boundaries are ceilings: they cap what's possible but never grant a permission on their own. An SCP can still contain Allow statements, but those set the guardrail rather than granting access — so an action left off the guardrail is implicitly denied. That gives three reasons a principal whose identity policy allows an action can still be blocked: an explicit Deny anywhere; the action falling outside an applicable SCP's allow-list (an implicit deny); or a permission boundary that doesn't include it.

Workloads should get their credentials from a role, never from a stored access key — that means EC2 instance profiles, Lambda execution roles, ECS task roles, EKS IRSA, and OIDC federation for CI/CD. People should federate through IAM Identity Center rather than each getting a per-user IAM user. And when a long-lived secret really is unavoidable, such as a database password or a third-party API key, the answer is Secrets Manager with automatic rotation — not a hardcoded value or a plaintext parameter.