Exam AWS Certified DevOps Engineer - Professional DOP-C02 topic 1 question 26 discussion

SCPs (Service Control Policies) are the best way to restrict permissions at the organizational level, which in this case would be used to restrict modifications to the IAM role used by the auditing application, while still allowing trusted administrators to make changes to it. Options C and D are not as effective because IAM permission boundaries are applied to IAM entities (users, groups, and roles), not the account itself, and must be applied to all IAM entities in the account.

A and B are wrong because "SCP never grants permissions", as stated at https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html?icmpid=docs_orgs_console#scp-effects-on-permissions. C is wrong because you can't attach the permission boundary to an AWS account, only to IAM entities, https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html#access_policies_boundaries-eval-logic. D is the correct option.

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html?icmpid=docs_orgs_console

Service Control Policies (SCPs) in AWS Organizations can be used to enforce maximum permissions for member accounts. They don't directly grant permissions or create permission boundaries. So C & D can be ruled out.

SCPs are applied at the account or OU level and affect all IAM entities within that organization. IAM Permission boundaries are applied individually to specific IAM roles or users.

A is correct: < prevent any modification to the auditing application's IAM role> means scp A: <Include a condition that allows the trusted administrator IAM role> this is not the same as allow statement. So this option still valid B: SCP does not have allow statement C and D: These options make modification to permission boundary of the auditing application's IAM role, which is irrelavant. Other accounts may or may not assume this role.

AWS supports permissions boundaries for IAM entities (users or roles)

in option A, shouldn't the first half override the second half. Explicitly deny everybody( will not matter if later it says Allow Admin ).

A seems ok. For C its wrong as you don't use permission boundary to deny permission. You use it to specify what and what can be done and not what cannot be done.

For AWS Organizations the SCP is the way to go. So A.

An SCP would accomplish efficiently the task for all the accounts from a single place. A permission boundary is not for that, it would have to be configured in each account and for all the users IMHO.

It is A without a question. SCP is far more efficient.

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html?icmpid=docs_orgs_console

C is more suitable option here to restrict permission.

A permissions boundary is designed to restrict permissions on IAM principals, such as roles, such that permissions don’t exceed what was originally intended. The permissions boundary uses an AWS or customer managed policy to restrict access, and it’s similar to other IAM policies you’re familiar with because it has resource, action, and effect statements. A permissions boundary alone doesn’t grant access to anything. Rather, it enforces a boundary that can’t be exceeded, even if broader permissions are granted by some other policy attached to the role. https://aws.amazon.com/blogs/security/when-and-where-to-use-iam-permissions-boundaries/

mi vote is for C as the right answer

Only valid solution is A, for C or D you need to attach boundaries on all IAM roles/users not the account or the role itself.