Practice vocabulary for compliance-as-code, policy engines in CI/CD, OPA, Checkov, Conftest, and shift-left security principles.
0 / 22 completed
1 / 22
What is 'compliance-as-code' in a DevSecOps context?
Compliance-as-code translates compliance requirements (e.g., 'all S3 buckets must have encryption enabled', 'no container should run as root') into automated policies evaluated in CI/CD pipelines and infrastructure provisioning. Policies are version-controlled, peer-reviewed, and auditable — turning compliance from a periodic manual audit into a continuous, automated check.
2 / 22
What is OPA (Open Policy Agent) and how is it used in CI/CD pipelines?
Open Policy Agent (OPA) is a CNCF project that decouples policy decision-making from application logic. Policies are written in Rego. In CI/CD, OPA evaluates structured inputs (JSON/YAML) against policies — e.g., checking Terraform plans, Kubernetes admission requests, or container configurations against organisational rules. Conftest is the CLI tool that brings OPA policy evaluation to pipeline workflows.
3 / 22
What is Checkov and what does it scan?
Checkov (by Bridgecrew/Palo Alto) scans IaC files before deployment — Terraform, CloudFormation, Kubernetes manifests, Helm charts, Dockerfiles — for security misconfigurations mapped to CIS Benchmarks, NIST, PCI DSS, and other frameworks. Running Checkov in CI catches misconfigurations like publicly accessible storage buckets, missing encryption, or overly permissive IAM roles before infrastructure is ever provisioned.
4 / 22
What is Conftest and how does it relate to OPA?
Conftest (part of the Open Policy Agent ecosystem) provides a simple CLI for evaluating configuration files against Rego policies. You write policies like 'Kubernetes Deployments must have resource limits' or 'Dockerfiles must not use the latest tag', then run conftest test in the pipeline against your manifests or configs. It bridges the gap between OPA's policy engine and everyday pipeline file testing.
5 / 22
What does 'shift-left security' mean?
Shift-left security moves security checks from the right side of the SDLC (production, post-deployment) to the left (design, development, CI pipeline). The earlier a vulnerability is found, the cheaper and faster it is to fix. Practices include developer security training, IDE security plugins, pre-commit hooks, SAST in CI, IaC scanning, and security requirements in Definition of Done. DevSecOps is the organisational model that operationalises shift-left security.
6 / 22
Reviewer: 'I'm seeing a Conftest rule failing on this PR. It's saying the Terraform module doesn't include a `version` attribute in its output. Should we add it, or is there something else going on here?'
Which of the following best describes the reviewer's concern and how they're approaching the issue?
The reviewer is highlighting a specific failure reported by Conftest—a policy violation. This indicates that Conftest isn't just flagging *any* issue, but is enforcing a particular rule about including version attributes in Terraform outputs. The incorrect options either misinterpret the nature of Conftest (it's not a general code error checker) or assume an acceptable design choice without considering the policy enforcement context. Understanding this distinction is key to effective use of compliance-as-code.
7 / 22
PR Description:
"@john.doe just merged this PR containing a new Kubernetes deployment. Conftest is failing with the message 'Missing required metadata for pod template'. I've checked the YAML and it *looks* correct – we're using Helm to generate the manifests. Should I manually add the missing metadata, or investigate why Conftest is flagging it?"
This scenario highlights a crucial aspect of Compliance-as-Code: Conftest isn't simply reporting an error; it's signaling that the policy *definition* is not correctly enforced. Adding the metadata blindly would be premature and potentially introduce further inconsistencies. The correct approach is to investigate why Conftest flagged the issue – perhaps the policy needs refinement or the Helm template requires adjustment to produce the desired output, ensuring a deeper understanding of how the pipeline is interpreting the requirements.
8 / 22
john.doe just submitted a pull request to update the deployment of our API service using Helm. The Conftest pipeline is reporting that the generated Kubernetes manifests are missing a `serviceAccountName` field. He's considering manually adding this attribute to the Helm chart template, but wants to ensure he's not overlooking a more fundamental issue with the compliance checks themselves. Which of the following actions would be MOST appropriate for john.doe to take next?
The key here is understanding that Conftest isn't just a scanner; it's an *enforcement engine*. It leverages OPA to determine if the generated code meets defined policies. The reviewer's question highlights a potential problem with the policy itself – perhaps the OPA rule doesn't explicitly require `serviceAccountName`. Adding it manually without understanding this could lead to a fragile solution and future issues. Investigating the OPA rule is the most proactive step for john.doe, ensuring he addresses the root cause rather than just patching the symptom.
9 / 22
Reviewer: 'I'm seeing a Conftest rule failing on this PR. It's saying the Terraform module doesn't include a `version` attribute in its output. Should we add it, or is there something else going on here?'
Which of the following best describes the reviewer's concern and how they're approaching the issue?
The reviewer is highlighting a specific failure reported by Conftest—a policy violation. This indicates that Conftest isn't just flagging *any* issue, but is enforcing a particular rule about including version attributes in Terraform outputs. The incorrect options either misinterpret the nature of Conftest (it's not a general code error checker) or assume an acceptable design choice without considering the policy enforcement context. Understanding this distinction is key to effective use of compliance-as-code.
10 / 22
PR Description:
"@john.doe just merged this PR containing a new Kubernetes deployment. Conftest is failing with the message 'Missing required metadata for pod template'. I've checked the YAML and it *looks* correct – we're using Helm to generate the manifests. Should I manually add the missing metadata, or investigate why Conftest is flagging it?"
This scenario highlights a crucial aspect of Compliance-as-Code: Conftest isn't simply reporting an error; it's signaling that the policy *definition* is not correctly enforced. Adding the metadata blindly would be premature and potentially introduce further inconsistencies. The correct approach is to investigate why Conftest flagged the issue – perhaps the policy needs refinement or the Helm template requires adjustment to produce the desired output, ensuring a deeper understanding of how the pipeline is interpreting the requirements.
11 / 22
john.doe just submitted a pull request to update the deployment of our API service using Helm. The Conftest pipeline is reporting that the generated Kubernetes manifests are missing a `serviceAccountName` field. He's considering manually adding this attribute to the Helm chart template, but wants to ensure he's not overlooking a more fundamental issue with the compliance checks themselves. Which of the following actions would be MOST appropriate for john.doe to take next?
The key here is understanding that Conftest isn't just a scanner; it's an *enforcement engine*. It leverages OPA to determine if the generated code meets defined policies. The reviewer's question highlights a potential problem with the policy itself – perhaps the OPA rule doesn't explicitly require `serviceAccountName`. Adding it manually without understanding this could lead to a fragile solution and future issues. Investigating the OPA rule is the most proactive step for john.doe, ensuring he addresses the root cause rather than just patching the symptom.
12 / 22
Reviewer: 'I'm seeing a Conftest rule failing on this PR. It's saying the Terraform module doesn't include a `version` attribute in its output. Should we add it, or is there something else going on here?'
Which of the following best describes the reviewer's concern and how they're approaching the issue?
The reviewer is highlighting a specific failure reported by Conftest—a policy violation. This indicates that Conftest isn't just flagging *any* issue, but is enforcing a particular rule about including version attributes in Terraform outputs. The incorrect options either misinterpret the nature of Conftest (it's not a general code error checker) or assume an acceptable design choice without considering the policy enforcement context. Understanding this distinction is key to effective use of compliance-as-code.
13 / 22
PR Description:
"@john.doe just merged this PR containing a new Kubernetes deployment. Conftest is failing with the message 'Missing required metadata for pod template'. I've checked the YAML and it *looks* correct – we're using Helm to generate the manifests. Should I manually add the missing metadata, or investigate why Conftest is flagging it?"
This scenario highlights a crucial aspect of Compliance-as-Code: Conftest isn't simply reporting an error; it's signaling that the policy *definition* is not correctly enforced. Adding the metadata blindly would be premature and potentially introduce further inconsistencies. The correct approach is to investigate why Conftest flagged the issue – perhaps the policy needs refinement or the Helm template requires adjustment to produce the desired output, ensuring a deeper understanding of how the pipeline is interpreting the requirements.
14 / 22
john.doe just submitted a pull request to update the deployment of our API service using Helm. The Conftest pipeline is reporting that the generated Kubernetes manifests are missing a `serviceAccountName` field. He's considering manually adding this attribute to the Helm chart template, but wants to ensure he's not overlooking a more fundamental issue with the compliance checks themselves. Which of the following actions would be MOST appropriate for john.doe to take next?
The key here is understanding that Conftest isn't just a scanner; it's an *enforcement engine*. It leverages OPA to determine if the generated code meets defined policies. The reviewer's question highlights a potential problem with the policy itself – perhaps the OPA rule doesn't explicitly require `serviceAccountName`. Adding it manually without understanding this could lead to a fragile solution and future issues. Investigating the OPA rule is the most proactive step for john.doe, ensuring he addresses the root cause rather than just patching the symptom.
15 / 22
Reviewer: 'I'm seeing a Conftest rule failing on this PR. It's saying the Terraform module doesn't include a `version` attribute in its output. Should we add it, or is there something else going on here?'
Which of the following best describes the reviewer's concern and how they're approaching the issue?
The reviewer is highlighting a specific failure reported by Conftest—a policy violation. This indicates that Conftest isn't just flagging *any* issue, but is enforcing a particular rule about including version attributes in Terraform outputs. The incorrect options either misinterpret the nature of Conftest (it's not a general code error checker) or assume an acceptable design choice without considering the policy enforcement context. Understanding this distinction is key to effective use of compliance-as-code.
16 / 22
PR Description:
"@john.doe just merged this PR containing a new Kubernetes deployment. Conftest is failing with the message 'Missing required metadata for pod template'. I've checked the YAML and it *looks* correct – we're using Helm to generate the manifests. Should I manually add the missing metadata, or investigate why Conftest is flagging it?"
This scenario highlights a crucial aspect of Compliance-as-Code: Conftest isn't simply reporting an error; it's signaling that the policy *definition* is not correctly enforced. Adding the metadata blindly would be premature and potentially introduce further inconsistencies. The correct approach is to investigate why Conftest flagged the issue – perhaps the policy needs refinement or the Helm template requires adjustment to produce the desired output, ensuring a deeper understanding of how the pipeline is interpreting the requirements.
17 / 22
john.doe just submitted a pull request to update the deployment of our API service using Helm. The Conftest pipeline is reporting that the generated Kubernetes manifests are missing a `serviceAccountName` field. He's considering manually adding this attribute to the Helm chart template, but wants to ensure he's not overlooking a more fundamental issue with the compliance checks themselves. Which of the following actions would be MOST appropriate for john.doe to take next?
The key here is understanding that Conftest isn't just a scanner; it's an *enforcement engine*. It leverages OPA to determine if the generated code meets defined policies. The reviewer's question highlights a potential problem with the policy itself – perhaps the OPA rule doesn't explicitly require `serviceAccountName`. Adding it manually without understanding this could lead to a fragile solution and future issues. Investigating the OPA rule is the most proactive step for john.doe, ensuring he addresses the root cause rather than just patching the symptom.
18 / 22
During a standup meeting, Sarah mentions that the Conftest pipeline flagged a new Terraform module with an issue. She explains that it's failing because the output doesn't consistently include a 'version' tag. What does Sarah likely mean by 'shifting left security' in this context?
Sarah's statement highlights 'shifting left security'. This means proactively identifying and addressing potential vulnerabilities – in this case, the missing version tag – at an earlier stage of the development process (Terraform module creation) instead of reacting to them later during deployment. Option A is too prescriptive; option C is incorrect because developers don't perform manual verification in a CI/CD pipeline. Option D misses the core principle.
19 / 22
Alex sends this Slack message to the team: 'Conftest is failing on the latest PR – it's complaining about missing metadata for the pod template. I've checked the YAML and it looks correct to me.' What is Alex primarily referring to when he says 'missing metadata'?
Alex's message refers to 'missing metadata' in the context of Conftest – specifically, the absence of defined configuration data within the YAML files for the pod template. This is a common issue where required fields are not present, causing Conftest to flag it as an error. Option A addresses syntax errors; option C is about pipeline support and option D concerns labels.
20 / 22
In a code review comment, David writes: 'The Conftest output shows a rule failing because the Helm chart doesn't specify a `serviceAccountName`. Should we update the Helm template to include it, or investigate if this is actually required by our security policies?' What does David's comment suggest about the role of OPA in this compliance-as-code scenario?
David's comment highlights OPA's role in policy enforcement. While Conftest detects the missing `serviceAccountName`, OPA (often used with tools like Argo CD) is responsible for *evaluating* whether this configuration meets a defined security policy – in this case, requiring all deployments to have a service account. Option A misrepresents OPA's function; option B is incorrect because OPA does participate in dynamic enforcement.
21 / 22
A new API deployment has failed due to a Conftest rule. The error message states: 'Missing required metadata for pod template'. Considering the principles of compliance-as-code, what is the *most* appropriate action for the development team to take?
The correct approach aligns with the core principles of compliance-as-code. Instead of blindly rolling back (A), ignoring the error (B) or escalating unnecessarily (D), the team should investigate *why* the metadata is missing – this is key to 'shifting left'. Fixing the root cause before deploying again ensures consistent compliance and prevents future failures. This action emphasizes proactive problem-solving.
22 / 22
During a team retrospective, Maria explains that they're using Conftest to scan their Terraform modules. She says: 'We're essentially automating the process of validating our infrastructure configurations against predefined rules.' What is Maria describing in this context?
Maria's explanation accurately captures the essence of using Conftest – automating infrastructure validation. This aligns with the CI/CD principles of 'shifting left' by integrating compliance checks into the development pipeline. Option A describes a manual audit; option C focuses on performance optimization and option D is about debugging.
What does the "Compliance-as-Code Pipeline Vocabulary" exercise cover?
Practice vocabulary for compliance-as-code, policy engines in CI/CD, OPA, Checkov, Conftest, and shift-left security principles.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
How many questions are in "Compliance-as-Code Pipeline Vocabulary"?
This exercise has 22 questions. Each one gives instant feedback with an explanation, so you can see exactly why an answer is right or wrong.
Do I need to create an account to save my progress?
No account is required. The progress bar and score are tracked in your browser for the current session -- the exercise is designed to be a quick, repeatable drill rather than something you resume later.
What happens if I get an answer wrong?
You'll see the correct answer highlighted immediately, along with a short explanation of why it's correct. Wrong answers aren't penalized beyond your score, and you can keep going through every question.
How is this exercise different from reading an article?
Articles explain vocabulary and concepts through prose, while exercises like this one are interactive drills -- multiple-choice questions -- that test and reinforce your recall of specific terms and phrasing.
Can I retry this exercise?
Yes -- use the "Try again" button on the results screen to reset your score and go through all the questions again from the start.
Where can I find more Devsecops Pipeline Language exercises?
Browse the full Devsecops Pipeline Language hub for related drills, or check the site-wide exercises index for other IT English topics.
Is this exercise suitable for beginners?
This exercise assumes basic familiarity with IT terminology. If a term feels unfamiliar, check the site Glossary for a plain-English definition before attempting the questions.
How often is new content like this published?
New exercises are added regularly across all categories, alongside new vocabulary sets and articles. Check back on the exercises hub to see what's new.