GitHub Actions Advanced Practice Exam: Hard Questions 2025

Your monorepo contains 20 microservices under /services/* and a shared library under /libs/shared. A workflow builds and tests on pull_request. You need to ensure only affected services run, but any change to /libs/shared must trigger builds for all services. Additionally, you must avoid running on docs-only changes under /docs. Which approach best meets the requirement with the least maintenance overhead?

A workflow uses OIDC to authenticate to Azure and deploy infrastructure. Security requires that deployments to production can only occur from the default branch AND only when the workflow is manually approved by designated reviewers. The team currently uses a single workflow with jobs: build, plan, apply. What is the most secure and idiomatic way to enforce this in GitHub Actions?

A workflow is reusable via workflow_call and is used by multiple repositories. It provisions infrastructure and needs Azure credentials. You must prevent callers from overriding the Azure subscription/tenant, and you must ensure secrets are not leaked to logs even if a caller passes unexpected inputs. What design best enforces these constraints?

You maintain a reusable workflow used across an enterprise. Callers want to customize behavior per repo, but you must keep a stable contract. You need to allow optional steps (e.g., run SAST, publish artifacts) without duplicating workflows. Which pattern is the most maintainable and aligns with GitHub Actions best practices?

A repository uses a reusable workflow that expects secrets for signing and publishing. Some consuming repositories are public and must not receive signing secrets on pull_request events from forks. You must still run tests for fork PRs. What is the safest configuration?

A workflow intermittently fails during dependency restore due to transient network errors. Re-running usually succeeds. You must reduce wasteful re-runs, keep run time low, and ensure correctness. Which solution is most appropriate?

Two workflows deploy to the same Azure App Service slot. One is triggered by push to main, the other by workflow_dispatch hotfix. Deployments occasionally overlap and cause partial rollouts. You must ensure only one deployment per slot runs at a time, while allowing independent builds to proceed concurrently. What is the best approach?

A workflow generates build artifacts used in later jobs and must retain them for 30 days for audit. Occasionally the workflow is canceled mid-run, and you still need partial logs/artifacts for troubleshooting without exposing secrets. Which design is most effective?

You need to implement a secure CI/CD pipeline that deploys to Azure using federated identity (OIDC) without long-lived secrets. The pipeline must support dev/test/prod with different subscriptions and enforce least privilege. What is the best architecture?

A deployment workflow builds a container image and pushes to Azure Container Registry (ACR), then updates an AKS deployment. You observe that occasionally an older image gets deployed even though a newer commit triggered the run. You need deterministic deployments and traceability between Git commit, image, and release. What change best fixes the issue?