Promote a credential after validating it
Secret rotation has steps with different effects: generate a version, apply it at the target, test it, and promote the current reference. In the Lambda rotation function, AWSPENDING supports work on the version still being prepared; finishSecret promotes the validated version to AWSCURRENT. Do not use production consumers as the first check of a new value. Reads have a contract too: if the client sends VersionId and VersionStage, both must identify the same version. Decide whether the process needs a fixed version or the current reference and retain identifiers in diagnostics without logging the secret. Retrying contradictory requests does not resolve inconsistent version selection.
Verify consumption after rotation
In a fictional settlement service, new workers authenticate while older processes fail to open connections. A direct read confirms the current value, but the caching component may retain the previous one. Check refresh, consumed version, and reconnection before rotating again. The Python caching component has configurable refresh; it does not provide universal immediate invalidation on rotation events. The application may also retain open connections behaving differently from new ones. Recover controlled groups, observe failures, and avoid printing credentials to compare processes. Successful target testing establishes neither every consumer’s refresh nor completion of all outstanding work.
Separate key rotation, disabling, and deletion
Rotating KMS material neither re-encrypts data nor rotates existing data keys. A compromised data key needs its own exposure analysis. Disabling a key prevents new KMS cryptographic operations, subject to service consistency, but consumers with available material can continue until they need it again. Do not conclude disabling failed merely because one application still works. CancelKeyDeletion leaves the key Disabled; authorized recovery may require EnableKey and subsequent validation. Reusing the same alias on another key does not recreate old material. Before a lifecycle action, identify dependencies, backups, historical data, and ownership of the decision to retain or recover use.
Distinguish collection from integrity
Enabling CloudTrail integrity validation allows digest-file delivery; it does not itself run verification of collected files. Define the interval, location, and validation tool and retain the result. Valid JSON or an object count does not establish unchanged content. If the feature was disabled, re-enabling does not automatically reconstruct digests for that interval. Existing logs can remain useful, but the evidence claim should acknowledge the limit. Do not confuse Event history with unlimited archival either: it is regional and contains ninety days of management events. Investigation of earlier periods depends on previously existing collection and retention.
Confirm coverage by account and Region
An organization trail can appear in a member account despite validation failures in destination resources. A KMS or bucket-policy change can affect delivery without removing the configuration object. Inspect status, errors, and received samples. With an opt-in home Region, member accounts must enable that Region to send activity to the described trail. Multi-Region does not remove this dependency. Administration belongs to the management account or appropriate delegated administrator with suitable permissions; ordinary-member visibility does not imply authority to change it. Maintain a matrix of accounts, Regions, expected events, and covered periods, including gaps and correction owners.
Make claims proportional to evidence
The local exercise compares expected account-and-Region scope with collected results. It distinguishes unobserved pairs, failed delivery, and integrity not yet validated. A green row in another account does not fill an absence. The model neither queries AWS nor checks digest signatures or proves event completeness; those tasks require real evidence, a defined period, and appropriate selectors. Use its result as an investigation list rather than a compliance certificate. At shift handover, communicate confirmed facts, affected interval, next action, and owner. Combining configuration, delivery, and validation supports a more precise claim than isolated trail existence.
# Original scope-review model. Does not validate CloudTrail signatures or completeness.
def evidence_gaps(expected, observed):
missing = sorted(expected - observed.keys)
failed = sorted(pair for pair in expected & observed.keys
if observed[pair]["delivery"]!= "ok")
unvalidated = sorted(pair for pair in expected & observed.keys
if observed[pair]["integrity"]!= "validated")
return {"missing": missing, "delivery": failed, "integrity": unvalidated}
expected = {("account-a", "region-1"), ("account-b", "region-1")}
observed = {("account-a", "region-1"): {"delivery": "ok", "integrity": "validated"}}
assert evidence_gaps(expected, observed)["missing"] == [("account-b", "region-1")]
observed[("account-b", "region-1")] = {"delivery": "error", "integrity": "pending"}
assert evidence_gaps(expected, observed) == {
"missing": [], "delivery": [("account-b", "region-1")],
"integrity": [("account-b", "region-1")]}
observed[("account-b", "region-1")] = {"delivery": "ok", "integrity": "validated"}
assert evidence_gaps(expected, observed) == {"missing": [], "delivery": [], "integrity": []}
Two accounts have not enabled the home Region and another has a KMS error. Despite a visible trail and digests elsewhere, the team declares gaps and validates only actually collected scope.
Common pitfalls
AWSCURRENT as immediate cache refresh; KMS rotation as data re-encryption; cancellation as EnableKey; digests as executed validation; multi-Region as universal coverage.
Related topics: Delegation, identity, and access limits
Credentials and evidence have complete paths. Confirm consumers, key state, delivery, and validation before declaring recovery or coverage.
Reference: Secrets Manager Lambda rotation steps · DOP-C02