hardMultiple Select
200-901 Implementing a secure CI/CD pipeline Practice Question
A company is implementing a secure CI/CD pipeline. Which THREE practices are essential for securing the pipeline?
⚠ Common exam trap
Cisco often tests the misconception that 'allowing any public registry' is acceptable for speed or convenience, but the correct practice is to restrict registries to trusted, scanned sources to prevent supply chain attacks.
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
✓
Sign and verify all build artifacts.
Option A is correct because signing build artifacts (e.g., with Sigstore/cosign or GPG) and verifying those signatures before deployment ensures integrity and provenance, preventing tampered or unauthorized artifacts from reaching production. Option D is correct because implementing role-based access control (RBAC) on the CI/CD system enforces least privilege, restricting who can modify pipelines, trigger builds, or access secrets and deployment targets. Option E is correct because integrating SAST tools into the build stage catches code-level vulnerabilities (e.g., injection flaws, insecure deserialization) early, before artifacts are promoted through the pipeline. Option B is incorrect because pulling container images from any public registry exposes the pipeline to untrusted or malicious images; images should come from vetted, trusted registries with scanning and signature verification. Option C is incorrect because storing secrets such as API keys and passwords in version control exposes them to anyone with repository access and to history leaks; secrets should be kept in a dedicated secrets manager (e.g., HashiCorp Vault, AWS Secrets Manager) and injected at runtime.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Sign and verify all build artifacts.
Why this is correct
Signing build artifacts with a private key and verifying signatures before deployment ensures tampering between build and release is detected. This satisfies the pipeline's integrity requirement, preventing an attacker who compromises an intermediate repository from injecting altered binaries into production.
- ✗
Allow all container images to be pulled from any public registry.
Why it's wrong here
Pulling images from any public registry removes provenance control, letting untrusted or tampered layers enter the build and deploy stages. It is tempting because unrestricted registries maximise image availability and convenience, which suits isolated lab or proof-of-concept environments where supply-chain risk is deliberately accepted, not a secure pipeline.
- ✗
Store secrets (API keys, passwords) in version control.
Why it's wrong here
Version control retains every committed value in history, so secrets remain recoverable by anyone with repository access even after deletion. It is tempting because committing configuration alongside code keeps deployments reproducible and simple, which suits non-sensitive parameters such as ports or feature toggles, not API keys or passwords.
- ✓
Implement role-based access control (RBAC) on the CI/CD system.
Why this is correct
RBAC restricts who can trigger builds, modify pipeline definitions, and access secrets, enforcing least privilege across the CI/CD system. This satisfies the pipeline's access-control requirement, limiting the blast radius if one developer's credentials are compromised.
- ✓
Use static application security testing (SAST) tools in the build stage.
Why this is correct
SAST tools scan source code during the build stage, catching injection flaws, insecure deserialisation, and hardcoded credentials before artefacts ship. This satisfies the pipeline's early-detection requirement, shifting remediation left where fixes cost far less than post-deployment patching.
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
About these practice questions
One of 975 original 200-901 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 200-901 practice question is part of Courseiva's free Cisco 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 200-901 exam.