SAP Public Cloud Developer (BTP / Integration Suite)

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.

RPO là lượng dữ liệu tối đa chấp nhận mất (tính theo thời gian); RTO là thời gian tối đa để khôi phục dịch vụ. Hai con số này do nghiệp vụ quyết định và định giá chiến lược.

Từ rẻ đến đắt:

• Backup & restore: sao lưu sang region khác, dựng lại khi cần; RTO hàng giờ.
• Pilot light: dữ liệu được replicate liên tục, chỉ phần lõi chạy sẵn.
• Warm standby: bản thu nhỏ chạy sẵn ở region khác, scale lên khi failover.
• Active-active: nhiều region cùng phục vụ; RTO/RPO gần 0, phức tạp nhất.

Hay sai: có backup nhưng chưa bao giờ thử khôi phục. Kế hoạch DR phải được diễn tập định kỳ.

Dùng mô hình landing zone: tách account (AWS), subscription (Azure) hoặc project (GCP) theo môi trường và team để cô lập quyền, chi phí và phạm vi sự cố.

• Quản lý tập trung bằng AWS Organizations, Azure Management Groups, GCP Organization/Folder.
• Áp guardrail ở cấp tổ chức: chặn region không dùng, bắt buộc mã hoá, cấm tắt log audit (SCP, Azure Policy, Organization Policy).
• Đăng nhập tập trung qua SSO, cấp quyền theo nhóm.
• Tài khoản riêng cho log audit và bảo mật, team ứng dụng không xoá được.
• Mạng nối qua hub (Transit Gateway, hub-spoke VNet, Shared VPC).
• Tag bắt buộc để phân bổ chi phí.

Người phỏng vấn muốn nghe: cân bằng giữa tự chủ của team và kiểm soát tập trung.

Multi-cloud có lý do chính đáng nhưng chi phí vận hành rất lớn; cần hỏi rõ mục tiêu trước khi đồng ý.

Lý do hợp lý:

• Yêu cầu pháp lý hoặc khách hàng chỉ định nhà cung cấp.
• Dùng dịch vụ đặc thù tốt nhất của từng bên.
• Công ty sáp nhập, mỗi bên đã dùng một cloud.

Cái giá:

• Đội phải giỏi hai nền tảng, IAM và mạng khác nhau.
• Chi phí truyền dữ liệu giữa cloud.
• Chỉ dùng mẫu số chung, mất lợi thế dịch vụ managed.

Giảm phụ thuộc thường chỉ cần container, Terraform và tránh API độc quyền ở phần lõi.

Người phỏng vấn muốn nghe: biết hỏi "để giải quyết vấn đề gì", không trả lời có/không ngay.

Khác nhau ở chỗ bạn tự quản lý tới tầng nào: IaaS bạn lo từ hệ điều hành trở lên, PaaS bạn chỉ lo code và dữ liệu, SaaS bạn chỉ dùng phần mềm.

• IaaS: máy ảo EC2, Azure Virtual Machines, Compute Engine.
• PaaS: Elastic Beanstalk, Azure App Service, Cloud Run, các DB quản lý sẵn như RDS, Cloud SQL.
• SaaS: email, bộ văn phòng, CRM dùng qua trình duyệt.

Người phỏng vấn muốn nghe: mô hình trách nhiệm chung (shared responsibility). Nhà cung cấp lo hạ tầng vật lý; cấu hình bảo mật, quyền truy cập và dữ liệu vẫn là việc của bạn ở mọi mô hình.

Region là một vùng địa lý; mỗi region có nhiều Availability Zone, là các trung tâm dữ liệu tách biệt về điện, mạng, làm mát nhưng nối với nhau độ trễ thấp.

Để chịu được mất một AZ:

• Chạy ứng dụng ở ít nhất 2 AZ, đứng sau load balancer.
• Dùng Auto Scaling group/managed instance group trải trên nhiều AZ.
• Database bật chế độ Multi-AZ (bản standby ở AZ khác, failover tự động).
• Ứng dụng stateless, session để ở Redis hoặc DB.

Hay sai: đặt NAT Gateway hoặc một thành phần duy nhất ở một AZ, tạo điểm lỗi đơn mà không để ý.

VPC là mạng riêng ảo của bạn trên cloud; subnet chia nhỏ dải IP; tính "public" hay "private" của subnet do route table quyết định.

• Public subnet: route 0.0.0.0/0 tới Internet Gateway; đặt load balancer, bastion.
• Private subnet: không có route trực tiếp ra Internet; đặt app server, database.
• NAT Gateway: nằm ở public subnet, cho máy trong private subnet đi ra Internet (tải package, gọi API) nhưng không cho kết nối từ ngoài vào.
• Security group lọc ở mức instance (stateful); Network ACL lọc ở mức subnet (stateless).

Người phỏng vấn muốn nghe: database không bao giờ đặt ở public subnet, và truy cập quản trị nên đi qua bastion hoặc dịch vụ kiểu Session Manager.

"I'd say my greatest strength is ownership. When I take on a task, I make sure it works end to end, not just that the code is merged. For example, after releasing a new feature, I usually check the logs and metrics for the first few days. Last year this helped me catch a data issue early, before it affected many users."

Mẹo: một điểm mạnh kèm một ví dụ ngắn là đủ. Các từ hay dùng: "ownership", "attention to detail", "problem-solving", "fast learner". Nói "I'd say…" nghe tự nhiên hơn "My strong point is…".

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.