Permissions, permission schemes, and issue security
Permissions in Jira Cloud operate at three levels, and questions usually test which level applies. Global permissions (administer Jira, create projects, browse users, manage groups) sit outside any project. Project permissions (browse projects, create issues, edit issues, transition issues, assign issues, assignable user, administer projects, manage sprints, set issue security, delete issues) are granted by a permission scheme to groups, project roles, individual users, or anyone/application access. Issue-level security is a second gate on top of Browse Projects: an issue security scheme defines levels, each level has members, and a user must be able to browse the project and be a member of the issue's security level.
Recommended practice is to grant permissions to project roles rather than individual users, because roles are per-project and scale when staff change; groups suit company-wide populations.
Traps: Anyone means logged-in users, plus anonymous only where anonymous access is separately enabled; a user who cannot see an issue may be blocked by the permission scheme, by issue security, or by a board or filter rather than by the project; administering a project does not grant access to global schemes; and editing a shared permission scheme affects every attached project. Use the permission helper before editing schemes.
Worked example: a contractor can browse a project but must not see HR issues. Do not revoke Browse Projects; add an issue security scheme, create a level containing the HR team, apply that level to the issues, and confirm the contractor lacks Set Issue Security.