Ngân hàng đề — Google Professional Cloud Architect

🧩 Phân tích nội dung câu hỏi

Đề mô tả một website thông tin công khai, người dùng ẩn danh trên toàn thế giới truy cập, đang chạy trên máy chủ cũ tại on-premises. Có hai vấn đề song song cần giải quyết cùng lúc:

1. Độ trễ truy cập cao — người dùng phàn nàn phản hồi chậm, mà họ nằm rải rác khắp thế giới.
2. Tấn công DDoS đến từ các dải IP luôn giống nhau.

Cụm từ quyết định đáp án nằm ở vế cuối: "prevent the denial-of-service traffic from entering your VPC network". Đây chính là ràng buộc phân biệt các phương án gần giống nhau. Yêu cầu không phải là "chặn được traffic xấu" chung chung, mà là chặn nó trước khi nó chạm vào VPC. Một cụm từ quan trọng nữa là "Anonymous users" — người dùng ẩn danh, không có danh tính để xác thực.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng là D: external HTTP(S) load balancer + Google Cloud Armor + Compute Engine.

• External HTTP(S) load balancer là load balancer toàn cầu, phục vụ từ edge của Google gần người dùng nhất. Đây là câu trả lời trực tiếp cho yêu cầu "improve access latency" với đối tượng người dùng phân tán khắp thế giới.
• Google Cloud Armor hoạt động ngay tại lớp edge, gắn vào backend service của external HTTP(S) load balancer. Traffic bị Cloud Armor từ chối bị chặn ở edge, không bao giờ đi tới VPC — khớp chính xác với ràng buộc "prevent ... from entering your VPC network". Vì đề nói các cuộc tấn công luôn đến từ cùng những dải IP, ta có thể viết security policy chặn theo dải IP nguồn một cách rất trực tiếp.
• Compute Engine là đường di chuyển đơn giản nhất cho một ứng dụng cũ mà management đã đánh giá là "easy, low risk" — lift-and-shift, không cần viết lại hay đóng gói ứng dụng.

❌ Vì sao các phương án còn lại sai

A — GKE + GKE service + network policy. Hỏng ở hai chỗ. Thứ nhất, containerize ứng dụng cũ là công sức lớn, mâu thuẫn với mô tả "easy, low risk migration". Thứ hai, và quan trọng hơn: GKE network policy điều khiển luồng traffic bên trong cluster, tức là traffic đã vào tới VPC rồi mới bị lọc. Nó không đáp ứng yêu cầu chặn trước khi vào VPC, và cũng không phải công cụ chống DDoS.

B — External HTTP(S) load balancer + VPC firewall rules + Compute Engine. Đây là phương án gần đúng nhất và là cái bẫy chính của câu hỏi. Nó đúng phần latency (load balancer toàn cầu) và đúng phần lift-and-shift lên Compute Engine. Chỗ hỏng duy nhất nằm ở lớp bảo vệ: VPC firewall rules chỉ có tác dụng khi gói tin đã đi vào phạm vi VPC. Traffic tấn công vẫn được nhận và xử lý bên trong ranh giới mạng của bạn rồi mới bị drop — trái hẳn với chữ "entering" trong đề. Cloud Armor mới là thứ đứng ở edge, trước VPC.

C — GKE + internal load balancer + IAP. Sai nặng nhất. Internal load balancer chỉ phục vụ traffic nội bộ, không thể để người dùng Internet toàn cầu truy cập — mâu thuẫn thẳng với "public information website". IAP thì dùng để xác thực và ủy quyền từng danh tính người dùng, trong khi đề nói rõ người dùng là anonymous; không có danh tính thì IAP không có gì để kiểm. Cộng thêm chi phí containerize không cần thiết như phương án A.

📌 Điểm cần nhớ

• Cụm "prevent traffic from entering your VPC" là dấu hiệu chỉ thẳng tới Cloud Armor (lọc tại edge), không phải VPC firewall rules (lọc sau khi đã vào VPC). Hai thứ này hay bị đặt cạnh nhau làm mồi nhử.
• Yêu cầu giảm latency cho người dùng toàn cầu trên web HTTP/HTTPS → external HTTP(S) load balancer; Cloud Armor cũng chỉ gắn được vào loại load balancer external này.
• Anonymous users loại trừ mọi giải pháp dựa trên danh tính như IAP. IAP chỉ hợp lý khi ứng dụng có người dùng đã xác thực (nhân viên, đối tác).
• Đề nhấn mạnh migration "easy, low risk" → ưu tiên lift-and-shift lên Compute Engine, không chọn phương án đòi containerize lại ứng dụng cũ.
• Internal load balancer không bao giờ là câu trả lời cho một public website — chỉ riêng từ "internal" đã đủ để loại phương án.

🧩 Phân tích nội dung câu hỏi

Đề đặt bạn vào vai cloud architect lo việc chuyển data warehouse từ on-premises lên Google Cloud. Có ba cụm từ trong đề quyết định đáp án:

• "data warehouse" — không phải database giao dịch (OLTP), không phải kho file thô, mà là hệ phân tích (OLAP) chạy truy vấn tổng hợp trên khối dữ liệu lớn.
• "several petabytes of data" — quy mô petabyte, loại thẳng những dịch vụ vốn không được thiết kế để quét và tổng hợp ở mức đó.
• "frequent, unpredictable spikes in query activity" — tải truy vấn tăng đột biến, không đoán trước được. Đây chính là ràng buộc phân biệt: giải pháp phải tự co giãn theo từng truy vấn, không đòi người vận hành cấp phát trước cluster hay instance.

Ghép ba cụm lại: đề đang hỏi dịch vụ nào vừa lưu petabyte, vừa chạy truy vấn phân tích, vừa tự lo phần compute khi tải nhảy vọt.

✅ Vì sao đáp án đúng là đúng

Đáp án là D — dùng BigQuery cho cả lưu trữ lẫn phân tích.

BigQuery là dịch vụ data warehouse serverless của Google Cloud, tức là đúng loại sản phẩm mà đề mô tả, không phải chắp vá từ nhiều mảnh. Nó tách phần lưu trữ khỏi phần tính toán: dữ liệu nằm trong storage dạng cột được quản lý sẵn, còn khi có truy vấn thì hệ thống tự huy động tài nguyên tính toán để chạy rồi thu lại. Vì phần compute do Google quản lý và cấp phát theo từng truy vấn, những spike bất ngờ được hấp thụ mà kiến trúc sư không phải dự đoán trước, không phải resize cluster, cũng không có bước cấp phát thủ công nào. Đây chính là điều mà cụm "unpredictable spikes" đòi hỏi.

Về quy mô, BigQuery được thiết kế cho kho dữ liệu ở mức petabyte và truy vấn bằng SQL chuẩn — hợp với đội ngũ đang quen data warehouse on-premises. Chọn D còn có một ưu điểm kiến trúc: dữ liệu và bộ máy truy vấn nằm cùng một chỗ, không phải bê dữ liệu qua lại giữa hai dịch vụ trước mỗi lần phân tích.

❌ Vì sao các phương án còn lại sai

A — Cloud Storage lưu dữ liệu, chạy scheduled queries bằng Dataflow. Đây là phương án gần đúng nhất và cũng dễ mắc bẫy nhất: Cloud Storage đúng là chứa được petabyte với chi phí thấp. Chỗ hỏng nằm ở phần truy vấn. Dataflow là engine xử lý luồng/lô dữ liệu (pipeline ETL), không phải công cụ truy vấn tương tác — nó không cho người dùng gõ SQL rồi nhận kết quả ngay. Chữ "scheduled" trong phương án tự tố cáo điều đó: chạy theo lịch thì ngược hẳn với yêu cầu đáp ứng những đợt truy vấn dồn dập, phát sinh bất ngờ. Ngoài ra Cloud Storage là object storage, tự nó không có bảng, không có schema, không có chỉ mục cho phân tích.

B — Bigtable lưu dữ liệu, phân tích bằng Data Studio. Bigtable chứa được lượng dữ liệu rất lớn, nhưng nó là NoSQL wide-column tối ưu cho đọc/ghi theo row key với độ trễ thấp — hợp với time series, IoT, dữ liệu tra cứu theo khoá. Nó không hỗ trợ SQL phân tích và không phù hợp với các truy vấn quét rộng, tổng hợp nhiều chiều vốn là bản chất của data warehouse. Về co giãn, Bigtable dựa trên cụm node phải cấu hình dung lượng, nên spike bất ngờ vẫn là bài toán của người vận hành. Data Studio chỉ là lớp trực quan hoá, nó không thay thế được một engine truy vấn — đặt nó lên trên Bigtable không biến hệ thống thành data warehouse.

C — Cloud SQL lưu dữ liệu, Dataflow phân tích. Sai ở cả hai vế. Cloud SQL là cơ sở dữ liệu quan hệ được quản lý, phục vụ khối lượng công việc giao dịch (OLTP) trên một instance có giới hạn dung lượng và tài nguyên — vài petabyte vượt xa phạm vi thiết kế của nó. Muốn tăng sức chịu tải phải nâng cấp instance thủ công, hoàn toàn ngược với yêu cầu tự co giãn. Vế thứ hai lặp lại đúng lỗi của phương án A: Dataflow không phải công cụ truy vấn phân tích tương tác.

📌 Điểm cần nhớ

• Đề nhắc "data warehouse" + quy mô petabyte + SQL phân tích trên Google Cloud thì gần như luôn là BigQuery; hãy coi đó là mặc định rồi mới xét xem có ràng buộc nào phá vỡ nó không.
• "Unpredictable spikes" là từ khoá đẩy về hướng serverless: chọn dịch vụ tự cấp phát compute theo truy vấn, tránh những dịch vụ đòi cấu hình node/instance trước.
• Phân biệt vai trò cho rõ: Cloud SQL là OLTP; Bigtable là NoSQL tra cứu theo key, độ trễ thấp; Cloud Storage là object storage; Dataflow là pipeline xử lý dữ liệu; Data Studio chỉ trực quan hoá. Không cái nào trong số đó là engine truy vấn phân tích.
• Cảnh giác với phương án ghép "kho rẻ + công cụ xử lý" để giả làm data warehouse: nếu phần truy vấn chạy theo lịch hoặc theo pipeline, nó không đáp ứng được nhu cầu truy vấn tương tác đột biến.

🧩 Phân tích nội dung câu hỏi

Đề mô tả: dữ liệu khách hàng nhạy cảm nằm trong Cloud Storage, cần một giải pháp vừa ngăn truy cập trái phép (prevents unauthorized data access) vừa đảm bảo tuân thủ quy định (ensures regulatory compliance).

Cụm từ quyết định là "both … and …" — đề đòi một phương án phủ cả hai vế cùng lúc, chứ không phải phương án nào hay nhất cho một vế. Vế thứ hai còn siết thêm: compliance với dữ liệu nhạy cảm thường yêu cầu tổ chức tự kiểm soát khoá mã hoá (quyền xoay khoá, thu hồi khoá, chứng minh ai giữ khoá), không chỉ là dữ liệu "có được mã hoá hay không". Cả bốn phương án đều là dịch vụ bảo mật hợp lệ của Google Cloud, nên bài này lọc theo độ phủ chứ không lọc theo đúng/sai kỹ thuật.

✅ Vì sao đáp án đúng là đúng

A — CMEK + IAM fine-grained access control là đáp án đúng vì nó ghép đúng hai lớp tương ứng với hai yêu cầu của đề:

• IAM fine-grained access control trả lời vế "prevents unauthorized data access": đây là lớp cấp phép trực tiếp trên bucket/object của Cloud Storage, quyết định principal nào được đọc, ghi, quản trị. Đây là cơ chế chặn truy cập trái phép ở đúng tầng dữ liệu.
• CMEK trả lời vế "regulatory compliance": Cloud Storage vốn đã mã hoá at-rest, nhưng CMEK cho phép tổ chức tự quản lý vòng đời khoá qua Cloud KMS — xoay khoá, vô hiệu hoá, huỷ khoá. Nhiều khung tuân thủ yêu cầu chính khả năng kiểm soát và chứng minh này, chứ không chấp nhận mã hoá do nhà cung cấp quản lý hoàn toàn.

Kết hợp lại: một lớp kiểm soát ai chạm được dữ liệu, một lớp kiểm soát khoá giải mã dữ liệu — đúng cấu trúc "defense in depth" mà đề đang mô tả.

❌ Vì sao các phương án còn lại sai

B — Cloud Audit Logs. Đây là kiểm soát phát hiện (detective), không phải ngăn chặn (preventive). Audit log ghi lại ai đã truy cập, đọc được sau khi việc đã xảy ra; nó rất có giá trị cho phần compliance (bằng chứng kiểm toán) nhưng không chặn được bất kỳ truy cập trái phép nào. Chỉ phủ nửa vế thứ hai, trượt hoàn toàn vế thứ nhất.

C — Cloud Identity-Aware Proxy (IAP). Đây là phương án sai về mặt kỹ thuật, không chỉ thiếu sót. IAP là lớp kiểm soát truy cập theo ngữ cảnh cho ứng dụng và VM — App Engine, Cloud Run, load balancer trước backend HTTPS, hoặc TCP forwarding tới VM. IAP không phải là cơ chế cấp phép cho các lời gọi trực tiếp vào Cloud Storage API; quyền trên object của Cloud Storage do IAM (và ACL) quyết định. Đặt IAP "để control access to Cloud Storage" là dùng sai dịch vụ.

D — VPC Service Controls. Đây là phương án gần đúng nhất, nên cần nói rõ nó hỏng ở đâu. VPC Service Controls thật sự là kiểm soát preventive: nó dựng service perimeter quanh Cloud Storage để chặn data exfiltration ra ngoài vành đai, kể cả khi kẻ tấn công đã có credential hợp lệ. Nhưng nó là kiểm soát ở tầng mạng/vành đai, hoạt động theo nguyên tắc "request này đến từ trong hay ngoài perimeter" — nó không cấp phép ở mức principal, tức là bên trong perimeter thì ai được đọc object nào vẫn hoàn toàn do IAM quyết định. Đồng thời nó không đụng gì tới quản lý khoá mã hoá, nên vế compliance về kiểm soát khoá bỏ trống. Nó là lớp bổ sung tốt cho A, nhưng đứng một mình thì không đủ cả hai vế.

📌 Điểm cần nhớ

• Câu hỏi có cấu trúc "both A and B" thì phải chọn phương án phủ cả hai yêu cầu; phương án chỉ xuất sắc ở một vế luôn là bẫy.
• Phân biệt preventive (IAM, CMEK, VPC Service Controls) và detective (Cloud Audit Logs). Đề hỏi "prevent" thì logging không bao giờ là đáp án chính.
• Với dữ liệu nhạy cảm và yêu cầu compliance, CMEK là tín hiệu nhận dạng quen thuộc: điểm khác biệt không nằm ở "có mã hoá không" mà ở "ai kiểm soát khoá".
• Nhớ đúng phạm vi từng dịch vụ: IAP dành cho ứng dụng/VM chứ không phải Cloud Storage API; VPC Service Controls chặn theo vành đai chứ không cấp phép theo principal; IAM mới là lớp cấp phép trực tiếp trên object.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một tình huống rất cụ thể: công ty đang replicate MySQL database từ private data center lên GCP để phục vụ disaster recovery, đường truyền hiện tại là Google Cloud VPN, và vấn đề gặp phải là latency issues cùng minor packet loss.

Cụm từ quyết định đáp án là "latency issues and a minor packet loss" khi dùng Cloud VPN. Đây không phải lỗi cấu hình database, cũng không phải lỗi ứng dụng — đó là đặc tính của chính đường truyền. Cloud VPN dựng đường hầm IPsec đi qua public Internet, nên chất lượng đường truyền phụ thuộc vào mạng công cộng: độ trễ biến động và mất gói là chuyện nằm ngoài tầm kiểm soát của bạn. Câu hỏi vì thế đang hỏi: thay hạ tầng kết nối nào để có đường truyền ổn định, riêng biệt?

Một chi tiết phụ nhưng quan trọng: replication của MySQL chạy trên TCP và yêu cầu dòng dữ liệu tin cậy, đúng thứ tự. Điều này loại thẳng phương án đụng đến giao thức.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng là A — Configure a Google Cloud Dedicated Interconnect.

Dedicated Interconnect cung cấp kết nối vật lý trực tiếp giữa mạng on-premises và VPC trên Google Cloud, không đi qua public Internet. Vì lưu lượng không phải chen chúc trên mạng công cộng, đường truyền có độ trễ thấp hơn và ổn định hơn nhiều, đồng thời tránh được phần lớn nguyên nhân gây packet loss vốn đến từ các chặng Internet trung gian.

Đây chính là công cụ Google định vị cho trường hợp cần băng thông cao, ổn định và liên tục giữa data center và cloud — đúng với nhu cầu replication database chạy thường xuyên trong kịch bản disaster recovery. Nó xử lý nguyên nhân gốc (chất lượng đường truyền) chứ không vá triệu chứng.

❌ Vì sao các phương án còn lại sai

B — Restore their database daily using Google Cloud SQL. Phương án này thay hẳn mô hình từ replication liên tục sang khôi phục theo ngày. Hậu quả là RPO (lượng dữ liệu có thể mất) nhảy vọt lên tới cả một ngày làm việc — đi ngược mục tiêu của một disaster recovery plan đang cố giữ bản sao gần thời gian thực. Ngoài ra, việc restore hằng ngày vẫn phải đẩy dữ liệu qua chính đường VPN đang có vấn đề, nên vấn đề mạng không hề được giải quyết.

C — Add additional VPN connections and load balance them. Đây là phương án gần đúng nhất và dễ mắc bẫy: thêm tunnel thì tăng được tổng băng thông, nghe có vẻ hợp lý. Nhưng nó hỏng ở chỗ mọi tunnel đều vẫn chạy trên public Internet. Latency và packet loss sinh ra từ chặng đường Internet, không sinh ra từ việc thiếu tunnel — nhân bản một đường truyền kém chất lượng lên nhiều lần vẫn cho ra chất lượng kém. Tệ hơn, trải một luồng replication qua nhiều đường có độ trễ khác nhau còn dễ gây ra hiện tượng gói đến lệch thứ tự.

D — Configure their replication to use UDP. Sai về bản chất kỹ thuật. UDP không có cơ chế truyền lại gói bị mất và không đảm bảo thứ tự — nghĩa là packet loss sẽ chuyển thẳng thành dữ liệu hỏng hoặc thiếu trong bản sao database, thay vì được TCP âm thầm sửa như hiện tại. Bên cạnh đó, MySQL replication chạy trên TCP và không có tùy chọn chuyển sang UDP; đây không phải là nút cấu hình tồn tại.

📌 Điểm cần nhớ

• Cloud VPN đi qua public Internet; Dedicated Interconnect là kết nối vật lý riêng. Khi đề nhắc tới latency không ổn định hoặc packet loss trên VPN, hướng trả lời gần như luôn là chuyển sang Interconnect.
• Thêm nhiều tunnel VPN chỉ giải quyết bài toán băng thông, không giải quyết bài toán chất lượng đường truyền. Đọc kỹ triệu chứng trong đề để phân biệt hai nhóm vấn đề này.
• Phương án chuyển từ replication liên tục sang backup/restore định kỳ luôn làm xấu đi RPO — cảnh giác khi đề nói rõ mục tiêu là disaster recovery.
• Database replication yêu cầu dòng dữ liệu tin cậy và đúng thứ tự (TCP). Bất kỳ phương án nào đề xuất đổi sang UDP để "đỡ mất gói" đều là bẫy ngược logic.

🧩 Phân tích nội dung câu hỏi

Đề bài dựng bối cảnh một công ty đa quốc gia triển khai ứng dụng microservices phức tạp lên GCP và hỏi giải pháp hiệu quả nhất. Có ba cụm từ trong đề quyết định đáp án, và phải thỏa cả ba chứ không phải chọn hai trong ba:

• "complex microservices-based applications" — ứng dụng chia thành nhiều service độc lập, cần một nền tảng điều phối container (container orchestration) chứ không phải nền tảng chạy một khối ứng dụng đơn.
• "SLA of 99.99% uptime... available all the time" — mức uptime này không đạt được nếu toàn bộ hạ tầng nằm trong một region. Một sự cố cấp region là đủ làm ứng dụng chết. Cụm này bắt buộc kiến trúc phải multi-region.
• "varying loads throughout the day and spikes during the holiday season" — tải biến động mạnh, nên phải có autoscaling thay vì cấp phát cố định.

Cụm phân biệt sắc nhất là "multiple regions" ẩn trong yêu cầu SLA cao — chỉ có một phương án nói rõ điều đó.

✅ Vì sao đáp án đúng là đúng

C — GKE với cluster ở nhiều region, bật autoscaling là phương án duy nhất khớp trọn cả ba ràng buộc:

• Microservices: GKE là Kubernetes có quản lý, sinh ra đúng cho mô hình này. Mỗi microservice đóng gói thành container, chạy như Deployment riêng, có service discovery, rolling update và health check sẵn — không phải tự dựng.
• Uptime cao: triển khai cluster ở nhiều region giúp ứng dụng sống sót khi một region gặp sự cố. Kết hợp với load balancing toàn cầu của GCP, lưu lượng được điều hướng sang region còn khỏe. Đây là điều kiện cần để nhắm tới mức SLA bốn số chín.
• Tải biến động: GKE hỗ trợ autoscaling ở hai tầng — số pod (Horizontal Pod Autoscaler) và số node trong node pool (Cluster Autoscaler). Tải tăng đột biến mùa lễ thì mở rộng, hết cao điểm thì co lại để khỏi trả tiền thừa.

❌ Vì sao các phương án còn lại sai

A — App Engine Standard với autoscaling. Đây là phương án gần đúng nhất và cũng dễ chọn nhầm nhất: App Engine Standard có autoscaling rất tốt, giải quyết ổn phần "tải biến động". Nó hỏng ở hai chỗ. Thứ nhất, App Engine là dịch vụ theo phạm vi region — một ứng dụng App Engine gắn với một region và không đổi được sau khi tạo, nên không tự nó cho ra kiến trúc multi-region như đề đòi. Thứ hai, App Engine Standard chạy trong sandbox với runtime và thư viện hạn chế, không phải chỗ thoải mái cho hệ microservices phức tạp cần kiểm soát runtime và mạng nội bộ.

B — Compute Engine trong một region. Sai ngay ở cụm quyết định: "within a single region" mâu thuẫn trực tiếp với yêu cầu uptime. Một sự cố cấp region là ứng dụng ngừng hoàn toàn. Ngoài ra, dùng VM trần cho microservices đồng nghĩa tự lo đóng gói, triển khai, service discovery và scaling — làm lại thủ công đúng thứ GKE đã có sẵn.

D — Kết hợp Compute Engine và Cloud Functions. Phương án này không nhắc gì tới multi-region lẫn autoscaling, nên bỏ trống hai ràng buộc chính của đề. Cloud Functions hợp với tác vụ ngắn, hướng sự kiện; ghép nó với VM cho một hệ microservices lâu dài tạo ra kiến trúc lai, hai mô hình vận hành khác nhau, hai cách triển khai và giám sát khác nhau — phức tạp hơn mà vẫn không đảm bảo được tính sẵn sàng.

📌 Điểm cần nhớ

• Đề nhắc SLA uptime rất cao thì hầu như luôn loại mọi phương án ghim vào một region; hãy tìm phương án có từ "multiple regions" hoặc "global".
• "Microservices" + "container" trong đề là tín hiệu mạnh cho GKE; App Engine hợp với ứng dụng web đơn khối hơn.
• App Engine gắn với một region và không đổi được sau khi tạo — nhớ chi tiết này để loại nhanh trong các câu hỏi về tính sẵn sàng liên vùng.
• Tải biến động theo giờ và tăng vọt theo mùa → cần autoscaling; ở GKE là hai tầng: pod (HPA) và node (Cluster Autoscaler).

Đáp án

C — Ghi dữ liệu vào hàng đợi Cloud Pub/Sub và cho ứng dụng đọc từ đó

Vì sao đúng

Vấn đề là tốc độ dữ liệu tới vượt tốc độ xử lý, từng đợt. Hàng đợi giải đúng chuyện đó: nó hấp thụ phần dôi ra, và ứng dụng tiêu thụ theo nhịp của mình thay vì bị đè bẹp. Không có bản ghi nào bị mất, và khi hết đợt cao điểm thì hàng đợi tự vơi.

Đây là kiểu giảm áp bằng đệm — cách xử lý chuẩn cho tải bùng phát mà không phải mua thêm máy cho mức đỉnh.

Vì sao các phương án khác sai

• A. Tăng CPU — trả tiền cho mức đỉnh suốt thời gian còn lại, và vẫn hỏng khi đỉnh cao hơn dự đoán.
• B. Ghi vào SSD cục bộ — tự dựng hàng đợi thô sơ, mất dữ liệu khi máy hỏng và không chia sẻ được giữa nhiều máy.
• D. Ghi vào Memorystore — bộ nhớ đệm, không có ngữ nghĩa xác nhận và thử lại của hàng đợi.

Đáp án

B, C và D — hợp đồng cam kết sử dụng, BigQuery giá cố định, và Archive Storage cho dữ liệu nguội

Vì sao đúng

Ba đòn tối ưu chi phí ứng với ba loại tài nguyên:

• B. Committed Use Contract — cam kết một mức tài nguyên trong một tới ba năm để đổi lấy giảm giá sâu; hợp lý vì nền tảng phân tích chạy liên tục.
• C. BigQuery giá cố định — trả theo mức tính toán thay vì theo lượng dữ liệu quét; đáng khi khối lượng truy vấn lớn và ổn định, và quan trọng hơn là chi phí đoán trước được.
• D. Archive Storage — dữ liệu tài chính cũ phải giữ để tuân thủ nhưng hiếm khi đọc; tầng này rẻ hơn Standard nhiều lần.

Vì sao các phương án khác sai

• A. Chiến lược đa đám mây để ép giá — làm kiến trúc phức tạp hơn nhiều so với phần tiết kiệm.
• E. Để mọi thứ ở lớp Standard — trả giá cao nhất cho cả dữ liệu chẳng ai đụng tới.

Đáp án

A — Đóng gói ứng dụng thành container và triển khai bằng Cloud Run

Vì sao đúng

Vấn đề của một máy ảo chạy liên tục là trả tiền cả lúc không ai dùng. Cloud Run tính tiền theo thời gian xử lý yêu cầu và co về 0 khi rảnh — với ứng dụng có lưu lượng thấp hoặc thất thường thì đây là mức tiết kiệm lớn nhất, đồng thời không còn máy nào phải vá hay trông.

Vì sao các phương án khác sai

• B. App Engine Flexible — chạy trên máy ảo bên dưới và luôn giữ ít nhất một bản, nên vẫn tốn tiền lúc rảnh.
• C. GKE với tự co giãn ngang — mạnh nhưng cụm luôn có node chạy nền; quá nặng cho một ứng dụng.
• D. Không thể giảm chi phí — sai.

Đáp án

C — Tắt health check của nhóm, rồi thêm khoá SSH vào dự án

Vì sao đúng

Máy khởi động lại mỗi 6 giây vì health check báo hỏng và nhóm tự thay máy. Không tắt health check thì đồng nghiệp không kịp đăng nhập — máy bị huỷ trước khi phiên SSH kết nối xong. Vì vậy thứ tự bắt buộc là: tắt health check để máy sống đủ lâu, rồi mới thêm khoá SSH để vào xem log.

Vì sao các phương án khác sai

• A. Khởi động lại cuốn chiếu — máy mới cũng hỏng y hệt vì nguyên nhân chưa được tìm ra.
• B. Tắt autoscaling — autoscaling quyết định số lượng máy; việc thay máy hỏng là do health check, nên tắt nhầm thứ.
• D. Cấp vai Viewer — cho xem cấu hình, không cho đăng nhập vào máy.

Đáp án

B — Triển khai front end và REST API thành hai service riêng của App Engine, cùng một CSDL quan hệ được quản lý

Vì sao đúng

App Engine có khái niệm service: nhiều thành phần trong cùng một ứng dụng, mỗi cái triển khai và co giãn độc lập nhưng dùng chung định tuyến, ghi log và giám sát. Đó là mô hình gọn nhất cho ứng dụng nhiều tầng: hai service cho hai tầng, Cloud SQL cho tầng dữ liệu, và không có máy nào phải vận hành.

Vì sao các phương án khác sai

• A. Front end trên Cloud Functions — Cloud Functions dựng cho hàm theo sự kiện, không phải để phục vụ giao diện web đầy đủ.
• C. Nhồi tất cả vào một cụm GKE — dùng namespace tách logic thì được, nhưng phải vận hành cả cụm cho một ứng dụng ba tầng.
• D. Trộn Compute Engine, GKE và CSDL tự quản — ba nền tảng khác nhau cho một ứng dụng, chi phí vận hành cao nhất.