A county AI gateway on AKS needs non-secret model endpoint URLs and secret API keys. How should those values be supplied in manifests?
Select an answer to reveal the explanation.
Short Explanation
Endpoint URLs are like the public street address of the model service; API keys are the badge that opens the door. Park the address in a ConfigMap and keep the badge in a Secret or Key Vault-backed secret so the county AI gateway does not treat them the same.
Full Explanation
Kubernetes separates non-sensitive configuration from secrets. For a county AI gateway on AKS, non-secret model endpoint URLs belong in a ConfigMap, while API keys belong in a Secret—or a sealed/Key Vault-backed secret integration. Pods mount or environment-inject each appropriately. That split limits accidental exposure of keys in world-readable ConfigMaps and matches how municipal platform teams harden generative gateways.
Putting API keys and endpoint URLs together in a public ConfigMap readable by every namespace fails secret protection—ConfigMaps are not encrypted secret stores. Embedding both keys and URLs as plaintext labels on every Pod fails confidentiality and creates sprawling, greppable secret copies. Emailing keys to on-call staff and omitting them from the cluster fails automated, auditable injection and encourages secret handling outside controlled channels.
Exam caveat: Kubernetes Secrets are base64-encoded, not strongly encrypted at rest unless you enable encryption providers or external secret managers. Exam answers still contrast ConfigMap vs Secret conceptually; production counties often add Azure Key Vault Secrets Store CSI or similar. Never treat labels/annotations as a secret channel.
Operational check: Review the AI gateway manifests: endpoints in ConfigMaps, keys in Secrets or Key Vault-backed volumes, RBAC limiting who can read Secrets, and no keys in Pod labels or shared ConfigMaps. Rotate a key in the secret store and confirm pods reload or restart per your documented process.