20 tough GH-200 GitHub Actions Exam Questions

GH-200 GitHub Actions Certification Exam Simulator

Over the past few months I have been helping professionals who were displaced by the AI revolution move into new and exciting roles in tech. A key part of that transition is strengthening the resume, and the certification I want my clients to prioritize is the GH-200 GitHub Actions certification.

Whether you are a Scrum Master, Business Analyst, DevOps engineer, or senior software developer, the GH-200 GitHub Actions exam is my first recommendation.

Modern teams live and breathe automation. If you cannot design reliable workflows, manage secrets safely, and ship with repeatable pipelines, your impact will be limited.

GitHub Actions & Copilot exam simulators

The GitHub Actions exam validates real proficiency in workflow syntax, runners, permissions, caching, artifacts, environments, reusable workflows, and secure CI and CD practices.

Through my Udemy courses on Git, GitHub, and GitHub Actions, and through the free practice question banks at certificationexams.pro, I have seen which topics challenge learners the most. Based on thousands of student interactions and performance data, these are 20 of the toughest GH-200 GitHub Actions certification exam questions in the practice pool.

GH-200 GitHub Actions Certification Course on Udemy

You can find more practice questions in my GitHub Actions Udemy course. Each question is thoroughly answered at the end of the set, so take your time, think like a release engineer, and check your reasoning when you are done.

If you are preparing for the GH-200 GitHub Actions exam or exploring other certifications from AWS, GCP, or Azure, you will find hundreds of additional practice exams and explanations at certificationexams.pro.

These are not GitHub exam dumps or braindumps. Every question is original and designed to teach both the coverage of the exam and the strategy to answer scenario based questions. Each answer includes a tip and guidance to reinforce the concept.

Now let us dive into the 20 toughest GH-200 GitHub Actions certification exam questions. Good luck, and remember, strong careers in modern software begin with mastering automation.

Question 1

Ravi is reviewing a failed GitHub Actions run in the Actions tab and he wants to open the YAML that defines the workflow used by that run directly from the run page. Which option in the failed run’s menu should he choose to view the workflow file quickly?

• A. Download log archive
• B. Create status badge
• C. View workflow file
• D. View raw logs

Question 2

An engineering team at mcnz.com operates a self hosted GitHub Actions runner inside a restricted VPC where all outbound internet access must go through an HTTP proxy. Which environment variable should you set on the runner so it can successfully connect to GitHub?

• A. NO_PROXY
• B. HTTP_PROXY
• C. https_proxy
• D. network_proxy

Question 3

In GitHub Actions, which trigger configuration runs a workflow only when a release is published and not for drafts, edits, creation, or prereleases?

• A. on: release
• B. on: release: types: [published]
• C. on: release: types: [created]

Question 4

Northwind Apps created a reusable GitHub Action and wants it to appear on GitHub Marketplace so other teams can adopt it right away without manual review. Which prerequisites must be satisfied for the listing to go live immediately? (Choose 5)

• A. The name in the action metadata must be unique across GitHub Marketplace
• B. You must enable Cloud Build in your Google Cloud project before publishing
• C. The action’s metadata file named action.yml is located at the root of the repository
• D. The repository that hosts the action is public
• E. The listing name cannot match any existing GitHub Marketplace category
• F. You have accepted the terms of service for publishing actions in GitHub Marketplace

Question 5

Your team maintains a GitHub Actions workflow named “release-flow” that runs when a push event occurs. It contains a job named “prod-deploy” that uses the condition github.repository == ‘orion-tech/web-prod’. The job includes steps that check out the code, set up Node.js version 18, and install the bats package globally using npm. If this workflow is triggered by a push to the orion-tech/web-staging repository, what will be true about the prod-deploy job?

• A. Cloud Build will run the deployment instead
• B. The prod-deploy job will execute all three configured steps
• C. The prod-deploy job will be marked as skipped
• D. The prod-deploy job will fail with a configuration error

Question 6

Which two system generated steps are automatically included in every GitHub Actions job even if they are not specified in the workflow?

• A. Set up job and Tear down job
• B. Set up job step and Complete job step
• C. Checkout and Post job cleanup
• D. Authenticate with GitHub App and Restore cache

Question 7

A DevOps team at Nova Retail adopts GitHub Actions to speed up dependency installation using the cache action. During a workflow run the specified cache key is not found. What will the cache action do in this situation?

• A. The action stops the workflow when the cache is missing
• B. The action searches other repositories to find a compatible cache
• C. The action saves a new cache at the end of the job if the run finishes successfully
• D. The action requires a maintainer to manually create or upload a cache before continuing

Question 8

At Brightpath Labs you received a production credential used by the billing service, so you added it as a secret in the repository that hosts that service. Teams deploying from two other repositories report that their GitHub Actions workflows cannot read this secret during deployment. You want those repositories to use the same secret while keeping centralized control. What should you do?

• A. Store the credential in Google Secret Manager and have each workflow fetch it at runtime
• B. Make the existing repository secret visible to everyone in the organization
• C. Create an organization Actions secret and allow only the required repositories to use it
• D. Encode the value with Base64 and store it in the repo so other teams can copy it

Question 9

In GitHub Actions, what advantage does a JavaScript action offer that leads to faster startup and simpler use across Ubuntu, macOS, and Windows runners?

• A. Docker container actions ensure a consistent environment across operating systems
• B. JavaScript actions run directly on the runner so they start faster and are simpler
• C. Composite actions

Question 10

Your DevOps team at scrumtuous.com is refining a GitHub Actions workflow and wants to avoid a build step running forever. When you set the “timeout-minutes” field on that step, what exactly does this configuration control?

• A. It defines the upper limit for the entire job duration
• B. It enforces a per command time limit within the step and fails the step if any single command exceeds it
• C. It sets how long the workflow waits for an external trigger such as a webhook or approval before continuing
• D. It caps the total runtime of the step as a whole and cancels it once that duration is reached

The full set of exam questions can be found on GitHub Actions Udemy course or certificationexams.pro

Question 11

Priya oversees GitHub Actions settings for Asteria Robotics and wants a single variable to be shared across several workflows. She can define it at the organization level, the repository level, and the environment level. If the same variable name exists at all three levels, which value will the workflow use when it runs in that environment?

• A. Organization level variable takes precedence
• B. The environment level variable overrides the others
• C. Repository level variable takes precedence
• D. Values are merged with no single winner

Question 12

How can you define a temporary environment variable and update PATH within a single GitHub Actions step so the changes affect only that step?

• A. GitHub Codespaces
• B. Use :: workflow commands in the step’s run to update env and PATH for that step
• C. Set the environment key at the job level in the workflow

Question 13

Solstice Insights created a custom Docker container action for a GitHub Actions workflow that deploys resources to Google Cloud. A run failed because the workflow may not have passed expected environment variables such as “GOOGLE_PROJECT” and you want to see what variables are present inside the container at runtime. What should you do?

• A. Review the env section in the action.yml to verify the variables defined for the action
• B. Run docker inspect on the job container to view the environment configuration reported by Docker
• C. Run the env command from the container entrypoint to print all environment variables available at runtime
• D. Use Secret Manager to list the secret values and map them to the container environment

Question 14

Orion Metrics has a team of 25 engineers who maintain CI pipelines with GitHub Actions and they are considering whether to define workflows in YAML or in JSON. Which statement accurately describes a syntactic behavior of YAML that differs from JSON for these workflow files?

• A. YAML requires every scalar string to be enclosed in quotation marks
• B. YAML disallows comments in workflow definitions
• C. YAML uses indentation and line breaks to represent structure while JSON defines structure with delimiters
• D. YAML permits literal tab characters for indentation

Question 15

What makes maintaining an IP allowlist difficult when using GitHub hosted runners for CI?

• A. GitHub does not publish any Actions runner IP ranges
• B. An enterprise proxy would make runner IPs static and remove the need to update the allowlist
• C. The allowlist must be updated often because GitHub hosted runner IP ranges are large and change frequently

Question 16

BlueHarbor Studios hosts a private repository on GitHub that uses GitHub Actions to build its service, and a tester needs to download the artifacts from a recent successful workflow run for audit review. What is the minimum repository permission the tester must have to retrieve those workflow artifacts?

• A. Write access
• B. Maintain access
• C. Read access
• D. Admin access

Question 17

An engineer at scrumtuous.com is writing a GitHub Actions workflow and needs to reference the built in authentication token as a secret within a job step. Which expression should be used to access this token from the secrets context?

• A. ${{ github.token }}
• B. ${{ secrets.GITHUB_TOKEN }}
• C. ${{ env.GITHUB_TOKEN }}
• D. ${{ GITHUB_TOKEN }}

Question 18

Which file names does GitHub Actions recognize for the metadata file of a composite action that defines its inputs, outputs, and how it runs? (Choose 2)

• A. actions.yaml
• B. action.yml
• C. workflow.yaml
• D. action.yaml

Question 19

Priya at Alpine Fabrics wants a GitHub Actions workflow to run for pushes to any branch and also when someone creates a branch or a tag. Which event configuration should she use in the workflow file?

• A. on: {push, create}
• B. on: [push, tag]
• C. on: [push, create]
• D. on: [push, release]

Question 20

At Riverbend Robotics your team uses GitHub Actions to roll out a service update to a staging environment. You created a repository secret named svc_token and you want the step that runs a shell script to expose this secret as an environment variable named DEPLOY_TOKEN. What is the correct workflow syntax to reference the secret as that environment variable?

• A. steps: – shell: bash with: DEPLOY_TOKEN: ${{ secrets.svc_token }} run: ./deploy_app.sh
• B. Use Secret Manager with workload identity federation to fetch svc_token at runtime instead of referencing a repository secret directly
• C. steps: – shell: bash env: DEPLOY_TOKEN: ${{ secrets.svc_token }} run: ./deploy_app.sh
• D. steps: – shell: bash env: DEPLOY_TOKEN: ${{ vars.svc_token }} run: ./deploy_app.sh

Check out my other GitHub certification courses on Udemy!

GitHub Actions certification exam answers

Here’s a thorough set of answers for the questions on the GitHub Actions exam.

Pay attention to the exam tips. They’ll help guide you when you’re not quite sure how to tackle an exam question.

Question 1

Ravi is reviewing a failed GitHub Actions run in the Actions tab and he wants to open the YAML that defines the workflow used by that run directly from the run page. Which option in the failed run’s menu should he choose to view the workflow file quickly?

• [*] C. View workflow file

The correct option is View workflow file because it lets Ravi open the workflow YAML that defined the run directly from the run page.

Choosing this option opens the workflow file in the repository at the commit used for that run so he can quickly inspect its triggers and steps and any changes that may have caused the failure.

The Download log archive option only packages and downloads the run logs for offline review and it does not open the workflow definition.

The Create status badge option helps generate a badge for README display and it does not show the workflow YAML.

The View raw logs option shows the text logs from the run and it does not display the workflow file.

Exam Tip

Match the action you need with the exact UI wording. If you must open the YAML then choose the option that says workflow file and avoid options that mention logs or badges.

Question 2

An engineering team at mcnz.com operates a self hosted GitHub Actions runner inside a restricted VPC where all outbound internet access must go through an HTTP proxy. Which environment variable should you set on the runner so it can successfully connect to GitHub?

• [*] C. https_proxy

The correct option is https_proxy.

GitHub Actions runners establish outbound connections to GitHub over HTTPS and the runner reads the lowercase proxy environment variables for its network configuration. Setting this variable directs all HTTPS requests through your HTTP proxy so registration and job dispatch can succeed in a restricted VPC.

NO_PROXY defines hosts that should bypass a proxy and it does not tell the runner which proxy to use, so it will not enable connectivity by itself.

HTTP_PROXY applies to plain HTTP traffic and the runner connects to GitHub using HTTPS. The runner also expects the lowercase names for proxy variables, so this one is not used.

network_proxy is not a standard proxy environment variable recognized by the runner or common networking libraries, so it will be ignored.

Exam Tip

Match the proxy variable to the traffic protocol and watch the case. If the connection is HTTPS then choose https_proxy and remember that many tools only honor the lowercase names.

Question 3

In GitHub Actions, which trigger configuration runs a workflow only when a release is published and not for drafts, edits, creation, or prereleases?

• [*] B. on: release: types: [published]

The correct option is on: release: types: [published] because it runs only when a release is published and it does not run for drafts, edits, creation, or prereleases.

Specifying the published activity type on the release event narrows the trigger to the publish action only. This matches the requirement to run the workflow after the release is finalized and it avoids earlier lifecycle events.

The option on: release is too broad because without an activity filter it triggers on many release actions including creation, edits, prereleases, and publication. That means it would also run when drafts are created or edited.

The option on: release: types: [created] triggers when a release is first created which can be a draft and it does not run when the release is later published so it does not meet the requirement.

Exam Tip

Map the requirement to an event type on the release trigger. Use published for only after the release goes live and remember that created can include drafts.

Question 4

Northwind Apps created a reusable GitHub Action and wants it to appear on GitHub Marketplace so other teams can adopt it right away without manual review. Which prerequisites must be satisfied for the listing to go live immediately? (Choose 5)

• [*] A. The name in the action metadata must be unique across GitHub Marketplace
• [*] C. The action’s metadata file named action.yml is located at the root of the repository
• [*] D. The repository that hosts the action is public
• [*] E. The listing name cannot match any existing GitHub Marketplace category
• [*] F. You have accepted the terms of service for publishing actions in GitHub Marketplace

The correct options are The name in the action metadata must be unique across GitHub Marketplace, The action’s metadata file named action.yml is located at the root of the repository, The repository that hosts the action is public, The listing name cannot match any existing GitHub Marketplace category, and You have accepted the terms of service for publishing actions in GitHub Marketplace.

GitHub uses the information in an action’s metadata to create its Marketplace listing and to prevent conflicts. This is why the name in the action metadata must be unique and why the listing name cannot match any existing GitHub Marketplace category. When naming requirements are satisfied the automated Marketplace checks can pass and the action can go live without manual review.

Automatic validation also confirms the repository structure and visibility. The action’s metadata file named action.yml is located at the root of the repository so GitHub can detect and parse it correctly, and The repository that hosts the action is public so the listing can be discovered and used by the community. These requirements enable immediate publication once all checks succeed.

Marketplace publication also requires agreement to the platform terms, so You have accepted the terms of service for publishing actions in GitHub Marketplace must be completed. After acceptance the listing can publish right away when the other conditions are met.

You must enable Cloud Build in your Google Cloud project before publishing is incorrect because it is unrelated to GitHub Actions and GitHub Marketplace and plays no role in listing an action.

Exam Tip

When a question asks about listings that go live immediately, focus on requirements that GitHub can verify with automated validations such as metadata location, unique naming, repository visibility, and acceptance of terms. Treat any mention of third party cloud services as likely unrelated distractors.

Question 5

Your team maintains a GitHub Actions workflow named “release-flow” that runs when a push event occurs. It contains a job named “prod-deploy” that uses the condition github.repository == ‘orion-tech/web-prod’. The job includes steps that check out the code, set up Node.js version 18, and install the bats package globally using npm. If this workflow is triggered by a push to the orion-tech/web-staging repository, what will be true about the prod-deploy job?

• [*] C. The prod-deploy job will be marked as skipped

The correct option is The prod-deploy job will be marked as skipped.

The job uses an if condition that checks whether the github.repository context equals orion-tech/web-prod. A push from orion-tech/web-staging makes that expression evaluate to false. GitHub Actions evaluates job level conditions before any steps run. When the condition is false the job is skipped and no steps are executed.

This results in a Skipped status for the job in the workflow run summary. The checkout step, the Node.js 18 setup, and the npm installation of the bats package would not run because the job never starts.

Cloud Build will run the deployment instead is incorrect because this workflow runs on GitHub Actions and there is no automatic handoff to Google Cloud Build.

The prod-deploy job will execute all three configured steps is incorrect because a false job condition prevents the job from starting and therefore no steps run.

The prod-deploy job will fail with a configuration error is incorrect because the configuration is valid and the false condition results in a clean skip rather than a failure.

Exam Tip

Identify whether a job level if condition evaluates to true for the triggering context. If it is false then the job will be skipped and none of its steps will run.

Question 6

Which two system generated steps are automatically included in every GitHub Actions job even if they are not specified in the workflow?

• [*] B. Set up job step and Complete job step

The correct option is Set up job step and Complete job step.

The Set up job step is added automatically at the beginning of every job and prepares the runner and environment so the rest of the steps can execute. The Complete job step is added automatically at the end of every job and finalizes the run and closes out the job so it consistently appears even when you do not define it in your workflow.

Set up job and Tear down job is incorrect because the ending step is not named Tear down job. The system generated ending step is called Complete job step and Tear down job is not a GitHub Actions step name.

Checkout and Post job cleanup is incorrect because checkout is an optional action that runs only if you configure it and Post job cleanup is not guaranteed for every job since it depends on actions that register post steps or on the runner environment, so these are not the two universal steps.

Authenticate with GitHub App and Restore cache is incorrect because neither is automatic for every job. Authentication with a GitHub App only occurs when you configure that method and cache restore happens only when you use the caching action and set it up in the workflow.

Exam Tip

When deciding which steps are universal, think about what appears at the very beginning and end of every job. Steps that are reusable actions like checkout or cache usually require configuration and are not system generated so focus on the steps that bracket every job.

Question 7

A DevOps team at Nova Retail adopts GitHub Actions to speed up dependency installation using the cache action. During a workflow run the specified cache key is not found. What will the cache action do in this situation?

• [*] C. The action saves a new cache at the end of the job if the run finishes successfully

The correct option is The action saves a new cache at the end of the job if the run finishes successfully.

This is how the cache action works when there is a miss in GitHub Actions. If no cache entry matches the key then the step proceeds without restored files. After the job completes successfully it saves a new cache at the end of the job if the run finishes successfully so future runs with the same key can restore it.

The action stops the workflow when the cache is missing is incorrect. A cache miss does not fail the step and the workflow continues normally.

The action searches other repositories to find a compatible cache is incorrect. Caches are scoped to the repository and runner environment and the action restores only from that scope or using restore keys within the same scope.

The action requires a maintainer to manually create or upload a cache before continuing is incorrect. The action manages cache creation automatically after a successful job and no manual upload is required.

Exam Tip

When you read about a cache miss think continue now and create later. The job keeps running and a cache is written in the post step only if the job succeeds.

Question 8

At Brightpath Labs you received a production credential used by the billing service, so you added it as a secret in the repository that hosts that service. Teams deploying from two other repositories report that their GitHub Actions workflows cannot read this secret during deployment. You want those repositories to use the same secret while keeping centralized control. What should you do?

• [*] C. Create an organization Actions secret and allow only the required repositories to use it

The correct option is Create an organization Actions secret and allow only the required repositories to use it. This lets you reuse the production credential across multiple repositories while keeping centralized control and limiting access to only the teams that need it.

An organization Actions secret is defined at the organization level and can be granted to selected repositories. Workflows in those repositories can reference the secret just like a repository secret which enables a single source of truth for the credential and simplifies rotation and auditing.

Repository secrets are isolated per repository by design. Moving the credential to an organization Actions secret is the supported way to share it with only the necessary repositories while following least privilege.

Store the credential in Google Secret Manager and have each workflow fetch it at runtime is not the best choice here because it shifts secret management outside GitHub and introduces extra access configuration and bootstrap credentials. The question is solved cleanly with a native GitHub capability that provides controlled sharing.

Make the existing repository secret visible to everyone in the organization is not possible with GitHub repository secrets and it would violate least privilege by exposing a production credential to all repositories.

Encode the value with Base64 and store it in the repo so other teams can copy it is insecure because Base64 is not encryption and committing secrets to a repository exposes them to unauthorized access and history retention.

Exam Tip

When multiple repositories must use the same secret in GitHub Actions, look for the highest scope that still supports selected repositories. Organization secrets provide centralized control and follow least privilege so prefer them over repo secrets or ad hoc workarounds.

Question 9

In GitHub Actions, what advantage does a JavaScript action offer that leads to faster startup and simpler use across Ubuntu, macOS, and Windows runners?

• [*] B. JavaScript actions run directly on the runner so they start faster and are simpler

The correct option is JavaScript actions run directly on the runner so they start faster and are simpler.

JavaScript actions execute on the host runner on Ubuntu, macOS, and Windows without starting a container. This avoids image build and pull time and uses the runner’s preinstalled Node runtime, which gives faster startup and keeps setup simple across operating systems.

Docker container actions ensure a consistent environment across operating systems is incorrect because containerized actions only run on Linux runners in GitHub hosted environments and they add the overhead of building or pulling an image, which slows startup rather than speeding it up.

Composite actions is incorrect because these are a way to reuse multiple workflow steps and they rely on tools already present on the runner, which does not inherently make them start faster and they do not provide the same cross platform simplicity as a single JavaScript action.

Exam Tip

When a question emphasizes fast startup and cross platform behavior across Ubuntu, macOS, and Windows, prefer a JavaScript action. If the question stresses environment consistency over speed, think of container actions, and if it stresses step reuse think of composite actions.

Question 10

Your DevOps team at scrumtuous.com is refining a GitHub Actions workflow and wants to avoid a build step running forever. When you set the “timeout-minutes” field on that step, what exactly does this configuration control?

• [*] B. It enforces a per command time limit within the step and fails the step if any single command exceeds it

The correct option is It enforces a per command time limit within the step and fails the step if any single command exceeds it. This means the configured timeout is applied to each command that runs inside the step and if any one command runs longer than the limit the step fails and the workflow proceeds according to its failure behavior.

This setting is useful when you want to prevent a single long running command from blocking the pipeline. It provides granular protection at the command level rather than only at the step or job level and it ensures the step fails quickly when an individual command exceeds the threshold.

It defines the upper limit for the entire job duration is incorrect because that describes a job level timeout which applies to the whole job and not to individual commands within a single step.

It sets how long the workflow waits for an external trigger such as a webhook or approval before continuing is incorrect because timeouts do not control waiting for external events or manual approvals and those are governed by different workflow mechanisms.

It caps the total runtime of the step as a whole and cancels it once that duration is reached is incorrect because this would end the entire step after the specified time whereas the setting in question focuses on each command within the step and fails the step if any single command exceeds the limit.

Exam Tip

Read the exact scope of the setting and map it to the correct level such as job, step, or workflow. When options sound similar look for words that indicate granularity like per command versus whole step or entire job.

Question 11

Priya oversees GitHub Actions settings for Asteria Robotics and wants a single variable to be shared across several workflows. She can define it at the organization level, the repository level, and the environment level. If the same variable name exists at all three levels, which value will the workflow use when it runs in that environment?

• [*] B. The environment level variable overrides the others

The correct option is The environment level variable overrides the others.

This scope has the highest precedence in GitHub Actions variable resolution. When the same variable name is defined at all three scopes, the workflow uses the value from this scope and ignores the repository and organization values.

Organization level variable takes precedence is incorrect because organization scoped values are overridden by repository and by the environment scope when the same name exists.

Repository level variable takes precedence is incorrect because a repository scoped value is still overridden by the environment scope when the same name exists.

Values are merged with no single winner is incorrect because GitHub Actions uses precedence rather than merging conflicting variable values.

Exam Tip

When variables or secrets exist at multiple scopes, remember that the environment scope has the highest precedence and overrides repository and organization values.

Question 12

How can you define a temporary environment variable and update PATH within a single GitHub Actions step so the changes affect only that step?

• [*] B. Use :: workflow commands in the step’s run to update env and PATH for that step

The correct option is Use :: workflow commands in the step’s run to update env and PATH for that step.

Within the run section you can write to the environment files named GITHUB_ENV and GITHUB_PATH so the variable and PATH update are available to the commands in that step. You can echo a name value pair into GITHUB_ENV to create a temporary variable and you can echo a directory into GITHUB_PATH to place it on PATH for that step. The legacy set env and add path forms that used the double colon syntax are deprecated so you should use the environment files approach.

GitHub Codespaces is a cloud development environment and it does not control environment variables or PATH inside a GitHub Actions step.

Set the environment key at the job level in the workflow applies the changes to every step in the job and it does not limit them to a single step.

Exam Tip

Focus on scope. If the question says only that step then prefer step run changes such as environment files or exports and avoid job level env which affects all steps.

Question 13

Solstice Insights created a custom Docker container action for a GitHub Actions workflow that deploys resources to Google Cloud. A run failed because the workflow may not have passed expected environment variables such as “GOOGLE_PROJECT” and you want to see what variables are present inside the container at runtime. What should you do?

• [*] C. Run the env command from the container entrypoint to print all environment variables available at runtime

The correct option is Run the env command from the container entrypoint to print all environment variables available at runtime.

For a Docker container action the entrypoint runs inside the container which means printing the environment there shows the exact variables the action can use. This approach reveals values provided by the workflow environment and default GitHub variables and any secrets that were mapped. It is the most direct way to verify whether GOOGLE_PROJECT and related variables are actually available when the action runs.

Review the env section in the action.yml to verify the variables defined for the action is incorrect because the metadata only describes defaults or expected inputs and it does not guarantee what the workflow passed at run time. Variables can be added or overridden in the workflow file or by the runner so you must check from inside the container.

Run docker inspect on the job container to view the environment configuration reported by Docker is incorrect because in GitHub Actions you do not manage the container directly and inspecting it from the host is not practical during a run. Even if you could inspect it you still might miss variables that are set or transformed by the entrypoint or shell at run time. Verifying from inside the container is authoritative.

Use Secret Manager to list the secret values and map them to the container environment is incorrect because listing secret values is not appropriate and does not reflect what the workflow actually exported. GitHub Actions injects secrets only when referenced and you should never print or enumerate secret values to debug environment presence.

Exam Tip

When debugging container actions think from inside the container. Add temporary commands in the entrypoint to print the environment rather than relying on static configuration files.

Question 14

Orion Metrics has a team of 25 engineers who maintain CI pipelines with GitHub Actions and they are considering whether to define workflows in YAML or in JSON. Which statement accurately describes a syntactic behavior of YAML that differs from JSON for these workflow files?

• [*] C. YAML uses indentation and line breaks to represent structure while JSON defines structure with delimiters

The correct option is YAML uses indentation and line breaks to represent structure while JSON defines structure with delimiters.

This statement is accurate because YAML relies on significant whitespace. Indentation and new lines convey nesting and list structure, so the layout of the file directly represents the data. JSON represents structure with explicit delimiters. It uses braces and brackets to define objects and arrays and it separates elements with commas and uses colons between keys and values.

YAML requires every scalar string to be enclosed in quotation marks is incorrect because YAML allows unquoted scalars in many cases. Quotes are only needed when the content would otherwise be ambiguous, such as when it contains special characters or leading and trailing spaces.

YAML disallows comments in workflow definitions is incorrect because YAML supports comments that start with a hash and workflow files can include them for readability.

YAML permits literal tab characters for indentation is incorrect because the YAML specification forbids tabs for indentation and requires spaces, and many parsers will error when tabs are used.

Exam Tip

When options compare formats, focus on what the specification enforces. YAML is whitespace significant while JSON is delimiter based. Be skeptical of absolute words like requires or disallows and verify rules about tabs and comments since these are common traps.

Question 15

What makes maintaining an IP allowlist difficult when using GitHub hosted runners for CI?

• [*] C. The allowlist must be updated often because GitHub hosted runner IP ranges are large and change frequently

The correct option is The allowlist must be updated often because GitHub hosted runner IP ranges are large and change frequently.

GitHub hosted runners are ephemeral and run across a large pool of infrastructure that uses many IP address ranges that are updated regularly. If you rely on an IP allowlist then you must keep adding and removing ranges as GitHub publishes changes which creates ongoing operational work and risk if the list is not kept current.

The statement GitHub does not publish any Actions runner IP ranges is incorrect because GitHub publishes the current IP ranges for Actions through the Meta API and in documentation, and you can retrieve them programmatically even though they still change over time.

The statement An enterprise proxy would make runner IPs static and remove the need to update the allowlist is incorrect because GitHub hosted jobs egress from GitHub’s infrastructure and your enterprise proxy cannot make those source addresses static. You would need self hosted runners or another architecture under your control if you require truly static egress.

Exam Tip

When a question references GitHub hosted runners and allowlists, look for words like ephemeral, dynamic, and large ranges. The best choice often emphasizes the need for frequent updates.

Cameron McKenzie is an AWS Certified AI Practitioner, Machine Learning Engineer, Solutions Architect and author of many popular books in the software development and Cloud Computing space. His growing YouTube channel training devs in Java, Spring, AI and ML has well over 30,000 subscribers.