--- title: "GitHub Actions: Workflow Automation Essentials" description: "Master GitHub Actions fundamentals with this quiz covering Workflows, YAML syntax, the Actions Marketplace, Matrix builds, and secure secret management." author: "Mohammad Abu Mattar" canonical: https://mkabumattar.com/quizzes/post/github-actions-workflow-automation-quiz --- # GitHub Actions: Workflow Automation Essentials Welcome to the GitHub Actions Basics Quiz! This quiz covers the fundamentals of GitHub Actions, including workflows, jobs, steps, triggers, and best practices. Test your knowledge and see how well you understand this powerful automation tool. ## Questions ### 1. Where must GitHub Actions workflow files be stored in a repository? - `.github/actions/` - The .github/actions/ folder is commonly used for local custom actions, but not for workflow definitions. - **`.github/workflows/`** ✅ - GitHub only parses YAML files located in .github/workflows/ at the root of the repository as active workflows. - `.github/pipelines/` - While other CI/CD platforms use the term "pipelines," GitHub strictly requires the "workflows" directory name. - `.github/scripts/` - This directory is often used for auxiliary shell or python scripts, but not for the main YAML workflow files. **Hint:** It is a specific hidden directory. ### 2. What is a "Job" in a GitHub Actions workflow? - A single terminal command - A single terminal command is defined as a "step" or a "run" instruction within a larger job structure. - **A group of steps that execute on the same runner** ✅ - A job is a unit of work; all steps in one job share the same virtual machine and filesystem environment. - A set of rules for merging pull requests - Rules for merging are defined in "Branch Protection Rules" rather than in the workflow job definitions. - A configuration for global environment variables - Global environment variables are defined at the workflow level or in environment settings, not as a job. **Hint:** Jobs run on the same runner. ### 3. What is the purpose of the "on" keyword in a workflow YAML? - To toggle the global visibility of the workflow - Visibility is controlled via GitHub repository settings and repository permissions, not the "on" keyword. - **To define the events that trigger the workflow** ✅ - The "on" key specifies which GitHub events (like push, pull_request, or release) initiate the automation. - To specify the runner operating system version - The operating system (e.g., ubuntu-latest) is defined using the "runs-on" keyword at the job level. - To enable the debugging logs for the current run - Debugging logs are enabled via secret variables or the UI, rather than the "on" trigger definition. **Hint:** It defines the trigger. ### 4. What does "runs-on: ubuntu-latest" specify? - The browser environment for headless testing - Headless browsers are installed on the runner, but they are not defined by the "runs-on" property. - **The type of virtual machine used to host the job** ✅ - The "runs-on" key determines the operating system and architecture of the GitHub-hosted or self-hosted runner. - The minimum version of Python required for the app - Language versions are managed using specific actions like "actions/setup-python" rather than the runner OS key. - The geographic region where the build is executed - GitHub automatically allocates data center resources; regions are not manually specified in the YAML. **Hint:** The execution environment. ### 5. How do you access a secret named "API_KEY" in a workflow? - `$API_KEY` - Direct shell variable access only works if the secret has been explicitly mapped to an environment variable. - **`${{ secrets.API_KEY }}`** ✅ - The secrets context is the official way to access encrypted data stored in GitHub repository settings. - `{{ env.API_KEY }}` - The "env" context accesses standard non-encrypted variables, not those stored in the Secrets vault. - `$GITHUB_SECRETS[API_KEY]` - This syntax is invalid; GitHub Actions uses specific context objects wrapped in double curly braces. **Hint:** Use the secrets context. ### 6. What is the "Marketplace" in GitHub Actions? - A premium store for purchasing enterprise support - Enterprise support is part of GitHub billing; the Marketplace is for automation components. - **A central registry for pre-built, reusable actions** ✅ - The Marketplace allows users to discover and implement actions created by GitHub and the wider community. - A dashboard for monitoring cloud infrastructure costs - Infrastructure costs are managed through the Billing section, not the Actions Marketplace. - A collaborative forum for discussing workflow bugs - Bug discussions occur in GitHub Issues or Discussions; the Marketplace hosts technical components. **Hint:** Reusable components. ### 7. What does the "uses" keyword do in a step? - It defines a custom shell variable for the job - Custom shell variables are defined using the "env" keyword rather than "uses." - **It references a specific action to be executed** ✅ - The "uses" key tells the runner to download and run a specific action, such as "actions/checkout." - It lists the binary dependencies for the runner - Binary dependencies are installed via "run" steps (e.g., apt-get install) rather than "uses." - It declares the libraries needed for the source code - Code libraries are managed by package managers (like npm or pip), not the GitHub workflow syntax. **Hint:** It calls an Action. ### 8. What is a "Matrix Build"? - **A strategy to run jobs across multiple configurations** ✅ - A matrix allows you to test code across multiple versions of languages, OSs, or dependencies simultaneously. - A method to visualize the dependency graph of jobs - Dependency visualization is a feature of the Actions UI, while "Matrix" refers to job variations. - A security system for rotating repository SSH keys - Key rotation is a security management task, not a workflow build strategy. - A database schema for storing build execution logs - Build logs are stored in an internal GitHub storage system, not a user-defined matrix database. **Hint:** Testing across multiple versions. ### 9. How do you make a job depend on the successful completion of another job? - `after: [job_id]` - The "after" keyword is not part of the GitHub Actions YAML specification for defining dependencies. - **`needs: [job_id]`** ✅ - The "needs" keyword establishes a dependency, ensuring a job only runs if the requirement job completes successfully. - `depends_on: [job_id]` - While "depends_on" is common in Docker Compose, GitHub Actions uses the "needs" syntax for orchestration. - `require: [job_id]` - The "require" keyword is used in programming languages like Ruby or PHP, but not in GitHub Actions YAML. **Hint:** The "needs" keyword. ### 10. What is the "GITHUB_TOKEN"? - A permanent personal access token for developers - Personal Access Tokens (PATs) are manually created and permanent; GITHUB_TOKEN is automated and ephemeral. - **A temporary secret for authenticating with the API** ✅ - GitHub automatically provides a GITHUB_TOKEN for each run to allow secure interaction with the repository. - A unique identifier for the GitHub Enterprise instance - Enterprise IDs are static configuration values, not dynamic authentication tokens for workflow runs. - A recovery key used for unlocking encrypted build logs - Build logs are unlocked via user permissions, not via a specific "GITHUB_TOKEN" artifact. **Hint:** An automatic authentication secret. ### 11. What is a "Self-hosted Runner"? - A runner that executes only local shell scripts - All runners can execute shell scripts; self-hosted refers to where the infrastructure is managed. - **A user-managed machine that executes workflow jobs** ✅ - Self-hosted runners allow you to use your own infrastructure (on-prem or cloud) to run GitHub Actions jobs. - A specialized browser for testing web applications - Testing is performed by tools like Selenium or Playwright on the runner, but the runner itself is a server. - A cloud-based IDE for editing workflow YAML files - Editing is done in the browser or an IDE (like VS Code); a runner is a backend execution environment. **Hint:** Your own hardware. ### 12. What is "workflow_dispatch" used for? - To delete old workflow runs from the repository - Deletion is handled by retention policies or the "Delete run" button, not the "workflow_dispatch" key. - **To trigger a workflow manually from the GitHub UI** ✅ - The "workflow_dispatch" trigger adds a "Run workflow" button, allowing users to start a run on demand. - To route build notifications to external chat apps - Routing notifications is typically handled by Webhooks or specific integration actions. - To deploy code to multiple production environments - Deployments are usually triggered by "push" or "release" events, though dispatch can be used as well. **Hint:** Manual control. ### 13. What is the "Context" in GitHub Actions? - The visual theme applied to the Actions dashboard - Themes are user interface preferences and are not related to the technical "Context" objects. - **A set of variables providing run-time information** ✅ - Contexts (like github, env, or job) provide data about the current run, the repository, and the environment. - The sequence of steps defined within a single job - The sequence of steps is simply called the "steps list" or "job definition," not the context. - A collection of third-party plugins for YAML editing - Editing plugins are part of the IDE environment, while contexts are internal GitHub Actions data structures. **Hint:** Accessing workflow data. ### 14. What does the "step.if" condition allow you to do? - To set a maximum execution timeout for the runner - Timeouts are managed by the "timeout-minutes" property rather than the "if" conditional key. - **To execute a step only when a specific condition is met** ✅ - The "if" key uses expressions to determine whether a step should run, such as checking for specific branch names. - To prompt the user for a manual input during a build - GitHub Actions is non-interactive; "if" checks logic, it does not stop to ask for user input. - To change the job name dynamically based on an error - Job names are static; however, you can use "if" to run specific cleanup steps when a job fails. **Hint:** Conditional logic. ### 15. What is a "Reusable Workflow"? - A workflow that restarts automatically after failure - Automatic restarts are handled by retry logic or self-hosted runner settings, not reusability. - **A workflow that can be called by multiple other files** ✅ - Reusable workflows allow you to centralize logic and "call" it from different repositories to avoid duplication. - A template used only for creating new repositories - Templates for repositories are called "Template Repositories," not reusable workflows. - A script that caches dependencies between different runs - Caching is handled by "actions/cache" or specific language setup actions, not by workflow reusability. **Hint:** Avoid duplicating YAML. ### 16. What is the purpose of "actions/checkout"? - To verify the payment status of a GitHub account - This is a financial term; in CI/CD, "checkout" refers to retrieving the source code from Git. - **To copy the repository source code onto the runner** ✅ - Without the checkout action, the runner would have access to the YAML file but not the actual code to build. - To log out of the current GitHub CLI session - Logging out is a command-line operation performed via "gh auth logout" rather than a workflow action. - To delete a remote branch after a successful merge - Branch deletion is a Git management task often handled by repository settings or manual commands. **Hint:** Getting the code. ### 17. What is "Artifact Uploading" in GitHub Actions? - Storing repository images in a private registry - Storing images is the role of a Container Registry (like GHCR), not the Artifact system. - **Persisting build outputs for later use or download** ✅ - Artifacts are files (like binaries or test reports) produced by a job that you want to keep after the run. - Pushing local source code changes back to the main branch - Pushing code is a Git operation, while artifact uploading deals with files generated *during* the build. - Sending automated alerts to external monitoring tools - Sending alerts is a notification task, whereas artifacts are physical files stored by GitHub. **Hint:** Saving files between jobs or for download. ### 18. What is an "Environment" in GitHub Actions? - The specific version of the OS kernel on the runner - This is a system property of the Runner image, not the "Environment" feature. - **A deployment target with specific protection rules** ✅ - Environments represent targets like "Production" where you can enforce manual approvals and manage secrets. - The collection of all software installed on the machine - This is the "Runner Image" or "Tool cache," not a GitHub Actions Environment. - A local sandbox used for debugging YAML syntax errors - Debugging is done via linter tools or trial runs; Environments are for orchestrating deployments. **Hint:** Deployment targets with protection rules. ### 19. What is "Concurrency" control in a workflow? - A method for increasing the speed of CPU operations - CPU speed is a hardware property; concurrency control is about managing multiple workflow executions. - **A way to limit the number of parallel workflow runs** ✅ - Concurrency keys ensure that only one run of a specific group (like a deployment) happens at a time. - A tool for managing multiple concurrent user logins - User logins are managed by GitHub Authentication, not by workflow concurrency settings. - A setting that runs one job on multiple different runners - Running jobs on multiple runners is "Parallelism" or "Matrix builds," not concurrency control. **Hint:** Managing overlapping runs. ### 20. What does the "continue-on-error: true" setting do? - It ignores all security policy violations in the code - Security policies are enforced by external scanners; this setting only affects the workflow status. - **It prevents a failed step from stopping the entire job** ✅ - Setting continue-on-error allows the job to proceed even if a specific step fails, marking the job as successful. - It automatically attempts to fix the failed shell command - GitHub Actions cannot fix code or commands; it can only decide whether to continue the execution flow. - It restarts the runner automatically upon a system crash - System crashes are handled by the GitHub runner service, not by the continue-on-error YAML key. **Hint:** Keep going regardless of failure. ### 21. What is the "Action" versioning syntax (e.g., @v4)? - It defines the priority level of the build in the queue - Queue priority is managed by GitHub based on your plan, not by the action name syntax. - **It pins a workflow to a specific version of an action** ✅ - Versioning (using tags, branches, or SHAs) ensures that your workflow remains stable even if an action is updated. - It indicates the number of contributors to the action - Contributor counts are metadata on the repository page and are not used within the YAML code. - It sets the maximum number of times an action can run - There is no built-in limit on action executions based on the versioning string. **Hint:** Using specific versions. ### 22. What is "Cache" used for in Actions? - A vault for storing encrypted production passwords - Production passwords should be stored in "Secrets," not in the "Cache" system. - **A system to persist dependencies between workflow runs** ✅ - Caching stores files like node_modules to avoid re-downloading them in every run, significantly speeding up builds. - A temporary storage for the runners swap file system - Swap files are part of the runner operating system management and are not exposed as an Actions feature. - A log of all previous Git commit messages and authors - Commit logs are part of the Git repository history, not the GitHub Actions cache. **Hint:** Speeding up dependency installs. ### 23. What is a "Composite Action"? - An action that combines multiple Docker containers - Docker actions run a single container; "Composite" refers to combining multiple YAML steps. - **A custom action that groups multiple workflow steps** ✅ - Composite actions allow you to bundle multiple "run" or "uses" steps into a single reusable unit. - A workflow that runs on both Linux and Windows runners - This is a multi-platform or "Matrix" build, not a composite action. - A list of all plugins used in the current repository - GitHub Actions uses actions rather than "plugins," and a list of them is not called a "Composite." **Hint:** Combining multiple steps into one action. ### 24. What is "Workflow Call" (workflow_call)? - A notification sent to the developer when a job fails - Notifications are automated alerts, whereas workflow_call is a specific trigger for reusability. - **A trigger that allows a workflow to be reused by others** ✅ - The workflow_call trigger is required in a YAML file for it to be callable by a "caller" workflow. - A command used to cancel a running workflow from the CLI - Canceling is done via "gh run cancel" or the UI, not through a YAML trigger definition. - A documentation file that describes the workflow logic - Documentation is usually stored in README.md files, not defined by a "workflow_call" key. **Hint:** Trigger for reusable workflows. ### 25. What is the purpose of "timeout-minutes"? - To schedule a specific time for the build to start - Starting times are scheduled using "cron" syntax under the "on" trigger, not timeout-minutes. - **To automatically cancel a job that runs for too long** ✅ - This prevents a hanging process or infinite loop from consuming all of your account's build minutes. - To track the total duration of the development cycle - Duration tracking is an analytics feature provided by GitHub Insights, not a YAML setting. - To set the time zone for the runners operating system - Time zones are typically set via shell commands or environment variables on the runner. **Hint:** Safety against hanging jobs. ### 26. What is "Step Masking"? - The process of skipping steps that have failed previously - Skipping is managed by the "if" condition or "continue-on-error" key, not by masking. - **A method to prevent secrets from appearing in build logs** ✅ - Masking replaces sensitive values (like secrets) with asterisks in the console output to prevent data leaks. - A way to hide the identity of the person triggering the run - The "actor" (the person who triggered the run) is always visible in the workflow metadata. - A configuration to hide the names of the internal servers - Server names in logs are not automatically hidden unless they match a defined secret value. **Hint:** Hiding sensitive output. ### 27. What does "fail-fast" do in a Matrix build? - It ensures the build fails within a few seconds of starting - The speed of a single failure is not affected; fail-fast refers to the orchestration of multiple jobs. - **It cancels all in-progress matrix jobs if any job fails** ✅ - If one version in your matrix fails, "fail-fast" cancels the others to save your Actions minutes. - It ignores all failures and marks the matrix as successful - Ignoring failures is the role of "continue-on-error," whereas fail-fast is about cancellation. - It automatically retries the failed job three times - Automatic retries are not a core feature of the fail-fast key in matrix configurations. **Hint:** Managing multiple variations. ### 28. What is a "Starter Workflow"? - A simplified workflow designed for training new users - While helpful for beginners, "Starter Workflows" are technical templates for specific languages and tools. - **A template provided by GitHub to help set up CI/CD** ✅ - GitHub suggests these templates based on your repository’s code (e.g., Node.js, Python, or Docker templates). - A workflow that only runs when a repository is created - Workflows run on various events; there is no specific "starter" event for repo creation. - A script that installs the GitHub Actions runner service - Installing the runner is a manual or script-based server task, not a "Starter Workflow." **Hint:** GitHub templates. ### 29. What is "OIDC" (OpenID Connect) in GitHub Actions? - A specialized protocol for compressing build artifacts - Artifact compression is handled by the upload/download actions, not the OIDC protocol. - **A method to authenticate with cloud providers without secrets** ✅ - OIDC allows the runner to exchange a short-lived token for cloud access (AWS/Azure), eliminating long-lived secrets. - A programming language used for writing GitHub apps - OIDC is an authentication protocol, not a language; apps are written in JS, Go, or Python. - A tool for managing the dependencies of a JavaScript project - JavaScript dependencies are managed by npm or yarn, not by an OIDC authentication layer. **Hint:** Secure cloud authentication. ### 30. What is the "workflow_run" trigger? - To execute a workflow every time a developer commits code - Commits are captured by the "push" trigger, whereas "workflow_run" focuses on other workflows. - **To start a workflow based on another workflows status** ✅ - This trigger allows you to chain workflows, for example, running a deployment after a test workflow passes. - To clean up the temporary files on the self-hosted runner - Cleanup is usually a "post" step or an independent maintenance script, not a workflow_run trigger. - To list all currently active workflows in the repository - Active workflows are viewed via the GitHub CLI or API, not via a specific YAML trigger. **Hint:** Chaining workflows.