40 câu hỏi phỏng vấn DevOps hàng đầu cho năm 2026 (Kèm đáp án chuyên gia)

Câu hỏi phỏng vấn DevOps nâng cao

Những câu hỏi này đi sâu vào kiến trúc, khả năng mở rộng, bảo mật và khả năng lãnh đạo. Hãy sẵn sàng bàn về đánh đổi, quyết định thiết kế và cách bạn tiếp cận DevOps ở quy mô lớn.

21. GitOps là gì và khác gì DevOps?

GitOps là một nhánh của DevOps sử dụng Git làm nguồn chân lý duy nhất cho hạ tầng và phân phối ứng dụng.

Trong GitOps, mọi thay đổi với ứng dụng hoặc hạ tầng đều được thực hiện qua pull request vào các kho Git. 

Một trình điều khiển GitOps (ví dụ ArgoCD, Flux) giám sát thay đổi và đồng bộ chúng vào cluster, duy trì mối quan hệ một-một giữa repo Git và cluster.

Vì vậy, GitOps mang quản lý phiên bản, khả năng kiểm toán và rollback vào quy trình hạ tầng.

22. Giải thích policy-as-code kèm ví dụ.

Policy-as-code là việc viết các chính sách bảo mật, tuân thủ và vận hành dưới dạng mã có thể thực thi, được tự động hóa và áp dụng trên toàn hệ thống.

Ví dụ gồm:

• Dùng OPA (Open Policy Agent) để chặn triển khai Kubernetes phơi bày dịch vụ công khai
• Ép buộc tất cả tài nguyên Terraform phải gắn thẻ chủ sở hữu và môi trường
• Ngăn pipeline CI/CD triển khai lên prod khi chưa được phê duyệt

Tôi từng dùng Gatekeeper (tích hợp K8s của OPA) để chặn ảnh container chưa quét, cải thiện bảo mật.

23. Bạn sẽ thiết kế hệ thống CI/CD có khả năng mở rộng thế nào?

Thiết kế hệ thống CI/CD có khả năng mở rộng là thiết yếu, và dạng câu hỏi thiết kế rất phổ biến, vì người phỏng vấn có thể thấy cách bạn suy nghĩ và lập luận.

Một vài thành phần chính trong thiết kế của bạn:

• Tách rời các giai đoạn (build, test, deploy) với trách nhiệm rõ ràng
• Song song hóa để tăng tốc (ví dụ chạy test trên nhiều node)
• Runner động trên Kubernetes để co giãn
• Bộ nhớ đệm cho phụ thuộc và artifact
• Bí mật & cách ly truy cập giữa các dự án

Ở quy mô lớn, cân nhắc dùng Tekton hoặc GitLab CI với Kubernetes runner.

24. Cách bạn ứng phó sự cố (incident response)?

Đây là phần quan trọng, vì người phỏng vấn muốn thấy bạn tương tác với khách hàng thế nào, khi họ thường bực vì có lỗi. Xử lý sự cố là công việc thường ngày của kỹ sư DevOps.

Nguyên tắc chính gồm:

1. Giữ bình tĩnh
2. Chẩn đoán nhanh (Vấn đề mạng? Ứng dụng? Hạ tầng?)
3. Giao tiếp rõ ràng 
4. Ghi chép mọi thứ
5. Hậu kiểm (xác định nguyên nhân gốc rễ và rút kinh nghiệm)

Nhớ một điều quan trọng: Đừng đổ lỗi cá nhân. 

Hãy tập trung vào hệ thống, quy trình và cải tiến.

25. Bạn quản trị khả quan sát (observability) trên microservice như thế nào?

Microservice đóng vai trò thiết yếu trong bối cảnh DevOps ngày nay. Do đó, bạn nên có thể trả lời những câu hỏi cơ bản về chúng, thể hiện hiểu biết chung về DevOps.

Để có observability, bạn cần ba thành phần:

1. Logging: Tập trung, có cấu trúc, tìm kiếm được (ví dụ ELK, Loki)
2. Metrics: Chuỗi thời gian kiểu Prometheus + dashboard (ví dụ Grafana)
3. Tracing: Truy vết phân tán như Jaeger hoặc OpenTelemetry

Kết nối tất cả bằng correlation ID để theo dõi yêu cầu qua các dịch vụ.

26. Bạn tối ưu pipeline chậm như thế nào?

Điều này xảy ra khá thường xuyên, và có một số bước điển hình nên theo:

• Đo lường trước: Dùng số liệu pipeline và thời gian từng bước để tối ưu quy trình.
• Cache thông minh: Phụ thuộc, lớp Docker, kết quả kiểm thử.
• Chia nhỏ kiểm thử: Chạy song song theo loại hoặc module.
• Dùng pre-commit hook: Bắt lỗi sớm.
• Bỏ qua bước không cần thiết: Dùng logic điều kiện (ví dụ chỉ build Docker nếu mã trong vị trí tương ứng thay đổi).

Đôi khi chỉ thêm phần cứng nhanh hơn không giải quyết được, mà cần triển khai pipeline hiệu quả hơn.

27. Bạn tiếp cận tuân thủ (compliance) trong quy trình DevOps thế nào?

Tuân thủ nên được tích hợp chủ động ngay từ đầu vòng đời phát triển phần mềm. 

Các bước cần theo:

• Quản lý phiên bản mọi thứ (mã, hạ tầng, chính sách)
• Vết kiểm toán qua Git, log CI/CD và công cụ giám sát
• Kiểm tra tuân thủ tự động (ví dụ CIS benchmark, trình quét bảo mật)
• Kiểm soát truy cập qua RBAC và nguyên tắc tối thiểu
• Quản lý secret với chính sách xoay vòng

28. Bạn có thể giải thích service mesh trong bối cảnh DevOps?

Service mesh (ví dụ Istio, Linkerd) quản lý giao tiếp giữa các dịch vụ với các tính năng như:

• Điều khiển lưu lượng (ví dụ retry, timeout, định tuyến)
• Bảo mật (mTLS giữa các dịch vụ)
• Quan sát (telemetry theo dịch vụ)

Thay vì nhúng logic này vào từng ứng dụng, mesh xử lý qua các proxy sidecar.

29. Bạn kiến trúc triển khai không downtime như thế nào?

Triển khai không downtime là thiết yếu, vì cho phép bạn phát hành thay đổi mà không gián đoạn trải nghiệm người dùng.

Chiến lược cho triển khai không downtime gồm:

• Blue-green hoặc canary để chuyển lưu lượng an toàn
• Di trú cơ sở dữ liệu theo hướng tương thích ngược
• Kiểm tra sức khỏe của load balancer trước khi thêm instance mới
• Tắt dần (graceful shutdown) để yêu cầu đang xử lý hoàn tất

30. Chaos engineering là gì, bạn đã dùng chưa?

Chaos engineering là chủ động đưa lỗi vào hệ thống để kiểm tra khả năng chịu lỗi.

Công cụ ví dụ: 

• Gremlin
• Chaos Monkey
• Litmus

Các kịch bản mô phỏng để kiểm tra độ ổn định gồm:

• Diệt ngẫu nhiên pod
• Mô phỏng độ trễ mạng
• Ngắt kết nối DB

Chaos engineering cũng được Netflix dùng rất nhiều. 

Nó giúp mô phỏng các kịch bản khác nhau và xem hệ thống của bạn phản ứng ra sao.

Câu hỏi phỏng vấn DevOps theo hành vi và tình huống

Những câu hỏi này đánh giá khả năng phản ứng hiệu quả trong các tình huống thực. Người phỏng vấn muốn thấy bạn xử lý tình huống đời thực và kiểm tra xem bạn chỉ học vẹt hay thực sự hiểu DevOps. 

Hãy chờ đợi các câu hỏi đào sâu vào trải nghiệm, phán đoán và khả năng làm việc dưới áp lực hoặc hợp tác liên phòng ban.

31. Hãy kể về lần bạn sửa một đợt triển khai bị hỏng.

Đây là cơ hội để bạn mô tả một sự cố thực tế. 

Người phỏng vấn muốn biết:

• Tình huống: Hỏng ở đâu?
• Tác động: Mức độ nghiêm trọng?
• Cách tiếp cận: Bạn đã làm gì?
• Bài học: Lần sau bạn sẽ làm khác đi thế nào?

Ví dụ: 

Tôi từng gặp một lần triển khai thất bại âm thầm ghi đè tệp cấu hình quan trọng trên production. Ứng dụng ngừng hoạt động 1 giờ cho đến khi tôi hoàn nguyên thủ công về phiên bản cũ. Tổng cộng 30 người dùng bị chặn trong 1 giờ. Tôi chẩn đoán bằng Git diff, thêm bước xác thực vào CI và triển khai hỗ trợ rollback. Sự cố không tái diễn nữa.

32. Mô tả một xung đột với lập trình viên. Bạn xử lý ra sao?

DevOps nằm ở giao điểm của nhiều đội, xung đột là chuyện xảy ra. Ở đây, người phỏng vấn muốn thấy bạn có trí tuệ cảm xúc.

Định khung như sau:

• Gốc rễ xung đột (ví dụ phát hành vội, sở hữu không rõ ràng)
• Cách bạn tiếp cận cuộc trao đổi (thấu hiểu + dữ liệu)
• Giải pháp (ví dụ cập nhật quy trình, làm rõ trách nhiệm)

Hãy thành thật và tránh chỉ trích cá nhân lập trình viên. Luôn nhấn mạnh bạn hướng đến hợp tác hiệu quả.

Và luôn ghi nhớ: Lập trình viên và kỹ sư DevOps thường có ưu tiên khác nhau. Lập trình viên muốn ra tính năng nhanh, còn bạn chú trọng bảo mật, ổn định và khả năng bảo trì dài hạn. Sự căng thẳng đó là bình thường; hiểu góc nhìn của họ giúp xử lý xung đột xây dựng hơn.

33. Bạn cân bằng tốc độ và ổn định trong chu kỳ phát hành như thế nào?

Đây là mâu thuẫn muôn thuở của DevOps.

Bạn có thể tập trung vào: 

• Cờ tính năng (feature flag): Bật/tắt tính năng trên production.
• Chiến lược triển khai: Canary hoặc blue-green
• Phương pháp Agile: Lặp nhanh.
• Giám sát: Observability mạnh, cho phép phản ứng nhanh khi có sự cố.
• Giao tiếp: Văn hóa phản hồi mở và học hỏi liên tục từ sai lầm.
• Tự động hóa: Tự động hóa tối đa nơi phù hợp để đạt tốc độ và độ ổn định cao hơn.

Bạn không phải chọn giữa tốc độ và an toàn, vì có thể thiết kế hệ thống DevOps để cải thiện cả hai.

34. Hãy mô tả quy trình của bạn sau một sự cố production.

Hệ thống đôi khi sẽ hỏng. Do đó, khả năng đưa chúng trở lại bình thường nhanh nhất có thể là tối quan trọng. 

Vì vậy, bạn có thể theo các bước sau để khôi phục hệ thống: 

1. Ghi nhận và cô lập: Cảnh báo bên liên quan và truyền thông kịp thời.
2. Chẩn đoán nhanh: Kiểm tra log, metric và dashboard để xác định vấn đề.
3. Khắc phục: Áp bản vá, rollback ứng dụng hoặc cấu hình lại để đưa hệ thống hoạt động trở lại.
4. Hậu kiểm: Ghi lại thời gian tìm và sửa lỗi, nguyên nhân gốc rễ và các đầu việc phòng tránh tái diễn.

Nếu bạn chưa từng dẫn dắt cuộc gọi xử lý sự cố, hãy luyện tập. Đây là kỹ năng được kỳ vọng ở kỹ sư cấp cao.

35. Hãy mô tả kinh nghiệm làm việc với các đội liên chức năng.

Là kỹ sư DevOps, bạn sẽ làm việc với rất nhiều đội liên chức năng. Hợp tác tốt là thiết yếu, và người phỏng vấn sẽ xem xét kỹ kỹ năng cộng tác của bạn.

Bạn có thể nói về:

• Cách bạn kết nối dev và ops
• Cách bạn hỗ trợ nhà khoa học dữ liệu áp dụng CI/CD
• Cách bạn giải quyết mâu thuẫn giữa đội bảo mật và sản phẩm (họ cãi nhau khá nhiều, tin tôi đi)

Nếu bạn từng tạo tài liệu hay công cụ nội bộ giúp người khác làm việc hiệu quả hơn, hãy nhắc đến, vì thể hiện tinh thần chủ động.

36. Bạn đã từng tự động hóa để loại bỏ công việc của chính mình chưa?

Đây là câu tôi thích nhất.

Thực tế: một mục tiêu cốt lõi của DevOps là tự động hóa quy trình lặp lại. Nhưng khi tự động hóa hết, còn gì để làm? Không hiếm kỹ sư DevOps tự động hóa đến mức không còn việc thủ công.

Dù vậy, tự động hóa chính là mục tiêu. Hãy thể hiện nó đã thấm vào tư duy của bạn. Công việc thủ công nên là cờ đỏ, thứ cần loại bỏ chứ không dung thứ.

Ví dụ:

"Tôi từng triển khai môi trường staging thủ công mỗi sáng thứ Hai. Tôi viết một script để xử lý chỉ với một lệnh, rồi gói nó vào GitHub Action để cả đội có thể kích hoạt bất cứ lúc nào."

Mục tiêu là chứng minh bạn suy nghĩ như một kỹ sư DevOps: giảm ma sát, loại bỏ nút thắt cổ chai, giải phóng con người cho các vấn đề phức tạp hơn.

37. Bạn giúp kỹ sư junior làm quen với thực hành DevOps như thế nào?

Câu hỏi này kiểm tra kỹ năng lãnh đạo và hợp tác nhóm của bạn. 

Một số ý tưởng để onboarding kỹ sư junior:

• Tạo trang tài liệu “Bắt đầu” với tất cả thông tin và liên kết liên quan
• Lập trình cặp hoặc cùng gỡ lỗi
• Ghi chép runbook và quy trình công việc
• Tạo môi trường sandbox để thử nghiệm an toàn
• Tổ chức workshop nội bộ về Docker/Kubernetes cơ bản

Khác biệt giữa kỹ sư giỏi và xuất sắc nằm ở kỹ năng truyền đạt.

38. Hãy mô tả một dự án DevOps mà bạn tự hào.

Đây là lúc bạn nói về một thành công sáng tạo của mình. Chọn thứ bạn đã tạo ra đáng kể và có thể nói chi tiết.

Bạn có thể nói về:

• Vấn đề bạn giải quyết
• Tác động (ví dụ tăng tốc phát hành, giảm MTTR)
• Công cụ và kiến trúc bạn dùng
• Điều bạn học được

Tôi từng là một phần của đội xây dựng một nền tảng MLOps nhỏ. Nền tảng này được phát hành dưới dạng Helm chart. Ban đầu, chúng tôi triển khai vào các namespace Kubernetes bằng bash script, phải kiểm tra thủ công xem Helm chart có được cập nhật thành công không, và mỗi lần phát hành mất gần một ngày. Sau đó, tôi triển khai GitOps với ArgoCD để phát hành chart nền tảng đến tất cả namespace chỉ với một cú nhấp, giảm thời gian phát hành xuống vài phút.

39. Bạn sẽ cải thiện điều gì trong pipeline DevOps hiện tại của mình?

Câu hỏi này thể hiện tinh thần tự phản biện và tầm nhìn của bạn.

Tránh nói “không có gì”. Thay vào đó, bạn có thể:

• Nêu nút thắt cổ chai (ví dụ bộ test chậm)
• Một nâng cấp công cụ đang dự định (ví dụ chuyển từ Jenkins sang Tekton)
• Khoảng trống observability bạn đang khắc phục
• Hoặc thậm chí điều chỉnh văn hóa (ví dụ tài liệu tốt hơn)

Bạn được đánh giá không chỉ bởi những gì bạn biết, mà còn bởi cách bạn suy nghĩ.

40. Hãy kể về lần bạn giới thiệu công cụ hoặc thực hành mới. Bạn đã thuyết phục mọi người như thế nào?

Là kỹ sư DevOps, bạn cải thiện quy trình và tự động hóa công việc. Điều này có nghĩa là bạn thay đổi hiện trạng, thường khiến mọi người do dự vì không muốn thay đổi.

Bạn cần thể hiện rằng mình có thể xử lý những tình huống như vậy một cách bình tĩnh và chuyên nghiệp. 

Bạn có thể đưa vào câu trả lời:

• Vì sao bạn đề xuất công cụ/thực hành đó?
• Bạn đã trình bày với đội như thế nào?
• Bạn đối mặt với sự phản kháng ra sao?
• Kết quả thế nào?

Ví dụ: “Tôi đề xuất áp dụng Terraform thay thế việc cấu hình AWS thủ công. Một vài đồng đội do dự, nên tôi demo quy trình có thể lặp lại, bổ sung tài liệu và hỗ trợ onboarding.”

Chiến lược chuẩn bị phỏng vấn

Phỏng vấn DevOps kiểm tra nhiều hơn là kiến thức kỹ thuật. Họ kiểm tra khả năng giải quyết vấn đề, hợp tác và tư duy phản biện dưới áp lực. 

Các phần sau đưa ra cách thực tế để mài giũa kỹ năng và nổi bật.

Đào sâu kỹ thuật

Chỉ hiểu bề mặt không đủ ở cấp mid hay senior. Bạn cần hiểu cách hệ thống vận hành bên trong.

Bạn nên đào sâu vào:

• Kubernetes: Học cách triển khai, scale và gỡ lỗi cluster. Tập trung vào mạng, volume bền vững và Helm.
• Terraform: Hiểu quản lý state, module và sử dụng remote backend.
• Mẫu hình CI/CD: Học cách tách rời giai đoạn, cache build và bảo mật pipeline.

Nếu bạn xây kỹ năng từ đầu, hãy bắt đầu với Introduction to Kubernetes và DevOps Concepts của DataCamp.

Tôi cũng luôn khuyên làm dự án thực hành, vì đó là nơi bạn học được nhiều nhất. Bạn có thể xây một ứng dụng, đóng gói container và triển khai bằng Terraform và Kubernetes với pipeline tự động.

Gợi ý tài nguyên

Bạn không cần tự học một mình. Có rất nhiều tài nguyên trực tuyến giúp tối ưu hành trình học của bạn. 

Một số tài nguyên hữu ích:

• Phỏng vấn thử: Thử các dịch vụ như Pramp, Interviewing.io, hoặc phỏng vấn ngang hàng với bạn bè/đồng nghiệp.
• Sách:
• The Phoenix Project (về văn hóa và câu chuyện DevOps giúp doanh nghiệp cải thiện)
• Site Reliability Engineering của Google (đào sâu)
• Terraform Up & Running của Yevgeniy Brikman (làm chủ IaC)
• Cheat sheet: In tham chiếu CLI Kubernetes, quy trình Git hoặc lệnh Linux bạn dùng hàng ngày.
• Cộng đồng:
• Các nhóm DevOps trên Discord
• r/devops trên Reddit
• Dev.to, Medium và blog DataCamp
• Khóa học:
• DevOps Concepts: Nền tảng cho pipeline phân phối và độ tin cậy hệ thống.
• Containerization and Virtualization with Docker and Kubernetes: Thiết yếu cho câu hỏi tập trung vào triển khai
• CI/CD for Machine Learning và Fully Automated MLOps: Nếu bạn ở vai trò kết hợp ML+DevOps.
• Bài viết chuẩn bị phỏng vấn khác:
• Đôi khi, hợp lý khi đào sâu vào các bài viết chuẩn bị phỏng vấn ở lĩnh vực liên quan. Ví dụ:
• 31 câu hỏi phỏng vấn Azure DevOps hàng đầu cho mọi cấp độ
• 24 câu hỏi phỏng vấn AWS DevOps hàng đầu
• 34 câu hỏi phỏng vấn Kỹ sư Đám mây hàng đầu năm 2026
• 30 câu hỏi phỏng vấn Điện toán Đám mây hàng đầu (2026)
• 30 câu hỏi phỏng vấn MLOps hàng đầu cho 2026

Nếu muốn nổi bật, bạn cần vượt xa việc học thuộc. Hãy xây dựng, cố tình làm hỏng và cải thiện.

Chuẩn bị cho câu hỏi theo tình huống và thực tế

Đây là nơi nhiều người vấp ngã. Nói CI/CD là gì thì dễ. Bình tĩnh nói về một sự cố production lúc 2 giờ sáng bạn đã xử lý (hoặc sẽ xử lý) thì khác.

Cách chuẩn bị:

• Xem lại các sự cố cũ: Điều gì sai? Cách khắc phục? Bây giờ bạn sẽ thay đổi gì?
• Làm hậu kiểm: Cả cho dự án cá nhân. Luyện viết theo cấu trúc STAR.
• Nghĩ như bên liên quan: Nếu phải giải thích bản phát hành thất bại cho product owner, bạn sẽ nói rõ ràng và không đổ lỗi thế nào?
• Luyện tư duy đánh đổi: Blue-green hay canary? Terraform hay Pulumi? Jenkins hay GitHub Actions? Đánh đổi là gì?

Chuẩn bị tốt nhất là kinh nghiệm, nhưng kịch bản mô phỏng cũng gần tương đương. Suy ngẫm về câu chuyện của bạn, và nếu chưa có nhiều, hãy tham khảo dự án mã nguồn mở, case study hoặc bài lab.

Kết luận

DevOps không chỉ là một chức danh hào nhoáng. Đó là một tư duy. 

Không phải chuyện học thuộc lệnh hay liệt kê công cụ trong CV. Mà là thể hiện cách bạn suy nghĩ, hợp tác và xây dựng hệ thống không sụp đổ khi đối mặt thực tế.

Trong hướng dẫn này, chúng ta đã đi từ câu hỏi nền tảng đến kiến trúc nâng cao, từ kiến thức công cụ đến góc nhìn hành vi. Nếu bạn đọc đến đây, bạn đã đi trước vì đa số ứng viên không chuẩn bị có cấu trúc đến vậy.

Nhưng đừng dừng lại ở đây:

• Hãy xây dựng thứ gì đó.
• Cố tình làm hỏng thứ gì đó.
• Viết về nó.
• Chia sẻ với người khác.
• Suy ngẫm về điều đã sai — và bạn sẽ sửa thế nào lần tới.

DevOps thiên về thực hành hơn là lý thuyết. Hãy nhớ điều đó khi phỏng vấn. Luôn giải thích quy trình suy nghĩ và tập trung vào trải nghiệm của chính bạn. 

Nếu bạn muốn các hướng dẫn thực hành, đừng bỏ lỡ Azure DevOps Tutorial. 

Chúc bạn may mắn trong các buổi phỏng vấn, hy vọng hướng dẫn này hữu ích cho bạn.