Study guide
8.1 Identity & Access Management, RBAC & ABAC
CompTIA Cloud+ Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Cloud Architecture Fundamentals
1.1 Cloud Service Models & Shared Responsibility 1.2 Cloud Deployment Models & Multi-Cloud Strategies 1.3 High Availability, Resiliency & Redundancy 1.4 Disaster Recovery & Business Continuity 1.5 Evolving Cloud Technologies: AI/ML Services, IoT & Edge Computing
2 Chapter 2: Cloud Compute & Storage Architecture
2.1 Virtualization & Hypervisor Architectures 2.2 Containerization & Microservices Architecture 2.3 Container Orchestration & Kubernetes Architecture 2.4 Cloud Storage Architectures & Performance
3 Chapter 3: Cloud Networking Architecture
3.1 Virtual Private Clouds & Subnetting Architecture 3.2 Hybrid & Multi-Cloud Connectivity 3.3 DNS, Load Balancing & Traffic Routing 3.4 Cloud Network Security Architecture
4 Chapter 4: Workload Assessment & Migration Planning
4.1 Cloud Migration Strategies (The 6/7 Rs) 4.2 Pre-Migration Workload Assessment & Sizing 4.3 Data & Database Migration Methods 4.4 Migration Execution, Cutover & Post-Migration Validation
5 Chapter 5: Infrastructure as Code & Provisioning
5.1 Infrastructure as Code Fundamentals & State Management 5.2 IaC Tooling & Template Authoring 5.3 Provisioning Automation & Image Management 5.4 Deployment Strategies & Release Patterns
6 Chapter 6: Cloud Operations & Lifecycle Management
6.1 Resource Lifecycle & Patch Management 6.2 Cloud Scaling Strategies & Elasticity 6.3 Cloud Cost Management & Optimization (FinOps) 6.4 Capacity Planning & Service Quotas
7 Chapter 7: Cloud Backup, Recovery & Business Continuity Operations
7.1 Backup Strategies, Storage Media & Retention Policies 7.2 Immutable Backups, Vault Locking & Ransomware Defense 7.3 Point-in-Time Recovery & Data Integrity Validation 7.4 High Availability Failover Drills & Chaos Engineering
8 Chapter 8: Cloud Security Controls & Identity and Access Management
8.1 Identity & Access Management, RBAC & ABAC 8.2 Identity Federation, SSO & Directory Integration 8.3 Multi-Factor Authentication, PAM & Machine Identities 8.4 Secrets Management & Cryptographic Credential Hygiene
9 Chapter 9: Data Protection, Vulnerability & Compliance
9.1 Data Encryption, Key Management & Confidential Computing 9.2 Vulnerability Management, Posture Assessment & CWPP 9.3 Container, Workload & Runtime Security 9.4 Cloud Compliance Frameworks & Governance Auditing
10 Chapter 10: DevOps Fundamentals & CI/CD Pipelines
10.1 Version Control Systems & Branching Strategies 10.2 Continuous Integration & Automated Testing Pipelines 10.3 Continuous Delivery, Deployment Automation & GitOps 10.4 Configuration Management & Systems Integration
11 Chapter 11: Cloud Observability & Monitoring
11.1 The Three Pillars of Observability: Metrics, Logs & Traces 11.2 Cloud Monitoring Architecture, Alerting & SLOs 11.3 Centralized Log Aggregation, SIEM & Log Analytics
12 Chapter 12: Troubleshooting Cloud Architecture & Deployments
12.1 Structured Cloud Troubleshooting Methodology 12.2 Troubleshooting Compute, Container & Storage Failures 12.3 Troubleshooting Provisioning, IaC & Automation Failures
13 Chapter 13: Troubleshooting Cloud Networking & Security
13.1 Troubleshooting Cloud Network Connectivity & Routing 13.2 Troubleshooting IAM, Permissions & Encryption 13.3 Troubleshooting Disaster Recovery & Performance Degradation
8.1 Identity & Access Management, RBAC & ABAC
Key Takeaways Explain This Topic AI
The Principle of Least Privilege (PoLP) and Separation of Duties (SoD) are the core pillars of Zero Trust cloud architectures, requiring explicit verification and minimal standing access for every request.
Role-Based Access Control (RBAC) binds static permissions to predefined job functions, whereas Attribute-Based Access Control (ABAC) dynamically grants fine-grained permissions using identity, resource, and environmental tags (e.g., env=prod, department, project).
Cloud policy evaluation follows a strict deterministic precedence: an Explicit Deny always overrides an Explicit Allow, and an Explicit Allow is required to override the Default Deny (implicit deny).
IAM entities include Users (long-term human credentials), Groups (administrative collections), Roles (assumable identities yielding temporary credentials), and Policies (declarative JSON/HCL permission documents).
Multi-layered cloud governance uses Permission Boundaries to limit maximum delegable permissions and Service Control Policies (SCPs) or Azure Management Policies as organization-wide guardrails.
Last updated: August 2026
Identity & Access Management, RBAC & ABAC
In modern cloud architecture, Identity and Access Management (IAM) serves as the primary security perimeter. Traditional network-centric security perimeters—such as border firewalls and demilitarized zones (DMZs)—are insufficient in distributed, multi-tenant cloud environments where workloads, serverless functions, and mobile workforces interact across global networks.
For the CompTIA Cloud+ (CV0-004) examination, cloud engineers must possess deep mastery of authorization models, declarative policy structures, access evaluation logic, and enterprise governance guardrails across Amazon Web Services (AWS) , Microsoft Azure , and Google Cloud Platform (GCP) .
1. Core Security Principles: Least Privilege, Separation of Duties & Zero Trust
Modern cloud security architecture relies on three interrelated governance principles to minimize the attack surface and mitigate lateral movement: +-----------------------------------------------------------------------------------------+
- | CORE CLOUD IAM SECURITY PILLARS |
- | |
- | +--------------------------+ +--------------------------+ +-----------------------+ |
- | | LEAST PRIVILEGE (PoLP) | | SEPARATION OF DUTIES(SoD)| | ZERO TRUST | |
- | | - Exact minimum actions | | - Divide critical tasks | | - Assume breach | |
- | | - Specific resource ARNs | | - Prevent single-person | | - Verify explicitly | |
- | | - Ephemeral time-bounds | | compromise or fraud | | - Continuous telemetry| |
- | | - No wildcard (*) admin | | - Dual-custody approvals | | - Contextual identity | |
- | +--------------------------+ +--------------------------+ +-----------------------+ |
- +-----------------------------------------------------------------------------------------+
- Principle of Least Privilege (PoLP)
The Principle of Least Privilege (PoLP) dictates that every identity—whether a human administrator, an automated deployment pipeline, or an application service—must be granted only the absolute minimum set of permissions necessary to perform its specific job function, for only the duration required.
Anti-Pattern: Assigning broad administrative privileges (such as AdministratorAccess or *:* ) to simplify deployment or troubleshoot access issues.
Best Practice: Authoring scoped policies specifying explicit API actions (e.g., s3:GetObject , ec2:DescribeInstances ) and restricting them to specific resource Amazon Resource Names (ARNs) or Azure Resource IDs, rather than using wildcard asterisks ( * ).
Separation of Duties (SoD)
Separation of Duties (SoD) is an administrative control that prevents fraud, unauthorized system modifications, and catastrophic operational errors by requiring that critical, high-risk tasks be divided among multiple individuals or distinct roles.
Infrastructure vs. Security Auditing: The cloud engineer who configures VPC routing and virtual machines must not possess the permissions to disable CloudTrail or delete centralized SIEM audit logs.
Billing vs. Operational Administration: Financial analysts who require access to cost allocation reports and billing dashboards should have no rights to terminate compute instances or alter network firewalls.
Dual-Control / Multi-Party Approval: High-impact operations—such as terminating production database clusters or modifying organization-wide root policies—require secondary administrative approval before execution.
Zero Trust Architecture (NIST SP 800-207)
The Zero Trust security model operates on the fundamental premise: "Never Trust, Always Verify." In a Zero Trust architecture, network locality does not confer trust. An internal IP address inside a Virtual Private Cloud (VPC) or corporate VPN is treated with the same skepticism as a request originating from the public internet.
Key Zero Trust tenets enforced through IAM include:
Explicit Verification: Every access request is authenticated and authorized using all available data points (identity, location, device health, service classification, and anomaly detection).
Least Privilege Access: Access is limited using Just-In-Time (JIT) and Just-Enough-Access (JEA) mechanisms, dynamic risk-based policies, and data protection.
Assume Breach: Workloads are micro-segmented, network communication is encrypted end-to-end, and telemetry is continuously analyzed to detect anomalies and limit blast radius.
2. Access Control Models: RBAC vs. ABAC
Cloud service providers implement two primary paradigms for granting and restricting access: Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC) . +-----------------------------------------------------------------------------------------+
- | RBAC VS. ABAC ARCHITECTURAL COMPARISON |
- | |
- | ROLE-BASED ACCESS CONTROL (RBAC) ATTRIBUTE-BASED ACCESS CONTROL (ABAC) |
- | +---------------------------------------+ +-------------------------------------+ |
- | | User: Alice | | User: Bob (Tag: Dept=Dev, Env=Prod) | |
- | | Role: 'DatabaseAdministrator' | | Policy: Allow Action on Resource IF | |
- | | Permissions: RDS:* on all instances | | PrincipalTag:Dept == ResourceTag:Dept||
- | | Result: Static access across fleet | | Result: Dynamic access evaluated on | |
- | | | | matching resource tags | |
- | +---------------------------------------+ +-------------------------------------+ |
- | Scale Limitation: 'Role Explosion' Scale Advantage: Scales with Metadata |
- +-----------------------------------------------------------------------------------------+
- Role-Based Access Control (RBAC)
RBAC assigns permissions to predefined roles , and users or groups are subsequently assigned to those roles based on their organizational job responsibilities.
Implementation: In Azure, RBAC utilizes built-in roles (e.g., Owner , Contributor , Reader , User Access Administrator ) or custom roles scoped to a Management Group, Subscription, Resource Group, or individual Resource.
Advantage: Simple to understand, straightforward to audit for small teams, and easy to map directly to corporate organizational charts.
Disadvantage (Role Explosion): As organizations scale across dozens of projects, regions, and environments, administrators must create hundreds of specialized, rigid roles (e.g., DevOps-App1-US-East-Dev , DevOps-App1-EU-West-Prod , DevOps-App2-US-East-Dev ), leading to severe management overhead and configuration drift.
Attribute-Based Access Control (ABAC)
ABAC evaluates access dynamically at request runtime by comparing attributes (tags) associated with the calling identity (principal), the target resource, the requested action, and the environment.
Implementation: Policies use condition keys such as aws:PrincipalTag/Department and aws:ResourceTag/Department . If the tags match, access is granted automatically without modifying IAM role definitions.
Advantage: Eliminates role explosion. When a developer provisions a new database tagged with Project=Apollo and Environment=Staging , any engineer with matching principal tags automatically gains access without IAM administrative intervention.
Disadvantage: Requires rigorous, organization-wide tag governance and standardization. If an automated IaC script fails to tag a resource properly, or if tag keys contain case-sensitivity mismatches ( Dept vs dept ), access is denied by default.
Comparison: RBAC vs. ABAC
- Architectural Dimension Role-Based Access Control (RBAC) Attribute-Based Access Control (ABAC)
- Access Criteria Assigned static role / group membership Dynamic metadata attributes (tags, environment, time)
- Scalability Low to Moderate (subject to role explosion) High (scales automatically with resource tagging)
Policy Maintenance High (must update policies/roles when new resources spawn) Low (single policy governs all matching tagged resources)
- Granularity Coarse to medium grain Fine-grained contextual control
- Governance Need Strict role catalog maintenance Strict tag enforcement via Cloud Policies / SCPs
Primary Use Case Baseline administrative access, small teams Dynamic multi-tenant clouds, microservice environments
3. Cloud Policy Evaluation Logic & Precedence
Cloud policy evaluation engines (such as the AWS IAM Policy Evaluation Engine and Azure Policy Engine) follow a strict, deterministic sequence to determine whether an API request is authorized. +-----------------------------------------------------------------------------------------+
- | CLOUD POLICY EVALUATION LOGIC FLOW |
- | |
- | 1. INCOMING API REQUEST |
- | (Principal, Action, Target Resource, Context) |
- | | |
- | v |
- | 2. DEFAULT STATE: [IMPLICIT / DEFAULT DENY] |
- | | |
- | v |
- | 3. IS THERE AN EXPLICIT DENY IN ANY MATCHING POLICY? |
- | (SCP, Permission Boundary, Identity Policy, Resource Policy) |
- | | | |
- | YES NO |
- | | | |
- | v v |
- | [DENY ACCESS] <============= 4. IS THERE AN EXPLICIT ALLOW? |
- | (Identity Policy OR Resource Policy) |
- | | | |
- | YES NO |
- | | | |
- | v v |
- | 5. WITHIN BOUNDARIES? [DENY ACCESS] |
- | (SCP & Boundary) |
- | | | |
- | YES NO |
- | | | |
- | v v |
- | [ALLOW ACCESS] [DENY ACCESS] |
- +-----------------------------------------------------------------------------------------+
Deterministic Policy Evaluation Rules:
Default Deny (Implicit Deny): By default, all requests are denied. If no policy explicitly allows an action, the request is blocked.
Explicit Deny Overrides Everything: An explicit "Effect": "Deny" in any applicable policy (SCP, Identity Policy, Resource Policy, or Permission Boundary) immediately halts evaluation and denies the request, overriding any and all explicit allows.
Explicit Allow Grants Access (Subject to Boundaries): For an access request to succeed, at least one applicable policy must contain an explicit "Effect": "Allow" , and the action must fall within the maximum permission envelope defined by applicable Permission Boundaries and Service Control Policies.
- Example: ABAC Policy with Explicit Deny and Conditional Allow {
- "Version": "2012-10-17",
- "Statement": [
- {
- "Sid": "AllowActionsMatchingDepartmentTags",
- "Effect": "Allow",
- "Action": [
- "ec2:StartInstances",
- "ec2:StopInstances",
- "ec2:RebootInstances"
- ],
- "Resource": "*",
- "Condition": {
- "StringEquals": {
- "aws:ResourceTag/Department": "${aws:PrincipalTag/Department}"
- }
- }
- },
- {
- "Sid": "ExplicitlyDenyProductionWithoutMFA",
- "Effect": "Deny",
- "Action": "ec2:*",
- "Resource": "*",
- "Condition": {
- "StringEquals": {
- "aws:ResourceTag/Environment": "prod"
- },
- "BoolIfExists": {
- "aws:MultiFactorAuthPresent": "false"
- }
- }
- }
- ]
- }
Analysis: If a user attempts to stop a production EC2 instance ( Environment=prod ) without active Multi-Factor Authentication (MFA), the second statement triggers an Explicit Deny , immediately overriding the first statement's allow, even if the user's department tag matches.
4. Multi-Layered IAM Entities & Guardrails +-----------------------------------------------------------------------------------------+
- | MULTI-TIERED IAM AUTHORIZATION ENVELOPE |
- | |
- | +---------------------------------------------------------------------------------+ |
- | | 1. SERVICE CONTROL POLICIES (SCPs) / AZURE MANAGEMENT GROUP POLICIES | |
- | | Organization-wide maximum allowable guardrails (Filters all child accounts) | |
- | | +-------------------------------------------------------------------------+ | |
- | | | 2. PERMISSION BOUNDARIES | | |
- | | | Maximum permission ceiling applied to an individual User or Role | | |
- | | | +-----------------------------------------------------------------+ | | |
- | | | | 3. IDENTITY-BASED POLICIES (IAM Policies / Roles) | | | |
- | | | | Actual granted permissions (Must fall within 1 and 2) | | | |
- | | | +-----------------------------------------------------------------+ | | |
- | | +-------------------------------------------------------------------------+ | |
- | +---------------------------------------------------------------------------------+ |
- | |
- | +---------------------------------------------------------------------------------+ |
- | | 4. RESOURCE-BASED POLICIES (S3 Bucket Policies, KMS Key Policies, Key Vaults) | |
- | | Attached directly to the resource; can grant direct cross-account access | |
- | +---------------------------------------------------------------------------------+ |
- +-----------------------------------------------------------------------------------------+
- IAM Entities
Users: Represent distinct human identities or legacy service accounts. They possess long-lived credentials (console passwords, static API Access Key / Secret Key pairs). In enterprise environments, direct IAM user creation is deprecated in favor of federated identities.
Groups: Administrative collections used to attach policies to multiple users simultaneously. Groups cannot be referenced as a Principal in policies.
Roles: Identities that can be assumed by anyone who needs them, including users, cloud services (e.g., EC2, Lambda), or external federated identities. Roles issue temporary, short-lived cryptographic credentials via the cloud Security Token Service (STS).
Policy Types & Guardrails
Identity-Based Policies: JSON documents attached directly to users, groups, or roles defining what that identity can do.
Resource-Based Policies: JSON documents attached directly to a resource (e.g., Amazon S3 bucket policy, AWS KMS key policy, Azure Key Vault access policy). Unlike identity policies, resource-based policies explicitly define the Principal allowed to access that specific asset and can grant direct cross-account access without requiring the caller to assume an external role.
Permission Boundaries: An advanced IAM feature that uses a managed policy to set the maximum permissions that an identity-based policy can grant to an IAM user or role. Even if a delegated administrator attempts to attach AdministratorAccess to a role, the role's effective permissions are capped at the boundary.
Service Control Policies (SCPs) / Azure Policy: Centralized governance rules applied at the organizational root, Organizational Unit (OU), or management group level. SCPs do not grant permissions ; instead, they define guardrails (the maximum available permissions) for all accounts within that OU, restricting even the account root user.
5. CompTIA Cloud+ Exam Traps & Real-World Pitfalls
Caution
Exam Trap: SCPs Do Not Grant Access An SCP containing "Effect": "Allow", "Action": "*", "Resource": "*" does NOT give any user administrator access. It merely permits child account administrators to delegate those actions using identity policies. Conversely, an SCP Deny statement blocks that action across all child accounts, regardless of what local IAM policies grant.
Warning
Exam Trap: Identity Policy vs Resource Policy in Cross-Account Access When accessing a resource in Account B from Account A via Identity Policies, Account A's role must assume a role in Account B. However, if Account B attaches a Resource-Based Policy that names Account A's principal, the caller can access the resource directly without assuming a cross-account role.