Multiple development teams deploy production workloads into a shared production AWS account. Recently, members of one development team terminated an EC2 instance belonging to another team. Developers use SAML federation via AWS Organizations to assume roles. You must prevent developers from managing instances belonging to other teams while still allowing them to manage their own instances. Which strategy meets these requirements?

The correct answer uses AWS STS session tags and an IAM policy to enforce resource ownership. By passing a DevelopmentUnit attribute as an STS session tag during SAML federation, the principal's session is tagged with their team. The IAM policy then uses a Deny statement with StringNotEquals on both the resource tag (DevelopmentUnit) and the principal tag (aws:PrincipalTag/DevelopmentUnit). This ensures that developers can only manage resources tagged with their own DevelopmentUnit, preventing them from affecting resources belonging to other teams. Incorrect options: Creating separate OUs and SCPs for each development unit is overly complex and does not directly address the need for fine-grained, tag-based control within a shared account. An SCP with an allow action and StringEquals assigned to the root OU would not prevent cross-team access; it would only allow access to resources matching the principal tag, but wouldn't explicitly deny access to others. Assigning separate IAM policies based on DevelopmentUnit during federation is not how IAM policies are assigned. Policies are attached to roles or users, not dynamically assigned per session in this manner.