hardMultiple ChoiceObjective-mapped
CISSP Practice Question: A security architect is reviewing the access…
A security architect is reviewing the access control model for a microservices architecture. Which approach minimizes the risk of privilege escalation from a compromised service?
⚠ Common exam trap
Many candidates confuse authentication (API keys, SSO) with authorization (ABAC, RBAC), assuming that verifying identity alone prevents privilege escalation, when in fact fine-grained authorization policies are required to limit what a compromised service can do.
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 attribute-based access control (ABAC) with service-specific policies.
ABAC with service-specific policies minimizes privilege escalation because it enforces fine-grained, context-aware permissions (e.g., user attributes, resource type, action) per microservice. If a service is compromised, its policies are scoped only to that service’s required operations, preventing lateral movement or elevation to other services. This aligns with the principle of least privilege and defense in depth in a distributed architecture.
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 attribute-based access control (ABAC) with service-specific policies.
Why this is correct
Attribute-Based Access Control (ABAC) is the most suitable model for complex, dynamic authorization requirements in modern service architectures. It evaluates access requests based on a combination of attributes associated with the subject (e.g., calling service identity), object (e.g., target resource), action (e.g., read, write), and environment (e.g., time of day, network location). By implementing service-specific policies, ABAC enables highly granular, context-aware authorization decisions, effectively limiting privilege escalation by ensuring services only access what is precisely needed under specific conditions.
- ✗
Implement role-based access control (RBAC) with global roles.
Why it's wrong here
Implementing Role-Based Access Control (RBAC) with global roles for service-to-service communication is generally insufficient and insecure. Global roles are inherently broad and static, making it difficult to apply the principle of least privilege effectively across diverse services with varying access needs. This approach often results in over-provisioning permissions, where a service might receive excessive privileges simply because a global role encompasses more access than strictly required for its specific functions, significantly increasing the attack surface.
- ✗
Use API keys for all service-to-service communication.
Why it's wrong here
API keys are a poor choice for comprehensive service-to-service authorization due to their inherent security limitations. They are essentially static secrets that, once compromised, grant full access to the associated permissions without further authentication or context-based checks. API keys lack the capability for dynamic, fine-grained authorization based on attributes, context, or real-time policy evaluation, making them highly vulnerable to theft and misuse and unsuitable for robust access control in a microservices environment.
- ✗
Deploy a single sign-on solution.
Why it's wrong here
Deploying a single sign-on (SSO) solution primarily addresses user authentication challenges, streamlining how human users log in to multiple applications with a single set of credentials. However, SSO does not inherently provide a mechanism for service-to-service authorization, which governs what one automated service can do when interacting with another. While SSO authenticates the user, it doesn't define or enforce the granular permissions between different backend services or microservices, which is the core problem this question addresses.
Quick reference
Access Control Model Comparison
| Model | Acronym | Who Controls Access? | Best For |
|---|---|---|---|
| Discretionary Access Control | DAC | Resource owner | Small teams, file shares |
| Mandatory Access Control | MAC | System / security labels | Classified govt / military |
| Role-Based Access Control | RBAC | Administrator (via roles) | Enterprise environments |
| Attribute-Based Access Control | ABAC | Policy engine (user + resource attributes) | Fine-grained, dynamic policies |
| Rule-Based Access Control | RuBAC | System rules / ACLs | Firewall rules, network ACLs |
Go deeper
Related to this question
Learn chapter
Security Governance and Principles
Key term
Access control
Access control is the security practice of determining who or what is allowed to view, use, or enter a resource, and under what conditions.
Key term
Risk
Risk is the possibility that an event or action will negatively affect an organization's ability to achieve its goals, often measured in terms of likelihood and impact.
About these practice questions
One of 747 original CISSP 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 by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CISSP practice question is part of Courseiva's free ISC2 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 CISSP exam.