The repository becomes as consequential as the infrastructure itself
Infrastructure as code defines servers, networks, and permissions in versioned configuration rather than through direct, manual changes against live systems — bringing the same reviewability and reproducibility that code review provides for application logic. But it also means a merged configuration change is typically applied automatically, which shifts the actually consequential access question: not who can directly touch production infrastructure, but who can get a change merged into the repository that defines it.
Treated carelessly, access to the configuration repository and its deployment pipeline becomes functionally equivalent to direct production access, even for someone who never personally touches a live system — a distinction that's easy to overlook if review attention stays focused on 'who has production credentials' without accounting for the automated path that also leads there.
Reviewing the pipeline, not just the credentials
A thorough review of who can affect production infrastructure has to include the full path: who can propose a change, who can approve it, and whether the pipeline that applies approved changes has its own access properly restricted. A well-guarded set of direct production credentials sitting alongside a loosely-guarded deployment pipeline hasn't actually restricted access to production at all — it's just added a detour that still arrives at the same place.