Identity and Access Management (IAM), Organizations + Fundamentals

• EC2 access to S3 without embedded credentials → attach an IAM role to the EC2 instance profile. The instance metadata service delivers automatically-rotating temporary credentials that the SDK picks up, so no keys live in code. Storing access keys in environment variables, a credentials file, or even a KMS-encrypted file is a credential-leak anti-pattern.
• Guaranteeing an action can never run (e.g. s3:DeleteBucket) → grant broad S3 access plus a separate statement that explicitly Denies that one action. An explicit Deny always overrides any Allow, from any policy. A plain Allow, a bucket policy alone, or relying on "unlisted actions are denied" all fail because the broad Allow already covers the dangerous action.
• Policy element for permitted/denied operations → the Action element (e.g. s3:GetObject). Resource = the ARN targets, Principal = who the policy applies to, Condition = optional conditional logic.
• Cross-account S3 access → needs grants on both sides: an identity-based policy in the requester's account allowing the action, plus a resource-based bucket policy in the owner's account naming the external principal. Either grant alone is insufficient; a single Service Control Policy (SCP) only restricts, it cannot grant.
• IAM role vs IAM user → roles issue temporary credentials via Security Token Service (STS) and can be assumed by services, federated identities, or other accounts; users hold permanent long-term passwords and access keys. Roles are the recommended identity for applications and services.
• Capping delegated permissions → an IAM permissions boundary sets the maximum effective permissions an entity can have; even a broader attached policy cannot exceed it. SCPs act at the account level, not on individual users; resource-based policies and Access Advisor do not cap permissions.
• Forcing Multi-Factor Authentication (MFA) for sensitive actions → use a Deny statement with the aws:MultiFactorAuthPresent condition key. It blocks the action unless MFA is in the session, and because it is an explicit Deny it wins over any Allow. A password policy, permission boundary, or Config rule cannot enforce per-request MFA.
• Restricting EC2 to specific regions for an Organizational Unit (OU) → a Service Control Policy (SCP) attached to the OU. It applies to every principal in every member account beneath it, including root users. Per-account IAM policies are unscalable and a Config rule only detects after the fact.
• SCP behavior → SCPs are guardrails that restrict the maximum permissions; they never grant. A principal still needs an IAM Allow. Critically, SCPs do not apply to the management (root) account of the organization.
• Shared responsibility on EC2 → the customer patches the guest operating system, app code, data, and security groups ("security IN the cloud"). AWS owns the hardware, hypervisor, network, and physical security ("security OF the cloud").
• Shared responsibility on RDS → because Relational Database Service (RDS) is managed, AWS patches the database engine and underlying OS/hardware; the customer still owns data encryption choices, DB user permissions, schema design, and network access.
• "Security IN the cloud" → the customer's domain: data, applications, IAM, OS/network configuration, and client-side encryption. "Security OF the cloud" (hardware, hypervisor, facilities) is AWS's.
• Group Allow vs user explicit Deny → effective permission is no access: an explicit Deny anywhere (user, group, or role) overrides any Allow. Policy order and where the Allow lives are irrelevant.
• Compromised access key rotation → disable (not delete) the old key, issue a new key, update all apps, verify, then delete the old key. Deleting immediately breaks dependent services; a password change has no effect on access keys.
• Well-Architected pillar for recovery and meeting demand → Reliability (test recovery, auto-recover, scale horizontally). Performance Efficiency is about efficient resource use, not recovery.
• Building without guessing capacity → the Performance Efficiency pillar's "eliminate capacity guessing" principle (auto scaling, managed services). Reliability is about failure recovery; Cost Optimization is the result, not the owning pillar.
• Surviving a full data-center power loss → deploy across at least two Availability Zones (AZs) in the region; AZs are physically separate with independent power, cooling, and networking. Multiple instances in one AZ or a cluster placement group share one failure domain.
• No explicit Allow and no explicit Deny → the request is implicitly denied; IAM is deny-by-default, and only an explicit Allow grants access.
• Letting employees use existing Active Directory logins → AWS IAM Identity Center (formerly AWS Single Sign-On) with Active Directory as the identity source federates users in without creating IAM users. Mirroring AD into IAM users or sharing root credentials are anti-patterns.