CCAO-F Using the Claude API Practice Question
A developer writes a Python script that calls the Claude Messages API. The script currently reads the API key from a hardcoded string in the source file and the file is committed to a public repository. Which change best addresses the security concern while keeping the script functional?
⚠ Common exam trap
The trap here is treating encoding or obfuscation as if it protects a secret, when only removing the credential from source and rotating it resolves the exposure.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Move the key into an environment variable and read it at runtime with os.environ, keeping the key out of source control.
Credentials must never live in source control. Reading the API key from an environment variable at runtime removes it from the codebase and repository history, so the exposure is eliminated while the script continues to authenticate normally. Any key that has already been committed should also be rotated.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Move the key into an environment variable and read it at runtime with os.environ, keeping the key out of source control.
Why this is correct
Storing secrets in environment variables keeps them out of the codebase and repository history, which directly removes the exposure caused by committing the key. The script still works because it reads the value at runtime. This is the standard practice for API credentials and allows different keys per environment without code changes.
- ✗
Base64-encode the hardcoded key so it is not readable as plain text in the repository.
Why it's wrong here
Base64 is an encoding, not encryption; anyone can trivially decode it. The key would still be committed to the repository and would remain fully usable by anyone who reads the file. This approach creates a false sense of security and does not remove the credential from source control, so the exposure persists.
- ✗
Obfuscate the key by splitting it across several string concatenations in the code before passing it to the client.
Why it's wrong here
Splitting the string across concatenations is trivial to reverse and the assembled key is still present in the committed source. This is obfuscation, not protection, and the credential remains exposed to anyone with repository access. The key must be removed from source entirely and rotated, not merely disguised within it.
- ✗
Add the source file to a .gitignore entry so future commits exclude it, leaving the existing key in the file.
Why it's wrong here
Ignoring the file prevents future commits but does nothing about the key already published in repository history, where it remains retrievable. The credential is still compromised and must be rotated regardless. Ignoring the file also risks breaking the project for collaborators who expect the source to be tracked, without solving the underlying exposure.
About these practice questions
One of 259 original CCAO-F practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Anthropic exam blueprint
This CCAO-F practice question is part of Courseiva's free Anthropic certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CCAO-F exam.