Cyber Security Quiz: Cloud Iam Policies
10 questions · exam conditions
0:00
Cloud Iam PoliciesQuestion 1 of 10

Developers receive an identity policy allowing all actions on development compute instances. Their identities are also subject to a permissions boundary that allows only DescribeInstance and StartInstance. The boundary contains no statement for StopInstance or ModifyNetwork. In this environment, a permissions boundary defines the maximum permissions an identity may receive but does not grant permissions by itself. No other policies apply.

Which operation can a developer perform under these policies?

Start and stop an instance, because the identity policy grants both and the boundary does not need to enumerate every denied action explicitly.
Modify an instance's network configuration, because the permissions boundary restricts only identity-management actions rather than compute resource operations.
Describe an instance only, because the boundary lists DescribeInstance first and a permissions boundary grants the permissions enumerated within it independently of the identity policy.
Start an instance, because that operation is permitted by both the identity policy and the permissions boundary, satisfying the intersection requirement.
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Cloud Iam Policies

Practice Cloud Iam Policies in Cyber Security with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Cloud Iam Policies, giving you a quick way to practice the rules, question types, and explanations that matter most for Cyber Security.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

Developers receive an identity policy allowing all actions on development compute instances. Their identities are also subject to a permissions boundary that allows only DescribeInstance and StartInstance. The boundary contains no statement for StopInstance or ModifyNetwork. In this environment, a permissions boundary defines the maximum permissions an identity may receive but does not grant permissions by itself. No other policies apply.

Which operation can a developer perform under these policies?

  1. Start and stop an instance, because the identity policy grants both and the boundary does not need to enumerate every denied action explicitly.
  2. Modify an instance's network configuration, because the permissions boundary restricts only identity-management actions rather than compute resource operations.
  3. Describe an instance only, because the boundary lists DescribeInstance first and a permissions boundary grants the permissions enumerated within it independently of the identity policy.
  4. Start an instance, because that operation is permitted by both the identity policy and the permissions boundary, satisfying the intersection requirement. (correct answer)
Explanation: 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.

Question 2

A company uses a cross-account access model in which a request must be allowed by the source principal's identity policy and by the target resource's policy. An explicit deny in either account overrides all allows. A role in the analytics account has an identity policy allowing ReadReport and DeleteReport on every report in the audit account. The audit account's resource policy trusts that role but allows it to perform only ReadReport on quarterly reports. No explicit denies apply.

Which statement correctly describes the role's effective cross-account access?

  1. It can read and delete quarterly reports because the identity policy allows both operations.
  2. It can read quarterly reports, but it cannot delete them because the resource policy lacks that permission. (correct answer)
  3. It cannot read quarterly reports because cross-account roles require matching policies with identical resource scopes.
  4. It can delete any report, but it can read only quarterly reports because resource policies constrain reads.
Explanation: 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.

Question 3

A cloud organization applies an organization-level guardrail listing approved regions and permitted service categories. The platform defines this guardrail as a maximum-permissions control: it can limit account-level IAM policies but cannot grant permissions. A developer's role currently allows only reading objects from storage. The guardrail permits key-management services in the developer's region, and no explicit deny applies to key creation.

Can the developer create a new encryption key in that region?

  1. Yes, because the guardrail permits both the approved region and the key-management service category, making those actions available to all principals.
  2. Yes, because the absence of an explicit deny in a guardrail effectively grants the listed services to all identities within the account.
  3. No, because organization-level guardrails that list permitted service categories implicitly deny all actions in those services to individual developer roles.
  4. No, because the guardrail establishes only the ceiling of permitted actions; an applicable identity policy must also grant key creation before it is authorized. (correct answer)
Explanation: 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.

Question 4

A company is preparing a least-privilege review. Employees may receive access through direct policies, nested groups, assumed roles, resource policies, and organization-level restrictions. Audit logs show which actions were used during the last 90 days, but some emergency permissions are legitimately required even though they were not exercised during that period.

Which review approach best supports an identity-first least-privilege decision?

  1. Remove every permission absent from the 90-day logs, because any access not exercised in that window cannot represent a current or documented business requirement.
  2. 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. (correct answer)
  3. Review direct user policies only, because inherited group memberships, assumed roles, and resource-based grants are evaluated separately after the identity authorization step completes.
  4. Retain all current permissions and rely on real-time anomaly detection alerts, because periodic access reviews lack the context needed to distinguish emergency privileges from routine unused access.
Explanation: 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.

Question 5

A continuous-integration service running outside the cloud needs to deploy an application several times each day. It currently stores a cloud access key in its secret vault. The service can obtain signed identity tokens containing repository, branch, and audience claims. The cloud IAM platform can validate those tokens and exchange approved tokens for short-lived role credentials.

Which change most effectively reduces credential risk while preserving automated deployments?

  1. Continue using the access key, but encrypt it with a key stored in the same deployment environment.
  2. Share one deployment key among repositories, then use audit logs to identify which repository used it.
  3. Trust validated workload tokens with restricted claims and issue short-lived credentials for a deployment role. (correct answer)
  4. Allow anonymous deployment requests from the service's fixed IP address and remove its stored access key.
Explanation: 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.

Question 6

A security-monitoring vendor operates a multi-tenant cloud service. Each customer configures a role that the vendor's service can assume to read that customer's security logs. The vendor uses the same service identity when making requests on behalf of different customers. The company wants to reduce the risk that another vendor customer could cause the service to assume the company's role.

Which trust-policy design best mitigates this confused-deputy risk?

  1. Trust the vendor service identity only when it presents a company-specific external identifier, and restrict the role to required logs. (correct answer)
  2. Trust every identity in the vendor's cloud account, but rotate the company's role name on a regular schedule.
  3. Trust the vendor service identity from any tenant, but require the resulting role session to use multifactor authentication.
  4. Trust the vendor's public network addresses, and allow the service to select any role session identifier it needs.
Explanation: 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.

Question 7

An organization adopts attribute-based access control. A policy allows a principal to administer a cloud resource when the principal's Project tag equals the resource's Project tag. Project owners correctly tag all resources. However, all employees can edit the Project tag on their own cloud identity.

Which control most directly addresses the resulting privilege-escalation path without abandoning attribute-based access control?

  1. Require project owners to retag resources each month and remove resources with missing project tags.
  2. Permit only a trusted provisioning process to set authorization-relevant identity tags and audit all changes. (correct answer)
  3. Allow employees to retain tag-editing rights but require multifactor authentication before each tag update.
  4. Add employees to project-named groups while continuing to let each employee select the matching identity tag.
Explanation: 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.

Question 8

A cloud environment evaluates applicable identity, group, and resource policies together. An action is authorized when at least one applicable policy allows it and no applicable policy explicitly denies it. A user has a direct policy allowing object reads from the financial-reports bucket. The user also belongs to a group whose policy explicitly denies all object-storage actions when requests originate outside the corporate network. The bucket policy allows authenticated company users to read objects. The user submits a read request from a personal network.

What is the expected authorization result?

  1. The request succeeds because the user's direct policy is more specific than the group policy.
  2. The request succeeds because both an identity policy and the bucket policy allow the read.
  3. The request fails because the applicable network-based explicit deny overrides the allow statements. (correct answer)
  4. The request fails because resource policies cannot authorize access requested through an identity policy.
Explanation: 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.

Question 9

Following an acquisition, a company must provide cloud-console access to 600 employees from the acquired company. The employees already authenticate through a corporate identity provider that supports federation and multifactor authentication. Security requirements prohibit separate long-lived cloud passwords and require access to end automatically when an employee is disabled at the identity provider.

Which IAM design best satisfies the identity-first requirements?

  1. Federate the identity provider, map validated group claims to cloud roles, and issue temporary role sessions. (correct answer)
  2. Create cloud users in bulk, copy identity-provider group names, and rotate their passwords every month.
  3. Create one cloud user per department, distribute its credentials, and restrict access through network locations.
  4. Synchronize permanent access keys to employee devices, then use the identity provider only for console authentication.
Explanation: 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.

Question 10

An engineer is allowed to assume an incident-response role whose role policy permits ReadObject and WriteObject on an evidence bucket. During role assumption, the engineer requests a session policy that permits only ReadObject. The platform treats session policies as additional maximum-permissions controls. The bucket policy permits the incident-response role to read and write, and no explicit deny applies.

What access does the resulting role session have to the evidence bucket?

  1. Read and write access, because the bucket and role policies both permit those operations.
  2. Write access only, because the session policy replaces the role policy rather than limiting it.
  3. Read access only, because the session's permissions are limited by the requested session policy. (correct answer)
  4. No access, because attaching a session policy prevents resource policies from recognizing the role.
Explanation: 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.