How would you reuse pipeline steps across projects using PaC principles?

WHAT THIS TESTS: Your ability to balance code reuse with team autonomy in a PaC environment. Interviewers want to see that you understand the difference between semantic duplication and incidental duplication, and that you know how to build composable primitives rather than monolithic shared pipelines that couple unrelated services.

A GOOD ANSWER COVERS: First, extraction strategy: move common steps into versioned reusable units such as Jenkins shared libraries, GitHub Actions reusable workflows, Azure Pipeline templates, or Tekton bundles. Second, interface design: define strict input contracts with required and optional parameters, environment variable conventions, and artifact expectations so consumers do not need to read the implementation. Third, consumption model: teams should compose these units into their own pipeline definitions rather than inheriting from a single parent pipeline, preserving independent release cadences. Fourth, versioning and governance: pin to semantic versions or commit SHAs, run integration tests in the library repo before publishing, and use CODEOWNERS or approval gates for changes that affect production deployments. Fifth, observability: the shared code should emit structured logs and metrics so calling pipelines can debug failures without tracing across repositories.

COMMON WRONG ANSWERS: Suggesting copy-paste as a quick fix. Proposing a single global pipeline that every team must use, which creates a bottleneck and forces lockstep deployments. Recommending unversioned includes that let a library change immediately break every consumer. Ignoring secrets handling by assuming the shared code can access all environments equally. Over-engineering by turning every two-line script into a reusable abstraction, which adds indirection without value.

LIKELY FOLLOW-UPS: How would you roll out a breaking change to a shared template used by fifty teams? How do you handle secrets or environment-specific configuration when the shared code runs in different cloud accounts? What is your testing strategy for the library itself? How do you prevent a compromised shared library from becoming a supply-chain attack vector?

ONE CONCRETE EXAMPLE: A security scan step that runs Trivy on container images. Instead of embedding the install, configure, and run commands in every microservice repository, you publish a GitHub reusable workflow called security-scan.yml at v2.1.0. It accepts inputs for image-tag, severity-threshold, and fail-on-cve. Each service repo calls it with their own build context. When Trivy releases a new version, you update the reusable workflow, test it against a canary repository, tag v2.2.0, and let teams opt in by bumping their reference. No team is forced to upgrade on Friday afternoon.