Cloud DevOps Engineer (Azure/AWS & Red Hat)

Object storage lưu file dạng đối tượng truy cập qua HTTP API, dung lượng gần như không giới hạn và rẻ; block storage là ổ đĩa gắn vào máy ảo; file storage là ổ mạng dùng chung qua NFS/SMB.

• Object: ảnh, video, backup, data lake, static website. Không sửa một phần file được, phải ghi đè cả object.
• Block (EBS, Managed Disk, Persistent Disk): ổ hệ điều hành, database tự quản; độ trễ thấp.
• File (EFS, Azure Files, Filestore): nhiều máy cùng đọc ghi một thư mục.

Hay sai: để bucket public để tiện chia sẻ. Nên giữ bucket private, chia sẻ bằng presigned URL hoặc CDN có kiểm soát.

User đại diện cho một người hoặc ứng dụng với credential dài hạn; role là tập quyền được "đội" tạm thời và cấp credential ngắn hạn tự hết hạn.

• Ứng dụng chạy trên cloud nên dùng role gắn vào máy ảo, container, function (instance profile, managed identity, service account).
• CI/CD ngoài cloud dùng OIDC federation để lấy token ngắn hạn, không cần key cố định.
• Áp dụng least privilege: chỉ cấp đúng action trên đúng resource.
• Bật MFA cho người dùng, hạn chế dùng tài khoản root.

Access key trong code dễ lộ qua Git, log, image; một khi lộ thì dùng được tới khi bị thu hồi.

Người phỏng vấn muốn nghe: policy cụ thể, tránh "Action": "*".

Serverless hợp với tải không đều, xử lý theo sự kiện, đội nhỏ không muốn vận hành server; trả tiền theo lượng dùng.

Hợp:

• Xử lý file khi upload, webhook, cron job, API lưu lượng thấp hoặc thất thường.

Cân nhắc:

• Cold start làm tăng độ trễ request đầu.
• Giới hạn thời gian chạy, bộ nhớ, kích thước gói.
• Tải cao và đều thì container/VM thường rẻ hơn.
• Kết nối DB: nhiều instance mở nhiều connection, cần connection pooler hoặc proxy.
• Khó debug và test cục bộ hơn.

Người phỏng vấn muốn nghe: quyết định dựa trên đặc điểm tải và chi phí, không chọn vì "đang hot".

CrashLoopBackOff nghĩa là container khởi động rồi thoát liên tục; cần tìm lý do nó thoát.

kubectl describe pod <pod>      # events, exit code, OOMKilled?
kubectl logs <pod> --previous   # log của lần chạy trước khi chết
kubectl get events --sort-by=.lastTimestamp

• Exit code 137 / OOMKilled: thiếu memory limit hoặc rò rỉ bộ nhớ.
• Lỗi cấu hình: thiếu biến môi trường, Secret/ConfigMap sai, không kết nối được DB.
• Liveness probe quá gắt khiến app bị kill khi đang khởi động; cân nhắc startupProbe.
• Sai lệnh command/args, sai kiến trúc image (arm64 và amd64).

Người phỏng vấn muốn nghe: quy trình có thứ tự, dựa vào events và log trước khi đoán.

Readiness quyết định Pod có nhận traffic không; liveness quyết định có restart container không; startup probe tạm hoãn hai probe kia cho tới khi app khởi động xong.

• Readiness fail: Pod bị gỡ khỏi endpoint của Service, không bị restart.
• Liveness fail: kubelet restart container.
• Startup probe hợp với app khởi động chậm (JVM, nạp model).

Lỗi hay gặp:

• Liveness kiểm tra cả DB bên ngoài: DB chậm là toàn bộ Pod bị restart dây chuyền.
• Không có readiness: rolling update đẩy traffic vào Pod chưa sẵn sàng, gây lỗi 5xx.

Người phỏng vấn muốn nghe: liveness chỉ nên kiểm tra chính process còn sống, phần phụ thuộc để cho readiness.

Load balancer tầng 4 phân phối theo IP/port (TCP/UDP), không đọc nội dung; tầng 7 hiểu HTTP nên định tuyến được theo path, host, header.

• L7 (ALB, Application Gateway, HTTP(S) LB): định tuyến /api và /web tới các nhóm khác nhau, kết thúc TLS, gắn WAF, hợp web/API.
• L4 (NLB, Azure Load Balancer): độ trễ thấp, thông lượng cao, giao thức không phải HTTP (game, MQTT, DB proxy), cần IP tĩnh.
• Cả hai đều có health check để loại máy hỏng.

Hay sai: health check trỏ vào trang nặng hoặc phụ thuộc DB, khiến LB loại hết máy khi DB chậm.

Bắt đầu từ dữ liệu chi phí, không đoán: xem Cost Explorer/Cost Management theo dịch vụ, region, tag và theo ngày để tìm điểm tăng.

Thủ phạm hay gặp:

• Tài nguyên quên tắt: máy dev, ổ đĩa, snapshot, IP tĩnh không gắn máy.
• Data transfer: traffic ra Internet, qua NAT Gateway, giữa AZ/region.
• Log và metric ghi quá nhiều, giữ quá lâu.
• Auto scaling không co lại.

Tối ưu: right-sizing, Savings Plans/Reserved cho tải nền ổn định, spot cho việc chịu ngắt quãng, lifecycle policy chuyển dữ liệu cũ sang lớp lưu trữ rẻ.

Người phỏng vấn muốn nghe: gắn tag bắt buộc và đặt budget alert để phát hiện sớm.

Trình bày theo luồng request và nói rõ điểm lỗi đơn được loại bỏ ở đâu.

• Biên: DNS, CDN cho nội dung tĩnh, WAF.
• Ứng dụng: load balancer L7 trước nhóm container/VM stateless trải nhiều AZ, auto scaling theo CPU hoặc số request.
• Dữ liệu: DB quản lý sẵn Multi-AZ, read replica cho đọc nhiều, Redis làm cache và session.
• Bất đồng bộ: queue cho việc nặng (gửi mail, xử lý ảnh).
• Vận hành: IaC, backup tự động có thử khôi phục, giám sát và alert theo SLO.

Người phỏng vấn muốn nghe: đánh đổi chi phí. 99.9% thường đủ với một region nhiều AZ; multi-region đắt và phức tạp hơn nhiều.

State là file Terraform ghi lại ánh xạ giữa code và tài nguyên thật; Terraform dựa vào nó để tính plan. Mất hoặc lệch state là nguy cơ tạo trùng hoặc xoá nhầm tài nguyên.

• Lưu state ở remote backend (S3, GCS, Azure Blob, Terraform Cloud), bật versioning và mã hoá.
• Bật locking để hai người không apply cùng lúc.
• Tách state theo môi trường/thành phần để giảm phạm vi ảnh hưởng.
• Không commit state lên Git: trong đó có thể chứa secret.
• Chạy plan trong CI cho mỗi PR, apply qua pipeline có duyệt.

Hay sai: sửa tay trên console rồi quên, tạo drift; nên định kỳ chạy plan để phát hiện.

Trả lời thật nhưng hướng về phía trước: nói điều bạn đang tìm kiếm, không kể xấu nơi cũ.

Lý do chấp nhận được: muốn thử thách mới, muốn làm sản phẩm, dự án kết thúc, công ty tái cấu trúc, thu nhập chưa tương xứng (nói khéo).

Câu mẫu: "Em đã làm 2 năm ở dự án outsourcing, học được nhiều về quy trình và làm việc với khách nước ngoài. Giờ em muốn gắn bó lâu dài với một sản phẩm để thấy được tác động của những gì mình làm, và vị trí bên mình đúng hướng đó."

Hay sai: chê sếp, chê đồng nghiệp, kể chuyện drama. Người phỏng vấn sẽ nghĩ bạn cũng sẽ nói về công ty họ như vậy. Nếu nhảy việc nhiều, chuẩn bị lời giải thích cho từng lần.