hardMultiple ChoiceObjective-mapped
CISSP Practice Question: To enforce separation of duties in a CI/CD…
To enforce separation of duties in a CI/CD pipeline, what architectural principle should be implemented?
⚠ Common exam trap
A common mix-up: candidates confuse 'DevOps' with 'no separation of duties,' assuming a single team should have full access to both code and deployment, when in fact the CISSP requires distinct roles even in agile pipelines to maintain accountability and audit trails.
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
✓
Require different permissions for committing code vs. deploying to production
Separation of duties in a CI/CD pipeline requires distinct permissions for code commits and production deployments. This ensures that no single individual can introduce and deploy malicious code without oversight, aligning with the principle of least privilege and auditability. By enforcing role-based access control (RBAC) with separate pipelines for build and release, organizations mitigate the risk of unauthorized changes reaching production.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Allow all developers to deploy their own code to production
Why it's wrong here
This approach directly violates the principle of separation of duties by allowing the same individual to both develop and release code into a production environment. Such a lack of control increases the risk of unauthorized or erroneous deployments, making it difficult to detect malicious intent or accidental misconfigurations. It removes the critical independent review step.
- ✗
Use a single approval gate without role distinction
Why it's wrong here
Implementing a single approval gate without distinct role-based authorization for who can approve is insufficient for enforcing separation of duties. While an approval step exists, if the approver can also be the committer or if there are no specific roles defining who *should* approve, the control becomes weak. True separation requires different individuals, with different responsibilities, to perform distinct actions.
- ✗
Grant a single DevOps team full access to both source code and deployment
Why it's wrong here
Granting a single DevOps team comprehensive access to both source code repositories and production deployment mechanisms consolidates too much power within one group. This configuration fails to establish effective separation of duties, as the same team could potentially develop, modify, and then release their own code without independent oversight from a distinct operational or security function. It centralizes control, increasing risk.
- ✓
Require different permissions for committing code vs. deploying to production
Why this is correct
Requiring distinct permissions for committing code into a repository versus deploying that code to a production environment is a fundamental application of separation of duties. This ensures that individuals responsible for developing and modifying code are not the same ones authorized to release it, thereby introducing an independent control point. It mitigates risks associated with insider threats and accidental errors by distributing critical responsibilities.
Visual reference
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
Identity and Access Management (IAM)
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
RBAC
RBAC is a method of restricting network access based on the roles of individual users within an organization, where permissions are assigned to roles rather than to individuals directly.
About these practice questions
Courseiva writes every CISSP question from scratch — 747 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 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.