Cloud Security interview questions: least-privilege
Reviewed by Mark Dickie · Last updated
7 questions on this page you can answer and see marked on the spot. Go to the first one
Least privilege is a security principle that grants an identity only the permissions it needs to do its job, and nothing more. In a cloud environment, this means scoping IAM policies, role assignments, and resource permissions to the narrowest set of actions on the narrowest set of resources. Interviewers test least-privilege because over-broad permissions are the root cause of most cloud breaches and the first thing an attacker escalates once inside.
On AWS, Azure, and GCP, least-privilege shows up in IAM policy writing, conditional keys, resource-level ARN scoping, and the gap between managed policies and custom inline policies. You should be able to read a policy statement, identify the excess permissions, and rewrite it tighter. Expect questions on Resource wildcards, Action wildcards, trust policies on roles, and how permission boundaries interact with identity-based policies.
| Concept | What an interviewer checks |
|---|---|
| IAM policy scoping | Can you replace "Resource": "*" with a specific ARN? |
| Action wildcards | Do you know why s3:* is too broad and what to narrow it to? |
| Conditional keys | Can you add aws:SourceIp or aws:RequestedRegion conditions? |
| Cross-account roles | Do you understand trust policies and external IDs? |
| Permission boundaries vs. SCPs | Can you explain the difference between a boundary and a deny? |
What does a least-privilege interview question look like?
Most questions give you a policy JSON snippet and ask you to find the problem. Others are scenario-based: a Lambda function needs to read one S3 bucket and write logs, and you must write the minimal policy. Some ask you to compare two approaches, like using a managed policy versus a custom inline policy, and explain the trade-offs in blast radius and maintainability.
How should I prepare for cloud security interview questions on least-privilege?
- Practice reading and writing IAM policy JSON by hand, without the console autocomplete.
- Memorize the common conditional keys for each cloud:
aws:SourceArn,aws:SourceAccount,aws:RequestTagon AWS; similar conditions exist on Azure and GCP. - Study the IAM access analyzer findings, since real interview scenarios are often drawn from the excess-permission patterns it flags.
- Learn the deny-evaluation order: an explicit deny always wins, then permission boundaries, then allow statements.
- Work through the difference between service control policies (SCPs), permission boundaries, and session policies, because interviewers love asking which one actually limits the effective permissions.
Key facts
- Tarmac has 11 Cloud Security interview questions on this topic, 10 of them on this page, at difficulty 1–5 of 5.
- Tarmac tracked 1,251 job postings asking for Cloud Security in September 2026.
- Roles asking for Cloud Security advertise a median base salary of US$177,500, across 232 job postings as of September 2026.
- Tarmac last reviewed these Cloud Security interview questions on 14 September 2026.
At a glance
| Questions | 10 shown · 11 in the bank |
|---|---|
| Difficulty | 1–5 of 5 |
| Formats | Multiple choice, Ordering, Multiple answer, Fill in the blank, True / false, Short answer, Flashcard |
What you'll review
- least privilege
Practice questions
Try one before you open the answer. Pick an option and press Check; it's marked on the spot.
In cloud IAM, what does the principle of least privilege require when you grant a workload or user access to a resource?#
Options
Show answer
Least privilege in cloud IAM means granting an identity only the specific actions it needs, scoped to the specific resources it uses. This limits the damage a leaked credential or compromised workload can cause. Broad roles, shared privileged accounts, and wildcard permissions all expand that blast radius, and audit logs detect misuse after the fact rather than preventing it.
Least privilege means an identity receives only the permissions required for its job, limited to the resources it needs. Granting the administrator role, sharing a highly privileged account, or using wildcard permissions all give an identity far more access than its task requires, which increases the blast radius if credentials are leaked or misused. Logging helps detect misuse but does not replace restricting permissions in advance.
You are tightening an over-permissioned cloud IAM role used by a production service. Put these steps in the order you should perform them, from first to last.#
Put these in order
Show answer
To tighten an over-permissioned cloud IAM role, first review which permissions the role actually used, then write a policy granting only those actions and resources. Attach the new policy and watch logs for access-denied errors. Only after that confirmation should you remove the old broad policy, since removing it earlier risks breaking the workload.
You must first learn which permissions the role really uses, since the new policy is derived from that usage data. Next, you write the policy that grants only those actions and resources. You then attach it alongside the existing setup and watch for access-denied errors to confirm nothing legitimate breaks. Only after that confirmation is it safe to remove the old broad policy; removing it earlier risks an outage before the replacement is proven.
An image-resize service runs under an AWS IAM role. It reads originals from one S3 bucket and writes thumbnails to a second bucket, and it never lists or deletes objects. Which of the following are valid applications of least privilege to this role's policy? Select all that apply.#
Options
Pick every one that applies.
Show answer
Least privilege for an AWS IAM role means granting only the actions and resources the workload needs. Restrict the Resource element to the specific buckets and object paths in use, and allow only the required actions such as s3:GetObject and s3:PutObject. Wildcard S3 permissions or temporary administrator access expand the blast radius of a compromise.
Least privilege means granting only the actions and resources a workload actually needs. Scoping the Resource element to the exact source and destination bucket paths, and allowing only the object actions the service uses (GetObject on the originals, PutObject on the thumbnails), both shrink what a compromised role could do. Granting wildcard S3 actions across all buckets, or attaching AdministratorAccess with a promise to remove it later, gives the role far more reach than the task requires and is the opposite of least privilege.
In AWS IAM, if no statement allows a request, access is refused by the default _____ that applies to every request. Granting a workload only the permissions it needs is known as the principle of least _____.#
Show answer
In AWS IAM, if no statement allows a request, access is refused by the default deny that applies to every request. Granting a workload only the permissions it needs is known as the principle of least privilege.
AWS IAM evaluates requests against a default deny: unless some applicable identity-based or resource-based policy contains an Allow that matches the action and resource, the request is refused. Because access must be explicitly granted, a team can keep permissions narrow by listing only the required actions and resources. This practice is called the principle of least privilege, which limits the blast radius if a credential is misused.
A backup service only needs to download existing objects under the S3 prefix arn:aws:s3:::reports-prod/daily/. Which IAM policy statement grants exactly the access it needs under least privilege?#
Options
Show answer
The least-privilege statement grants only s3:GetObject scoped to arn:aws:s3:::reports-prod/daily/*. A service that only downloads needs one read action on the specific prefix it uses. Wildcard actions such as s3:*, or wildcard resources, grant write, delete, or access to unrelated objects that the workload never requires.
Least privilege means granting only the actions and resources the workload actually uses. The service only downloads objects, so the single action s3:GetObject is sufficient, and scoping the resource to the daily/ prefix limits it to the objects it needs. The other options are broader: wildcard actions allow writes and deletes, and wildcard resources or a wider bucket prefix expose objects the service never reads.
True or false: An IAM policy that allows every S3 action (s3:*) on the objects in a single bucket (arn:aws:s3:::reports-bucket/*) satisfies least privilege, because its scope is limited to one bucket.#
Options
Show answer
A wildcard action such as s3:* scoped to one bucket is not least privilege. Least privilege limits both the resources and the actions granted. Scoping the resource alone still allows deleting, overwriting, and changing ACLs on every object, so policies should list only the specific actions a workload needs, such as s3:GetObject.
Least privilege constrains both the resources and the actions granted. Limiting the resource to one bucket's objects narrows scope, but s3:* still grants every object-level action, including deleting objects, overwriting them, and changing object ACLs. A workload that only reads reports needs just s3:GetObject on that ARN. Because the action set is unrestricted, the policy grants far more than the workload requires, so the statement is false.
A nightly Lambda function must read report files stored under the daily/ prefix of the S3 bucket reports-bucket. It must never read other prefixes, and it must never write, delete, or change any object. Which IAM Allow statement grants exactly the permissions this function needs?#
Options
Show answer
An IAM statement with s3:GetObject on arn:aws:s3:::reports-bucket/daily/* is the least-privilege grant. It allows only reading objects under the required prefix. Broader actions such as s3:*, or broader resources such as the whole bucket or *, grant access the function does not need.
Least privilege means limiting both the action and the resource to what the workload needs. The function only reads objects, so the action must be limited to s3:GetObject, which rules out s3:* because it grants write and delete. The function only needs the daily/ prefix, so the resource must be reports-bucket/daily/*; a statement covering the whole bucket grants reads from other prefixes, and a wildcard resource covers every bucket in the account. Only the statement with s3:GetObject scoped to reports-bucket/daily/* matches both constraints.
A production service runs under an AWS IAM role that was granted s3:* on arn:aws:s3:::* during a prototype and never narrowed. Describe a concrete process to reduce this role to least privilege without breaking the service, and name one preventive guardrail that stops a developer from re-broadening the role later. Assume the service has some infrequent jobs (for example, a monthly report) that must keep working.#
Show answer
First, measure actual use: enable or review CloudTrail data events for S3 and the role's service-last-accessed data over a window long enough to include the monthly job, so rare but required actions are captured. Second, generate a candidate policy from that observed activity (for example with IAM Access Analyzer policy generation) and scope it to the specific bucket and prefix ARNs the service touches, adding condition keys where useful. Third, roll the narrowed policy out in staging or as a new policy version, run the full workload including the monthly job path, and watch for AccessDenied events in CloudTrail before removing the broad statement. Guardrail: attach a permissions boundary to every role the developers are allowed to create or modify, so even an identity policy granting s3:* cannot exceed the boundary; alternatively, an organization service control policy that denies the broad S3 actions across accounts.
A strong answer treats least privilege as an evidence-driven loop rather than a one-time edit: it uses CloudTrail or service-last-accessed data over a window long enough to capture infrequent jobs, derives a policy from observed activity, scopes resources and conditions tightly, and validates the change before removing the broad grant. The guardrail must be enforced outside the role's own identity policy, such as a permissions boundary or an organization SCP, so that a future broad grant cannot take effect beyond the approved ceiling. Answers that only say 'remove the wildcard' without a way to discover required actions, or a guardrail that is itself editable by the same developer, are incomplete.
In AWS IAM, which of the following statements about how effective permissions are evaluated are correct? Select all that apply.#
Options
Pick every one that applies.
Show answer
In AWS IAM, an explicit Deny in any applicable policy overrides any Allow, and service control policies do not restrict the root user of the organization's management account. Permission boundaries and SCPs only cap permissions; they never grant them on their own, and a wildcard Allow remains limited by an attached boundary.
AWS evaluates all applicable policies together, and any explicit Deny (from identity, resource, SCP, permission boundary, or session policy) overrides every Allow. Service control policies apply to member accounts' principals and do not affect the management account's root user. A permission boundary is only a ceiling: it never grants access, so an identity policy must still allow the action, and a wildcard Allow in that identity policy is still capped by the boundary.
AWS IAM, least privilege: a role is assumed with AssumeRole and a session policy is passed. Considering only the role's identity-based policies, its permissions boundary, and that session policy (ignore SCPs, resource-based policies, and session tags), what is the exact condition under which a request for an action is allowed?#
Show answer
The action must be allowed by the identity-based policies AND allowed by the permissions boundary AND allowed by the session policy, and no applicable explicit Deny may match in any of them. The effective permissions are the intersection of the three allow sets, and an explicit Deny in any of them overrides all allows.
In AWS IAM, a permissions boundary and a session policy each act as an additional filter on top of identity-based policies rather than as grants. Evaluation for a same-account request requires an Allow from each applicable policy layer, so the effective permission set is their intersection. Any explicit Deny in any evaluated policy takes precedence over Allow statements, which is why the condition includes the absence of a matching Deny. The question deliberately excludes SCPs and resource-based policies, since those add further layers (SCPs intersect at the organization level, and a same-account resource policy can grant access without an identity-policy Allow), and including them would change the condition.
Related interview questions
Job market
See cloud-security salaries and hiring demand from live job postings.
The other 1 question
This page shows 10 and marks what you pick. That's as far as a page can go. A free account opens the other 1 and keeps every answer. What you miss comes back until it's right: after a day, then at longer gaps.
Free · the whole bank · 100 marked answers per 30 days · written feedback on the paid plan