Organizations use policies to create controls that are applied to accounts. A policy is a document containing one or more rules. Standard policies are used for defining backups, tag keys with allowed values, how artificial intelligence services store and use content, and service control policies that we will discuss in this section. Policies can be applied at different levels in your OU hierarchy and flow downward. If you apply a policy at the root level, then that policy would be applied to all accounts in all OUs. However, if you apply a policy to a specific OU, then the policy would apply to all accounts contained in that OU including any nested OUs you may have created. A policy attached to one of the nodes in an organization’s hierarchy flows down and affects all branches, OUs, and leaves. Accounts that are underneath policies are inherited from above and additive to policies at lower levels.
Service control policies (SCPs) are created to define and enforce what actions IAM users, groups, and roles can perform and are blocked from performing in the accounts in your organization that the SCP is applied to. SCPs are explicitly defined; if a right is not granted, it is by default denied. This works the same as IAM where an empty IAM policy is an implicit DENY. If you attach an empty SCP to an account, this is the same as attaching a policy that explicitly denies all actions. Permissions in an account that has an SCP attached are a combination of what the SCP allows and what is allowed explicitly in the permissions attached to the principal. For example, if an SCP applied to an account denies all S3 operations, then that account cannot manage S3. However, if the SCP permits S3 console operations, then the account would also have to configure rights and policies for S3 operations as if it were a non-organization–managed account. SCP allows the right for accounts to perform actions, but these actions still need to be defined in the account. When the organization account blocks access to a service or API action for a member account, a user or role in that account can’t access any of the prohibited services or API actions, even if an administrator of a member account explicitly grants such permissions in an IAM policy. The organization account overrides all member accounts.
SCPs can be created and managed only at the root account, and any lower levels cannot modify, add, or delete SCPs. You can use the IAM policy simulator to test the effects of SCPs. The IAM policy simulator is helpful for analyzing effects of individual principals in an account.
To add an account into your organization, you must send out an invitation to the account owner to join. This can be issued only by the organization’s management account and is extended to either the account ID or the email address that is associated with the invited account. When the invited account accepts the invitation, it then becomes a member account in the organization.
You can also send invitations to existing member accounts if you need to change from supporting only consolidated billing to supporting all features. Invitations work when accounts exchange handshakes, which is a multistep process of exchanging information between two parties. Handshake messages are passed between and responded to by the handshake initiator, which is the management account and the recipient or member account.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
