A housing authority discovers a cross-account trust relationship that lets a partner agency's role read its model artifacts more broadly than the partnership actually requires. What is the correct remediation?
Select an answer to reveal the explanation.
Short Explanation
A trust relationship that's wider than the partnership itself is a spare key that opens more doors than the guest was ever supposed to use. Narrowing the policy's actions and resources keeps the partnership intact while closing off everything beyond what it actually requires. The fix is a smaller key, not no key and not a master key.
Full Explanation
The fix for an overly broad cross-account trust relationship is to narrow it — restrict the trust policy's permitted actions and resource scope to only what the partnership genuinely requires — which preserves the legitimate integration while closing the unintended over-access. Removing the relationship entirely treats a scoping problem as though the partnership itself were illegitimate, which breaks a working integration instead of fixing its permissions. Leaving the relationship unchanged out of concern for breaking the integration accepts an ongoing security exposure indefinitely rather than testing a scoped-down version, which is the actual risk being asked about. Granting administrator access instead of narrowing the policy moves in exactly the wrong direction — it trades a specific, auditable overexposure for a much larger one under the mistaken idea that broad grants are simpler to manage. Scope caveat: after narrowing a cross-account trust policy, confirm with the partner agency which specific resources and actions their workflow actually uses, since removing too much can break the legitimate parts of the integration. Operational check: have the partner agency exercise its normal workflow against the narrowed policy in a test environment and confirm it still functions before rolling the change out to production.