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

🧩 Phân tích chi tiết câu hỏi trắc nghiệm

✅ Nội dung câu hỏi được giải thích rõ ràng:
Câu hỏi mô tả tình huống triển khai một ứng dụng lớn trên Google Cloud Platform (GCP), bao gồm kết nối với on-premises (hệ thống tại chỗ). Yêu cầu chính là:

• Đảm bảo kết nối trực tiếp (direct connectivity) giữa các workloads (các máy ảo hoặc dịch vụ) ở tất cả các regions trên GCP và các vị trí on-premises.
• KHÔNG sử dụng address translation (không NAT hoặc proxy, để routing trực tiếp dựa trên IP gốc).
• Vấn đề lớn: Tất cả các dải địa chỉ RFC 1918 (private IP như 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) đã được sử dụng hết ở on-premises, dẫn đến nguy cơ overlap (trùng lặp địa chỉ IP) nếu dùng chung trên GCP.
  Mục tiêu là thiết kế mạng VPC để tránh overlap, hỗ trợ routing global/multiregion mà không cần dịch địa chỉ. Đây là kịch bản thực tế cho hybrid cloud với Cloud Interconnect hoặc HA VPN, sử dụng Cloud Router và BGP để advertise routes.
  (Kiến thức cập nhật đến 2026: GCP hỗ trợ Shared VPC global với non-RFC1918 ranges qua VPC peering và Interconnect, theo docs VPC 2024-2026).

✅ Đáp án đúng và lý do lựa chọn:
Đáp án đúng: Use non-RFC 1918 ranges with a single global VPC.
🛠️ Lý do chi tiết:

• Sử dụng dải IP public (non-RFC 1918) cho subnets VPC (ví dụ: 35.0.0.0/8 hoặc các public ranges khác không overlap với on-premises).
• Single global VPC: Một VPC duy nhất spanning tất cả regions (qua auto-mode hoặc custom subnets global), dễ quản lý, hỗ trợ routing trực tiếp qua Cloud Router + BGP mà không cần peering phức tạp.
• Kết nối on-premises qua Dedicated Interconnect hoặc Partner Interconnect, advertise routes private (non-RFC1918) mà KHÔNG NAT, đảm bảo direct connectivity end-to-end.
• Tránh overlap hoàn toàn vì on-premises dùng hết RFC1918, nhưng GCP dùng public ranges routed privately.
  📘 Nguồn tham khảo:
• Google Cloud VPC Design Best Practices (cập nhật 2025).
• Cloud Interconnect Overview (hỗ trợ non-RFC1918 routing đến 2026).

📋 Giải thích tất cả các phương án (đúng/sai)

• ❌ [SAI] Use multiple VPC networks with a transit network using VPC Network Peering.
  🧩 Phân tích sai: VPC Network Peering không hỗ trợ transit routing (không chuyển tiếp traffic giữa các VPC peered), cần thiết kế hub-spoke phức tạp với Shared VPC hoặc Appliance, nhưng vẫn không giải quyết overlap RFC1918 (các VPC vẫn dùng private ranges trùng). Không đảm bảo direct connectivity global mà không NAT.

• ❌ [SAI] Use overlapping RFC 1918 ranges with multiple isolated VPC networks.
  🧩 Phân tích sai: Nếu overlap RFC1918 giữa GCP và on-premises, routing trực tiếp sẽ thất bại (conflict IP), không thể kết nối mà không dùng NAT hoặc proxy. Multiple isolated VPC chỉ làm phức tạp thêm, không scale global và vi phạm yêu cầu "without address translation".

• ❌ [SAI] Use overlapping RFC 1918 ranges with multiple isolated VPC networks and Cloud NAT.
  🧩 Phân tích sai: Cloud NAT thực hiện address translation (dịch IP private sang public), trực tiếp vi phạm yêu cầu "without address translation". Overlap vẫn tồn tại, chỉ mask tạm thời nhưng không direct connectivity, và NAT không scale tốt cho large deployment multiregion.

• ✅ [ĐÚNG] Use non-RFC 1918 ranges with a single global VPC.
  🛠️ Phân tích đúng (tóm tắt lại): Như phần đáp án trên, giải pháp tối ưu, tuân thủ best practices GCP cho hybrid cloud lớn, tránh overlap, hỗ trợ BGP routing direct qua Interconnect/VPN. Scale hoàn hảo cho all-regions workloads.

🛡️ Kết luận: Giải pháp đúng tận dụng non-RFC1918 để hybrid routing mượt mà, phù hợp kỳ thi Professional Cloud Network Engineer (PCCNE). Nếu triển khai thực tế, test với Network Connectivity Center (mới 2024+).

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

Câu hỏi này thuộc lĩnh vực mạng VPC trên Google Cloud Platform (GCP) (không phải AWS như đề cập nhầm, vì AWS sử dụng Security Groups hoặc Network ACLs mà không có khái niệm "target tag" như network tags trong GCP). 🛤️

Tình huống: Nhóm bảo mật của công ty muốn hạn chế loại lưu lượng inbound (vào) đến các web server để chống lại các mối đe dọa bảo mật. Bạn cần cấu hình firewall rules trên VPC để chỉ cho phép HTTP (port 80) và HTTPS (port 443) qua giao thức TCP dành cho web traffic.

Yêu cầu chính:

• Inbound traffic (ingress): Lưu lượng từ bên ngoài vào web server.
• Chỉ TCP ports 80 và 443: HTTP và HTTPS chuẩn.
• Target tag "web-server": Sử dụng network tags để áp dụng rule cho các VM có tag này.
• Allow all IP addresses: Cho phép từ mọi nguồn IP (0.0.0.0/0).
• Priority: "Allow on match" nghĩa là rule ưu tiên cho phép nếu khớp, và ngầm định deny các traffic khác (theo nguyên tắc implicit deny của GCP VPC firewall).

Mục tiêu là tạo rule ingress allow chính xác để bảo vệ web server mà không mở rộng không cần thiết. 📘 Nguồn tham khảo: Google Cloud VPC Firewall Rules Documentation (cập nhật đến 2024, không thay đổi lớn dự kiến đến 2026).

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Create an allow on match ingress firewall rule with the target tag “web-server” to allow all IP addresses for TCP ports 80 and 443.

Lý do:

• Ingress: Đúng hướng lưu lượng (vào web server từ internet/client).
• TCP ports 80 & 443: Chính xác cho HTTP/HTTPS.
• Target tag “web-server”: Áp dụng cho các instance có tag này.
• Allow all IP (0.0.0.0/0): Cho phép web traffic từ mọi nơi.
• Allow on match: Rule sẽ match và allow, các traffic khác bị deny mặc định. Hoàn hảo để hạn chế chỉ HTTP/HTTPS TCP, chống DDoS/threats khác. 🛡️

🛠️ Giải thích tất cả các phương án (đúng/sai)

• Phương án 1: Create an allow on match ingress firewall rule with the target tag “web-server” to allow all IP addresses for TCP port 80.
  ❌ Sai: Chỉ cho phép port 80 (HTTP), thiếu port 443 (HTTPS). Không đáp ứng yêu cầu "HTTP and HTTPS".

• Phương án 2: Create an allow on match egress firewall rule with the target tag “web-server” to allow all IP addresses for TCP port 80.
  ❌ Sai:

  • Egress (ra ngoài): Sai hướng, chỉ kiểm soát traffic từ web server đi ra, không phải inbound vào server.
  • Chỉ port 80: Thiếu 443. Không bảo vệ inbound threats.

• Phương án 3 (Đúng ✅): Create an allow on match ingress firewall rule with the target tag “web-server” to allow all IP addresses for TCP ports 80 and 443.
  ✅ Đúng: Hoàn toàn khớp yêu cầu: Ingress, TCP 80/443, target tag đúng, allow all IPs. Bảo mật tối ưu theo best practices GCP.

• Phương án 4: Create an allow on match egress firewall rule with the target tag “web-server" to allow web server IP addresses for TCP ports 80 and 443.
  ❌ Sai:

  • Egress: Sai hướng (ra ngoài, không phải inbound).
  • Source là "web server IP addresses": Sai logic, egress rule thường source là instance IP, nhưng yêu cầu là inbound từ all IPs vào server. Không phù hợp bảo vệ inbound traffic.

Lưu ý bổ sung: Trong GCP (phiên bản mới nhất 2024+), firewall rules có priority (thấp hơn = ưu tiên cao hơn), và hierarchical firewall policies hỗ trợ từ 2023, nhưng rule cơ bản ingress với tags vẫn là chuẩn. Không cần regional/subnet rules ở đây vì tag-based đủ. 🔍 Nguồn: GCP Firewall Best Practices.

🧩 Giải thích nội dung câu hỏi

Câu hỏi xoay quanh việc tối ưu hóa chi phí truyền dữ liệu (data transfer costs) khi triển khai VLAN attachments cho một Dedicated Interconnect đã được thiết lập thành công.

• Tình huống cụ thể:

  • Kết nối vật lý (physical connection) được đặt tại colocation facility gần nhất với region us-west2.
  • 75% workloads nằm ở us-east4 (phần lớn traffic).
  • 25% workloads nằm ở us-central1 (phần nhỏ hơn).
  • Tất cả workloads có profile traffic mạng giống nhau (tức là lượng traffic cân bằng theo tỷ lệ workloads).

• Mục tiêu: Triển khai VLAN attachments sao cho giảm thiểu chi phí truyền dữ liệu từ on-premises (qua Interconnect) đến các workloads ở các region khác nhau.

🛠️ Kiến thức cốt lõi (Google Cloud Networking, cập nhật đến 2026):

• Dedicated Interconnect là kết nối vật lý tốc độ cao (10/100 Gbps) từ colo facility đến Google backbone.
• VLAN attachment gắn kết nối này với Cloud Router để route traffic vào VPC network.
• Chi phí data transfer:
  • Traffic từ Interconnect vào region đích (ingress) miễn phí.
  • Nhưng nếu dùng VPC global routing giữa các region, traffic inter-region sẽ phát sinh egress costs (ví dụ: us-west2 → us-east4 có phí khoảng $0.01-$0.02/GB tùy hướng, theo bảng giá 2024-2026).
• Giải pháp tối ưu: Sử dụng một Dedicated Interconnect duy nhất nhưng tạo nhiều VLAN attachments ở các Cloud Router của regions có workloads lớn, để traffic đi trực tiếp qua Google backbone mà không qua inter-region transfer (zero additional cost).

📘 Tài liệu tham khảo:

• Google Cloud Interconnect Overview (cập nhật 2025).
• VLAN Attachments & Costs – Xác nhận một physical connection hỗ trợ multiple VLAN attachments cross-region.
• Data Transfer Pricing – Ingress miễn phí, tránh inter-region egress.

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Keep the existing Dedicated Interconnect. Deploy a VLAN attachment to a Cloud Router in us-east4, and deploy another VLAN attachment to a Cloud Router in us-central1.

Lý do 🏆:

• Giữ nguyên kết nối vật lý hiện tại (gần us-west2) để tiết kiệm chi phí (không cần đặt thêm physical connection mới, tốn kém ~$thousands/tháng).
• Triển khai 2 VLAN attachments: Một ở us-east4 (cho 75% traffic – lớn nhất, ưu tiên cao) và một ở us-central1 (25% traffic).
• Traffic từ on-premises sẽ route trực tiếp qua Google backbone đến từng region mà không phát sinh inter-region data transfer costs (ingress miễn phí).
• Tối ưu nhất vì phân bổ theo tỷ lệ workloads, hỗ trợ bởi tính năng multi-region VLAN attachments trên single Dedicated Interconnect (hỗ trợ lên đến 32 VLANs/Interconnect theo docs 2026).

❌ Giải thích tất cả các phương án

Dưới đây là phân tích chi tiết từng lựa chọn (giữ nguyên văn bản gốc tiếng Anh), với lý do đúng/sai dựa trên chi phí và best practices:

• [SAI] Keep the existing Dedicated interconnect. Deploy a VLAN attachment to a Cloud Router in us-west2, and use VPC global routing to access workloads in us-east4 and us-central1.
  ❌ Lý do sai: VLAN attachment chỉ ở us-west2 (gần physical connection), traffic đến us-east4 (75%) và us-central1 (25%) phải qua VPC global routing → phát sinh inter-region egress costs cao (ví dụ: ~$0.02/GB từ us-west2 sang us-east4). Không tối ưu, chi phí tăng vọt cho phần lớn workloads.

• [ĐÚNG] Keep the existing Dedicated Interconnect. Deploy a VLAN attachment to a Cloud Router in us-east4, and deploy another VLAN attachment to a Cloud Router in us-central1.
  ✅ Lý do đúng (như đã giải thích ở trên): Tối ưu chi phí tuyệt đối, traffic trực tiếp đến từng region, tận dụng single physical connection với multi-VLAN cross-region.

• [SAI] Order a new Dedicated Interconnect for a colocation facility closest to us-east4, and use VPC global routing to access workloads in us-central1.
  ❌ Lý do sai: Đặt Dedicated Interconnect mới ở gần us-east4 → chi phí cao gấp đôi (physical setup + port hours ~$2.5K/tháng + cross-connect fees). Traffic đến us-central1 (25%) vẫn qua global routing → vẫn tốn inter-region costs. Không cần thiết khi existing Interconnect đã hỗ trợ multi-VLAN.

• [SAI] Order a new Dedicated Interconnect for a colocation facility closest to us-central1, and use VPC global routing to access workloads in us-east4.
  ❌ Lý do sai: Tương tự lựa chọn trên, nhưng tệ hơn vì ưu tiên us-central1 (chỉ 25%) thay vì us-east4 (75%) → chi phí cao cho physical mới + phần lớn traffic (75%) đến us-east4 vẫn tốn inter-region egress. Hoàn toàn không tối ưu.

🛡️ Lưu ý cuối: Giải pháp này phù hợp với Hybrid Connectivity best practices trên Google Cloud (2026), ưu tiên multi-VLAN trên single Interconnect để scale mà không tăng costs. Nếu traffic tăng, có thể xem Partner Interconnect làm backup!

🧩 Giải thích nội dung câu hỏi

Câu hỏi mô tả một môi trường hybrid cloud (lai giữa Google Cloud và on-premises), nơi môi trường Google Cloud được kết nối với mạng on-premises qua HA VPN (High Availability VPN) và Cloud Router được cấu hình mặc định trong một central transit hub VPC (VPC trung tâm kiểu hub). Máy chủ DNS on-premises nằm tại IP 192.168.20.88.

Yêu cầu chính:

• Các tài nguyên Compute Engine trong nhiều spoke VPCs (các VPC phát ngôn kiểu spoke) phải có thể resolve (phân giải tên miền) các hostname private on-premises sử dụng domain corp.altostrat.com.
• Đồng thời, vẫn resolve được các Google Cloud hostnames (như metadata server, private Google APIs).
• Phải tuân thủ Google-recommended practices (thực hành khuyến nghị của Google), tức là mô hình hub-and-spoke với DNS phân giải private an toàn, không lộ ra ngoài.

Vấn đề cốt lõi:

• On-premises DNS chỉ accessible từ hub VPC (qua VPN).
• Spoke VPCs cần forward query DNS đến on-premises qua hub.
• Cloud Router mặc định không advertise các range private Google APIs (như 35.199.192.0/19), nên cần custom để resolve GCP services private.
• Cần kết nối spoke-hub để traffic DNS và route chảy đúng.

📘 Tài liệu tham khảo:

• Cloud DNS Private zones (cập nhật 2024-2026).
• Cloud Router custom route advertisements (bao gồm 35.199.192.0/19 cho private Google access).
• Hub-and-spoke topology best practices (khuyến nghị peering + DNS forwarding/peering zones).

✅ Đáp án đúng: Lựa chọn đầu tiên (gồm 4 bước)

Lựa chọn đúng:

1. Create a private forwarding zone in Cloud DNS for ‘corp.altostrat.com’ called corp-altostrat-com that points to 192.168.20.88. Associate the zone with the hub VPC.
2. Create a private peering zone in Cloud DNS for ‘corp.altostrat.com’ called corp-altostrat-com associated with the spoke VPCs, with the hub VPC as the target.
3. Set a custom route advertisement on the Cloud Router for 35.199.192.0/19.
4. Configure VPC peering in the spoke VPCs to peer with the hub VPC.

Lý do chọn đáp án này 🛠️:

• Bước 1: Tạo private forwarding zone trong hub VPC để forward tất cả query corp.altostrat.com đến DNS on-premises (192.168.20.88). Hub accessible on-premises qua HA VPN, nên forwarding chỉ associate với hub VPC.
• Bước 2: Tạo private peering zone trong spoke VPCs, target hub VPC, để spoke forward query đến hub (nơi forwarding zone xử lý tiếp). Đây là cách khuyến nghị cho hub-spoke DNS resolution.
• Bước 3: Cloud Router mặc định không advertise range 35.199.192.0/19 (private Google APIs VPC range). Custom advertisement đảm bảo on-premises advertise route này về GCP, giúp resolve GCP hostnames private từ on-premises (và ngược lại).
• Bước 4: VPC peering spoke-hub cho phép traffic DNS và route (on-premises) chảy giữa spoke-hub mà không cần shared VPC phức tạp. Toàn bộ tuân thủ Google best practices cho hybrid hub-spoke (cập nhật 2026).
  Kết quả: Spoke resolve on-premises qua hub → on-prem DNS, và GCP services private đầy đủ.

❌ Giải thích tất cả các phương án (sai và đúng)

• Phương án 1 (ĐÚNG - như trên) ✅: Hoàn chỉnh, chính xác theo docs GCP. Kết hợp forwarding/peering zones + custom route + peering. Không có lỗi cấu hình hay thiếu bước.

• Phương án 2 (SAI) ❌:

  1. Create a private forwarding zone in Cloud DNS for ‘corp.altostrat.com’ called corp-altostrat-com that points to 192.168.20.88.
  2. Associate the zone with the hub VPC. Create a private peering zone in Cloud DNS for ‘corp.altostrat.com’ called corp-altostrat-com associated with the spoke PCs, with the hub VPC as the target.
  3. Set a custom route advertisement on the Cloud Router for 35.199.192.0/19.
     Lý do sai 🧩:
  • Bước 2 có lỗi chính tả "spoke PCs" (phải là "spoke VPCs"). Cloud DNS chỉ associate với VPC, không phải PC.
  • Thiếu bước VPC peering: Spoke không kết nối hub → peering zone không route được traffic DNS đến hub. Không resolve được.

• Phương án 3 (SAI) ❌:

  1. Create a private forwarding zone in Cloud DNS for ‘corp.altostrat.com’ called corp-altostrat-com that points to 192.168.20.88. Associate the zone with the hub VPC.
  2. Create a private peering zone in Cloud DNS for ‘corp.altostrat.com’ called corp-altostrat-com associated with the spoke VPCs, with the hub VPC as the target.
  3. Set a custom route advertisement on the Cloud Router for 35.199.192.0/19.
  4. Create a hub-and-spoke VPN deployment in each spoke VPC to connect back to the on-premises network directly.
     Lý do sai 🛠️:
  • Bước 4 sai hoàn toàn: Tạo VPN direct từ mỗi spoke đến on-premises vi phạm hub-spoke (tạo "spaghetti networking", tốn kém, không scalable). Google khuyến nghị peering spoke-hub, không VPN direct. Dẫn đến duplicate tunnels, conflict routes.

• Phương án 4 (SAI) ❌:

  1. Create a private forwarding zone for ‘corp altostrat.com’ called corp-altostrat-com that points to 192. 168.20.88. Associate the zone with the hub VPC.
  2. Create a private peering zone in Cloud DNS for ‘corp.altostrat.com’ called corp-altostrat-com associated with the spoke VPCs, with the hub VPC as the target.
  3. Sat a custom route advertisement on the Cloud Router for 35.199.192.0/19.
  4. Create a hub and spoke VPN deployment in each spoke VPC to connect back to the hub VPC.
     Lý do sai 📘:
  • Bước 1: Lỗi chính tả domain corp altostrat.com (thiếu dấu chấm → corp.altostrat.com), và IP 192. 168.20.88 (khoảng trắng sai). Cloud DNS reject zone invalid.
  • Bước 3: Lỗi đánh máy "Sat" thay "Set".
  • Bước 4: VPN spoke-hub không cần thiết (peering hiệu quả hơn, low-latency). VPN chỉ dùng cho on-premises, không intra-GCP. Không theo best practices.

Tóm lại, chỉ phương án 1 đầy đủ, chính xác và scalable! 🚀

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

Câu hỏi thuộc chủ đề Google Cloud VPC Firewall Rules (không phải AWS như đề cập nhầm, mà là kiến thức cốt lõi của Google Cloud Networking).

• Tình huống hiện tại (từ image5.png): VPC có bộ quy tắc firewall áp dụng cho tất cả instances. Các quy tắc cụ thể như sau:

  • Egress (ra khỏi VPC) deny (chặn) destination 192.0.2/24 port 80, priority 100 ✅ (ưu tiên cao, đánh giá đầu tiên).
  • Egress deny destination 198.51.100/24 port 80, priority 200.
  • Ingress (vào VPC) allow (cho phép) source 203.0.113/24 port 80, priority 300.

  📝 Lưu ý về priority: Trong GCP, priority là số nguyên từ 0-65535. Số nhỏ hơn = ưu tiên cao hơn (đánh giá trước). Nếu không khớp quy tắc nào, egress mặc định allow (cho phép), ingress mặc định deny (chặn).

• Yêu cầu cập nhật (từ image6.png): Thêm quy tắc mới egress deny destination 192.0.4/32 (một IP cụ thể /32) port 80, với Logging = true (ghi log firewall vào Cloud Logging để theo dõi).

• Ràng buộc: Sử dụng tài khoản user mới (new user account). Phải gán IAM roles phù hợp trước khi update quy tắc. User cần:

  • Quyền apply/update firewall rule (tạo/cập nhật VPC Firewall Rule).
  • Quyền view firewall logs (xem log trong Cloud Logging, vì firewall logs được lưu ở đó).

• Mục tiêu: Chọn cách gán role + priority đúng để quy tắc mới hoạt động hiệu quả, được đánh giá trước các quy tắc hiện có (đặc biệt trước priority 100), và enable logging.

🛠️ Kiến thức cập nhật (GCP 2026): VPC Firewall Rules thuộc Compute Engine. Không dùng Hierarchical Firewall Policies (org level). Logging firewall yêu cầu enable khi create/update rule, logs lưu vào Cloud Logging buckets.

✅ Đáp án đúng

Assign the compute.securityAdmin and logging.viewer role to the new user account. Apply the new firewall rule with a priority of 50.

Lý do chọn (chi tiết):

• Roles đúng:
  • compute.securityAdmin: Cấp quyền đầy đủ quản lý VPC Firewall Rules (compute.firewalls.create, compute.firewalls.update, compute.firewalls.get). Phù hợp cho VPC-level, không phải org-level. Cho phép enable logging trên rule.
  • logging.viewer: Cấp quyền xem log (logging.logs.list, logging.entries.list) trong Cloud Logging, nơi lưu firewall logs.
• Priority 50 đúng: 50 < 100 (ưu tiên cao hơn rule đầu tiên). Quy tắc mới được đánh giá đầu tiên cho egress traffic đến 192.0.4/32:80 → deny ngay + ghi log. Đảm bảo không bị rule priority 100 "chen ngang" (dù không overlap range, nhưng thứ tự đánh giá tối ưu cho hiệu suất và logging sớm).
• Kết quả: User có thể apply rule mới và xem logs mà không thừa quyền.

❌ Giải thích tất cả các phương án (đúng/sai)

• ✅ Assign the compute.securityAdmin and logging.viewer role to the new user account. Apply the new firewall rule with a priority of 50.

  • Đúng hoàn toàn 🏆: Như lý do trên. Role phù hợp cho VPC FW + log viewing. Priority 50 đảm bảo rule mới đứng top precedence (trước 100/200/300), deny + log chính xác cho 192.0.4/32:80.

• ❌ Assign the compute.securityAdmin and logging.bucketWriter role to the new user account. Apply the new firewall rule with a priority of 150.

  • Sai:
    • logging.bucketWriter chỉ cho phép ghi log vào bucket (logging.buckets.update), không xem log (thiếu logging.logs.list). User không view được firewall logs.
    • Priority 150 thấp hơn (số cao hơn 100), rule đánh giá sau rule p100 → có thể kém hiệu quả (dù không overlap range ở đây, nhưng không đảm bảo precedence cao nhất theo yêu cầu hình ảnh).

• ❌ Assign the compute.orgSecurityPolicyAdmin and logging.viewer role to the new user account. Apply the new firewall rule with a priority of 50.

  • Sai:
    • compute.orgSecurityPolicyAdmin chỉ quản lý Organization/Hierarchical Security Policies (org level, không phải VPC Firewall Rules). Không có quyền compute.firewalls.* cho VPC → không apply được rule.
    • logging.viewer đúng nhưng role FW sai. Priority 50 tốt nhưng vô dụng vì thiếu quyền update.

• ❌ Assign the compute.orgSecurityPolicyAdmin and logging.bucketWriter role to the new user account. Apply the new firewall rule with a priority of 150.

  • Sai toàn bộ 💥:
    • compute.orgSecurityPolicyAdmin sai như trên (không quản lý VPC FW).
    • logging.bucketWriter sai (chỉ write, không view logs).
    • Priority 150 sai (thấp hơn p100, không optimal).

📘 Tài liệu tham khảo (cập nhật 2026)

• IAM Roles: Google Cloud Compute IAM Roles → compute.securityAdmin cho VPC FW.
• Logging Roles: Cloud Logging Access Control → logging.viewer cho read logs.
• Firewall Rules & Priority: VPC Firewall Rules Docs → Lower number first; logging enabled per-rule.
• Exam Source: ExamTopics/Google Cloud Professional Cloud Network Engineer (ruleset tương tự các exam 2023-2026).
• CLI Example: gcloud compute firewall-rules create ... --priority=50 --logging=true.

🛡️ Lời khuyên: Luôn test rule mới bằng gcloud compute firewall-rules describe và kiểm tra logs qua Console Logging. Tránh org roles cho VPC!

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

Câu hỏi thuộc chủ đề bảo mật truy cập API trong Google Cloud Platform (GCP) (không phải AWS như đề cập nhầm – vì liên quan đến VPCs, Cloud Storage và BigQuery là các dịch vụ đặc trưng của GCP). Tình huống: Tổ chức có một project duy nhất chứa nhiều VPC (Virtual Private Clouds). Yêu cầu bảo vệ truy cập API đến Cloud Storage buckets và BigQuery datasets bằng cách chỉ cho phép từ các tài nguyên trong corporate public networks (tức các dải IP công khai của mạng nội bộ công ty, không phải từ VPC nội bộ).

Mục tiêu chính là ngăn chặn truy cập trái phép từ bên ngoài, sử dụng cơ chế VPC Service Controls (VPC-SC) để tạo "perimeter" bảo vệ, kết hợp Access Context Manager (nay là Access Context Policies trong VPC-SC) để định nghĩa quy tắc dựa trên IP ranges. Điều này giúp chặn dữ liệu rò rỉ ra ngoài perimeter, đặc biệt với các dịch vụ như Storage và BigQuery có API public endpoints.

Lưu ý kỹ thuật cập nhật 2026: VPC-SC hỗ trợ project-level perimeters để bao quát toàn bộ project (bao gồm multiple VPCs), và access levels dựa trên IP chỉ áp dụng cho ingress traffic từ public networks. Không cần firewall vì API calls không routing qua VPC firewall. (Nguồn: GCP VPC Service Controls Docs, cập nhật Q1/2026 với hỗ trợ dry-run perimeters nâng cao).

✅ Đáp án đúng

Create a VPC Service Controls perimeter for your project with an access context policy that allows your corporate public network IP ranges.

Lý do chọn:

• Project có một project duy nhất với multiple VPCs, nên tạo perimeter ở mức project sẽ bảo vệ toàn bộ tài nguyên (Cloud Storage, BigQuery) trong project đó, bao quát tất cả VPCs mà không cần tạo riêng lẻ.
• Access context policy (Access Level) định nghĩa chỉ cho phép IP ranges của corporate public networks, chặn tất cả truy cập API khác (kể cả từ VPC nội bộ nếu không chỉ định).
• Đây là giải pháp chuẩn GCP cho zero-trust access control đến Google APIs, ngăn exfiltration. Hoàn hảo khớp yêu cầu "only from corporate public networks".

📋 Giải thích tất cả các phương án (đúng/sai)

• ❌ [SAI] Create an access context policy that allows your VPC and corporate public network IP ranges, and then attach the policy to Cloud Storage and BigQuery.
  Phân tích sai: Access Context Policy (Access Level) không thể attach trực tiếp vào từng resource như Cloud Storage hay BigQuery. Nó phải được sử dụng bên trong VPC Service Controls perimeter để có hiệu lực. Hơn nữa, câu hỏi chỉ yêu cầu từ corporate public IP, không cần "VPC" (có thể hiểu là private IP), dẫn đến over-permissive.

• ✅ [ĐÚNG] Create a VPC Service Controls perimeter for your project with an access context policy that allows your corporate public network IP ranges.
  Phân tích đúng: Như đã giải thích ở trên – project-level perimeter lý tưởng cho single project với multiple VPCs, access policy giới hạn chính xác corporate public IP ranges, bảo vệ API access hiệu quả mà không ảnh hưởng internal traffic nếu cấu hình đúng. (🛠️ Best practice theo GCP Security Blueprint).

• ❌ [SAI] Create a firewall rule to block API access to Cloud Storage and BigQuery from unauthorized networks.
  Phân tích sai: Firewall rules ở VPC chỉ control traffic vào/ra VPC (GCE VMs, etc.), không block được API calls trực tiếp đến Google APIs (như storage.googleapis.com) vì chúng là public endpoints, routing qua internet backbone. Không giải quyết được yêu cầu bảo mật API từ public networks.

• ❌ [SAI] Create a VPC Service Controls perimeter for each VPC with an access context policy that allows your corporate public network IP ranges.
  Phân tích sai: VPC-SC perimeters không tạo theo từng VPC mà theo project/folder/organization. Với single project, tạo multiple perimeters per VPC là không khả thi và phức tạp hóa (overlap, management overhead). Project-level là đúng cách.

📘 Tài liệu tham khảo

• VPC Service Controls Overview (GCP Docs, 2026).
• Access Levels with IP Conditions (hỗ trợ IPv6 mới).
• Protecting Cloud Storage & BigQuery.
• GCP Well-Architected Framework: Security Pillar (Q4/2025 update).

Kết luận 🏆: Giải pháp tận dụng VPC-SC + Access Contexts là mạnh mẽ nhất cho enterprise security! Nếu cần demo Terraform config, hỏi thêm nhé. 🚀

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

Câu hỏi thuộc chủ đề Cloud NAT trong Google Cloud Platform (GCP) (không phải AWS như đề cập nhầm, vì sử dụng VPC, us-east1 region và Cloud NAT gateway – các khái niệm đặc trưng của GCP).

Công ty đã triển khai 2000 máy ảo (VMs) trong private subnet của VPC tại vùng us-east1. Các VMs này cần ít nhất 128 kết nối TCP đồng thời đến một public repository để người dùng tải phần mềm cập nhật và gói tin qua internet.

Yêu cầu chính:

• Cấu hình Cloud NAT gateway để hỗ trợ outbound NAT (xuất phát từ VMs ra internet).
• Đảm bảo tất cả 2000 VMs có thể kết nối đồng thời mà không bị hết port (port exhaustion).

Tính toán nhu cầu port 📊:

• Mỗi VM cần ≥128 TCP connections → Tổng 2000 VMs × 128 = 256.000 ports cần thiết.
• Cloud NAT (phiên bản mới nhất 2024-2026): Mỗi NAT IP hỗ trợ 64.512 ports (gần 64K ports/IPv4).
• Minimum ports per VM (cấu hình được từ 1-128, mặc định 64) quyết định phân bổ port tối thiểu cho mỗi VM.
• Để tránh hết port: Tổng ports cần (VMs × min ports/VM) ≤ Tổng ports khả dụng (số NAT IPs × 64.512).

Cần chọn 2 phương pháp đúng để đạt yêu cầu. 🛠️

✅ Đáp án đúng (Chọn 2)

Dựa trên tài liệu GCP Cloud NAT mới nhất (cập nhật đến 2026), hai đáp án đúng là:

1. Use the default Cloud NAT gateway to automatically scale to the required number of NAT IP addresses, and update the minimum number of ports per VM to 128.
   Lý do: Chế độ auto-allocation (mặc định) tự động scale số NAT IP dựa trên traffic, đảm bảo đủ ports cho 256.000 connections. Cập nhật min ports/VM = 128 khớp yêu cầu, hệ thống sẽ scale lên ≥4 IPs (4×64.512=258.048 > 256.000). Hoàn hảo cho scale tự động! 🚀

2. Configure the NAT gateway in manual allocation mode, allocate 4 NAT IP addresses, and update the minimum number of ports per VM to 128.
   Lý do: Chế độ manual allocation cho phép chỉ định chính xác 4 NAT IPs (tổng 258.048 ports > 256.000), kết hợp min ports/VM=128 đảm bảo mỗi VM có đủ 128 connections đồng thời. Tính toán chính xác, không lãng phí! 🔢

📋 Giải thích tất cả các phương án (Đúng/Sai)

Dưới đây là phân tích từng lựa chọn một cách chi tiết, giữ nguyên văn bản gốc tiếng Anh. Sử dụng kiến thức Cloud NAT GCP v2 (2024-2026): Port limits, auto/manual mode, min ports/VM=1-128.

• Configure the NAT gateway in manual allocation mode, allocate 2 NAT IP addresses, and update the minimum number of ports per VM to 256.
  ❌ SAI: Chỉ 2 NAT IPs cung cấp 2×64.512=129.024 ports, nhưng min ports/VM=256 → Tổng cần 2000×256=512.000 ports >> 129.024 → Hết port ngay! Không đáp ứng yêu cầu 128 connections/VM. 🛑

• Create a second Cloud NAT gateway with the default minimum number of ports configured per VM to 64.
  ❌ SAI: Tạo gateway thứ 2 với default min ports=64 → Mỗi gateway (giả sử 1 IP/gateway) chỉ ~64.512 ports/gateway, tổng 2 gateways ~129.024 ports. Nhưng 2000×64=128.000 ports cần đã sát nút, chưa kể overhead, và không đảm bảo 128 connections/VM (vẫn dùng default 64). Không scale đủ! 🔄

• Use the default Cloud NAT gateway's NAT proxy to dynamically scale using a single NAT IP address.
  ❌ SAI: Cloud NAT không có NAT proxy (đó là tính năng của khác dịch vụ); nó là pure NAT. Single IP chỉ 64.512 ports << 256.000 cần → Không scale dynamic với 1 IP duy nhất. Sai hoàn toàn về cơ chế! 🚫

• Use the default Cloud NAT gateway to automatically scale to the required number of NAT IP addresses, and update the minimum number of ports per VM to 128.
  ✅ ĐÚNG: Như giải thích trên, auto-scale + min ports=128 đảm bảo đủ IPs và ports. Hoạt động thực tế trong production GCP. 🌟

• Configure the NAT gateway in manual allocation mode, allocate 4 NAT IP addresses, and update the minimum number of ports per VM to 128.
  ✅ ĐÚNG: Tính toán chính xác 4 IPs đủ ports, manual control phù hợp môi trường lớn. Lý tưởng cho kiểm soát chi phí/IP. 💪

📘 Tài liệu tham khảo (GCP chính thức, cập nhật 2026)

• Cloud NAT overview & port allocation – Chi tiết 64.512 ports/IP, min ports/VM=1-128.
• Configure Cloud NAT – Auto/manual mode, scaling rules.
• NAT limits & quotas – Xác nhận tính toán ports cho large-scale (2000+ VMs).
• GCP Exam Guide (Professional Cloud Network Engineer): Reference cho scenario outbound NAT private subnets.

Nếu cần demo gcloud CLI hoặc Terraform config, hãy cho biết nhé! 🛠️

🧩 Phân tích chi tiết câu hỏi

📖 Nội dung câu hỏi:
Câu hỏi mô tả một thiết kế mạng kết nối giữa Google Cloud Platform (GCP) và môi trường on-premises qua VPN tunnel sử dụng BGP (Border Gateway Protocol). Cụ thể:

• On-premises: Có Subnet-a chứa Compute instances, kết nối qua Router đến VPN Gateway, sau đó tunnel VPN đến Google Cloud VPN Gateway. Router on-premises thiết lập BGP Session với Cloud Router của GCP.
• Google Cloud VPC:
  • Region europe-west1: Chứa Subnet-1 với Compute Engine instances.
  • Region asia-southeast1: Chứa Subnet-2 với Compute Engine instances (đây là nơi gặp vấn đề).
  • Cloud Router (có lẽ đặt ở europe-west1, dựa trên vị trí hình ảnh) nhận routes từ BGP session với on-premises, và có kết nối đến VPN Gateway.
• Vấn đề chính ❌: Compute Engine instances trong Subnet-2 (asia-southeast1) không thể giao tiếp với compute resources on-premises.
  Hình ảnh minh họa rõ ràng sự phân cách region: Cloud Router và VPN Gateway gắn với VPC, nhưng routes từ BGP (prefixes on-premises) chỉ propagate cục bộ nếu VPC đang ở chế độ Regional dynamic routing mode (mặc định). Do đó, Subnet-2 ở region khác không nhận được routes để route traffic về on-premises qua VPN tunnel.

🛠️ Nguyên nhân gốc rễ: Trong GCP, dynamic routing mode của VPC quyết định cách Cloud Router propagate routes học từ BGP:

• Regional (mặc định): Routes chỉ áp dụng trong region của Cloud Router.
• Global: Routes propagate toàn bộ VPC, cross-region.
  Vì Subnet-2 ở region khác (asia-southeast1), nó không nhận routes on-premises → Không route được traffic.

✅ Đáp án đúng: Change the VPC dynamic routing mode to Global.
Lý do lựa chọn 🏆:
Chuyển VPC sang Global dynamic routing mode sẽ cho phép Cloud Router propagate tất cả routes động (bao gồm prefixes on-premises học từ BGP) đến mọi subnet trong mọi region của VPC. Kết quả: Instances ở Subnet-2 (asia-southeast1) sẽ nhận route để gửi traffic qua VPN Gateway → on-premises. Đây là giải pháp chuẩn, không ảnh hưởng thiết kế hiện tại, và hiệu quả ngay lập tức. (Áp dụng phiên bản GCP mới nhất 2026: VPC hỗ trợ Global mode đầy đủ cho multi-region dynamic routing).

📋 Giải thích tất cả các phương án (giữ nguyên text gốc)

• ❌ Configure a custom route advertisement on the Cloud Router.
  Phân tích sai 🚫: Custom route advertisement dùng để Cloud Router advertise (quảng bá) routes tùy chỉnh của GCP ra ngoài (ví dụ: sang on-premises qua BGP). Nhưng vấn đề ở đây là nhận và propagate routes từ on-premises vào VPC (học từ BGP), không phải advertise ra. Thay đổi này không giải quyết việc Subnet-2 thiếu routes cross-region.

• ❌ Enable IP forwarding in the asia-southeast1 region.
  Phân tích sai 🚫: IP forwarding là tính năng cho VM instances (enable trên NIC để VM route traffic), không áp dụng cho region hay VPC level. Region không có khái niệm IP forwarding; đây là nhầm lẫn với GCE VM config. Không liên quan đến route propagation từ Cloud Router.

• ✅ Change the VPC dynamic routing mode to Global.
  Phân tích đúng 🎯: Như giải thích trên, Global mode enable route propagation cross-region toàn VPC. Cloud Router sẽ inject BGP-learned routes (on-premises prefixes) vào routing table của tất cả subnets, bao gồm Subnet-2. Không cần thay đổi BGP session hay thêm hardware.

• ❌ Add a second Border Gateway Protocol (BGP) session to the Cloud Router.
  Phân tích sai 🚫: Cloud Router hỗ trợ multiple BGP sessions, nhưng thêm session thứ hai (có lẽ ở asia-southeast1) là thừa và phức tạp hóa thiết kế (duplicate routes, potential loops). Một Cloud Router duy nhất với Global mode đủ để propagate routes everywhere; không cần multi-router trừ khi scale cao.

📘 Tài liệu tham khảo (GCP docs cập nhật 2026)

• VPC Dynamic Routing Mode: Google Cloud VPC Documentation - Dynamic Routing Modes (Regional vs Global, cross-region propagation).
• Cloud Router BGP: Cloud Router Overview (Route propagation rules).
• HA VPN with BGP: Configure HA VPN with Dynamic Routing.
• Best Practices Multi-Region: Multi-region VPC Design.

Giải pháp này đảm bảo high availability và simplicity theo best practices GCP! 🚀

🧩 Giải thích chi tiết nội dung câu hỏi

Câu hỏi xoay quanh việc thiết kế môi trường hybrid cloud kết nối giữa Google Cloud Platform (GCP) và mạng on-premises sử dụng Cloud HA VPN (High Availability VPN) và Cloud Router với cấu hình mặc định.

• Mục tiêu chính: Các tài nguyên Compute Engine trong GCP (thuộc subnet 10.204.0.0/24) cần resolve (tra cứu DNS) các hostname private on-premises sử dụng domain corp.altostrat.com, đồng thời vẫn giữ khả năng resolve các hostname của Google Cloud (như metadata.google.internal).
• Thách thức:
  • Server DNS on-premises tại 192.168.20.88 được bảo vệ bởi firewall, chỉ cho phép traffic hợp lệ.
  • Kết nối VPN sử dụng BGP qua Cloud Router (default: chỉ advertise các custom subnet routes của VPC đến on-premises, không advertise IP ranges của Google VPN).
  • Cần tuân thủ Google-recommended practices: Sử dụng Cloud DNS private forwarding zone để forward query cho domain cụ thể đến DNS on-premises, đảm bảo traffic DNS (UDP/TCP port 53) có thể đi qua VPN hai chiều (forward và return traffic).
• Kiến thức cốt lõi (cập nhật GCP 2026):
  • Private forwarding zone trong Cloud DNS forward query từ Google's anycast resolvers (IP nguồn thuộc range 35.199.192.0/19 cho Cloud HA VPN ở một số regions như us-central1).
  • Traffic từ GCP qua VPN đến on-premises không sử dụng source IP private của VM (10.204.0.0/24), mà là external IP của Cloud VPN gateway (35.199.192.0/19).
  • Để return traffic từ DNS on-premises về Google's resolvers, cần custom route advertisement trên Cloud Router để on-premises BGP học route cho 35.199.192.0/19.
  • Route đến DNS IP (192.168.20.88) được học tự động qua BGP từ on-premises.

📘 Tài liệu tham khảo:

• Cloud DNS: Forwarding zones over VPN/Interconnect (GCP docs, cập nhật 2025-2026).
• Cloud Router custom advertisements.
• Cloud VPN IP ranges.

✅ Đáp án đúng: Lựa chọn thứ 2

Lý do chọn 🛠️:

• Đây là giải pháp chuẩn Google-recommended cho private DNS forwarding qua HA VPN.
  • Bước 1: Tạo private forwarding zone forward chính xác domain đến IP DNS on-premises → GCP VMs (sử dụng default Cloud DNS resolver) tự động forward query.
  • Bước 2: Firewall on-premises mở 35.199.192.0/19 (IP nguồn thực tế của Google resolvers qua VPN).
  • Bước 3: Custom route advertisement trên Cloud Router cho 35.199.192.0/19 → On-premises BGP học route này, đảm bảo return traffic symmetric (tránh asymmetric routing gây drop packet).
• Giải pháp scalable, không can thiệp instance-level, giữ nguyên resolve GCP hostnames.

📋 Giải thích tất cả các phương án (đúng/sai)

• Phương án 1 [SAI]:

  1. Create a private forwarding zone in Cloud DNS for ‘corp.altostrat.com’ called corp-altostrat-com that points to 192.168.20.88.
  2. Configure your on-premises firewall to accept traffic from 10.204.0.0/24.
  3. Set a custom route advertisement on the Cloud Router for 10.204.0.0/24
     ❌ Sai vì: Bước 2 mở firewall sai IP nguồn (10.204.0.0/24 là private subnet GCP VM, nhưng traffic DNS forwarding qua VPN dùng source 35.199.192.0/19 → bị block). Bước 3 thừa vì Cloud Router default advertise VPC subnets (10.204.0.0/24) → không cần custom.

• Phương án 2 [ĐÚNG]:

  1. Create a private forwarding zone in Cloud DNS for ‘corp.altostrat.com’ called corp-altostrat-com that points to 192.168 20.88.
  2. Configure your on-premises firewall to accept traffic from 35.199.192.0/19
  3. Set a custom route advertisement on the Cloud Router for 35.199.192.0/19.
     ✅ Đúng hoàn toàn: Như giải thích trên. Lưu ý typo nhỏ "192.168 20.88" nhưng ý đúng (IP 192.168.20.88). Đảm bảo forwarding + firewall + route symmetric.

• Phương án 3 [SAI]:

  1. Create a private forwarding zone in Cloud DNS for ‘corp .altostrat.com’ called corp-altostrat-com that points to 192.168.20.88.
  2. Configure your on-premises firewall to accept traffic from 10.204.0.0/24.
  3. Modify the /etc/resolv conf file on your Compute Engine instances to point to 192.168.20 88
     ❌ Sai vì: Domain sai syntax (‘corp .altostrat.com’ có space → invalid). Bước 2 sai IP nguồn (như phương án 1). Bước 3 không recommended (modify resolv.conf thủ công trên instances → không scalable, phá vỡ default Google DNS resolver, có thể conflict với GCP metadata resolution).

• Phương án 4 [SAI]:

  1. Create a private zone in Cloud DNS for ‘corp altostrat.com’ called corp-altostrat-com.
  2. Configure DNS Server Policies and create a policy with Alternate DNS servers to 192.168.20.88.
  3. Configure your on-premises firewall to accept traffic from 35.199.192.0/19.
  4. Set a custom route advertisement on the Cloud Router for 35.199.192.0/19.
     ❌ Sai vì: Bước 1 dùng private zone (hosted zone chứa records) thay vì forwarding zone → không forward query đến on-premises DNS. Bước 2 "DNS Server Policies" không tồn tại ở GCP (confuse với Azure Private DNS?). Domain sai (‘corp altostrat.com’ thiếu dot). Bước 3-4 đúng nhưng tổng thể sai.

Tóm tắt khuyến nghị 🚀: Implement phương án 2 để hybrid DNS hoạt động mượt mà, kiểm tra bằng nslookup từ Compute Engine instance!

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

Câu hỏi mô tả tình huống: Công ty bạn có một Virtual Private Cloud (VPC) duy nhất trên Google Cloud, đã kết nối với on-premises (mạng nội bộ). Bạn đang triển khai ứng dụng mới trên Google Kubernetes Engine (GKE), ứng dụng này chỉ được truy cập từ cùng VPC và các vị trí on-premises. Đặc biệt, control plane của GKE phải được expose chỉ qua private connectivity đến danh sách các on-premises subnets được định nghĩa trước.

📌 Yêu cầu chính:

• GKE cluster phải là private (không public).
• Control plane chỉ accessible privately từ VPC nội bộ và on-premises subnets cụ thể.
• Sử dụng private connectivity (như Cloud Interconnect, HA VPN với Cloud Router) đã có sẵn.
• Không cho phép truy cập từ internet hoặc ngoài danh sách subnets on-premises.

🛠️ Bối cảnh kỹ thuật (cập nhật đến 2026):

• GKE private cluster hỗ trợ private endpoint cho control plane (IP private trong VPC, thường 172.16.0.0/28 hoặc tùy chỉnh).
• Để on-premises truy cập private control plane: Cần routes đúng (export/import qua Cloud Router BGP) và authorized networks để restrict CIDRs cụ thể.
• Custom route advertisements trên Cloud Router cho phép advertise subnet control plane chỉ đến peer on-premises subnets mong muốn (sử dụng BGP route policies).
• Không dùng VPC Peering vì on-premises không phải GCP VPC (mà dùng Cloud Router cho interconnect/VPN).

📘 Tài liệu tham khảo:

• GKE Private Clusters
• Private Endpoint & Authorized Networks
• Cloud Router BGP & Custom Advertisements

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Create a GKE private cluster with a private endpoint for the control plane. Configure VPC Networking Peering export/import routes and custom route advertisements on the Cloud Routers. Configure authorized networks to specify the desired on-premises subnets.

Lý do 🏆:

• Private cluster + private endpoint: Đảm bảo control plane chỉ accessible qua private IP (không public), phù hợp yêu cầu "private connectivity only".
• VPC Networking Peering export/import routes + custom route advertisements on Cloud Routers: Cho phép propagate routes của control plane subnet từ VPC đến Cloud Router BGP, và advertise chỉ đến subnets on-premises cụ thể (sử dụng route policies để filter).
• Authorized networks: Restrict truy cập control plane private endpoint chỉ từ CIDRs on-premises subnets định nghĩa, ngay cả qua private access (tính năng bắt buộc cho security).
• Toàn bộ kết hợp đảm bảo zero public exposure, chỉ VPC + on-premises subnets được phép. Đây là best practice theo docs GCP 2026.

🔍 Giải thích tất cả các phương án

Dưới đây là phân tích chi tiết từng lựa chọn giữ nguyên văn bản gốc:

• Create a GKE private cluster with a private endpoint for the control plane. Configure VPC Networking Peering export/import routes and custom route advertisements on the Cloud Routers. Configure authorized networks to specify the desired on-premises subnets.
  ✅ Đúng (như đã giải thích ở trên). Kết hợp đầy đủ private endpoint, route propagation/advertisement để on-premises route đúng, và authorized networks để whitelist subnets cụ thể. Hoàn hảo cho yêu cầu.

• Create a GKE private cluster with a public endpoint for the control plane. Configure VPC Networking Peering export/import routes and custom route advertisements on the Cloud Routers.
  ❌ Sai: Public endpoint expose control plane qua IP public (dù cluster private), cho phép truy cập từ internet (dù có routes). Không đáp ứng "private connectivity only". Routes thừa vì public không cần BGP cho control plane.

• Create a GKE private cluster with a private endpoint for the control plane. Configure authorized networks to specify the desired on-premises subnets.
  ❌ Sai: Thiếu route configuration (export/import + custom advertisements). On-premises không biết route đến private IP control plane (10.x/172.x), traffic không đến được dù có authorized networks. Chỉ authorized networks chưa đủ cho private routing qua Cloud Router.

• Create a GKE public cluster. Configure authorized networks to specify the desired on-premises subnets.
  ❌ Sai: Public cluster có control plane public IP, accessible từ internet toàn cầu (authorized networks chỉ restrict CIDR, không block hoàn toàn public). Không private, vi phạm yêu cầu "only from VPC and on-premises". Không cần/mention routes vì public.