# คำถามสัมภาษณ์งาน CI/CD Pipeline: GitHub Actions, GitLab CI และ Jenkins ปี 2026

> รวมคำถามสัมภาษณ์งาน CI/CD pipeline พร้อมคำตอบสำหรับปี 2026 ครอบคลุม GitHub Actions workflow, GitLab CI pipeline, Jenkins declarative pipeline และความปลอดภัย supply chain

- Published: 2026-05-18
- Updated: 2026-05-18
- Author: SharpSkill
- Tags: ci-cd, github-actions, gitlab-ci, jenkins, devops, interview
- Reading time: 10 min

---

คำถามสัมภาษณ์งานเกี่ยวกับ CI/CD pipeline ถือเป็นหนึ่งในหัวข้อที่พบบ่อยที่สุดในกระบวนการสรรหาบุคลากร DevOps ตลอดปี 2026 โดย [GitHub Actions](https://docs.github.com/en/actions) ประมวลผลงานมากกว่า 71 ล้าน job ต่อวัน, [GitLab CI](https://docs.gitlab.com/ee/ci/) เปิดตัวฟีเจอร์การสร้าง pipeline ด้วย AI และ [Jenkins](https://www.jenkins.io/) ยังคงอัตราการใช้งานอยู่ที่ 28% ผู้สัมภาษณ์คาดหวังให้ผู้สมัครสามารถแสดงทักษะการใช้งานจริงบนทั้งสามแพลตฟอร์มได้

> **สิ่งที่ผู้สัมภาษณ์ต้องการทดสอบ**
>
> คำถามสัมภาษณ์งาน CI/CD ส่วนใหญ่จะแบ่งออกเป็นสามหมวดหลัก: การออกแบบ pipeline (วิธีจัดโครงสร้าง stage และ job) ความปลอดภัย (การจัดการ secret และการเสริมความแข็งแกร่ง supply chain) และการแก้ไขปัญหา (การ debug build ที่ล้มเหลว การเพิ่มประสิทธิภาพ pipeline ที่ช้า) ผู้สมัครควรเตรียมตัวอย่างการเขียน pipeline configuration อย่างน้อยหนึ่งชุด

## โครงสร้าง Workflow และ Trigger ใน GitHub Actions

GitHub Actions จัดระบบอัตโนมัติผ่าน workflow, job และ step โดย workflow คือไฟล์ YAML ที่เก็บไว้ในไดเรกทอรี `.github/workflows/` ซึ่งกำหนดว่าระบบอัตโนมัติจะทำงานเมื่อใดและอย่างไร แต่ละ workflow สามารถมี job ได้หนึ่งหรือหลาย job และแต่ละ job จะทำงานบน runner ที่แยกกัน

คำถามสัมภาษณ์งานที่พบบ่อยจะขอให้ผู้สมัครอธิบายความสัมพันธ์ระหว่าง trigger `on` การพึ่งพาระหว่าง job และ keyword `needs`

```yaml
# .github/workflows/ci.yml
name: CI Pipeline

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run lint

  test:
    needs: lint              # รอให้ lint เสร็จก่อน
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node: [20, 22]       # รันเทสต์บนทั้งสองเวอร์ชัน
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}
          cache: npm
      - run: npm ci
      - run: npm test

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    environment: production  # ต้องได้รับการอนุมัติ
    steps:
      - uses: actions/checkout@v4
      - run: ./deploy.sh
```

Workflow นี้แสดงให้เห็นสามแนวคิดสำคัญ: keyword `needs` สร้าง dependency graph ระหว่าง job ต่างๆ, กลยุทธ์ `matrix` ช่วยให้ทดสอบแบบขนานบน Node.js หลายเวอร์ชัน และ keyword `environment` กำหนดให้การ deploy ต้องผ่านการอนุมัติด้วยตนเอง

## การกำหนดค่า Pipeline ใน GitLab CI ด้วย Stages

GitLab CI ใช้ไฟล์ `.gitlab-ci.yml` ที่ root ของ repository ซึ่งแตกต่างจาก GitHub Actions ที่ job ทำงานแบบอิสระโดยค่าเริ่มต้น [GitLab CI จัดกลุ่ม job เข้าใน stage](https://docs.gitlab.com/ee/ci/yaml/) ที่ทำงานตามลำดับ ในขณะที่ job ภายใน stage เดียวกันจะทำงานแบบขนาน

ผู้สัมภาษณ์มักขอให้ผู้สมัครแปลง workflow ของ GitHub Actions เป็น pipeline ของ GitLab CI หรือในทางกลับกัน

```yaml
# .gitlab-ci.yml
stages:
  - validate
  - test
  - deploy

variables:
  NODE_VERSION: "22"

lint:
  stage: validate
  image: node:${NODE_VERSION}
  cache:
    key: ${CI_COMMIT_REF_SLUG}
    paths:
      - node_modules/
  script:
    - npm ci
    - npm run lint

unit-tests:
  stage: test
  image: node:${NODE_VERSION}
  parallel:
    matrix:
      - NODE_VERSION: ["20", "22"]
  script:
    - npm ci
    - npm test
  artifacts:
    reports:
      junit: coverage/junit.xml
    expire_in: 7 days

deploy-production:
  stage: deploy
  image: alpine:latest
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual                   # ประตูควบคุมแบบแมนนวล
  environment:
    name: production
    url: https://app.example.com
  script:
    - ./deploy.sh
```

ความแตกต่างหลักจาก GitHub Actions: stages กำหนดลำดับการทำงานทั้งระบบ, keyword `parallel:matrix` จัดการ matrix build และ `artifacts:reports:junit` รวมผลการทดสอบเข้ากับหน้า merge request โดยตรง GitLab 18.11 ยังเปิดตัว [CI/CD inputs สำหรับ pipeline merge request](https://docs.gitlab.com/releases/18/gitlab-18-11-released/) ที่ช่วยให้กำหนดพารามิเตอร์แบบไดนามิกส์ได้ในแต่ละรอบการรัน pipeline

## ไวยากรณ์ Jenkins Declarative Pipeline

Jenkins ใช้ `Jenkinsfile` ที่เก็บไว้ที่ root ของ repository โดยไวยากรณ์ declarative pipeline ซึ่งเป็นมาตรฐานที่แนะนำในปี 2026 มอบการจัดการข้อผิดพลาดที่มีโครงสร้างชัดเจนและรูปแบบตาม stage ที่ชัดเจน

คำถามสัมภาษณ์ที่พบบ่อย: อธิบายความแตกต่างระหว่าง declarative และ scripted pipeline และเมื่อไรควรใช้แต่ละแบบ

```groovy
// Jenkinsfile
pipeline {
    agent any

    tools {
        nodejs 'node-22'       // กำหนดค่าใน Jenkins Global Tool
    }

    environment {
        CI = 'true'
        DEPLOY_ENV = credentials('deploy-env-secret')
    }

    stages {
        stage('Install') {
            steps {
                sh 'npm ci'
            }
        }

        stage('Lint & Test') {
            parallel {             // ทำงานแบบขนาน
                stage('Lint') {
                    steps {
                        sh 'npm run lint'
                    }
                }
                stage('Test') {
                    steps {
                        sh 'npm test'
                    }
                    post {
                        always {
                            junit 'coverage/junit.xml'
                        }
                    }
                }
            }
        }

        stage('Deploy') {
            when {
                branch 'main'
            }
            input {
                message 'Deploy to production?'
            }
            steps {
                sh './deploy.sh'
            }
        }
    }

    post {
        failure {
            mail to: 'team@example.com',
                 subject: "Build failed: ${env.JOB_NAME}",
                 body: "Check ${env.BUILD_URL}"
        }
    }
}
```

Declarative pipeline บังคับโครงสร้างผ่านบล็อกที่จำเป็นได้แก่ `pipeline`, `agent` และ `stages` คำสั่ง `parallel` ภายใน stage จะรัน lint และ test พร้อมกัน คำสั่ง `input` หยุดการทำงานชั่วคราวเพื่อรอการอนุมัติด้วยตนเอง คล้ายกับ environment ของ GitHub Actions และ manual gate ของ GitLab ทั้งนี้ Jenkins ยังกำหนดให้ใช้ Java 21 ตั้งแต่เดือนมกราคม 2026 ดังนั้นสภาพแวดล้อมของ pipeline ต้องคำนึงถึงความต้องการ runtime นี้ด้วย

## การจัดการ Secret บนแพลตฟอร์ม CI/CD ต่างๆ

ทุกการสัมภาษณ์งาน CI/CD จะมีคำถามเกี่ยวกับการจัดการ secret อยู่เสมอ แต่ละแพลตฟอร์มจัดการข้อมูลประจำตัวแตกต่างกัน และการเข้าใจผลกระทบด้านความปลอดภัยถือเป็นสิ่งสำคัญ

**GitHub Actions** เก็บ secret ในระดับ repository, environment หรือ organization โดย secret จะถูกซ่อนจาก log โดยอัตโนมัติ แต่รูปแบบ scoping ปัจจุบันยังมีข้อจำกัด [แผนงานด้านความปลอดภัยปี 2026](https://github.blog/news-insights/product-news/whats-coming-to-our-github-actions-2026-security-roadmap/) ได้เปิดตัว scoped secret ที่ผูกข้อมูลประจำตัวกับบริบทการทำงานเฉพาะ ลดความเสี่ยงจากสิทธิ์การเข้าถึงที่กว้างเกินไป

**GitLab CI** มอบ CI/CD variable พร้อมกฎการป้องกัน โดยตัวแปรที่ถูกป้องกันจะถูก inject เข้าไปใน pipeline ที่รันบน branch หรือ tag ที่ได้รับการป้องกันเท่านั้น GitLab 18.3 เพิ่มสิทธิ์แบบ fine-grained สำหรับ CI/CD job token โดยใช้หลักการ least-privilege

**Jenkins** ใช้ปลั๊กอิน Credentials ที่รองรับข้อมูลประจำตัวหลายรูปแบบ (username/password, SSH key, secret text, ใบรับรอง) helper `credentials()` ใน declarative pipeline จะผูก secret กับตัวแปรสภาพแวดล้อม และ credential ระดับ Folder จำกัดสิทธิ์การเข้าถึงเฉพาะโปรเจกต์

คำตอบสัมภาษณ์ที่สำคัญ: ห้าม hardcode secret ในไฟล์ pipeline โดยเด็ดขาด ใช้ระบบจัดการ secret ดั้งเดิมของแพลตฟอร์มเสมอ หมุนเวียน credential อย่างสม่ำเสมอ และเลือกใช้ token ระยะสั้นแทน API key ระยะยาว

## การเพิ่มประสิทธิภาพ Pipeline และกลยุทธ์การแคช

Pipeline ที่ช้าส่งผลโดยตรงต่อประสิทธิภาพการทำงานของนักพัฒนา ผู้สัมภาษณ์จะทดสอบว่าผู้สมัครสามารถวิเคราะห์และแก้ไขจุดคอขวดด้านประสิทธิภาพในระบบ CI/CD ได้หรือไม่

เทคนิคการเพิ่มประสิทธิภาพที่ใช้ได้ทั่วไปบนทั้งสามแพลตฟอร์มมีสามวิธี:

**Dependency caching** หลีกเลี่ยงการดาวน์โหลด package ซ้ำในทุกรอบการรัน GitHub Actions ใช้ `actions/cache` หรือการรองรับแคชที่มีมาใน setup action GitLab CI ใช้ `cache` พร้อมกลยุทธ์ key Jenkins อาศัยการคงอยู่ของ workspace หรือคำสั่ง `stash`/`unstash`

**การทำงานแบบขนาน** แบ่งงานไปยังหลาย runner GitHub Actions ใช้กลยุทธ์ `matrix`, GitLab CI ใช้ `parallel:matrix` และ Jenkins ใช้คำสั่ง `parallel` ระดับความละเอียดของการแบ่งงานที่เหมาะสมขึ้นอยู่กับโปรเจกต์: job ขนานมากเกินไปจะเสียเวลาเริ่มต้น runner แต่น้อยเกินไปจะทำให้ทรัพยากรเหลือใช้

**การทำงานแบบมีเงื่อนไข** ข้าม stage ที่ไม่จำเป็น ทั้งสามแพลตฟอร์มรองรับ: GitHub Actions ด้วยนิพจน์ `if`, GitLab CI ด้วย `rules` และ Jenkins ด้วยคำสั่ง `when` Pipeline ที่ออกแบบมาดีจะข้าม stage deployment บน feature branch และข้ามการเปลี่ยนแปลงเฉพาะ lint ไม่ให้รัน test suite ทั้งหมด

## ความปลอดภัย Pipeline CI/CD และการป้องกัน Supply Chain

การโจมตี supply chain ที่พุ่งเป้าระบบ CI/CD เพิ่มขึ้นอย่างมากในปี 2025 โดยมีเหตุการณ์ที่ส่งผลกระทบต่อ [tj-actions/changed-files และ GitHub Actions ยอดนิยมอื่นๆ](https://github.blog/news-insights/product-news/whats-coming-to-our-github-actions-2026-security-roadmap/) คำถามสัมภาษณ์ในปัจจุบันจึงทดสอบผู้สมัครเกี่ยวกับกลยุทธ์การเสริมความแข็งแกร่งเป็นประจำ

ตรึงเวอร์ชันของ action ด้วย commit SHA เฉพาะแทน tag เพื่อป้องกันการโจมตีแบบ tag-hijacking:

```yaml
# .github/workflows/secure.yml
steps:
  # เสี่ยง: tag สามารถถูกย้ายไปยัง commit ที่เป็นอันตราย
  - uses: actions/checkout@v4

  # ปลอดภัย: ตรึงด้วย commit SHA ที่แน่นอน
  - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
```

GitLab CI จัดการปัญหา supply chain ผ่าน [CI/CD components พร้อมการรับรอง SLSA Level 1](https://docs.gitlab.com/ee/ci/components/) (มีให้ใช้ตั้งแต่ GitLab 18.1) ซึ่งมอบแหล่งที่มาที่ชัดเจนยิ่งขึ้นเมื่อประกอบ pipeline จาก component ที่ใช้ซ้ำได้ container tag แบบ immutable (GitLab 18.2) ป้องกันการเปลี่ยน image หลังเผยแพร่แล้ว

สำหรับ Jenkins กลไก Shared Library ควรใช้ repository เฉพาะที่มี branch protection การกำหนดให้มี code review และ signed commit คณะกรรมาธิการยุโรปได้เปิดตัว[โครงการ Bug Bounty สำหรับ Jenkins](https://www.jenkins.io/blog/tags/announcement/) ผ่าน YesWeHack เมื่อไม่นานมานี้ สะท้อนให้เห็นถึงบทบาทสำคัญของแพลตฟอร์มนี้ใน supply chain ขององค์กร

## ตารางเปรียบเทียบข้ามแพลตฟอร์มสำหรับการเตรียมสัมภาษณ์

| คุณสมบัติ | GitHub Actions | GitLab CI | Jenkins |
|---|---|---|---|
| ไฟล์กำหนดค่า | `.github/workflows/*.yml` | `.gitlab-ci.yml` | `Jenkinsfile` |
| รูปแบบการทำงาน | ตาม job (ขนานโดยค่าเริ่มต้น) | ตาม stage (stage ตามลำดับ) | ตาม stage (ยืดหยุ่น) |
| Runner hosting | GitHub-hosted + self-hosted | GitLab.com shared + self-hosted | Self-hosted เท่านั้น |
| การเก็บ secret | Secret ระดับ repository/org/environment | CI/CD variable (มีการป้องกัน) | ปลั๊กอิน Credentials |
| Matrix build | `strategy.matrix` | `parallel:matrix` | `matrix` (ปลั๊กอิน) |
| ประตูแมนนวล | `environment` + required reviewers | `when: manual` | คำสั่ง `input` |
| Marketplace | 20,000+ Actions บน Marketplace | CI/CD Components Catalog | 1,800+ ปลั๊กอิน |
| ฟีเจอร์ AI | Copilot for Actions (preview) | Duo CI Expert Agent (beta) | ปลั๊กอินจากชุมชน |
| ราคา | ฟรีสำหรับ repo สาธารณะ, คิดตามนาทีสำหรับ repo ส่วนตัว | 400 นาที CI/CD ฟรี, จากนั้นเป็นขั้นบันได | ฟรี (โอเพนซอร์ส), ดูแลเอง |

ตารางเปรียบเทียบนี้ครอบคลุมความแตกต่างที่มักถูกทดสอบบ่อยที่สุดในการสัมภาษณ์ คำถามต่อยอดที่มักตามมาคือ: "จะเลือกแพลตฟอร์มใดสำหรับโปรเจกต์ใหม่ และเพราะอะไร?" คำตอบขึ้นอยู่กับเครื่องมือที่มีอยู่ ขนาดทีม ข้อกำหนดด้าน compliance และว่าองค์กรต้องการโครงสร้างพื้นฐานแบบจัดการให้ (GitHub/GitLab) หรือควบคุมทั้งหมด (Jenkins)

ฝึกฝนคำถามเหล่านี้ด้วยโมดูลสัมภาษณ์ [CI/CD fundamentals](/technologies/devops/interview-questions/ci-cd-fundamentals) และ [GitHub Actions](/technologies/devops/interview-questions/github-actions) หรือศึกษาเพิ่มเติมกับคำถามเฉพาะของ [GitLab CI](/technologies/devops/interview-questions/gitlab-ci) และ [Jenkins](/technologies/devops/interview-questions/jenkins) สำหรับการเตรียมตัว DevOps ที่ครอบคลุมยิ่งขึ้น คู่มือ[คำถามสัมภาษณ์งาน DevOps ที่จำเป็น](/blog/devops/essential-devops-interview-questions)ครอบคลุมหัวข้อทั้งหมดนอกเหนือจาก CI/CD

## สรุป

- GitHub Actions โดดเด่นสำหรับ workflow ที่ใช้งานกับ GitHub โดยตรงด้วยระบบนิเวศ marketplace และฟีเจอร์ parallel steps ที่กำลังจะมา แต่ควรตรึง action ด้วย commit SHA เพื่อลดความเสี่ยงจาก supply chain
- GitLab CI มอบการรวม CI/CD และการสแกนความปลอดภัยที่แน่นแฟ้นที่สุด พร้อมการรับรอง SLSA สำหรับ component และสิทธิ์ fine-grained job token ตั้งแต่เวอร์ชัน 18.3
- Jenkins ยังคงเป็นตัวเลือกที่ยืดหยุ่นที่สุดสำหรับองค์กรที่ต้องการควบคุมโครงสร้างพื้นฐานทั้งหมด แม้ว่าจะต้องการ Java 21 ตั้งแต่เดือนมกราคม 2026 และมีภาระการดูแลที่สูงกว่า
- การจัดการ secret เป็นหัวข้อด้านความปลอดภัยที่ถูกทดสอบมากที่สุดบนทั้งสามแพลตฟอร์ม: ควรแสดงความรู้เกี่ยวกับ scoped secret, protected variable และกลยุทธ์การหมุนเวียน credential
- การเพิ่มประสิทธิภาพ pipeline ผ่านการแคช การทำงานแบบขนาน และการทำงานแบบมีเงื่อนไขใช้ได้บนทุกแพลตฟอร์มและแสดงให้เห็นประสบการณ์ใช้งานจริงในระดับ production ต่อผู้สัมภาษณ์
- เตรียมการกำหนดค่า pipeline ที่ใช้งานได้จริงอย่างน้อยหนึ่งชุดต่อแพลตฟอร์ม โดยเน้นรูปแบบการใช้งานจริงแทนตัวอย่างอย่างง่าย

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/th/blog/devops/ci-cd-pipeline-interview-questions-github-actions-gitlab-ci-jenkins