Is it possible to start AWS SCP with a default blacklist--and incrementally add rights?

Question

In a Pluralsight SCP course I'm working through, the instructor (Brian Eiler) described the normal state of affairs (with the Root having AWSFullAccess), but then went on to say that it could be handled the other way around–that it's possible to give the root account an SCP that grants nearly nothing and have child OUs/Accounts add permissions to that minimal set.

For learning purposes I thought I'd try this out. I proceeded as follows.

I created a new SCP: No-op

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Statement1",
      "Effect": "Allow",
      "Action": [
        "iam:GetLoginProfile"
      ],
      "Resource": "*"
    }
  ]
}

I added this No-op policy to the Organization Root account and then detached the standard FullAWSAccess SCP.

I next proved out that a user with full account rights could not list, let alone create, an EC2 instance in an account under the organization named Fun-One. So far, so good.

I then created a new SCP policy: Allow-EC2

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Statement1",
      "Effect": "Allow",
      "Action": [
        "ec2:*"
      ],
      "Resource": "*"
    }
  ]
}

I added the Allow-EC2 SCP policy to Fun-One and expected that admin user to now be able to list and create EC2s.

Not so.

I tried many things. Nothing worked. But when I added the Allow-EC2 SCP to the root OU, the admin user was able to list and create EC2s in Fun-One.

So it appears the tale I was told is not true. I've provided that material (down below) as an "answer" to this post.

My question is this: who is confused? Me? Or the instructor?

POSTSCRIPT:

Rohit's answer matches my experience. If Service X is denied (even implicitly) in OU A, then no child OU/Account under OU A can ever permit Service X. End of story. What the instructor said is simply not true.

Answer 1

You are correct if there is deny at organization level, it won't check anything downwards.

Default Way - Restrict S3 Access for an Organization Unit:

• you already have FullAWS Access in SCP
• restrict S3 Access by adding DENY S3

You can Implement otherway around: For Example: I have an OraganizationUnit where I only want S3 Access:

• I will remove FullAWSAccess and only Allow S3 Access.

Facts to understand before designing these type of policies.

• Deny wins over allow, if in the same policy you have a deny statement and an allow statement for the same service/action, DENY WINS.
• if you won't allow, it will be considered deny.
• you must understand why these policies are used at given stage, for example Organization Unit SCP is to control various services at account level. If an organization unit must only read data from S3 and won't update, I will only allow read for that organization unit.
• you must understand implicit and explict deny that I have mentioned at the bottom of this anwser.

I think better way to design policy approach is to understand policy evaluation logic.

I use this diagram before designing any policy, more details are here in aws documentation

Further There are two type of denies:

• Explicit: when you mention deny in the effect of policy
• Implicit: when you mention allow in the effect but operation that is not mentioned will be considered as implicit deny.