[NEW] GitHub Actions

Detailed Exam Domain CoverageThe official GitHub Actions certification exam evaluates practical knowledge across four primary functional domains. This question bank reflects those exact weightings and core technical focus areas:Author and maintain workflows (40%)Triggers Events: Configuring automated executions via event filters (push, pull_request, types, paths), time-based schedules (cron syntax), manual triggers (workflow_dispatch, workflow_call), and incoming webhooks.Workflow Architecture: Designing jobs, steps, dependencies (needs), conditional execution logic (if statements), context expressions, and runner environments.Variables Secrets: Managing configuration data via environment variables, organization/repository secrets, and scoping security inheritance with the automated GITHUB_TOKEN.Advanced Topologies: Designing purpose-built configurations for matrix builds, containerized packages, service containers (databases/caches), automated CodeQL security scanning, targeted custom runners, and multi-environment cloud deployments.Consume workflows (20%)Log Analysis: Accessing, searching, and interpreting real-time step execution logs, diagnostic debugging output, and job execution states.GitHub REST/GraphQL API: Programmatically querying workflow histories, downloading run artifacts, triggering remote dispatches, and parsing active runner metrics.Troubleshooting: Identifying root causes for failed dependencies, syntax errors, timeouts, and structural breaks inside dependency graphs.Artifact Retention: Generating, storing, downloading, and mapping output files across completely distinct, un-linked workflow runs.Author and maintain actions (25%)Custom Tooling: Developing bespoke automation using JavaScript actions, custom Docker container environments, and composite sequence definitions driven by custom action.yml metadata structures.Security Versioning: Enforcing reliable build practices by pinning execution dependencies to specific git tags, unique SHA-1 commit hashes, or semantic version branches.Lifecycle Management: Updating local actions to track upstream API changes, deprecating outdated node runtimes, and managing long-term codebase maintenance.Distribution Models: Sharing reusable, production-ready modules across enterprise network boundaries via internal registry access configurations.Manage GitHub Actions for the enterprise (15%)Governance Compliance: Implementing organizational policies that strictly restrict outside marketplace integrations and dictate allowed third-party templates.Infrastructure Scaling: Provisioning, maintaining, and scaling standard GitHub-hosted execution nodes versus self-hosted private runner pools.Network Security: Isolating execution workloads using runner groups, network security perimeters, customized labels, proxy controls, and IP allow lists.Secret Management: Designing secure storage hierarchies using encrypted organizational variables and fine-grained repository access control lists.Course DescriptionClearing the official GitHub Actions certification requires more than just a surface-level familiarity with YAML syntax. The actual exam presents complex, situational troubleshooting scenarios where multiple options look visually identical but fail due to minor architectural misconfigurations, permission scopes, or security violations.I designed this practice test repository to bridge the gap between reading standard documentation and facing real-world certification constraints. Instead of superficial trivia, these questions challenge your structural understanding of continuous integration and delivery pipelines within the GitHub ecosystem. Every scenario mimics the structural framing, vocabulary, and difficulty level of the live assessment.Each practice test covers complex enterprise governance problems, deep log debugging, matrix-build optimizations, and custom action development. If you understand why an option fails and how the correct engine processes the workflow file, you will be fully prepared to pass the test on your first attempt.Sample Practice QuestionsQuestion 1: Workflow Security ScopingA DevOps engineer needs to configure a workflow that builds a production Docker image and pushes it to the GitHub Packages container registry (ghcr. io). To comply with the principle of least privilege, the default repository wide GITHUB_TOKEN permissions must be restricted globally to read-only, but elevated explicitly for the specific job handling the registry upload.Which YAML configuration correctly implements this access control policy?A) Set permissions: read-all at the workflow root, and permissions: packages: write at the specific job level.B) Set permissions: {} at the workflow root, and inside the job configuration block define permissions: packages: write and contents: read.C) Set permissions: read at the workflow root, and inside the job configuration block define permissions: packages: write.D) Leave the root permissions empty, and define permissions: write-all strictly inside the upload job block.E) Set permissions: contents: read at the workflow root, and permissions: write inside the upload job block.F) Set permissions: secure at the workflow root, and permissions: packages: upload at the specific job level.Detailed Explanations:Correct Answer: BWhy it is correct: When you define a permissions block anywhere in a workflow, any permission scopes not explicitly named inside that specific block are automatically set to none. Specifying permissions: {} at the root strips all default access keys. Then, inside the specific job block, explicitly declaring packages: write allows container publication, while contents: read preserves the necessary permission to checkout and read the repository code. This satisfies the strict least-privilege target.Incorrect Options:Why A is incorrect: Setting permissions: read-all at the root is a valid global block. However, when you define a new permissions block at the job level, it completely overwrites the root settings for that job rather than extending them. Because the job block only specified packages: write, the implicit contents permission drops to none, causing the actions/checkout step to fail because it cannot read the code.Why C is incorrect: The key-value pairing permissions: read is invalid syntax. Permissions must be configured using explicit top-level shorthand like read-all / write-all, or assigned via explicit key-value mappings targeting specific permission scopes (e.g., contents: read).Why D is incorrect: Leaving the root permissions empty causes the workflow to default to your standard repository or organizational token default policies (which frequently default to broad read/write access). This violates the core prompt requirement to enforce a global read-only policy at the workflow file level.Why E is incorrect: Declaring permissions: write inside the job block is invalid syntax. The Actions framework requires you to target specific individual metadata scopes (like packages, issues, or deployments) when assigning specific read or write values.Why F is incorrect: Neither secure nor packages: upload are valid tokens or scopes within the GitHub Actions runner execution schema. Using them will trigger a structural schema validation error before execution starts.Question 2: Custom Action Architecture Runner ConstraintsAn enterprise infrastructure team manages a pool of self-hosted runners operating exclusively on Windows Server instances. A development team wants to write a custom, reusable automated utility action to deploy internally across multiple repositories. The utility must execute quickly without introducing external dependencies onto the underlying runner host during execution.Which action type should be developed to satisfy these environmental and performance requirements?A) A custom Docker container action using a lightweight Alpine Linux base image.B) A custom JavaScript action targeted to run natively via the built-in Node.js execution engine.C) A custom Composite action that calls a sequence of PowerShell Core wrapper scripts.D) A custom Docker container action running a native Windows Server Core base image.E) A custom Bash shell script wrapped inside a Linux-native composite action.F) A custom Ansible playbook action executed via an automated marketplace runner extension.Detailed Explanations:Correct Answer: BWhy it is correct: JavaScript actions run directly inside a packaged Node.js environment supplied natively by the standard GitHub Actions runner agent application. They run out-of-the-box across Windows, macOS, and Linux systems without requiring any pre-installed host platform runtimes, container runtimes, or hypervisors, making them highly efficient and platform-independent.Incorrect Options:Why A is incorrect: Docker container actions are supported only on Linux-hosted runner environments. They cannot execute on Windows-hosted or macOS-hosted runners, meaning the execution engine will fault immediately when scheduled onto the Windows Server pool.Why C is incorrect: While composite actions utilizing PowerShell can run on Windows, composite steps execute sequential shell interpretations directly on the host machine. If the underlying scripts depend on specialized modules, libraries, or binaries, those dependencies must be pre-configured on the host system, failing the requirement to avoid adding external configuration dependencies to the runner host.Why D is incorrect: GitHub Actions does not support running Windows-based container images for custom Docker container actions; the action execution engine explicitly requires Linux-based containers.Why E is incorrect: Linux-native composite actions utilizing Bash shells will fail on Windows nodes unless a Bash emulation layer (such as Git Bash or WSL) is explicitly installed and configured on the host path, violating the strict zero-dependency constraint.Why F is incorrect: Ansible is not a native action type supported by the core GitHub runner execution engine engine (action.yml metadata only permits node*, docker, or composite). This setup would introduce a heavy dependencies footprint onto the runner environment.Question 3: Enterprise Runner Group IsolationAn organization administrator needs to restrict access to a high-performance, self-hosted runner group containing specialized licensed build software. These resources must only be accessible by specific production deployment repositories inside the organization, preventing arbitrary developer repositories from consuming the execution pool.How should this security boundary be enforced within the administrator panel?A) Configure custom runner labels on the individual machines matching the designated repository names.B) Set the runner group visibility configuration option to "Selected repositories", and explicitly check the allowed project repositories.C) Write a centralized organization-level workflow policy file that uses an if condition to validate the repository namespace.D) Create a dedicated secret named RUNNER_GROUP_KEY inside each allowed repository matching the group token.E) Change the runner group visibility option to "Private", which automatically limits access to repositories owned by organization administrators.F) Configure an IP allow list policy at the organization level to block traffic coming from non-production runners.Detailed Explanations:Correct Answer: BWhy it is correct: GitHub Enterprise and Organization layers allow administrators to manage runner groups as hard security boundaries. Setting the group visibility status explicitly to "Selected repositories" allows you to cherry-pick exactly which code repositories can send execution jobs to that runner group, completely blocking unapproved project workflows at the scheduling layer.Incorrect Options:Why A is incorrect: Runner labels are designed for matching system capabilities (e.g., operating system, GPU availability) to a job's runs-on requirement. Labels do not prevent an unauthorized repository from simply adding that exact label string into its own workflow file to hijack the runner.Why C is incorrect: Organization-level policies can restrict structural constraints (like allowed actions), but they cannot inject dynamic runtime validation wrappers into individual user workflow execution blocks across arbitrary repositories.Why D is incorrect: Runner group authentication and routing are handled entirely at the system platform level via administrative access lists. Workflows do not authenticate against runner pools using manually assigned repository secrets.Why E is incorrect: "Private" is not a valid configuration state for self-hosted runner groups. The available visibility scopes are "All repositories", "Private repositories" (meaning all internal/private repos, not admin-only), and "Selected repositories".Why F is incorrect: IP allow lists restrict network traffic to the GitHub web platform interface from user clients. They do not manage or segment internal job-routing logic between repositories and h