A platform team lets product engineers create IAM roles for Lambda functions, but a recent review found wildcard permissions and privilege escalation via iam:PassRole. Engineers need flexibility without exceeding approved limits. Which least-privilege combination safely delegates role creation?

The correct combination is preventive and delegated because permissions boundaries set a hard maximum that no created role can exceed even if engineers write wildcard policies, while tightly scoped engineer identity policies ensure they can only call approved iam:CreateRole, iam:PutRolePolicy and iam:PassRole actions under defined conditions, preserving flexibility without privilege escalation. The Access Analyzer validation approach fails by assurance type because it provides point-in-time findings and refines PassRole targeting but does not enforce an immutable privilege ceiling at creation time. The mandatory tagging with automated audit approach fails by enforcement mechanism because ABAC and detective tag checks aid ownership and cost tracking but cannot stop an overly permissive policy from becoming effective. The CloudTrail monitoring with automated remediation approach fails by timing because detective controls revoke excessive permissions after deployment, leaving a window for Lambda role exploitation and violating the approved-limits requirement. On exams, do not confuse detective validation or monitoring with preventive capping when the stem emphasizes exceeding limits and PassRole escalation. In practice, verify by attempting to create a role with AdministratorAccess under the boundary and confirming denial, then confirming iam:PassRole succeeds only for approved Lambda roles within the boundary.