- Which review design BEST reduces excess privilege without incorrectly removing justified low-frequency access?
Answer: Review permissions against documented job tasks, flag usage anomalies, and require owners to justify or remove seasonal and unused access.
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.
- Which design MOST effectively limits privilege escalation through the pipeline?
Answer: 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.
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.
- Which architecture BEST approximates least privilege under this constraint?
Answer: Place the credential in a controlled gateway that authenticates operators and exposes only the three approved, validated, and logged operations.
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.
- Which access design provides the required coverage with the LEAST unnecessary privilege?
Answer: Allow task-specific role activation and enforce that the approver's identity must differ from the creator's identity for each payment.
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.
- Which redesign MOST effectively applies least privilege and limits the impact of credential compromise?
Answer: Create one identity per service and environment, scope it to required actions and resources, and use short-lived workload credentials.
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.
- Which workload policy is the MOST appropriate least-privilege design?
Answer: Allow object read on the input prefix, object write on the output prefix, input-key decryption, and output-key encryption only.
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.
- Which self-service policy BEST meets the requirement?
Answer: Require an immutable approved permission boundary on created roles and restrict role passing to approved roles and compute services.
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.
- Which policy design BEST applies least privilege?
Answer: Provide a masked aggregate view by default and activate case-bound, customer-filtered, read-only access to unmasked rows for four hours.
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.
- Which policy design BEST satisfies these requirements while minimizing standing privilege?
Answer: Keep administrators eligible for a scoped production role, activate it after independent approval, and issue an individually attributed 30-minute session.
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.
- Which access-policy design BEST enforces least privilege for the help-desk agents?
Answer: Require matching region and active-ticket attributes for each request, and deny resets when the target is the requester or another help-desk agent.
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.
