DevSecOps Policy Vocabulary — Pipeline Gates and Shift-Left Security
Practice the vocabulary used when designing and discussing DevSecOps policy enforcement in CI/CD pipelines: shift-left security, the difference between blocking and advisory gates, how to describe what a pipeline policy does, and how to communicate enforcement decisions to developers.
0 / 12 completed
1 / 12
Your team is introducing container image scanning. A colleague asks: 'What does shift-left security mean for this?' Which answer is correct?
Shift-left security: 'left' refers to the left side of the software delivery timeline (design and code) vs. 'right' (production and runtime). Shift-left means: developer runs SAST in their IDE, pre-commit hooks catch secrets, CI pipeline scans images and IaC, compliance gates run on Terraform plans. Benefits: faster feedback loop, cheaper to fix (cost of fixing a vulnerability in CI is far lower than in production), higher developer ownership. Phrase: 'We shifted the image scan left — it now runs in the build stage, not the deploy stage.'
2 / 12
Fill in the blank: 'CRITICAL severity container vulnerabilities are _____ — the build fails immediately and the image cannot be pushed to the registry until they are patched or an exception is approved.'
'Enforced in CI with a blocking security gate' is the correct DevSecOps vocabulary combination. 'Enforced in CI' = the check runs automatically in the pipeline. 'Blocking security gate' = the pipeline fails and the artifact cannot proceed. Together they describe a hard control: no human can approve the build past this point without going through the formal exception process. Compare: 'advisory only in CI' = the check runs and reports, but the build continues — used for low-severity findings or during rollout.
3 / 12
When would you use an 'advisory only gate' instead of a 'blocking security gate' in a pipeline?
Advisory only gate use cases: (1) New policy rollout — run in warn mode for 2 weeks to measure how many builds would fail before enforcing. (2) Low-severity findings — MEDIUM vulnerability advisory, HIGH is blocking, CRITICAL is blocking with emergency override. (3) Legacy codebases — report violations while teams remediate rather than blocking all work. (4) Pilot — enforce blocking only for new code, advisory for existing. Transition vocabulary: 'We are moving the IaC policy gate from advisory to blocking on 2026-07-01 — prepare for builds to fail if violations are present.'
4 / 12
A developer's pull request fails at the pipeline policy stage with the message: 'conftest: 1 violation found — Terraform resource aws_s3_bucket.logs does not have logging enabled [policy: s3-access-logging-required].' What should the developer do?
Correct pipeline policy response: (1) Read the violation message — it names the exact resource, the exact missing property, and the exact policy rule. (2) Fix it: add the required configuration to the Terraform code. (3) If there is a legitimate technical reason the fix is not possible for this specific resource, submit a formal exception request. The violation message is designed to be self-documenting: resource + violation + policy ID. Never disable a shared policy or bypass the gate unilaterally — it removes the protection for all other engineers and resources in scope.
5 / 12
Your team is documenting CI/CD pipeline security architecture. Which sentence correctly uses 'policy-as-code in CI/CD'?
Policy-as-code in CI/CD has three distinguishing characteristics: (1) Machine-readable rules (Rego, Sentinel, OPA YAML, conftest policies — not PDFs or wikis). (2) Automated evaluation at pipeline stages (not periodic reviews). (3) Version-controlled alongside application code (with PR review, history, rollback). The sentence that satisfies all three: 'expressed as version-controlled code, automatically evaluated at defined pipeline stages.' YAML pipeline definitions are process-as-code (they define pipeline structure), not policy-as-code (which evaluates resource compliance). Storing policies in Git without automated evaluation is versioning, not enforcement.
6 / 12
Sarah from the Security team sent this Slack message to the development team: 'Hey everyone, we're implementing pipeline gates to enforce security best practices. We'll be using 'blocking' gates that halt the build if a policy is violated, and 'advisory' gates which just flag issues for review. Which of these statements *best* reflects Sarah's intention regarding 'blocking' gates?
Sarah is describing 'blocking' gates as those that halt the pipeline. This signifies a critical requirement – the build *must* be addressed before continuing. The incorrect options misinterpret blocking gates; they aren't for guidance or automatic fixes but specifically to prevent further processing until resolved. This aligns with DevSecOps principles of integrating security proactively.
7 / 12
You're reviewing a pull request for a new microservice deployment. The PR description states: 'This change implements logging for all S3 buckets according to our s3-access-logging-required policy. A 'policy-as-code' approach is being utilized, ensuring consistent security enforcement across the pipeline.' Which of the following scenarios would justify using an 'advisory only gate' instead of a 'blocking security gate' at this stage?
An 'advisory only gate' flags issues for review but doesn't halt the build. The scenario describes a low-risk configuration change focused on auditability – this aligns with an advisory approach where the team can assess and decide on remediation without interrupting the pipeline. Blocking gates are reserved for high-severity, immediate risks.
8 / 12
David from DevOps is explaining the new pipeline gates to the team during a standup. He says: 'We're introducing a 'blocking' gate for all deployments to our production environment. If the policy check fails – specifically, if Terraform doesn't correctly configure S3 bucket logging – the entire build stops. This ensures we don't accidentally deploy insecure configurations.' Which of the following best describes David's explanation?
The explanation clarifies that a 'blocking' gate has an active role in preventing deployments. The key concept here is that the build stops when a policy violation occurs – this aligns with David's statement about actively preventing insecure configurations. Option A misrepresents the impact of a blocking gate; options C and D confuse it with advisory gates or limit its scope.
9 / 12
'A policy-as-code approach to security in our CI/CD pipeline means defining and enforcing security rules not just in documentation but as version-controlled code. For example, the S3 bucket logging policy is stored in a Terraform configuration file and automatically checked during the build process. CRITICAL container vulnerabilities are
— the build fails immediately and the image cannot be pushed to the registry until they are patched or an exception is approved.
This question tests understanding of 'policy-as-code'. The blank should be filled with a concise description of the concept – that security policies are defined and managed programmatically. It's crucial to link this back to the real-world consequence: failure of the build due to the policy violation.
10 / 12
Maria, a security engineer, sends a Slack message to the team after a failed pipeline run. The error message was: 'conftest: 1 violation found — Terraform resource aws_s3_bucket.logs does not have logging enabled [policy: s3-access-logging-required].' She asks: 'How should we approach this?' Which response best reflects the correct DevSecOps strategy?
This scenario tests understanding of 'shift-left' security. The correct answer emphasizes investigating and fixing the root cause in the code (Terraform template) rather than simply applying a workaround. Options A & B are unacceptable; option D shifts responsibility away from the development team.
11 / 12
Ben leaves this comment on a code review for a new microservice deployment: 'Looks good! But I'm seeing that we're logging all S3 buckets according to the s3-access-logging-required policy. Can you confirm that this is actually enforced by a pipeline gate and isn't just a best practice suggestion? It would be beneficial if the policy was defined as code, so it can be automatically validated.' What is Ben's primary concern?
Ben's concern centers on the lack of *automated* enforcement of the security policy. He's rightly questioning whether the logging is truly protected by a 'blocking' gate. The question tests whether the developer understands that 'policy-as-code' needs to be actively enforced within the CI/CD pipeline, not just recommended.
12 / 12
Your team is building a new CI/CD pipeline. You need to define how your security policies will be managed. Which statement best describes the purpose of using 'policy-as-code' in this context?
This question directly addresses the core concept of 'policy-as-code'. The correct answer highlights that it's about consistent management, versioning, and automated enforcement across the entire pipeline – encompassing both infrastructure and application code. Option A is incorrect; option C overstates the complexity while option D provides a misinterpretation.
What will I practice in "DevSecOps Policy Vocabulary — Pipeline Gates and Shift-Left Security"?
This is a Policy As Code exercise set. It walks through 12 scenario-based multiple-choice questions built around real usage of policy as code terminology that IT professionals encounter on the job.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to complete with no account, sign-up, or paywall.
How many questions are in this exercise?
This set contains 12 questions. Each one shows immediate feedback and a detailed explanation after you answer, so you learn the correct usage right away rather than waiting for a final score.
Do I need prior experience to complete this exercise?
No prior experience is required. Each question includes a full explanation covering the reasoning behind the correct answer, so the exercise itself teaches the policy as code vocabulary as you go.
Can I retry the exercise if I get questions wrong?
Yes — use the "Try again" button on the results screen to reset your answers and go through all the questions again. There is no limit on attempts.
Is my progress saved?
Your answers and score for the current session are tracked in the browser as you go. No account or login is needed, and there is nothing to install.
What if I don't understand a term used in a question?
Read the explanation shown after you answer each question — it breaks down the correct term in plain English with a real-world example. You can also check the site Glossary for quick definitions.
How is this different from reading a blog article on the topic?
Exercises like this one are interactive drills that test and reinforce specific vocabulary through multiple-choice questions, while blog articles explain concepts in prose. Practising here after reading builds active recall, not just passive recognition.
Where can I find more Policy As Code exercises?
See the Policy As Code exercises hub for the full set of related pages, or browse all exercise categories from the main Exercises index.
Can I use this exercise to prepare for a technical interview?
Yes — policy as code vocabulary comes up often in technical discussions and interviews. Pair this exercise with our dedicated Interview Preparation section for role-specific practice.