Github Action Interview: CICD Pipeline

• Position: Senior Software Engineer | Devops Engineer
• Interview Time: Jan 2024
• Company Type: High traffic application
• Company Name: XXXX

1. What are GitHub Actions, and how do they differ from other CI/CD tools like Jenkins or GitLab CI/CD?

Answer:
GitHub Actions is a CI/CD tool tightly integrated with GitHub, allowing developers to automate workflows directly within their repositories. Unlike Jenkins, which requires an external server and more setup, GitHub Actions is cloud-native and requires minimal configuration. Compared to GitLab CI/CD, GitHub Actions provides flexibility with reusable workflows and integrations through the marketplace, though GitLab CI/CD is often praised for its native multi-project pipelines. GitHub Actions shines in ease of use and direct integration with GitHub events like push, pull_request, or release.

2. Can you explain the differences between workflows, jobs, and steps in GitHub Actions?

Answer:

• Workflow: A collection of jobs defined in a YAML file that automates processes (e.g., testing, building, deploying). Workflows are triggered by events like push or pull_request.
• Job: A unit of work within a workflow that runs on a single runner. Jobs can run in parallel or sequentially based on dependencies.
• Step: An individual task in a job, such as checking out code, running tests, or deploying. Steps can execute scripts or use prebuilt GitHub Actions from the marketplace.

For example, a workflow might have multiple jobs for testing and deployment, each with steps to check out the code and run commands.

3. How do you handle secrets in GitHub Actions? What are the best practices to ensure sensitive data is secure?

Answer:
Secrets are stored securely in the repository or organization settings. They are accessed in workflows via ${{ secrets.SECRET_NAME }}. Best practices include:

• Least Privilege: Only store secrets necessary for the workflow.
• Restrict Access: Use repository-level or environment-level secrets to limit access to specific workflows.
• Secret Rotation: Regularly update and rotate secrets to reduce the risk of exposure.
• Avoid Logging Secrets: Never echo secrets in logs or output to prevent accidental exposure.

4. Suppose a workflow fails during execution. How would you debug and resolve the issue?

Answer:

1. Review Logs: Examine the detailed logs provided by GitHub Actions for error messages.
2. Re-run Jobs: Use the “Re-run all jobs” option to ensure the failure isn’t transient.
3. Add Debugging: Use ACTIONS_RUNNER_DEBUG or custom logging to capture additional details.
4. Test Locally: Reproduce the issue locally using a runner like act.
5. Check Dependencies: Ensure dependencies (e.g., npm packages, Docker images) are available and compatible.

5. Can you walk through creating a reusable workflow for multiple repositories in an organization?

Answer:
Reusable workflows in GitHub Actions are created in a .github repository and shared across other repositories in the organization.

1. Define the Workflow: Create a YAML file under .github/workflows. Use workflow_call to allow inputs.
2. Reference the Workflow: In another repo, call the reusable workflow

6. How would you implement a deployment strategy using GitHub Actions for multiple environments (e.g., staging, production)?

Answer:
I would define environment-specific workflows and use GitHub Environments with approval gates:

1. Define different workflows for staging and production branches.
2. Use environment protection rules to require manual approval for production:

  jobs:  
    deploy:  
      environment:  
        name: production  
        requires: approval  

3. Use secrets specific to each environment for secure deployment.

7. What are some strategies you use to optimize GitHub Actions workflows to reduce execution time and costs?

Answer:

1. Parallel Jobs: Split independent jobs to run in parallel.
2. Caching: Utilize actions like actions/cache to store dependencies (e.g., npm packages, Docker layers) between runs.
3. Job Matrix: Use a matrix strategy to test multiple configurations simultaneously.
4. Selective Workflow Triggers: Only trigger workflows for specific branches or files.
5. Self-Hosted Runners: For high workloads, use self-hosted runners to save on GitHub-hosted runner costs.

8. Can you explain how to use caching effectively in GitHub Actions?

Answer:
Caching speeds up workflows by reusing data from previous runs. Common use cases include:

1. Caching Dependencies:

 steps:  
    - name: Cache npm dependencies  
      uses: actions/cache@v3  
      with:  
        path: node_modules  
        key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}  

2. Docker Layer Caching:
   Use GitHub’s cache feature to cache Docker layers to avoid rebuilding unchanged layers.

Ensure cache keys are unique to avoid conflicts and verify that caches are updated when dependencies change.

9. How do you ensure workflow security in GitHub Actions, especially for open-source repositories?

Answer:

• Use verified actions from the marketplace to reduce the risk of malicious code.
• Avoid directly running untrusted user input in workflows.
• Store sensitive data securely using GitHub Secrets.
• Enforce branch protection rules to prevent unverified changes.
• Regularly audit workflows and update dependencies to patch vulnerabilities.

10. What are composite actions in GitHub Actions, and how do you use them?

Answer:
Composite actions allow you to create custom actions by combining multiple steps. They are defined in action.yml files and help reuse logic across workflows. Example:

name: My Composite Action  
description: A reusable action  
inputs:  
  name:  
    description: Name input  
    required: true  
runs:  
  using: "composite"  
  steps:  
    - run: echo "Hello ${{ inputs.name }}"  

To use it, reference the action in your workflow:

steps:  
  - uses: ./path-to-composite-action  
    with:  
      name: World