mediumMultiple Select
CV0-004 Practice Question: Which THREE of the following are recommended…
Which THREE of the following are recommended practices for securing cloud API access? (Choose three.)
⚠ Common exam trap
A common trap is the misconception that embedding API keys in source code is acceptable for convenience, but this violates secure coding standards and is a common cause of data breaches in cloud environments.
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
✓
Use role-based access control to limit permissions for each API user
Option A is correct because role-based access control (RBAC) enforces least privilege by assigning each API user or service only the specific permissions required for its function, reducing the blast radius of a compromised credential. Option C is correct because enabling detailed logging of all API calls to a centralized service (e.g., AWS CloudTrail, Azure Monitor, or GCP Cloud Audit Logs) provides an audit trail for detecting anomalous activity, supporting incident response, and meeting compliance requirements. Option E is correct because regularly rotating API keys and tokens limits the window of exposure if a credential is leaked, and rotation should be automated and paired with revocation of old credentials. Option B is not recommended because embedding API keys in source code exposes them to anyone with repository access and often leads to leaks in version control history; secrets should be stored in a secrets manager or vault. Option D is not recommended because exposing API endpoints publicly to all clients removes authentication and network controls, increasing attack surface; endpoints should be restricted via authentication, authorization, and network policies such as private endpoints or IP allowlists.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Use role-based access control to limit permissions for each API user
Why this is correct
Role-based access control enforces least privilege by assigning permissions through roles rather than to individual API users, so each caller receives only the scopes its function requires. This directly satisfies the stem's constraint of limiting permissions per API user, reducing blast radius if credentials leak and simplifying revocation at scale.
- ✗
Embed API keys directly in application source code for convenience
Why it's wrong here
Hard-coded keys are exposed to anyone with repository, build-log or binary access, and cannot be rotated without redeploying the application. It tempts because embedding credentials removes an external dependency during development, and would be acceptable only for throwaway local testing with non-production, non-sensitive endpoints.
- ✓
Enable detailed logging of all API calls to a centralized service
Why this is correct
Centralised logging captures every API call, giving the audit trail needed to detect anomalous access patterns and satisfy the monitoring constraint in the stem. Because API credentials are frequently targeted, correlating request metadata across services enables rapid forensic investigation and supports compliance reporting without impeding legitimate traffic.
- ✗
Expose API endpoints publicly for easy access by all clients
Why it's wrong here
Public endpoints let unauthenticated clients reach the API, removing the authentication and authorisation boundary that access control depends on. It tempts because public exposure genuinely suits deliberately open, read-only data services, and would be correct for those, but not for APIs handling tenant or sensitive data.
- ✓
Rotate API keys and tokens on a regular schedule
Why this is correct
Regular rotation limits the useful lifetime of a leaked key or token. Even if a credential is exposed, it expires before an attacker can exploit it persistently, directly satisfying the requirement to reduce credential compromise risk.
Quick reference
AAA Protocol Comparison
| Protocol | Port(s) | Encryption | Transport | Primary Use |
|---|---|---|---|---|
| RADIUS | 1812 / 1813 | Password only | UDP | Network access control |
| TACACS+ | 49 | Full packet | TCP | Device administration |
| Diameter | 3868 | Full session | TCP / SCTP | Carrier / mobile networks |
| 802.1X | — | EAP-based | Layer 2 | Port-based access control |
TACACS+ encrypts the entire packet; RADIUS only encrypts the password field — a key exam distinction.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CV0-004 question from scratch — 834 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CV0-004 practice question is part of Courseiva's free CompTIA 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 CV0-004 exam.