Dev Tooling & DevOps cơ bản: Git + Docker + CI/CD + Maven/Gradle + Kubernetes (Fresher Backend — VPBank)

Mảng này KHÔNG đòi hỏi fresher biết vận hành thực tế Jenkins/K8s. Interviewer ngân hàng chỉ cần thấy: (1) bạn dùng Git thành thạo ở mức làm việc nhóm, (2) hiểu đúng khái niệm Docker/CI/CD/Maven, (3) có ý thức về quy trình kiểm soát thay đổi và bảo mật — thứ ngân hàng coi trọng hơn cả kỹ năng tool.

1. Danh sách chủ đề con theo độ ưu tiên

Ưu tiên CAO (phải trả lời trôi chảy)

• Git cơ bản: clone / add / commit / push / pull, status / log / diff; khái niệm working directory → staging area → repository.
• Branch & làm việc nhóm: tạo branch, checkout/switch, feature branch workflow, Git Flow ở mức khái niệm (main/develop/feature/hotfix).
• Merge vs Rebase (mức khái niệm, không cần thuộc lệnh nâng cao) + giải quyết merge conflict — gần như chắc chắn bị hỏi qua câu "làm nhóm gặp conflict xử lý sao?".
• Pull Request & code review: vì sao mọi thay đổi phải qua PR — đây là điểm ngân hàng cực kỳ quan tâm (kiểm soát thay đổi, audit).
• git fetch vs git pull — câu hỏi phân loại kinh điển.
• Docker khái niệm: image vs container, Dockerfile là gì, vì sao dùng Docker (nhất quán môi trường dev/UAT/prod, đóng gói dependency).
• CI/CD là gì: pipeline build → test → deploy; Jenkins ở mức "công cụ chạy pipeline tự động"; vì sao ngân hàng cần approval và tách môi trường.
• Maven cơ bản: pom.xml, dependency, lifecycle clean → compile → test → package → install; mvn package tạo ra file JAR.
• Quản lý config/secret: Spring profiles (dev/uat/prod), vì sao KHÔNG commit mật khẩu DB/API key vào Git, .gitignore.

Ưu tiên TRUNG BÌNH

• git stash, git revert vs git reset (khái niệm: revert an toàn cho branch chung, reset chỉ dùng local).
• Commit message tử tế, atomic commit (mỗi commit một mục đích).
• Docker cơ bản thực hành: docker build / run / ps / logs, port mapping -p 8080:8080, biến môi trường -e.
• Gradle so với Maven (khái niệm: cùng mục đích build tool, Gradle dùng Groovy/Kotlin DSL, build nhanh hơn nhờ cache — biết tồn tại là đủ).
• GitHub Actions (nếu đồ án có dùng — nói được flow YAML: on push → build → test).
• Unit test trong pipeline: vì sao test fail thì pipeline dừng (quality gate).
• Artifact repository (Nexus/Artifactory) ở mức "nơi lưu JAR/image đã build" — chỉ cần biết khái niệm.

Ưu tiên THẤP (biết khái niệm 1–2 câu là đủ, đừng đầu tư sâu)

• Kubernetes/OpenShift: chỉ cần nói được "container orchestration là gì" — tự động deploy, scale, restart container; OpenShift là bản K8s doanh nghiệp của Red Hat mà nhiều ngân hàng dùng. KHÔNG cần biết Pod/Service/Ingress chi tiết.
• docker-compose: chạy nhiều container cùng lúc (app + DB) bằng 1 file YAML.
• Git tag & release: đánh dấu version (v1.0.0), dùng khi release.
• Blue-green / canary deployment: nghe qua để không ngơ ngác, không cần trình bày.

2. Câu hỏi phỏng vấn khả năng cao + hướng trả lời

Câu 1. Em dùng Git thế nào trong project nhóm? Gặp conflict thì xử lý ra sao?

Hướng trả lời:

• Mô tả workflow thật của nhóm: mỗi người làm trên feature branch riêng tách từ main/develop, làm xong tạo Pull Request, thành viên khác review rồi mới merge.
• Trước khi push, luôn git pull (hoặc git fetch + merge) để cập nhật code mới nhất, giảm khả năng conflict.
• Khi gặp conflict: Git đánh dấu vùng xung đột bằng <<<<<<< HEAD ... ======= ... >>>>>>>; mở file, đọc hiểu cả hai phía thay đổi, chọn/kết hợp code đúng, xoá marker, chạy lại app/test để chắc chắn không vỡ, rồi git add + commit.
• Điểm quan trọng: nếu conflict ở phần code của người khác, trao đổi với người đó thay vì tự đoán — chọn sai phía có thể xoá mất logic của đồng đội.

Ý ăn điểm: kể một conflict CỤ THỂ từng gặp trong đồ án (ví dụ hai người cùng sửa một service). Góc ngân hàng: nhấn mạnh "vì vậy em hiểu tại sao ngân hàng bắt buộc mọi thay đổi qua PR + review — code chạm đến tiền và dữ liệu khách hàng thì không ai được tự ý sửa trực tiếp trên nhánh chính".

Lỗi cần tránh: trả lời "nhóm em push thẳng lên main" (báo động đỏ); giải conflict bằng cách "chọn Accept All Current Changes" máy móc; không test lại sau khi resolve.

Câu 2. git merge khác git rebase như thế nào?

Hướng trả lời:

• merge: gộp hai nhánh, tạo một merge commit mới; lịch sử giữ nguyên dạng phân nhánh — an toàn, không viết lại lịch sử.
• rebase: "nhấc" các commit của nhánh mình đặt lại lên đầu nhánh đích → lịch sử thẳng, sạch, nhưng viết lại commit (commit hash thay đổi).
• Quy tắc vàng: không rebase nhánh đã push chung với người khác — vì viết lại lịch sử làm lệch repo của đồng đội. Rebase chỉ dùng cho nhánh cá nhân trước khi tạo PR.
• Thực tế nhóm em dùng merge qua PR cho an toàn; rebase để dọn lịch sử local.

Ý ăn điểm: nói được "golden rule of rebase". Góc ngân hàng: lịch sử Git là một phần audit trail — ngân hàng cần truy vết ai sửa gì, khi nào; nên môi trường ngân hàng thường ưu tiên merge (giữ nguyên lịch sử) trên nhánh chung.

Lỗi cần tránh: nói "rebase tốt hơn merge" chung chung; không biết rebase viết lại lịch sử; lẫn rebase với revert.

Câu 3. git fetch khác git pull chỗ nào?

Hướng trả lời:

• git fetch: tải commit mới từ remote về local (cập nhật origin/main), chưa động vào code đang làm — an toàn, chỉ để xem có gì mới.
• git pull = fetch + merge (hoặc + rebase nếu cấu hình): vừa tải vừa gộp ngay vào nhánh hiện tại — tiện nhưng có thể sinh conflict bất ngờ.
• Thói quen tốt: đang code dở thì fetch trước để xem thay đổi (git log origin/main), chủ động chọn thời điểm merge.

Ý ăn điểm: công thức "pull = fetch + merge" + nói được vì sao fetch an toàn hơn. Lỗi cần tránh: trả lời "giống nhau"; nói fetch làm thay đổi working directory.

Câu 4. Pull Request là gì? Vì sao phải code review, tự merge không được à?

Hướng trả lời:

• PR là yêu cầu gộp code từ feature branch vào nhánh chính, kèm mô tả thay đổi; người khác review, comment, approve rồi mới merge.
• Lợi ích: bắt bug sớm, thống nhất coding convention, chia sẻ kiến thức (ít nhất 2 người hiểu đoạn code), và tạo bằng chứng kiểm soát — ai viết, ai duyệt.
• Nhánh chính thường được protect: cấm push trực tiếp, bắt buộc PR + approve + CI pass.

Ý ăn điểm — góc ngân hàng: đây là yêu cầu tuân thủ (compliance), không chỉ là thói quen tốt. Với hệ thống xử lý giao dịch tiền, một dòng code sai có thể gây sai lệch số dư; ngân hàng cần chứng minh với kiểm toán rằng không một thay đổi nào vào production mà không qua ít nhất một người duyệt (nguyên tắc four-eyes / maker-checker — giống như giao dịch viên nhập lệnh phải có kiểm soát viên duyệt).

Lỗi cần tránh: coi review là "hình thức, mất thời gian"; không biết branch protection tồn tại.

Câu 5. Docker là gì? Khác máy ảo (VM) chỗ nào? Image khác container chỗ nào?

Hướng trả lời:

• Docker đóng gói ứng dụng cùng toàn bộ môi trường chạy (JDK, thư viện, config) thành một đơn vị chạy được ở bất kỳ đâu có Docker → giải quyết "trên máy em chạy được mà".
• Khác VM: VM ảo hoá cả phần cứng, mỗi VM chở nguyên một hệ điều hành riêng → nặng (GB), khởi động phút. Container dùng chung kernel với máy chủ, chỉ cô lập process/filesystem/network → nhẹ (MB), khởi động giây, một máy chạy được nhiều container.
• Image vs container: image là bản đóng gói bất biến (như file .class hoặc bản thiết kế); container là instance đang chạy của image (như object được new từ class). Một image chạy ra nhiều container.
• Ví dụ Dockerfile cho Spring Boot:

FROM eclipse-temurin:17-jre
WORKDIR /app
COPY target/myapp.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

Ý ăn điểm: phép so sánh class/object cho image/container; nói "cùng một image được test ở UAT chính là thứ chạy ở prod". Góc ngân hàng: ngân hàng có nhiều môi trường (dev → SIT → UAT → prod); Docker đảm bảo thứ đã kiểm thử là thứ được deploy, loại bỏ rủi ro "prod cấu hình khác UAT" — rủi ro vận hành lớn với hệ thống giao dịch.

Lỗi cần tránh: nói "Docker là máy ảo nhẹ" rồi dừng lại (phải nói được điểm khác cốt lõi: chung kernel); lẫn lộn image và container; nói Docker "tự động scale" (đó là việc của Kubernetes).

Câu 6. Vì sao dự án của em (hoặc ngân hàng) nên dùng Docker thay vì cài trực tiếp lên server?

Hướng trả lời:

• Nhất quán môi trường: dev dùng JDK 17, server lỡ cài JDK 11 → lỗi khó hiểu; Docker khoá cứng môi trường trong image.
• Cô lập: nhiều service chạy chung một máy không giẫm chân nhau về thư viện, port, version.
• Triển khai nhanh & rollback dễ: deploy = kéo image version mới chạy lên; lỗi thì chạy lại image version cũ.
• Là nền cho CI/CD và Kubernetes: pipeline build ra image, đẩy vào registry, các môi trường chỉ việc kéo về.

Ý ăn điểm — góc ngân hàng: rollback nhanh bằng image cũ chính là một phần của rollback plan mà quy trình change management ngân hàng bắt buộc phải có trước mỗi lần release. Lỗi cần tránh: chỉ nói "Docker phổ biến nên dùng"; không nêu được lợi ích cụ thể nào.

Câu 7. CI/CD là gì? Vì sao ngân hàng cần pipeline tự động nhưng lại kiểm soát release rất chặt?

Hướng trả lời:

• CI (Continuous Integration): mỗi lần push/PR, hệ thống tự động build + chạy test → phát hiện lỗi tích hợp sớm, code trên nhánh chính luôn ở trạng thái build được.
• CD (Continuous Delivery/Deployment): tự động hoá đóng gói và triển khai; Delivery = sẵn sàng deploy nhưng cần người bấm nút, Deployment = tự deploy luôn.
• Pipeline điển hình: checkout code → build (mvn package) → unit test → build Docker image → push registry → deploy dev → deploy UAT (test) → APPROVAL → deploy prod.
• Jenkins: công cụ CI/CD phổ biến trong ngân hàng, pipeline định nghĩa bằng Jenkinsfile; tương tự GitHub Actions/GitLab CI.
• Nghịch lý bề ngoài "tự động nhưng chặt" thực ra hợp lý: tự động để loại lỗi con người (build/test/deploy giống hệt nhau mọi lần, có log đầy đủ), kiểm soát để tuân thủ: deploy prod cần approval của cấp có thẩm quyền, thường vào khung giờ ít giao dịch, có rollback plan; dev không có quyền deploy thẳng production — người viết code và người phê duyệt release là khác nhau (segregation of duties).

Ý ăn điểm: phân biệt Delivery/Deployment + nói được vì sao ngân hàng thường dừng ở Delivery (con người approve bước cuối). Nhắc "mọi lần deploy đều được log lại phục vụ audit". Lỗi cần tránh: nói CI/CD chỉ là "deploy tự động" (bỏ quên phần test); nói "tự động thì bỏ luôn approval cho nhanh" — ngược triết lý ngân hàng.

Câu 8. Trong pipeline, nếu unit test fail thì chuyện gì xảy ra? Vì sao?

Hướng trả lời:

• Pipeline dừng ngay (fail fast), code không được merge/deploy; dev nhận thông báo, sửa rồi push lại.
• Test đóng vai trò quality gate: chặn lỗi ở cửa rẻ nhất — sửa bug ở CI tốn vài phút, bug lọt lên production của ngân hàng có thể gây sai giao dịch, phải đối soát, thậm chí báo cáo sự cố.
• Vì thế mvn package mặc định chạy test trước khi đóng gói; cờ -DskipTests chỉ dùng khi thật sự hiểu mình đang làm gì.

Ý ăn điểm: cụm "fail fast" và "quality gate". Góc ngân hàng: một bug tính lãi sai lọt qua vì "skip test cho nhanh" là ví dụ tốt để nói về chi phí của lỗi. Lỗi cần tránh: trả lời "thì skip test đi ạ".

Câu 9. Maven dùng để làm gì? mvn package thực hiện những bước nào?

Hướng trả lời:

• Maven là build tool: quản lý dependency (tự tải JAR từ Maven Central về local repository ~/.m2), chuẩn hoá cấu trúc project, và tự động hoá build theo lifecycle.
• pom.xml khai báo thông tin project + dependency:

<project>
  <groupId>com.example</groupId>
  <artifactId>banking-demo</artifactId>
  <version>1.0.0</version>
  <dependencies>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
  </dependencies>
</project>

• Lifecycle chạy tuần tự các phase trước đó: mvn package = validate → compile (biên dịch source) → test (chạy unit test, fail thì dừng) → package (đóng gói JAR/WAR vào target/).
• Các phase liên quan: clean xoá target/; install copy JAR vào local repo; deploy đẩy lên remote repo (Nexus). Gradle là lựa chọn tương đương, dùng script Kotlin/Groovy, build nhanh hơn nhờ incremental build — khái niệm giống nhau.

Ý ăn điểm: nói rõ "package tự chạy compile và test trước" — nhiều fresher không biết lifecycle là chuỗi tích luỹ. Góc ngân hàng: dependency được khai báo tường minh trong pom.xml giúp kiểm soát phiên bản thư viện và lỗ hổng bảo mật (ví dụ sự cố Log4j — ngân hàng phải rà soát mọi pom.xml để biết hệ thống nào dính). Lỗi cần tránh: nói Maven chỉ là "chỗ tải thư viện"; không biết JAR nằm ở target/; lẫn phase với plugin/goal (không cần sa đà — nắm phase là đủ).

Câu 10. Em deploy đồ án của em như thế nào? (gần như chắc chắn bị hỏi khi khai thác project trong CV)

Tình huống A — đã từng dùng Docker/cloud (kể trung thực theo mức đã làm):

• "Em build bằng mvn package ra file JAR, viết Dockerfile đóng gói cùng JRE 17, docker build ra image rồi chạy docker run -p 8080:8080. Database em chạy bằng container PostgreSQL riêng (hoặc docker-compose gộp app + DB). Sau đó em đưa lên [Render/Railway/EC2...], cấu hình connection string qua biến môi trường chứ không hardcode."
• Nếu có GitHub Actions: "mỗi lần push lên main, Actions tự build + test, pass mới deploy."
• Chốt: "Em hiểu đây là bản đơn giản; ở ngân hàng sẽ có thêm UAT, approval, và em sẽ không có quyền tự deploy prod — em thấy điều đó hợp lý vì hệ thống chạm đến tiền của khách."

Tình huống B — chưa từng deploy thật (trả lời trung thực + chứng minh hiểu khái niệm):

• "Đồ án của em mới chạy ở local: mvn spring-boot:run, DB MySQL cài trên máy. Em chưa deploy lên server thật, nhưng em đã tìm hiểu quy trình: build JAR bằng mvn package, viết Dockerfile để đóng gói, chạy container và map port; nếu có thời gian em sẽ thử trên một VPS hoặc dịch vụ free-tier."
• "Em cũng hiểu tại sao cần tách config theo môi trường — local em dùng application-dev.properties, còn thông tin kết nối prod phải nằm ngoài code."
• Chốt bằng thái độ: "Đây là phần em biết mình còn thiếu và đang chủ động bù — em đã viết thử Dockerfile cho đồ án tuần trước."

Ý ăn điểm: trung thực + cho thấy hiểu bức tranh (build → đóng gói → cấu hình → chạy) dù chưa làm hết; câu chốt về quy trình ngân hàng ở cả hai tình huống. Lỗi cần tránh: nói dối đã dùng Kubernetes/AWS rồi bị hỏi sâu và vỡ trận (interviewer ngân hàng rất hay đào tiếp); trả lời cụt lủn "em chưa deploy bao giờ" mà không thể hiện đã tìm hiểu.

Câu 11. Em quản lý cấu hình và mật khẩu DB trong project thế nào? Có commit vào Git không?

Hướng trả lời:

• Tuyệt đối không commit secret (mật khẩu DB, API key, token) vào Git — repo có thể bị lộ, và lịch sử Git giữ vĩnh viễn: xoá ở commit sau thì secret vẫn nằm trong history.
• Cách làm đúng: đọc từ biến môi trường (spring.datasource.password=${DB_PASSWORD}), file config local đưa vào .gitignore, chỉ commit file mẫu application-example.properties.
• Tách cấu hình theo môi trường bằng Spring profiles: application-dev.properties, application-uat.properties, application-prod.properties; kích hoạt bằng --spring.profiles.active=prod.
• Nếu lỡ commit secret: coi như đã lộ → đổi mật khẩu/key ngay, không chỉ xoá file.

Ý ăn điểm — góc ngân hàng: đây là lỗi bảo mật kinh điển của fresher và là câu interviewer ngân hàng dùng để lọc ý thức bảo mật. Nói thêm: ở ngân hàng, dev thậm chí không được biết mật khẩu DB production — secret do team vận hành quản lý qua vault/secret manager, app nhận lúc runtime. Lỗi cần tránh: "em để trong application.properties và push lên GitHub luôn ạ" — trả lời thật thà kiểu này mà không kèm "giờ em biết đó là sai và cách sửa là..." sẽ mất điểm nặng.

Câu 12. Jenkins là gì? Em đã dùng bao giờ chưa?

Hướng trả lời:

• Jenkins là automation server mã nguồn mở chạy pipeline CI/CD: lắng nghe sự kiện (push code, tạo PR, lịch định kỳ) → tự chạy chuỗi bước build/test/deploy định nghĩa trong Jenkinsfile.
• Trả lời trung thực: "Em chưa vận hành Jenkins thực tế, nhưng em đã dùng GitHub Actions cho đồ án — về bản chất giống nhau: file cấu hình khai báo các bước, trigger theo sự kiện push. Em tin chuyển sang Jenkins chỉ là học cú pháp mới."
• Biết thêm 1 ý: Jenkins phổ biến ở ngân hàng vì self-hosted — chạy trong hạ tầng nội bộ, code và artifact không rời khỏi mạng ngân hàng.

Ý ăn điểm: câu "khái niệm giống GitHub Actions, khác cú pháp" + lý do self-hosted. Lỗi cần tránh: chém đã cấu hình Jenkins master/agent; hoặc hoảng loạn "em không biết gì về Jenkins" rồi im lặng.

Câu 13. Kubernetes/OpenShift là gì? (chỉ cần mức khái niệm)

Hướng trả lời:

• Khi hệ thống có hàng chục service, mỗi service nhiều container, cần công cụ container orchestration: tự động deploy, scale theo tải, tự restart container chết (self-healing), phân bổ container lên nhiều máy, rolling update không downtime.
• Kubernetes (K8s) là chuẩn de-facto; OpenShift là distribution K8s của Red Hat, thêm bảo mật và công cụ quản trị — được nhiều ngân hàng (trong đó có các ngân hàng Việt Nam) chọn vì có hỗ trợ doanh nghiệp và kiểm soát chặt hơn.
• Trung thực về giới hạn: "Em mới hiểu ở mức khái niệm và vai trò của nó sau Docker; em sẵn sàng học khi vào việc."

Ý ăn điểm: liên kết chuỗi Docker → nhiều container → cần orchestration; biết OpenShift là "K8s phiên bản doanh nghiệp". Góc ngân hàng: giờ cao điểm chuyển tiền (lễ Tết, ngày trả lương) hệ thống cần scale nhanh rồi thu lại — đó chính là bài toán K8s giải. Lỗi cần tránh: cố trình bày Pod/Deployment/Service khi không nắm chắc — sa lầy đúng vùng mình yếu nhất.

Câu 14. git revert khác git reset? Lỡ commit sai lên nhánh chung thì làm gì?

Hướng trả lời:

• reset: dịch chuyển nhánh về commit cũ, xoá lịch sử phía sau → chỉ an toàn trên nhánh local chưa push.
• revert: tạo commit mới đảo ngược thay đổi của commit sai → lịch sử được giữ nguyên, an toàn cho nhánh chung.
• Lỡ commit sai đã push lên nhánh chung → dùng revert; không reset + force push vì phá lịch sử của cả team.

Ý ăn điểm — góc ngân hàng: revert giữ nguyên dấu vết "đã có lỗi và đã sửa" — đúng tinh thần audit trail: ngân hàng không xoá lịch sử, kể cả lịch sử sai (giống bút toán kế toán: sai thì ghi bút toán điều chỉnh, không tẩy sổ). Lỗi cần tránh: đề xuất force push lên nhánh chung.

3. Ghi chú chiến thuật trước phỏng vấn

Định vị đúng kỳ vọng. VPBank không kỳ vọng fresher vận hành Jenkins/Kubernetes/OpenShift thực tế — các JD liệt kê chúng là "hiểu biết là lợi thế". Chiến thuật đúng: trả lời khái niệm chính xác, thành thật về giới hạn, và luôn kèm một câu thể hiện tinh thần học ("em đã tự tìm hiểu X, chưa có cơ hội dùng thật, em muốn được học ở môi trường có quy trình chuẩn như ngân hàng"). Interviewer ngân hàng đánh giá cao thành thật + ý thức quy trình hơn là danh sách buzzword.

Sợi chỉ đỏ để lồng vào mọi câu trả lời: ngân hàng = kiểm soát thay đổi (change management) + phân quyền (dev không tự deploy prod) + audit trail (mọi thứ truy vết được) + bảo mật (secret không vào Git). Cứ mỗi câu tooling, gắn được một trong bốn ý này là bạn nổi bật hẳn so với fresher chỉ thuộc định nghĩa.

2–3 việc làm nhanh trước phỏng vấn (1–2 buổi tối):

1. Đưa đồ án lên GitHub cho tử tế: README mô tả cách chạy, commit message rõ nghĩa (feat: add transfer API validation thay vì update, fix bug), tạo ít nhất 1 branch + 1 PR tự merge để có cái mà kể. Kiểm tra kỹ không có password/API key nào trong repo và trong history.
2. Viết 1 Dockerfile cho đồ án Spring Boot (dùng mẫu 5 dòng ở Câu 5), chạy được docker build + docker run -p 8080:8080 trên máy mình. Chỉ 30 phút nhưng biến câu trả lời "em có biết Docker" thành "em đã docker hoá đồ án của em".
3. Nếu từng đụng GitHub Actions: mở lại file workflow YAML, nhớ được flow on: push → jobs: build → steps: checkout, setup-java, mvn package để khi bị hỏi Jenkins có cái quy chiếu; nếu chưa từng, đọc lướt một Jenkinsfile mẫu 15 dòng trên mạng để quen mặt chữ stage('Build'), stage('Test'), stage('Deploy').

Câu thoát hiểm vạn năng khi bị hỏi vượt tầm (K8s networking, Jenkins agent, Helm...): "Phần này em mới dừng ở mức khái niệm là [nói đúng 1–2 câu khái niệm]; em chưa làm thực tế nên không dám nói sâu, nhưng em đã quen cách tự học qua việc [Docker hoá đồ án / dùng Actions], em tin sẽ bắt nhịp nhanh." — vừa trung thực, vừa không để khoảng lặng, vừa chốt bằng điểm mạnh.