Security
What you must know
IAM evaluation logic is the backbone: an explicit Deny always wins, then an Allow must exist from an identity-based policy, a resource-based policy, a permissions boundary, a session policy, or an SCP. SCPs and permission boundaries only filter; they never grant. Roles are assumed through STS, and a role has two policies that are easy to confuse: the trust policy (who may assume it) and the permissions policy (what the role can do).
For encryption, know KMS customer managed keys versus AWS managed keys, that a key policy must allow a principal before an IAM policy can help, and the S3 encryption options (SSE-S3, SSE-KMS, SSE-C, client side). Know Secrets Manager (native rotation, RDS integration) versus SSM Parameter Store (cheaper, SecureString, no built-in rotation). Know Cognito user pools for authentication versus identity pools for issuing temporary AWS credentials, and security groups (stateful, allow-only) versus network ACLs (stateless, allow and deny).
Traps
Believing an SCP grants access; assuming an IAM policy in the caller account is enough for cross-account access; forgetting the KMS key policy; mixing up user pools and identity pools; and granting s3:* on * instead of scoping to a bucket ARN and prefix.
Rule of thumb
Cross-account access to an encrypted resource needs three independent grants: the caller identity policy, the trust or resource policy in the owning account, and the KMS key policy. If any one is missing you get AccessDenied, so check all three before changing anything else.