A maintenance script runs on an application server and connects to the database with a username and password stored in plain text at the top of the script file. Several operators can read that file. What should the DBA do?
Select an answer to reveal the explanation.
Short Explanation
Base64 isn't a lock, it's just a different font; anyone can turn it back in seconds. The real fix is to get the secret out of the file and into a protected store your script fetches when it runs. Watch for any answer that hides the password instead of protecting it.
Full Explanation
Credential storage checks are part of code auditing: any script that connects to a database must obtain its credentials without exposing them to people who can read the code. Storing the password in a secrets manager, an operating system credential store or a protected configuration with tight file permissions lets the script retrieve it at runtime under its service identity, while operators who read the script see only a reference. This also allows rotation without editing code, and access to the secret can be logged. Moving the script to client workstations spreads the plain-text password onto more machines with weaker controls, increasing exposure rather than reducing it. Base64 is an encoding, not encryption; it is reversible by anyone with standard tools, so it provides no confidentiality. Granting the account the DBA role violates least privilege by giving a maintenance script far more power than it needs, and avoiding rotation leaves a long-lived secret in place. Exam caveat: where the platform supports it, integrated or certificate-based authentication can remove the stored password entirely, which is even better than storing it securely. Operational check: search the script repository for embedded passwords, move each one into the protected store, rotate the exposed password, and confirm the script still connects using the new credential retrieved at runtime.