After creating a new workflow, GitHub Actions will suggest starter workflows for your repository. What option should you click on if there is a starter workflow that you want to use?
A
Configure
B
Deploy
C
Use
D
Install
Correct Answer:
A. Configure
Explanation:
The “Choose a workflow“ page shows a selection of recommended starter workflows. Find the starter workflow that
you want to use, then click Configure. To help you find the starter workflow that you want, you can search for
keywords or filter by category.
https://docs.github.com/en/actions/learn-github-actions/using-starter-workflows
When creating a custom action for GitHub Actions, which of the following files are required? (select three)
A
script.py for Python actions
B
action.yml or action.yaml for action metadata
C
main.js or index.js for JavaScript actions
D
Dockerfile for containerized actions
Correct Answer:
B. action.yml or action.yaml for action metadata
Explanation:
The question topic revolves around the essential files required to create a custom action for GitHub Actions. This
includes understanding the necessary files and their formats, such as JavaScript files (main.js or index.js) for
JavaScript actions and an action metadata file (action.yml or action.yaml) to define the action‘s configuration and
behavior.
WRONG ANSWER:
While Python actions may use a .py script, there is no such thing as a Python action. GitHub only supports custom
actions for Docker container actions, Javascript actions, or composite actions.
https://docs.github.com/en/actions/creating-actions/about-custom-actions
Your organization uses GitHub Actions in Enterprise Cloud and wants to ensure automation is reused and maintained when creating new workflows in the organization‘s repositories. What feature should be used?
A
contribution guidelines
B
workflow templates
C
GitHub wiki
D
naming conventions
Correct Answer:
B. workflow templates
Explanation:
Workflow templates are a great way to ensure automation is reused and maintained in your enterprise. Both in
Enterprise Cloud and Enterprise Server, users with write access to an organization‘s .github repository can create
workflow templates that will be available for use to the other organization‘s members with the same write access.
Workflow templates can then be used to create new workflows in the public and private repositories of the
organization. <br.
WRONG ANSWERS:
contribution guidelines might be helpful, but they won‘t help ensure automation is reused and maintained in your
Enterprise.
naming conventions are super important (I‘ll take that to the grave), but they won‘t help ensure automation
workflows are reused
A GitHub wiki might help provide information and documentation for your organization, but it won‘t ensure the
reuse of existing workflows.
https://docs.github.com/en/actions/using-workflows/creating-starter-workflows-for-your-organization
Which YAML keyword is used to specify the events that should trigger a workflow?
A
event
B
on
C
workflow
D
Trigger
Correct Answer:
B. on
Explanation:
The on keyword is used to specify the events that should trigger a workflow. It allows you to define the events, such
as pushes, pull requests, or other GitHub activities, that should initiate the execution of the workflow
********************
WRONG ANSWERS:
There is no trigger keyword to specify the events that should trigger a workflow
The event keyword is not used to trigger a workflow
The workflow keyword is used to define the entire GitHub Actions workflow, including jobs, steps, and their
configurations
https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows
As the lead developer of the GitHub Action library, you are concerned about the reliability of versioning using tags.
A
use abbreviated commit SHAs instead of full SHAs for versioning to simplify tracking
B
implement commit SHAs for versioning to ensure reliability and security
C
continue to use tags but avoid deletions or movements to maintain consistency
D
utilize branch names instead of tags for versioning to prevent potential inconsistencies
Correct Answer:
B. implement commit SHAs for versioning to ensure reliability and security
Explanation:
Tags are useful and widely used, but one downside to using tags is that they can be deleted or moved. With Git, each
commit receives a calculated SHA value, which is unique and cannot be modified. Using a commit SHA for versioning
will give you the most reliable and secure way to version and use an action. However, often in Git you can abbreviate
the SHA hash to the first several characters, and Git will recognize the reference. If you‘re using the commit‘s SHA for
release management, you need to use the full SHA value and not the abbreviated value.
********************
WRONG ANSWERS: >br>
Continuing to use tags but avoiding deletions or movements to maintain consistency: While avoiding deletions or
movements of tags can help maintain consistency, relying solely on tags for versioning still poses risks due to their
susceptibility to deletion or movement.
Utilizing branch names instead of tags for versioning to prevent potential inconsistencies: Using branch names for
versioning introduces its own set of challenges, such as ambiguity in distinguishing between stable releases and
ongoing development, and does not address the issue of reliability and security associated with using tags.
Using abbreviated commit SHAs instead of full SHAs for versioning to simplify tracking: Abbreviated commit SHAs
may simplify tracking, but they do not ensure reliability and security in versioning. Utilizing full commit SHAs is
recommended for precise versioning and to avoid potential conflicts or inaccuracies. <br.
https://docs.github.com/en/actions/creating-actions/releasing-and-maintaining-actions
What functionality does a composite action offer in GitHub Actions?
A
integrating third-party APIs and services directly into workflows
B
automating the deployment of applications to cloud platforms like AWS and Azure
C
combining multiple workflow steps into one action for streamlined execution
D
creating custom Docker containers for isolated workflow execution
Correct Answer:
C. combining multiple workflow steps into one action for streamlined execution
Explanation:
A composite action allows for consolidating multiple workflow steps into a single action. This simplifies workflow
configuration and execution by bundling related steps together, enhancing the readability and maintainability of
workflows.
********************
WRONG ANSWERS:
This option describes the functionality of Docker container actions, not composite actions. Docker container actions
are used for running workflows within isolated Docker containers.
While GitHub Actions can interact with third-party APIs and services, this functionality is not specific to composite
actions. Composite actions focus on combining multiple workflow steps into one action.
While GitHub Actions can automate application deployment to cloud platforms, this functionality is not specific to
composite actions. Composite actions are used for streamlining workflow steps, not for deployment automation.
https://docs.github.com/en/actions/creating-actions/about-custom-actions#composite-actions
What happens if a job is not approved within 30 days while awaiting review in a workflow?
A
the job will automatically start without approval
B
the job will automatically fail
C
the job with be put on hold indefinitely until approved
D
the job will remain in the “Waiting” status until approved
Correct Answer:
B. the job will automatically fail
Explanation:
Jobs that reference an environment configured with required reviewers will wait for an approval before starting.
While a job is awaiting approval, it has a status of “Waiting“. If a job is not approved within 30 days, it will
automatically fail.
*****************
WRONG ANSWERS:
The job will not automatically start without approval, it will fail after 30 days
Putting the job on hold indefinitely will not happen, it will fail instead
The “Waiting” status is only on the job during the 30 day approval period, after the job will automatically fail
https://docs.github.com/en/actions/managing-workflow-runs/reviewing-deployments
You have developed a new GitHub Action and want to share it with the greater community. Where should you publish it?
A
a private repository
B
GitHub Marketplace
C
personal blog or website
D
a public repository
Correct Answer:
B. GitHub Marketplace
Explanation:
The GitHub Marketplace provides a platform for developers to share and discover GitHub Actions, enabling users to
find and incorporate pre-built actions into their workflows easily. Publishing your GitHub Action on the Marketplace
allows it to reach a wider audience and be easily discovered by other GitHub users.
********************
WRONG ANSWERS:
Publishing your GitHub Action in a private repository would restrict its visibility to only those who have access to the
repository. It would not be accessible to the broader community.
While you can publish your GitHub Action in a public repository, it may not be as discoverable or accessible to users
as it would be on the GitHub Marketplace.
While you could promote your GitHub Action on your personal website or blog, this method may not reach as wide
of an audience or be as convenient for users to discover and incorporate into their workflows compared to
publishing it on the GitHub Marketplace.
https://docs.github.com/en/actions/creating-actions/publishing-actions-in-github-marketplace
Your organization uses various custom actions and scripts within GitHub Actions workflows across projects. To enhance collaboration and manage components, which file and folder naming convention approach would be most beneficial?
A
stick to existing platform/language conventions without requiring organization-specific guidelines
B
use random names or abbreviations for shorter filenames
C
implement and enforce an organization-wide naming convention that clearly identifies the
component type, purpose, and version
D
allow individual teams to set their own naming conventions for their reusable components
Correct Answer:
C. implement and enforce an organization-wide naming convention that clearly identifies the
component type, purpose, and version
Explanation:
To effectively manage and collaborate on your organization‘s diverse reusable components in GitHub Actions
workflows, enforce a standardized naming convention across all teams. While existing platform/language
conventions offer a foundation, they lack the specificity for efficient discovery and collaboration within your unique
context. Random names or abbreviations, while concise, sacrifice clarity and impede component identification and
reuse.
********************
WRONG ANSWERS:
Random names/abbreviations promote compactness but hinder understanding and the identification and reuse of
components. Consistency is key.
While using existing conventions offers a base structure, relying solely on platform/language conventions can create
inconsistencies and lack clarity within your organization‘s specific context.
Individual team conventions can create inconsistency, making component discovery and collaboration across teams
challenging.
https://docs.github.com/en/actions/using-workflows/reusing-workflows
https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions
Which configuration is appropriate for triggering a workflow on a pull request?
A
on:
pull_request:
types: - main
B
on: push
C
on: fork
D
on:
pull_request:
branches: - main
Correct Answer:
D. on:
pull_request:
branches: - main
Explanation:
on:
pull_request:
branches: – main
This configuration specifies the pull_request event and further filters it to only trigger the workflow when the pull
request targets the main branch. This accurately defines the trigger condition for the workflow, ensuring that it runs
specifically when a pull request is opened or updated for the main branch.
******************
WRONG ANSWERS:
The types key should specify the types of pull request events to trigger the workflow, such as opened, synchronize,
or closed. The value main does not represent a valid pull request event type.
The configuration on: push is incorrect for triggering a workflow on pull requests. It‘s correct for triggering a
workflow on push events, but not for pull requests.
The configuration using on: fork runs your workflow when someone forks a repository but does not trigger for pull
requests.
https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows
https://docs.github.com/en/actions/using-workflows/triggering-a-workflow
Questions: 1-10 out of 539
Continue Full Practice..
GET ALL 539 QUESTIONS