GitHub Actions reusable workflows and composite actions enable DRY CI/CD pipelines across repositories. Understanding workflow_call, input/secret contracts, OIDC authentication, and the difference between reusable workflows and composite actions is essential for CI/CD platform engineers.
0 / 5 completed
1 / 5
What trigger event must a reusable GitHub Actions workflow define to be callable from other workflows?
A reusable workflow must define on: workflow_call as its trigger. This event enables the workflow to be called from other workflows using the uses: keyword in a job's definition. Without workflow_call, the workflow cannot be referenced as a reusable component.
2 / 5
A calling workflow uses jobs: build: uses: org/repo/.github/workflows/build.yml@main with: node-version: '20'. What restriction applies to the with: inputs?
Inputs passed via with: must be declared in the reusable workflow's on.workflow_call.inputs section with a type (string, boolean, number) and optionally required and default. Undeclared inputs cause a validation error. This enforces a clear contract between calling and reusable workflows.
3 / 5
How does a reusable workflow securely receive secrets from its caller?
The reusable workflow declares expected secrets in on.workflow_call.secrets (optionally marked required: true). The caller passes them using secrets: in the job definition (or secrets: inherit to pass all caller secrets automatically). Secrets are never exposed as plain text — they flow as encrypted values.
4 / 5
What is the difference between a reusable workflow and a composite action in GitHub Actions?
A reusable workflow is called as a job — it spins up its own runner and can have multiple steps, services, and parallel jobs. A composite action is called as a step within an existing job — it runs on the calling job's runner and shares its filesystem and environment. Reusable workflows are heavier but more isolated; composite actions are lighter and share context.
5 / 5
A company deploys to production using GitHub Actions with OIDC instead of long-lived AWS credentials. What does OIDC enable in this context?
With OIDC, GitHub Actions generates a short-lived JWT token for each workflow run. AWS IAM is configured to trust GitHub's OIDC provider; the workflow calls aws-actions/configure-aws-credentials which exchanges the JWT for temporary AWS credentials via STS. This eliminates the need to store long-lived AWS access keys as GitHub secrets.