Feature flags for the portal can be ordinary configuration, but third-party API tokens must not sit in plaintext parameters. How should Parameter Store / Secrets Manager usage be matched to sensitivity?
Select an answer to reveal the explanation.
Short Explanation
Feature flags are sticky notes; API tokens are the safe combination. Plaintext parameters are fine for the notes — tokens get SecureString or Secrets Manager.
Full Explanation
Parameter Store and Secrets Manager usage should match sensitivity. Non-sensitive portal feature flags may live as ordinary plaintext String parameters, while third-party API tokens must be SecureString parameters or Secrets Manager secrets. That civic configuration pattern keeps low-risk toggles easy to read in consoles and pipelines without placing bearer tokens beside them in the same unprotected channel. Strength of storage follows classification, not symmetry for its own sake.
Storing API tokens as plaintext String parameters and feature flags as Secrets Manager secrets for symmetry fails because it inverts protection—tokens need the stronger store, flags usually do not. Putting both in a public S3 config object readable by everyone fails conceptually by publishing tokens. Using only plaintext env vars for tokens to avoid KMS Decrypt latency fails because latency preference does not justify unprotected credentials.
Exam caveat: SecureString still requires IAM and KMS permissions that should be scoped to the consuming role; a readable parameter path with broad GetParameter allows is still a leak. Operational check: inventory parameters for the portal, confirm tokens are SecureString or Secrets Manager, confirm flags are appropriately plaintext, and remove any public S3 config that embeds secrets.