Identity & Access Management

The Shared Responsibility Model splits security duties between AWS and the customer. AWS handles security “of” the cloud — physical data centers, hardware, networking, and the hypervisor. Customers handle security “in” the cloud — guest OS patches on EC2, IAM permissions, data encryption choices, and security-group rules. The boundary shifts by service type, a common exam trap. With EC2 (IaaS) the customer owns the guest OS and above; with a managed service like RDS, AWS patches the database engine, shrinking customer scope toward access rules and encryption.

AWS Identity and Access Management (IAM) controls authentication (who can sign in) and authorization (what they can do) across AWS services and resources. It uses four constructs: users (individual identities), groups (collections of users sharing permissions), roles (temporary identities assumed by services or federated users), and policies (JSON documents that allow or deny actions). The key exam distinction: users carry long-term credentials, while roles issue short-term, automatically rotated credentials. Roles are the preferred way to grant AWS services like EC2 or Lambda permission to call other APIs — safer than embedding access keys in code.

An IAM role is an AWS identity carrying permissions policies but not tied to a specific user or group. Instead, it is assumed temporarily by trusted entities — an EC2 instance, a Lambda function, an AWS service, or a user from another account — and issues short-lived Security Token Service (STS) credentials that expire automatically. The key exam distinction: roles replace static, long-lived access keys for service-to-service calls. Users have permanent credentials; roles issue temporary ones through STS. When an EC2 instance must call S3 or DynamoDB without storing credentials in code, use an instance profile backed by an IAM role.

An IAM policy is a JSON document containing statements, each with an Effect (Allow or Deny), one or more Actions such as s3:GetObject, and the Resources they apply to. Policies are identity-based (attached to a user, group, or role) or resource-based (attached to a resource, like an S3 bucket policy). Access is implicitly denied by default, so permissions must be explicitly granted. AWS managed policies are reusable pre-built documents; customer managed policies are reusable but custom-authored; inline policies embed in a single identity and are deleted with it. An explicit Deny always overrides any Allow.

Multi-Factor Authentication (MFA) adds a second identity check beyond a password, typically a time-based one-time code from a hardware device or virtual authenticator app. AWS supports MFA for IAM users and the root user, and now requires MFA for the root user across account types as part of a phased rollout. On the exam, remember scope: enabling root MFA protects the account’s most privileged identity, while MFA on individual IAM users is a strong best practice. Pairing MFA with least-privilege IAM policies illustrates defense in depth, layering multiple controls.

The root user is the original identity created when an AWS account is first opened, authenticated by the account’s email address and password rather than IAM credentials. It has unrestricted access to every service and billing setting and cannot have its own permissions reduced by any policy. Because of this, AWS recommends protecting it with a hardware or virtual MFA device immediately and then leaving it dormant for routine work.

The key exam distinction is that a handful of tasks are root-only and cannot be delegated to any IAM user or role — closing the account, changing the AWS support plan, and restoring IAM permissions are classic examples. Everyday administration should use IAM users or roles with least-privilege policies instead.

Amazon Cognito provides authentication, authorization, and user management for web and mobile apps without custom identity code. It uses two constructs: a User Pool, a managed directory handling sign-up, sign-in, and multi-factor authentication for app users, and an Identity Pool, which exchanges a token for temporary AWS credentials so users can call AWS services directly. The exam distinction is scope: Cognito governs end-user identity (customers logging into your app), while IAM governs workforce and service identity (who operates AWS resources). If a scenario describes adding login to a mobile app or federating with Google or Active Directory, the answer is Cognito, not IAM.

AWS Artifact is a self-service portal giving customers on-demand access to AWS compliance documentation, including SOC 1, SOC 2, and SOC 3 reports, PCI DSS attestations, ISO certifications, and FedRAMP authorizations. These let customers validate AWS’s control environment to their own auditors and regulators without waiting on AWS Support. The key exam distinction is that Artifact covers AWS’s side of the Shared Responsibility Model — it proves what AWS has done, not the customer. It also lets customers review and accept legal agreements such as the Business Associate Addendum (BAA) for HIPAA.