🔑Exam Guide: Cloud Practitioner
Domain 2: Security & Compliance
📘Task Statement 2.3
🎯 What Is This Task Testing?
This objective checks whether you understand how AWS manages identities and permissions, including:
- IAM basics (users, groups, roles, policies)
- Why and how to protect the root user
- The principle of least privilege
- IAM Identity Center (AWS Single Sign-On) and federated access
- Credentials: access keys, password policies, and secure storage (Secrets Manager / Systems Manager)
1) 🧠 IAM Basics
Who You Are vs What You Can Do
In AWS:
- An identity (user/role) answers: “Who is making the request?”
- A policy answers: “What are they allowed to do?”
Core IAM components
- IAM Users: individual identities (often for people).
- IAM Groups: collections of users with shared permissions.
- IAM Roles: identities assumed temporarily (recommended for AWS services, cross-account access, and federation).
- IAM Policies: permission documents (JSON) that allow/deny actions on resources.
Prefer roles + temporary credentials over long-lived credentials whenever possible.
2) 🛡️ Principle of Least Privilege
Least privilege means granting only the permissions required to perform a task—nothing more.
- Use narrow permissions (specific actions + specific resources)
- Avoid using
"*"for actions/resources unless required - Assign permissions to groups/roles, not directly to many users (easier governance)
- Use managed policies where appropriate, but prefer custom policies when you need tighter control
3) 📄 Policies
Managed vs Custom
AWS Managed Policies
- Created and maintained by AWS
- Useful for common job roles and quick starts
- Might be broader than necessary
Customer Managed Policies (Custom)
- Created and maintained by you
- Best when you must enforce strict least privilege
- Reusable across users/roles/accounts
Inline Policies
- Attached to a single user/group/role
- Harder to manage at scale (use with care)
4) ✅ Authentication Methods in AWS
You should recognize common ways users and systems authenticate:
- Username/password: IAM user sign-in to AWS console
- Access keys: programmatic access via CLI/SDK, should be protected and rotated
- Multi-factor authentication (MFA): strongly recommended, especially for privileged users
- IAM Identity Center (AWS SSO): centralized workforce access, typically backed by an identity provider
- Cross-account IAM roles: secure access across AWS accounts without sharing long-term credentials
- Federated access: external identity provider signs users in; AWS issues temporary credentials
5) 🏢 IAM Identity Center
AWS Single Sign-On
IAM Identity Center provides centralized access management for workforce users:
- One place to assign access to AWS accounts and applications
- Supports SSO and typically integrates with external identity providers (federation)
- Helps reduce the need for many separate IAM users in each account
6) Access Keys, Password Policies, and Credential Storage 🔐
Access keys
- Used for programmatic access (CLI/SDK)
- Should be treated like passwords (never hard-code in code repositories)
- Best practice is to prefer roles and temporary credentials when possible
Password policies (for IAM users)
Password policies can enforce:
- minimum length
- complexity requirements
- rotation/expiration
- preventing password reuse
Credential storage (don’t store secrets in code)
- AWS Secrets Manager: purpose-built for managing secrets (credentials, API keys) and can support rotation workflows.
- AWS Systems Manager Parameter Store: stores configuration and secrets (often used for parameters; can store secure strings).
“Where should we store database passwords securely?” → Secrets Manager
Parameter Store is also valid in many scenarios depending on wording.
7) ⚠️ Root User
Why It Matters and What Only Root Can Do
The root user has full, unrestricted access to the account. It should be used only for tasks that require it.
Tasks that commonly require the root user
- Changing the account’s email address or certain account settings
- Managing root-level security settings (e.g., some billing/ownership functions)
- Closing the AWS account
- Certain billing and payment configuration actions
root is for rare, account-level administrative tasks.
8) 🛡️ Root User Protection Methods
You should know best practices for protecting root:
- Enable MFA on the root user
- Do not use root for daily administration
- Create admin access for humans via IAM users/roles or IAM Identity Center
- Secure root credentials:
- strong password
- store credentials securely
- Use monitoring and detection (e.g., alerts on root activity) if mentioned
“How do you best protect the root account?” → Enable MFA and avoid routine use.
9) 🔄 Federated Identity
Very common in enterprises
Users authenticate with an external identity provider (IdP), then receive access to AWS—often via:
- IAM Identity Center
- assumed roles (temporary credentials)
Why it matters: Federation reduces password sprawl and avoids creating lots of IAM users for employees.
Quick Exam-Style Summary ✅
- IAM controls access using identities (users/groups/roles) + policies.
- Apply least privilege: only required actions, only required resources.
- Roles + temporary credentials are preferred over long-lived access keys.
- IAM Identity Center (SSO) supports centralized, federated workforce access.
- Store secrets in AWS Secrets Manager (or Parameter Store when appropriate), not in code.
- Root user is powerful and should be protected with MFA and used only when necessary.
Top comments (0)