How would you implement conditional logic in a pipeline?

What's really being asked

This question tests whether you understand the difference between trigger-time filtering and runtime conditional execution in pipeline engines. A senior candidate should demonstrate that they can use the platform's native expression language to skip or include jobs based on branch, event type, or custom variables, rather than falling back to imperative shell scripting which obscures the DAG and breaks the visual UI.

The full answer

First, job-level conditionals using the if key with built-in contexts and expressions, for example checking github.ref equals refs/heads/main to decide whether a deploy job runs. Second, the distinction between on.push.branches filters at the workflow trigger level versus runtime if conditions inside the job; triggers prevent the whole workflow from starting while runtime conditionals let earlier stages like test run on every branch and only gate the deploy stage. Third, using environment protection rules such as required reviewers or deployment branches as an additional safety layer beyond YAML conditionals. Fourth, handling pull request versus push events differently by inspecting github.event_name so that deploys do not fire on PR builds. Fifth, composing reusable workflows with inputs and conditionals passed from the caller so logic stays DRY across repositories.

The mistakes people make

A red flag is suggesting a single monolithic job where a bash script checks the branch name and exits zero or non-zero; this hides job state from the platform dashboard and prevents granular retry. Another mistake is conflating workflow triggers with job conditions and claiming that on.push.branches main will selectively run only the deploy job when in fact it suppresses the entire workflow for other branches. Candidates also err by hardcoding secrets or environment names inside conditional expressions rather than using environment protection rules.

What usually comes next

The interviewer may ask how you would handle a hotfix branch pattern where release branches should also trigger deploys, or how you would implement a manual approval gate before production. They might also probe failure modes, such as what happens when an if expression evaluates incorrectly due to a null context field, or how you test conditional logic without merging to main.

A concrete example

In GitHub Actions, you define a build job that runs on every push and pull request. Then you define a deploy job that needs build and includes if github.ref equals refs/heads/main and github.event_name equals push. The deploy job targets an environment named production which has a protection rule restricting deployment branches to main and requiring one reviewer. This means even if a malicious actor bypasses the YAML conditional, the environment gate blocks the deployment.