Cyber Security Quiz: Cloud Misconfigurations
10 questions · exam conditions
0:00
Cloud MisconfigurationsQuestion 1 of 10

A cloud storage bucket has an object ACL granting read access to everyone. The account also has an enforced setting that blocks all public access through bucket policies and ACLs. A security scanner reports the ACL as public, but an unauthenticated request to the object is denied.

Which conclusion BEST explains the current risk?

The object is publicly readable because an object ACL always overrides an account-level control.
The object is not currently public, but the ACL remains a latent risk if the blocking control is removed.
The object is private because unauthenticated requests cannot be authorized by object ACLs.
The object is publicly listable but not readable because account-level controls affect only object retrieval.
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Cloud Misconfigurations

Practice Cloud Misconfigurations 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 Misconfigurations, 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

A cloud storage bucket has an object ACL granting read access to everyone. The account also has an enforced setting that blocks all public access through bucket policies and ACLs. A security scanner reports the ACL as public, but an unauthenticated request to the object is denied.

Which conclusion BEST explains the current risk?

  1. The object is publicly readable because an object ACL always overrides an account-level control.
  2. The object is not currently public, but the ACL remains a latent risk if the blocking control is removed. (correct answer)
  3. The object is private because unauthenticated requests cannot be authorized by object ACLs.
  4. The object is publicly listable but not readable because account-level controls affect only object retrieval.
Explanation: When evaluating cloud storage access controls, you need to distinguish between what a configuration says and what actually happens at runtime. AWS S3 (and similar platforms) implement layered controls, where account-level "Block Public Access" settings act as a guardrail that overrides permissive ACLs — even when those ACLs explicitly grant public read. Here's the key insight: the Block Public Access setting doesn't delete the ACL; it simply overrides it at evaluation time. So the object is effectively private right now — unauthenticated requests are denied — but the ACL still exists in the configuration. This makes B the best conclusion: the object is not currently exposed, but the permissive ACL is a latent risk. If an administrator ever disables the block setting, public access would be immediately granted with no further changes needed. A is wrong because it inverts the actual priority order. Object ACLs do not override account-level Block Public Access controls — the account-level setting wins. This is a common misconception worth memorizing. C is wrong because it misidentifies why the request is denied. Unauthenticated requests can be authorized by object ACLs under normal conditions — the denial here is caused by the block setting, not by some inherent ACL limitation. D is wrong because it fabricates a distinction between "listable" and "readable" that doesn't reflect how account-level controls actually work. Block Public Access applies broadly to public access attempts, not selectively to retrieval operations. Your study tip: on security exams, watch for questions that separate current state from residual risk. A control masking a misconfiguration is not the same as fixing it.

Question 2

A storage policy contains an allow statement with a principal of everyone. The statement also requires the requester's organization identifier to equal the company's cloud organization ID. The bucket has no public ACLs, and organization membership is centrally controlled.

How should a reviewer interpret this policy?

  1. It is necessarily public because an everyone principal cannot be narrowed by a policy condition.
  2. It is anonymous-only because organization conditions do not apply to authenticated cloud identities.
  3. It is broadly shared within the organization, but the condition prevents ordinary internet-wide access. (correct answer)
  4. It grants access only to the bucket owner because organization conditions are evaluated locally.
Explanation: When you see a policy that combines a broad principal (like "everyone") with a condition, the critical skill is understanding that conditions actively restrict who the permission applies to — they don't just add metadata. Cloud IAM policies evaluate both the principal and all attached conditions together; a match requires satisfying both. Here, "everyone" as a principal sounds alarming, but the condition requiring the requester's organization ID to match the company's own organization ID is the gating factor. Only identities that belong to that specific cloud organization can satisfy the condition, which means arbitrary internet users cannot access the bucket. This makes C correct: the policy is broadly shared within the organization, but the condition blocks ordinary public internet access. A is wrong because it assumes conditions are meaningless modifiers on broad principals — in reality, IAM conditions are enforced during authorization evaluation. An "everyone" principal scoped by an organization condition is functionally equivalent to "everyone in this organization." B gets things backwards: organization conditions apply precisely to authenticated cloud identities, because only authenticated users have verifiable organization membership. Anonymous users would fail the condition, not pass it. D confuses "organization" with "owner." An organization in cloud IAM is a hierarchy containing many users and projects — not a single account. Reducing the grant to just the bucket owner would require explicit owner-only principal binding, which isn't described here. As a study tip: whenever you see "everyone" or a wildcard principal, immediately look for conditions — they are often what separates a dangerously public policy from a legitimately broad but internally scoped one.

Question 3

A bucket policy allows a partner account to upload objects into a shared bucket. The policy grants the partner both object-write permission and permission to replace the bucket policy. The partner does not currently have object-read permission.

Why is this configuration more dangerous than the intended upload-only design?

  1. The partner can change the resource policy and potentially grant itself or others broader bucket access. (correct answer)
  2. Object-write permission automatically includes permission to read every existing object in the bucket.
  3. Any cross-account upload makes the bucket anonymously readable until ownership is transferred.
  4. Replacing a bucket policy affects object retention settings but cannot alter authorization permissions.
Explanation: When you see a question about cloud storage permissions and cross-account access, think about privilege escalation — the ability for a limited user to expand their own access beyond what was originally intended. Here's the core danger: if a partner account can replace the bucket policy, they hold the keys to the kingdom. Even if they were only granted upload-only access initially, they can simply rewrite the policy to grant themselves (or anyone else) full read, delete, or administrative permissions. The original "limited" access becomes a launchpad for unlimited access. That's exactly what makes A correct — the write-policy permission completely undermines the intended upload-only design by letting the partner redefine the rules of the bucket itself. B is wrong because write permissions and read permissions are entirely separate in AWS IAM and bucket policies. Uploading objects grants no implicit ability to read existing ones — these must be explicitly authorized. C is a fabricated claim. Cross-account uploads do not automatically make a bucket publicly readable. Object ownership and ACLs can be configured carefully, but no such automatic anonymous-access behavior exists by default. D is also false and inverts reality. Bucket policies absolutely control authorization permissions — that's their primary purpose. Retention settings are managed separately through Object Lock configurations, not bucket policies. The key study tip here: on security exams, always ask yourself "can this permission be used to gain more permissions?" The ability to modify a policy document is almost always more dangerous than any single data-access permission, because it enables privilege escalation rather than just data exposure.

Question 4

A folder-level IAM policy grants a storage-object viewer role to all authenticated cloud users. A newly created project inherits that policy. Its bucket has no local public ACL or local IAM grant, but an employee from an unrelated company can authenticate with a cloud account and read an object.

Which remediation MOST directly addresses the cause while preserving intended internal sharing?

  1. Enable provider-managed encryption because inherited viewers cannot decrypt newly encrypted objects.
  2. Delete the bucket's local ACL because inherited IAM roles are evaluated only after local ACLs.
  3. Disable object listing because unrelated authenticated users can read only objects they can enumerate.
  4. Remove the inherited all-authenticated-users grant and replace it with a company-controlled group. (correct answer)
Explanation: When you see a cloud IAM question involving inherited policies and unintended access, your first instinct should be to trace where the permission originates and who it grants access to — not just how the access manifests. Here, the root cause is explicit: a folder-level policy grants the storage-object viewer role to all authenticated cloud users. That phrase is the vulnerability. "All authenticated users" in most cloud providers means anyone with any valid account on that platform — not just employees of your organization. Because the project inherits this policy, the unrelated employee's cloud account qualifies, and they gain read access. Option D directly attacks this root cause by replacing the overly broad principal (all authenticated users) with a company-controlled group, preserving internal sharing while closing the door to outsiders. This is the principle of least privilege applied at the identity boundary. Option A is a red herring — provider-managed encryption controls confidentiality at rest but doesn't affect IAM authorization. A viewer with a valid grant can still read encrypted objects; the cloud provider decrypts transparently. Option B misunderstands evaluation order. The scenario already states there is no local ACL, so deleting something that doesn't exist changes nothing. Also, in most providers, IAM and ACLs are evaluated in union, not sequentially. Option C targets enumeration, not authorization. Even without listing, if the employee already knows an object's path, they can still read it under the inherited grant. As a study tip: whenever a question mentions "all authenticated users" in a cloud IAM context, treat it as an automatic red flag — it almost always signals an overly permissive principal that should be scoped to an organization-controlled identity.

Question 5

An automation role used for nightly database backups has administrator access to the entire cloud account. Its workflow only creates snapshots, writes backup objects to one storage bucket, and records status in one logging service. The security team wants the most effective long-term correction without stopping backups.

Which action BEST addresses the underlying cloud misconfiguration?

  1. Rotate the automation role's credentials monthly while retaining administrator access.
  2. Limit the role to required backup actions and resources, then test the revised workflow. (correct answer)
  3. Shorten the role session duration while retaining the current administrator policy.
  4. Enable additional audit logging for every administrative operation performed by the role.
Explanation: When you see a cloud security question involving an over-privileged role or account, your first instinct should be to think about the Principle of Least Privilege (PoLP) — the foundational idea that any identity should have only the permissions it actually needs to perform its function, nothing more. Here, the automation role performs exactly three tasks: creating snapshots, writing to one storage bucket, and logging status. Yet it holds full administrator access to the entire cloud account. That's a massive, unnecessary attack surface. If the role were ever compromised, an attacker would inherit unrestricted control of the whole environment. The genuine fix — and why B is correct — is to rewrite the role's policy to permit only those specific actions on those specific resources, then validate the workflow still runs. This directly eliminates the misconfiguration at its root. A is a trap because rotating credentials doesn't reduce the scope of access. A stolen or leaked credential rotated monthly is still administrator-level for up to 30 days. Frequency of rotation doesn't substitute for limiting what the credential can do. C similarly misses the point. Shortening session duration adds friction but leaves the full administrator policy intact. During any active session, the role can still touch everything in the account. D improves visibility but does nothing to prevent damage. Audit logging lets you detect abuse after the fact; it doesn't constrain what the role is allowed to do. Detection is not remediation. Study tip: On security exams, distinguish between compensating controls (logging, rotation, session limits) and corrective controls (actually fixing the misconfiguration). Questions asking for the "best long-term correction" almost always favor removing the root cause over monitoring around it.

Question 6

A storage container rejects anonymous requests. A contractor can download one object by using a signed URL that expires in seven days. The contractor posts the URL in a public issue tracker, and external users download the object before expiration.

Which assessment is MOST accurate?

  1. The container has anonymous public access because any successful unauthenticated download proves a public ACL exists.
  2. The container's network firewall failed because signed URLs are evaluated only after network authorization.
  3. The exposed signed URL delegated temporary object access, even though the container itself rejects anonymous access. (correct answer)
  4. The object's encryption failed because encrypted storage cannot be downloaded through a publicly shared URL.
Explanation: When you see a question about cloud storage access controls, focus on the distinction between container-level permissions and object-level delegated access. These are separate mechanisms, and confusing them is exactly what the distractors exploit. The key concept here is the signed URL. Cloud platforms (AWS S3, Google Cloud Storage, Azure Blob) allow an authorized user to generate a time-limited URL that cryptographically delegates access to a specific object. Crucially, this works independently of the container's baseline policy. The container can — and in this scenario does — reject anonymous requests. But a signed URL embeds temporary credentials in the URL itself, so anyone possessing it can download the object until expiration. The contractor essentially handed strangers a temporary access token, not a permanent permission change. Answer C captures this precisely: the container's anonymous-rejection policy remained intact, but the signed URL delegated scoped, temporary access to the object. Answer A is wrong because no public ACL was ever set. Successful downloads happened due to the signed URL's embedded credentials, not a container permission change — those are fundamentally different mechanisms. Answer B is wrong because signed URLs are not evaluated at the network firewall layer; they are authenticated at the storage service layer via cryptographic signature verification. There was no firewall failure here. Answer D is wrong because encryption governs data confidentiality at rest or in transit — it has nothing to do with who is authorized to request a file. An encrypted object can still be downloaded by anyone holding valid credentials or a valid signed URL. Your study tip: always ask whether access was granted through identity policy (ACLs, IAM roles) versus delegated credentials (signed URLs, SAS tokens). Leaking a signed URL is a credential exposure problem, not a misconfiguration of the container's access policy.

Question 7

A build service is allowed to create compute instances and attach any existing service role to them. The build service cannot directly read the production secrets vault. One existing service role has permission to read all secrets, and instances launched by the build service can execute attacker-controlled startup commands.

Which IAM change would MOST directly prevent the build service from using its permissions to obtain production secrets?

  1. Restrict the roles the build service may attach to instances to an approved deployment role. (correct answer)
  2. Remove direct vault-read permission from the build service's own identity policy.
  3. Require multifactor authentication whenever an administrator reads a production secret.
  4. Encrypt production secrets with the cloud provider's default vault encryption key.
Explanation: When you see IAM questions involving privilege escalation, ask yourself: where does the actual exploit path run? The attacker's chain here isn't "build service reads secrets directly" — it's "build service attaches a privileged role to an instance, then uses attacker-controlled startup commands to harvest secrets through that role." Blocking the correct link in that chain is what this question is really testing. Answer A directly severs the attack path. If the build service can only attach an approved, least-privilege deployment role — not the all-secrets role — then no instance it launches can ever reach production secrets, regardless of what startup commands run. This is the principle of constraining role-passing permissions (sometimes called iam:PassRole restrictions in AWS), and it neutralizes the privilege escalation at its source. Answer B is a trap because the passage already tells you the build service cannot directly read the vault. Removing a permission it doesn't have changes nothing about the actual exploit chain. Answer C protects administrator access paths but does nothing about machine identities. An EC2 instance authenticating via an attached service role never triggers MFA, so this control is entirely irrelevant to the described attack. Answer D addresses data confidentiality at rest, not access control. Default encryption doesn't prevent an authorized role from decrypting and reading secrets — it only protects against physical media theft. The role with full read access can still retrieve everything. Study tip: On IAM privilege escalation questions, always trace the full attack chain before evaluating answers. The correct fix targets the weakest link in that chain, not a tangential control.

Question 8

A team configures a storage container so anonymous users cannot list its contents. During testing, an unauthenticated user who knows an object's exact URL successfully downloads that object. The team argues that the container is private because directory listing is disabled.

Which finding BEST describes the misconfiguration?

  1. Object-read access is public even though anonymous container listing remains disabled. (correct answer)
  2. Container listing is public because successful object retrieval implies list permission.
  3. The download must have used cached credentials because private objects cannot have direct URLs.
  4. Only object metadata is public because anonymous users cannot browse the container.
Explanation: Cloud storage systems enforce permissions at two distinct levels: the container (bucket) level and the individual object level. These are independent controls, and confusing them is one of the most common misconfigurations in cloud environments. When you see a question describing a "private" container where objects are still accessible, your instinct should be to check whether object-level permissions were configured separately from container-level permissions. In this scenario, disabling anonymous listing only prevents unauthenticated users from enumerating what objects exist inside the container — it says nothing about whether those objects can be read directly. If an object's read ACL is set to public, anyone with the URL can download it regardless of whether listing is disabled. That's exactly what happened here, making A correct: object-read access is public, even though container listing is disabled. These are two separate permission grants. B is wrong because it reverses the logic — successfully downloading an object does not imply list permission. A user can read a specific object without any ability to browse the container's contents. C is a fabricated technical detail; there's no mechanism by which a direct URL download implies cached credentials, and private objects can absolutely have valid URLs — their permissions simply block unauthenticated access. D is wrong because the anonymous user downloaded the full object, not just metadata; metadata-only access would mean a HEAD request succeeds but a GET request fails. The key study takeaway: in cloud storage, listing permission and read permission are orthogonal. Disabling one does not disable the other. Always verify object-level ACLs independently of container-level settings.

Question 9

A company stores customer exports in a bucket that is publicly readable. The bucket uses provider-managed encryption at rest, requires HTTPS in transit, and records access logs. An engineer states that these controls make the public-read policy acceptable because the files are always encrypted.

Which response BEST evaluates the engineer's claim?

  1. The claim is correct because encryption at rest prevents anonymous users from receiving plaintext objects, regardless of the access policy.
  2. The claim is correct because HTTPS authenticates each requester before the storage service returns an object, blocking unauthorized access.
  3. The claim is incorrect because authorized public reads are decrypted and delivered in plaintext despite storage and transport encryption. (correct answer)
  4. The claim is incorrect only if access logging is disabled, because without logs there is no mechanism to restrict who retrieves an object.
Explanation: When evaluating security claims, always ask yourself: what actually happens to data at the moment it reaches an authorized requester? Encryption protects data at specific points in its journey, but it doesn't determine who gets access — that's the job of access control policies. Here's the core issue: provider-managed encryption at rest means the storage provider automatically encrypts data on disk and decrypts it before serving it. When a public-read policy allows anonymous users to request a file, the storage service authenticates itself to perform the decryption on the requester's behalf, then delivers fully readable plaintext to that anonymous user over HTTPS. The encryption never protected against unauthorized disclosure — it only protected against physical media theft or provider-side breaches. This is exactly why C is correct: authorized public reads result in plaintext delivery, making the public-read ACL the actual vulnerability, regardless of how many encryption controls exist. A is wrong because it fundamentally misunderstands what encryption at rest protects against. It prevents someone from reading raw disk sectors, not from receiving objects through a legitimately granted HTTP request. B confuses authentication with authorization — HTTPS authenticates the server to the client (via TLS certificates), not the client to the server. It provides confidentiality in transit, not access control. D incorrectly frames logging as a restriction mechanism; access logs record who retrieved objects after the fact but do nothing to block retrieval in the first place. A useful rule of thumb: encryption ≠ access control. On exam questions, whenever someone claims encryption makes a permissive access policy "safe," that's almost always a red flag for exactly this misconception.

Question 10

A developer's identity policy allows all actions on all resources. A permissions boundary attached to the developer allows only read operations on development storage. A production bucket policy does not grant the developer access, and no other applicable policy allows production access.

What is the developer's effective access under these conditions?

  1. All cloud resources are accessible because the identity policy contains unrestricted wildcards.
  2. Only development storage reads are allowed because the boundary limits the identity policy's maximum permissions. (correct answer)
  3. Production storage reads are allowed because bucket policies are unnecessary for same-account identities.
  4. No access is allowed because attaching a permissions boundary converts every identity allow into a deny.
Explanation: When cloud providers evaluate access requests, they rarely consult just one policy — they layer multiple policy types together, and each layer can independently constrain what's allowed. The key concept here is the permissions boundary: a managed policy that sets the maximum permissions an identity can exercise, regardless of what the identity policy says. Think of it as a ceiling, not a grant. In this scenario, the developer's identity policy is wide open (all actions, all resources), which sounds powerful — but the permissions boundary caps effective access at read-only operations on development storage. Even though the identity policy would theoretically allow production access, the boundary filters out anything beyond its scope. The intersection of what the identity policy allows and what the boundary permits determines effective access. That intersection is development storage reads only, making B correct. A is wrong because wildcard identity policies don't override boundaries. A permissions boundary doesn't care how permissive your identity policy is — it enforces a hard ceiling regardless. C is wrong because the production bucket policy explicitly withholds access, and even if it didn't, the permissions boundary would still block production access since it only permits development storage reads. Bucket policies and boundaries are evaluated together, not independently. D is wrong because a permissions boundary doesn't convert identity allows into explicit denies — it simply limits the maximum scope of permissions. The developer still has access within that boundary. A useful mental model: permissions boundaries don't add access — they only subtract it. On exam questions, always check whether a boundary is present before assuming an identity policy's grants are fully effective.