DevOps / Platform Engineer

Trả lời đúng ít nhất 3/4 câu để đánh dấu đã qua chặng này.

1. Câu 1/4·Cơ bảnKhi deploy, orchestrator gửi SIGTERM rồi 30 giây sau gửi SIGKILL. Vì sao app nên xử lý SIGTERM?

   Kernel bỏ qua SIGTERM với process không chạy bằng root nên phải gửi lạiSIGTERM bắt được để xử lý nốt request đang chạy và đóng kết nối, còn SIGKILL thì khôngXử lý SIGTERM làm process khởi động lại tại chỗ thay vì dừngSIGKILL đến trước nên handler SIGTERM chỉ cần flush file log
2. Câu 2/4·Cơ bảnMột script chạy curl -sf "$URL" | jq .version > version.txt và vẫn chạy tiếp dù curl lỗi. Điều gì khiến lỗi đó dừng script?

   set -x, in từng lệnh trước khi chạy để thấy được lỗiThêm 2>/dev/null để lỗi của curl không bao giờ tới jqBọc dòng lệnh trong $( ) để bắt output lỗi vào một biếnset -euo pipefail, để lệnh nào trong pipeline lỗi cũng làm script thất bại
3. Câu 3/4·Cơ bảnBạn đã trỏ A record sang server mới, nhưng vài người dùng vẫn vào server cũ suốt nhiều giờ. Vì sao?

   Thay đổi DNS chỉ có hiệu lực sau khi reboot server gốcTrình duyệt bỏ qua A record và phân giải qua CNAMEWeb server cũ vẫn trả lời truy vấn DNS cho domainResolver cache bản ghi cũ cho tới khi hết TTL
4. Câu 4/4·Cơ bảnNgay sau một lần deploy, người dùng báo không truy cập được site. Thứ tự debug hiệu quả nhất là gì?

   Đọc log ứng dụng trước, vì phần lớn lỗi bắt đầu từ codeXóa cache trình duyệt và thử trên vài trình duyệt trước tiênRestart load balancer trước rồi xem lỗi có hết khôngDNS bằng dig, rồi kết nối TCP, rồi TLS bằng openssl s_client, rồi HTTP

Trả lời đúng ít nhất 3/4 câu để đánh dấu đã qua chặng này.

1. Câu 1/4·Cơ bảnSau khi chạy git reset --hard HEAD~3 bạn nhận ra vẫn cần các commit đó. Làm sao lấy lại?

   Không làm gì được, vì reset --hard xóa vĩnh viễn commitChạy git revert HEAD~3 để khôi phục ba commit đã mấtTìm commit cũ trong git reflog rồi reset hoặc tạo branch tại đóChạy git stash pop, vì reset đã stash các commit bị bỏ
2. Câu 2/4·Cơ bảnVì sao team deploy nhiều lần mỗi ngày thường chọn trunk-based development thay vì GitFlow?

   Trunk-based development bỏ được nhu cầu code review và CITrunk-based nghĩa là push thẳng lên main, không có branch hay PRBranch ngắn hạn được merge thường xuyên giữ main luôn deploy được và tránh merge lớn, đau đầuGitFlow không dùng được với GitHub hay GitLab
3. Câu 3/4·Cơ bảnMột tính năng cần ba tuần để làm, nhưng team muốn merge vào main mỗi ngày. Cách nào hợp với trunk-based development?

   Merge từng phần nhỏ sau một feature flag vẫn tắt với người dùngLàm trên một fork và merge fork về khi hoàn tấtMerge vào main mỗi ngày nhưng bỏ qua CI cho phần chưa xongGiữ một feature branch dài hạn và rebase lên main mỗi tuần
4. Câu 4/4·Cơ bảnHai PR đều pass CI khi chạy riêng, nhưng main bị vỡ khi cả hai được merge. Điều gì ngăn chuyện này?

   Merge queue kiểm mỗi PR trên main mới nhất cộng các PR xếp trước nóBắt buộc hai reviewer approve cho mọi pull requestDùng squash merge thay cho merge commit với mọi PRBắt buộc mọi commit trên main được ký bằng key đã xác minh

Trả lời đúng ít nhất 3/4 câu để đánh dấu đã qua chặng này.

1. Câu 1/4·Cơ bảnVề mặt kỹ thuật, một container đang chạy là gì?

   Một process được cô lập bằng namespace, giới hạn bằng cgroup và dùng chung kernel của hostMột file nén mà Docker daemon giải nén rồi giả lậpMột máy ảo nhẹ có kernel riêng và một hypervisor nhỏMột chroot jail khởi động init system và driver phần cứng riêng
2. Câu 2/4·Cơ bảnVới một image Node, mỗi lần đổi code là cài lại toàn bộ dependency. Dockerfile copy cả repo rồi mới chạy npm ci. Cách sửa là gì?

   Đổi base image sang Alpine để bước cài đặt nhanh hơnCopy package.json và lockfile trước, chạy npm ci, rồi mới copy phần source còn lạiBuild với --no-cache để mọi layer luôn được build lại từ đầuChuyển npm ci vào entrypoint của container để chạy lúc khởi động
3. Câu 3/4·Cơ bảnMột bản build Docker cần token npm riêng. Cách nào giữ token không lọt vào image và history của nó?

   BuildKit secret mount, RUN --mount=type=secret,id=npm ...Copy file .npmrc chứa token rồi xóa ở RUN kế tiếpĐưa sẵn token vào một base image dùng chung cho mọi bản buildTruyền bằng ARG NPM_TOKEN rồi unset ở một instruction sau
4. Câu 4/4·Cơ bảnVì sao deploy image theo tag latest là rủi ro?

   Registry tự động xóa image latest sau một ngàyImage gắn tag latest luôn được build kèm debug symbolTag này thay đổi được, nên các môi trường có thể âm thầm chạy image khác nhauKubernetes từ chối pull mọi image gắn tag latest

Trả lời đúng ít nhất 3/4 câu để đánh dấu đã qua chặng này.

1. Câu 1/4·Trung cấpVì sao nên build image một lần rồi promote đúng image đó từ staging lên production?

   Cluster production không pull được image do CI runner buildRegistry tính tiền theo lượt build nên build một lần rẻ hơn rõ rệtStaging và production cần cùng biến môi trường được đóng sẵn trong imageThứ đã được test chính là thứ được deploy, không lệch do build lại
2. Câu 2/4·Trung cấpMột workflow GitHub Actions deploy lên AWS bằng access key lưu trong repository secrets. Cải tiến được khuyến nghị là gì?

   Rotate access key bằng tay sáu tháng một lần và vẫn để trong secretsLưu key thành biến môi trường trên self-hosted runnerĐưa key vào file workflow, mã hóa base64 cho an toànDùng OIDC để assume một IAM role và lấy credential ngắn hạn cho mỗi lần chạy
3. Câu 3/4·Trung cấpVì sao nên pin action bên thứ ba theo full commit SHA thay vì tag như @v4?

   Tag thay đổi được, nên repo bị chiếm quyền có thể trỏ tag sang code độc hạiGitHub chặn action tham chiếu theo tag trong repo publicSHA làm workflow nhanh hơn vì action không cần tải vềTag chỉ phân giải được với action do chính GitHub phát hành
4. Câu 4/4·Trung cấpMột workflow kích hoạt bằng pull_request_target checkout code PR từ fork rồi chạy npm test. Rủi ro là gì?

   Workflow không thấy code của PR nên test luôn passCode không tin cậy từ fork chạy với quyền truy cập secrets và token có quyền ghiCache dependency phình to và làm chậm các workflow khácPR từ fork không kích hoạt được event này nên không có gì chạy

Trả lời đúng ít nhất 3/4 câu để đánh dấu đã qua chặng này.

1. Câu 1/4·Trung cấpMột Lambda function chỉ đọc object từ một S3 bucket. Thiết lập IAM nào tuân theo least privilege?

   Execution role chỉ cho phép s3:GetObject trên object của bucket đóAccess key của một IAM user lưu trong biến môi trường của functionAdministratorAccess trong lúc phát triển, siết lại trước khi ra mắtGắn managed policy AmazonS3FullAccess vào execution role
2. Câu 2/4·Trung cấpVì sao đặt database RDS trong private subnet phía sau tầng ứng dụng?

   Private subnet giúp không cần cấu hình security groupRDS chỉ hỗ trợ Multi-AZ khi đặt trong private subnetPrivate subnet cho database nhiều IOPS hơn public subnetNó không có route từ internet, nên chỉ resource bên trong VPC mới truy cập được
3. Câu 3/4·Trung cấpHóa đơn cho thấy phí NAT gateway cao do các instance trong private subnet tải file lớn từ S3 cùng region. Cách sửa nào đúng?

   Chuyển instance sang public subnet và gán public IPNâng NAT gateway lên instance type lớn hơn có nhiều băng thông hơnBật S3 Transfer Acceleration cho bucket đang được tảiThêm S3 gateway VPC endpoint để lưu lượng đó đi vòng qua NAT gateway
4. Câu 4/4·Trung cấpVì sao chạy production trong một Availability Zone duy nhất là vấn đề?

   Security group chỉ có tác dụng khi trải qua nhiều AZAWS tính thêm phí cho resource nằm trong một AZDatabase trong một AZ không thể backup đượcSự cố ở AZ đó làm sập toàn bộ dịch vụ

Trả lời đúng ít nhất 3/4 câu để đánh dấu đã qua chặng này.

1. Câu 1/4·Trung cấpVì sao lưu Terraform state trong remote backend có locking?

   Các bản Terraform gần đây không còn hỗ trợ state cục bộCác lần apply đồng thời không làm hỏng state, và cả team dùng chung một nguồn sự thậtRemote state giúp plan không cần gọi API của cloud providerLocking mã hóa mọi giá trị bí mật trong file state
2. Câu 2/4·Trung cấpAi đó đổi một EC2 instance do Terraform quản lý từ t3.small sang t3.large trên console. Lần terraform apply tiếp theo sẽ ra sao?

   Terraform tự ghi thay đổi trên console ngược vào các file .tfKhông có gì, vì Terraform chỉ so sánh resource tạo ở lần chạy gần nhấtApply sẽ lỗi cho tới khi có người xóa và tạo lại instanceTerraform phát hiện drift và đổi instance về đúng giá trị trong code
3. Câu 3/4·Trung cấpVì sao nên chia Terraform state theo service và môi trường thay vì một state cho tất cả?

   Mỗi provider chỉ cấu hình được một lần trong một file stateNó giới hạn blast radius, để một lần apply sai không đụng tới mọi resourceState nhỏ cho phép các thay đổi nhỏ bỏ qua code review an toànTerraform giới hạn cứng 100 resource cho mỗi file state
4. Câu 4/4·Trung cấpBạn muốn chặn pull request tạo ra S3 bucket đọc công khai. Bước kiểm tra nên chạy ở đâu?

   Trong script audit hằng tuần quét AWS account đang chạyTrong CloudWatch alarm báo động sau khi bucket đã tồn tạiTrong README của module, nhắc người đóng góp cẩn thậnTrên code hoặc plan trong CI bằng Checkov, Trivy hoặc OPA/Conftest, trước khi apply

Trả lời đúng ít nhất 3/4 câu để đánh dấu đã qua chặng này.

1. Câu 1/4·Trung cấpVì sao liveness probe không nên kiểm database?

   Kubelet chặn mọi probe dùng cổng databaseKiểm database chỉ được phép đặt trong startup probeKhi database chậm, mọi pod đều fail liveness và bị restart dây chuyềnLiveness probe không được phép mở kết nối mạng ra ngoài
2. Câu 2/4·Trung cấpMột HPA đặt mục tiêu 70% CPU nhưng pod không bao giờ scale dù tải nặng. Container không khai báo CPU request. Vì sao?

   HPA tính utilization theo phần trăm của request, nên thiếu request thì không có mốc để soPod không có CPU limit bị loại khỏi metrics serverHPA chỉ scale theo memory trừ khi đã cài KEDAHPA bỏ qua Deployment và chỉ scale StatefulSet theo CPU
3. Câu 3/4·Trung cấpKhi Argo CD quản lý cluster, CI nên phát hành phiên bản ứng dụng mới thế nào?

   Chạy kubectl apply lên production ở bước cuối pipelineSSH vào node và pull image mới bằng tayCập nhật image tag trong config repo và để Argo CD sync thay đổiXóa pod đang chạy để chúng khởi động lại với image mới nhất
4. Câu 4/4·Trung cấpVì sao commit manifest Kubernetes Secret lên Git là không an toàn, dù giá trị trông như đã bị xáo trộn?

   Giá trị chỉ được mã hóa base64, ai cũng giải ngay đượcKubelet không đọc được Secret đã từng nằm trong Git historyGit nén file và làm hỏng giá trị secret đã mã hóaBase64 là mã hóa thật nhưng key lại nằm chung repo

Trả lời đúng ít nhất 3/4 câu để đánh dấu đã qua chặng này.

1. Câu 1/4·Trung cấpVì sao nên cảnh báo theo burn rate của error budget trên nhiều cửa sổ thời gian thay vì ngưỡng CPU?

   Nó chỉ gọi on-call khi người dùng bị ảnh hưởng đủ nhanh để đe dọa SLOSeries burn rate tốn ít dung lượng hơn nhiều so với metric CPUPrometheus exporter không thu thập được metric CPUCảnh báo burn rate bắn thường xuyên hơn nên không sót sự cố nào
2. Câu 2/4·Trung cấpMột developer thêm label user_id vào counter http_requests_total. Điều gì xảy ra?

   Số series tăng theo từng người dùng, làm phình bộ nhớ, chi phí và thời gian queryPrometheus tự gộp mọi người dùng vào một seriesGrafana ẩn label mới nên thực tế không có gì thay đổiCounter bị chuyển thành histogram có bucket cho từng người dùng
3. Câu 3/4·Trung cấpMột cảnh báo cho thấy lỗi 500 tăng vọt. Cách nhanh nhất để đi từ một dòng log lỗi tới lời gọi downstream bị chậm là gì?

   Dùng trace_id trong dòng log có cấu trúc để mở trace tương ứngGrep log của mọi service tìm các dòng cùng timestampRestart service rồi theo dõi log trực tiếp chờ lỗi tiếp theoNâng log level lên debug và đợi đợt tăng vọt kế tiếp
4. Câu 4/4·Trung cấpĐiều gì làm một postmortem thực sự cải thiện độ tin cậy?

   Timeline thật dài đính kèm mọi tin nhắn chat trong sự cốNêu tên kỹ sư gây ra sự cố để không ai lặp lạiAction item có người phụ trách, được theo dõi tới khi xong, tập trung vào hệ thống thay vì con ngườiCông bố cho toàn công ty trong vòng một giờ sau khi xử lý xong

Trả lời đúng ít nhất 3/4 câu để đánh dấu đã qua chặng này.

1. Câu 1/4·Nâng caoTeam ký mọi image bằng cosign, nhưng trong cluster không có gì verify chữ ký. Việc này bảo vệ production được bao nhiêu?

   Hoàn toàn, vì Kubernetes mặc định verify chữ ký cosignRất ít, vì image chưa ký hoặc bị sửa vẫn chạy đượcHoàn toàn, vì log Rekor chặn pull image chưa kýMột phần, vì registry từ chối push image chưa ký
2. Câu 2/4·Nâng caoMột AWS access key đã bị commit và push. Bạn đã xóa nó ở commit kế tiếp. Bạn còn phải làm gì?

   Squash hai commit để key biến mất khỏi historyThu hồi và rotate key ngay, rồi kiểm log xem có bị lạm dụng khôngChuyển repo sang private để không ai xem được historyKhông cần gì thêm, vì commit mới nhất đã không còn key
3. Câu 3/4·Nâng caoMột lần scan tìm ra 2.000 CVE trên các image. Bạn nên ưu tiên xử lý thế nào?

   Chỉ theo điểm CVSS, cao nhất trước, bất kể ngữ cảnhTheo thứ tự chữ cái tên package để dễ theo dõi tiến độTạm dừng mọi bản sửa cho tới khi scanner được chỉnh về không còn findingTheo khả năng bị khai thác thật, dùng EPSS và danh sách CISA KEV, cùng mức phơi nhiễm trong hệ thống
4. Câu 4/4·Nâng caoĐâu là cách hợp lý để áp dụng SLSA cho các build pipeline?

   Nhảy thẳng lên mức cao nhất cho mọi repo cùng lúcNâng mức đảm bảo của build từng bậc, bắt đầu từ việc tạo provenanceCài nó như một vulnerability scanner chạy trong mỗi CI jobChỉ áp dụng cho dự án open source, không cho service nội bộ

Trả lời đúng ít nhất 3/4 câu để đánh dấu đã qua chặng này.

1. Câu 1/4·Nâng caoVì sao nên vận hành internal developer platform như một sản phẩm?

   Nó có người dùng, nên mức độ sử dụng và hài lòng quyết định nó có tạo ra giá trị khôngTư duy sản phẩm giúp bỏ qua bước phỏng vấn developerNó cho phép platform team áp đặt mọi lựa chọn công cụ trong công tySản phẩm có thể tính phí ngược cho team khác như cost center riêng
2. Câu 2/4·Nâng caoBạn ra mắt một service template có sẵn CI/CD và observability. Làm sao để các team dùng nó?

   Thông báo một lần qua email toàn công ty rồi coi như xongChặn deploy với mọi service không tạo từ templateĐể golden path là tùy chọn nhưng đủ tốt để các team tự chọnCài hàng chục plugin Backstage để portal trông đầy đủ
3. Câu 3/4·Nâng caoMột deployment vLLM autoscale theo CPU, nhưng latency tăng vọt khi GPU đã bão hòa mà CPU vẫn thấp. Tín hiệu nào nên dùng để scale?

   CPU utilization của container với ngưỡng mục tiêu thấp hơnMức dùng memory trung bình của node trên cả clusterSố namespace đang chạy workloadĐộ dài hàng đợi request hoặc số request đang chờ trên mỗi replica
4. Câu 4/4·Nâng caoMột agent AIOps truy cập hạ tầng qua các MCP server. Thiết lập mặc định an toàn là gì?

   Quyền ghi chỉ trong giờ hành chính khi kỹ sư đang onlineKhông ghi log để output nhạy cảm không bị lưu ở đâu cảQuyền chỉ đọc, cần người duyệt cho mọi thao tác ghi, và audit log cho mọi hành độngQuyền admin để agent xử lý sự cố mà không phải chờ người