Module 5: Identity and Access Management (IAM) and Security Services

Step 1 – Why IAM and Security Services Matter for CLF-C02

In the last module, you learned the Shared Responsibility Model: AWS secures the cloud, customers secure what they run in the cloud.

This module focuses on how you secure access and monitor security in AWS, which is a high‑weight area on the CLF‑C02 (current Cloud Practitioner exam as of early 2026).

In 15 minutes, you’ll learn to:

• Distinguish IAM users, groups, roles, and policies
• Explain why MFA and careful use of access keys are essential
• Match common AWS security services to basic scenarios:
• KMS – encryption and key management
• AWS WAF – web application firewall
• AWS Shield – DDoS protection
• Amazon GuardDuty – threat detection
• AWS CloudTrail – logging API activity
• AWS Security Hub – central security view

Keep the Well‑Architected Security Pillar in mind: identity, detection, infrastructure protection, data protection, and incident response. IAM and these services are core tools for implementing those principles.

Step 2 – IAM Users, Groups, Roles, and Policies (Big Picture)

Think of AWS Identity and Access Management (IAM) as the gatekeeper for everything in your AWS account.

Core building blocks:

• IAM User – A digital identity representing a person or application that needs long‑term access.
• IAM Group – A collection of users that share permissions.
• IAM Role – An identity that you assume temporarily to get specific permissions.
• IAM Policy – A JSON document that defines what is allowed or denied.

A simple mental model:

• User: "Who are you?" (long‑term identity)
• Role: "What job are you doing right now?" (temporary identity)
• Policy: "What are you allowed to do?" (permissions)
• Group: "Which team are you on?" (shared permissions)

For CLF‑C02, you won’t be asked to write complex JSON, but you must recognize these terms and choose the right one in a scenario.

Visual description:

> Imagine a company building:

> - Employees (users) wear ID badges.

> - Teams (groups) like "Developers" or "Finance" get shared access to certain floors.

> - Temporary visitor passes (roles) are given to contractors for specific tasks.

> - The building access rules (policies) define which badge can open which doors.

Step 3 – Matching Users, Groups, and Roles to Real Scenarios

Use these short scenarios to solidify when to use each IAM concept.

Scenario 1 – New Developer Joins

• A new hire, Alex, joins your company as a backend developer.
• Alex needs to log in to the AWS Management Console and work with EC2 and S3.

What do you use?

• Create an IAM user for Alex.
• Add Alex to the Developers group, which already has a policy like `AmazonEC2ReadOnlyAccess` and permissions to a specific S3 bucket.

Why not a role? Because Alex is a human needing long‑term access.

---

Scenario 2 – EC2 Instance Needs S3 Access

• You have an EC2 instance running an app that needs to read images from an S3 bucket.

What do you use?

• Create an IAM role for EC2 with a policy that allows `s3:GetObject` on that bucket.
• Attach that role to the EC2 instance.

No access keys are needed in code; the instance assumes the role automatically.

---

Scenario 3 – Short‑Term Admin Access

• A support engineer needs temporary admin access to fix a production issue.

What do you use?

• The engineer signs in with their IAM user.
• They then assume an IAM role (for example, `AdminRole`) that gives elevated permissions for a limited time.

This is safer than giving permanent admin permissions to the user.

Step 4 – Quick Thought Exercise: Pick the Right IAM Concept

For each mini‑scenario, decide: User, Group, Role, or Policy? (You can write your answers down or say them aloud.)

1. You want to give the same S3 read‑only permissions to 20 existing IAM users.
2. You need a way for a Lambda function to write logs to CloudWatch.
3. You want to define that `john-dev` can only list and read objects from a specific S3 bucket.
4. You want to grant a third‑party auditing company temporary access to review your account.

Scroll down for suggested answers.

---

Suggested answers (check yourself):

1. Group – Put users in a group that has the S3 read‑only policy.
2. Role – A role for Lambda with permissions to write to CloudWatch.
3. Policy – Attach a policy with `s3:ListBucket` and `s3:GetObject` to John’s user or group.
4. Role – Create a role that the external auditor can assume, with limited permissions.

Step 5 – MFA, Access Keys, and Root User Best Practices

At the CLF‑C02 level, you must understand how identities authenticate and why MFA is strongly recommended.

Root user vs IAM users

• Root user: The email/account used when the AWS account was first created.
• Has unrestricted access to everything.
• Should be used very rarely (e.g., account‑level settings, closing the account).
• IAM users: Day‑to‑day identities for people and applications.

Best practice: Secure root with MFA, then stop using it for daily work.

MFA (Multi‑Factor Authentication)

• Adds a second factor in addition to your password.
• Common MFA methods:
• Virtual authenticators (e.g., Google Authenticator, Authy)
• Hardware keys (e.g., FIDO2 security keys)
• Greatly reduces risk if a password is stolen.

> For the exam: If a scenario mentions protecting the AWS account from compromised passwords, especially for root or admins, the best answer is usually enable MFA.

Access keys (for programmatic access)

• Access key ID + secret access key = credentials for CLI/SDK.
• Belong to an IAM user or are provided by roles behind the scenes.

Best practices you should recognize:

• Avoid long‑term access keys when you can use roles (e.g., for EC2, Lambda).
• Never hard‑code keys in code or commit them to GitHub.
• Rotate or delete unused access keys.

Exam‑style takeaway: If a developer accidentally uploads access keys to a public repo, the immediate response is to disable/delete the keys and create new ones (or move to roles).

Step 6 – Overview of Key AWS Security Services

Now connect IAM to other core security services you must recognize for CLF‑C02. Think of these as different layers of protection.

1. AWS KMS (Key Management Service)

• Manages encryption keys used to protect data at rest and in transit.
• Common use cases:
• Encrypting S3 objects, EBS volumes, RDS databases.
• Encrypting application secrets.

2. AWS WAF (Web Application Firewall)

• Protects web applications from common attacks (e.g., SQL injection, XSS).
• Works with CloudFront, Application Load Balancer, and API Gateway.

3. AWS Shield

• DDoS protection service.
• Two tiers:
• Shield Standard – Automatically included at no extra cost for most AWS services.
• Shield Advanced – Paid tier with enhanced detection and support.

4. Amazon GuardDuty

• Threat detection service.
• Uses machine learning and threat intelligence to detect suspicious activity in:
• AWS CloudTrail logs
• VPC Flow Logs
• DNS logs

5. AWS CloudTrail

• Logs who did what, when, and from where in your AWS account.
• Tracks API calls and console actions.

6. AWS Security Hub

• Central dashboard that aggregates findings from:
• GuardDuty
• AWS Config
• Inspector, Macie, and others
• Helps you see your overall security posture and compliance against standards.

Link back to Well‑Architected Security Pillar:

• Identity & access: IAM, MFA
• Detection: GuardDuty, CloudTrail, Security Hub
• Infrastructure & app protection: WAF, Shield
• Data protection: KMS

Your exam task is to match each service to its purpose in simple scenarios.

Step 7 – Match the Security Service to the Problem

Try to solve these matching questions before looking at the answers.

Problem A: You need to know which IAM user deleted an S3 bucket yesterday.

Problem B: Your web app is receiving a huge spike in traffic that looks like a DDoS attack.

Problem C: You want to encrypt data stored in an S3 bucket using AWS‑managed keys.

Problem D: You want a single place to see security alerts from GuardDuty and other services.

Problem E: Your API is being probed with SQL injection attempts.

Options: KMS, WAF, Shield, GuardDuty, CloudTrail, Security Hub

---

Suggested answers:

• Problem A → CloudTrail (who did what, when)
• Problem B → Shield (DDoS protection; Shield Standard is automatic)
• Problem C → KMS (manage encryption keys for S3)
• Problem D → Security Hub (central security view)
• Problem E → WAF (block SQL injection and other web exploits)

Step 8 – IAM Concepts Quiz

Test your understanding of IAM basics.

Step 9 – Security Services Quiz

Check that you can map services to scenarios.

Step 10 – Flashcard Review of Key Terms

Flip through these cards (mentally or by writing them out) to reinforce key CLF‑C02 concepts from this module.