The annual job behind an apparently unused credential

The name says old

The name old-supplier-export looks as though somebody has already made the retirement decision. Its job calendar is less agreeable: the next annual export is configured for 15 January. In this invented inventory, the quiet months used to justify deleting the credential omit the part of the year when it is needed. I would follow the effective job reference before trusting either the name or the reassuring absence of recent use.

The review date is 1 January 2026. K17 last appears in the teaching log on 15 January 2025, and the next configured export runs on 15 January 2026. Those eleven quiet months do not include its annual occasion to work. This is a synthetic retirement plan, with no client or cloud account being audited, but it gives the deletion question a precise dependency to resolve rather than an arbitrary number of days to wait.

Removing unnecessary components is valuable work. Google’s SRE discussion of simplicity argues for eliminating accidental complexity and dead code. [1] The practical challenge is establishing what is dead, then carrying the removal far enough that dependencies, documentation and permissions agree. A shorter list is a good result when the system has less unnecessary responsibility, rather than one fewer visible name hiding the same responsibility elsewhere.

Identify what is actually being retired

An account, a credential and a permission are different things. The example concerns credential K17 used by a service identity, not deletion of the entire identity. That distinction matters if other credentials or workloads use the same account. Removing the wrong level can affect more work than the inventory row suggests; retaining the account does not mean the old credential must remain valid.

Record the exact asset, environment, owner and known access without copying the secret value. A key identifier and supported management path should be sufficient for review. The label can help locate the asset, but it does not establish whether the credential is obsolete. Compare it with effective consumer references and the relevant activity evidence before assigning a retirement state.

Inspect known consumers: scheduled jobs, deployment configuration, secret references, recovery procedures and the business process that still expects their output. The annual export is a concrete dependency. An old recovery note referencing K17 is another question, though a document mention does not prove the fallback is still used. Classify each reference as active, obsolete or unresolved with evidence, rather than treating every search match as either a blocker or irrelevant clutter.

Look for indirection. A job may refer to a secret alias which currently resolves to K17 rather than naming the credential directly. A configuration search for the exact key identifier could miss it. Conversely, a historical log entry can remain after the live reference has moved. The inventory needs the effective relationship used at execution time, not just a reassuring count of textual matches.

Absence is evidence only within its coverage

The log has no calls in the observed window. Check what it actually records before deciding K17 is unused: which environments, authentication paths and consumers are included, and can it distinguish this credential from others on the same identity? A route missing from that coverage remains a dependency to investigate. Giving it an unused badge would turn a gap in the log into a decision the log cannot support.

The work’s calendar should shape the observation. An annual job asks a different question from a weekly integration, without requiring every team to wait another year before improving it. Confirm whether the export is still needed, move it to the supported replacement and exercise a representative safe route where possible. That addresses the known dependency directly. Watching an unrelated thirty-day window expire would add time to the decision without necessarily telling us anything new about January.

Google Cloud’s key-management guidance recommends using insights and authentication metrics to identify unused keys, disabling keys when no longer needed and deleting when their lack of need is established. [2] That is a provider-specific example of a useful staged approach. Check the actual platform’s behaviour and recovery facilities; this article does not supply a cloud command or promise that every disabled asset can be restored in the same way.

The review may instead establish that the annual export is no longer needed. Confirm that with the responsible owner and destination evidence, then retire both the job and its access. Automatically migrating it to a new identity would retain the workload without establishing its purpose. The useful outcome is a supported dependency where the work remains necessary, or a completed retirement where it does not.

Make the transition observable and bounded

If the export remains necessary, move its consumer to the replacement credential or supported workload identity through the authorised change process. Then follow a safe representative run far enough to see what the replacement can do. Authentication alone does not establish permission to produce and deliver the export. Local file generation can check its format while leaving destination writing untested. Keep that distinction with the result and obtain the remaining check through the supported non-destructive route before calling the job migrated. The next person needs to know whether the replacement merely signed in or actually reached the part of the workflow that depended on K17.

After migration, keep a finite retirement plan for K17: which consumers were moved, what remains unresolved, who owns the decision, when disabling is appropriate and what observation would require a response. Avoid a vague waiting state that never ends. Keeping an unnecessary valid credential indefinitely has its own cost and exposure; uncertainty should create a concrete investigation, not a permanent exception with no owner.

Choose the observation signals before disabling. Authentication failures on the relevant workload, a missed expected output or a known recovery exercise can reveal a remaining dependency. The response should identify which asset changed and which rollback or alternative path is authorised. Quietness after disabling is meaningful only with coverage of the work that could have needed it, including the seasonal route or its representative check.

Separate disabling from deletion where the platform supports that staged lifecycle. The first can reduce exposure while providing a controlled opportunity to discover a missed dependency; the second removes the old asset under the provider’s actual rules. Do not use the staged period as an excuse to distribute extra secret copies “just in case”. Preserve recovery instructions and appropriate authorised access, not a shadow collection of unmanaged credentials.

Finish the removal beyond the console

Once the old credential is retired, remove its live references and update the recovery note. Leave a record linking the retired identifier, decision evidence and replacement where appropriate. The next person should not find a runbook confidently instructing them to use K17 or a failed job attempting to read a deleted secret alias. Deletion in one console is not the entire dependency change.

Moving the job is also a chance to ask what access it still needs. A replacement may not require every permission accumulated by the old shared identity. Copying them all because the new credential authenticates would preserve the old exposure by default. Keep the review bounded to the supported export and its destination, rather than turning a useful small retirement into an indefinite redesign of the organisation’s identity system.

Keep the outcome honest. “No known consumers remain; representative export verified; old credential disabled and later deleted under the platform procedure” is a useful record when those steps actually happened. The resource here is only an authored inventory for deciding those steps. No real secret, cloud account, export or credential operation was accessed or changed.

By the next January, the owner should be able to find one of two answers. The export is still needed and has a verified replacement route, with K17 retired through the platform’s staged process; or the export itself has ended, with its references and recovery instructions retired too. Either explains where the responsibility went. A deleted console entry without that explanation merely postpones the dependency question until the annual job tries to use it.