GitHub GH-200: Why a Workflow Passes but Deploys Nothing

A GitHub Actions run ends with a green check, but the expected application version never reaches staging. The build job passed; the deployment job was skipped because a condition evaluated differently than the author expected. Reliable automation requires understanding triggers, job dependencies, permissions and environment protection as one execution system.

GH-200, GitHub Actions, covers creating and troubleshooting workflows, authoring actions, organization-scale administration and securing automation. Microsoft’s January 2026 study guide puts substantial emphasis on workflow design and enterprise management, not just YAML syntax. The GitHub GH-200 exam page is best used to guide experiments in a repository where the event history and job logs are available.

Read the event before reading the failed step

Workflows respond to events such as pushes, pull requests, manual dispatches and schedules. Their execution can also depend on branches, paths and expressions. A job that never started cannot be repaired by changing a command inside it. First inspect which workflow event occurred, which ref it used and whether filters admitted the run. Distinguish a workflow that was not triggered from one that triggered but skipped a downstream job.

Create a repository with one push-triggered workflow and a second workflow that runs only for a selected branch. Push a change to the wrong branch, then check whether any run exists. Next add a conditional job and examine how the dependency result affects later execution. This basic exercise prevents a common mistake: assuming that an apparently valid workflow file must run for every repository change. The event payload is part of the input to the automation.

Artifacts and caches have different jobs

A build artifact carries an output from one step or job to another or preserves it for later use. A cache accelerates repeated work by reusing dependencies or intermediate material when keys match. Confusing the two can produce unreliable deployments, particularly when cached outputs are treated as proof that the current source was built. Design a promotion path in which the tested artifact is the one deployed, with a traceable version and digest. The same deployment reliability problem is addressed from the Azure DevOps perspective in Microsoft AZ-400 release-pipeline engineering, with emphasis on traceable releases. Build artifacts often become container images; Mirantis DCA container operations explores the Docker operations required to use those images safely.

Consider a test job and a release job running on different runners. Local files from the first job are not automatically present in the second. Upload the intended build output and download it where required; examine retention and access expectations. For dependency caches, choose keys that reflect lockfiles and runtime differences, and know when to invalidate them. Reproducibility should not depend on an undocumented directory left by a previous run.

Permissions are part of workflow logic

Workflows can authenticate with the built-in token, repository or environment secrets, and in some designs an external identity provider through OpenID Connect. Each option has implications for duration, scope and rotation. Avoid issuing a broadly privileged, long-lived credential simply because it makes the initial deployment easier. Specify the permissions needed by each job, protect deployment environments and limit what untrusted pull requests can access.

In a test pipeline, deliberately remove permission to create a release. Compare the resulting authorization error with a bad command or missing artifact. Then restore only the needed permission rather than enabling every scope. Review how third-party actions are selected and version-pinned. A workflow can be syntactically correct yet unsafe because it executes unreviewed code with elevated rights; security review must cover the dependency chain of the automation itself.

Reuse should reduce drift, not hide behavior

Reusable workflows, composite actions and JavaScript or Docker actions serve different purposes. A reusable workflow can standardize a multi-job pipeline, while an action packages a focused operation; enterprise policies may determine which actions teams are allowed to consume. Identify stable inputs, outputs and required secrets before designing the interface. Teams need a route to upgrade shared automation without unexpectedly breaking production releases.

Build a reusable test workflow with inputs for language version and an output for the artifact name. Call it from two repositories and change the shared implementation deliberately. Examine which callers pick up the change and when. Document compatibility and release rules. The exam rewards understanding how a component is distributed and maintained, not just how to copy a YAML example from one repository to another.

Diagnosis requires the complete run story

A useful troubleshooting sequence starts with event details, evaluates job conditions, inspects runner selection, verifies dependencies and token rights, and only then reads failing step logs. Mask sensitive values and preserve enough evidence to reproduce the error. Enterprise administrators also need visibility into concurrency, runner queues, usage limits and organizational policies that affect what developers can run.

For GH-200 preparation, intentionally cause four different outcomes: no run, skipped job, denied permission and failed command. Explain why each produces different evidence and needs a different correction. Add one deployment that requires an environment approval. When you can reason from the event to the artifact actually deployed, a green check becomes meaningful rather than comforting decoration.