A workflow is the top-level GitHub Actions concept — a YAML file in .github/workflows/ that defines triggers, jobs, and steps for automated CI/CD processes.
2 / 14
The 'runs-on' key in a GitHub Actions job specifies:
'runs-on' defines the runner environment — GitHub provides hosted runners (ubuntu-latest, macos-latest, windows-latest) or you can use self-hosted runners.
3 / 14
A GitHub Actions 'secret' is:
Secrets store sensitive values (API keys, credentials) securely. They are masked in logs and accessible to workflows via the secrets context: ${{ secrets.MY_SECRET }}
4 / 14
The 'on: push: branches: [main]' trigger in a workflow means:
The 'on' key defines triggers. 'push: branches: [main]' fires the workflow on every push directly to the main branch.
5 / 14
What does 'needs' do in a GitHub Actions workflow with multiple jobs?
'needs' creates job dependencies — a 'deploy' job with 'needs: build' will only run after the 'build' job completes successfully.
6 / 14
Mark suggests adding an `always` trigger to Sarah's GitHub Actions workflow. Sarah is concerned about the workflow's execution time and wants to minimize unnecessary runs. She's questioning whether a general `runs-on` directive targeting 'ubuntu-latest' will adequately handle both successful and failed job outcomes, or if more granular control within the workflow itself is required. Specifically, she wonders if the default Ubuntu environment provides sufficient logging capabilities for all potential scenarios without requiring explicit conditional logic.
Sarah's question highlights a key distinction: the `always` trigger guarantees *some* logging execution regardless of the job's status, while a general `runs-on` directive relies on the default Ubuntu environment for logging. While Ubuntu provides basic logging, it might not be sufficient for complex failure scenarios requiring specific diagnostics or detailed error reporting. Explicit conditions within the workflow offer more targeted control over logging based on the actual outcome.
7 / 14
Mark suggests adding an `always` trigger to Sarah's GitHub Actions workflow. Sarah is concerned about the workflow's execution time and wants to minimize unnecessary runs. She's questioning whether a general `runs-on` directive targeting 'ubuntu-latest' will adequately handle both successful and failed job outcomes, or if more granular control within the workflow itself is required. Specifically, she wonders if the default Ubuntu environment provides sufficient logging capabilities for all potential scenarios without requiring explicit conditional logic.
Sarah's question highlights a key distinction: the `always` trigger guarantees *some* logging execution regardless of the job's status, while a general `runs-on` directive relies on the default Ubuntu environment for logging. While Ubuntu provides basic logging, it might not be sufficient for complex failure scenarios requiring specific diagnostics or detailed error reporting. Explicit conditions within the workflow offer more targeted control over logging based on the actual outcome.
8 / 14
Mark suggests adding an `always` trigger to Sarah's GitHub Actions workflow. Sarah is concerned about the workflow's execution time and wants to minimize unnecessary runs. She's questioning whether a general `runs-on` directive targeting 'ubuntu-latest' will adequately handle both successful and failed job outcomes, or if more granular control within the workflow itself is required. Specifically, she wonders if the default Ubuntu environment provides sufficient logging capabilities for all potential scenarios without requiring explicit conditional logic.
Sarah's question highlights a key distinction: the `always` trigger guarantees *some* logging execution regardless of the job's status, while a general `runs-on` directive relies on the default Ubuntu environment for logging. While Ubuntu provides basic logging, it might not be sufficient for complex failure scenarios requiring specific diagnostics or detailed error reporting. Explicit conditions within the workflow offer more targeted control over logging based on the actual outcome.
9 / 14
Mark suggests adding an `always` trigger to Sarah's GitHub Actions workflow. Sarah is concerned about the workflow's execution time and wants to minimize unnecessary runs. She's questioning whether a general `runs-on` directive targeting 'ubuntu-latest' will adequately handle both successful and failed job outcomes, or if more granular control within the workflow itself is required. Specifically, she wonders if the default Ubuntu environment provides sufficient logging capabilities for all potential scenarios without requiring explicit conditional logic.
Sarah's question highlights a key distinction: the `always` trigger guarantees *some* logging execution regardless of the job's status, while a general `runs-on` directive relies on the default Ubuntu environment for logging. While Ubuntu provides basic logging, it might not be sufficient for complex failure scenarios requiring specific diagnostics or detailed error reporting. Explicit conditions within the workflow offer more targeted control over logging based on the actual outcome.
10 / 14
Liam in the code review says: 'This action is running on a small VM. Can we specify runs-on: ubuntu-latest to improve build speed?' What does Liam likely mean by 'ubuntu-latest'?
runs-on: ubuntu-latest refers to using the newest stable version of Ubuntu as the execution environment for the GitHub Action. This ensures that the action benefits from the most up-to-date packages and security patches, contributing to faster build times and more reliable results. Option A is incorrect because 'ubuntu-latest' doesn't specify a *version*.
11 / 14
During a Slack conversation about debugging a failing GitHub Action, David asks: 'How do I check the logs generated by an action during its execution?' Which of the following options correctly describes how to view these logs?
GitHub Actions provides a dedicated 'Logs' section within the workflow run on the GitHub Actions dashboard. This is the standard and most effective way to view detailed logs generated during an action's execution – this is what David needs. git log and grep are not designed for this purpose, and checking the runs-on file won't show runtime logs.
12 / 14
In a PR description for a new GitHub Action that automatically deploys code to staging, Chloe writes: 'This action is triggered on every push to the develop branch and uses the deploy_staging secret.' What role does the deploy_staging secret likely play?
The deploy_staging secret is almost certainly a credential (e.g., an API key or password) used to authenticate with the staging environment's deployment server. This allows the action to securely deploy code without hardcoding sensitive information directly in the workflow definition. Option A is incorrect; the trigger defines the branch.
13 / 14
During a standup meeting, Ethan says: 'I'm using a GitHub Action that runs every time someone opens an issue in the bugtracker project.' What does Ethan likely mean by 'runs every time someone opens an issue'?
Ethan describes a GitHub Action triggered by a 'webhook event'. When someone creates a new issue in the bugtracker project (through the GitHub API), this triggers a webhook that calls the action. This is the standard way to automate responses to events within GitHub – Option B is correct.
14 / 14
Fiona asks you about using 'needs' in a multi-job GitHub Actions workflow. She wants to ensure that Job A completes successfully before Job B starts. Which of the following best describes the purpose of the 'needs' keyword?
'Needs' establishes a dependency between GitHub Actions jobs. This means Job B will not start until Job A has successfully completed its execution – ensuring proper workflow orchestration and preventing potential errors caused by incomplete dependencies. Option D is incorrect; 'needs' defines *dependencies*, not environment variables.
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
How many questions are in "GitHub Actions Vocabulary"?
This exercise has 14 questions. Each one gives instant feedback with an explanation, so you can see exactly why an answer is right or wrong.
Do I need to create an account to save my progress?
No account is required. The progress bar and score are tracked in your browser for the current session -- the exercise is designed to be a quick, repeatable drill rather than something you resume later.
What happens if I get an answer wrong?
You'll see the correct answer highlighted immediately, along with a short explanation of why it's correct. Wrong answers aren't penalized beyond your score, and you can keep going through every question.
How is this exercise different from reading an article?
Articles explain vocabulary and concepts through prose, while exercises like this one are interactive drills -- multiple-choice questions -- that test and reinforce your recall of specific terms and phrasing.
Can I retry this exercise?
Yes -- use the "Try again" button on the results screen to reset your score and go through all the questions again from the start.
Where can I find more Developer Toolchain exercises?
Browse the full Developer Toolchain hub for related drills, or check the site-wide exercises index for other IT English topics.
Is this exercise suitable for beginners?
This exercise assumes basic familiarity with IT terminology. If a term feels unfamiliar, check the site Glossary for a plain-English definition before attempting the questions.
How often is new content like this published?
New exercises are added regularly across all categories, alongside new vocabulary sets and articles. Check back on the exercises hub to see what's new.