Security mandates rotating the Intersight API secret every 90 days with minimal downtime. Which approach makes that rotation practical?
Select an answer to reveal the explanation.
Short Explanation
Rotatable secrets are spare keys at the front desk—swap the key, reload the door crew, no factory rebuild. A constant welded into the binary forces a full remanufacture every 90 days.
Full Explanation
Keep the secret in an external store so operations can replace it and restart or reload processes without rebuilding the image. Rotation for the municipal service then becomes a configuration operation rather than a full software release every ninety days or after a leak is confirmed. Compiling the secret as a constant in source forces a code change and image rebuild for every rotation, which slows incident response when a credential must die quickly across environments. Tattooing the secret into an immutable AMI with no injection path at boot freezes credentials into machine images that are expensive and slow to respin when compromise is suspected. Sharing one never-rotated secret across all applications avoids operational updates only by maximizing blast radius and violating least privilege between civic workloads. Exam caveat: rotation requires coordination—update the store, roll pods or refresh mounts, confirm consumers switched, then revoke the old value so overlap does not leave a valid leaked credential active. Operational check: rotate a staging credential in the external store, trigger rolling restart or secret reload, confirm the application uses the new value, and verify authentication with the old value fails.