Week Four: Managing Actions and Packages 📦 [GitHub Administration Certification Prep Course]

[queenofcorgis]

Congratulations, you are one week away from being ready to ace the GitHub Administration Certification exam. Remember, we’ll be awarding 15 GitHub Certification exam vouchers to members who engage with us during the course, the winners of those vouchers will be announced the week of November 3rd.

Looking for our previous weeks’ to study as part of the GitHub Administration Certification exam prep course?

• Week One’s Discussion
• Week Two’s Discussion
• Week Three’s Discussion

Step One: Prep 📚

• Microsoft Learn Modules

  • Manage GitHub Actions in the enterprise
  • Leverage GitHub Actions to publish to GitHub Packages

• Further reading:

  • Managing GitHub Actions for your enterprise from GitHub Docs
  • Manage your billing, licensing, and consumption-based services from @rhoticity
  • Enterprise workflow automation at scale

• Video

  • Managing GitHub Actions Enterprise on LinkedIn

• Hands on learning

  • GitHub Skills: Publish to GitHub Packages

Step Two: Test Your Knowledge ⚡

Question One: What is a recommended way to restrict the use of third-party GitHub Actions in an enterprise environment?
A) Allow all public actions by default and update your policies as you see fit
B) Disable GitHub Actions entirely and build your own automation tools
C) Configure policies to allow only actions from approved organizations or repositories
D) Set repository visibility to private before adding third-party GitHub Actions

Question Two: How can an organization control access to reusable workflows in GitHub Actions?
A) By limiting access to approved repositories and teams
B) By making all workflows public
C) By deleting workflows after each use
D) By enabling auto-merge on all pull requests

Question Three: What is a self-hosted runner in GitHub Actions?
A) A runner managed by GitHub and available to all repositories
B) A runner managed by an external provider and available on marketplace
C) A runner that only executes scheduled workflows
D) A runner hosted and maintained by your organization, running on your own infrastructure

Question Four: Which step should administrators take to register a new self-hosted runner with a GitHub repository or organization?
A) Download the runner application and execute the configuration script with a registration token
B) Enable branch protection rules and review repository rulesets
C) Download the runner application and execute the configuration script with SSH in the command line
D) Add the runner to the workflow YAML file and in internal documentation

Question Five: How can organizations control which workflows have access to specific secrets?
A) By scoping secrets to specific branches, codespaces, or repositories
B) By rotating secrets regularly and removing unused secrets
C) By scoping secrets to particular environments, repositories, or organizations
D) By storing secrets only in the repository documentation that they want them to be used in

Question Six: What is required in a workflow to authenticate and publish a package to the GitHub Packages registry?
A) A personal access token (PAT) with appropriation permissions
B) A secret token with appropriate permissions
C) An merged pull request enabling the workflow
D) A runner in the workflow YAML file

Question Seven: Which of the following package formats is supported by GitHub Packages for storing code dependencies? Choose all that apply.

A) Markdown (.md)
B) Docker
C) CSV files
D) RubyGems
E) JavaScript

Question Eight: What happens to items when they are automatically archived in a GitHub project?

1. They are permanently deleted
2. They are moved to the archived project board
3. They are hidden from the active workspace but can be restored later
4. They are marked as completed

Jump to the answers comment 🧠

Looking to hide your answers? This markdown formatting will only show your answers if someone clicks to reveal it. Copy the text below to format your answers this way if you’d like!

<details>

Your answers go here!

</details>   

Use the discussion below to share additional study resources, ask questions for our team to answer, and respond to our prep questions.

*No Purchase Necessary. Open only to Github community members 18+. Game ends 11/1/25. For details, see Official Rules.

[paulsuv9]

✅ Week Four Knowledge Check – GitHub Admin Prep (With Rationale)

1. C) Configure policies to allow only actions from approved organizations or repositories
   → This ensures third-party actions are vetted and safe for enterprise use.

2. A) By limiting access to approved repositories and teams
   → Reusable workflows can be scoped to specific repos and teams for controlled access.

3. D) A runner hosted and maintained by your organization, running on your own infrastructure
   → Self-hosted runners are managed internally for custom execution environments.

4. A) Download the runner application and execute the configuration script with a registration token
   → This is the required setup step to register a new runner.

5. C) By scoping secrets to particular environments, repositories, or organizations
   → Secrets can be scoped to control access at multiple levels.

6. A) A personal access token (PAT) with appropriate permissions
   → PATs are required to authenticate and publish packages to GitHub Packages.

7. B) Docker, D) RubyGems, E) JavaScript
   → These are supported formats for storing code dependencies in GitHub Packages.

8. They are hidden from the active workspace but can be restored later
   → Archived items are not deleted—they’re retrievable if needed.

[fradel]

Click to reveal answers

Question One:
What is a recommended way to restrict the use of third-party GitHub Actions in an enterprise environment?
Answer: C) Configure policies to allow only actions from approved organizations or repositories

---

Question Two:
How can an organization control access to reusable workflows in GitHub Actions?
Answer: A) By limiting access to approved repositories and teams

---

Question Three:
What is a self-hosted runner in GitHub Actions?
Answer: D) A runner hosted and maintained by your organization, running on your own infrastructure

---

Question Four:
Which step should administrators take to register a new self-hosted runner with a GitHub repository or organization?
Answer: A) Download the runner application and execute the configuration script with a registration token

---

Question Five:
How can organizations control which workflows have access to specific secrets?
Answer: C) By scoping secrets to particular environments, repositories, or organizations

---

Question Six:
What is required in a workflow to authenticate and publish a package to the GitHub Packages registry?
Answer: B) A secret token with appropriate permissions

---

Question Seven:
Which of the following package formats is supported by GitHub Packages for storing code dependencies?
Answers:

• B) Docker
• D) RubyGems
• E) JavaScript

---

Question Eight:
What happens to items when they are automatically archived in a GitHub project?
Answer: They are hidden from the active workspace but can be restored later

[salahtidur]

Here are my answers:

1. C. Configure policies to allow only actions from approved organizations or repositories

2. A. By limiting access to approved repositories and teams

3. D. A runner hosted and maintained by your organization, running on your own infrastructure

4. A. Download the runner application and execute the configuration script with a registration token

5. C. By scoping secrets to particular environments, repositories, or organizations

6. B. A secret token with appropriate permissions

7. B. Docker, D. RubyGems, E. JavaScript

8. C. They are hidden from the active workspace but can be restored later

 

[MOHAMED-LAAGUILI]

1. C) Configure policies to allow only actions from approved organizations or repositories
2. A) By limiting access to approved repositories and teams
3. D) A runner hosted and maintained by your organization, running on your own infrastructure
4. A) Download the runner application and execute the configuration script with a registration token
5. C) By scoping secrets to particular environments, repositories, or organizations
6. B) A secret token with appropriate permissions
7. B) Docker , D) RubyGems , E) JavaScript
8. They are hidden from the active workspace but can be restored later

[mvark]

My answers -

C - The recommended way to restrict the use of third-party GitHub Actions in an enterprise environment is to configure policies to allow only actions from approved organizations or repositories

A - An organization can control access to reusable workflows in GitHub Actions by limiting access to approved repositories and teams

D - A self-hosted runner in GitHub Actions is a runner that is hosted and maintained by your organization, running on your own infrastructure

A - To register a self-hosted runner, download and install the runner application, then run the configuration script using the registration token generated by GitHub.

C - Organizations control which workflows have access to specific secrets primarily by scoping secrets to particular environments, repositories, or organizations

B - To authenticate and publish a package to the GitHub Packages registry in a GitHub Actions workflow, the workflow requires a secret token with appropriate permissions.

B,D,E - GitHub Packages supports the following package formats for storing code dependencies:

• Docker
• RubyGems
• JavaScript (npm)

C - When items are automatically archived in a GitHub project, they are hidden from the active workspace but can be restored later. Archiving items helps you improve focus by removing old items from your project views. An archived item retains all of its custom field data and can be viewed or restored from the archive page.

[mvark]

This year, I used GitHub Actions for the first time on a personal data project and I'm amazed by its capability.

I set up a workflow to query an externally hosted Datasette database with 17K+ records. In about a minute, it filtered the data down to 13K relevant records and automatically saved the results as a CSV file in my repo!

I owe my discovery of GitHub Actions to the GitHub Foundations exam.

[jccampanero]

Github actions are certainly a great tool @mvark, glad you find them useful too.

[paulsuv9]

Loved the use case, @mvark—17K records filtered and saved via GitHub Actions is a great showcase of automation at scale. Curious if you’ve explored any policy enforcement or secrets management workflows yet? That’s where I’m focusing this week.

[jccampanero]

Thank you very much for this new week's content.

These are my answers (I followed your advice @queenofcorgis Lili regarding the details section, thanks for the tip):

Question One: What is a recommended way to restrict the use of third-party GitHub Actions in an enterprise environment?
A) Allow all public actions by default and update your policies as you see fit
B) Disable GitHub Actions entirely and build your own automation tools
C) Configure policies to allow only actions from approved organizations or repositories
D) Set repository visibility to private before adding third-party GitHub Actions

Question Two: How can an organization control access to reusable workflows in GitHub Actions?
A) By limiting access to approved repositories and teams
B) By making all workflows public
C) By deleting workflows after each use
D) By enabling auto-merge on all pull requests

Question Three: What is a self-hosted runner in GitHub Actions?
A) A runner managed by GitHub and available to all repositories
B) A runner managed by an external provider and available on marketplace
C) A runner that only executes scheduled workflows
D) A runner hosted and maintained by your organization, running on your own infrastructure

Question Four: Which step should administrators take to register a new self-hosted runner with a GitHub repository or organization?
A) Download the runner application and execute the configuration script with a registration token
B) Enable branch protection rules and review repository rulesets
C) Download the runner application and execute the configuration script with SSH in the command line
D) Add the runner to the workflow YAML file and in internal documentation

Question Five: How can organizations control which workflows have access to specific secrets?
A) By scoping secrets to specific branches, codespaces, or repositories
B) By rotating secrets regularly and removing unused secrets
C) By scoping secrets to particular environments, repositories, or organizations
D) By storing secrets only in the repository documentation that they want them to be used in

Question Six: What is required in a workflow to authenticate and publish a package to the GitHub Packages registry?
A) A personal access token (PAT) with appropriation permissions ¹
B) A secret token with appropriate permissions ¹
C) An merged pull request enabling the workflow
D) A runner in the workflow YAML file

¹ I defined A and B as correct answers, I think they can both be right. On one hand, you can use GITHUB_TOKEN to publish packages within the same repository, limiting the scope and improving security, but you can also use a PAT to authenticate against the Github Packages registry, with broader access across repositories and organizations.

Question Seven: Which of the following package formats is supported by GitHub Packages for storing code dependencies? Choose all that apply.
A) Markdown (.md)
B) Docker
C) CSV files
D) RubyGems
E) JavaScript ²

² Assuming the answer means npm.

Question Eight: What happens to items when they are automatically archived in a GitHub project?
A) They are permanently deleted
B) They are moved to the archived project board
C) They are hidden from the active workspace but can be restored later
D) They are marked as completed

I wish to say thank you for this wonderful trip. As usual, it has been a great learning initiative with fantastic learning resources and community contributions.

Thank you for being a wonderful host, @queenofcorgis Lili.

[weekijoon]

For question 6, thanks for laying out your thoughts on both options since it is a helpful nuance to capture.

I think you're right that that both tokens can work. I would lean towards B if question is strictly asking required in a workflow since PAT itself isn't required, as a GITHUB_TOKEN alone would suffice (if GITHUB_TOKEN alone would suffice, PAT wouldn't be required, just a secret token with appropriate permission). Just maybe more of an exam question phrasing semantics, or I could be wrong too!

https://docs.github.com/en/packages/learn-github-packages/about-permissions-for-github-packages#access-tokens

Maybe @queenofcorgis could weigh in when the answers are out :)

[queenofcorgis]

Thanks for the kind words @jccampanero and for participating - it great to have you in the community!

[jccampanero]

For question 6, thanks for laying out your thoughts on both options since it is a helpful nuance to capture.

I think you're right that that both tokens can work. I would lean towards B if question is strictly asking required in a workflow since PAT itself isn't required, as a GITHUB_TOKEN alone would suffice (if GITHUB_TOKEN alone would suffice, PAT wouldn't be required, just a secret token with appropriate permission). Just maybe more of an exam question phrasing semantics, or I could be wrong too!

https://docs.github.com/en/packages/learn-github-packages/about-permissions-for-github-packages#access-tokens

Maybe @queenofcorgis could weigh in when the answers are out :)

Thank you very much @weekijoon. In the end you were right... I am happy to hear that, in any case, the brainstorming was useful for you.

Thank you very much for sharing the link to the appropriate Github documentation, and for your time to read and reply to my comment. I really appreciate it.

[jccampanero]

Thanks for the kind words @jccampanero and for participating - it great to have you in the community!

Thank you very much @queenofcorgis Lili. It is my pleasure to participate in this great community.

It is great to have you on Github!

[weekijoon]

Thank you for the great initiative and additional learning resources in addition to MS Learn, was a great way to keep myself engaged to complete the materials.

Answers:

1. Question One: What is a recommended way to restrict the use of third-party GitHub Actions in an enterprise environment? A) Allow all public actions by default and update your policies as you see fit B) Disable GitHub Actions entirely and build your own automation tools `C) Configure policies to allow only actions from approved organizations or repositories` D) Set repository visibility to private before adding third-party GitHub Actions

2. Question Two: How can an organization control access to reusable workflows in GitHub Actions?
   A) By limiting access to approved repositories and teams
   B) By making all workflows public
   C) By deleting workflows after each use
   D) By enabling auto-merge on all pull requests

3. Question Three: What is a self-hosted runner in GitHub Actions?
   A) A runner managed by GitHub and available to all repositories
   B) A runner managed by an external provider and available on marketplace
   C) A runner that only executes scheduled workflows
   D) A runner hosted and maintained by your organization, running on your own infrastructure

4. Question Four: Which step should administrators take to register a new self-hosted runner with a GitHub repository or organization?
   A) Download the runner application and execute the configuration script with a registration token
   B) Enable branch protection rules and review repository rulesets
   C) Download the runner application and execute the configuration script with SSH in the command line
   D) Add the runner to the workflow YAML file and in internal documentation

5. Question Five: How can organizations control which workflows have access to specific secrets?
   A) By scoping secrets to specific branches, codespaces, or repositories
   B) By rotating secrets regularly and removing unused secrets
   C) By scoping secrets to particular environments, repositories, or organizations
   D) By storing secrets only in the repository documentation that they want them to be used in

6. Question Six: What is required in a workflow to authenticate and publish a package to the GitHub Packages registry?
   A) A personal access token (PAT) with appropriation permissions
   B) A secret token with appropriate permissions
   C) An merged pull request enabling the workflow
   D) A runner in the workflow YAML file

7. Question Seven: Which of the following package formats is supported by GitHub Packages for storing code dependencies? Choose all that apply.
   A) Markdown (.md)
   B) Docker
   C) CSV files
   D) RubyGems
E) JavaScript

8. Question Eight: What happens to items when they are automatically archived in a GitHub project?
   They are permanently deleted
   They are moved to the archived project board
   They are hidden from the active workspace but can be restored later
   They are marked as completed

[queenofcorgis]

You're welcome, thank you for participating!

[Apexq]

1-C
2-A
3-D
4-A
5-C
6-B
7-B
8-C

[queenofcorgis]

The answers are... click details to reveal them! Don't worry if you haven't had a chance to study yet, after you post your answers, check them against the ones below.

Question One: What is a recommended way to restrict the use of third-party GitHub Actions in an enterprise environment? C) Configure policies to allow only actions from approved organizations or repositories

Question Two: How can an organization control access to reusable workflows in GitHub Actions?
A) By limiting access to approved repositories and teams

Question Three: What is a self-hosted runner in GitHub Actions?
D) A runner hosted and maintained by your organization, running on your own infrastructure

Question Four: Which step should administrators take to register a new self-hosted runner with a GitHub repository or organization?
A) Download the runner application and execute the configuration script with a registration token

Question Five: How can organizations control which workflows have access to specific secrets?
C) By scoping secrets to particular environments, repositories, or organizations

Question Six: What is required in a workflow to authenticate and publish a package to the GitHub Packages registry?
B) A secret token with appropriate permissions

Question Seven: Which of the following package formats is supported by GitHub Packages for storing code dependencies? Choose all that apply.

B) Docker
D) RubyGems

As a reminder, the winners of our 15 vouchers will be announced the week of November 3rd.

[paulsuv9]

Thanks for curating another solid module, @queenofcorgis. The Week Four focus on Actions and Packages helped reinforce some of the governance and automation patterns I’ve been tracking across enterprise workflows. Appreciate the clarity in the Docs links and the pacing across modules—looking forward to wrapping up.

[mvark]

From your answer for Question Seven: "Which of the following package formats is supported by GitHub Packages for storing code dependencies?", I see that though npm is related to JavaScript it is not considered as it has to be more explicit and specific.

[johnnieng]

Question 1
What is a recommended way to restrict the use of third-party GitHub Actions in an enterprise environment?

Answer: C – Configure enterprise or repository policies to allow only actions from approved sources.​
https://docs.github.com/en/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization

A) Allow all public actions by default — Not secure. This increases supply chain risk.

B) Disable GitHub Actions entirely — Too restrictive; organizations should manage rather than disable.
C) Configure policies to allow only actions from approved organizations or repositories — Correct. GitHub recommends restricting workflows to use only approved actions or those authored within your enterprise to minimize risk.​
D) Set repository visibility to private — Does not control third-party action usage.

Question 2
How can an organization control access to reusable workflows in GitHub Actions?

Answer: A – Access control is managed by allowing only approved repositories and teams to use reusable workflows.​
https://docs.github.com/en/actions/reference/workflows-and-actions/reusing-workflow-configurations

A) By limiting access to approved repositories and teams — Correct. Access to reusable workflows can be restricted at the repository, organization, or enterprise level, only allowing specific repositories or teams to call them.​

B) By making all workflows public — Opposite of best practice.
C) By deleting workflows after each use — Not required.
D) By enabling auto-merge on all pull requests — Unrelated.

Question 3
What is a self-hosted runner in GitHub Actions?

Answer: D – A self-hosted runner is maintained on your infrastructure to execute workflows.​
https://docs.github.com/en/actions/concepts/runners/self-hosted-runners

A) Managed by GitHub — That’s a GitHub-hosted runner.

B) Managed by an external provider — Incorrect.
C) Executes only scheduled workflows — False.
D) Hosted and maintained by your organization, running on your own infrastructure — Correct. Self-hosted runners are maintained by your organization on its own servers, VMs, or containers, providing control over software, OS, and compliance requirements.​

Question 4
Which step should administrators take to register a new self-hosted runner?

Answer: A – Download the runner app and configure it with a time-limited registration token.​
https://docs.github.com/en/actions/how-tos/manage-runners/self-hosted-runners/add-runners

A) Download the runner application and execute the configuration script with a registration token — Correct. After generating a token from GitHub’s runner setup page, the admin runs a configuration script to register the runner with the repository or organization.​

B) Enable branch protection rules — Unrelated.
C) Execute script with SSH manually — Partially true but incomplete.
D) Add the runner to YAML — That references an existing runner; it doesn’t register one.

Question 5
How can organizations control which workflows have access to specific secrets?

Answer: C – Secrets should be scoped to selected repositories, environments, or organizations.
https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets

A) By scoping secrets to specific branches or codespaces — Branch-based scoping is limited.

B) By rotating secrets regularly — Best practice, but not the control mechanism.
C) By scoping secrets to particular environments, repositories, or organizations — Correct. Secrets can be limited to specific environments or repositories, following the principle of least privilege.​
D) By storing secrets in documentation — Insecure.

Question 6
What is required in a workflow to authenticate and publish a package to the GitHub Packages registry?

Answer: B – A secret token with appropriate permissions.
https://docs.github.com/en/packages/managing-github-packages-using-github-actions-workflows/publishing-and-installing-a-package-with-github-actions

A) (Personal Access Token) can technically work but is not the recommended or required approach for workflows publishing to their own repository. GitHub recommends using GITHUB_TOKEN instead for better security.​

B) The GITHUB_TOKEN is accessed in your workflow file using the secrets context: ${{ secrets.GITHUB_TOKEN }}. This token must be configured with the proper permissions in your workflow file:​

• Read access for the contents scope

• Write access for the packages scope

This approach is GitHub's recommended best practice for publishing packages associated with the workflow repository. The GITHUB_TOKEN provides easy and secure authentication without requiring you to create and manage long-lived personal access tokens.

C) (Merged pull request) is not an authentication requirement - workflows can publish packages from various triggers, not just merged pull requests.

D) (Runner in YAML file) is necessary for workflow execution but is not specifically related to authentication for publishing packages.

Question 7
Which of the following package formats is supported by GitHub Packages for storing code dependencies?

Answer: B) Docker, D) RubyGems, and E) JavaScript
https://docs.github.com/en/[email protected]/packages/learn-github-packages/introduction-to-github-packages

A) Markdown (.md) - NOT SUPPORTED. Markdown files are used for documentation, not as a package format for storing code dependencies.

B) Docker - SUPPORTED. GitHub Packages includes a Container registry optimized for Docker and OCI images. You can publish Docker containers using a Dockerfile.​
C) CSV files - NOT SUPPORTED. CSV files are data formats, not package formats for dependency management.
D) RubyGems - SUPPORTED. GitHub Packages provides a RubyGems package manager registry where you can publish Ruby packages using Gemfile format with the gem client.​
E) JavaScript - SUPPORTED. GitHub Packages supports JavaScript packages through the npm registry, using package.json format with the npm client.​

Question 8
What happens to items when they are automatically archived in a GitHub project?

Answer: 3. They are hidden from the active workspace but can be restored later – Archiving preserves item data and allows recovery when needed.​
https://docs.github.com/en/issues/planning-and-tracking-with-projects/automating-your-project/archiving-items-automatically

1.They are permanently deleted — False.

2.They are moved to an archived project board — Not accurate.
3.They are hidden from the active workspace but can be restored later — Correct. Archived items are removed from active views but retain their data and can be restored at any time.​
4.They are marked as completed — Status depends on workflow, not archival.

[paulsuv9]

Appreciate the detailed breakdown and citations, @johnnieng—especially the nuance around PAT vs secret token for package publishing. Your framing helped clarify some of the edge cases I was tracking.

[venusuni]

this is very detailed!

[Misunhwang]

1. C
2. A
3. D
4. A
5. C
6. B
7. B
   8, C

[ImmrBhattarai]

I appreciate other mentioning detailed answers with official reference to documentation. But, here's my sweet summary of what I believe are the answers to these questions. Correct me, if I am incorrect somewhere.

1. C 2. A 3. D 4. A 5. C 6. B 7. B 8. C

[paulsuv9]

Nice summary, @ImmrBhattarai—looks like you’ve got a solid handle on the core concepts. Let me know if you’re exploring any reusable workflow setups or self-hosted runner configs this week!

[mvpkenlin]

Question #	My Answer	My Explain
Q1	C) Configure policies to allow only actions from approved organizations or repositories	This limits risk by restricting third-party GitHub Actions to trusted sources.
Q2	A) By limiting access to approved repositories and teams	Reusable workflows can be scoped to specific repos and teams for controlled access.
Q3	D) A runner hosted and maintained by your organization, running on your own infrastructure	Self-hosted runners give you control over the environment and resources.
Q4	A) Download the runner application and execute the configuration script with a registration token	This step registers the runner securely with GitHub.
Q5	C) By scoping secrets to particular environments, repositories, or organizations	This ensures secrets are only accessible where needed.
Q6	B) A secret token with appropriate permissions	Workflows use secret tokens to authenticate securely with GitHub Packages.
Q7	B) Docker D) RubyGems E) JavaScript	GitHub Packages supports multiple formats including Docker, RubyGems, npm (JavaScript), and more.
Q8	C) They are hidden from the active workspace but can be restored later	Archived items are not deleted—they’re just removed from view until needed.

[niikwade]

My answers to week 4's questions below. These learning weeks have been a good run, always is. I am really pumped to take the certification.

Question One: What is a recommended way to restrict the use of third-party GitHub Actions in an enterprise environment? **C) Configure policies to allow only actions from approved organizations or repositories**

Question Two: How can an organization control access to reusable workflows in GitHub Actions?
A) By limiting access to approved repositories and teams

Question Three: What is a self-hosted runner in GitHub Actions?
D) A runner hosted and maintained by your organization, running on your own infrastructure

Question Four: Which step should administrators take to register a new self-hosted runner with a GitHub repository or organization?
A) Download the runner application and execute the configuration script with a registration token

Question Five: How can organizations control which workflows have access to specific secrets?
C) By scoping secrets to particular environments, repositories, or organizations

Question Six: What is required in a workflow to authenticate and publish a package to the GitHub Packages registry?
B) A secret token with appropriate permissions

Question Seven: Which of the following package formats is supported by GitHub Packages for storing code dependencies? Choose all that apply.
B) Docker
D) RubyGems

Question Eight: What happens to items when they are automatically archived in a GitHub project?
C. They are hidden from the active workspace but can be restored later

[venusuni]

Trying to list out the keywords in MS DOC for easier reference

Question 1: Restricting third-party GitHub Actions
Answer: C) Configure policies to allow only actions from approved organizations or repositories

Explanation: This is the standard security practice for enterprises. Allowing all public actions (A) creates a significant security risk, as you would be running unvetted code. Disabling Actions entirely (B) negates the platform's value. The correct approach is to configure policies at the organization or enterprise level to create an "allow-list." This list permits only actions that are created by GitHub, by your own organization, or by other specific, trusted creators.

MS Doc Link: Enforcing policies for GitHub Actions in your enterprise

Keyword Area from Doc: "Allow specific actions and reusable workflows"

Question 2: Controlling access to reusable workflows
Answer: A) By limiting access to approved repositories and teams

Explanation: Reusable workflows are stored within a repository. Their accessibility is controlled by that repository's visibility and settings. For a reusable workflow in an internal repository, you can specify exactly which other repositories (or all repositories in the organization) are allowed to call it. For workflows in private repositories, you must explicitly grant access to other repositories.

MS Doc Link: Reusing workflows - Access control

Keyword Area from Doc: "Access to the reusable workflow"

Question 3: What is a self-hosted runner?
Answer: D) A runner hosted and maintained by your organization, running on your own infrastructure

Explanation: A self-hosted runner is a machine that you provide and manage, which connects to GitHub Actions. This contrasts with GitHub-hosted runners, which are managed by GitHub. Using self-hosted runners gives you complete control over the hardware, operating system, and software environment, which is often necessary for compliance, accessing private networks, or using specific hardware (like GPUs).

MS Doc Link: About self-hosted runners

Keyword Area from Doc: "What is a self-hosted runner?"

Question 4: Registering a new self-hosted runner
Answer: A) Download the runner application and execute the configuration script with a registration token

Explanation: The process involves going to your repository or organization's Settings > Actions > Runners page and clicking "New self-hosted runner." GitHub will provide platform-specific commands to download the runner application. You then run a configuration script (config.sh or config.cmd) and pass it a unique, time-limited registration token generated by GitHub. This token authenticates the runner and links it to your repository or organization.

MS Doc Link: Adding self-hosted runners

Keyword Area from Doc: "Adding a self-hosted runner to a repository" (or organization)

Question 5: Controlling workflow access to secrets
Answer: C) By scoping secrets to particular environments, repositories, or organizations

Explanation: GitHub provides three levels for managing secrets:

Organization-level: Can be made available to all or selected repositories.

Repository-level: Available to all workflows within that repository.

Environment-level: The most granular. The secret is only available to workflow jobs that explicitly deploy to a specific, named environment (e.g., production). This prevents development or test workflows from accessing production keys.

MS Doc Link: Using secrets in GitHub Actions

Keyword Area from Doc: "Levels of secrets"

Question 6: Authenticating to publish a package
Answer: B) A secret token with appropriate permissions

Explanation: To publish a package to GitHub Packages, your workflow needs to authenticate. This is typically done using the automatically generated GITHUB_TOKEN, which is a secret available in every workflow. Crucially, this token must be granted the packages: write permission in your workflow's YAML file. Alternatively, you can use a Personal Access Token (PAT) with the correct scope, but you must store it as a secret (like MY_PAT_SECRET) and use that secret in the workflow. In both cases, it's a "secret token with appropriate permissions."

MS Doc Link: Publishing and installing packages with GitHub Actions

Keyword Area from Doc: "Permissions for GITHUB_TOKEN"

Question 7: Supported package formats
Answer: B) Docker, D) RubyGems

Explanation: GitHub Packages supports several common package managers. According to the documentation, this includes container images (like Docker), RubyGems, npm (for JavaScript/Node.js), Apache Maven (for Java), Gradle (for Java), and NuGet (for .NET). Markdown and CSV files are document and data formats, not code package formats.

MS Doc Link: About GitHub Packages

Keyword Area from Doc: "Supported package registries"

Question 8: Archiving items in a GitHub project
Answer: C) They are hidden from the active workspace but can be restored later

Explanation: Archiving is a non-destructive way to clean up your project board. When an item (like a closed issue or merged pull request) is archived, its card is hidden from all open views. This keeps the board focused on active work. The item itself is not deleted and can be found in the "Archived items" view, from which it can be restored to the active board at any time.

MS Doc Link: Archiving items in your project

Keyword Area from Doc: "Archiving items" and "Restoring archived items from a view"

[AICertGit]

Here are the answers to questions.

Question 1: Restricting third-party GitHub Actions
Answer: C) Configure policies to allow only actions from approved organizations or repositories
https://docs.github.com/en/actions/get-started/understand-github-actions

Explanation: The recommended and most secure approach is to use an allow-list policy at the enterprise or organization level. This policy restricts workflows to only use actions created by GitHub, your organization, or other specifically approved third parties, preventing unvetted code execution.

Keywords: Configure policies, approved organizations, allow-list

Question 2: Controlling access to reusable workflows
Answer: A) By limiting access to approved repositories and teams
https://notes.kodekloud.com/docs/GitHub-Actions/Reusable-Workflows-and-Reporting/Step-3-Using-Inputs-in-Reusable-Workflow

Explanation: Access to a reusable workflow is controlled by the visibility and permissions of the repository where the workflow is stored. You limit access by explicitly configuring settings to allow only specific repositories or organization members/teams to call it.

Keywords: Limiting access, approved repositories, reusable workflows

Question 3: What is a self-hosted runner in GitHub Actions?
Answer: D) A runner hosted and maintained by your organization, running on your own infrastructure
https://github.com/nicklegan/aks-auto-scaling-github-self-hosted-runners

Explanation: A self-hosted runner is a machine you manage yourself (on-premises or in your cloud infrastructure) that executes GitHub Actions jobs. This gives you control over the hardware, operating system, and network environment.

Keywords: hosted and maintained by your organization, own infrastructure

Question 4: Registering a new self-hosted runner
Answer: A) Download the runner application and execute the configuration script with a registration token
https://baccini-al.medium.com/how-to-containerize-a-github-actions-self-hosted-runner-5994cc08b9fb

Explanation: To register, you first download the runner software. You then run a configuration script, passing it a unique, short-lived registration token provided by GitHub. This token authenticates the runner and links it to the target repository or organization.

Keywords: runner application, configuration script, registration token

Question 5: Controlling workflow access to specific secrets
Answer: C) By scoping secrets to particular environments, repositories, or organizations

Explanation: Secrets can be defined at the organization, repository, or environment level. Scoping secrets to a specific environment (like 'production') is the most granular way to ensure only jobs targeting that environment can access the sensitive data.

Keywords: scoping secrets, environments, repositories, organizations

Question 6: Required for authentication to publish a package
Answer: B) A secret token with appropriate permissions

Explanation: A workflow requires an authentication token with the necessary permissions. This is typically the built-in GITHUB_TOKEN (which is a type of secret) configured with the packages: write scope, or a user-defined Personal Access Token (PAT) stored as a secret.

Keywords: secret token, appropriate permissions, packages: write

Question 7: Supported package formats
Answer: B) Docker, D) RubyGems

Explanation: GitHub Packages supports various package management formats for code dependencies, including Docker (container images), RubyGems, npm, Apache Maven, and NuGet. Markdown and CSV files are general data formats, not package formats.

Keywords: Docker, RubyGems, package formats

Question 8: What happens to automatically archived items
Answer: They are hidden from the active workspace but can be restored later

Explanation: Archiving is a way to clean up the active view of a GitHub Project (Projects or Projects (classic)). Archived items are not permanently deleted; they are moved to an archival view and can be restored to the active board at any time.

Keywords: hidden from the active workspace, restored later, archived

[selendemir]

Question One: What is a recommended way to restrict the use of third-party GitHub Actions in an enterprise environment?
Answer: C) Configure policies to allow only actions from approved organizations or repositories

Security regulations that limit which third-party GitHub Actions are permitted to operate within the company can be enforced by administrators. By limiting the use of actions from reliable sources or organizations, these regulations lower the possibility of running harmful or unconfirmed code.

Question Two: How can an organization control access to reusable workflows in GitHub Actions?
Answer: A) By limiting access to approved repositories and teams

Permissions can be defined by organizations to limit who has access to reusable workflows. Administrators maintain improved governance and consistency across projects by limiting access to specific repositories or teams, ensuring that only authorized users can initiate or alter these workflows.

Question Three: What is a self-hosted runner in GitHub Actions?
Answer: D) A runner hosted and maintained by your organization, running on your own infrastructure

A self-hosted runner is a computer that runs GitHub Actions workflows and is controlled by your company. It can safely interact with on-premises infrastructure, supports specific software or hardware requirements, and gives greater control over the execution environment.

Question Four: Which step should administrators take to register a new self-hosted runner with a GitHub repository or organization?
Answer: A) Download the runner application and execute the configuration script with a registration token

Administrators must download GitHub's runner application and securely connect it to the repository or organization using a given registration token in order to add a self-hosted runner. Through this procedure, the runner is authenticated and given the ability to receive and carry out workflow jobs.

Question Five: How can organizations control which workflows have access to specific secrets?
Answer: C) By scoping secrets to particular environments, repositories, or organizations

There is fine-grained control over when and when secrets can be accessed because they can be declared at several levels, such as environment, repository, or organization. This makes it possible to guarantee that only operations that actually require sensitive data, such as credentials or API tokens, have access to them.

Question Six: What is required in a workflow to authenticate and publish a package to the GitHub Packages registry?
Answer: B) A secret token with appropriate permissions

A workflow has to contain an authentication token (such a GITHUB_TOKEN or Personal Access Token) with the required permissions in order to publish or communicate with GitHub Packages. This guarantees that packages in the registry can only be published or modified by workflows that are permitted.

Question Seven: Which of the following package formats is supported by GitHub Packages for storing code dependencies? (Choose all that apply.)
Answer: B) Docker, D) RubyGems

For storing and managing dependencies, GitHub Packages supports a variety of package formats, such as RubyGems for Ruby libraries and Docker for container images. Developers may safely save, version, and distribute code components within GitHub thanks to these integrations.

[nagasriramnani]

Question One: What is a recommended way to restrict the use of third-party GitHub Actions in an enterprise environment?
Answer: C) Configure policies to allow only actions from approved organizations or repositories

Question Two: How can an organization control access to reusable workflows in GitHub Actions?
Answer: A) By limiting access to approved repositories and teams

Question Three: What is a self-hosted runner in GitHub Actions?
Answer: D) A runner hosted and maintained by your organization, running on your own infrastructure

Question Four: Which step should administrators take to register a new self-hosted runner with a GitHub repository or organization?
Answer: A) Download the runner application and execute the configuration script with a registration token

Question Five: How can organizations control which workflows have access to specific secrets?
Answer: C) By scoping secrets to particular environments, repositories, or organizations

Question Six: What is required in a workflow to authenticate and publish a package to the GitHub Packages registry?
Answer: B) A secret token with appropriate permissions

Question Seven: Which of the following package formats is supported by GitHub Packages for storing code dependencies? Choose all that apply.
Answer: B) Docker
D) RubyGems
E) JavaScript

Question Eight: What happens to items when they are automatically archived in a GitHub project?
Answer: 3. They are hidden from the active workspace but can be restored later

You can copy and use the following markdown format to hide your answers:

Question 1: C
Question 2: A
Question 3: D
Question 4: A
Question 5: C
Question 6: B
Question 7: B, D, E
Question 8: 3

Please do mark answered, if this response has supported in discussion