Proposed flow for this scenario

  1. Workload identity
  2. Store read permission
  3. Key-use permission when required
  4. Retrieve selected version
  5. Use without logging value

This flow describes a design to evaluate. The local experiment explores one stated mechanism. Its scope appears with the controls; the proposed services are not provisioned.

Decision checkpoints

ChoiceFits whenWatch for
Secrets ManagerCredentials need a secret-specific lifecycle and a rotation design.Assuming enabling a feature automatically updates every dependent application.
Parameter StoreHierarchical configuration and selected secure values fit the application.Treating all configuration values as harmless to expose.
KMSKey policy, encryption-key lifecycle and cryptographic use are the responsibility.Expecting a KMS key to store and rotate database passwords.

Classify the value before choosing a service

For the synthetic LetX worker, /shahriarlabs/letx/queue-name is application configuration. A database credential has an independent lifecycle and exposure risk. A customer-managed key describes who may use cryptographic operations; its identifier is not the password.

Write down the owner, readers, update frequency, recovery needs and acceptable retrieval failure for each value. Then choose a store. The choice is not determined simply by whether the value is a string; both configuration and sensitive credentials can have that representation.

Store permission and key permission are different gates

A workload may be allowed to retrieve a secret while lacking the required permission to use its customer-managed encryption key. A KMS key policy also affects whether identity-based permissions can authorize use. Diagnose the failed action and the key state rather than adding unrelated store-read grants.

Parameter Store SecureString similarly involves KMS. An undecrypted read and a decrypted value are different outcomes. Review history and hierarchy permissions too: an alternative read path can expose a version even if the application normally uses one selected parameter name.

Rotation is a coordinated change

For a credential, identify how the backing system accepts the replacement, when readers refresh, how old and new values overlap, and what happens if one step fails. Secret storage alone cannot answer those questions. Cache expiry must fit the rotation plan.

The local console supports synthetic version changes and labels, not an actual rotation Lambda or a database password change. Its KMS controls model metadata, key-use permissions and lifecycle; they do not encrypt a browser-stored value. Never paste production credentials into these exercises.

A small decision exercise

Create a customer-managed key in the local KMS console. Create a synthetic secret and a SecureString parameter using that key, then practice store reads with and without the modeled key permission. Disable the key and compare the resulting failures with a missing store-read permission.

Use only the fixed synthetic values accepted by the console. Exports and local storage are learning state, not a secure vault. The policy experiment below illustrates allow and deny relationships; it does not perform encryption or retrieve a real credential.

Cost and the changed requirement

Question: LetX now needs a credential rotation process that changes the actual database password and allows applications to refresh safely. Is migrating a String parameter to SecureString sufficient? No. Encryption at rest does not implement the credential-change workflow. Evaluate the secret lifecycle and how the application participates.

Compare current prices against stored values, API calls, rotation activity, key use and availability requirements. Avoid a blanket claim that one service is always free or cheaper. Prefer the smallest service combination that actually satisfies the lifecycle instead of putting every configuration item behind the most elaborate path.

Practice the supported console workflow

SimAWS · ShahriarLabs

Predict it. Test it. Change one thing.

Local educational model. No account or cloud charges. Nothing is deployed to AWS.

Asset reader request

s3:GetObject on arn:aws:s3:::lesson-assets/Report.txt

{
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::lesson-assets/Report.txt"
    }
  ]
}

Selected same-account identity-policy behavior. This is not a complete AWS policy simulator.

sim.shahriarlabs.com · Free to explore

Sources and scope

Reviewed against these official references. The model’s supported scope appears alongside its controls.

How we review explanations