Multi-Cloud Security Curriculum · Module 02

Identity & Access Management in Cloud

RBAC/ABAC/PBAC, MFA, Conditional Access, Zero Trust, PAM, Identity Federation — ~60 min interview prep aligned to the curriculum.

Interview Q&As

MCQ Questions

Simulations

Module Duration

Topics Covered

Topic	Type
RBAC vs ABAC vs PBAC	Reading
MFA & Conditional Access	Reading
Zero Trust & PAM	Reading
Identity Federation — SSO, SAML, OAuth 2.0, OIDC	Reading
IAM Misconfigurations & Real Breaches	Reading
Interview Q&A (20 questions)	Q&A
MCQ Quiz (25 questions)	Quiz
4 Interactive Simulations	Simulation

💡 Resources: Microsoft Entra ID Documentation · Google Cloud IAM Docs · ISACA Identity & Access Management Framework · AWS IAM Best Practices

Core Concepts · ~10 min

IAM in Cloud Environments

Access Control Models

Model	How it works	Cloud Example	Granularity
RBAC (Role-Based)	Access granted based on job role	AWS IAM Roles, Azure RBAC built-in roles	Medium
ABAC (Attribute-Based)	Access based on attributes (department, classification, location)	AWS tag-based IAM conditions, Azure ABAC	High
PBAC (Policy-Based)	Explicit policy statements (allow/deny per action/resource)	AWS IAM JSON policies, GCP IAM conditions	Very High

MFA Methods — Strength Comparison

Method	Factor Type	Strength	Weakness
Hardware Key (FIDO2/YubiKey)	Something you have (physical)	⭐⭐⭐⭐⭐ Strongest	Can be lost/stolen physically
TOTP App (Authenticator)	Something you have (TOTP)	⭐⭐⭐⭐	Phishable via real-time relay
Push Notification (Duo)	Something you have (device)	⭐⭐⭐	MFA fatigue attacks (prompt bombing)
Email OTP	Something you have (email)	⭐⭐	Email account may be compromised
SMS OTP	Something you have (phone)	⭐ Weakest	SIM swapping, SS7 interception

Identity Federation Protocols

Protocol	Type	Token Format	Use Case
SAML 2.0	Authentication + Authorization	XML assertions	Enterprise SSO (ADFS → AWS/Azure)
OAuth 2.0	Authorization only	Access tokens (opaque/JWT)	Delegated access (social login, API access)
OIDC	Authentication (built on OAuth 2.0)	JWT ID tokens	Web/mobile login, user identity
AWS STS	Temporary credential issuance	Short-lived keys + session token	Cross-account role assumption
SCIM	User provisioning/sync	JSON REST API	Sync AD users to cloud apps

PAM — Privileged Access Management

PAM controls and monitors access to privileged accounts (admin, root, service accounts).

Concept	Description	Cloud Implementation
Just-in-Time (JIT)	Temporary privilege elevation only when needed	Azure PIM, AWS IAM Identity Center
Least Privilege	Minimum permissions for the task	AWS IAM Access Analyzer, GCP Recommender
Session Recording	Record all privileged sessions for audit	AWS Session Manager, CyberArk
Break-Glass Account	Emergency access account used only in crisis	Azure Emergency Access Account
Credential Vaulting	Securely store and rotate privileged credentials	HashiCorp Vault, AWS Secrets Manager

Top IAM Misconfigurations & Real Breaches

Misconfiguration	Risk	Real Example
Root account without MFA	Complete account takeover	Multiple AWS account breaches
Wildcard IAM policy (Action:, Resource:)	Full access to everything	Common in dev accounts
Hardcoded credentials in code	Credential exposure via GitHub	Uber breach (2022) — hardcoded AWS keys
SSRF → IAM metadata	Steal EC2 IAM role credentials	Capital One breach (2019)
Long-lived API keys (no rotation)	Persistent attacker access	Tesla cryptojacking (2018)
Overprivileged service accounts	Lateral movement post-compromise	GCP project-wide Owner service accounts

Interview Q&A · 20 Questions

Interview Questions & Model Answers

Click to expand. Difficulty: Easy Medium Hard

1What is the difference between RBAC, ABAC, and PBAC?Medium▼

RBAC (Role-Based Access Control): Access is determined by the user's role (job title/function). Simple to manage but coarse-grained. Example: "All DevOps engineers have access to production deployments." AWS IAM Roles, Azure built-in RBAC roles.
ABAC (Attribute-Based Access Control): Access decisions based on attributes of the user, resource, and environment. More granular. Example: "Users in the Finance department can access documents tagged Classification=Financial in business hours." AWS tag-based conditions, Azure ABAC.
PBAC (Policy-Based Access Control): Access controlled by explicit policy statements defining allowed/denied actions on specific resources. Extremely granular. Example: AWS IAM JSON policies allowing s3:GetObject on a specific bucket ARN.

💡 Most cloud IAM systems use a combination: RBAC for broad role assignment, ABAC for attribute-based conditions, PBAC for fine-grained resource-level controls. AWS IAM is primarily PBAC with RBAC-like roles.

2How does MFA work in cloud environments? What are the strongest MFA methods?Easy▼

MFA requires two or more independent factors. In cloud: users authenticate with password (something you know) + a second factor. Cloud MFA enforcement mechanisms:

AWS: IAM policies with MFA conditions (aws:MultiFactorAuthPresent), AWS Organizations SCPs mandating MFA
Azure: Conditional Access policies requiring MFA for privileged roles or risky sign-ins
GCP: OS Login 2FA, Cloud Identity MFA policies

Strongest to weakest:

FIDO2 Hardware Key (YubiKey) — phishing-resistant
TOTP Authenticator App (Google Authenticator, Authy)
Push Notification (Microsoft Authenticator, Duo)
Email OTP
SMS OTP — most susceptible to SIM swapping

💡 Microsoft recommends deploying passwordless MFA (FIDO2 + biometric) to eliminate the password entirely — "the best password is no password."

3What is Conditional Access and how does it work in Azure?Medium▼

Azure Conditional Access is a Zero Trust policy engine that makes access decisions based on signals — who is accessing, what are they accessing, from where, and under what conditions. It works as: Signal → Decision → Enforcement.

Common signals:

User identity and group membership
Device compliance (Intune-managed, domain-joined)
Location (IP address, named location, country)
Application being accessed
Sign-in risk (Microsoft Entra ID Protection ML risk score)

Example policy: "If user is in the Finance group AND is accessing the Finance app AND device is not Intune-compliant → Require MFA AND block download."

💡 Conditional Access is the control plane for Zero Trust in Azure. Always start with report-only mode to understand impact before enforcing policies.

4What is Zero Trust and how does it apply to identity?Medium▼

Zero Trust is a security model based on "never trust, always verify" — no user, device, or network is trusted by default, even inside the corporate network. The three core principles:

Verify explicitly: Always authenticate and authorize based on all available data points (identity, location, device health, service/workload, data classification, anomalies).
Use least privilege access: Limit user access with just-in-time, just-enough-access (JIT/JEA), and risk-based adaptive policies.
Assume breach: Minimize blast radius, segment access, end-to-end encryption, use analytics to detect threats.

Applied to identity: every access request is treated as if it originates from an untrusted network. Identity becomes the primary control plane replacing the network perimeter.

💡 Zero Trust is not a product — it's an architecture. Microsoft BeyondCorp (Google) and NIST SP 800-207 are key references.

5What is PAM (Privileged Access Management)?Medium▼

PAM is a set of cybersecurity strategies and technologies for controlling, monitoring, and auditing access to privileged accounts (admin, root, service accounts) that have elevated permissions.

Core PAM capabilities:

Credential vaulting: Securely store and automatically rotate privileged passwords
Session management: Record and monitor privileged sessions
JIT access: Elevate privileges only when needed, for a limited time
Least privilege enforcement: Grant minimum necessary rights
Multi-factor authentication: Require strong authentication for privileged accounts

Cloud PAM solutions: Azure Privileged Identity Management (PIM), AWS IAM Identity Center, CyberArk, BeyondTrust, HashiCorp Vault.

💡 Interview angle: Privileged accounts are attackers' #1 target. PAM reduces the blast radius of credential compromise by making privileges time-limited and auditable.

6What is Just-in-Time (JIT) access and why is it important?Medium▼

JIT access is a PAM principle where privileged access is granted only at the time of need, for the minimum duration required, and then automatically revoked. Instead of standing permanent admin privileges, users request elevated access for a specific task.

Why important:

Eliminates standing privilege — reduces the attack window dramatically
If credentials are compromised, attacker only gets time-limited access
Creates an audit trail of when and why privilege was elevated
Reduces insider threat impact

Cloud implementations: Azure PIM (approve/auto-approve, time-bounded roles), AWS IAM temporary credentials via STS AssumeRole with time limits.

💡 JIT + JEA (Just Enough Access) together implement the principle of least privilege in practice: access only when needed AND only the minimum required.

7Explain SAML 2.0 and how it enables identity federation.Hard▼

SAML (Security Assertion Markup Language) 2.0 is an XML-based open standard for exchanging authentication and authorization data between an Identity Provider (IdP) and Service Provider (SP).

Flow (IdP-initiated):

User accesses SP (e.g., AWS console)
SP redirects to IdP (e.g., ADFS, Okta, Azure AD)
User authenticates at IdP
IdP generates signed XML SAML assertion with user attributes
User's browser POSTs assertion to SP
SP validates assertion signature against IdP's certificate
SP grants access based on assertion attributes

Key SAML components: Assertion (who you are), Protocol (how to request/respond), Binding (transport mechanism — POST, redirect).

💡 SAML is used for enterprise SSO scenarios. AWS supports SAML federation for console access. Note: SAML is complex and XML-based; OIDC is the modern replacement for web/mobile scenarios.

8What is the difference between OAuth 2.0 and OIDC?Hard▼

OAuth 2.0: An authorization framework — it answers "what can this application access on behalf of the user?" It does NOT authenticate users. It issues access tokens (opaque strings or JWTs) that authorize specific scopes. Common grant types: Authorization Code, Client Credentials, Device Flow.
OIDC (OpenID Connect): An authentication layer built on top of OAuth 2.0 — it answers "who is this user?" It adds an ID Token (always a JWT) containing user identity claims (sub, email, name) on top of OAuth's access token. This enables SSO.

Analogy: OAuth is like a hotel key card (grants access to specific rooms). OIDC is like the front desk verifying your identity AND giving you the key card.

💡 When you click "Sign in with Google" on a website, that's OIDC. The Google OAuth access token lets your app access Google APIs. The OIDC ID token tells the app who you are.

9What is SSO and what are its security risks?Medium▼

SSO (Single Sign-On) allows users to authenticate once with a centralized identity provider and access multiple services without re-authenticating. Benefits: improved UX, centralized access control, easier deprovisioning.

Security risks:

Single point of failure: If the IdP is compromised, ALL connected services are compromised.
Blast radius of credential compromise: One stolen password gives access to all SSO-connected apps.
Session token theft: If long-lived SSO sessions are stolen (cookie/token), attacker accesses all apps.
Deprovisioning lag: Offboarding must revoke SSO access immediately or terminated employees retain access.

Mitigations: Enforce MFA on the IdP, short session lifetimes, conditional access policies, real-time user deprovisioning via SCIM.

💡 This is why IdP security (Azure Entra ID, Okta, Ping) is CRITICAL — it IS the new perimeter.

10What are the most common IAM misconfigurations in cloud?Easy▼

Root account without MFA: AWS root account is all-powerful — compromise = total loss.
Wildcard permissions: Action: "*", Resource: "*" grants admin-level access.
Long-lived API keys: Keys never rotated or from inactive users still active.
Overprivileged service accounts: Lambda with AdministratorAccess instead of specific permissions.
Cross-account role with overly permissive trust policy: Principal: "*" allows any account to assume the role.
No IAM Access Analyzer: No automatic detection of public or cross-account resource exposures.
Shared IAM users: Multiple people sharing one IAM user — no individual accountability.
Hardcoded credentials in code/environment: Keys in GitHub, Lambda env vars in plaintext.

11What is a managed identity/service account and what are its risks?Medium▼

Managed identities (Azure) and IAM Instance Profiles (AWS) are cloud-native mechanisms for assigning identities to cloud resources (VMs, Lambda, App Service) without needing to manage credentials explicitly. The CSP manages credential rotation automatically.

Benefits: No credentials to store, auto-rotated, auditable.
Risks:

Overprivileged managed identities: If a VM is compromised and its managed identity has broad permissions, attacker inherits those permissions without needing any credentials.
SSRF attacks: Attacker exploits SSRF to query the Instance Metadata Service (IMDS) and retrieve the managed identity's token (Capital One breach).
Lateral movement: Use the managed identity to access other cloud resources and escalate privilege.

💡 Always apply least privilege to managed identities/service accounts. Enable IMDSv2 in AWS to prevent SSRF-based metadata theft.

12How does AWS IAM differ from Azure RBAC?Hard▼

Dimension	AWS IAM	Azure RBAC
Model	Policy-based (JSON documents)	Role assignment (built-in + custom roles)
Default	Deny-by-default (everything denied unless allowed)	Deny-by-default with explicit assignments
Scope	Account-level, resource-level ARNs	Management Group → Subscription → Resource Group → Resource
Service Identities	IAM Roles (assumed by EC2/Lambda via instance profiles)	Managed Identities (system-assigned or user-assigned)
Federation	SAML 2.0, OIDC, AWS Identity Center	Azure Entra ID (native SAML, OIDC, OAuth)
Privilege Mgmt	IAM Access Analyzer, STS, AWS Organizations SCPs	Azure PIM, Conditional Access, Entra ID Governance

13What is AWS STS (Security Token Service)?Medium▼

AWS STS is a web service that enables requesting temporary, limited-privilege credentials for AWS resources. Instead of using long-lived IAM access keys, applications and users can assume IAM roles and get time-limited credentials (access key + secret key + session token).

Key STS operations:

AssumeRole: Cross-account or same-account role assumption
AssumeRoleWithSAML: SAML-based federation (enterprise SSO)
AssumeRoleWithWebIdentity: OIDC-based federation (Cognito, Google, GitHub Actions)
GetSessionToken: MFA-protected temporary credentials

Default session duration: 1 hour (max 12 hours for roles). Short-lived credentials significantly reduce breach risk.

💡 Best practice: Never use long-lived IAM access keys. Use roles and STS everywhere — EC2 Instance Profiles, Lambda execution roles, GitHub Actions OIDC federation.

14What is a federation trust and how can it be abused?Hard▼

A federation trust is a trust relationship established between an Identity Provider (IdP) and a Service Provider (SP) — the SP trusts assertions from the IdP. In cloud: AWS trusts Azure AD as the IdP; Azure trusts Okta, etc.

How it can be abused:

Golden SAML attack: Attacker steals the IdP's SAML signing certificate private key and can forge valid SAML assertions for ANY user, including admins — without the IdP's knowledge. Used in the SolarWinds attack against Microsoft 365.
Overly permissive SAML attributes: If the SP trusts a role attribute in SAML assertions, attacker who can modify SAML token can claim admin roles.
Compromised IdP: If the IdP (Okta, ADFS) is breached, all federated SPs are exposed — as seen in the Okta breach (2022).

💡 Golden SAML is one of the most dangerous cloud identity attacks. Mitigate by protecting AD FS signing certificates with HSMs, monitoring for unusual SAML assertion activity.

15What is a break-glass account?Medium▼

A break-glass account (also called emergency access account) is a highly privileged account used only in emergency situations where normal administrative access is unavailable — for example, if the SSO/MFA provider is down and no admin can log in.

Best practices for break-glass accounts:

Exclude from Conditional Access and MFA policies that could lock them out
Use strong, complex passwords (120+ characters) stored in a sealed envelope in a physical safe
Configure alerts for any use of the break-glass account
Review and audit access logs monthly to confirm account hasn't been used inappropriately
Use at least 2 break-glass accounts stored separately
Test access annually to ensure they still work

💡 Azure specifically recommends having ≥2 emergency access accounts that are cloud-only (not synced from on-prem AD) to survive AD outages.

16What is AWS IAM Access Analyzer?Medium▼

AWS IAM Access Analyzer is a service that continuously analyzes resource-based policies to identify resources (S3 buckets, IAM roles, KMS keys, Lambda functions, SQS queues, SNS topics) that are shared with external principals (other AWS accounts, the internet).

It generates findings when it detects public or cross-account access — helping identify unintended access exposures. Use cases:

Detect S3 buckets accessible to the public internet
Find IAM roles assumable by external AWS accounts
Validate that only intended external access exists
Generate least-privilege policies based on CloudTrail activity (Policy Generation feature)

Zone of Trust: defines what is "internal" — findings are generated for access granted outside this zone.

💡 Access Analyzer's policy generation feature analyses 90 days of CloudTrail and generates a minimal IAM policy based on what was actually called — perfect for right-sizing over-permissive policies.

17How would you respond to a compromised cloud IAM credential?Hard▼

Immediate response steps for a compromised AWS access key:

Disable/delete the key immediately (AWS IAM → Deactivate access key)
Preserve evidence first: Export CloudTrail logs before taking any other action
Identify blast radius: Review CloudTrail for all API calls made with the key (what was accessed/modified/deleted)
Revoke active sessions: Attach AWSRevokeOlderSessions policy or revoke session tokens
Assess impact: Check for: new IAM users created, new access keys, S3 data exfiltration, resource creation (cryptomining), policy changes
Remediate: Delete any resources created by attacker, restore any deleted resources from backups
Root cause: Identify how the key was stolen (GitHub, hardcoded, phishing)
Notify: Legal, management, DPO if personal data affected

💡 Enable GuardDuty — it will automatically alert on credential anomalies (unusual region, impossible travel, known malicious IPs).

18What is the Capital One breach and what IAM failure caused it?Hard▼

The Capital One breach (2019) resulted in the theft of 106 million customer records from AWS S3 buckets. The attack chain:

Attacker exploited an SSRF vulnerability in Capital One's WAF (running on EC2)
SSRF allowed the attacker to query the EC2 Instance Metadata Service (IMDSv1) at 169.254.169.254
The WAF EC2 instance had an IAM role with excessive S3 permissions
Attacker retrieved temporary IAM credentials from IMDS
Used those credentials to list and download S3 buckets containing customer data

IAM failures that enabled this:

IMDSv1 was enabled (no session token required — vulnerable to SSRF)
The WAF's IAM role had overly broad S3 permissions (should have had no S3 access)
No GuardDuty or anomaly detection on unusual S3 access patterns

💡 Fix: Enable IMDSv2 (requires PUT session token), apply least privilege to EC2 IAM roles, enable GuardDuty, monitor unusual cross-service access.

19What is cross-account role assumption in AWS?Hard▼

Cross-account role assumption allows an IAM principal in one AWS account (Account A) to temporarily assume an IAM role in another AWS account (Account B) to access resources there — without sharing credentials.

How it works:

Account B creates an IAM role with a trust policy allowing Account A to assume it
Account A principal calls sts:AssumeRole with the Account B role ARN
STS returns temporary credentials scoped to Account B's role
Principal uses those credentials to access Account B resources

Security considerations:

Trust policies should specify exact account IDs and role ARNs — never Principal: "*"
Add ExternalId condition for third-party access (confused deputy protection)
Require MFA condition for sensitive cross-account assumptions
Monitor with CloudTrail AssumeRole events

💡 Cross-account roles are the foundation of AWS multi-account architectures (AWS Organizations) — security tooling in the security account assumes roles into member accounts.

20What is SCIM (System for Cross-domain Identity Management)?Medium▼

SCIM is an open standard protocol (RFC 7644) for automating the exchange of user identity information between identity providers and cloud applications. It provides a standardized REST API for user and group provisioning/deprovisioning.

SCIM enables automatic:

User creation when a new employee joins (synced from AD/HR system to cloud apps)
Attribute updates (name change, department change)
Account deactivation when an employee leaves — critical for offboarding
Group synchronization

SCIM is supported by Azure Entra ID, Okta, and most major SaaS apps (Salesforce, ServiceNow, Box).

💡 Without SCIM, offboarding requires manually revoking access in every application — a process that's often delayed or incomplete, leaving terminated employee access active for days or weeks.

MCQ Quiz · 25 Questions

Multiple Choice Questions

Progress:

0 / 25

Simulation 1

Access Control Model Matcher

Classify each scenario as RBAC, ABAC, or PBAC.

Simulation 2

Federation Protocol Matcher

Match each description to the correct identity protocol or service.

Simulation 3

IAM Misconfiguration Risk Rater

Assign the correct risk level to each IAM configuration scenario.

Simulation 4

MFA Strength Ranker

Click each MFA method to assign its strength rank (1 = strongest, 5 = weakest). Click a method, then click the rank slot.

Rank slots (1 = Strongest → 5 = Weakest):

🎉

Module 02 complete! Proceed to Module 03: Network Security in Multi-Cloud.