Day-five deployability is a sequencing problem, not a permissions problem. The goal is not to hand a new engineer the keys to production; it is to stage access so that each grant is justified by a rehearsed task, and to make the first production deploy a supervised drill with a rollback path the engineer has already walked. For a team of two to fifteen engineers who are their own on-call rotation, the scarce resource is attention. Staging access so the new engineer can self-serve read-only investigation early buys back senior time that would otherwise be spent answering “what does this dashboard mean” questions.
Start with read-only observability, not deploy rights
The first grants should let the new engineer see the system without changing it. That means read-only access to logs, metrics, dashboards, and the deployment history. In AWS, this is a role assumed through federation with an identity provider, not an IAM user with long-lived credentials. AWS’s IAM best-practices page states plainly: “Require human users to use federation with an identity provider to access AWS using temporary credentials.” The same posture applies on GCP, where Google Cloud advises avoiding user-managed service account keys and using other authentication methods whenever possible.
Read-only access is not a courtesy. It is the prerequisite for every later grant. A new engineer who can query the last deploy’s commit SHA, the error rate during that window, and the relevant log lines can form a hypothesis before asking for production write access. That is the difference between a grant that is earned by a rehearsed action and one that is assigned by a checklist.
Stage the sequence by task rehearsal
The sequence that works for small teams looks like this:
- Read-only observability and logs. The engineer can inspect production state but not mutate it.
- Non-production deploy. The engineer deploys to staging or a scratch environment, using the same pipeline that production uses. This rehearses the deploy path without production risk.
- Production deploy behind a supervised change. The first production deploy is paired with a rollback rehearsal and a synthetic check. The engineer sees the failure path, not just the happy path.
- Break-glass and credential-issuing paths last. These are the grants that can cause the most damage if misused, and they are the least necessary for a first deploy.
Each step should be preceded by the new engineer demonstrating the read-only or non-production version of the task. A day-three task might be: restore a non-production database from the latest backup into a scratch environment and diff row counts against the source. That rehearses the restore path, surfaces whether the backup is actually restorable, and justifies the restore-credential grant with an observed action rather than a role name.
Default to temporary credentials and least privilege
AWS recommends granting only the permissions required to perform a task, starting broad only while exploring and then reducing toward least privilege. In practice, that means starting with a narrow role and widening only against observed activity. IAM Access Analyzer can generate least-privilege policies based on access activity logged in CloudTrail, which is a more reliable signal than a role template written from memory.
For human access, temporary credentials via federation are the default. Long-lived access keys are the exception, and the exception should be documented. AWS notes that some use cases require long-term credentials, such as workloads that cannot use IAM roles or third-party clients that do not support IAM Identity Center. Those are workload cases, not human onboarding cases. If a new engineer needs a long-lived key to deploy, that is a signal that the deploy path itself needs work.
On GCP, the equivalent discipline is avoiding user-managed service account keys. Google Cloud warns that service account keys can become a security risk if not managed carefully, and that the main threats include credential leakage, privilege escalation, and non-repudiation. The recommended mitigation is to avoid user-managed keys and use other authentication methods whenever possible. Where keys are unavoidable, Google Cloud recommends routinely rotating all keys you manage, including service account keys.
One tradeoff worth naming: setting an expiry time on a service account key can cause workloads to fail when the key expires. Google Cloud advises against expiry times for production workloads for this reason. The safer pattern for production is a key that does not expire, managed through rotation, rather than a key that expires and takes a service down with it.
Make the first production deploy a drill
The value of day-five deployability is not that the engineer has “full access.” It is that the team has a working rollback path and a synthetic check, and that the new engineer has walked both. A supervised first deploy should include:
- A pre-agreed rollback command or pipeline action, rehearsed in non-production.
- A synthetic check that fires if the deploy breaks a known path.
- A named person who is watching the deploy and can call the rollback.
- A short written record of what was deployed, what was checked, and what would have triggered a rollback.
This is where backup and recovery drills intersect with access sequencing. PostgreSQL’s documentation states that you should set up and test your procedure for archiving WAL files before you take your first base backup. The same logic applies to access: test the rollback path before you grant the deploy right. If the new engineer’s first production deploy is also the first time anyone has run the rollback in six months, the drill is doing double duty, and that is a feature, not a bug.
For file-level restores, restic’s restore command supports a --dry-run option that prints information about what would be restored without running the full restore. That is a useful rehearsal step for a new engineer: run the dry-run, read the output, then run the real restore into a scratch target. restic also warns that restoring data in-place can leave files in a partially restored state if the restore operation is interrupted, and recommends creating a current backup before restoring a different snapshot. A new engineer who has read that warning and practiced the safe path is better prepared than one who has only been granted the role.
Write the offboarding and review dates into the same ticket
If the grant has no scheduled review, it is a permanent grant in practice regardless of intent. AWS recommends regularly reviewing and removing unused users, roles, permissions, policies, and credentials. The practical way to do that for a small team is to put the review date and the offboarding path in the same ticket that grants day-one access. When the engineer leaves, or when the project ends, the ticket already contains the list of what to revoke.
This is also where blameless postmortem culture connects to access hygiene. Google’s SRE book describes blameless postmortems as a tenet of SRE culture that focuses on contributing causes without indicting an individual or team. The same posture applies to access reviews: the question is not “who granted this,” but “what task justified this grant, and is that task still happening?” Google’s SRE book also recommends defining postmortem criteria before an incident occurs so everyone knows when a postmortem is necessary. Defining access-review criteria before onboarding occurs serves the same purpose.
What can wait until after day five
Not every grant needs to be in place for a first deploy. The following can typically be deferred without blocking a supervised production deploy:
- Break-glass access to credential-issuing systems.
- Write access to production data stores, beyond what the deploy itself requires.
- Access to billing, cost-management, or account-level settings.
- Permission to modify IAM policies, roles, or service accounts.
- Access to backup repositories in a write or delete capacity.
Deferring these grants is not a lack of trust. It is a recognition that each one carries a different blast radius, and that the first week is better spent rehearsing the deploy and rollback paths than accumulating permissions that will not be exercised until later.
Monitoring and escalation access
A new engineer who is joining the on-call rotation needs to understand the escalation path before they need to use it. PagerDuty documents that integrations can be configured via email, API, or MCP, and that an email integration is created with its own email address. For a small team, the practical step is to add the new engineer to the escalation policy in a shadow capacity first: they receive the page, but a senior engineer is primary. That gives them the context of what pages look like without the pressure of being the first responder.
The same logic applies to synthetic checks. A new engineer should be able to see the check, read its history, and understand what a failure looks like before they are responsible for responding to one. If the team has a runbook for the check, the new engineer should read it and, ideally, update it with anything that was unclear. That is a low-risk way to contribute to operational knowledge while still building context.
FAQ
Does this mean a new engineer should not have production access in week one?
No. It means the production access should be scoped to the deploy path and paired with a rollback rehearsal. Read-only production access can and should come early. Write access to production should be tied to a specific, rehearsed task.
What if the team does not use AWS or GCP?
The provider-specific guidance cited here does not apply unchanged to bare-metal environments. The underlying principles, temporary credentials where possible, least privilege, scheduled review, and rehearsed rollback, are portable. The implementation will differ.
How does this relate to backup and recovery drills?
Access sequencing and recovery drills share the same logic: test the procedure before you rely on it. PostgreSQL’s documentation advises setting up and testing WAL archiving before taking the first base backup. restic’s --dry-run option lets you see what a restore would do before it does it. A new engineer’s first production deploy should follow the same pattern. For a broader checklist, see Write the Recovery Checklist Before You Need It.
What about break-glass access?
The retrieved sources do not describe break-glass procedures in detail. The general principle is that break-glass access should be the last grant, should be logged, and should have a defined review path. If your team has a break-glass procedure, the new engineer should read it before they need it, but they do not need to hold the credential on day one.
How do we know when to review access?
AWS recommends regularly reviewing and removing unused users, roles, permissions, policies, and credentials. For a small team, the practical trigger is the same ticket that granted the access. If the ticket has a review date, the review happens. If it does not, the grant tends to persist.
The sequence, in short
Read-only observability first. Non-production deploy second. Production deploy behind a supervised change with a rehearsed rollback third. Break-glass and credential-issuing paths last. Default to temporary credentials and least privilege. Write the review and offboarding dates into the same ticket that grants access. Treat the first production deploy as a drill, not a graduation. The point is not to slow the new engineer down; it is to make sure that when they deploy, they have already seen what happens when it goes wrong.