- Which statement correctly describes the role's effective cross-account access?
Answer: It can read quarterly reports, but it cannot delete them because the resource policy lacks that permission.
When you encounter cross-account access questions in AWS (or similar cloud environments), the key principle to internalize is the intersection rule: both the identity policy (attached to the principal) and the resource policy (attached to the target) must explicitly allow an action. If either policy is silent on a permission — or denies it — the action is blocked. Think of it as two gatekeepers who must both say yes.
In this scenario, the role's identity policy allows both ReadReport and DeleteReport on all reports. However, the audit account's resource policy only permits ReadReport on quarterly reports. For an action to succeed cross-account, it must appear in both policies. ReadReport on quarterly reports clears both gates — it's allowed. DeleteReport never clears the resource policy's gate — even though the identity policy permits it — so it's blocked. That makes B the correct answer.
A is wrong because the identity policy alone isn't sufficient in cross-account scenarios. Having both ReadReport and DeleteReport in the identity policy doesn't grant those permissions if the resource policy doesn't mirror them. C is a fabricated rule — policies don't need identical resource scopes to function; they just each need to permit the specific action being requested. D reverses the logic entirely; since the resource policy only covers ReadReport on quarterly reports, DeleteReport is blocked everywhere — there's no pathway for deletion at all.
Your study tip: remember the cross-account access formula as AND logic — identity policy AND resource policy must both allow. A single missing allow kills the action, even without an explicit deny.
- A user's own policy allows full storage access, but a cap attached to that same user limits it to read-only. What is the cap?
Answer: Permissions boundary
A permissions boundary attached to a user limits that user to the overlap of the boundary and the user's policies. A service control policy also limits permissions, but it applies to accounts in an organization, not to a single user.
- Can the developer create a new encryption key in that region?
Answer: No, because the guardrail establishes only the ceiling of permitted actions; an applicable identity policy must also grant key creation before it is authorized.
Whenever you see a question involving cloud permission models — especially with organizational guardrails like AWS Service Control Policies (SCPs) or similar constructs — you need to think in terms of layered authorization: every layer must affirmatively permit an action before it is allowed.
Guardrails at the organization level function as a permission ceiling, not a permission grant. They define the maximum scope of what could be allowed within an account, but they do not themselves authorize any principal to do anything. For the developer to create an encryption key, two independent conditions must both be true: (1) the guardrail must not block the action, and (2) the developer's own identity policy must explicitly grant key creation. In this scenario, only condition one is satisfied — the guardrail permits key-management services in the approved region. The developer's role policy grants only storage read access. Because no identity policy grants key creation, the action is denied by default. That makes D the correct answer.
A is wrong because it conflates "permitted by guardrail" with "available to all principals." Guardrails permitting a service category never automatically grant that service to anyone — they simply remove an organizational ceiling. B compounds this misconception by claiming the absence of an explicit deny is equivalent to a grant, which inverts the fundamental cloud IAM principle: access requires an affirmative allow. C goes too far in the opposite direction, incorrectly claiming guardrails implicitly deny listed services to individual roles — in reality, guardrails neither grant nor implicitly deny; they only constrain what identity policies can do.
A useful pattern to remember: guardrails cap, identity policies grant. Both must align for an action to succeed.
- What is the expected authorization result?
Answer: The request fails because the applicable network-based explicit deny overrides the allow statements.
When evaluating cloud authorization decisions, the most important rule to internalize is the explicit deny override: in virtually every major cloud IAM framework (AWS, Azure, GCP), an explicit deny always wins, regardless of how many allow statements exist or where they come from. This question tests whether you understand that hierarchy.
Here, the user has three applicable policies evaluated together: a direct identity policy (allows reads), a group policy (explicitly denies all object-storage actions from outside the corporate network), and a bucket resource policy (allows authenticated users to read). The user requests from a personal network — triggering the group policy's explicit deny condition. Because that deny is explicit and applicable, it overrides both allow statements. The request fails. That's why C is correct.
A is wrong because specificity doesn't determine priority in cloud IAM — explicit denies do. There's no "more specific wins" principle that can override an explicit deny; that logic applies to some firewall rule systems, not identity policy evaluation.
B is wrong because it assumes that having multiple allow statements strengthens the authorization. It doesn't. Even ten allow policies cannot overcome a single applicable explicit deny. The number or source of allows is irrelevant once an explicit deny is triggered.
D is wrong because it describes a relationship between identity and resource policies that simply doesn't exist. Resource policies and identity policies are evaluated together, not in isolation — neither type categorically blocks the other from contributing to an allow decision.
Your study tip: memorize the phrase "explicit deny always wins." On exam questions involving multiple overlapping policies, locate any explicit deny first — if one applies to the request, the authorization result is deny, full stop.
- What access does the resulting role session have to the evidence bucket?
Answer: Read access only, because the session's permissions are limited by the requested session policy.
When a cloud platform evaluates access requests, it doesn't simply ask "does any policy allow this?" — it asks "what is the intersection of all applicable permission boundaries?" Session policies work as an additional ceiling on what a role session can do, not as a replacement or override of existing policies.
Here's how the logic flows: the role policy grants ReadObject and WriteObject. The bucket policy also grants both. Normally, that means full read/write access. But when the engineer attaches a session policy requesting only ReadObject, the platform computes the effective permissions as the intersection of (role policy ∩ session policy). Since WriteObject is not in the session policy, it falls outside that intersection and is denied — leaving only ReadObject. This makes C correct.
A is tempting because both the role policy and bucket policy do permit read and write. The trap is ignoring the session policy's role as a maximum-permissions limiter. The bucket policy cannot grant back access that the session policy has excluded.
B misunderstands the relationship between session and role policies. The session policy doesn't replace the role policy — it further restricts it. The role policy remains in effect; the session policy simply narrows the ceiling.
D describes a behavior that doesn't exist. Resource policies (like the bucket policy) absolutely continue to recognize and evaluate role sessions; attaching a session policy doesn't make the session invisible to resource-based policies.
As a study tip, remember this rule: effective permissions = minimum of all permission layers. When you see session policies on the exam, always apply the intersection principle rather than assuming additive or replacement behavior.
- Staff sign in through their company identity provider and receive temporary cloud role credentials, with no cloud user accounts. What is this?
Answer: Identity federation
With federation, the cloud trusts the company identity provider and issues temporary role credentials, so no cloud user accounts are needed. Password synchronization is tempting, but it copies credentials into the cloud instead of trusting the provider.
- In identity-first cloud security, what mainly determines whether a request to read a storage bucket is allowed?
Answer: The caller's identity and its granted permissions
Identity-first security authorizes each request based on who the authenticated caller is and what its policies allow. Network location is the tempting answer, but trusting the corporate network is the perimeter model that identity-first security replaces.
- Which operation can a developer perform under these policies?
Answer: Start an instance, because that operation is permitted by both the identity policy and the permissions boundary, satisfying the intersection requirement.
When a question involves multiple overlapping policies, your instinct should be to ask: "What is the intersection of what each policy allows?" In AWS-style permission models, a permissions boundary doesn't grant access on its own — it acts as a ceiling. For an action to succeed, it must be explicitly allowed by both the identity policy and the permissions boundary simultaneously.
Here, the identity policy grants all actions on compute instances, which includes StartInstance. The permissions boundary explicitly allows DescribeInstance and StartInstance. Because StartInstance appears in both, it clears the intersection requirement — making D the correct answer. The developer can start an instance because that single action satisfies both layers of authorization.
Choice A fails because StopInstance is absent from the permissions boundary. Even though the identity policy grants it, the boundary's silence on StopInstance isn't a neutral omission — it means the ceiling doesn't cover that action, so it's effectively denied. A boundary must include an action for it to be executable, not merely refrain from denying it.
Choice B makes a false assumption that the boundary only restricts identity-management actions. The passage gives no indication of that scope — the boundary is defined by what it explicitly enumerates, not by inferred categories.
Choice C misreads how boundaries work. The boundary does not grant permissions independently; it only caps what the identity policy can deliver. Listing DescribeInstance first carries no special significance — ordering is irrelevant.
Study tip: Think of a permissions boundary as a fence, not a key. The identity policy is the key, but if the fence doesn't have a gate for that action, the key is useless. Always check that both layers cover the same action.
- Contractors need admin rights for a two-day incident response. Which approach best fits identity-first least privilege?
Answer: Time-limited role access granted through approval
Just-in-time access through an approved role that expires keeps privileges individual and short-lived. Permanent admin rights with MFA is the tempting choice, but MFA only strengthens sign-in while the excess standing privilege remains.
- Which control most directly addresses the resulting privilege-escalation path without abandoning attribute-based access control?
Answer: Permit only a trusted provisioning process to set authorization-relevant identity tags and audit all changes.
Whenever you see a question about attribute-based access control (ABAC), focus on where trust is established. ABAC grants permissions based on tags or attributes, so the security of the entire model depends on who controls those tags. If a principal can modify their own authorization-relevant attributes, they can self-grant elevated privileges — this is the classic ABAC privilege-escalation pattern.
The vulnerability here is straightforward: because employees can edit their own Project tag, any employee can simply set their tag to match any project's resources and instantly gain administrative rights over them. The root cause isn't the policy logic — it's that untrusted principals control trust-determining data.
B directly closes this gap by removing tag-editing rights from employees entirely and routing all changes through a controlled provisioning process with audit logging. This preserves the ABAC model while fixing the actual vulnerability: the integrity of the attribute source.
A is a reactive measure focused on resource tags, not identity tags. Monthly retagging doesn't prevent an employee from changing their own identity tag between cycles, so the escalation path remains open.
C adds friction but not security. Requiring MFA before a malicious tag update still allows the update to happen — an attacker or insider simply completes the MFA challenge and proceeds. Authentication strength doesn't replace authorization integrity.
D compounds the problem. Adding group memberships while still allowing employees to self-select matching tags means two misconfigured mechanisms now coexist, doubling the attack surface rather than reducing it.
The study takeaway: in ABAC questions, always ask who controls the attributes. Untrustworthy attribute sources are the canonical weakness of the model, and the fix is always governance of the attribute pipeline, not policy adjustments downstream.
- Which trust-policy design best mitigates this confused-deputy risk?
Answer: Trust the vendor service identity only when it presents a company-specific external identifier, and restrict the role to required logs.
When you see a question about multi-tenant cloud services and role assumption, think about the confused deputy problem: a trusted intermediary (the vendor) can be tricked by one party into acting on behalf of another. The defense requires the role itself to verify who it's really supposed to serve — not just who is asking.
The strongest mitigation is answer A. Cloud platforms like AWS support an ExternalId condition in IAM trust policies — a customer-specific secret shared only between the customer and the vendor. When the vendor assumes your role, it must present your unique external identifier. Even if another tenant somehow manipulates the vendor's service into targeting your role ARN, they cannot provide your secret identifier, so the assumption fails. Pairing this with least-privilege log access further limits blast radius.
Answer B is ineffective because rotating a role name does nothing to prevent assumption by the vendor's service — it's security through obscurity, and it creates operational chaos without addressing the root cause. Answer C misapplies MFA. MFA protects human login sessions; it isn't meaningfully enforced during service-to-service role assumption, so this condition either fails silently or is bypassed entirely by machine identities. Answer D is the weakest option — IP address restrictions are trivially bypassed since all tenants share the vendor's infrastructure and egress addresses, and allowing the service to choose its own session identifier removes an important audit and control mechanism.
Your study tip: whenever a scenario involves a shared intermediary assuming roles on behalf of multiple parties, immediately think ExternalId condition. It's the canonical AWS solution to the confused deputy problem and a frequent exam target.
- Which change most effectively reduces credential risk while preserving automated deployments?
Answer: Trust validated workload tokens with restricted claims and issue short-lived credentials for a deployment role.
When a question describes an external CI/CD system that needs cloud access, you should immediately think about workload identity federation — the modern alternative to storing long-lived credentials. The core principle is: instead of issuing a static secret, the cloud platform verifies who the caller is through a trusted token, then grants a temporary credential scoped only to what that caller needs.
That's exactly why C is correct. The CI service can already produce signed identity tokens with specific claims (repository, branch, audience). The cloud IAM platform validates those tokens — confirming the caller's identity — and exchanges approved ones for short-lived role credentials. Nothing sensitive is stored, the credentials expire automatically, and you can restrict access by claim (e.g., only the main branch of a specific repo gets deployment rights). This directly eliminates the risk of a leaked long-lived key.
A makes the classic mistake of treating encryption as a security solution when the key material itself is the threat. Encrypting the access key with another key stored in the same environment provides no meaningful protection — an attacker who compromises the environment gets both keys.
B introduces a scope problem: sharing one key across multiple repositories means a compromise in any one of them exposes all deployments. Audit logs help with forensics after a breach, not prevention.
D trades one vulnerability for another. IP-based trust is easily bypassed through IP spoofing or infrastructure compromise, and removing the key while allowing anonymous requests eliminates authentication entirely.
Study tip: On security exams, "short-lived credentials + verified identity" almost always beats "long-lived credentials + compensating controls." When you see workload identity or token exchange described, that's the signal to choose federation over stored secrets.
- Which IAM design best satisfies the identity-first requirements?
Answer: Federate the identity provider, map validated group claims to cloud roles, and issue temporary role sessions.
When a question describes federated identity, automatic deprovisioning, and a ban on long-lived credentials, you're being tested on identity federation and least-privilege IAM design — specifically how to grant cloud access through an existing identity provider rather than duplicating identities.
The ideal design, captured in A, federates the corporate identity provider with the cloud platform using a standard protocol like SAML or OIDC. When an employee authenticates, the identity provider passes validated group claims, which the cloud maps to predefined roles. The cloud then issues temporary, time-limited role sessions — no standing passwords, no permanent keys. Critically, if the employee is disabled at the identity provider, their next login simply fails, satisfying the automatic revocation requirement without any additional cloud-side cleanup.
B is a classic anti-pattern: bulk-created cloud users with copied group names reproduce the identity problem rather than solving it. Monthly password rotation still leaves credentials alive between cycles, violating the "no long-lived passwords" requirement and breaking the automatic-revocation guarantee.
C uses shared departmental credentials, which destroys individual accountability, makes revocation of a single user impossible, and relies on network location as a weak compensating control — none of which align with identity-first security.
D contradicts the core requirement directly. Permanent access keys synchronized to devices are exactly the long-lived credentials the policy prohibits; using the identity provider only for console login leaves API access completely uncontrolled.
Study tip: On IAM questions, look for the phrase "temporary credentials" as a signal of best practice — any design that issues permanent keys or passwords when federation is available is almost certainly a distractor.
- A policy attached directly to a storage bucket lists which accounts may read objects in it. What kind of IAM policy is this?
Answer: Resource-based policy
A policy attached to a resource, such as a bucket, that names which principals may access it is resource-based. An identity-based policy is the tempting answer, but it attaches to a user, group or role, not to the bucket.
- Which review approach best supports an identity-first least-privilege decision?
Answer: Calculate effective entitlements across all policy sources, compare them with observed activity, and have access owners validate unused or high-risk permissions before any removal decision is made.
When tackling least-privilege review questions, remember the core principle: least privilege isn't just about what permissions exist — it's about understanding effective access across every policy layer, then making informed decisions. Questions like this test whether you understand that identity-first security requires a complete, validated picture before any changes occur.
Answer B is correct because it captures all three pillars of a sound review: aggregation (calculating effective entitlements across direct policies, groups, roles, and resource policies), comparison (mapping entitlements against observed activity), and validation (looping in access owners before removal). That last step is critical — the passage explicitly notes some emergency permissions are legitimate even if unused. Removing them without owner validation would cause real operational harm.
Answer A is the most tempting distractor but commits a serious error: it treats 90-day logs as a complete source of truth. This ignores break-glass or emergency permissions that are legitimately infrequent. Automating removals without validation is precisely the trap the passage is designed to highlight.
Answer C misrepresents how modern identity systems work. Effective permissions are determined by the intersection of all policy sources simultaneously — you cannot meaningfully review direct policies in isolation and defer everything else. Doing so would give you an incomplete and potentially misleading entitlement picture.
Answer D is a passive, compensating-control approach, not a least-privilege strategy. Anomaly detection catches misuse after the fact; it doesn't reduce the attack surface proactively. Relying on it as a substitute for access reviews contradicts the fundamental goal of least privilege.
Your study tip: whenever a question describes complex, layered permission systems, the right answer will almost always require holistic aggregation plus human validation — not automation alone or partial-scope reviews.
