Create a role with a permissions boundary that permits creating policies and roles, and grant the developer access to assume it
A developer is creating a proof of concept for a new software as a service (SaaS) application. The application is in a shared development AWS account that is part of an organization in AWS Organizations. The developer needs to create service-linked IAM roles for the AWS services that are being considered for the proof of concept. The solution needs to give the developer the ability to create and configure the service-linked roles only. Which solution will meet these requirements?
Community Votes
100% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
A permissions boundary sets the maximum permissions a principal can hold, so attaching one that permits only the policy and role creation actions required satisfies 'the ability to create and configure the roles only' while the role itself carries those permissions (D). Option B's PowerUserAccess is far broader than the requirement and would grant the developer unrelated administrative capabilities. Option C denies iam:* outright, which prevents the very role creation the task requires. Option A routes access through a cross-account role in the management account, adding indirection without narrowing anything.
The developer needs to create and configure service-linked IAM roles for the proof of concept and nothing more. Creating an IAM role that carries the required permissions along with a permissions boundary that explicitly allows creating policies and roles caps what the developer can do to that scope, and granting the developer permission to assume the role delivers the access. The boundary is what keeps the developer's reach limited to creating and configuring roles rather than granting broader administrative capability.
Attaching the PowerUserAccess managed policy to an IAM group (B) — PowerUserAccess grants a broad set of administrative actions well beyond creating and configuring service-linked roles, so it fails the 'only' requirement even with MFA enforced. Adding an SCP that denies iam:* (C) — this blocks the developer from creating any IAM roles or policies at all, which is exactly the capability the task requires, so the task becomes impossible. trungtd's objection to A is that it adds complexity and risk, which is correct, but D remains the option that actually scopes the permissions.
Community Discussion (3 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
The requirement is to let the developer create and configure service-linked IAM roles, and only that. A permissions boundary is the AWS mechanism for capping the maximum permissions a principal can exercise, so creating an IAM role that holds the necessary permissions and attaching a boundary that permits creating policies and roles confines the developer to precisely that scope, while granting the developer access to assume the role delivers the access (D). This satisfies the least-privilege requirement directly: the boundary defines the ceiling, the role provides the capability within it, and no unrelated administrative permission is conferred.Why the Other Options Are Wrong
A creates an IAM user for the developer in the management account and a cross-account role in the development account, limiting the cross-account role's scope to common services. Besides the indirection of a separate user and cross-account role for a proof of concept, a scope limited to common services does not express the specific requirement of permitting only role and policy creation, so the boundary in D is the correct expression of that constraint. B adds the developer to an IAM group with the PowerUserAccess managed policy and enforces MFA. PowerUserAccess grants a broad administrative capability set far beyond creating and configuring service-linked roles, so it violates the 'only' in the requirement; MFA protects the authentication path but does not narrow what the principal may do. C adds an SCP to the development account with a Deny rule for iam:* in order to limit the developer's access. Denying all iam actions prevents the developer from creating any IAM roles or policies, which is exactly the capability the task requires, so the developer could not complete the proof of concept at all. D is the correct answer.Community Comment Notes
Community voted D unanimously. trungtd, whose comment carried the most weight, explained that A adds unnecessary complexity and security risk by involving a management-account user and cross-account role, and that PowerUserAccess is too broad, which is why D is preferred. TEC1 emphasized that D is more granular, granting the necessary permissions while maintaining least privilege and allowing the developer to create the required roles. tgv confirmed D without further comment. No alternative received support.Official Reference
Related Analysis
Practice All DOP-C02 Questions
Access 85 questions with complete answers and detailed explanations.
View Full DOP-C02 Practice Test →