A SaaS company needs fine-grained tenant authorization for a document API, with developers defining policies in code, plus temporary on-premises build agents accessing S3 without stored long-term keys. The design must separate policy management from application code. Which authorization approach should the architect evaluate for human, application, and system access?

The correct design externalizes fine-grained decisions while removing static secrets: Amazon Verified Permissions centralizes Cedar policies written as code in a managed policy store for tenant-aware document checks, separating policy versioning, testing and audit from API deployment, while IAM Roles Anywhere lets on-premises agents authenticate with X.509 certificates to a trust anchor and assume a role for short-lived S3 access without stored keys. The Cognito scopes-and-groups design handles authentication and coarse tenancy well and can federate agents for temporary credentials, but OAuth scopes cannot scale to document-level context and force policy logic back into application code, violating the separated Cedar management requirement. The broker design preserves Verified Permissions yet issues agent credentials from a service using an IAM user, which reintroduces a long-lived secret requiring storage and rotation and therefore fails the keyless temporary access mandate and expands blast radius. The Lambda authorizer design appears policy-as-code by embedding a Cedar-style library, but compiling rules into the function couples authorization to code releases and loses centralized governance and consistent evaluation across human, application and system identities. On exams distinguish proving identity from deciding tenant-scoped permissions and recall Roles Anywhere is for non-AWS PKI workloads, not user pools or EC2 instance profiles. Practically confirm the policy store schema covers tenant attributes and document actions and verify the trust anchor, role profile and certificate rotation enforce least-privilege S3 access with CloudTrail.