Purpose of This Lesson

This hands-on lesson demonstrates how to use an AWS Organizations Service Control Policy (SCP) to restrict actions in a member account, including actions performed by users with administrative permissions. The workflow covers creating an organizational unit (OU), moving an account into it, creating an SCP that denies selected IAM role operations, attaching the policy to the OU, validating the restriction, and removing the policy.

Key Concepts

• Service Control Policy (SCP): An AWS Organizations policy that defines the maximum available permissions for accounts in an organization or organizational unit. An SCP does not grant permissions; it places limits on what principals in the affected account can do.
• Deny-list strategy: The organization initially uses a policy that allows everything by default. Specific actions are then blocked with explicit Deny statements.
• Organizational unit (OU): A logical container for AWS accounts. Attaching an SCP to an OU affects accounts placed within that OU.
• Explicit deny: A matching explicit deny overrides an otherwise available allow, including permissions granted through administrator access in the member account.
• Resource-specific restriction: The demonstrated policy targets a particular IAM role ARN rather than every IAM role.
• Management account versus member account: The SCP is created and managed from AWS Organizations in the management account, while its effect is tested by switching into the production member account.

Technical / Operational Context

Organization structure

The example organization begins with a root containing a management account and a production account. The workflow creates a prod OU and moves the production account into it:

Root
├── Management account
└── prod OU
    └── Production account

The SCP is attached to the prod OU, so the production account inherits the restriction because it is a member of that OU.

Policy design

The example SCP uses an explicit deny statement for several IAM API actions that could modify a protected role. The transcript identifies actions such as:

• AttachRolePolicy
• DeleteRole
• DeleteRolePermissionsBoundary

The policy’s Resource element contains the ARN of the specific role to protect. The role must therefore exist before the final SCP JSON is completed.

The demonstration creates an IAM role named test SCP in the production account, copies its ARN, and inserts that ARN into the policy document. The role’s business purpose is not important to the demonstration; it exists to provide a concrete protected resource.

End-to-end workflow

1. Enable SCPs if necessary. The lesson assumes SCPs were enabled previously. Enabling them is the prerequisite for using them.
2. Create an OU. In AWS Organizations, select the root, choose Actions → Create new organizational unit, and create prod.
3. Move the production account. Move the production member account into the prod OU.
4. Create the target IAM role. Switch to the production account, open IAM, create the test SCP role, and copy its ARN.
5. Complete the policy JSON. Insert the role ARN into the SCP’s Resource field and retain the explicit deny statements for the selected IAM operations.
6. Create the SCP. In AWS Organizations, open Policies → Service control policies, create a policy named deny modify IAM role, and paste the policy JSON.
7. Attach the SCP. Select the prod OU, choose its policies, attach deny modify IAM role, and confirm the attachment.
8. Test the restriction. In the production account, attempt to attach a policy to the protected role. The operation fails with an explicit deny from a service control policy. An attempt to delete the role also fails while the SCP remains attached.
9. Remove the restriction when testing is complete. Return to the management account, detach the SCP from the prod OU, and then verify that the role can again be deleted in the production account.

Exam- or Assessment-Relevant Takeaways

• An SCP is a permission boundary for an AWS account, not a replacement for IAM permissions. The account still needs IAM allows, but those allows cannot overcome a matching SCP deny.
• A member-account administrator can still be constrained by an SCP inherited from the account’s OU.
• To affect a particular account, place that account in an OU and attach the SCP to the OU, or apply the policy at another applicable organization level.
• When a requested operation fails despite administrative permissions, look for an explicit deny in an SCP as a possible cause.
• The policy’s resource ARN must identify the intended role. The role is created first so its ARN can be inserted into the SCP.
• The management account performs organization-level policy administration in this workflow; the member account is used to validate the policy’s effect.
• Detaching the SCP removes that organization-level restriction, which is why the previously blocked IAM operations succeed afterward.

Tool / Feature Decision Guide

Requirement	Appropriate choice	Reason
Restrict actions across an account or group of accounts	AWS Organizations SCP	SCPs limit the maximum permissions available in member accounts.
Apply one restriction to a production account grouped with similar accounts	Attach the SCP to a prod OU	Accounts in the OU inherit the policy, making the control easier to manage centrally.
Protect one role rather than all IAM roles	Use the role ARN in the policy Resource	The deny can target the specific role demonstrated in the lesson.
Verify that an administrative user is constrained	Test from the member account after attachment	The relevant behavior is whether the account’s IAM operation is blocked by the inherited SCP.
Restore the original permissions after a controlled test	Detach the SCP from the OU	Removing the policy removes the demonstrated organization-level deny.

Common Traps / Misconceptions

• “Administrator access can do anything.” Not when an applicable SCP contains an explicit deny.
• “An SCP grants access.” It does not grant permissions. IAM policies must still provide the required allow, subject to the SCP’s limits.
• “Creating an SCP automatically affects every account.” The policy must be attached at an applicable organization level, and the account must be within that policy’s scope.
• “The policy can be written before knowing the protected role.” This example requires the role ARN in the Resource field, so the role is created first and its ARN is then added to the JSON.
• “A failed delete means the IAM console is broken.” The failure can be the expected result of an explicit SCP deny.
• “Detaching a policy only changes the console display.” Detaching the SCP changes the effective permissions and allows the previously blocked operations to proceed, assuming the IAM permissions otherwise allow them.
• “The OU name alone enforces production controls.” The control comes from the SCP attached to the OU, not from the OU’s name.

Real-World Engineer / Analyst Notes

• Use OUs to organize accounts by environment or governance needs, such as production, and attach controls centrally rather than configuring every account independently.
• Test restrictive SCPs with a deliberately created resource before applying them to important production roles or accounts.
• Keep track of the management-account versus member-account context. Organization policy changes and member-account validation occur in different consoles or role sessions.
• Record the exact resource ARN and the IAM actions covered by the deny. A role-specific policy is narrower than an account-wide deny and should be reviewed for unintended gaps.
• Treat detaching an SCP as a permissions change. The lesson includes a warning because removing the policy immediately makes the blocked capabilities available again.
• When troubleshooting an authorization failure, inspect both IAM policies and AWS Organizations SCPs. An IAM allow does not cancel an explicit organization-level deny.

Quick Reference Summary

• SCPs must be enabled before they can be used.
• Create an OU and place the target member account inside it.
• Create the protected IAM role and copy its ARN.
• Build an SCP with explicit deny statements for selected IAM role operations and specify the role ARN as the resource.
• Attach the SCP to the OU.
• Test an attach-policy or delete-role operation from the member account.
• Expect an explicit SCP-deny failure even with administrator access.
• Detach the SCP from the management account to remove the demonstrated restriction.

Flashcards

Q: An IAM administrator in a member account cannot attach a policy to a role and the error mentions an explicit deny in a service control policy. What should be investigated first?
A: Check the SCPs inherited by the account from its OU or organization hierarchy. An explicit SCP deny overrides the administrator’s IAM allow.

Q: When should an SCP be attached to an OU instead of configured separately for one account?
A: Attach it to an OU when the same governance restriction should apply to accounts grouped there, such as production accounts. Accounts placed in the OU inherit the policy.

Q: What is the difference between an SCP and an IAM policy in this lesson?
A: The IAM policy supplies permissions, while the SCP limits the maximum permissions available to the account. An SCP does not grant access by itself.

Q: Why is the protected IAM role created before the SCP is finalized?
A: The policy targets a specific resource ARN. The role must exist so its ARN can be copied into the SCP’s Resource field.

Q: Which account performs the organization-level SCP attachment in the demonstrated workflow?
A: The management account administers AWS Organizations and attaches the SCP to the OU. The production member account is used to test the result.

Q: What happens when a deny policy targeting a role is attached to the role’s account scope?
A: Matching IAM operations against that role, such as attaching a policy or deleting the role, are denied even for an administrative user in the member account.

Q: Why does the example use a deny-list strategy?
A: The existing full-access policy allows actions by default, so the organization adds explicit deny statements only for operations it wants to disallow.

Q: What is the practical effect of moving the production account into the prod OU?
A: It places the account within the scope of SCPs attached to that OU, including the demonstrated deny policy.

Q: When would a role ARN be more appropriate than a broad resource specification in this example?
A: Use the role ARN when the goal is to protect one specific role rather than deny the selected IAM operations for every role in the account.

Q: What is the expected result of trying to delete the protected role while the SCP remains attached?
A: The deletion fails because the SCP explicitly denies the relevant role-deletion operation.

Q: What must be done to make the previously blocked role operations available again in this demonstration?
A: Detach the deny modify IAM role SCP from the prod OU. The member account can then perform the operations if its IAM permissions otherwise allow them.

Q: What is the authorization trap when an administrator can normally modify IAM roles but suddenly cannot?
A: Administrative IAM permissions do not override an applicable explicit deny. The denial may come from an inherited SCP rather than from the IAM role’s policies.

Practice Questions

Question 1

A production account contains a sensitive IAM role. Administrators in that account must retain broad access, but nobody should be able to delete the role or attach policies to it. Which implementation best matches the lesson?

A. Remove administrator access from every user in the account
B. Create an SCP with explicit denies for the relevant IAM actions and target the role ARN, then attach it to the production OU
C. Add an allow-only IAM policy to the role
D. Create a new IAM group and place the role in that group

Correct answer: B

Explanation: The lesson demonstrates using an SCP to deny selected IAM role operations and applying it through the OU that contains the production account. An SCP can constrain administrators in the member account.

Question 2

A policy has been created in AWS Organizations, but a test in the production account succeeds. What is the most likely missing step based on the demonstrated workflow?

A. Enable MFA for the management account
B. Attach the SCP to the OU containing the production account
C. Add administrator access to the protected role
D. Delete and recreate the production account

Correct answer: B

Explanation: Creating an SCP does not by itself put it into effect. The policy must be attached to an applicable organization level, such as the prod OU.

Question 3

An SCP is intended to protect one role, but the policy JSON contains the ARN of a different role. What is the decisive concern?

A. The SCP will automatically discover the intended role by its name
B. The deny may target the wrong resource, so the intended role may not be protected
C. SCPs can only target users, not roles
D. The management account cannot create policies containing ARNs

Correct answer: B

Explanation: The demonstrated policy uses a specific role ARN in its Resource element. The ARN must correspond to the role that should be protected.

Question 4

After validating the restriction, an engineer wants the production account to delete the test role. The account’s administrator still has the necessary IAM permissions, but deletion continues to fail. What should the engineer do?

A. Attach the same deny SCP again
B. Move the role into the management account
C. Detach the deny SCP from the prod OU and retry
D. Change the role’s name to match the OU name

Correct answer: C

Explanation: The lesson removes the restriction by detaching the SCP from the OU. Once the organization-level deny is gone, the existing IAM permissions can take effect.

WordPress Metadata

Suggested Slug:
aws-organizations-service-control-policies-scp-deny-policy

Meta Description:
Learn how to create an AWS Organizations Service Control Policy that prevents member-account administrators from modifying a protected IAM role.

Tags:
AWS Organizations, Service Control Policies, SCP, IAM, AWS security, AWS CloudOps, organizational units, explicit deny, AWS accounts, permissions boundaries