During review of a licensing Oracle Function, a database password is found in Function application config and duplicated as an ENV in the image. What should replace both?
Select an answer to reveal the explanation.
Short Explanation
Function config and image layers are the wrong pockets for a password—anyone who can pull or read config can see them. Put the secret in Vault and fetch it with a principal.
Full Explanation
A database password found in Function application config and duplicated as an ENV in the licensing Function image should be removed from both places. Store the password in OCI Vault and retrieve it at runtime with a resource principal (Functions) or workload principal (OKE). Application config remains appropriate for non-secret settings; image layers remain free of credentials so pulls and layer inspection cannot disclose the municipal database password.
Keeping the password in Function config because config is “encrypted like Vault secrets” overstates config protection and still lacks Vault’s versioning, rotation states, and fine-grained secret IAM. Keeping the password only in the image and marking OCIR private still exposes secrets to anyone with pull rights and forces rebuilds on every rotation. Moving the password into a public GitHub Actions variable so the image stays clean merely relocates the leak into CI.
Exam caveat: after moving to Vault, delete old config keys and rebuild images so historical layers and application config revisions do not retain the password. Operational check: scrub config and Dockerfile/ENV, deploy retrieval via resource principal, rotate the Vault secret once, and confirm the Function picks up the new current version without a config edit or image rebuild.