Cyber Security Quiz: Designing Least Privilege Policies
10 questions · exam conditions
0:00
Designing Least Privilege PoliciesQuestion 1 of 10

An image-processing workload receives events containing the exact object key of each image in an input storage prefix. It reads the image, decrypts it with an input key, writes a transformed image to an output prefix, and encrypts the result with a different output key. Retries may overwrite the same output object. The workload never enumerates or deletes objects.

Which workload policy is the MOST appropriate least-privilege design?

Allow object read and bucket listing on the input bucket, object write and delete on the output bucket, and use of both encryption keys.
Allow object read on both prefixes, object write on both prefixes, and encryption and decryption with both encryption keys.
Allow object read on the input prefix, object write on the output prefix, input-key decryption, and output-key encryption only.
Allow object read on the input prefix and object write on the output prefix, using the storage service's full encryption-key permissions.
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Designing Least Privilege Policies

Practice Designing Least Privilege 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 Designing Least Privilege 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

An image-processing workload receives events containing the exact object key of each image in an input storage prefix. It reads the image, decrypts it with an input key, writes a transformed image to an output prefix, and encrypts the result with a different output key. Retries may overwrite the same output object. The workload never enumerates or deletes objects.

Which workload policy is the MOST appropriate least-privilege design?

  1. Allow object read and bucket listing on the input bucket, object write and delete on the output bucket, and use of both encryption keys.
  2. Allow object read on both prefixes, object write on both prefixes, and encryption and decryption with both encryption keys.
  3. Allow object read on the input prefix, object write on the output prefix, input-key decryption, and output-key encryption only. (correct answer)
  4. Allow object read on the input prefix and object write on the output prefix, using the storage service's full encryption-key permissions.
Explanation: Whenever you see a workload security question like this, anchor yourself to the principle of least privilege: grant only the permissions required to perform the described task — nothing more. Your job is to map each operation the workload actually performs to the minimum permission that enables it. The workload does exactly four things: reads an image from the input prefix, decrypts it using the input key, writes a transformed image to the output prefix, and encrypts that result using the output key. That's it. Option C mirrors this precisely — read on the input prefix, write on the output prefix, decryption with the input key, and encryption with the output key. Each permission has a direct, necessary job. This is the correct answer. Option A fails on two counts: it grants bucket listing (the workload never enumerates objects) and delete permission on the output bucket (the workload never deletes — retries just overwrite). Both are unnecessary privileges that expand the blast radius if the workload is compromised. Option B is overly broad in a different way: it allows read and write on both prefixes. The workload only reads from input and only writes to output — granting the reverse permissions on each bucket is pure excess, violating least privilege. Option D sounds reasonable but is dangerously vague. "Full encryption-key permissions" implies both encrypt and decrypt on both keys, when the workload only needs decrypt on the input key and encrypt on the output key. Granting full key permissions could allow unauthorized decryption of output data or re-encryption of input data. Study tip: For least-privilege questions, mentally simulate each step of the described workflow and check each answer for any permission that has no corresponding operation — extra permissions are red flags.

Question 2

Database administrators perform routine work without production-administrator privileges. Several times per month, one administrator must perform a production maintenance task requiring elevated access. Policy requires two-person authorization, sessions no longer than 30 minutes, and attribution of every privileged action to the individual administrator.

Which policy design BEST satisfies these requirements while minimizing standing privilege?

  1. Place administrators in a permanent production role, but require a second administrator to review privileged activity logs each week.
  2. Store a shared production credential in a vault, release it after peer approval, and rotate it after each maintenance session.
  3. Keep administrators eligible for a scoped production role, activate it after independent approval, and issue an individually attributed 30-minute session. (correct answer)
  4. Grant the production role automatically for 30 minutes when an administrator opens a maintenance ticket containing an approved change number.
Explanation: When you see privilege management questions like this, think about three pillars: least privilege (no standing access), accountability (individual attribution), and separation of duties (two-person control). The ideal design satisfies all three simultaneously. Option C achieves this perfectly. Administrators hold no standing production privileges — they are merely eligible for a scoped role. Activation requires independent peer approval (two-person authorization), the role is individually attributed so every action is tied to a specific person, and the session is automatically bounded to 30 minutes. Nothing is granted before it's needed, and nothing persists after. This is the textbook implementation of Just-In-Time (JIT) privileged access. Option A fails immediately on the "minimizing standing privilege" requirement — administrators permanently hold the production role. Weekly log review is a detective control, not a preventive one, and it does nothing to limit access before harm occurs. Option B is tempting because it uses a vault and peer approval, but the fatal flaw is the shared credential. When multiple people can use the same credential, individual attribution is impossible — you can't prove which administrator performed a specific action. Rotation after the session helps hygiene but doesn't fix the accountability gap. Option D skips the human peer-approval step entirely. Ticket automation with an approved change number is a system check, not independent human authorization. Two-person integrity requires a second person to actively approve, not a workflow rule to auto-grant access. Your study tip: watch for answers that satisfy most requirements but quietly violate one. Exams frequently hide a single fatal flaw — shared credentials killing attribution, or automation replacing human approval — to test whether you read carefully.

Question 3

Fraud analysts normally need aggregated transaction trends with customer identifiers masked. During an approved investigation, a designated analyst may view unmasked transactions for the specific customer and case for up to four hours. The analyst does not need to modify transaction data.

Which policy design BEST applies least privilege?

  1. Grant analysts read access to the transaction table and rely on the analytics application to mask identifiers unless a case is open.
  2. Provide a masked database view and grant temporary read access to the full transaction table after an investigation is approved.
  3. Provide a masked aggregate view by default and activate case-bound, customer-filtered, read-only access to unmasked rows for four hours. (correct answer)
  4. Create a separate unmasked table for investigations and grant each designated analyst permanent read-only access to that replicated table.
Explanation: When you see a question about access control policy, anchor your thinking to the three pillars of least privilege: minimum necessary access, just-in-time provisioning, and precise scoping. The goal is never to grant more access than the task requires — in terms of scope, permissions, or duration. The scenario tells you analysts normally need masked, aggregated data, but during approved investigations they temporarily need unmasked rows for one specific customer with no modification rights for four hours. The ideal policy mirrors those constraints exactly. Option C does precisely this — a masked aggregate view is the default, and elevated access is narrowly scoped to the relevant customer, read-only, and automatically expires after four hours. Every dimension of the exception is bounded. Option A fails because it delegates enforcement to the application layer rather than the database. Application-level masking can be bypassed, misconfigured, or exploited — the database itself should enforce access boundaries, not rely on downstream logic. Option B is closer but still too broad. Granting temporary read access to the full transaction table exposes every customer's data, not just the one under investigation. It violates the scoping requirement of least privilege even if the duration is temporary. Option D is the most dangerous choice. Replicating sensitive data into a separate table and granting permanent read-only access to designated analysts eliminates both time-bound and case-bound constraints entirely — a clear least-privilege violation hiding behind the word "read-only." As a study tip: on access control questions, watch for answers that get one dimension right (like read-only) while failing on scope or duration — those are the most common traps.

Question 4

An accounts-payable system has two sensitive actions: creating a supplier payment and approving that payment. At a small branch, the same employee may be trained for both duties and may cover either duty on different days. No payment may be both created and approved by the same person.

Which access design provides the required coverage with the LEAST unnecessary privilege?

  1. Assign both roles permanently, but require the employee to enter a different justification code when approving a payment they created.
  2. Allow task-specific role activation and enforce that the approver's identity must differ from the creator's identity for each payment. (correct answer)
  3. Assign only the payment-creator role and let a branch manager share an approval account when the regular approver is absent.
  4. Permit employees to hold only one role permanently and have administrators swap assignments whenever coverage needs change.
Explanation: When you see access-control questions involving conflicting duties, your mental anchor should be two principles working together: Separation of Duties (SoD) and Least Privilege. SoD means no single person completes a sensitive transaction end-to-end; Least Privilege means you grant only the access actually needed, nothing more. Option B satisfies both principles cleanly. By allowing task-specific role activation, an employee holds neither role permanently — they activate whichever role their current task requires. The system then enforces that the approver's identity must differ from the creator's identity for that payment. This gives the branch full coverage with zero standing over-privilege, making B the correct answer. Option A fails on Least Privilege. Permanently assigning both roles means the employee always has the ability to both create and approve, regardless of what they're doing that day. A justification code is a compensating control, not a preventive one — it documents abuse after the fact rather than blocking it architecturally. Option C is dangerous because it introduces shared credentials. When a manager shares an approval account, there is no individual accountability — you lose the audit trail that tells you who approved a payment, which undermines both SoD and forensic investigation. Option D addresses SoD but destroys operational flexibility. Forcing administrators to manually swap role assignments whenever coverage needs change introduces delays and administrative overhead, and it doesn't scale. The branch loses coverage exactly when it's most urgent. Study tip: On access-control questions, always ask two things in order — "Does this block the violation (not just log it)?" and "Does this grant more access than the task requires?" Any answer that fails either test is wrong.

Question 5

A managed service provider's help-desk agents support multiple customer tenants. An agent may view a customer's contact record and reset the customer's multifactor authentication only when the agent has an active ticket for that tenant and the tenant is assigned to the agent's support region. Agents must not reset their own accounts or accounts belonging to other help-desk agents.

Which access-policy design BEST enforces least privilege for the help-desk agents?

  1. Assign a regional help-desk role that permits viewing and resetting every nonadministrative account in tenants assigned to that region.
  2. Require matching region and active-ticket attributes for each request, and deny resets when the target is the requester or another help-desk agent. (correct answer)
  3. Grant reset access for the ticket's tenant after ticket creation, then remove the access automatically when the ticket is closed.
  4. Permit resets for all tenants through the support portal, but require agents to document a valid ticket number in the audit record.
Explanation: When a question describes a complex access scenario with multiple conditions, your instinct should be to look for an access-control model that enforces all of those conditions simultaneously — not just some of them. This is the essence of least privilege: grant only the permissions needed, only when they're needed, and with no room for abuse. The scenario establishes three distinct rules: agents must have an active ticket, that ticket must match the agent's region, and agents cannot reset their own or other agents' accounts. Option B satisfies all three by evaluating region, active-ticket status, and target-account type on every single request. Nothing is assumed in advance — access is granted or denied dynamically based on real-time attributes. That's the hallmark of Attribute-Based Access Control (ABAC), which is ideal when multiple contextual conditions must combine to authorize an action. Option A falls short because a regional role grants standing access to all non-admin accounts in a region, even when no ticket exists. That over-permission violates least privilege from the start. Option C is closer — it ties access to a specific ticket — but it still doesn't prevent an agent from resetting another help-desk agent's account during an active ticket window. The peer-reset restriction is simply absent. Option D is the most dangerous distractor. Requiring documentation in an audit log is a detective control, not a preventive one. It records abuse after it happens rather than blocking it. For exam questions about least privilege, always ask: does this policy prevent unauthorized actions, or merely detect them afterward? Prevention always wins.

Question 6

A vendor's management product exposes only one API credential type, which has administrative authority over all product functions. Internal operators need only three low-risk actions. The vendor cannot modify the product before deployment, and operators must not receive the administrative credential.

Which architecture BEST approximates least privilege under this constraint?

  1. Store the administrative credential in an enterprise vault and permit operators to retrieve it only after authenticating with multifactor authentication.
  2. Issue each operator a copy of the administrative credential, then use audit alerts to detect calls outside the three approved actions.
  3. Rotate the administrative credential daily and require operators to obtain manager approval before using it in the vendor interface.
  4. Place the credential in a controlled gateway that authenticates operators and exposes only the three approved, validated, and logged operations. (correct answer)
Explanation: When you encounter a constraint-based least privilege question, ask yourself: given what cannot change, which solution minimizes actual access rather than just controlling when or how full access is granted? Least privilege means an entity receives only the permissions necessary for its specific tasks — nothing more. The challenge here is that the vendor's API grants all-or-nothing administrative authority. You cannot fix the credential itself, so the architecture must compensate by acting as a filter between operators and that credential. Option D achieves this by introducing a purpose-built gateway. Operators authenticate to the gateway, which holds the administrative credential internally and never exposes it directly. The gateway translates operator requests into only the three approved API calls — validating inputs, blocking anything else, and logging every transaction. Operators effectively have three-action credentials, even though the underlying API credential is fully administrative. This is the closest approximation to least privilege available under the constraint. Option A fails because it still allows operators to retrieve the raw administrative credential after MFA. Once retrieved, the operator has unrestricted administrative authority — MFA controls access timing, not scope of permission. Option B is worse: distributing the credential to every operator and relying on alerts is detective, not preventive — abuse can occur freely and is caught only after the fact. Option C's daily rotation and approval workflow reduces the exposure window but doesn't restrict what operators can do once they have the credential; a slow approval process is not access scoping. Remember this pattern: compensating controls that restrict scope (gateways, proxies, wrappers) achieve least privilege; controls that only restrict timing or detection do not.

Question 7

Three microservices currently share one long-lived service account. The ingestion service writes to a queue, the processor reads that queue and writes results to storage, and the reporting service reads only approved result objects. Separate development and production environments use different resources.

Which redesign MOST effectively applies least privilege and limits the impact of credential compromise?

  1. Create one identity per service and environment, scope it to required actions and resources, and use short-lived workload credentials. (correct answer)
  2. Create one identity per microservice, allow each identity access to both environments, and restrict its permissions by application function.
  3. Retain one service account per environment, remove unused permissions, and rotate each account's long-lived credential every week.
  4. Create separate read-only and write-only shared accounts, then give each microservice whichever shared credential matches its primary operation.
Explanation: When tackling least-privilege questions, focus on two dimensions simultaneously: identity granularity (how many separate identities exist) and credential hygiene (how long those credentials remain valid). A strong design minimizes both the scope of what each identity can do and the window of opportunity if credentials are stolen. The gold standard is exactly what A describes — one identity per service and per environment, scoped only to the actions and resources each service actually needs, using short-lived workload credentials (like OIDC tokens or AWS IAM Roles Anywhere). This limits blast radius in two ways: a compromised ingestion-service credential in development cannot touch production storage, and because the credential expires quickly, attackers have a tiny window to exploit it. Every axis of separation adds a containment boundary. B fails because allowing each identity to span both environments eliminates the environment isolation boundary. A compromised processor credential in dev immediately threatens production data. C retains one account per environment, meaning all three microservices still share the same credential — if the reporting service is compromised, the attacker inherits write access to the queue and storage too. Weekly rotation helps slightly but doesn't fix the fundamental over-sharing problem. D sounds structured but actually reintroduces shared credentials — multiple microservices holding the same write-only account means a compromise of any of them exposes that shared identity's full write scope across all resources it touches. A useful pattern to remember: on exam questions about credential compromise, any answer that involves sharing credentials between services or environments is almost always wrong, regardless of how the permissions are framed.

Question 8

A company is redesigning quarterly access reviews. Current reviews show managers a list of role names, and most access is renewed without investigation. Security proposes automatically removing every permission not used during the prior 90 days. Some permissions, however, are required only during annual closing or disaster recovery.

Which review design BEST reduces excess privilege without incorrectly removing justified low-frequency access?

  1. Automatically retain all role-based permissions because the original role approval already established a continuing business requirement.
  2. Automatically remove every permission unused for 90 days and require users to request it again when an annual event begins.
  3. Ask managers to renew complete roles annually and provide raw activity logs only when a manager questions an assignment.
  4. Review permissions against documented job tasks, flag usage anomalies, and require owners to justify or remove seasonal and unused access. (correct answer)
Explanation: When you see a question about access reviews and least privilege, focus on the tension between over-provisioning (leaving excess access in place) and over-removal (stripping legitimate but infrequent access). The best control design must handle both failure modes. Option D succeeds because it builds the review around documented job tasks rather than raw usage alone. By flagging anomalies and requiring owners to actively justify seasonal or low-frequency access, it creates a human checkpoint before anything is removed. Annual-close permissions and disaster-recovery rights are documented as legitimate exceptions, so they survive review — but they must be defended, not silently retained. This is the principle of risk-informed, context-aware privilege management. Option A fails because it assumes the original role approval is a permanent, self-sustaining justification. Roles evolve, people change jobs, and business needs shift — a one-time approval cannot account for ongoing relevance. This is the classic "set it and forget it" trap that perpetuates privilege creep. Option B is appealing because automation sounds efficient, but a hard 90-day cutoff ignores documented exceptions. Removing annual-close or disaster-recovery permissions and forcing re-request during a crisis introduces operational risk — exactly the scenario the passage warns you about. Option C partially improves on the current state but keeps the core flaw: managers reviewing complete roles by name rather than individual permissions. Providing raw logs only on request means most access still gets rubber-stamped, just on an annual cycle instead of quarterly. For the exam, remember: good access-review design combines usage data, documented justification, and human accountability — no single factor alone is sufficient.

Question 9

A cloud platform team wants developers to create workload roles without waiting for a central administrator. Each workload role must remain within an approved permission ceiling, and developers must not be able to create a role and attach it to an unapproved compute service to gain its permissions.

Which self-service policy BEST meets the requirement?

  1. Allow developers to create roles and policies freely, but alert the security team whenever a role includes permissions outside the approved ceiling.
  2. Allow developers to create only roles with approved names and deny them permission to attach administrator-managed policies to those roles.
  3. Provide approved role templates, but let developers remove the permission ceiling when a workload requires an unsupported cloud service.
  4. Require an immutable approved permission boundary on created roles and restrict role passing to approved roles and compute services. (correct answer)
Explanation: When a question asks about self-service IAM in the cloud, focus on two security properties: preventing privilege escalation and enforcing an immutable ceiling. Developers creating their own roles is risky unless the system structurally prevents them from exceeding approved permissions or weaponizing those roles against privileged services. Option D satisfies both properties simultaneously. A permission boundary is an IAM mechanism that sets the maximum permissions a role can ever have — even if a developer attaches a broader policy, the boundary caps what's actually granted. Requiring this boundary to be immutable (developers can't remove or weaken it) enforces the ceiling without central bottlenecks. Restricting role passing to approved roles and compute services closes the privilege-escalation path where a developer crafts a permissive role and attaches it to a privileged service (like a Lambda function or EC2 instance) to inherit those permissions indirectly. Option A is reactive, not preventive — alerting after a misconfiguration is already created leaves a window of exposure and relies on humans to remediate quickly. Option B restricts naming conventions and policy attachment, but naming rules are trivially bypassed and don't cap actual permissions; a developer could still craft an inline policy with excessive rights. Option C is the most dangerous distractor: allowing developers to remove the permission ceiling "when needed" destroys the entire control — an attacker or careless developer simply claims they need an unsupported service to escape the boundary entirely. Study tip: On cloud security questions, watch for controls that structurally prevent harm versus controls that merely detect or discourage it — the former is almost always the stronger answer.

Question 10

A continuous-delivery pipeline registers application task definitions and deploys them to one production service. The application tasks need a runtime role that can read a specific configuration path and publish to a specific message topic. The pipeline itself does not need either application permission. Registering a task definition requires the pipeline to pass the runtime role to the container service.

Which design MOST effectively limits privilege escalation through the pipeline?

  1. Grant the pipeline the runtime role's permissions directly and allow it to pass any role whose name begins with the application's prefix.
  2. Allow deployment only to the named service and passing only the scoped runtime role to the container service; keep data permissions on that runtime role. (correct answer)
  3. Allow deployment to every service in the production cluster, but require all task definitions to use the same centrally managed runtime role.
  4. Allow the pipeline to create and pass application roles as needed, while denying it direct access to the configuration path and message topic.
Explanation: When a pipeline needs to pass a role to another service, it gains a subtle but dangerous capability: if the pipeline can pass any powerful role, an attacker who compromises the pipeline can escalate privileges far beyond what the pipeline itself should have. The design challenge is to let the pipeline do its job without becoming a privilege-escalation vector. The most effective control is to constrain both dimensions of what the pipeline can do: limit where it can deploy (only the named service) and limit which role it can pass (only the specific scoped runtime role). This is exactly what B does. By keeping the data-plane permissions — reading configuration, publishing to the topic — on the runtime role rather than the pipeline role, the pipeline never touches sensitive data directly. An attacker exploiting the pipeline still can't reach those resources without separately compromising the runtime role. A is dangerous because allowing the pipeline to pass any role matching a name prefix is a weak boundary. An attacker could register a malicious role with that prefix and pass it, escalating privileges through the naming convention alone. C sounds controlled because of "centrally managed," but allowing deployment to every service dramatically widens the blast radius. A compromised pipeline could push malicious task definitions cluster-wide. D lets the pipeline create and pass roles dynamically. Even if direct data access is denied, the ability to create roles means the pipeline could craft a role with whatever permissions it wants — a textbook privilege escalation path. When you see pipeline-plus-role-passing scenarios, always ask: is the pass permission scoped to the minimum necessary role and target? That constraint is the core of the correct answer.