Identity, Access Control and Data Protection

Security is the heaviest single domain on CLF-C02: Domain 2 carries 30% of the scored content, and its two access tasks (2.3 "Identify AWS access management capabilities" and 2.4 "Identify components and resources for security") are the most reliably tested of the whole exam. AWS's own framing starts from one uncomfortable sentence about the root user: it has "complete access to all AWS services and resources". Everything else in this lesson, MFA, roles, Identity Center, least privilege, security groups, WAF, encryption, exists to make sure that sentence never becomes an incident.

In this lesson you will:

• protect the root user: MFA device limits, the 35-day rule, no root access keys, and the tasks only root can do;
• build IAM from its four objects: users, groups, roles and policies;
• separate identity-based from resource-based policies and run the evaluation logic: explicit deny, union, ceilings, cross-account;
• choose roles versus users from the question stem: cross-account, EC2 instance profiles, federation, external ID;
• place IAM Identity Center (workforce SSO), Cognito (customer identity) and Directory Service (enterprise AD) correctly;
• pick an authentication option: passkeys/FIDO, virtual TOTP, hardware TOTP, access keys, STS temporary credentials;
• compare security groups and network ACLs on scope, rules, statefulness and defaults;
• choose between AWS WAF, Shield Standard, Shield Advanced and Firewall Manager: with real bill arithmetic;
• protect data at rest and in transit, and follow KMS envelope encryption and the three key types;
• one-line every in-scope threat-detection service and run a least-privilege checklist;
• study four AWS-published security and compliance case studies: centralised network policy, identity-based access, inherited FedRAMP controls and faster authorisation;
• track the 2026 guide and tooling updates that touch IAM, policy scope and security tooling: every bullet sourced and date-stamped;
• practise with 12 exam-style questions plus four interactive checks.

---

1. The root account: one identity, unlimited reach

1.1 What root is

There is exactly one root identity per AWS account, an email address plus a password, and AWS documents that it has "complete access to all AWS services and resources", including billing. It cannot be deleted, it cannot be restricted by an IAM policy inside its own account, and it bypasses MFA-less checks the moment it is used. This is why Domain 2 task 2.3 lists "importance of protecting the AWS root user account" as knowledge and "identifying tasks that only the account root user can perform" as a skill: the exam wants you to know both why root matters and which tasks genuinely require it.

1.2 Tasks only the root user can perform

The list is short, memorable and examinable; these are the answers to "which action requires the root user?":

• changing the account email, password or access keys for the root identity itself (standalone accounts);
• closing or reopening a standalone account;
• restoring IAM user permissions: the last-administrator lockout recovery;
• activating IAM access to the billing console;
• viewing certain tax invoices;
• registering for the EC2 Reserved Instances Marketplace;
• enabling S3 MFA Delete;
• editing or deleting an S3 or SQS resource policy that denies all principals;
• GovCloud signup and root keys; linking an Amazon Mechanical Turk account.

Everything else on the exam, creating IAM users, attaching policies, starting EC2, writing bucket policies, resetting a colleague's password, is done by an administrative identity, never by root.

1.3 Example E1: day-1 root hardening, step by step

A new production account is opened. The hardening sequence below uses only verified limits:

• 📚 Did you know? AWS's root-user best-practice page recommends multi-person approval for root: one group holds the account password, a different group holds the MFA device, so no single employee can act as root alone. The same page caps MFA at eight devices per root user and tells you to register root MFA within 35 days of first sign-in: two numbers the exam likes to quote back at you (as of Oct 2026; verify current before use).

---

2. IAM building blocks: users, groups, roles and policies

2.1 The four objects, exactly

A role has two halves and both are mandatory: the permissions policy answers what may the session do, the trust policy (a resource-based policy attached to the role) answers who may assume it. A perfectly written permissions policy with a trust policy that names nobody is useless; it is a locked door with a sign reading "employees only" and no employees listed on it.

2.2 Identity-based versus resource-based policies

AWS managed policies are broad, AWS-maintained starting points (job functions such as read-only administration). Customer managed policies are the ones you write and refine: the least-privilege end state. Inline policies are embedded in a principal and are deleted with it, which makes them useful for one-shot permissions and dangerous as a default.

2.3 How AWS evaluates a request: explicit deny wins

AWS's documented order, compressed to the four moves that appear on the exam:

1. Authenticate the caller (who is this?).
2. Gather every applicable policy: identity-based and resource-based, plus SCPs, RCPs, permissions boundaries and session policies.
3. Any explicit Deny anywhere wins. AWS "first checks all policies for a Deny": one deny, in any applicable document, beats every allow.
4. Otherwise compute the union of identity-based and resource-based allows, then intersect it with the ceiling: permissions boundaries, SCPs and RCPs must all allow (an intersection). SCPs grant nothing; they only filter what an identity inside the account could otherwise do.

2.4 Example E2: effective permissions for John (three layers)

John's identity policy allows s3:Get* on reports/*. The reports bucket policy says Deny s3:* when aws:SecureTransport is false. The account's SCP says Deny s3:* outside the home Region.

Count the layers: one allow, two denies, three policy types, and read the direction of each request before choosing. Note what would happen if the identity policy were removed: (a) becomes an implicit deny, so removing a grant is a real mitigation, not a formality.

2.5 Permissions boundaries and the least-privilege tooling

A permissions boundary is a managed policy that sets the maximum an identity policy may grant. It grants nothing by itself: its exam use case is safe delegation: let a developer write their own identity policy, but cap it with a boundary so they can never exceed, say, read-only plus a sandbox bucket. The narrowing toolkit for least privilege is:

• start from an AWS managed job-function policy;

• refine with IAM Access Analyzer (generates policies from CloudTrail activity, validates external/public access, previews cross-account exposure);

• check last accessed information to delete permissions nobody uses.

• 📚 Did you know? A group cannot be used as a Principal in any AWS policy; you attach a policy to a group, but you can never allow a group in a bucket policy or role trust policy; you must name its users or, better, a role. Groups also cannot be nested, and there is no default user group in IAM (as of Oct 2026).

---

3. Roles versus users: the decision the exam repeats

3.1 The use-case table

Session arithmetic worth memorising: AssumeRole sessions last up to 43,200 seconds = 12 hours, while role chaining (assuming a second role from a first) is capped at 1 hour: a 12× difference. During a session the role's permissions replace the caller's for the duration.

3.2 Example E3: the cross-account audit role

An auditor in account 1111 needs read-only access to account 2222. Two documents, both mandatory:

Either policy alone fails: trust without an identity grant gives "you are not authorized"; an identity grant without trust gives "not authorized to perform sts:AssumeRole". The session is temporary (1-hour default, up to 12 hours): nothing to leak, nothing to rotate, and access disappears when the role's trust is revoked.

3.3 Example E4: the EC2 instance profile, zero shipped keys

An application on EC2 must read s3://photos. Instead of copying an access key into the AMI:

1. Create role Get-pics whose trust policy allows the service ec2.amazonaws.com.
2. Attach a permissions policy allowing s3:GetObject on that bucket only.
3. Attach the role to the instance through an instance profile.
4. The SDK reads temporary credentials from the instance metadata service and refreshes them before expiry: the developer never sees a secret.

If the instance is compromised, the attacker inherits exactly one permission on exactly one bucket: the blast radius is the policy document, not the company's AWS account. Contrast the IAM-user answer: an access key baked into an AMI is a credential with no expiry, no scope boundary beyond its policy, and a habit the exam marks wrong.

• 📚 Did you know? Role chaining deserves its own mnemonic: 12 hours for a single AssumeRole, 1 hour for a chained one (43,200 s vs 3,600 s, as of Oct 2026). AWS caps chaining precisely because each hop multiplies the chance that a stale session outlives the person who started it.

---

4. IAM Identity Center: the workforce answer

AWS Single Sign-On was renamed AWS IAM Identity Center on 26 July 2022, and the exam still rewards you for knowing both names. Identity Center is AWS's workforce single sign-on: employees get one login that opens many AWS accounts and AWS applications, with permissions delivered through permission sets - AWS's named bundle of permissions applied to a user or group, with no long-term keys.

The pattern to memorise: 12 accounts, one login, no IAM users → IAM Identity Center. AWS's own best-practice wording is "Require human users to use federation" and prefer "phishing-resistant MFA such as passkeys and security keys": Identity Center is how that recommendation scales past a handful of accounts.

---

5. Amazon Cognito: customer identity at exam depth

Cognito is the customer identity (CIAM) option, and AWS describes it as three things in one service: "a user directory, an authentication server, and an authorization service". It sits at a different altitude from IAM: your application's users are not IAM users and never see the AWS console.

Exam depth stops exactly there: know that user pools authenticate, identity pools authorise AWS access, that the AWS credentials are temporary, and that Cognito is for customers while IAM Identity Center is for workforce. Deeper topics (hosted UI customization, lambda triggers, advanced security features) are not what a practitioner question asks for.

---

6. Authentication options and MFA

6.1 The five ways to prove who you are

AWS's best-practice wording to recognise: "Require human users to use federation" and use "phishing-resistant MFA such as passkeys and security keys". The trap option recommends SMS MFA: AWS ended support for enabling SMS multi-factor authentication in IAM, so any answer that says "enable SMS MFA on the root user" is wrong.

⚠️ Two credential numbers, two traps. First, SMS MFA is not an IAM option: the supported factors are passkeys/FIDO security keys (phishing-resistant and recommended), virtual authenticator (TOTP) and hardware TOTP, so "secure the root user with an SMS code" is always wrong, even though a Cognito user pool may still send SMS codes to your application's users. Second, two is the ceiling for access keys per IAM user and zero is the recommendation for root; a "fix" that mints a third key, or a root access key "just for this script", answers the wrong question.

6.2 Where secrets live

Task 2.3 explicitly names credential storage: AWS Secrets Manager and AWS Systems Manager Parameter Store (SecureString). Hard-coded keys in a repository, in an AMI or in environment variables of a public Lambda are the anti-pattern the exam tests by inversion: the correct answer always retrieves a secret at runtime from one of those two services, or avoids the secret entirely by using a role.

6.3 Example E5: counting the credentials in one account

A single-account setup has: root (0 access keys), 6 IAM users each with 2 access keys, 10 roles, 3 permission sets in Identity Center.

The audit question writes itself: 12 long-lived secrets exist and only 2 people need them. The remediation is not "add MFA"; it is to replace the users with Identity Center groups and roles, delete the unused keys, and keep the remaining pairs on a rotation schedule.

• 📚 Did you know? The two-access-keys-per-user ceiling is deliberate: key one while key two is still live lets you rotate without downtime (update the application, then delete the old key). AWS shows the secret exactly once: after that, the only recovery is creating a new key pair, which is why "view the old secret key again" is never a valid option.

---

7. Security groups versus network ACLs

Both are the VPC's packet filters, both are free of charge (as of Oct 2026), and they differ on four axes the exam tests relentlessly.

Two consequences follow directly from the state column: with a stateful security group you open 443 inbound and the replies flow back automatically; with a stateless NACL you must also allow the ephemeral return ports inbound, or the connection never completes. And neither device filters DNS, DHCP, the instance metadata service, ECS task metadata or Time Sync; those bypass them by design.

7.1 Defaults are not "secure"

• The default security group allows all outbound and inbound only from itself: usable, not secure.
• The default network ACL allows all traffic in and out, plus * DENY rules that always sit at the bottom of the list: permissive by default, with the deny catch-all available for a quick block.

Neither default is an answer to "how do I restrict this", and "add a deny rule to the security group" is always wrong: security groups have no deny rules: use a NACL, or deny at the IAM/bucket-policy layer.

7.2 Example E6: layered network defence

An internet-facing three-tier application, assembled from verified behaviour:

The mental model: NACL = the subnet's bouncer with a blacklist; security group = the instance's firewall with only a guest list; WAF = the application-layer inspector; Shield = the anti-DDoS umbrella.

• 📚 Did you know? Security group rules can reference other security groups, which is how the tiered pattern above works without hard-coding CIDR blocks, and it is why moving an application tier to a new subnet requires no rule edits at all. Network ACLs, by contrast, are subnet-bound and IP-based by nature (as of Oct 2026; per-VPC and per-SG quotas apply, verify current before use).

---

8. AWS WAF, AWS Shield and AWS Firewall Manager

Three services, three altitudes. Confusing them costs multiple questions, because each has a one-sentence identity:

WAF capacity is measured in Web ACL Capacity Units (WCUs); rules may be custom, AWS Managed Rules, or Marketplace rule groups, plus IP set/regex set and rate-based rules. Shield Advanced also bundles up to 50 billion WAF requests per month per payer ID and DDoS cost protection (reimbursement of scaling charges caused by an attack).

8.1 Example E7: the WAF bill

AWS publishes its own worked example, and the arithmetic generalises:

Notice what does not appear in the bill: security groups and network ACLs are free, so "add a security group rule" is the cost answer when the question is about filtering traffic that never reaches an HTTP rule set.

8.2 Example E8: Shield Advanced arithmetic

The phrasing test is reliable: "free, automatic DDoS protection" → Shield Standard; "stop SQL injection on this ALB" → WAF; "apply this rule set to every account in the organization" → Firewall Manager.

---

9. Data protection: at rest, in transit, and KMS

9.1 The two directions

S3 encryption choices at exam depth: SSE-S3 (default, free), SSE-KMS (per-request charges, plus a per-use audit trail in CloudTrail), DSSE-KMS (dual layer), SSE-C (you supply the key), and client-side encryption. Enforce transit with a bucket policy or an SCP that denies aws:SecureTransport = false: the deny from §2.4, applied to data protection.

9.2 KMS: keys, and envelope encryption

AWS Key Management Service keeps keys inside FIPS 140-3 Security Level 3 validated hardware security modules (HSMs): the keys are generated there and never leave that boundary unencrypted. Because calling the HSM for every byte would be absurd, KMS uses envelope encryption: "encrypting the data key under another key".

Rotating the key never re-encrypts your bulk data: the root key only re-wraps the data key, which is the practical reason envelope encryption exists.

9.3 Example E9: envelope encryption on a 1 GB object

1. Your application calls KMS GenerateDataKey with a customer managed key. KMS returns a plaintext data key and the same key encrypted under the KMS key.
2. The application encrypts the 1 GB object with the plaintext data key in memory; the plaintext key is discarded.
3. The wrapped data key is stored alongside the ciphertext. KMS never sees the object; the HSM never exports the root key.
4. To read the object later, the application sends only the wrapped key back to KMS (Decrypt), receives the plaintext key, and decrypts locally.
5. If you rotate the KMS key tomorrow, only step 4's wrapping changes: the 1 GB object is untouched.

• 📚 Did you know? AWS managed KMS keys now rotate about every 365 days, a change made in May 2022, when the interval shortened from three years, and carry no monthly key fee (usage fees still apply, as of Oct 2026). The customer managed key is the only type that gives you key-policy control, enable/disable, scheduled deletion and custom rotation, which is why "which key gives me full control" almost always means customer managed, not "the one I created" versus "AWS created".

---

10. Threat detection, audit and posture: in-scope one-liners

Domain 2 task 2.4 asks you to describe security features and to identify "services for identifying security issues". Every row below is on the CLF-C02 in-scope list or in a Domain 2 task statement: nothing else.

Mnemonic:

• GuardDuty detects
• Inspector scans
• Macie finds sensitive data
• Detective explains
• Security Hub aggregates
• Trusted Advisor advises
• CloudTrail records
• Config remembers
• Artifact certifies

• 📚 Did you know? CloudTrail Event history is free and automatic for the past 90 days of management events in every account; you do not have to create a trail to answer "who terminated my instance last month". A trail to a private S3 bucket with log-file validation is the upgrade that gives you the full, tamper-evident record the best-practice checklist demands (as of Oct 2026).

---

11. The least-privilege best-practice checklist

11.1 Five groups of habits

11.2 Example E10: scoring an account against the checklist

---

Real-World Case Studies

AWS publishes what these patterns look like in production. Every figure below is customer- or AWS-claimed and unaudited, quoted with its source so you can check it: the examinable point is the pattern (which control was centralised, which identity model replaced which, which number moved), not the marketing figure.

Case A, athenahealth: centralised network security across 120 accounts

Exam lesson: the number to remember is not 95%, it is 120 accounts and eight people. Domain 2's answer to "how do you enforce a control everywhere" is always centralise the policy and share it (RAM, Firewall Manager, SCPs, an organisation CloudTrail), never "log into each account". Note that AWS Network Firewall is out of scope for CLF-C02 service-selection questions in the current guide, know the centralisation pattern, select the in-scope service.

Case B, Avalon Healthcare Solutions: identity-based access instead of VPN

Exam lesson: this is the Zero Trust shape Domain 2 rewards: verify the identity, grant narrowly, and stop treating the network as the boundary. AWS Verified Access is not on the CLF-C02 in-scope security list, so it appears only as a distractor: the in-scope selections for this pattern are IAM Identity Center (workforce federation), Cognito (customer identity) and cross-account IAM roles.

Case C, Smartsheet Gov: FedRAMP ready in under 90 days

Exam lesson: the number to hold is <90 days versus 12 to 18 months: an evidence story, not a service-selection story. FedRAMP is a government authorisation, not an AWS product: AWS supplies GovCloud (US) and the inherited controls, the customer gets the ATO. When a question asks where the audit paperwork comes from, the in-scope answer is AWS Artifact; when it asks who patches the hypervisor, the answer is the shared responsibility model.

Case D, Socure: 46+ FedRAMP controls inherited from GovCloud

Exam lesson: 46 inherited, zero delegated. Inherited controls are the whole argument for the shared responsibility model: AWS covers the platform, you still own identity, least privilege, encryption and configuration. The examinable selections behind this paragraph are KMS, CloudTrail, Config, GuardDuty, Security Hub, IAM and AWS Artifact for the evidence itself: not the complementary tools named in the blog.

• 📚 Did you know? Inheritance cuts both ways in these two stories: Smartsheet Gov reached FedRAMP ready in under 90 days where AWS says the process can run 12 to 18 months, and Socure counted 46+ inherited FedRAMP controls, yet both still owned their own IAM, keys and configuration. That is precisely why the shared responsibility model has two columns, and why "AWS handles security, so I skip MFA" is never the answer (AWS Public Sector Blog, 29 Aug 2019 and 14 Nov 2024; figures customer-published).

What the security cases share

2026 Updates (as of October 2026)

• 📚 Did you know? The current exam guide PDF carries no version number at all, only "Copyright © 2026", while the only stamped artefact AWS ever published is the launch-era Version 1.0 CLF-C02 guide. The uiVersion=2024.10 string visible in AWS Docs URLs is the documentation site template version, not a guide revision, and the in-scope page warns that its list is "non-exhaustive and subject to change" (all three checked 2026-10).

---

Practice Questions