AWS Certified Cloud Practitioner (CLF-C02) #4 Domain 2-1 Security — Shared Responsibility Model and IAM Basics

With #3, Domain 1 is done. Now we enter the largest domain in the exam, accounting for 30% — Security and Compliance. This domain is split across two posts. This one covers the shared responsibility model and IAM basics; the next, #5, covers compliance and encryption.

Shared Responsibility Model #

This is the single most frequently tested concept on CLF-C02. It’s the model that captures — in a single diagram — how far AWS’s responsibility extends and where the customer’s responsibility begins.

            ┌────────────────────────────────┐
            │   Customer responsibility      │
   IN       │   ── SECURITY IN THE CLOUD ──  │
   THE      │   Customer data, platform, app │
   CLOUD    │   IAM policies, OS patch, FW   │
            │   Network / firewall configs   │
            │   Client- and server-side enc. │
            └────────────────────────────────┘
            ┌────────────────────────────────┐
            │   AWS responsibility           │
   OF       │   ── SECURITY OF THE CLOUD ──  │
   THE      │   Hardware, network, facility  │
   CLOUD    │   Host OS / hypervisor         │
            │   Global infra (Region/AZ)     │
            │   The service software itself  │
            └────────────────────────────────┘

Two key terms:

• Security OF the Cloud — AWS’s responsibility (security of the cloud itself)
• Security IN the Cloud — the customer’s responsibility (security of what’s put on the cloud)

Responsibility by area #

How responsibility shifts by service model #

Even within AWS, the scope of customer responsibility changes based on which service you use.

Summary: the more managed the service, the more AWS owns; the closer to IaaS, the more the customer owns.

What the customer always owns #

These belong to the customer regardless of which service is used.

• The data itself (classification, ownership, access rights)
• IAM user / role / policy design
• Credential management (access key rotation, MFA)
• Client-side encryption (optional but recommended where it applies)

Common exam patterns #

“Who is responsible for automatically applying OS patches?” → Customer for EC2, AWS for RDS. When both appear among the choices, decide by the service name.

“Who is responsible for encrypting data in an S3 bucket?” → The customer (enforce encryption via bucket policy, or encrypt the data itself).

“Who is responsible for defending against SQL injection in an app running on EC2?” → The customer.

“Who is responsible for the physical security of an AWS data center?” → AWS.

IAM (Identity and Access Management) #

IAM is the service that manages who (WHO) can do what (WHAT) on AWS resources. It’s a global service and is provided free of charge.

We worked through IAM hands-on in the console and CLI in Basics #2. From the certification angle, we focus on the concepts and vocabulary.

The four IAM essentials #

User #

A user created in the IAM console after sign-up. Used as a human account or a service account.

{
  "Console Login Password": "Password for console access",
  "Access Key ID + Secret Access Key": "Key pair for CLI / SDK",
  "MFA Device": "Additional authentication"
}

Group #

Used to grant the same permissions to multiple users. Example: attach an EC2 read/write policy to a “developers group” and it applies to every developer inside it.

Group constraints:

• Groups can only contain users. A group cannot contain another group.
• A group itself holds no credentials. It cannot log in.

Role #

The object people get confused by most often. It works as temporary credentials.

The key difference between roles and users:

• A user has permanent credentials. If a key is leaked, it must be revoked and reissued.
• A role works with temporary tokens. Typically valid for one hour, refreshed automatically.

When the exam asks, “How should credentials be managed for accessing S3 from EC2?”, the answer is attach an IAM role (not storing an access key on the EC2 instance).

Policy #

A JSON document that defines permissions. You don’t need to write policy JSON from scratch on the exam, but you do need to know the structure and vocabulary.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket/*"
    }
  ]
}

Kinds of policies #

Recommended preference order: AWS Managed Policy → Customer Managed Policy → Inline Policy.

Least Privilege #

The most important principle in IAM design. Grant only the minimum permissions necessary.

Anti-patterns that show up often as wrong answers:

• “Grant AdministratorAccess to every user” — always wrong
• “Use the same policy for every IAM user for convenience” — wrong
• “Grant one user all permissions and use them when needed” — wrong

Patterns that are correct answers:

• Define a role and grant it to the people who need it
• Split policies by group (developers, read-only, admins)
• Audit permissions regularly (IAM Access Analyzer)

MFA (Multi-Factor Authentication) #

A security-hardening mechanism that requires a second authentication factor on top of a password.

MFA types #

Who should MFA be enforced on #

• Root user — MFA always required (top exam frequency)
• IAM admin-level users — strongly recommended
• Any user who can log into the console — can be enforced via policy

When the exam asks, “What is the first step to harden AWS account security?” → apply MFA to the root user and create an IAM user.

Root User Guide #

The account you get right after sign-up has a root user. It holds every permission, so it’s the most protected credential there is.

Tasks only root can perform (frequent on the exam) #

Principles for using root #

• Never use it for daily work — use an IAM user
• MFA is mandatory — Hardware MFA recommended
• Don’t create access keys — delete them immediately if any exist
• Use a strong password — very complex, stored somewhere safe

Access Key Operations #

The key pair used by the CLI / SDK.

Access Key ID:     AKIAIOSFODNN7EXAMPLE
Secret Access Key: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

Operating principles #

• Never hardcode in source — pushed to git, a bot finds it within minutes
• On EC2, use IAM roles instead of access keys
• Rotate keys periodically (Access Key Rotation)
• Disable unused keys
• You can hold two at once — to rotate, create a new key → update the code → disable the old key → delete it

IAM Identity Center (formerly AWS SSO) #

A service for signing in to multiple AWS accounts and external SaaS apps with a single credential. Covered in Basics #5.

From the certification angle:

• Recommended for organizations using multiple AWS accounts
• Supports external IdP federation (Okta, Azure AD, etc.)
• Uses temporary credentials instead of IAM users

Common traps #

1) “Root is always safe, so daily use is fine” #

The most frequently tested trap. Never use root for daily work. Create an IAM user and work from there.

2) “Grant maximum permissions and trim later” #

Another common anti-pattern in answer choices. The correct answer is start with least privilege and add as needed.

3) Assuming IAM is a regional service #

IAM is a global service. When you open IAM in the console, the region selector switches to “Global”.

4) Groups inside groups #

Groups contain only users. You cannot put a group inside another group.

5) “Store an access key on EC2 so code can reach S3” #

This is an anti-pattern. The right answer is attach an IAM role to the EC2 instance.

6) Treating MFA as optional #

Root MFA is not optional. It must be applied.

7) Overuse of inline policies #

They aren’t reusable, which makes them hard to manage. Prefer customer managed policies you can attach to multiple objects.

Wrap-up #

What this post locked in:

• Shared Responsibility Model — Security OF the Cloud (AWS) vs. Security IN the Cloud (customer)
• The responsibility boundary shifts with the service model — the closer to IaaS, the more the customer owns
• Data, IAM, and credentials are always the customer’s responsibility
• Four IAM essentials — User / Group / Role / Policy
• Users have permanent credentials; roles use temporary credentials (EC2, Lambda, cross-account)
• A policy is a JSON document — Effect / Action / Resource / Condition
• Principle of least privilege — grant only the minimum required
• MFA — mandatory on root, strongly recommended on console users
• Root user — never use for daily work. MFA mandatory. Don’t create access keys
• Traps — daily root use, granting maximum permissions, assuming IAM is regional, groups inside groups, storing access keys on EC2, treating MFA as optional

Next — Domain 2-2 Compliance and Encryption #

On to the second half of Domain 2.

#5 Domain 2-2 Compliance — Governance, AWS Artifact, GDPR/HIPAA covers the kinds of AWS compliance certifications and what they mean, accessing certification documents through AWS Artifact, governance tools (CloudTrail, Config), and data encryption (at rest and in transit) along with the role of KMS.