Least-privilege policies (permissions boundaries, session policies, conditions): SCS-C03 study notes and practice questions
What to know about Least-privilege policies (permissions boundaries, session policies, conditions) for the SCS-C03 exam, from the Identity and Access Management domain (20% of the exam guide), then 1 free question to test it. Part of the SCS-C03 study guide.
These questions describe a team that needs to delegate some IAM work, a federated user who needs less than a role’s full access, or an over-broad policy that must be narrowed without breaking the workload. The answer almost always uses the smallest tool that caps permissions at the right layer. Know which layer each tool acts on.
The facts that decide answers
Identity-based policies grant permissions. Scope each statement to specific actions and resource ARNs, and add conditions where they help.
Permissions boundaries are managed policies that set the maximum permissions for a user or role. The effective access is the overlap between the boundary and the identity policy. A boundary never grants access on its own.
Delegation with boundaries: a policy can let developers create roles only when they attach a required boundary, using an iam:PermissionsBoundary condition.
Session policies are passed when a role is assumed. They intersect with the role’s policies for that session and cannot add permissions.
SCPs and RCPs set limits across accounts in an organization. SCPs do not grant permissions, and they do not apply to the management account.
Useful conditions:aws:MultiFactorAuthPresent, aws:SecureTransport, aws:RequestedRegion and aws:PrincipalOrgID. aws:SourceIp does not apply to calls that AWS services make on your behalf.
IAM Access Analyzer policy generation builds a policy from CloudTrail activity over a period you choose, which is the best starting point for narrowing an existing role.
iam:PassRole should name the specific roles a user may pass, not every role.
How to choose
Scenario wording
Pick
Developers create roles, but those roles can never exceed a ceiling
Permissions boundary, required through an iam:PermissionsBoundary condition
A federated session needs less than the role’s full access
Session policy at AssumeRole
Block a service or Region in every account, including future accounts
SCP
Restrict how resources can be accessed from outside the organization
RCP
Narrow an over-broad role to what it actually uses
Access Analyzer policy generation from CloudTrail
Require MFA for sensitive actions
Deny with aws:MultiFactorAuthPresent set to false
Require encryption in transit
Deny with aws:SecureTransport set to false
Common traps
Thinking a permissions boundary grants access. The role still needs an identity policy that allows the action.
Expecting an SCP to grant permissions. It only limits them.
Widening a policy with a wildcard resource to fix an access-denied error, instead of finding the missing action.
Relying on aws:SourceIp for calls made by AWS services.
Writing policies from scratch when Access Analyzer can generate one from real use.
A SaaS startup lets its developers create IAM roles for new Lambda functions and containers. Security wants developers to create their own roles, but no role may ever hold more permissions than the team's approved set.
The startup runs one development account, and its engineers ship new functions every week, so the control must not slow releases. Developers must not be able to remove or change that limit, and the approach must keep working when new AWS services are added to the approved set later.
Which solution meets these requirements?
Choose one answer.
AA. Give developers the AdministratorAccess policy, and turn on AWS CloudTrail alerts for IAM role changes. The security team will review the alerts each morning and remove any role that exceeds the approved set.
BB. Have developers request each role from the operations team through a ticket, and have operations create the role from a fixed template. Developers never create IAM roles directly in the account.
CC. Attach a service control policy to the development account that denies iam:CreateRole for all principals, including the deployment pipeline. Developers then request roles from the security team.
DD. Allow developers to create roles only when a managed permissions boundary that lists the approved services is attached, and deny any change to that boundary policy.
Show the answer and explanation
Answer: D
A. Wrong: Alerts detect problems after they happen, and developers would already hold any permission they need to grant themselves. The requirement is that no role can exceed the approved set, which needs a preventive control.
B. Wrong: A fixed template limits what each role can do, but every new role waits in a queue. This adds overhead for each Lambda and container change, and developers cannot self-serve as the startup wants.
C. Wrong: The deny stops role creation for developers, but it also blocks the deployment pipeline that creates roles for functions and containers. The startup wants developers to self-serve, so this option breaks the workflow.
D. Right: Correct. The boundary caps what any new role can ever do, whatever its identity policy says, and the deny on the boundary keeps developers from lifting the limit. Developers still create roles themselves, and a new service only needs the boundary policy updated. Learn more: Permissions boundaries for IAM entities (opens in a new tab)
Explanation
A permissions boundary sets the maximum permissions a role can have, and an IAM condition can require every role a developer creates to carry it. Denying changes to the boundary keeps the limit in place. Detection after the fact, ticket queues, and a blanket deny each miss one of the requirements.
Want more on Least-privilege policies (permissions boundaries, session policies, conditions)? The 5 full-length practice sets have 6 more Least-privilege policies (permissions boundaries, session policies, conditions) questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →
Study Least-privilege policies (permissions boundaries, session policies, conditions)