An organization uses AWS Organizations with separate accounts for finance and marketing. The finance team’s data processing app (in the finance account) uses Lambda and stores confidential data in a DynamoDB table. The marketing team (in a different account) must have access to only specific attributes of that DynamoDB table. How should a solutions architect provide the marketing team the required limited access?

The correct approach involves cross-account role assumption. The finance account, which owns the DynamoDB table, creates an IAM role with an inline policy that specifies fine-grained access to particular DynamoDB attributes using conditions. This role's trust policy is configured to allow the marketing account to assume it. The marketing account then creates an IAM role that has permission to assume the finance account's role. This establishes a secure, least-privilege access path. Incorrect options: SCPs are guardrails for maximum permissions within an OU; they do not grant access. Resource-based policies on DynamoDB tables can grant cross-account access, but the marketing account would still need an IAM role with permissions to access the table, not just a role to assume. This option is less explicit about the assumption mechanism. IAM permissions boundaries limit the maximum permissions an IAM entity can have; they do not grant access themselves. The primary mechanism for granting access remains the IAM policy attached to the role.