GitHub Actions for ML Pipelines Quiz

Answers and explanations appear as you take the quiz.

1. What does a GitHub Actions workflow define?
   • Triggers, jobs, runners and steps
   • A container image manifest and layer list
   • Branch protection rules for a repository
   • The model dependency lockfile alone
2. Why separate fast pull-request checks from full GPU training?
   • It guarantees model quality without evaluation
   • It keeps feedback quick while reserving specialized compute for expensive work
   • It removes all runner maintenance
   • It makes GPU hardware available on every runner
3. What should connect an evaluation report to the artifact promoted later?
   • The author’s username alone
   • The workflow display name only
   • The artifact digest or another immutable identity
   • A cache key that changes each run
4. Why avoid exposing repository secrets to untrusted pull-request code?
   • Actions cannot run without write tokens
   • Secrets are required to run Python imports
   • It makes all validation nondeterministic
   • Workflow code could use them to access external systems
5. What can OIDC provide when configured with a cloud provider?
   • A permanent model accuracy certificate
   • Short-lived credentials tied to workflow identity
   • An artifact cache without access control
   • A Python virtual environment
6. How should a dependency cache be used in an Actions workflow?
   • Keep a deployable model file between workflow runs as the official release record
   • Reuse dependencies with a key that ignores dependency input changes
   • Speed up repeated dependency setup with keys based on dependency inputs
   • Use a mutable image tag as the only record of workflow output
7. What does an environment protection rule add to a model release job?
   • A lockfile for training data
   • An automatic guarantee that metrics are unbiased
   • A new GPU device
   • A controlled approval or deployment condition
8. What does GitHub Actions alone not guarantee?
   • That training data, evaluation or release decisions are sound
   • That defined workflow steps execute on a runner
   • That jobs can depend on prior jobs
   • That artifacts can be uploaded