13.2 Troubleshooting IAM, Permissions & Encryption
Key Takeaways
- Cloud IAM policy evaluation strictly follows an Explicit Deny precedence: an explicit Deny in any policy (IAM policy, SCP, Permission Boundary, Resource Policy) unconditionally overrides all Allow statements.
- Service Control Policies (SCPs) and Cloud Organization Policies establish account-level guardrails; they define the maximum allowable permissions and will block root users and administrators if an explicit deny is present.
- Cross-account resource access requires a dual-authorization model: the identity-based policy in Account A must permit the action, AND the resource-based policy in Account B must explicitly permit Account A's principal.
- To prevent the Confused Deputy problem in third-party SaaS integrations, cross-account IAM role trust policies must enforce an External ID condition (sts:ExternalId) alongside the principal ARN.
- KMS CMK decryption failures occur when an IAM principal lacks kms:Decrypt permissions or when the KMS Key Policy fails to explicitly delegate access to the AWS account root or target principal; default AWS-managed keys cannot be shared across accounts.
Last updated: August 2026
Troubleshooting IAM, Permissions & Encryption
Identity, permissions, and cryptographic key management form the core security fabric of enterprise cloud platforms. In complex multi-account and multi-cloud architectures, permission failures frequently block mission-critical workloads, automated deployment pipelines, and cross-organization integrations.
For the CompTIA Cloud+ (CV0-004) examination, engineers must understand the exact hierarchical evaluation logic of cloud authorization engines, resolve cross-account trust barriers, diagnose Key Management Service (KMS) decryption errors, and fine-tune Web Application Firewalls (WAF).
1. Cloud IAM Policy Evaluation Hierarchy
When an authenticated principal (user, service account, or IAM role) attempts to perform an API action against a cloud resource, the cloud authorization engine evaluates all applicable policies according to a deterministic hierarchy.
+---------------------------------------------------------------------------------------------------+
| IAM POLICY EVALUATION DECISION LOGIC |
| |
| [ Incoming API Request ] |
| │ |
| ▼ |
| +─────────────────────────────────────────────────────────────+ |
| | Step 1: Default Posture | |
| | Initial Decision = IMPLICIT DENY | |
| +──────────────────────────────┬──────────────────────────────+ |
| │ |
| ▼ |
| +─────────────────────────────────────────────────────────────+ YES |
| | Step 2: Is there an EXPLICIT DENY in ANY applicable policy? |──────────────► [ FINAL: DENY ] |
| | (Identity, Resource, SCP, Boundary, Session Policy) | |
| +──────────────────────────────┬──────────────────────────────+ |
| │ NO |
| ▼ |
| +─────────────────────────────────────────────────────────────+ NO |
| | Step 3: Do Organization SCPs / Guardrails allow the action? |──────────────► [ FINAL: DENY ] |
| +──────────────────────────────┬──────────────────────────────+ |
| │ YES |
| ▼ |
| +─────────────────────────────────────────────────────────────+ NO |
| | Step 4: Does the IAM Permissions Boundary allow the action? |──────────────► [ FINAL: DENY ] |
| +──────────────────────────────┬──────────────────────────────+ |
| │ YES |
| ▼ |
| +─────────────────────────────────────────────────────────────+ YES |
| | Step 5: Is there an EXPLICIT ALLOW in Identity OR Resource? |──────────────► [ FINAL: ALLOW ] |
| +──────────────────────────────┬──────────────────────────────+ |
| │ NO |
| ▼ |
| [ FINAL: DENY ] (Implicit Deny) |
+---------------------------------------------------------------------------------------------------+
Key Authorization Principles
- Default Implicit Deny: By default, all requests are implicitly denied until an explicit allow statement is evaluated.
- Explicit Deny Precedence: An
Explicit Denyin any policy unconditionally overrides allAllowstatements. Even if ten identity policies grantAdministratorAccess, a single SCP or permission boundary denyings3:DeleteBucketwill permanently block that action. - Service Control Policies (SCPs): In AWS Organizations (and Azure Management Group Policy / GCP Organization Constraints), SCPs act as guardrails. SCPs never grant permissions; they specify the maximum permissions available to accounts within an Organizational Unit (OU). If an SCP does not allow an action, no user or role in the member account—including the account root user—can perform that action.
- Permissions Boundaries: An advanced IAM feature used to delegate administration. A permissions boundary sets the maximum allowable permissions for an IAM entity (user or role). The effective permissions are the intersection of the identity policy and the permissions boundary.
2. Cross-Account Access & Trust Policy Troubleshooting
Cross-account architectures allow workloads in one cloud account (e.g., Account A: Production) to access resources or assume roles in another account (e.g., Account B: Central Logging or Shared Services).
+---------------------------------------------------------------------------------------------------+
| CROSS-ACCOUNT ROLE ASSUMPTION & TRUST |
| |
| Account A (Source: 111122223333) Account B (Target: 444455556666) |
| +------------------------------+ +------------------------------------+ |
| | IAM User / Worker Node | | IAM Role: CrossAccountWorkerRole | |
| | | | | |
| | Identity Policy: | | 1. Trust Policy (Who can assume?): | |
| | { | sts:AssumeRole | Principal: Account A (1111...) | |
| | "Effect": "Allow", | ──────────────────►| Condition: ExternalId = "xyz" | |
| | "Action": "sts:AssumeRole",| | | |
| | "Resource": "arn:aws:iam:: | | 2. Permissions Policy (What do?): | |
| | 444455556666:role/..." | | Allow s3:PutObject on CentralS3 | |
| | } | +------------------------------------+ |
| +------------------------------+ |
+---------------------------------------------------------------------------------------------------+
Cross-Account Authorization Requirements
For cross-account access, permissions must be granted on both sides:
- Identity Policy (Account A): Must grant
sts:AssumeRoletargeting the Amazon Resource Name (ARN) of the role in Account B. - Trust Policy (Account B): The role in Account B must have a Trust Policy (AssumeRolePolicyDocument) listing Account A (or a specific IAM principal in Account A) as a trusted
Principal. - If either policy is missing, misconfigured, or has an explicit deny, the caller receives an
AccessDeniederror when invoking the AWS Security Token Service (sts:AssumeRole).
The Confused Deputy Problem & External ID
When an organization uses a third-party SaaS vendor (e.g., a multi-tenant monitoring or backup provider) that needs to assume an IAM role in the customer's AWS account:
- Vulnerability (Confused Deputy): If the trust policy only checks the SaaS provider's AWS account ID as the principal, a malicious customer of the same SaaS provider could give the SaaS platform the victim's Role ARN. The SaaS platform would then assume the victim's role, exposing the victim's account to the attacker.
- Remediation: Enforce an External ID (
sts:ExternalId) in the trust policy'sConditionblock. The SaaS provider generates a unique, secret External ID per customer and passes it when making theAssumeRoleAPI call.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::999988887777:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "EnterpriseCustomer-Secret-UID-9842"
}
}
}
]
}
3. Cryptographic Key Management (KMS) & Decryption Errors
Encryption at rest using AWS KMS Customer Managed Keys (CMKs), Azure Key Vault, or GCP Cloud KMS introduces complex access control dependencies across both resource policies and cryptographic key policies.
+---------------------------------------------------------------------------------------------------+
| KMS DUAL POLICY EVALUATION ARCHITECTURE |
| |
| [ IAM Principal ] |
| / \ |
| / \ |
| ▼ ▼ |
| [ IAM Identity Policy ] [ KMS Key Policy ] |
| - Allow s3:GetObject - Allow kms:Decrypt |
| - Allow kms:Decrypt - MUST Delegate to Root: |
| "Principal": {"AWS": "arn:aws:iam::1111:root"}|
| \ / |
| ▼ ▼ |
| [ S3 Object Decrypted ] |
+---------------------------------------------------------------------------------------------------+
Root Cause Triage for KMS Decryption Failures
- Missing
kms:Decryptorkms:GenerateDataKey: To read an S3 bucket or attach an EBS volume encrypted with SSE-KMS, the requesting IAM principal requires both the resource action (s3:GetObjectorec2:AttachVolume) AND the KMS key action (kms:Decrypt,kms:DescribeKey). - KMS Key Policy Delegation to Account Root: KMS keys utilize their own dedicated Key Policies. If the KMS Key Policy does not explicitly contain a statement delegating permissions to the account root (
"Principal": {"AWS": "arn:aws:iam::account-id:root"}), IAM identity policies have zero authority to grant access to the key. In this scenario, IAM administrators cannot access or grant access to the key via IAM policies alone. - Cross-Account KMS Usage: Default AWS-managed KMS keys (e.g.,
aws/s3,aws/ebs) cannot be shared across different AWS accounts. For cross-account S3 bucket replication or AMI sharing, the resource must be encrypted with a Customer Managed Key (CMK) whose Key Policy explicitly permits the external account ID. - KMS Grant Expiration: Ephemeral services (such as Auto Scaling launching EC2 instances with encrypted EBS volumes) utilize KMS Grants to delegate temporary cryptographic permissions. If a grant token expires, is revoked, or is deleted, instance launch operations fail with
Client.KmsError.
# Inspect the Key Policy of an AWS KMS Customer Managed Key
aws kms get-key-policy \
--key-id arn:aws:kms:us-east-1:123456789012:key/12345678-1234-1234-1234-123456789012 \
--policy-name default \
--output json
4. Web Application Firewall (WAF) & Security Rule Drops
Cloud Web Application Firewalls (AWS WAF, Azure WAF, Cloudflare) protect web applications at Layer 7 from common web exploits such as SQL Injection (SQLi), Cross-Site Scripting (XSS), and HTTP flood DDoS attacks.
+---------------------------------------------------------------------------------------------------+
| WAF INCIDENT TRIAGE & REMEDIATION WORKFLOW |
| |
| [ Client Receives HTTP 403 Forbidden ] |
| │ |
| ▼ |
| [ Inspect CloudWatch WAF Metrics: BlockedRequests vs. CountedRequests ] |
| │ |
| ▼ |
| [ Query WAF Sampled Requests / Log Stream for TerminatingRuleId ] |
| │ |
| ├── False Positive: AWSManagedRulesCommonRuleSet blocked valid JSON/SQL keyword |
| │ └── Action: Switch rule action to 'Count' mode -> Create custom Exclusion Rule |
| │ |
| └── Legitimate Rate Limit: Single corporate NAT IP exceeded 2000 req/5min rule |
| └── Action: Whitelist corporate egress CIDR or increase rate threshold |
+---------------------------------------------------------------------------------------------------+
Diagnosing False Positives
- Managed Rule Set False Positives: Pre-packaged managed rule sets (such as OWASP Top 10 or AWS Core Rule Set) inspect URI strings, query arguments, and body payloads. When legitimate application traffic contains legitimate XML tags, JSON syntax, or apostrophes in names (e.g.,
O'Connor), WAF inspection engines frequently misidentify the payload as an SQLi or XSS pattern and block the request withHTTP 403 Forbidden. - Triage via Sampled Requests: Use the cloud console or CLI to inspect WAF Sampled Requests. Identify the
TerminatingRuleIdand the specific match pattern that triggered the block. - Remediation Strategy: Never immediately disable an entire WAF rule group. Instead:
- Switch the specific triggering rule from
BlocktoCountmode to monitor traffic without dropping packets. - Author a scoped Rule Exclusion / Override or Custom Regex Condition that bypasses inspection specifically for the legitimate API path (e.g.,
/api/v2/comments).
- Switch the specific triggering rule from
# Query AWS WAF sampled requests to identify blocked requests in the last 3 hours
aws wafv2 get-sampled-requests \
--web-acl-arn arn:aws:wafv2:us-east-1:123456789012:regional/webacl/ProdWAF/abc-123 \
--rule-metric-name AWSManagedRulesCommonRuleSetMetric \
--scope REGIONAL \
--time-window StartTime=$(date -u -v-3H +%s),EndTime=$(date -u +%s) \
--max-items 100
5. Authentication Incidents: Leaked Credentials & Unauthorized Access
Authentication failures and credential compromise are among the most common cloud security incidents and the root cause of numerous public breach disclosures.
Leaked & Compromised Credentials
- Exposure vectors: Access keys committed to public Git repositories, secrets baked into container images or printed into CI/CD build logs, long-lived keys pasted into support tickets, and credentials harvested from the instance metadata service via SSRF attacks.
- Detection: Providers flag keys discovered in public repositories (AWS automatically attaches the
AWSCompromisedKeyQuarantinepolicy to keys found online). Watch audit trails forGetCallerIdentityreconnaissance calls, API activity from unfamiliar geographies or anonymizing VPN exits, and impossible-travel sign-ins. - Response runbook:
- Immediately deactivate or delete the exposed access key and revoke all active session tokens.
- Rotate every dependent secret and redeploy workloads onto short-lived credentials (instance profiles or workload identity federation) instead of static keys.
- Audit historical API activity for the compromised principal to identify what the attacker enumerated or created — unauthorized crypto-mining fleets and newly created IAM users are the classic follow-on actions.
- Prevention: Never store secrets in source code; enforce secret scanning (such as
git-secrets) in the CI pipeline; and prefer OIDC-based workload identity federation, which eliminates long-lived keys entirely.
Unauthorized Access, Privilege Escalation & Cipher Suite Deprecations
- Unauthorized software and shadow IT: Reconcile running workloads against the asset inventory; untagged instances that were created outside the IaC pipeline frequently indicate either shadow IT or attacker-provisioned resources.
- Privilege escalation triage: A principal holding
iam:PassRoleon a powerful role together withec2:RunInstancescan launch an instance that assumes that role and inherit its privileges. When unexpected administrator-level API calls appear, audit role-passing permissions and permissions boundaries first. - Cipher suite deprecations: Sudden TLS handshake failures after a provider security update usually mean the client still negotiates a deprecated protocol (TLS 1.0/1.1) or cipher suite (RC4, 3DES). Upgrade the client TLS library and enforce a minimum of TLS 1.2 or 1.3 in load-balancer security policies.
6. CompTIA Cloud+ Exam Traps: IAM & Security
| Common Exam Trap | Real-World Cloud Reality | CompTIA Rule to Apply |
|---|---|---|
| Assuming account administrators bypass Organization SCPs. | SCPs set hard guardrails at the organization root/OU level; even account root and AdministratorAccess cannot bypass an SCP Deny. | SCPs restrict all principals within the member account, including the root user. |
| Assuming IAM policies alone control KMS key access. | KMS keys require an explicit Key Policy; without account root delegation in the Key Policy, IAM policies cannot grant access. | KMS Key Policies take precedence over IAM policies. |
| Sharing AWS-managed default KMS keys across accounts. | Default keys (aws/s3, aws/ebs) are restricted to the local account only and cannot be shared across accounts. | You must use a Customer Managed Key (CMK) for cross-account encryption sharing. |
| Omitting External ID in third-party vendor role trusts. | Without an External ID, third-party SaaS integrations are vulnerable to the Confused Deputy exploit. | Always enforce sts:ExternalId in cross-account SaaS trust policies. |
Loading diagram...
Test Your Knowledge
A cloud administrator in a member account is assigned the AWS managed policy 'AdministratorAccess', granting full ':' permissions. However, when the administrator attempts to delete an unneeded Amazon S3 bucket, the AWS management console returns an 'Access Denied' error. CloudTrail logs show that no IAM permission boundaries are attached to the administrator's identity. What is the MOST likely cause of this authorization block?
A
B
C
D
Test Your Knowledge
A data engineering team configures an Amazon S3 bucket encrypted with a Customer Managed Key (CMK) in AWS Key Management Service (KMS). An application running on an EC2 instance in the same account is assigned an IAM role with full 's3:GetObject' permissions on the bucket. However, when the application attempts to read objects from the bucket, it receives an 'AccessDenied' error. What additional permission configuration is required to allow the application to read the encrypted objects?
A
B
C
D
Test Your Knowledge
An enterprise integrates a third-party multi-tenant SaaS analytics platform to inspect cloud infrastructure logs. The security team creates an IAM role in their production account that the SaaS vendor's AWS account will assume. To prevent the Confused Deputy vulnerability, what critical condition must the cloud security team configure in the IAM role's trust policy?
A
B
C
D