The prebuilt Kubernetes path injects Meraki API credentials via Secret-mounted environment variables at deploy time. A teammate proposes baking the key into the image layers. Which choice follows the integration contract?
Select an answer to reveal the explanation.
Short Explanation
Don’t etch the vault combination into every crate stamp—hand the combination at delivery. Cluster Secrets and ConfigMaps inject at deploy; baking tokens into the image fails the contract.
Full Explanation
The prebuilt Kubernetes path injects Meraki API credentials via Secret-mounted environment variables at deploy time, so the integration contract is to leave credentials out of the image and consume Secret or ConfigMap values injected at deploy. Image layers are widely copied and cached; secrets belong in the cluster’s secret store handed to pods at delivery. That split keeps municipal Meraki keys rotatable without rebuilding every tag.
Baking the Meraki key into every image tag so pods need no cluster Secrets embeds production credentials in an artifact that travels through registries and developer laptops. Committing the key in a public Dockerfile ARG default for “reproducibility” publishes the secret into version control and build history. Hard-coding the key in application source checked into the repo is the same class of leak—credentials in the codebase rather than in deploy-time injection.
Exam caveat: ConfigMaps are for non-secret config; API keys still belong in Secrets (or equivalent), but both are inject-at-deploy, not bake-into-image. Operational check: scan the image and Dockerfile for Meraki key material, confirm the Deployment references a Secret for the credential env vars, and rotate the Secret without requiring a new application image build.