When a member creates a fine-grained personal access token that targets organization resources, what enterprise/organization control commonly applies before the token can access those resources?
Select an answer to reveal the explanation.
Short Explanation
When you create a fine-grained PAT that touches org resources, many enterprises force an approval step so owners see who wants what access. That's a big improvement over classic PATs with a giant repo scope living forever in your shell history. Teach developers to request least privilege and expire tokens aggressively.
Full Explanation
The correct answer is that organization owners may be required to approve fine-grained PAT access to organization resources when approval policies are enabled. Fine-grained PATs support repository-level and permission-level scoping and can be governed with enterprise/organization policies, including approval workflows for org-owned resources. The claim that the token automatically receives enterprise owner privileges is wrong: PATs do not elevate users to enterprise owner. The claim that fine-grained PATs never require approval because they are always read-only is wrong: fine-grained tokens can request write permissions and are not inherently always read-only. The claim that only outside collaborators can create fine-grained PATs is wrong: members, not only outside collaborators, create PATs subject to policy. Administrators should prefer fine-grained over classic PATs, set maximum lifetimes, monitor token use in audit logs, and revoke promptly on offboarding.