Learn pipeline-as-code vocabulary: Jenkinsfile, GitHub Actions YAML, pipeline triggers, pipeline stages and jobs, CI config in version control — the language of modern CI/CD configuration.
0 / 14 completed
1 / 14
The DevOps engineer says: 'The Jenkinsfile defines the pipeline — it lives in the root of the repository.' What is a Jenkinsfile?
A Jenkinsfile is a text file (written in Groovy-based Declarative or Scripted DSL) that defines a Jenkins pipeline. It specifies stages (Build, Test, Deploy), steps within each stage, conditions (when to run), and post-actions. Storing the Jenkinsfile in the repository is the pipeline-as-code approach — the pipeline definition is versioned alongside the application code.
2 / 14
The team lead says: 'We moved from Jenkins to GitHub Actions last year.' What is GitHub Actions?
GitHub Actions is GitHub's integrated CI/CD platform. Pipelines (called workflows) are defined as YAML files in the .github/workflows/ directory of the repository. Workflows consist of jobs, steps, and actions (reusable units). They trigger on events like push, pull_request, or schedule, and run on GitHub-hosted or self-hosted runners.
3 / 14
The CI configuration comment reads: 'The pipeline triggers on push to main.' What does 'triggers on push to main' mean?
A pipeline trigger defines what event causes the pipeline to start. 'Triggers on push to main' means the CI/CD pipeline runs automatically whenever a commit is pushed to the main branch. Common triggers include: push to a branch, pull request opened/updated, a scheduled cron time, or a manual workflow dispatch. Triggers are defined in the pipeline YAML configuration.
4 / 14
The engineer explains: 'Pipeline-as-code means the CI config is in version control alongside the application.' What is the key benefit of this approach?
Pipeline-as-code means the CI/CD pipeline definition is stored as a file (Jenkinsfile, .github/workflows/*.yml, .gitlab-ci.yml) in the version-controlled repository. Benefits include: pipeline changes go through code review, the pipeline history is auditable via git log, pipelines are reproducible (checking out any commit gives you the pipeline that ran at that point), and onboarding is easier.
5 / 14
The GitHub Actions workflow file contains: 'jobs: build: / test:'. What is the difference between a 'job' and a 'step' in a pipeline?
In GitHub Actions (and most CI systems), a workflow contains jobs. Each job runs on a runner (a virtual machine or container). Jobs can run in parallel or have dependencies on other jobs. Each job contains steps — individual tasks such as checking out code, running tests, or building a Docker image. Steps within a job run sequentially on the same runner.
6 / 14
kubectl get deployments -n myapp
During a code review, Sarah asks you to explain the purpose of this command. You need to describe it in a way that aligns with the concept of Pipeline-as-Code and how it integrates with Kubernetes deployment management.
The correct answer highlights that the command retrieves information about existing deployments. This is crucial because Pipeline-as-Code relies on dynamically retrieving and reacting to changes in your infrastructure (in this case, Kubernetes). The other options misinterpret the command's purpose – it doesn't define deployments or trigger rebuilds; instead, it provides data used *within* the pipeline definition. Understanding how pipelines interact with infrastructure is a core element of Pipeline-as-Code vocabulary.
7 / 14
kubectl get deployments -n myapp
During a code review, Sarah asks you to explain the purpose of this command. You need to describe it in a way that aligns with the concept of Pipeline-as-Code and how it integrates with Kubernetes deployment management.
The correct answer highlights that the command retrieves information about existing deployments. This is crucial because Pipeline-as-Code relies on dynamically retrieving and reacting to changes in your infrastructure (in this case, Kubernetes). The other options misinterpret the command's purpose – it doesn't define deployments or trigger rebuilds; instead, it provides data used *within* the pipeline definition. Understanding how pipelines interact with infrastructure is a core element of Pipeline-as-Code vocabulary.
8 / 14
kubectl get deployments -n myapp
During a code review, Sarah asks you to explain the purpose of this command. You need to describe it in a way that aligns with the concept of Pipeline-as-Code and how it integrates with Kubernetes deployment management.
The correct answer highlights that the command retrieves information about existing deployments. This is crucial because Pipeline-as-Code relies on dynamically retrieving and reacting to changes in your infrastructure (in this case, Kubernetes). The other options misinterpret the command's purpose – it doesn't define deployments or trigger rebuilds; instead, it provides data used *within* the pipeline definition. Understanding how pipelines interact with infrastructure is a core element of Pipeline-as-Code vocabulary.
9 / 14
kubectl get deployments -n myapp
During a code review, Sarah asks you to explain the purpose of this command. You need to describe it in a way that aligns with the concept of Pipeline-as-Code and how it integrates with Kubernetes deployment management.
The correct answer highlights that the command retrieves information about existing deployments. This is crucial because Pipeline-as-Code relies on dynamically retrieving and reacting to changes in your infrastructure (in this case, Kubernetes). The other options misinterpret the command's purpose – it doesn't define deployments or trigger rebuilds; instead, it provides data used *within* the pipeline definition. Understanding how pipelines interact with infrastructure is a core element of Pipeline-as-Code vocabulary.
10 / 14
Mark from QA sends a Slack message: 'The build failed again! It's complaining about missing dependencies. I think the pipeline needs to install them before running the tests.' Considering Pipeline-as-Code, what is Mark *really* asking for when he mentions 'installing dependencies'?
Mark is highlighting that Pipeline-as-Code emphasizes defining *every* step in the process – including dependency installation – within the configuration itself. Option B accurately describes this; a pipeline definition explicitly specifies how dependencies are installed. Options A and C represent more complex approaches, while option D is a reactive response to a failure, not a core principle of Pipeline-as-Code.
11 / 14
During a PR review, David explains: 'We're using a YAML file to define our CI/CD pipeline. It specifies which services are deployed and in what order.' What is the core concept being illustrated here relating to Pipeline-as-Code?
David's statement centers around the idea that the CI/CD pipeline configuration – in this case, the YAML file – is treated as code. This aligns with Pipeline-as-Code, where infrastructure and deployments are defined declaratively using code (like YAML) instead of relying on manual processes or graphical tools. Option A describes a different technology; option C contradicts the concept; and option D offers a non-code approach.
12 / 14
You're reviewing a GitHub Actions workflow file for a new feature. The workflow includes this step: `steps: - name: 'Build Application' uses: actions/checkout@v3
outputs: [always()]`. What does the actions/checkout@v3 action contribute to within the context of Pipeline-as-Code?
The actions/checkout@v3 action is a fundamental step in many CI/CD pipelines. As part of Pipeline-as-Code, it's explicitly defined within the workflow file – and, crucially, represents one *step* within the larger, codified pipeline definition. Options A, B, and D describe other functionalities that would typically be handled by separate steps or actions.
13 / 14
During a standup meeting, Sarah explains: 'We're using Pipeline-as-Code to manage our deployments. This means that every stage of the process – from building the code to deploying it to production – is defined in a single, version-controlled file.' What's the *primary* benefit she's highlighting?
Sarah is emphasizing the core benefit of Pipeline-as-Code – reproducibility and consistency. By defining the entire pipeline in code, you can ensure that deployments are executed exactly as defined every time, minimizing variations and human error. Options A, C, and D represent potential *secondary* benefits but aren't the primary driver.
14 / 14
You're debugging a failed CI build. The pipeline logs show that a step named 'Run Tests' didn't execute. Examining the Pipeline-as-Code configuration (a YAML file), you find an empty section for this step. What is the most likely cause of this issue?
If a step is defined in Pipeline-as-Code but has no associated actions or configuration within that definition (like specifying which tests to run), the pipeline execution engine won't know what to do. This results in the step not executing. Options A and C describe potential problems with the test suite or build process, while option D suggests a problem with the testing environment itself.
What will I practice in "Pipeline-as-Code Vocabulary"?
This is a CI/CD Pipeline Language exercise set. It walks through 14 scenario-based multiple-choice questions built around real usage of CI/CD Pipeline Language 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 14 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 CI/CD Pipeline Language 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 CI/CD Pipeline Language exercises?
See the CI/CD Pipeline Language 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 — CI/CD Pipeline Language vocabulary comes up often in technical discussions and interviews. Pair this exercise with our dedicated Interview Preparation section for role-specific practice.