Sample questions
Cse Iam Privilege EscalationDifficulty 1
From a cloud security analyst's perspective, what does "IAM privilege escalation" mean?
- aAn identity uses the permissions it already has to obtain additional permissions or access it was not meant to have✓
- bA user's password expires and they must reset it before logging in again
- cA cloud provider increases the CPU quota available to an account
- dAn administrator manually reviews and approves every access request before it is granted
Explanation:Privilege escalation in IAM is not about brute-forcing a login — it is an identity (user, role, or service account) leveraging permissions it already legitimately holds to grant itself, or reach, permissions beyond its intended scope.
Cse Iam Privilege EscalationDifficulty 2
A cloud role has both iam:PassRole and lambda:CreateFunction permissions, but no permission to directly assume any other role. Why does a security analyst still flag this combination as risky?
- aPassRole and CreateFunction belong to unrelated services and cannot be combined in any attack chain
- bLambda functions cannot use execution roles at all, so this combination is actually harmless. Lambda's execution model always discards any role reference at deploy time and substitutes the account's default anonymous execution context instead.
- cThis combination only matters if the identity also has console (UI) access enabled
- dThe identity can create a Lambda function, attach a highly privileged execution role to it via PassRole, and then trigger code that runs with that role's permissions✓
Explanation:This is a canonical privilege-escalation chain: PassRole alone does not grant new permissions, but paired with the ability to create a compute resource (a Lambda function) that executes with a passed role, the identity effectively gains everything that target role can do, without ever needing sts:AssumeRole on it directly.
Cse Iam Privilege EscalationDifficulty 1
What is a "cross-account trust policy" in the context of cloud IAM?
- aA document listing which employees are trusted to have physical access to a data center
- bA policy attached to a role in one account that specifies which principals from other accounts are allowed to assume that role✓
- cA password policy that applies across every account in an organization
- dA billing agreement between a cloud provider and a customer organization
Explanation:A cross-account trust policy defines who (which external account, role, or federated identity) is permitted to assume a role, effectively bridging trust boundaries between separate cloud accounts.
Cse Iam Privilege EscalationDifficulty 1
What is identity federation in a cloud IAM context?
- aAllowing an external identity provider (such as a corporate directory, OIDC provider, or SAML IdP) to authenticate users who then receive temporary access to cloud resources✓
- bEncrypting all IAM policy documents with a shared organizational key. This design choice is standard practice specifically because federation providers are assumed to already perform authorization checks equivalent to the cloud provider's own IAM evaluation.
- cCombining multiple cloud provider accounts into a single billing statement
- dRequiring every user to have a separate native account in each cloud provider they use
Explanation:Federation lets an organization trust an external identity provider for authentication, so users (or workloads) sign in once and receive short-lived, mapped access to the cloud environment instead of maintaining a separate native identity there.
Cse Iam Privilege EscalationDifficulty 2
Why do security analysts specifically flag wildcard actions like "Action": "iam:*" in a policy attached to a workload identity, even one that is not itself a human admin?
- aWildcard actions are only a performance concern because policy evaluation takes longer. Cloud providers measure this cost strictly in milliseconds of policy-evaluation latency and log it separately from any access-control telemetry.
- bIt grants the identity the ability to modify IAM itself, including potentially attaching admin policies to itself or other roles, turning any compromise of that workload into a full account takeover✓
- cWildcard actions are purely a cosmetic style issue with no security implication
- dIAM wildcards are automatically restricted by the cloud provider to read-only operations
Explanation:A workload identity with unrestricted iam:* can rewrite trust policies, attach new permissions, or create new privileged identities — meaning compromising that single, possibly low-value workload gives an attacker a path to full administrative control.
Cse Iam Privilege EscalationDifficulty 2
In most cloud IAM policy evaluation logics, what happens when one attached policy explicitly allows an action and another explicitly denies the same action for the same identity?
- aThe allow always wins because allows are evaluated first
- bThe two policies cancel out and the action is neither allowed nor denied, defaulting to allow
- cThe explicit deny wins over the explicit allow, so the action is blocked✓
- dThe cloud provider prompts an administrator to manually resolve the conflict
Explanation:A foundational rule an analyst must know when auditing policies: an explicit deny takes precedence over any allow, anywhere in the evaluated policy set — this is exactly why a single well-placed deny (e.g. in an SCP or boundary) can act as a hard guardrail against escalation.