Bộ Câu Hỏi Phỏng Vấn DevOps & Cloud Engineer 2026 Kèm Trả Lời Mẫu

Mặc định tuyệt đối: trong một cuộc phỏng vấn DevOps, những câu hỏi về công cụ, pipeline, và cloud có thể làm ứng viên thất bại chỉ vì các chi tiết nhỏ. Những câu hỏi về khái niệm thì ai cũng biết, nhưng các trò chuyện tình huống mới thực sự phân biệt những người tốt với những người xuất sắc.

Đây là bộ câu hỏi phỏng vấn DevOps & Cloud Engineer 2026 thật được hỏi nhiều nhất tại các công ty sản phẩm lớn và các startup công nghệ tại Việt Nam và quốc tế.

Tại Sao DevOps Vẫn Đều Tuyệt Đối Quan Trọng Trong 2026?

DevOps không còn là một từ khóa vay. Theo báo cáo DORA (DevOps Research and Assessment), các doanh nghiệp elite có thể:

• Deploy lên production nhiều lần mỗi ngày
• Tỷ lệ thay đổi lỗi (change failure rate) dưới 5%
• Thời gian phục hồi trung bình (MTTR) dưới 1 giờ

Những con số này tạo ra khoảng cách lớn với phần lớn các doanh nghiệp hiện nay. Đây là lý do các nhà tuyển dụng nhanh chóng đánh giá ứng viên qua khả năng thực tế, không phải khả năng thuộc lòng.

Cụ phỏng vấn DevOps 2026 thường bao gồm:

• 1 phỏng vấn screening 30 phút
• 1 phỏng vấn kỹ thuật 60 phút
• 1 phỏng vấn xử lý sự cố thực tế (live troubleshooting)
• 1 phỏng vấn system design 60 phút

Phần 1: Câu Hỏi Cơ Bản về DevOps và CI/CD

Câu 1: CI/CD là gì? Mô tả các giai đoạn của một pipeline

Trả lời: CI (Continuous Integration) là thực hành hợp nhất mã người phát triển vào cùng một nhánh chính thường xuyên, mỗi lần commit đều tự động kích hoạt kiểm tra. CD (Continuous Delivery) là bước tiếp theo, đảm bảo mã luôn sẵn sàng deploy lên production với một nút bấm. Continuous Deployment đi xa hơn, tự động deploy sau khi tất cả kiểm tra đều qua.

Giai đoạn của pipeline:

1. Commit và Build - Commit code, tự động build artifact
2. Test - Unit test, integration test, contract test
3. Security Scan - SAST, container scanning, secrets scanning
4. Artifact Store - Store image/artifact với phiên bản cụ thể
5. Deploy to Staging - Deploy lên môi trường staging
6. Smoke Test - Kiểm tra nhanh sau deploy
7. Approval - Phê duyệt từ người có thẩm quyền
8. Deploy to Production - Deploy lên production với chiến lược an toàn

Câu 2: Jenkins vs GitHub Actions vs GitLab CI - Bạn chọn cái nào và tại sao?

Trả lời: Không có công cụ nào là tốt nhất cho mọi trường. Lựa chọn phụ thuộc vào:

• Nếu bạn cần tích hợp sâu với GitHub, Actions là lựa chọn tự nhiên
• Nếu doanh nghiệp đã có Jenkins và không muốn di chuyển, tiến đời lên Jobs DSL và Pipeline
• GitLab CI mạnh khi bạn cần IOC (Integrated Ops Center) với issue tracking và CI/CD cùng một nơi

Điểm then chốt: GitHub Actions đã vượt Jenkins về thị phần thị trường trong 2025, theo Stack Overflow Survey. Nhưng vấn đề named pipe Jenkins còn tồn tại ở nhiều tổ chức lớn.

Câu 3: Làm thế nào để xử lý secrets trong pipeline?

Trả lời: Đây là câu hỏi loại bỏ ứng viên ngay lập tức.

• Tuyệt đối không lưu secrets trong code hoặc CI config
• Sử dụng HashiCorp Vault, AWS Secrets Manager, hoặc GCP Secret Manager
• Trong GitHub Actions: dùng Encrypted Secrets, inject tại runtime
• Trong Kubernetes: External Secrets Operator đồng bộ từ Vault
• Nguyên tắc: inject tại deploy time, không phải build time

Câu 4: Chỉ số DORA là gì? Tại sao nó quan trọng?

Trả lời: DORA là bốn chỉ số mà Google nghiên cứu trên hơn 30,000 kỹ sư:

• Deployment Frequency - Tần số deploy
• Lead Time for Changes - Thời gian từ commit đến production
• Change Failure Rate - Tỷ lệ lỗi thay đổi
• Time to Restore Service - Thời gian phục hồi dịch vụ

Nếu bạn chỉ nhớ một điều: elite team deploy nhiều lần/ngày,kém team deploy vài tuần hoặc ít hơn.

👉 Luyện tập trả lời câu hỏi CI/CD pipeline và DevOps cơ bản với X Interview để nắm vững quy trình build - test - deploy.

Phần 2: Docker và Container

Câu 5: Làm thế nào để tối ưu hóa một Dockerfile chậm?

Trả lời: Đây là bài toán thực tế mà nhiều kỹ sư gặp phải.

# Dùng multi-stage build để giảm kích thước

FROM node:18-alpine AS builder

WORKDIR /app

COPY package*.json ./

RUN npm ci --only=production

COPY . .

RUN npm run build

FROM node:18-alpine

WORKDIR /app

COPY --from=builder /app/dist ./dist

COPY --from=builder /app/node_modules ./node_modules

EXPOSE 3000

CMD ["node", "dist/index.js"]

Kỹ thuật then chốt:

1. Multi-stage builds - Loại bỏ build dependencies khỏi image cuối
2. Minimal base image - Alpine, distroless thay vì ubuntu
3. Layer caching - Đặt less frequently changed layers trước
4. .dockerignore - Loại bỏ node_modules, .git khỏi context

Câu 6: Sự khác nhau giữa COPY và ADD trong Dockerfile?

Trả lời:

• COPY - Copy file/directory từ context vào image, hạn chế hơn nhưng dễ dưới hơn
• ADD - Có thể copy từ URL (curl), giải nén tar/zip tự động, nhưng phức tạp hơn

Quy tắc: Dùng COPY trước. Chỉ dùng ADD khi bạn thực sự cần URL hoặc giải nén tự động.

Câu 7: Docker layer caching hoạt động như thế nào?

Trả lời: Mỗi instruction trong Dockerfile tạo ra một layer. Docker cache các layer đã build nếu instruction không thay đổi. Thực tế:

• Thay đổi thứ tự instruction để maximise cache hits
• Instruction phổ biến như RUN npm ci nên đặt trước COPY . .
• COPY package*.json trước COPY . . vì package.json thay đổi ít hơn code

👉 Thực hành các câu hỏi Docker và Containerization với X Interview — từ Dockerfile optimization đến multi-stage build.

Phần 3: Kubernetes

Câu 8: Pod Lifecycle và Probe khác nhau như thế nào?

Trả lời:

• Liveness Probe - Kiểm tra container có còn sống không. Nếu thất bại, kubelet sẽ restart container
• Readiness Probe - Kiểm tra container có sẵn sàng nhận traffic chưa. Nếu thất bại, Service sẽ loại bỏ pod khỏi load balancing
• Startup Probe - Cho phép container khởi động trước khi các probe khác hoạt động

Ví dụ thực tế:

readinessProbe:

httpGet:

path: /healthz

port: 8080

initialDelaySeconds: 5

periodSeconds: 5

failureThreshold: 3

Câu 9: Chỉ số trụ trong Kubernetes và cách xử lý

Câu 10: Zero-downtime deployment trong Kubernetes như thế nào?

Trả lời: Sử dụng Strategy RollingUpdate:

spec:

strategy:

type: RollingUpdate

rollingUpdate:

maxSurge: 1

maxUnavailable: 0

Nguyên tắc:

• maxUnavailable: 0 - Không cho phép bất kỳ pod nào bị downtime
• maxSurge: 1 - Cho phép 1 pod thêm trong quá trình update
• PodDisruptionBudget đảm bảo luôn có đủ pod hoạt động

Câu 11: GitOps khác với CI/CD truyền thống như thế nào?

Trả lời: Đây là câu hỏi phân biệt senior DevOps với mid-level.

GitOps (Pull-based):

• Cluster đơn vị hóa vào Git repository, không phải CI push vào cluster
• Không cần credentials trong CI pipeline
• Audit trail tốt hơn qua Git history
• ArgoCD, Flux là các công cụ phổ biến

CI/CD truyền thống (Push-based):

• CI pipeline chạy kubectl apply hoặc helm upgrade
• Credentials cần được lưu trong CI
• Less secure vì credentials có thể bị compromise

👉 Luyện tập trả lời câu hỏi Kubernetes — Pod lifecycle, zero-downtime deployment, GitOps và troubleshooting cluster với X Interview.

Phần 4: Infrastructure as Code

Câu 12: Terraform state là gì? Tại sao nó quan trọng?

Trả lời: State là file JSON ghi nhận trạng thái hiện tại của hạ tầng. Nó liên kết giữa cấu hình (config) và thực thể trên cloud.

Vấn đề: Nếu hai người cùng chạy terraform apply, state có thể bị conflict. Giải pháp:

• Remote state - S3 + DynamoDB cho locking
• Workspace - Phân tách môi trường dev/staging/prod
• Backend - Lưu state trên cloud, không phải local

Câu 13: Hạn chế khi nào terraform apply thất bại giữa chừng?

Trả lời: Đây là tình huống "2 AM incident" mà nhiều kỹ sư đều gặp.

Tình huống: Apply chạy được 50% rồi fail.

Các bước xử lý:

1. Không chạy lại apply ngay - sẽ làm trạng thái phức tạp hơn
2. Chạy terraform state list để xác định resources nào đã được tạo
3. Chạy terraform apply một lần nữa - Terraform sẽ nhận diện và bỏ qua resources đã tồn tại
4. Nếu vẫn lỗi, dùng terraform state mv để di chuyển resources sang trạng thái đúng
5. Thông báo cho on-call team về trạng thái inconsistency

👉 Thử trả lời các câu hỏi Terraform và Infrastructure as Code thực tế với X Interview — bao gồm state management và troubleshooting.

Phần 5: Observability và Monitoring

Câu 14: SLI, SLO, SLA khác nhau như thế nào?

Trả lời:

• SLI (Service Level Indicator) - Metrics thực tế bạn đo: p99 latency, availability
• SLO (Service Level Objective) - Mục tiêu bạn đặt: 99.95% uptime, p99 < 200ms
• SLA (Service Level Agreement) - Hợp đồng với khách hàng: 99.9% uptime

Ví dụ: SLI là p99 latency = 180ms. SLO là p99 < 200ms. SLA là nếu không đạt, hoàn tiền 10%.

Câu 15: Prometheus pull-based model khác với push-based như thế nào?

Trả lời: Prometheus scrape (pull) metrics từ targets, không phải targets push lên Prometheus.

Lợi ích:

• Không cần config firewall cho targets
• Dễ đổi mới metrics endpoint mà không cần restart collector
• Tồn tại thực tế để scrape nhiều hơn 10,000 targets

Trade-off: Không phù hợp cho short-lived jobs (lambda functions). Giải pháp: Pushgateway cho những trường hợp này.

Phần 6: Troubleshooting Thực Tế

Câu 16: "Deployment đi vào production rồi error rate gấp 4 lần. Bạn làm gì?"

Trả lời: Đây là câu hỏi loại bỏ ứng viên không có phương pháp.

Bước 1: Rollback trước, debug sau. Lấy site trở lại bình thường trước.

Bước 2: Xác nhận rollback thành công bằng cách theo dõi error rate giảm

Bước 3: So sánh commit cũ và mới, đọc diff, đọc logs

Bước 4: Reproduce locally

Bước 5: Viết postmortem - cái gì break, tại sao tests không bắt được, cái gì thay đổi

Câu 17: "Kubernetes API server không phản hồi. Bạn xử lý như thế nào?"

Trả lời: Đi cắm:

1. Kiểm tra etcd - kubectl get componentstatus hoặc check etcd pod logs
2. Kiểm tra kubelet - systemctl status kubelet trên master nodes
3. Kiểm tra API server pod - kubectl get pods -n kube-system
4. Check networking - DNS resolution, connectivity giữa nodes
5. Xem logs - /var/log/kubernetes/ trên master nodes

Nếu là managed cluster (EKS/GKE/AKS): liên hệ nhà cung cấp vì đây có thể là infrastructure issue.

👉 Luyện tập xử lý tình huống troubleshooting Kubernetes và incident response với X Interview — rèn kỹ năng debug dưới áp lực.

Phần 7: Cloud Architecture

Câu 18: Thiết kế một ứng dụng trên AWS với high availability

Trả lời:

[CloudFront]

[ALB/EC2]

/ \

[ASG Zone 1] [ASG Zone 2]

[RDS Primary] [RDS Replica]

Thành phần cần có:

• Multi-AZ - EC2 auto-scaling qua 2+ AZ
• ALB - Load balancer với health checks
• RDS Aurora - Database với automatic failover
• S3 - Lưu trữ static assets với cross-region replication
• CloudFront - CDN cho content delivery

Câu 19: S3 bucket security best practices

Trả lời:

• Block public access - Tất cả setting
• Bucket policy - Chỉ cho phép từ VPC endpoint hoặc CloudFront
• IAM Roles - Không dùng Access Keys cho humans
• Encryption - SSE-S3 hoặc SSE-KMS
• Versioning - Bật versioning để recover
• Lifecycle - Chuyển sang IA sau 90 ngày, Glacier sau 1 năm

Nguyên tắc: User là người, Role là what you assume. Zero long-lived credentials cho applications.

👉 Thực hành các câu hỏi Cloud Architecture và AWS với X Interview — thiết kế hệ thống high availability, S3 security và IAM best practices.

Phần 8: Security và DevSecOps

Câu 20: Làm thế nào để bảo vệ CI/CD pipeline?

Trả lời:

1. Secrets management - Không lưu trong code, dùng vault
2. OIDC - Sử dụng OpenID Connect thay vì static credentials cho cloud access
3. Image signing - Sign container images với Cosign
4. SBOM - Software Bill of Materials để track dependencies
5. Policy as Code - OPA, Sentinel cho terraform plans
6. Audit trail - Tất cả thay đổi đều log và review được

Câu 21: Zero-trust networking trong Kubernetes

Trả lời:

• Network Policies - Default deny, chỉ cho phép nội dung rõ ràng
• Service Mesh - Istio/Linkerd cho mTLS
• Workload Identity - Kubernetes service account sang AWS IAM role
• Admission Controllers - OPA Gatekeeper cho policy enforcement
• Runtime Security - Falco cho anomaly detection

👉 Luyện tập trả lời câu hỏi DevSecOps và CI/CD security với X Interview — secrets management, image signing và zero-trust networking.

Kiến Nghị Chuẩn Bị Cho Kỹ Sư DevOps 2026

Top 5 công cụ nên thường thực

1. GitHub Actions - Đã vượt Jenkins, tích hợp sâu với GitHub
2. Terraform - IaC, remote state với locking
3. Kubernetes (CKA/CKAD) - Kubernetes admin certification
4. Prometheus + Grafana - Monitoring và alerting
5. ArgoCD - GitOps, pull-based deployment

Kiến nghị thực tế

1. Không học thuộc lòng - Hiểu trade-offs, không phải definitions
2. Có một câu chuyện - Mỗi câu trả lời nếu được neo vào dự án thật
3. Narrate thinking - Nếu troubleshooting, nói ra suy nghĩ, không im lặng
4. Hiểu System Design - Thiết kế pipeline, thiết kế hạ tầng
5. Postmortem - Viết được postmortem cho thấy sự trung thực và học hỏi

Tài liệu tham khảo

• AWS - What is DevOps?
• Kubernetes Official Documentation
• Docker Official Documentation
• Terraform by HashiCorp

Lời Kết

DevOps interview 2026 không còn là trắc nghiệm kiến thức. Đây là bài kiểm tra tư duy hệ thống, khả năng xử lý sự cố lúc 2 giờ sáng, và kinh nghiệm vận hành thực tế.

Nếu bạn muốn luyện tập với 200+ câu hỏi phỏng vấn DevOps & Cloud Engineer có trả lời chi tiết, cùng nhiều kịch bản tình huống, truy cập: X-interview.com

X-INTERVIEW cung cấp hệ thống ôn luyện với các bài mock interview, câu hỏi theo chủ đề, và hướng dẫn trả lời theo phương pháp STAR.