30 Câu hỏi và đáp án phỏng vấn DevOps năm 2026

DevOps thực sự có ý nghĩa gì với bạn?

DevOps là một văn hóa và tập hợp các thực hành giúp rút ngắn khoảng cách từ lúc viết code đến khi vận hành ổn định trên production, bằng cách tự động hóa pipeline và chia sẻ trách nhiệm giữa đội phát triển và vận hành. DevOps hướng đến việc phát hành nhanh, an toàn và có thể lặp lại — không phải là tên của một công cụ cụ thể.

Họ đang đánh giá: câu trả lời về văn hóa và thực hành, không phải danh sách công cụ

CI/CD là gì và một pipeline tốt cần làm được những gì?

CI (continuous integration) tự động build và kiểm thử code sau mỗi thay đổi; CD (continuous delivery/deployment) tự động đưa code đến hoặc vào production. Một pipeline tốt phát hiện vấn đề sớm, luôn thực hiện cùng một quy trình và biến việc release thành hoạt động ổn định, dễ rollback.

Họ đang đánh giá: khả năng tự động hóa build, test và deploy — chứ không chỉ biết viết tắt

Container giải quyết vấn đề gì?

Container đóng gói ứng dụng cùng mọi thứ cần thiết để chạy, nhờ đó ứng dụng hoạt động nhất quán trên mọi máy và loại bỏ vấn đề “máy tôi chạy được”. Khả năng tái tạo này giúp quá trình triển khai dễ dự đoán hơn và môi trường nhất quán từ laptop đến production.

Họ đang đánh giá: hiểu khả năng tái tạo môi trường và lý do điều đó quan trọng

Container khác máy ảo (virtual machine) như thế nào?

VM ảo hóa toàn bộ một máy, bao gồm cả hệ điều hành riêng, nên nặng hơn và khởi động chậm hơn. Container chia sẻ kernel của hệ điều hành trên host và chỉ cô lập ứng dụng, vì vậy nhẹ và khởi động nhanh. Container đánh đổi một phần khả năng cô lập để đạt hiệu quả tốt hơn nhiều.

Họ đang đánh giá: kiến thức nền tảng thường khiến ứng viên thiếu chuẩn bị bị lúng túng

Version control là gì và bạn sử dụng branching như thế nào?

Version control theo dõi các thay đổi của code theo thời gian và cho phép cả nhóm làm việc cùng nhau mà không ghi đè lên phần của người khác. Branching giúp bạn phát triển một tính năng trong phạm vi riêng, sau đó merge trở lại — thường thông qua một branch tồn tại ngắn hạn và pull request được review trước khi merge.

Họ đang đánh giá: mức độ thành thạo Git cơ bản và quy trình làm việc hợp lý

Docker image khác container như thế nào?

Image là template tĩnh đã được build — một bản thiết kế. Container là một instance đang chạy của image đó. Bạn build một image một lần và có thể chạy nhiều container từ image ấy, tương tự mối quan hệ giữa một class và các instance của nó.

Họ đang đánh giá: hiểu sự khác biệt giữa thời điểm build và thời điểm runtime

“Idempotent” nghĩa là gì và tại sao nó quan trọng trong automation?

Một thao tác idempotent cho cùng một kết quả dù được chạy một lần hay nhiều lần. Điều này quan trọng vì automation và quá trình deploy thường được retry; các bước idempotent có thể chạy lại an toàn sau lỗi mà không tạo bản sao hoặc gây drift.

Họ đang đánh giá: khả năng chạy lại an toàn — một khái niệm cốt lõi trong vận hành

Hãy mô tả những gì xảy ra từ lúc git push đến khi code chạy trên production.

Lệnh push kích hoạt CI, hệ thống build code, chạy test và tạo artifact hoặc image. Nếu mọi bước đều đạt, pipeline sẽ deploy — thường lên staging trước rồi đến production — bằng chiến lược như rolling hoặc canary, với health check xác nhận thành công trước khi chuyển traffic.

Họ đang đánh giá: khả năng hiểu toàn bộ delivery pipeline từ đầu đến cuối

Infrastructure as Code là gì và tại sao nên dùng thay cho việc thiết lập thủ công?

IaC định nghĩa server, network và service trong các file được quản lý bằng version control, thay vì thao tác qua console. Cách này giúp hạ tầng có thể tái tạo, review và nhất quán giữa các môi trường, đồng thời loại bỏ tình trạng drift và vấn đề “không ai nhớ hệ thống này được thiết lập thế nào”.

Họ đang đánh giá: khả năng tái tạo, version control và drift

Bạn quản lý secret và configuration giữa các môi trường như thế nào?

Tuyệt đối không đưa secret vào code — hãy dùng environment variable, secrets manager hoặc vault — và inject chúng trong thời điểm deploy. Configuration thay đổi theo từng môi trường thông qua các nguồn config riêng, nhờ đó cùng một artifact có thể chạy ở mọi nơi với các thiết lập khác nhau.

Họ đang đánh giá: mức độ trưởng thành về bảo mật; một phương án thực tế có giá trị hơn câu trả lời chung chung

Kubernetes làm gì và khi nào bạn thực sự cần đến nó?

Kubernetes điều phối container trên nhiều máy — lập lịch, mở rộng, tự phục hồi và kết nối mạng cho chúng. Bạn cần Kubernetes khi vận hành nhiều service ở quy mô lớn và cần các khả năng đó; với một ứng dụng nhỏ, đây thường là giải pháp quá phức tạp so với những lựa chọn đơn giản hơn.

Họ đang đánh giá: hiểu orchestration và biết tránh over-engineering

Làm thế nào để triển khai không downtime?

Khởi chạy các instance mới song song với instance cũ, chờ health check và readiness check đạt yêu cầu, sau đó chuyển traffic sang instance mới rồi loại bỏ instance cũ — theo cách rolling hoặc blue-green. Điều quan trọng là không bao giờ định tuyến traffic đến một instance chưa được xác nhận là healthy.

Họ đang đánh giá: rolling deploy, health check và readiness probe

Bạn monitoring những gì trên production và thiết lập alert cho điều gì?

Hãy monitoring các tín hiệu phản ánh trải nghiệm người dùng — tỷ lệ lỗi, độ trễ, traffic và mức bão hòa — cùng với tình trạng của hệ thống. Chỉ alert cho những vấn đề cần con người xử lý, vì alert mọi thứ sẽ tạo ra nhiễu và khiến cảnh báo quan trọng bị bỏ qua.

Họ đang đánh giá: sự khác biệt giữa thu thập dữ liệu và có tín hiệu thực sự hữu ích để hành động

Hãy giải thích sự khác nhau giữa triển khai blue-green và canary.

Blue-green chạy hai môi trường đầy đủ và chuyển toàn bộ traffic từ môi trường cũ sang môi trường mới cùng lúc, đồng thời cho phép rollback ngay bằng cách chuyển ngược lại. Canary đưa phiên bản mới đến một tỷ lệ nhỏ traffic trước, theo dõi rồi tăng dần. Canary giới hạn phạm vi ảnh hưởng; blue-green đơn giản hơn nhưng mang tính “tất cả hoặc không gì cả”.

Họ đang đánh giá: hiểu các đánh đổi giữa những chiến lược release và biết khi nào nên dùng từng cách

Những khái niệm Terraform cốt lõi nào bạn sử dụng hằng ngày?

Bạn viết resource trong các file config, chạy plan để xem trước thay đổi và apply để thực hiện. State theo dõi những gì thực sự tồn tại, module đóng gói các thành phần có thể tái sử dụng, còn remote backend lưu state để cả nhóm chia sẻ một nguồn sự thật duy nhất một cách an toàn.

Họ đang đánh giá: state, module, remote backend và plan/apply

Load balancer hoạt động như thế nào và tại sao cần nó?

Load balancer phân phối traffic đi vào giữa nhiều instance của service và định tuyến tránh các instance không khỏe thông qua health check. Bạn cần nó để tăng tính sẵn sàng và khả năng mở rộng — không instance nào trở thành nút thắt hoặc điểm lỗi duy nhất.

Họ đang đánh giá: phân phối traffic, health check và tính sẵn sàng

Horizontal scaling khác vertical scaling như thế nào?

Vertical scaling nâng cấp một máy mạnh hơn (thêm CPU/RAM); horizontal scaling bổ sung thêm máy. Horizontal scaling mở rộng tốt hơn và tăng khả năng dự phòng nhưng đòi hỏi ứng dụng phải stateless; vertical scaling đơn giản hơn nhưng có giới hạn và vẫn tồn tại một điểm lỗi duy nhất.

Họ đang đánh giá: chiến lược mở rộng và trường hợp áp dụng của từng cách

Một Kubernetes pod bị kẹt ở trạng thái CrashLoopBackOff. Hãy trình bày cách bạn debug.

Tôi sẽ dùng describe pod để xem event, sau đó kiểm tra log nhằm tìm nguyên nhân crash — thường là config sai, thiếu biến môi trường, dependency lỗi hoặc health check không đạt. Tôi xử lý từ triệu chứng rồi mở rộng dần: vấn đề nằm ở image, config, readiness probe hay một thành phần mà ứng dụng cần nhưng không tồn tại?

Họ đang đánh giá: quy trình triage có hệ thống: describe, log, event — không đoán mò

Terraform apply thất bại giữa chừng. Bạn sẽ làm gì?

Terraform ghi lại trong state những gì đã hoàn tất, vì vậy tôi sẽ đọc lỗi, kiểm tra state để biết chính xác điều gì đã thay đổi và khắc phục nguyên nhân gốc — thường là vấn đề dependency hoặc quyền truy cập — rồi chạy lại apply để hệ thống tiến về desired state. Tôi tránh chỉnh sửa thủ công vì có thể khiến state và thực tế bị lệch nhau.

Họ đang đánh giá: hiểu state và bình tĩnh khôi phục sau thay đổi dang dở

Bạn thiết kế CI/CD pipeline cho một team release nhiều lần mỗi ngày như thế nào?

Cần các bài test nhanh và chạy song song để phản hồi sớm, các gate rõ ràng trước khi merge, deploy tự động với rollback dễ dàng và đủ khả năng self-service để kỹ sư không phải chờ tôi. Mục tiêu là biến việc release thành hoạt động an toàn, thường nhật, trong đó pipeline phát hiện vấn đề thay vì phụ thuộc vào một người kiểm duyệt thủ công.

Họ đang đánh giá: chạy song song, gate, rollback và self-service

Hãy kể về một sự cố bạn gây ra hoặc xử lý, cùng với post-mortem.

Tôi sẽ trình bày một trường hợp cụ thể: điều gì hỏng, chúng tôi phát hiện ra sao, khôi phục service thế nào và — quan trọng nhất — post-mortem không quy trách nhiệm đã tìm ra nguyên nhân gốc cùng những thay đổi giúp ngăn sự cố lặp lại. Bài học và biện pháp phòng ngừa quan trọng hơn việc đổ lỗi.

Họ đang đánh giá: mức độ senior; khả năng chịu trách nhiệm với thất bại và học hỏi từ đó

Bạn xử lý configuration drift trong hạ tầng như thế nào?

Quản lý mọi thứ thông qua Infrastructure as Code để desired state được định nghĩa và version control, phát hiện drift bằng cách so sánh state thực tế với state mong muốn, rồi reconcile bằng cách apply lại thay vì sửa tay. Cách khắc phục là biến thay đổi thủ công thành ngoại lệ, không phải quy trình thường xuyên.

Họ đang đánh giá: khả năng phát hiện và reconcile

Terraform chạy trong CI/CD của bạn như thế nào và ai phê duyệt apply?

Thông thường pipeline tự động chạy plan khi có thay đổi và đăng diff để review; apply chỉ chạy sau khi được phê duyệt, thường bị giới hạn trong protected branch hoặc một bước thủ công. Nhờ vậy, thay đổi hạ tầng được review và audit thay vì chạy tùy tiện từ laptop của một người.

Họ đang đánh giá: tích hợp pipeline và kiểm soát thay đổi

Bạn thiết kế observability như thế nào để vấn đề xuất hiện trước khi người dùng nhận ra?

Kết hợp metrics, log và trace, đồng thời alert trên các chỉ báo sớm — độ trễ hoặc tỷ lệ lỗi tăng, tài nguyên gần bão hòa — chứ không chỉ khi hệ thống đã hỏng hoàn toàn. Dashboard tốt và alert có ý nghĩa giúp bạn nhìn thấy sự suy giảm đang hình thành và hành động trước khi nó trở thành outage.

Họ đang đánh giá: metrics, log, trace và alert có ý nghĩa

Bạn bảo mật container image và supply chain của nó như thế nào?

Bắt đầu từ một trusted base image tối giản, chỉ cài những gì cần thiết, scan image để tìm lỗ hổng đã biết trong pipeline, pin dependency và chạy container bằng user không có quyền root theo nguyên tắc least privilege. Mục tiêu là tạo ra attack surface nhỏ, rõ ràng và được cập nhật thường xuyên.

Họ đang đánh giá: base image tối giản, scan và least privilege

Đang là 3 giờ sáng. CPU của một service tăng vọt và request bị timeout. Hãy trình bày cách bạn xử lý.

Trước tiên là ổn định hệ thống: kiểm tra dashboard và các thay đổi gần đây; nếu deploy gây ra sự cố, hãy rollback. Sau đó chẩn đoán — đây là traffic tăng đột biến, một đoạn code xử lý quá nhiều, dependency chậm hay rò rỉ tài nguyên? Tôi sẽ giảm thiểu tác động để khôi phục service (scale out, giảm tải hoặc rollback), cập nhật tình hình và dành việc tìm nguyên nhân gốc chi tiết cho post-mortem.

Họ đang đánh giá: khả năng triage bình tĩnh, có cấu trúc dưới áp lực

Hãy thiết kế chiến lược deploy và rollback cho một service thanh toán tuyệt đối không được mất dữ liệu.

Sử dụng rollout an toàn như canary hoặc blue-green với health check, làm cho các thao tác idempotent để retry không dẫn đến tính phí hai lần, đồng thời bảo đảm thay đổi database tương thích ngược để rollback không bị lỗi khi phiên bản cũ và mới chạy đồng thời. Rollback phải tức thì và an toàn cho dữ liệu, không phải xử lý trong tình trạng hỗn loạn.

Họ đang đánh giá: độ tin cậy, idempotency và rollback an toàn trong điều kiện ràng buộc nghiêm ngặt

Hãy xây dựng workflow deploy self-service để 80 kỹ sư không cần đến bạn cho mọi lần release.

Cung cấp một pipeline chuẩn theo “paved path” với các guardrail — test tự động, gate và thiết lập mặc định an toàn — để các team tự deploy mà không cần chuyên môn sâu về platform. Vai trò của tôi chuyển sang xây dựng và duy trì platform đó, thay vì trở thành nút thắt thủ công trong mọi lần release.

Họ đang đánh giá: tư duy platform; khả năng tự đưa mình ra khỏi luồng công việc trọng yếu

Một thay đổi config gây suy giảm dây chuyền trên nhiều region. Bạn phản ứng và ngăn sự cố lặp lại như thế nào?

Trước tiên rollback thay đổi để ngăn tình hình xấu thêm, sau đó điều tra vì sao một config có thể làm nhiều region ngừng hoạt động. Biện pháp phòng ngừa gồm rollout config theo từng giai đoạn (không áp dụng toàn cầu cùng lúc), giới hạn blast radius và validation trước khi thay đổi được lan truyền — thay đổi config cần được đối xử cẩn trọng như một code deploy.

Họ đang đánh giá: tư duy về blast radius và khả năng phòng ngừa sau sự cố

Hãy thiết kế hệ thống monitoring và on-call cho một hệ thống mà mỗi phút downtime đều gây thiệt hại tài chính.

Xác định SLO rõ ràng, chỉ alert cho những vấn đề đe dọa SLO để đội on-call không bị nhấn chìm trong nhiễu và thiết lập quy trình escalation thực sự hiệu quả. Bổ sung redundancy để giảm các điểm lỗi duy nhất và luyện tập quy trình xử lý sự cố, nhờ đó khi có lỗi, đội ngũ phản ứng theo quy trình đã chuẩn bị thay vì ứng biến.

Họ đang đánh giá: SLO, kỷ luật alert và escalation