> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Workflow Standardization and Enterprise Policies

> Centralizing CI using reusable GitHub Actions workflows and enterprise allow lists to reduce pipeline sprawl, improve security, and enforce consistent CI practices across repositories.

Without a centralized workflow strategy, large organizations accumulate many divergent CI pipelines. When each team writes its own pipeline, you get inconsistent security, varying update practices, and high maintenance overhead.

![A slide titled "The Pipeline Sprawl Problem" showing a stylized building icon at the top with several curved lines branching downward. The lines connect to five labeled areas—Payments, Web, Mobile, Data, and Search—each represented by small square pipeline icons.](https://mintcdn.com/kodekloud-c4ac6d9a/Ae2SeWV4btujbkSt/images/GitHub-Administration-Certification/GitHub-Actions-and-Runners/Workflow-Standardization-and-Enterprise-Policies/pipeline-sprawl-payments-webmobile-data-search.jpg?fit=max\&auto=format\&n=Ae2SeWV4btujbkSt\&q=85\&s=5ff188547d7953f90224ffee1005f81f)

If you manage 200 repositories, that can become 200 different CI implementations and 200 separate security configurations. When a critical vulnerability appears in a build tool, patching every workflow individually is time-consuming and error-prone. Reusable workflows let platform teams centralize CI best practices and reduce that operational cost.

Think of a reusable workflow as the global franchise recipe. Without it, each shop invents its own dough and outcomes vary wildly.

![A minimalist slide titled "The Franchise Analogy" showing a highlighted shop icon with a pizza slice above it. Below are smaller shop icons labeled Berlin, Austin, Lagos, Osaka, Lima, and Oslo.](https://mintcdn.com/kodekloud-c4ac6d9a/Ae2SeWV4btujbkSt/images/GitHub-Administration-Certification/GitHub-Actions-and-Runners/Workflow-Standardization-and-Enterprise-Policies/franchise-analogy-highlighted-pizza-shop-branches.jpg?fit=max\&auto=format\&n=Ae2SeWV4btujbkSt\&q=85\&s=192f2de908176b68e3e6054918a1b54e)

A platform team maintains a single, security-vetted reusable workflow. Product teams call that workflow with a single `uses` line at the job level and can still supply job-specific inputs, secrets, or extra steps.

Example: caller workflow in a product repository (`.github/workflows/ci.yml`)

```yaml theme={null}
name: CI
on:
  push:
    branches: [main]

jobs:
  build:
    uses: acme/.github/workflows/reusable-ci.yml@v1
    with:
      node-version: '20'
    secrets:
      NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
    # Or pass all caller secrets:
    # secrets: inherit
```

To allow a workflow to be invoked this way, the called workflow must declare the `workflow_call` trigger. That exposes inputs and secrets so callers can pass values explicitly.

Example reusable workflow in the platform repo (`.github/workflows/reusable-ci.yml`):

```yaml theme={null}
name: Reusable CI

on:
  workflow_call:
    inputs:
      node-version:
        required: false
        type: string
    secrets:
      NPM_TOKEN:
        required: false

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: ${{ inputs.node-version }}

      - name: Install
        run: npm ci

      - name: Test
        run: npm test
```

Reusable workflows are invoked at the job level using `uses` and can accept `inputs` and `secrets`. To forward all allowed caller secrets, use `secrets: inherit` in the caller workflow.

Do not confuse reusable workflows with composite actions. Key differences:

| Concept | Invocation level | Typical use case |
| - | - | - |
| Reusable workflow | Job level (`uses` in jobs) | Central CI jobs, platform-managed pipelines, shared job structure |
| Composite action | Step level (`uses` in steps) | Reusable step sequences or encapsulated multi-command steps inside a single job |

Illustration of the structural difference:

```yaml theme={null}
Workflow run
job: lint
job: build ← reusable workflow
job: deploy

job: build
  step: checkout
  step: setup ← composite action (contains multiple run commands)
  step: test
```

Enterprise-level governance sits above this, controlling where developers may source actions. By default, workflows can reference actions from anywhere; as an admin you should restrict that using organization-level allowed actions (see GitHub docs: [https://docs.github.com/en/organizations/keeping-your-organization-secure/managing-github-actions-settings-for-your-organization#configuring-allowed-actions-for-your-organization](https://docs.github.com/en/organizations/keeping-your-organization-secure/managing-github-actions-settings-for-your-organization#configuring-allowed-actions-for-your-organization)).

You can restrict actions to one of these modes:

| Allow list mode | What it permits |
| - | - |
| GitHub Actions only | Only actions created by GitHub |
| Verified creators (Marketplace partners) | Actions published by verified Marketplace partners (blue checkmark) |
| Allow list of specific actions | Curated list of individual actions you explicitly allow |

![Screenshot of an "Enterprise Actions Policy" settings panel with the "Allow select actions" radio button selected and a checked item for "Actions created by GitHub."](https://mintcdn.com/kodekloud-c4ac6d9a/Ae2SeWV4btujbkSt/images/GitHub-Administration-Certification/GitHub-Actions-and-Runners/Workflow-Standardization-and-Enterprise-Policies/enterprise-actions-policy-allow-select-github.jpg?fit=max\&auto=format\&n=Ae2SeWV4btujbkSt\&q=85\&s=5815a5e6ac8b4455e1df06c904348514)

When browsing the GitHub Marketplace ([https://github.com/marketplace/actions](https://github.com/marketplace/actions)), verified partner actions display a blue checkmark. You can permit those while blocking unverified community actions.

![A screenshot of a "Verified Marketplace Actions" panel (GitHub Marketplace - Actions) listing actions like "Configure AWS Credentials" and "Build and Push Docker Image," both marked "Allowed" with green checkmarks. The list also includes a "Fast Cache Helper" entry by a community developer.](https://mintcdn.com/kodekloud-c4ac6d9a/Ae2SeWV4btujbkSt/images/GitHub-Administration-Certification/GitHub-Actions-and-Runners/Workflow-Standardization-and-Enterprise-Policies/github-marketplace-actions-allowed.jpg?fit=max\&auto=format\&n=Ae2SeWV4btujbkSt\&q=85\&s=5efe8a6af6ec7abf9d7e87e6db834383)

If a workflow tries to use an action not on the enterprise allow list, the run fails immediately during the policy check (see About allowed and blocked actions: [https://docs.github.com/en/actions/learn-github-actions/security-hardening-for-github-actions#about-allowed-and-blocked-actions](https://docs.github.com/en/actions/learn-github-actions/security-hardening-for-github-actions#about-allowed-and-blocked-actions)).

Important: Restricting allowed actions protects your environment but can cause immediate workflow failures if teams reference blocked or unverified actions. Communicate policy changes and provide a curated list of approved alternatives.

For both the exam and practical governance, keep these concise facts top of mind:

* Reusable workflows use the `workflow_call` trigger and are invoked at the job level.
* Composite actions are invoked at the step level and group multiple commands inside a step.
* Enterprise allow lists (including the "verified creators" filter in the Marketplace) determine which third-party actions are permitted.

![A slide titled "Exam Facts" with three numbered items: the reusable workflow trigger is workflow\_call (called at the job level), composite actions are called at the step level (they bundle multiple run commands), and allow lists are configured at the enterprise level.](https://mintcdn.com/kodekloud-c4ac6d9a/Ae2SeWV4btujbkSt/images/GitHub-Administration-Certification/GitHub-Actions-and-Runners/Workflow-Standardization-and-Enterprise-Policies/examfacts-workflowcall-job-composite-step-enterpriseallowlists.jpg?fit=max\&auto=format\&n=Ae2SeWV4btujbkSt\&q=85\&s=d468513f6cdee081fb5874405c5556d5)

Further reading and references:

* Reusing workflows: [https://docs.github.com/en/actions/using-workflows/reusing-workflows](https://docs.github.com/en/actions/using-workflows/reusing-workflows)
* Composite actions: [https://docs.github.com/en/actions/creating-actions/creating-a-composite-action](https://docs.github.com/en/actions/creating-actions/creating-a-composite-action)
* Configuring allowed actions for organizations: [https://docs.github.com/en/organizations/keeping-your-organization-secure/managing-github-actions-settings-for-your-organization#configuring-allowed-actions-for-your-organization](https://docs.github.com/en/organizations/keeping-your-organization-secure/managing-github-actions-settings-for-your-organization#configuring-allowed-actions-for-your-organization)
* About allowed and blocked actions: [https://docs.github.com/en/actions/learn-github-actions/security-hardening-for-github-actions#about-allowed-and-blocked-actions](https://docs.github.com/en/actions/learn-github-actions/security-hardening-for-github-actions#about-allowed-and-blocked-actions)

> [card] [Watch Video](https://learn.kodekloud.com/user/courses/github-administration-certification/module/3ba840c5-7afb-4da9-8395-a430a6354557/lesson/900898ec-cdae-4138-9ba5-d38460d51824)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.