✅ Beginner (1–15)
1. What is GitHub Actions?
Answer: GitHub Actions is a CI/CD tool provided by GitHub that allows you to automate your software development workflows.
Explanation: You can use it to build, test, and deploy your code directly from your GitHub repository.
2. What is a workflow in GitHub Actions?
Answer: A workflow is a YAML file that defines automated processes like testing or deployment.
Explanation: It lives in the .github/workflows directory and is triggered by specific events like code pushes or pull requests.
3. How do you trigger a GitHub Actions workflow?
Answer: By using events like push, pull_request, schedule, or workflow_dispatch.
Explanation: These are defined in the on: field of the workflow.
4. What is the purpose of the .github/workflows directory?
Answer: It's where all your workflow YAML files reside.
Explanation: GitHub automatically detects files in this path and runs them based on triggers.
5. What are jobs and steps in a workflow?
Answer: Jobs are groups of steps, and steps are individual commands or actions.
Explanation: Jobs run independently (or sequentially with needs:), and steps run in sequence inside a job.
6. What does runs-on mean in GitHub Actions?
Answer: It specifies the virtual environment (runner) on which the job will run.
Explanation: Example: runs-on: ubuntu-latest.
7. What is the difference between run and uses?
Answer: run executes shell commands, uses runs a pre-built GitHub action.
Explanation: uses: actions/checkout@v3 vs. run: echo Hello.
8. What is a GitHub-hosted runner?
Answer: A GitHub-hosted VM that runs your workflows.
Explanation: Comes pre-installed with tools for various languages and platforms.
9. What is workflow_dispatch used for?
Answer: It allows manual triggering of workflows via the GitHub UI.
Explanation: You can optionally define inputs: for dynamic behavior.
10. How do you use environment variables?
Answer: Use env: block or define inline with run:.
Example:
11. What is actions/checkout used for?
Answer: It checks out your repository code into the runner.
Explanation: Most workflows need it to access code.
12. What is the default shell in GitHub Actions?
Answer: Bash for Linux/macOS and PowerShell for Windows runners.
Explanation: Can be overridden using shell: key.
13. What are reusable workflows?
Answer: Workflows that can be called from other workflows using workflow_call.
Explanation: Great for standardizing pipelines across repositories.
14. How do you manually trigger workflows with inputs?
Answer: Use workflow_dispatch with inputs:
Example:
15. How do you define outputs in steps?
Answer: Use id + echo "key=value" >> $GITHUB_OUTPUT
Example:
✅ Intermediate (16–35)
16. How do you cache dependencies?
Answer: Use actions/cache@v3 with a key and path.
Use case: Speeds up builds by not reinstalling packages each time.
17. What is a matrix strategy?
Answer: It allows running a job for multiple configurations.
Example: Test Node.js on multiple versions.
18. How can you run jobs in sequence?
Answer: Use needs: to specify job dependencies.
Example:
19. How do you pass data between jobs?
Answer: Use outputs: in one job and needs.<job>.outputs.<key> in the next.
Explanation: Output must be explicitly set and exposed.
20. What are artifacts?
Answer: Files you can upload/download between jobs.
Use case: Upload test reports, logs, or build outputs.
21. What are secrets in GitHub Actions?
Answer: Encrypted values used for storing sensitive information.
Use case: Access tokens, AWS credentials, etc.
22. How do you conditionally run a step or job?
Answer: Use the if: conditional.
Example:
23. How do you trigger a workflow on schedule?
Answer: Use on: schedule: with a CRON expression.
24. What is GITHUB_ENV used for?
Answer: Used to persist environment variables across steps.
Example: echo "NAME=value" >> $GITHUB_ENV
25. What are GitHub Contexts?
Answer: Metadata objects like github, env, runner, etc.
Use case: Dynamic values like github.actor, github.sha
26. How do you debug a failing workflow?
Answer: Use run: echo and review logs in Actions UI.
Tip: Set ACTIONS_RUNNER_DEBUG and ACTIONS_STEP_DEBUG to true in secrets.
27. Can you reuse code across workflows?
Answer: Yes, using workflow_call or composite actions.
28. How do you deploy using GitHub Actions?
Answer: Build app → Push image → Deploy with Terraform, Helm, CLI, etc.
29. What are composite actions?
Answer: Custom actions made of multiple shell steps.
Stored in: .github/actions/your-action/action.yml
30. What is a self-hosted runner?
Answer: Your own server configured to run GitHub Actions workflows.
Use case: Specialized hardware, longer runtime, firewall access.
31. How do you run commands in different shells?
Answer: Use shell: key in run steps.
Example: shell: bash
32. How do you fail a workflow manually?
Answer: exit 1 in shell or throw in JavaScript.
Use case: Force failure on unmet conditions.
33. What is the difference between env: and secrets:?
Answer: env: is for non-sensitive values, secrets: for sensitive values.
34. How do you reference branch or commit info?
Answer: Use ${{ github.ref }} and ${{ github.sha }}
35. What is strategy.fail-fast?
Answer: Stops all matrix jobs if one fails. Default is true.
✅ Expert (36–50)
36. How do you run Terraform from GitHub Actions?
Answer: Use setup-terraform and securely pass AWS credentials.
Steps: init → validate → plan → apply
37. How do you run Docker builds and push to ECR?
Answer: Login with amazon-ecr-login, build and push image via CLI.
38. How do you pass inputs to a reusable workflow?
Answer: Use inputs: in workflow_call and reference with ${{ inputs.key }}.
39. How do you run workflows only on file changes?
Answer: Use paths: and paths-ignore: in the trigger.
40. What is the conclusion field in steps context?
Answer: It indicates if a step concluded with success, failure, or skipped.
41. How do you use GitHub Actions in monorepos?
Answer: Use paths: to limit triggers per directory.
42. How do you call one workflow from another?
Answer: Use workflow_call in the reusable workflow and uses: in caller.
43. How do you version your custom actions?
Answer: Tag releases (v1, v1.0.0) and use the tag in uses:.
44. How do you handle secret rotation securely?
Answer: Use repository or environment secrets, and rotate via API or manually.
45. What are environment protection rules?
Answer: Restrict deployment to environments until approved (via reviewers).
46. How can you test your GitHub Actions locally?
Answer: Use tools like act to simulate actions locally.
47. What are needs used for?
Answer: Specify job dependencies and pass outputs between jobs.
48. How do you dynamically name artifacts or logs?
Answer: Use ${{ github.run_number }} or ${{ github.sha }} in names.
49. How do you integrate Slack notifications?
Answer: Use slackapi/slack-github-action or curl with a webhook.
50. How do you secure workflows from unauthorized access?
Answer: Use branch protection rules, required reviewers, and encrypted secrets.
48. Can outputs be used by other workflows or steps?
Answer:
-
Within the same job: Yes, outputs from one step can be accessed by later steps in the same job using
${{ steps.<step_id>.outputs.<output_name> }}. -
Between jobs in the same workflow: Yes, but the producing job must declare the outputs explicitly using the
outputs:keyword, and the consuming job accesses them vianeeds.<job_id>.outputs.<output_name>. -
Between different workflows: No, outputs cannot be passed directly between workflows.
Explanation:
Outputs are scoped to the job or the steps within a job. For cross-job communication, outputs must be exposed explicitly. To share data across workflows, you must use workarounds such as storing data in artifacts, external storage (S3, database), or triggering workflows with input parameters.
Example for steps:
Example for jobs:
13. What are reusable workflows and composite actions? How do they differ?
Answer:
-
Reusable workflows are complete workflows that can be called from other workflows using the
workflow_calltrigger. They help standardize and share common CI/CD logic across multiple repositories or workflows. -
Composite actions are custom actions composed of multiple shell commands or steps, packaged as a single action that can be reused in workflows. They live inside a repository and simplify complex tasks into one reusable unit.
Explanation:
-
Reusable workflows can have inputs and outputs, accept parameters, and support job-level workflows.
No comments:
Post a Comment