In a CircleCI .circleci/config.yml, what is an orb, and what kinds of reusable elements can a single orb contain?

## The problem orbs solve CircleCI configuration lives in a single `.circleci/config.yml` per repository. Without a reuse mechanism, twenty repositories that all check out code, restore a dependency cache, install packages, run tests and upload results end up carrying twenty near-identical copies of the same YAML — and a fix to the shared part has to be pasted twenty times. An orb is CircleCI's answer: a **versioned package of configuration**, published to a registry under a namespace, that any config pulls in by name and version. This is the feature the leaf is really about. Other platforms approximate it with templates or with a marketplace of individual steps; CircleCI's unit of reuse is a package that can carry whole jobs and whole environments, not only steps. ## Declaring and using one Orbs require pipeline configuration `version: 2.1`; a `version: 2` config cannot use them. ```yaml version: 2.1 orbs: node: circleci/[email protected] jobs: test: executor: node/default steps: - checkout - node/install-packages - run: npm test workflows: build: jobs: - test ``` The left-hand key `node` is a local alias you choose; the right-hand side `circleci/[email protected]` is `namespace/orb-name@version`. Everything the orb provides is then referenced with that alias and a slash: `node/default`, `node/install-packages`. ## The three element types - **Commands** — a named, parameterizable sequence of steps. Used inside a job's `steps:` list exactly where you would otherwise write several `run:` steps. This is the finest-grained unit. - **Jobs** — a complete job: its executor and its steps. You can place an orb-provided job straight into `workflows:` without writing a `jobs:` entry yourself, and pass parameters to it. - **Executors** — a named environment definition (image, resource class, working directory, environment variables) that a job selects with `executor:`. This is what lets an orb standardize *where* work runs, not just what runs. A single orb commonly ships all three, so adopting it can replace both the steps and the environment definition in a repo's config. ## Resolution happens at compile time When a pipeline is triggered, CircleCI compiles the config: orb references are fetched from the registry and their elements are inlined, producing one flat configuration that the jobs then execute. Two consequences matter in interviews. First, an orb cannot make decisions at runtime that plain configuration could not — it is text substitution, not a plugin executing inside the platform. Second, the resolved version is fixed for that pipeline run, so a mid-run publish of a new orb version cannot change what is already executing. Locally, `circleci config process .circleci/config.yml` (CircleCI CLI) prints the fully expanded configuration, and `circleci config validate` checks it. Reading the processed output is the honest way to answer "what is this orb actually adding to my pipeline?" ## Where orbs come from, and the trust question Orbs live in a public registry organized by namespace. Orbs in the `circleci` namespace are authored by CircleCI itself; others are published by partners, by the community, or by your own organization into its own namespace, and CircleCI also supports orbs kept private to an organization. Because an orb's steps execute inside *your* job, with your environment variables and whatever context secrets that job has been granted, an orb reference is a third-party dependency in the strictest sense. Treat it as one: know who owns the namespace, pin the version deliberately, and read the processed config the first time you adopt it. Never publish a public orb containing credentials — the source of a public orb is readable by anyone. ## Pitfalls candidates trip on - **The version is not optional.** `circleci/node` with no `@version` will not resolve; a reference must name a version or a version-like alias. - **An orb is not a server plugin.** Nothing gets installed on an agent, and there is no orb runtime — the platform never runs orb code outside your job's own steps. - **Alias confusion.** If two orbs both provide a command called `install`, the alias you chose in the `orbs:` block is what disambiguates them. - **An executor is not an orb.** The executor decides the machine or container a job runs on; the orb is the package that may happen to define one.