Đáp án Quiz CI/CD — 75 câu hỏi có giải thích

Đáp án: C

Gộp code vào nhánh chính thường xuyên (ít nhất mỗi ngày), mỗi lần gộp đều chạy build và test tự động. Cốt lõi là nhánh sống ngắn và phản hồi nhanh, không phải việc cài một công cụ.

Đáp án: A

PATCH (số cuối): 1.4.2 → 1.4.3. Quy tắc: MAJOR khi phá tương thích, MINOR khi thêm tính năng vẫn tương thích, PATCH khi sửa lỗi mà không đổi hành vi công khai.

Đáp án: D

Để thứ đã kiểm chính là thứ chạy thật. Build lại cho từng môi trường có thể ra kết quả khác nhau (dependency đổi, cấu hình build lệch), khiến việc kiểm ở staging mất giá trị.

Đáp án: D

Nguyên tắc fail fast: xếp job theo thứ tự nhanh trước — lint và kiểm kiểu (giây) → unit test (phút) → build → integration → e2e. Lỗi rẻ nhất được phát hiện trước.

Đáp án: B

pnpm install --frozen-lockfile (hoặc npm ci): cài đúng những gì lockfile ghi, và thất bại nếu lockfile không khớp package.json thay vì âm thầm sửa nó.

Đáp án: A

Vài ngày tới vài tuần là đủ cho báo cáo test và log — chúng chỉ có giá trị khi đang điều tra. Riêng artifact đã phát hành (image, package) thì giữ lâu hơn vì cần cho rollback và truy vết.

Đáp án: B

Gộp toàn bộ commit của nhánh thành một commit trên nhánh chính. Lịch sử gọn và mỗi commit là một thay đổi hoàn chỉnh — đổi lại mất các commit nhỏ trong quá trình làm.

Đáp án: C

Dùng chung phần kiểm tra (lint, test, build) để kết quả trên PR đúng bằng kết quả trên nhánh chính, và đặt điều kiện cho phần deploy — chỉ chạy khi nhánh là main (hoặc khi có tag phát hành).

Đáp án: D

Trunk-based giữ nhánh sống rất ngắn (vài giờ tới một ngày) và merge vào nhánh chính liên tục, dùng feature flag để giấu tính năng chưa hoàn thiện. GitFlow duy trì nhiều nhánh dài song song, nên tích hợp bị dồn về cuối và xung đột lớn hơn.

Đáp án: B

Nguyên tắc fail fast: đặt lint, kiểm tra kiểu và unit test ở đầu để lỗi rõ ràng được báo trong vòng một hai phút. Vòng phản hồi ngắn là yếu tố quan trọng nhất quyết định người phát triển có thực sự dùng CI hay không.

Đáp án: B

Canary đưa phiên bản mới tới một tỷ lệ nhỏ lưu lượng thật (ví dụ 5%), theo dõi tỷ lệ lỗi và độ trễ, rồi tăng dần nếu số liệu tốt hoặc quay lui nếu xấu. Phạm vi ảnh hưởng khi có lỗi vì thế nhỏ hơn nhiều so với chuyển toàn bộ cùng lúc.

Đáp án: D

Các yêu cầu phổ biến: bắt buộc pull request (không đẩy thẳng), các job CI bắt buộc phải xanh, có ít nhất một người duyệt, và thường thêm chặn force push cùng chặn xoá nhánh.

Đáp án: B

Matrix sinh ra một job cho mỗi tổ hợp cấu hình đã khai báo — ví dụ ba phiên bản Node nhân hai hệ điều hành thành sáu job chạy song song. Dùng để kiểm chứng ứng dụng hoặc thư viện hoạt động trên mọi phiên bản được hỗ trợ.

Đáp án: B

Kết quả của commit cũ không còn giá trị khi đã có commit mới, nên để nó chạy tiếp chỉ chiếm runner và kéo dài hàng đợi cho cả nhóm. Cấu hình nhóm đồng thời theo nhánh và bật huỷ lần chạy đang dở là cách xử lý chuẩn.

Đáp án: D

Build theo lịch bắt được các hỏng hóc không do mã nguồn: phụ thuộc gián tiếp cập nhật, image nền có bản mới, chứng chỉ hết hạn, dịch vụ bên ngoài đổi hành vi. Cùng một commit hôm qua xanh hôm nay đỏ chính là tín hiệu này.

Đáp án: B

Đặt ở cả hai: hook pre-commit chặn ngay trên máy người phát triển trước khi bí mật vào lịch sử Git; job trong CI bắt các trường hợp hook bị bỏ qua. Bật thêm quét ở phía nền tảng lưu trữ mã nếu có.

Đáp án: C

Tiền tố chuẩn hoá (feat, fix, chore, kèm dấu hiệu phá vỡ tương thích) cho phép công cụ tự tính số phiên bản theo semantic versioning và sinh changelog phân nhóm. Nhờ đó phần phát hành không cần thao tác thủ công.

Đáp án: A

File tài nguyên có hash nội dung trong tên thì cache rất lâu và đánh dấu là bất biến. File HTML điểm vào thì không cache hoặc cache rất ngắn, vì nó chứa tham chiếu tới bộ file mới. Nhờ vậy phát hành mới có hiệu lực ngay mà không cần xoá cache.

Đáp án: D

Nó chặn kiểu suy giảm tích luỹ dần: mỗi pull request thêm một chút và không ai phản đối, nhưng sau vài tháng thời gian tải tăng đáng kể. Cổng kiểm tra làm phần tăng thêm trở nên hiển thị ngay tại pull request gây ra nó.

Đáp án: B

Kiểm tra khác biệt môi trường trước tiên: phiên bản runtime và phụ thuộc, biến môi trường, múi giờ và ngôn ngữ, thứ tự chạy test, và trạng thái còn sót trên máy cá nhân. CI khởi động sạch nên phơi bày những phụ thuộc ngầm mà máy cá nhân che đi.

Đáp án: B

Dùng secret store của CI (GitHub Actions secrets, biến môi trường của nền tảng deploy), tham chiếu qua biến môi trường trong job. Không bao giờ commit secret, kể cả trong repo riêng tư.

Đáp án: C

Mất cache layer: Docker tính lại từ layer bị đổi trở đi, nên sửa một dòng code làm npm install chạy lại từ đầu. Thứ tự đúng: copy package.json + lockfile → install → rồi mới copy phần source còn lại.

Đáp án: A

latest là cái tên di động: nó trỏ vào đâu tuỳ lần push cuối. Khi có sự cố, bạn không biết chính xác code nào đang chạy và không rollback về đúng bản trước được. Tag theo commit SHA hoặc phiên bản.

Đáp án: A

Cache theo hash của lockfile: khoá cache là deps-${hash(pnpm-lock.yaml)}. Lockfile không đổi thì khôi phục cache trong vài giây; đổi thì cache miss và cài lại — đúng lúc cần thiết.

Đáp án: C

Rollback về bản trước rồi mới điều tra. Điều kiện để làm được điều đó nhanh: image được tag bất biến, migration tương thích hai chiều, và rollback là một lệnh đã từng được diễn tập.

Đáp án: D

Chặn merge: lint, kiểm kiểu, unit + integration test — nhanh và tất định. Chạy sau merge hoặc theo lịch: e2e đầy đủ, test hiệu năng, quét bảo mật sâu, build cho nhiều nền tảng.

Đáp án: C

Review được thứ đang chạy thay vì tưởng tượng từ diff — quan trọng nhất với thay đổi giao diện, và cho phép người không đọc code (thiết kế, sản phẩm) góp ý trực tiếp trên bản chạy.

Đáp án: C

Retry có giới hạn (1–2 lần) nhưng phải ghi lại test nào cần retry và bao nhiêu lần. Không có số liệu đó thì flaky tích luỹ âm thầm, và tới lúc CI đỏ ai cũng cho là flaky — kể cả khi là lỗi thật.

Đáp án: B

Máy không sạch giữa các lần chạy: cache, tệp tạm, biến môi trường và cả credential còn sót lại từ job trước. Job này có thể lấy dữ liệu của job khác, và build "chạy được" chỉ vì máy đó đã cài sẵn thứ gì đó.

Đáp án: D

Tách deploy (đưa code lên) khỏi release (bật cho người dùng). Nhờ đó gộp code sớm mà chưa lộ tính năng, bật dần cho một phần người dùng, và tắt ngay khi có sự cố mà không phải rollback.

Đáp án: B

Code do người ngoài viết chạy trong runner của bạn: nếu có secret thì họ in ra được, và có thể lạm dụng tài nguyên CI. Vì thế nền tảng CI mặc định không cấp secret cho workflow từ fork.

Đáp án: C

Multi-stage build: stage đầu cài dependency và build, stage cuối FROM một base gọn rồi chỉ COPY --from kết quả cần chạy. Công cụ build không đi vào image cuối.

Đáp án: D

Ba điều kiện: test đủ tin để merge là deploy được, rollback nhanh đã diễn tập, và giám sát báo được ngay khi lỗi tăng. Thiếu bất kỳ điều nào thì deploy tự động chỉ đẩy lỗi ra production nhanh hơn.

Đáp án: A

Thực dụng nhất là không cho tụt: coverage của PR không được thấp hơn nhánh chính. Nó chặn việc thêm code không test mà không tạo áp lực viết test hình thức để đạt một con số tuyệt đối.

Đáp án: C

Hai thứ nhanh và rõ ràng nhất: quét dependency (lỗ hổng đã biết trong thư viện) và quét secret (khoá bị commit). Cả hai chạy trong giây, ít báo sai, và bắt được đúng loại sự cố hay xảy ra thật.

Đáp án: C

Runner của CI là máy mới mỗi lần nên không có cache cục bộ. Cấu hình cache ngoài máy: --cache-from/--cache-to trỏ vào registry, hoặc dùng cache của nền tảng CI với buildx.

Đáp án: B

Biến môi trường đọc lúc chạy, khai ở nền tảng deploy cho từng môi trường. Nhờ đó một artifact duy nhất chạy được ở mọi nơi, và secret không bao giờ nằm trong repo.

Đáp án: D

Tự gán người review theo đường dẫn tệp trong pull request, và (kèm branch protection) bắt buộc phải có duyệt của chủ sở hữu phần đó. Hữu ích khi repo lớn và không ai nắm hết mọi phần.

Đáp án: C

Quy ước commit message (Conventional Commits): feat:, fix:, refactor:, và ! hoặc BREAKING CHANGE cho thay đổi phá vỡ tương thích. Công cụ nhóm các mục và suy ra được mức tăng phiên bản.

Đáp án: B

Readiness probe: một endpoint kiểm phụ thuộc thiết yếu (kết nối DB, cấu hình đã nạp) và chỉ trả về OK khi sẵn sàng. Load balancer chỉ gửi traffic tới instance pass probe.

Đáp án: B

Thông báo có địa chỉ: người mở PR nhận khi PR của họ đỏ, và nhánh chính đỏ thì báo vào một kênh có người chịu trách nhiệm. Gửi cho tất cả mọi lần đỏ là cách nhanh nhất để không ai đọc nữa.

Đáp án: A

Khai service container Postgres trong job (đúng phiên bản như production), chờ nó sẵn sàng rồi chạy migration và test. Mỗi lần chạy có DB sạch và độc lập với các job khác.

Đáp án: A

Định dạng tự động ở editor (format on save) và pre-commit hook, CI chỉ kiểm lại để chặn trường hợp bỏ qua hook. Khi công cụ quyết định định dạng thì review chỉ còn bàn về logic.

Đáp án: C

Bốn chỉ số DORA: tần suất deploy, thời gian từ commit tới production, tỉ lệ deploy gây lỗi, và thời gian khôi phục. Hai cái đầu đo tốc độ, hai cái sau đo độ ổn định — phải xem cùng nhau.

Đáp án: C

Ba thứ đi cùng nhau: rolling deploy (thay từng phần, luôn còn instance phục vụ), graceful shutdown (xử lý xong request đang chạy trước khi thoát), và migration cộng thêm (bản cũ và mới cùng chạy được trên một schema).

Đáp án: B

Ghim theo commit SHA đầy đủ (uses: actions/checkout@<sha>). Tag là con trỏ di động: nếu tài khoản tác giả bị chiếm, kẻ tấn công trỏ @v4 sang code chèn mã và pipeline của bạn chạy nó với secret.

Đáp án: A

Rủi ro nghiêm trọng nhất là mất hoặc lộ dữ liệu thật: một migration thử, một test xoá dữ liệu, hay một job gửi mail ở staging chạm vào dữ liệu người dùng thật. Hai môi trường phải có DB riêng.

Đáp án: C

Deploy nhỏ hơn, thường xuyên hơn. Nghe phản trực giác nhưng đúng: lô một tháng chứa hàng trăm thay đổi nên khi lỗi không biết cái nào gây ra; lô một ngày thì nguyên nhân gần như hiển nhiên.

Đáp án: C

Vấn đề xung đột ngữ nghĩa: pull request A và B đều xanh trên bản nhánh chính cũ, nhưng khi cả hai vào thì nhánh chính hỏng — ví dụ A đổi tên một hàm còn B thêm chỗ gọi hàm cũ. Merge queue chạy CI trên tổ hợp thực tế trước khi merge.

Đáp án: B

GitOps đảo chiều: thay vì pipeline đẩy thay đổi vào cụm, một tác nhân chạy trong cụm kéo trạng thái mong muốn từ Git và liên tục đối chiếu. Git là nguồn sự thật, và mọi sai lệch so với nó đều được phát hiện.

Đáp án: A

Chia test ra nhiều máy chạy song song cho hiệu quả cao nhất mà không đổi nội dung test. Kèm theo: cache phụ thuộc, chỉ chạy phần bị ảnh hưởng bởi thay đổi, và tách e2e chậm sang tầng chạy sau merge.

Đáp án: C

Cấu hình theo mức rủi ro: gom nhóm các bản vá và nâng cấp nhỏ vào một pull request theo tuần, tách riêng các bản nâng cấp lớn, và ưu tiên xử lý ngay các bản vá bảo mật. Tự động merge chỉ nên áp cho nhóm rủi ro thấp nhất khi đã có bộ test đủ tin cậy.

Đáp án: A

Mặc định là quay lui trước để đưa hệ thống về trạng thái đã biết là tốt, rồi mới điều tra và sửa. Chỉ chọn sửa rồi triển khai tiếp khi việc quay lui không khả thi — ví dụ đã có thay đổi schema không đảo ngược được.

Đáp án: A

Cấp quyền tối thiểu cho từng job: job build chỉ đọc mã, job publish mới có quyền ghi vào registry, job deploy mới có quyền lên môi trường đích. Ưu tiên danh tính liên kết theo phiên thay vì token tĩnh lưu trong kho bí mật.

Đáp án: D

Hai mô hình tuỳ bối cảnh: đồng bộ (mọi package cùng một số phiên bản) hợp khi chúng luôn được dùng cùng nhau; độc lập hợp khi các package có người dùng và vòng đời riêng. Điều bắt buộc ở cả hai là chỉ phát hành package thực sự thay đổi.

Đáp án: D

Nguyên tắc build một lần, phát hành nhiều lần: tạo artifact một lần từ một commit, gắn định danh cố định (digest hoặc mã commit), rồi chuyển chính artifact đó qua staging và production. Cấu hình khác nhau được nạp lúc chạy, không nướng vào artifact.

Đáp án: C

Chốt mức nền bằng cách ghi nhận các cảnh báo hiện có, rồi chặn merge chỉ khi có cảnh báo mới. Nợ cũ được dọn dần theo nguyên tắc chạm đâu dọn đó, thay vì phải dừng phát triển để dọn một lượt.

Đáp án: A

Tách phần chung thành workflow dùng lại được với tham số cho phần khác biệt (phiên bản runtime, lệnh test, môi trường triển khai). Mỗi kho chỉ còn vài dòng gọi tới workflow chung, và việc cập nhật diễn ra ở một nơi.

Đáp án: D

Dựng image đa kiến trúc: build cho từng nền tảng rồi đăng ký một manifest chung dưới một tag. Máy chủ kéo image sẽ tự nhận bản khớp với kiến trúc của nó, nên cấu hình triển khai không cần biết chạy trên loại máy nào.

Đáp án: C

Cache từ xa cho phép dùng lại kết quả build giữa các máy: thứ đã được build trên máy đồng nghiệp hoặc trong một lần chạy CI trước không phải build lại. Điều kiện là khoá cache phải tính từ nội dung đầu vào một cách xác định.

Đáp án: A

Quy trình chuẩn: phát hiện và ghi nhận test không ổn định; cách ly khỏi cổng chặn merge nhưng vẫn chạy và theo dõi; giao chủ sở hữu và thời hạn để sửa; và xoá khỏi cách ly sau khi đã ổn định. Chạy lại tự động là biện pháp tạm, không phải giải pháp.

Đáp án: A

Quan trọng nhất là dọn tự động: xoá môi trường khi pull request đóng hoặc merge, kèm một tiến trình quét các môi trường quá hạn. Không có bước này, chi phí và hạn mức tài nguyên sẽ cạn dần mà không ai để ý.

Đáp án: A

Cấu trúc chuẩn: pull request chạy xem trước thay đổi và đăng kết quả vào phần bình luận để review; sau khi merge thì job áp dụng chạy tự động. Kèm theo là khoá để không hai lần áp dụng chạy đồng thời.

Đáp án: C

maxSurge (số pod được tạo vượt mức mong muốn) quyết định tốc độ, và maxUnavailable (số pod được phép thiếu) quyết định dung lượng tối thiểu còn phục vụ. Đặt maxUnavailable bằng 0 giữ đủ dung lượng nhưng cần chỗ trống trong cụm để tạo pod mới.

Đáp án: B

Hiệu quả nhất là cắt việc không cần làm: chỉ build và test phần bị ảnh hưởng bởi thay đổi, cache phụ thuộc và kết quả build, và huỷ lần chạy cũ khi có commit mới. Sau đó mới tới việc chọn loại máy phù hợp cho từng job.

Đáp án: C

Cần một bản đồ phụ thuộc giữa mã nguồn và test. Trong monorepo, đồ thị giữa các package cho phép suy ra ở mức thô. Chính xác hơn thì dùng dữ liệu độ bao phủ từ các lần chạy trước để biết test nào chạm tới file nào.

Đáp án: B

Sinh đặc tả API ở mỗi lần build rồi so với bản của nhánh chính bằng công cụ chuyên dụng. Công cụ phân biệt được thay đổi tương thích (thêm trường tuỳ chọn) với thay đổi phá vỡ tương thích (xoá trường, đổi kiểu, thêm trường bắt buộc), và chặn merge ở nhóm thứ hai.

Đáp án: C

Chặn ở mức nghiêm trọng cao trở lên cho phụ thuộc chạy ở production, cảnh báo với mức thấp hơn, và có cơ chế ghi nhận ngoại lệ kèm thời hạn và người chịu trách nhiệm. Phụ thuộc chỉ dùng cho phát triển nên tách chính sách riêng.

Đáp án: A

Ghim image nền theo digest để bản dựng tái lập được, rồi có pipeline theo lịch cập nhật digest, dựng lại, chạy bộ test và mở pull request. Nhờ đó bản vá vào hệ thống đều đặn mà vẫn qua kiểm thử.

Đáp án: B

Vấn đề lớn nhất là báo sai do môi trường render: font khác, phiên bản trình duyệt khác, độ phân giải khác đều tạo ra chênh lệch pixel. Cách xử lý: chạy trong container cố định, đặt ngưỡng sai khác, và có quy trình duyệt ảnh chuẩn mới.

Đáp án: A

Mặt trái là dồn thay đổi: sau thời gian đóng băng, lần triển khai đầu tiên mang theo hàng chục thay đổi cùng lúc, nên nếu hỏng thì rất khó biết nguyên nhân và khó quay lui. Đóng băng chuyển rủi ro sang tương lai chứ không loại bỏ nó.

Đáp án: D

Đổi ở tầng cân bằng tải (đổi target group hoặc trọng số): hiệu lực gần như tức thì và quay lui cũng tức thì. Đổi DNS thì phụ thuộc thời gian lan truyền và bộ nhớ đệm của client, nên không dùng cho việc cần đảo ngược nhanh.

Đáp án: A

Chỉ cần vô hiệu hoá các file điểm vào (HTML và các file cấu hình không có hash). Tài nguyên có hash trong tên thì bản mới có đường dẫn khác nên không đụng cache cũ, và việc vô hiệu hoá toàn bộ chỉ tốn phí và dồn tải về máy chủ gốc.

Đáp án: D

Dùng phát hành theo giai đoạn: cửa hàng cho phép mở dần từ vài phần trăm người dùng, theo dõi tỷ lệ lỗi và đánh giá, rồi tăng tiếp hoặc dừng. Đây là biện pháp chính vì bản đã cài trên máy người dùng không thể bị thu hồi.

Đáp án: B

Kiểm tra cấu hình theo schema trong pipeline, và để ứng dụng kiểm tra lại lúc khởi động rồi thoát ngay nếu sai. Lỗi cấu hình phát hiện lúc khởi động tốt hơn nhiều so với phát hiện khi một tính năng cụ thể được gọi tới lần đầu.