This set builds vocabulary for reusable CI configuration and pipeline orchestration.
0 / 5 completed
1 / 5
At standup, a dev mentions reusing a pre-packaged, shareable set of CI configuration for a common task like deploying to AWS instead of writing it from scratch. What is this called in CircleCI?
An orb is a reusable, shareable package of CircleCI configuration, encapsulating common tasks like deploying to a specific cloud provider, so teams don't need to write and maintain that boilerplate configuration from scratch in every project. This promotes consistency and reduces duplicated effort across pipelines. Orbs can be published publicly or kept private within an organization.
2 / 5
During a design review, the team wants to run the same job definition with different input parameters, like different deployment target environments. Which feature supports this?
Parameterized jobs or commands accept configurable inputs, like a target environment name, letting the same underlying job definition be reused across different contexts instead of duplicating nearly identical configuration for each variation. This reduces maintenance overhead when the underlying logic is the same but inputs differ. Parameterization is a key mechanism that makes orbs and reusable configuration practical.
3 / 5
In a code review, a dev references the sequence of individual jobs, like build, test, and deploy, executed in a defined order for a given pipeline. What is this called?
A workflow orchestrates the sequence and dependencies between individual jobs, such as running tests before triggering a deployment, defining the overall structure of a CI/CD pipeline. This ordering ensures later stages only run once earlier stages succeed. Workflows are the top-level construct that ties together the individual jobs and orbs used in a pipeline.
4 / 5
An incident report shows a pipeline used an outdated version of a third-party orb that introduced a breaking change without the team noticing. What practice would prevent this?
Pinning an orb to a specific, deliberately reviewed version prevents an unexpected breaking change in a newer release from silently affecting the pipeline, giving the team control over when and how they adopt updates. Always tracking the latest version automatically introduces risk of unreviewed changes landing unexpectedly. This version-pinning discipline applies to any external dependency a CI pipeline relies on, not just orbs specifically.
5 / 5
During a PR review, a teammate asks why the team uses a published orb for AWS deployment instead of writing the deployment steps manually in every project's config. What is the reasoning?
Writing the same deployment steps manually in every project's configuration duplicates effort and risks inconsistency, while a shared orb centralizes that logic so a fix or improvement benefits every project using it at once. This reuse mirrors the value of a shared library versus copy-pasted code across a codebase. The tradeoff is a dependency on the orb's maintainers keeping it correct and up to date.