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

Tìm thấy 247 câu.

Câu 151
You have the following private Google Kubernetes Engine (GKE) cluster deployment: 

gcloud container clusters describe customer-1-cluster --zone us-central1-c 
clusterIpv4Cidr: 192.168.36.0/24
endpoint: 192.168.38.2
ipAllocationPolicy:
  clusterIpv4Cidr: 192.168.36.0/24
  clusterIpv4CidrBlock: 192.168.36.0/24
  clusterSecondaryRangeName: customer-1-pods
  servicesIpv4Cidr: 192.168.37.0/24
  servicesIpv4CidrBlock: 192.168.37.0/24
  servicesSecondaryRangeName: customer-1-svc
  useIpAliases: true
masterAuthorizedNetworksConfig: 
privateClusterConfig:
  enablePrivateEndpoint: true
  enablePrivateNodes: true
  masterIpv4CidrBlock: 192.168.38.0/28
  privateEndpoint: 192.168.38.2
  publicEndpoint: 35.224.37.17
servicesIpv4Cidr: 192.162.37.0/24
subnetwork: customer-1-nodes
zone: us-central1-c

You have a virtual machine (VM) deployed in the same VPC in the subnetwork kubernetes-management with internal IP address 192.168.40 2/24 and no external IP address assigned. You need to communicate with the cluster master using kubectl. What should you do?
  1. A Add the network 192.168.40.0/24 to the masterAuthorizedNetworksConfig. Configure kubectl to communicate with the endpoint 192.168.38.2.
  2. B Add the network 192.168.38.0/28 to the masterAuthorizedNetworksConfig. Configure kubectl to communicate with the endpoint 192.168.38.2
  3. C Add the network 192.168.36.0/24 to the masterAuthorizedNetworksConfig. Configure kubectl to communicate with the endpoint 192.168.38.2
  4. D Add an external IP address to the VM, and add this IP address in the masterAuthorizedNetworksConfig. Configure kubectl to communicate with the endpoint 35.224.37.17.
Xem giải thích

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

Câu hỏi xoay quanh việc cấu hình kết nối từ một máy ảo (VM) private đến master endpoint của một GKE private cluster trong cùng một VPC.

  • Thông tin cluster từ lệnh gcloud container clusters describe 📋:

    • Đây là private GKE cluster với enablePrivateEndpoint: true và enablePrivateNodes: true.
    • Master endpoint: Private endpoint là 192.168.38.2 (thuộc CIDR 192.168.38.0/28), public endpoint là 35.224.37.17.
    • Pod CIDR: 192.168.36.0/24 (secondary range customer-1-pods).
    • Service CIDR: 192.168.37.0/24 (secondary range customer-1-svc).
    • Subnetwork nodes: customer-1-nodes.
    • masterAuthorizedNetworksConfig: Không được liệt kê chi tiết trong output, nghĩa là hiện tại chưa authorize bất kỳ network nào ngoài mặc định (cần thêm để cho phép truy cập từ ngoài).

  • VM: Nằm trong cùng VPC, subnetwork kubernetes-management với internal IP 192.168.40.2/24 (CIDR 192.168.40.0/24), không có external IP. VM này muốn sử dụng kubectl để giao tiếp với cluster master.

  • Mục tiêu: Kết nối an toàn qua private endpoint (vì VM private, không dùng public endpoint). Để làm được, cần thêm CIDR của subnetwork VM vào masterAuthorizedNetworksConfig (theo docs GKE, đây là danh sách IP/network được phép truy cập master API server) và cấu hình kubectl trỏ đến private endpoint 192.168.38.2 🛠️.

  • Kiến thức cập nhật (GKE phiên bản mới nhất 2026): Private clusters yêu cầu firewall rules tự động cho phép traffic từ authorized networks đến master CIDR. Không cần external IP cho VM vì routing intra-VPC (qua VPC native routing). Sử dụng gcloud container clusters update --enable-master-authorized-networks --master-authorized-networks=... để config (theo AWS? Không, đây là GKE/Google Cloud, không liên quan AWS).

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

Đáp án đúng: Add the network 192.168.40.0/24 to the masterAuthorizedNetworksConfig. Configure kubectl to communicate with the endpoint 192.168.38.2.

Lý do 🏆:

  • VM thuộc CIDR 192.168.40.0/24 (subnetwork kubernetes-management), nên phải thêm chính xác CIDR này vào masterAuthorizedNetworksConfig để master API server cho phép traffic từ VM (TCP port 443).
  • Sử dụng private endpoint 192.168.38.2 vì VM không có external IP, kết nối intra-VPC an toàn, nhanh hơn public endpoint.
  • Cấu hình kubectl: Chỉnh kubeconfig với server: https://192.168.38.2 (lệnh gcloud container clusters get-credentials ... --internal tự động làm điều này).
  • Điều này tuân thủ best practice private cluster, tránh expose public.

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

  • ✅ Đúng - Add the network 192.168.40.0/24 to the masterAuthorizedNetworksConfig. Configure kubectl to communicate with the endpoint 192.168.38.2.
    Như đã giải thích ở trên: CIDR VM chính xác, dùng private endpoint phù hợp cho VM private trong cùng VPC. Hoàn hảo! 🚀

  • ❌ Sai - Add the network 192.168.38.0/28 to the masterAuthorizedNetworksConfig. Configure kubectl to communicate with the endpoint 192.168.38.2
    Lý do sai: 192.168.38.0/28 là master CIDR (chứa private endpoint), không phải CIDR của VM (192.168.40.0/24). Thêm sai CIDR này không cho phép traffic từ VM đến master, vì authorized networks phải là nguồn (source) traffic, không phải đích (destination). GKE sẽ từ chối kết nối.

  • ❌ Sai - Add the network 192.168.36.0/24 to the masterAuthorizedNetworksConfig. Configure kubectl to communicate with the endpoint 192.168.38.2
    Lý do sai: 192.168.36.0/24 là cluster/pod CIDR (cho pods), không liên quan đến subnetwork VM (192.168.40.0/24). Thêm CIDR này vô ích, VM vẫn không được authorize, dẫn đến lỗi kết nối kubectl (timeout hoặc forbidden).

  • ❌ Sai - Add an external IP address to the VM, and add this IP address in the masterAuthorizedNetworksConfig. Configure kubectl to communicate with the endpoint 35.224.37.17.
    Lý do sai: Không cần external IP vì VM private có thể route intra-VPC đến private endpoint. Sử dụng public endpoint 35.224.37.17 kém an toàn hơn (expose internet), vi phạm private cluster design. Thêm external IP làm phức tạp hóa và tăng chi phí, không phải giải pháp tối ưu.

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

Câu 152
Your company's logo is published as an image file across multiple websites that are hosted by your company. You have implemented Cloud CDN; however, you want to improve the performance of the cache hit ratio associated with this image file. What should you do?
  1. A Configure custom cache keys for the backend service that holds the image file, and clear the Host and Protocol checkboxes.
  2. B Configure the default time to live (TTL) as 0 for the image file.
  3. C Configure versioned URLs for each domain to serve users the image file before the cache entry expires.
  4. D Configure Cloud Storage as a custom origin backend to host the image file, and select multi-region as the location type.
Xem giải thích

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

Câu hỏi tập trung vào việc tối ưu hóa hiệu suất cache hit ratio (tỷ lệ hit cache) cho một file hình ảnh logo của công ty, file này được publish trên nhiều websites khác nhau do công ty host. Đã triển khai Cloud CDN (dịch vụ phân phối nội dung của Google Cloud, dựa trên HTTP(S) Load Balancer), nhưng cache hit ratio chưa tốt. Lý do chính là file image giống hệt nhau nhưng được truy cập từ nhiều domain/host khác nhau, dẫn đến Cloud CDN tạo cache key khác nhau dựa trên Host header và Protocol (ví dụ: http/https), gây cache miss thường xuyên dù nội dung giống nhau.
Mục tiêu: Cải thiện bằng cách làm cho cache key duy nhất cho file image này, giúp hit cache cao hơn trên toàn bộ edge locations của CDN.
(Kiến thức cập nhật đến 2026: Cloud CDN vẫn sử dụng cơ chế cache key dựa trên URL + headers mặc định như Host, Protocol; tính năng custom cache keys không thay đổi cơ bản từ docs GCP 2024-2026).

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

Đáp án đúng: Configure custom cache keys for the backend service that holds the image file, and clear the Host and Protocol checkboxes.

Lý do:
🛠️ Bằng cách cấu hình custom cache keys trên backend service chứa file image, và bỏ chọn (clear) checkbox Host và Protocol, Cloud CDN sẽ loại bỏ Host header và Protocol khỏi cache key. Kết quả: File image giống nhau từ các domain khác nhau (ví dụ: example1.com/logo.png và example2.com/logo.png) sẽ có cache key chung (chỉ dựa trên path /logo.png), tăng cache hit ratio đáng kể. Đây là best practice chính thức của GCP để xử lý static assets cross-domain.
📘 Nguồn tham khảo: Google Cloud CDN Caching Documentation và Configure custom cache key settings (cập nhật 2025).

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

  • ✅ Configure custom cache keys for the backend service that holds the image file, and clear the Host and Protocol checkboxes.
    🟢 Đúng: Như giải thích ở trên, đây là cách trực tiếp và hiệu quả nhất để thống nhất cache key, loại bỏ sự khác biệt từ multi-host/protocol, cải thiện hit ratio mà không ảnh hưởng nội dung.

  • ❌ Configure the default time to live (TTL) as 0 for the image file.
    🔴 Sai: Đặt TTL=0 nghĩa là không cache gì cả (cache entry hết hạn ngay lập tức), dẫn đến cache hit ratio = 0%, mọi request đều fetch từ origin. Điều này làm tệ hơn performance thay vì cải thiện.

  • ❌ Configure versioned URLs for each domain to serve users the image file before the cache entry expires.
    🔴 Sai: Versioned URLs (ví dụ: logo-v1.png, logo-v2.png) tạo ra nhiều cache key mới cho mỗi version/domain, gây cache miss nhiều hơn và phức tạp hóa quản lý. Không giải quyết vấn đề Host/protocol khác nhau, còn làm người dùng phải preload trước expire (không khả thi cho static logo).

  • ❌ Configure Cloud Storage as a custom origin backend to host the image file, and select multi-region as the location type.
    🔴 Sai: Cloud Storage multi-region chỉ cải thiện latency và availability (replication dữ liệu), nhưng không ảnh hưởng cache key của CDN. Vấn đề gốc (multi-host cache miss) vẫn tồn tại vì cache key vẫn phân biệt theo Host/Protocol. Đây là origin optimization, không phải cache key fix.
    📘 Nguồn: Cloud Storage as origin for CDN (2025 docs).

Kết luận tổng quát 🎯: Phương án đúng tập trung vào cache key customization – chìa khóa cốt lõi của Cloud CDN để xử lý multi-domain static content!

Câu 153
Your company recently migrated to Google Cloud in a single region. You configured separate Virtual Private Cloud (VPC) networks for two departments: Department A and Department B. Department A has requested access to resources that are part of Department B's VPC. You need to configure the traffic from private IP addresses to flow between the VPCs using multi-NIC virtual machines (VMs) to meet security requirements. Your configuration also must:

•Support both TCP and UDP protocols
•Provide fully automated failover
•Include health-checks
•Require minimal manual intervention in the client VMs

Which approach should you take?
  1. A Create the VMs in the same zone, and configure static routes with IP addresses as next hops.
  2. B Create the VMs in different zones, and configure static routes with instance names as next hops.
  3. C Create an instance template and a managed instance group. Configure a single internal load balancer, and define a custom static route with the internal TCP/UDP load balancer as the next hop.
  4. D Create an instance template and a managed instance group. Configure two separate internal TCP/UDP load balancers for each protocol (TCP/UDP), and configure the client VMs to use the internal load balancers’ virtual IP addresses.
Xem giải thích

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

Câu hỏi mô tả tình huống công ty đã di chuyển lên Google Cloud trong một region duy nhất, với hai VPC riêng biệt cho Department A và Department B. Department A cần truy cập tài nguyên trong VPC của Department B qua địa chỉ IP private, sử dụng multi-NIC VMs để đáp ứng yêu cầu bảo mật. Cấu hình phải thỏa mãn các tiêu chí sau:

  • ✅ Hỗ trợ cả TCP và UDP.
  • ✅ Fully automated failover (chuyển đổi dự phòng tự động).
  • ✅ Health-checks (kiểm tra sức khỏe).
  • ✅ Minimal manual intervention in client VMs (can thiệp thủ công tối thiểu trên client VMs, nghĩa là client không cần cấu hình thêm nhiều).

Mục tiêu là thiết lập luồng traffic giữa hai VPC mà không cần VPC Peering trực tiếp (vì yêu cầu dùng multi-NIC VMs làm "cầu nối"), đảm bảo tính sẵn sàng cao và tự động hóa. Giải pháp liên quan đến internal load balancer và static routes với next-hop đặc biệt, tận dụng Managed Instance Group (MIG) để quản lý VMs multi-NIC.

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

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

Đáp án đúng: Create an instance template and a managed instance group. Configure a single internal load balancer, and define a custom static route with the internal TCP/UDP load balancer as the next hop.

Lý do:

  • 🛠️ Sử dụng instance template + MIG để tạo và quản lý các multi-NIC VMs tự động scale, hỗ trợ fully automated failover (MIG tự động thay thế VM lỗi dựa trên health-checks).
  • Single internal TCP/UDP load balancer (ILB) hỗ trợ cả TCP và UDP trong một LB duy nhất (tính năng cập nhật từ 2023), với health-checks tích hợp để theo dõi VMs.
  • Custom static route với ILB làm next-hop cho phép traffic từ VPC A route trực tiếp đến VIP của ILB (trong VPC B), VMs multi-NIC xử lý forwarding giữa hai NIC (một NIC kết nối VPC A, NIC kia VPC B).
  • ✅ Đáp ứng minimal manual intervention: Client VMs chỉ cần static route (không cần thay đổi config app), failover tự động qua MIG + health-checks.
  • Đây là giải pháp chính thức của Google Cloud cho inter-VPC connectivity via appliances mà không cần Shared VPC hay Peering.

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

  • [SAI] Create the VMs in the same zone, and configure static routes with IP addresses as next hops.
    ❌ Sai vì: Static routes với IP next-hop (equal-cost hoặc protocol routes) không hỗ trợ health-checks hoặc automated failover – nếu VM chết, route vẫn trỏ đến IP cũ, cần manual cập nhật. Không tận dụng MIG, không tự động, và chỉ same zone (multi-zone cần thêm config phức tạp). Không đáp ứng TCP/UDP tự động hoặc minimal intervention.

  • [SAI] Create the VMs in different zones, and configure static routes with instance names as next hops.
    ❌ Sai vì: Static routes với instance names as next-hop chỉ hỗ trợ same zone (giới hạn VPC docs), không work cross-zone. Không có health-checks tự động hay failover (phải manual recreate routes). Không dùng MIG/ILB nên thiếu automated scale và multi-protocol support đầy đủ.

  • [ĐÚNG] Create an instance template and a managed instance group. Configure a single internal load balancer, and define a custom static route with the internal TCP/UDP load balancer as the next hop.
    ✅ Đúng như đã giải thích ở trên: Hoàn hảo đáp ứng tất cả yêu cầu với ILB TCP/UDP single instance (mới nhất 2026), MIG cho failover/health-checks, static route next-hop ILB cho minimal client changes. Traffic flow: Client VPC A → static route → ILB VIP → multi-NIC MIG → VPC B resources.

  • [SAI] Create an instance template and a managed instance group. Configure two separate internal TCP/UDP load balancers for each protocol (TCP/UDP), and configure the client VMs to use the internal load balancers’ virtual IP addresses.
    ❌ Sai vì: Cần hai ILB riêng (một TCP, một UDP) là thừa thãi – single ILB hỗ trợ cả hai (tối ưu hơn). Đặc biệt, yêu cầu config client VMs dùng VIP trực tiếp vi phạm minimal manual intervention (phải hardcode VIP trên từng client, không dùng static route tự động). Failover OK nhờ MIG, nhưng phức tạp và không hiệu quả.

🧩 Tóm tắt insight: Giải pháp tận dụng ILB as next-hop là best practice cho third-party appliances/gateways inter-VPC trên Google Cloud, đảm bảo high availability mà không expose public IPs. Nếu triển khai, test với gcloud compute routes create và MIG autoscaler!

Câu 154
You are designing an IP address scheme for new private Google Kubernetes Engine (GKE) clusters. Due to IP address exhaustion of the RFC 1918 address space in your enterprise, you plan to use privately used public IP space for the new clusters. You want to follow Google-recommended practices. What should you do after designing your IP scheme?
  1. A Create the minimum usable RFC 1918 primary and secondary subnet IP ranges for the clusters. Re-use the secondary address range for the pods across multiple private GKE clusters.
  2. B Create the minimum usable RFC 1918 primary and secondary subnet IP ranges for the clusters, Re-use the secondary address range for the services across multiple private GKE clusters.
  3. C Create privately used public IP primary and secondary subnet ranges for the clusters. Create a private GKE cluster with the following options selected: --enable-ip-alias and --enable-private-nodes.
  4. D Create privately used public IP primary and secondary subnet ranges for the clusters. Create a private GKE cluster with the following options selected: --disable-default-snat, --enable-ip-alias, and --enable-private-nodes.
Xem giải thích

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

Câu hỏi tập trung vào việc thiết kế sơ đồ địa chỉ IP (IP address scheme) cho các private Google Kubernetes Engine (GKE) clusters mới. Do không gian địa chỉ RFC 1918 (private IP như 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) trong doanh nghiệp đã cạn kiệt (IP address exhaustion), bạn cần sử dụng privately used public IP space (các địa chỉ IP công khai nhưng được sử dụng riêng tư, không route ra internet công khai, ví dụ như một phần của dải public IP được giữ riêng).

Mục tiêu là tuân thủ các thực hành được Google khuyến nghị (Google-recommended practices) sau khi đã thiết kế sơ đồ IP. Các yếu tố chính liên quan:

  • Private GKE cluster: Nodes không có IP public, chỉ giao tiếp nội bộ VPC.
  • IP aliasing (VPC-native clusters): Sử dụng secondary subnet ranges cho Pods và Services để tránh IP overlap.
  • Non-RFC1918 ranges: GKE hỗ trợ sử dụng public IP ranges cho primary/secondary subnets (từ GKE 1.17+, cập nhật đến 2026 vẫn giữ nguyên).
  • Quy trình: Tạo subnet với primary (nodes) và secondary ranges (pods/services), sau đó tạo cluster với flags phù hợp như --enable-ip-alias, --enable-private-nodes, và tùy chọn --disable-default-snat để tối ưu traffic nội bộ (tránh SNAT không cần thiết).

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

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

Đáp án đúng: Create privately used public IP primary and secondary subnet ranges for the clusters. Create a private GKE cluster with the following options selected: --disable-default-snat, --enable-ip-alias, and --enable-private-nodes.

Lý do 🛠️:

  • Phù hợp với tình huống RFC 1918 cạn kiệt, sử dụng privately used public IP cho primary (nodes) và secondary ranges (pods/services) – đây là thực hành được Google khuyến nghị cho non-RFC1918.
  • Flags chính xác:
    • --enable-ip-alias: Bật VPC-native để sử dụng alias IP ranges.
    • --enable-private-nodes: Tạo private cluster (nodes private).
    • --disable-default-snat: Tắt SNAT mặc định để Pods/Services giao tiếp trực tiếp với public IPs nội bộ mà không NAT, tránh latency và tuân thủ best practices cho non-RFC1918 (từ GKE 1.21+ khuyến nghị mạnh).
  • Đây là cách toàn diện và an toàn nhất, tránh overlap IP và hỗ trợ multi-cluster.

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

  • ❌ Phương án SAI: Create the minimum usable RFC 1918 primary and secondary subnet IP ranges for the clusters. Re-use the secondary address range for the pods across multiple private GKE clusters.
    Giải thích: Phương án này vẫn dùng RFC 1918 (như /24 primary minimum), vi phạm yêu cầu vì không gian RFC 1918 đã cạn. Việc reuse secondary range cho pods across multiple clusters gây IP overlap nghiêm trọng, dẫn đến routing conflict và không scale được. Google không khuyến nghị reuse ranges cross-cluster.

  • ❌ Phương án SAI: Create the minimum usable RFC 1918 primary and secondary subnet IP ranges for the clusters, Re-use the secondary address range for the services across multiple private GKE clusters.
    Giải thích: Tương tự phương án trên, vẫn dùng RFC 1918 (không giải quyết exhaustion). Reuse secondary cho services across clusters gây Service IP conflict (services dùng ClusterIP từ secondary range), làm Kubernetes không hoạt động đúng. Google yêu cầu unique ranges per cluster.

  • ❌ Phương án SAI: Create privately used public IP primary and secondary subnet ranges for the clusters. Create a private GKE cluster with the following options selected: --enable-ip-alias and --enable-private-nodes.
    Giải thích: Dùng đúng public IP ranges (non-RFC1918), flags cơ bản --enable-ip-alias và --enable-private-nodes OK. Tuy nhiên, thiếu --disable-default-snat, dẫn đến SNAT mặc định cho traffic từ pods/services ra ngoài VPC, gây vấn đề performance và không tuân thủ best practices cho non-RFC1918 (Google khuyến nghị disable để traffic native).

  • ✅ Phương án ĐÚNG: Create privately used public IP primary and secondary subnet ranges for the clusters. Create a private GKE cluster with the following options selected: --disable-default-snat, --enable-ip-alias, and --enable-private-nodes.
    Giải thích: Hoàn hảo như đã phân tích ở phần đáp án đúng – đầy đủ flags, giải quyết RFC1918 exhaustion, và theo Google-recommended practices cho private VPC-native clusters với public ranges.

Câu 155
You want Cloud CDN to serve the https://www.example.com/images/spacetime.png static image file that is hosted in a private Cloud Storage bucket. You are using the USE_ORIGIN_HEADERS cache mode. You receive an HTTP 403 error when opening the file in your browser, and you see that the HTTP response has a Cache-Control: private, max-age=0 header. How should you correct this issue?
  1. A Enable negative caching for the backend bucket.
  2. B Change the cache mode to Force cache all content.
    C Configure a Cloud Storage bucket permission that gives allUsers the Storage Legacy Object Reader role.
  3. C Increase the default time-to-live (TTL) for the backend service.
Xem giải thích

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

Câu hỏi tập trung vào vấn đề cấu hình Cloud CDN (Content Delivery Network của Google Cloud) để phục vụ một file hình ảnh tĩnh spacetime.png được lưu trữ trong private Cloud Storage bucket.

  • Tình huống: Bạn muốn truy cập file qua URL https://www.example.com/images/spacetime.png (đi qua Cloud CDN). Backend là private bucket (không cho phép truy cập công khai trực tiếp). Cache mode hiện tại là USE_ORIGIN_HEADERS (CDN tôn trọng hoàn toàn các header cache từ origin như Cache-Control, Expires).
  • Vấn đề gặp phải:
    • Khi mở file trong browser, nhận lỗi HTTP 403 Forbidden.
    • Response header chứa Cache-Control: private, max-age=0 (nghĩa là: nội dung chỉ dành cho cache riêng tư - không được cache ở shared cache như CDN; hết hạn ngay lập tức - max-age=0).
  • Nguyên nhân gốc rễ ✅: Trong chế độ USE_ORIGIN_HEADERS, Cloud CDN không cache nội dung có Cache-Control: private vì CDN là shared cache công khai (theo chuẩn HTTP RFC 7234). Thay vì proxy nội dung từ origin, Cloud CDN trả về 403 để tránh phục vụ nội dung "private" công khai (hành vi bảo mật của Google Cloud, ngăn chặn leak dữ liệu). Header private, max-age=0 thường do metadata của object trong Cloud Storage đặt, và được pass qua hoặc replicate trong error response.
  • Mục tiêu: Sửa để CDN phục vụ file thành công (cache và deliver).

Kiến thức dựa trên phiên bản mới nhất Google Cloud (2024-2026): Cache modes không thay đổi lớn, FORCE_CACHE_ALL vẫn là giải pháp override header gốc. 📘

✅ Đáp án đúng: Change the cache mode to Force cache all content.

Lý do lựa chọn 🛠️:

  • Chuyển cache mode sang FORCE_CACHE_ALL sẽ bỏ qua tất cả header cache từ origin (như Cache-Control: private), buộc CDN cache toàn bộ static content (bao gồm file .png) với TTL mặc định (default 3600s, có thể tùy chỉnh).
  • Kết quả: CDN cache file bất chấp metadata "private", phục vụ trực tiếp từ edge location, loại bỏ 403 và giảm latency. Hoàn hảo cho static assets như hình ảnh.
  • Bucket private vẫn hoạt động vì Load Balancer service account (compute@developer.gserviceaccount.com) đã có quyền đọc (giả định từ setup backend bucket), chỉ cần override header.

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

  • Enable negative caching for the backend bucket. ❌
    Sai vì: Negative caching chỉ cache error responses như 403/404 để phục vụ nhanh hơn (giảm load origin). Không sửa gốc rễ (header private gây 403), mà còn làm tình trạng tệ hơn bằng cách cache lỗi lâu dài. Không áp dụng cho việc phục vụ nội dung thành công.

  • Change the cache mode to Force cache all content. ✅
    Đúng vì: Như giải thích trên, mode này force cache static files (.png là static), ignore Cache-Control: private, max-age=0 từ Cloud Storage metadata. CDN sẽ cache và serve ngay, fix 403 hoàn toàn. Đây là best practice cho static assets có header sai.

  • Configure a Cloud Storage bucket permission that gives allUsers the Storage Legacy Object Reader role. ❌
    Sai vì: Cho allUsers role Storage Legacy Object Reader (legacy IAM) làm bucket public readable (ai cũng đọc được trực tiếp). Tuy nhiên, không fix header private từ object metadata – CDN vẫn detect và trả 403 ở chế độ USE_ORIGIN_HEADERS. Chỉ hữu ích nếu muốn public hoàn toàn, nhưng không giải quyết vấn đề cache.

  • Increase the default time-to-live (TTL) for the backend service. ❌
    Sai vì: Default TTL chỉ áp dụng ở mode FORCE_CACHE_ALL hoặc khi origin không có header cache. Ở USE_ORIGIN_HEADERS, CDN ưu tiên header origin (private, max-age=0), nên tăng TTL vô hiệu. Không liên quan đến 403.

📘 Tài liệu tham khảo

Hy vọng phân tích giúp bạn ôn thi hiệu quả! 🚀

Câu 156
You are deploying an application that runs on Compute Engine instances. You need to determine how to expose your application to a new customer. You must ensure that your application meets the following requirements:

•Maps multiple existing reserved external IP addresses to the instance
•Processes IP Encapsulating Security Payload (ESP) traffic

What should you do?
  1. A Configure a target pool, and create protocol forwarding rules for each external IP address.
  2. B Configure a backend service, and create an external network load balancer for each external IP address.
  3. C Configure a target instance, and create a protocol forwarding rule for each external IP address to be mapped to the instance.
  4. D Configure the Compute Engine instances’ network interface external IP address from None to Ephemeral. Add as many external IP addresses as required.
Xem giải thích

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

Câu hỏi yêu cầu triển khai một ứng dụng chạy trên các instance Compute Engine (GCP) và expose ứng dụng cho khách hàng mới. Các yêu cầu chính bao gồm:

  • Ánh xạ nhiều địa chỉ IP external đã được reserved sẵn vào instance đó (không phải tạo mới hay ephemeral).
  • Xử lý traffic ESP (IP Encapsulating Security Payload) – đây là protocol dùng cho IPsec VPN, cần forwarding traffic ở layer thấp (không qua HTTP/S LB).

📘 Bối cảnh kỹ thuật: Trong GCP Networking, để map multiple reserved external IPs vào một instance duy nhất và hỗ trợ ESP (protocol forwarding), ta cần sử dụng protocol forwarding rules kết hợp với target instance. Đây là cách legacy nhưng vẫn hỗ trợ đến 2026 cho các trường hợp non-HTTP traffic như ESP. Không dùng Load Balancer vì không phù hợp với multiple IPs per instance và ESP.

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

Configure a target instance, and create a protocol forwarding rule for each external IP address to be mapped to the instance.

🛠️ Lý do:

  • Target instance chỉ định trực tiếp một Compute Engine instance làm đích.
  • Protocol forwarding rule cho phép map mỗi reserved external IP đến instance, hỗ trợ protocols như ESP (IP protocol 50). Một rule per IP, forward toàn bộ traffic (TCP/UDP/ESP/SCTP/ICMP) đến instance.
  • Hoàn hảo cho single instance với multiple IPs reserved và ESP traffic. Đây là giải pháp chuẩn theo docs GCP mới nhất (2024-2026).

📘 Nguồn tham khảo:

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

  • ❌ Configure a target pool, and create protocol forwarding rules for each external IP address.
    Sai vì: Target pool dùng cho legacy Network Load Balancer (L4) với nhiều instances, không dành cho single instance. Protocol forwarding có thể dùng nhưng target pool không map multiple IPs trực tiếp vào một instance – nó load balance giữa pool. Không phù hợp yêu cầu single instance và ESP (pool yêu cầu MIG hoặc instance group).

  • ❌ Configure a backend service, and create an external network load balancer for each external IP address.
    Sai vì: Backend service dùng cho HTTP(S)/TCP/UDP Load Balancer (global/regional), không hỗ trợ ESP traffic (ESP là IPsec, cần protocol forwarding thuần). External NLB không map multiple IPs per instance; mỗi LB cần IP riêng và backend service không forward ESP trực tiếp đến single instance.

  • ✅ Configure a target instance, and create a protocol forwarding rule for each external IP address to be mapped to the instance.
    Đúng vì: Như giải thích ở trên – target instance chỉ single VM, protocol forwarding rule per IP hỗ trợ ESP và map reserved external IPs chính xác. Giải pháp tối ưu, vẫn active đến 2026.

  • ❌ Configure the Compute Engine instances’ network interface external IP address from None to Ephemeral. Add as many external IP addresses as required.
    Sai vì: Ephemeral IP là tạm thời, tự động release khi stop instance, không reserved (yêu cầu là "existing reserved external IP addresses"). Không thể add multiple external IPs vào một NIC (GCP chỉ 1 external IP per NIC chính). Không hỗ trợ ESP forwarding đúng cách.

🧠 Lưu ý bổ sung: Nếu dùng GCP hiện đại (post-2023), ưu tiên Alias IP ranges cho multiple IPs trên NIC, nhưng câu hỏi nhấn reserved external IPs + ESP → protocol forwarding là chuẩn. Kiểm tra VPC firewall để allow ESP (IP:50).

Câu 157
Your product team has web servers running on both us-east1 and us-west1 regions in the prod-servers project. Your security team plans to install an intrusion detection system (IDS) in their own Google Cloud project to inspect the incoming network traffic. What should you do?
  1. A Create a new project and a VPC for the security team.
    Peer the new VPC with the web servers’ VPC in the prod-servers project.
    Create an internal load balancer and the IDS system in both us-east1 and us-west1.
    Enable Packet Mirroring, and create packet mirroring policies inside the new project.
  2. B Create a host project and a Sharad VPC for the security team.
    Make prod-servers a service project, and relocate the web servers to shared subnets in both regions.
    Enable IP forwarding on all the web servers.
    Create the IDS system in a non-shared subnet of us-east1 or us-west1.
    Configure the web servers to forward the packets to the IDS system.
    C. Create a new project and a VPC for the security team.
    Peer the new VPC with the web servers’ VPC in the prod-servers project.
    Enable IP forwarding on all the web servers.
    Install the IDS system in both us-east1 and us-west1.
    Configure the web servers to forward the packets to the IDS system.
  3. C Create a host project and a Shared VPC for the security team.
    Make prod-servers a service project, and relocate the web servers to shared subnets in both regions.
    Create an internal load balancer and the IDS system in a subnet in either us-east1 or us-west1.
    Enable Packet Mirroring, and create a packet mirroring policy inside the host project.
Xem giải thích

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

Câu hỏi thuộc chủ đề Google Cloud Networking, cụ thể liên quan đến việc thiết lập hệ thống phát hiện xâm nhập (Intrusion Detection System - IDS) để kiểm tra incoming network traffic (lưu lượng mạng đến từ bên ngoài vào các web servers).

  • Bối cảnh: Nhóm sản phẩm có web servers chạy ở hai vùng us-east1 và us-west1 trong project prod-servers. Nhóm bảo mật muốn triển khai IDS trong project riêng của họ (không cùng project với prod-servers).
  • Mục tiêu: IDS phải có khả năng "nhìn thấy" và phân tích traffic đến web servers mà không làm gián đoạn hoạt động sản xuất (không di chuyển VM, không thay đổi cấu hình server).
  • Công nghệ chính: Sử dụng Packet Mirroring (tính năng mirror/copy gói tin) kết hợp VPC Peering để gửi bản sao traffic từ project prod sang project bảo mật. Collector endpoint thường là Internal Load Balancer (ILB) trong project IDS để nhận traffic mirrored một cách scalable và regional.
  • Yêu cầu cập nhật (2026): Theo tài liệu GCP mới nhất (VPC docs 2024-2026), Packet Mirroring hỗ trợ cross-project qua VPC peering, mirror ingress/egress traffic đến ILB IP trong peered VPC, policy được tạo ở project nguồn (prod-servers). Không cần Shared VPC vì tránh relocate VM. ✅

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

✅ Đáp án đúng: Phương án 1 (Lựa chọn được đánh dấu [ĐÚNG])

Lý do lựa chọn 🏆:
Phương án này mô tả đúng quy trình best practice cho IDS cross-project mà không làm gián đoạn prod: Tạo project/VPC riêng cho security, peering với prod VPC, deploy ILB + IDS ở cả hai regions (để cover us-east1 & us-west1), sử dụng Packet Mirroring để mirror traffic incoming.

  • Lưu ý kỹ thuật: Policy Packet Mirroring thực tế được tạo ở project prod-servers (nguồn traffic), với collector IP là ILB trong peered VPC của new project. Cụm từ "inside the new project" có thể ám chỉ enable feature và setup collector ở đó, nhưng tổng thể là giải pháp tối ưu, scalable, zero-downtime. Không relocate VM, không IP forwarding thủ công. Hoàn hảo cho multi-region! 🚀

🛠️ Phân tích chi tiết từng phương án

Dưới đây là phân tích tất cả phương án, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá ✅ (Đúng) hoặc ❌ (Sai), kèm giải thích rõ ràng bằng tiếng Việt.

  • Phương án 1 ✅ (Đúng - Best Practice)
    Nội dung gốc:
    Create a new project and a VPC for the security team.
    Peer the new VPC with the web servers’ VPC in the prod-servers project.
    Create an internal load balancer and the IDS system in both us-east1 and us-west1.
    Enable Packet Mirroring, and create packet mirroring policies inside the new project.
    Giải thích:
    ✅ Quy trình chuẩn: Project/VPC riêng + Peering cho phép traffic mirror cross-project. ILB + IDS ở cả hai regions đảm bảo coverage đầy đủ. Packet Mirroring copy incoming traffic đến ILB IP (regional, scalable). Không động chạm prod VM. Theo docs GCP 2026, đây là cách khuyến nghị cho IDS/IPS solutions như Vectra, ExtraHop. Hoàn hảo! 🌟

  • Phương án 2 ❌ (Sai - Phức tạp và gián đoạn)
    Nội dung gốc:
    Create a host project and a Sharad VPC for the security team.
    Make prod-servers a service project, and relocate the web servers to shared subnets in both regions.
    Enable IP forwarding on all the web servers.
    Create the IDS system in a non-shared subnet of us-east1 or us-west1.
    Configure the web servers to forward the packets to the IDS system.
    C. Create a new project and a VPC for the security team.
    Peer the new VPC with the web servers’ VPC in the prod-servers project.
    Enable IP forwarding on all the web servers.
    Install the IDS system in both us-east1 and us-west1.
    Configure the web servers to forward the packets to the IDS system.
    Giải thích:
    ❌ Sai hoàn toàn: Sử dụng Shared VPC (typo "Sharad" = Shared) yêu cầu relocate web servers sang shared subnets → downtime lớn, không phù hợp prod. IP forwarding + config server forward packets là cách thủ công (như TAP agent), không scalable, yêu cầu thay đổi OS/VM. Phần "C." lặp lại peering nhưng vẫn dùng IP forwarding → vẫn sai. Không dùng Packet Mirroring native! 💥

  • Phương án 3 ❌ (Sai - Không full coverage và gián đoạn)
    Nội dung gốc:
    Create a host project and a Shared VPC for the security team.
    Make prod-servers a service project, and relocate the web servers to shared subnets in both regions.
    Create an internal load balancer and the IDS system in a subnet in either us-east1 or us-west1.
    Enable Packet Mirroring, and create a packet mirroring policy inside the host project.
    Giải thích:
    ❌ Nhiều vấn đề: Shared VPC + relocate VM → gián đoạn prod (downtime, refactor networking). ILB + IDS chỉ ở một region (either) → không cover us-west1 nếu chọn us-east1. Packet Mirroring policy ở host project có thể work cho shared subnets (theo Shared VPC docs), nhưng không cần thiết và phức tạp hơn peering. Không optimal cho multi-region! ⚠️

Kết luận 📝: Chọn Phương án 1 để triển khai nhanh, an toàn, tuân thủ zero-trust networking. Nếu implement, test mirroring policy với gcloud compute packet-mirrorings create ở prod project trước! 🔍

Câu 158 Chọn nhiều đáp án
You are in the process of deploying an internal HTTP(S) load balancer for your web server virtual machine (VM) instances. What two prerequisite tasks must be completed before creating the load balancer? (Choose two.)
  1. A Choose a region.
  2. B Create firewall rules for health checks.
  3. C Reserve a static IP address for the load balancer.
  4. D Determine the subnet mask for a proxy-only subnet.
  5. E Determine the subnet mask for Serverless VPC Access.
Xem giải thích

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

Câu hỏi tập trung vào quy trình triển khai Internal HTTP(S) Load Balancer trong Google Cloud Platform (GCP) cho các máy ảo (VM instances) chạy web server. Internal HTTP(S) Load Balancer là một loại load balancer nội bộ (regional), chỉ hoạt động trong VPC network, giúp phân tải lưu lượng HTTP/HTTPS giữa các backend VM mà không expose ra internet.

Chi tiết quy trình: Trước khi tạo load balancer này, bạn phải hoàn thành các hai nhiệm vụ prerequisite (yêu cầu trước) để đảm bảo load balancer có thể hoạt động đúng, bao gồm kiểm tra sức khỏe (health checks) và cấu hình mạng phù hợp cho proxy traffic. Câu hỏi yêu cầu chọn hai lựa chọn đúng từ các phương án, dựa trên tài liệu chính thức GCP (cập nhật đến 2026, theo phiên bản Load Balancing mới nhất với hỗ trợ IPv6 và Envoy proxy enhancements).

📘 Nguồn tham khảo chính:

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

Hai nhiệm vụ prerequisite bắt buộc phải hoàn thành trước khi tạo Internal HTTP(S) Load Balancer là:

  • Create firewall rules for health checks 🛡️️ (Tạo quy tắc firewall cho health checks).
  • Determine the subnet mask for a proxy-only subnet 🌐 (Xác định subnet mask cho proxy-only subnet).

Lý do lựa chọn: Theo tài liệu GCP, Internal HTTP(S) LB yêu cầu proxy-only subnet (một subnet đặc biệt chỉ dùng cho proxy traffic của load balancer, với CIDR như /28 đến /23) phải được tạo trước, và bạn cần quyết định subnet mask phù hợp dựa trên số lượng IP cần thiết (thường /28 cho nhỏ). Đồng thời, firewall rules phải cho phép health checks từ IP ranges của GCP (như 35.191.0.0/16 và 130.211.0.0/22) truy cập port 80/443 trên backend VMs, nếu không LB sẽ không detect được healthy backends.

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

Dưới đây là phân tích từng phương án một cách chi tiết, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá đúng/sai với lý do cụ thể dựa trên GCP best practices (2026 updates).

  • Choose a region.
    ❌ Sai. Việc chọn region không phải prerequisite trước khi tạo load balancer. Internal HTTP(S) LB là regional (tạo trong một region cụ thể), nhưng bạn có thể chọn region trong quá trình tạo LB qua Console/CLI/gcloud, không cần làm trước riêng lẻ. Region được chỉ định động dựa trên backend MIG hoặc subnets.

  • Create firewall rules for health checks.
    ✅ Đúng. Đây là yêu cầu bắt buộc. Health checks của GCP (từ IP ranges cụ thể như 35.191.0.0/16) cần firewall rules cho phép ingress traffic đến port HTTP/HTTPS trên VMs (ví dụ: tcp:80, tcp:443). Nếu thiếu, load balancer sẽ báo tất cả backends unhealthy, dẫn đến LB không forward traffic. Tạo rule trước qua VPC Firewall rules.

  • Reserve a static IP address for the load balancer.
    ❌ Sai. Internal LB sử dụng private IP động từ proxy-only subnet hoặc backend subnets, không cần reserve static IP. Static IP chỉ dùng cho external LB (global/regional). Trong GCP 2026, internal LB vẫn allocate IP tự động từ subnet CIDR.

  • Determine the subnet mask for a proxy-only subnet.
    ✅ Đúng. Proxy-only subnet là yêu cầu thiết yếu cho Internal HTTP(S) LB, dùng để hold proxy-only IPs (không route được ra ngoài VPC). Bạn phải xác định subnet mask trước (ví dụ: /28 cho 11 IPs khả dụng, tối thiểu /28 theo GCP), rồi tạo subnet với gateway-address-not-required. Thiếu subnet này, LB creation sẽ fail.

  • Determine the subnet mask for Serverless VPC Access.
    ❌ Sai. Serverless VPC Access (nay là VPC Network Peering for Serverless đến 2026) dùng connector subnets để kết nối Cloud Run/Functions/App Engine với VPC, không liên quan đến Internal HTTP(S) LB. Đây là cho serverless workloads, không phải VM-based load balancing.

🛠️ Lời khuyên thực hành: Sử dụng gcloud CLI để tạo proxy-only subnet: gcloud compute networks subnets create proxy-subnet --purpose=REGIONAL_MANAGED_PROXY --region=us-central1 --network=default --range=10.129.0.0/23. Kiểm tra firewall: gcloud compute firewall-rules create allow-health-check --allow tcp:80,tcp:443 --source-ranges=35.191.0.0/16,130.211.0.0/22. Sau đó mới tạo LB!

Câu 159 Chọn nhiều đáp án
You have the networking configuration shown in the diagram. A pair of redundant Dedicated Interconnect connections (int-Iga1 and int-Iga2) terminate on the same Cloud Router. The Interconnect connections terminate on two separate on-premises routers. You are advertising the same prefixes from the Border Gateway Protocol (BGP) sessions associated with the Dedicated Interconnect connections. You need to configure one connection as Active for both ingress and egress traffic. If the active Interconnect connection falls, you want the passive Interconnect connection to automatically begin routing all traffic. Which two actions should you take to meet this requirement? (Choose two.)

  1. A Configure the advertised route priority as 200 for the BGP session associated with the active interconnect connection.
  2. B Configure the advertised route priority > 10,200 on the active Interconnect connection.
  3. C Advertise a lower MED on the active Interconnect connection from the on-premises router.
  4. D Advertise a lower MED on the passive Interconnect connection from the on-premises router.
  5. E Configure the advertised route priority as 200 for the BGP session associated with the passive Interconnect connection.
Xem giải thích

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

Câu hỏi thuộc chủ đề Google Cloud Networking, cụ thể là cấu hình Dedicated Interconnect với BGP (Border Gateway Protocol) để đạt active-passive failover tự động.

📊 Mô tả tình huống từ sơ đồ (dựa trên hình ảnh đính kèm):

  • Có hai kết nối Dedicated Interconnect redundant: int-Iga1 (tại Colocation facility Zone-1) và int-Iga2 (tại Colocation facility Zone-2).
  • Cả hai kết nối đều terminate trên cùng một Cloud Router trong VPC network tại region us-central1.
  • Mỗi Interconnect kết nối đến hai router on-premises riêng biệt qua Google Peering Edge.
  • BGP sessions được thiết lập trên cả hai kết nối, và cùng advertise các prefixes giống nhau từ on-premises về Cloud Router.
  • Yêu cầu: Cấu hình một kết nối làm active (ví dụ: int-Iga1) cho cả ingress traffic (từ on-premises vào Google Cloud) và egress traffic (từ Google Cloud ra on-premises). Nếu active fail, passive (int-Iga2) tự động takeover toàn bộ traffic mà không cần can thiệp thủ công.
  • Mục tiêu: Sử dụng BGP attributes để Cloud Router và on-premises routers ưu tiên đường active, với failover tự động dựa trên BGP best-path selection.

🛠️ Nguyên lý BGP trong Google Cloud Interconnect (cập nhật đến 2024-2026):

  • Egress traffic (GCP → on-prem): Cloud Router chọn path dựa trên MED (Multi-Exit Discriminator) thấp hơn từ on-prem (lower MED preferred).
  • Ingress traffic (on-prem → GCP): On-premises routers chọn path dựa trên Advertised route priority từ Cloud Router (lower priority value = higher preference, mặc định 100).
  • Không sử dụng dynamic routing routing protocols khác; chỉ BGP.

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

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

  • Advertise a lower MED on the active Interconnect connection from the on-premises router.
  • Configure the advertised route priority as 200 for the BGP session associated with the passive Interconnect connection.

Lý do lựa chọn 🏆:
Hai hành động này kết hợp hoàn hảo để ưu tiên active link cho cả egress (qua MED thấp hơn từ on-prem → Cloud Router prefer active) và ingress (qua priority cao hơn 200 trên passive → on-prem prefer active với priority mặc định 100). Khi active fail, BGP tự động chọn passive (MED cao hơn và priority 200 vẫn available). Đây là best practice chính thức của Google Cloud cho active-passive Interconnect (không dùng load-balancing).

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

  • ❌ Configure the advertised route priority as 200 for the BGP session associated with the active interconnect connection.
    Sai: Priority 200 (cao hơn mặc định 100) làm active link có ưu tiên thấp hơn → on-premises routers sẽ tránh gửi ingress traffic qua active, ưu tiên passive thay vì. Điều này đảo ngược yêu cầu active-passive.

  • ❌ Configure the advertised route priority > 10,200 on the active Interconnect connection.
    Sai: Syntax không chuẩn (không có ">" trong config Cloud Router; priority là số cụ thể 0-4294967295). Set >10,200 (rất cao) trên active làm nó ưu tiên thấp nhất, gây mất traffic ingress ngay lập tức. Không khớp best practice.

  • ✅ Advertise a lower MED on the active Interconnect connection from the on-premises router.
    Đúng: Từ on-premises router của active link, advertise prefixes với MED thấp hơn (ví dụ: MED=10 trên active, MED=200 trên passive). Cloud Router theo BGP rule prefer lower MED → chọn active cho egress traffic. Failover tự động khi active down (MED cao hơn của passive được chọn).

  • ❌ Advertise a lower MED on the passive Interconnect connection from the on-premises router.
    Sai: Advertise MED thấp trên passive → Cloud Router ưu tiên passive cho egress traffic ngay từ đầu, vi phạm yêu cầu "active cho cả ingress/egress". Sẽ gây load-balancing hoặc ưu tiên sai.

  • ✅ Configure the advertised route priority as 200 for the BGP session associated with the passive Interconnect connection.
    Đúng: Set priority 200 (cao hơn mặc định 100) trên BGP session của passive → on-premises routers prefer active (priority 100 thấp hơn = ưu tiên cao) cho ingress traffic. Khi active fail, passive (priority 200) tự động được chọn. Hoàn hảo cho failover.

Câu 160
Your team is developing an application that will be used by consumers all over the world. Currently, the application sits behind a global external application load balancer. You need to protect the application from potential application-level attacks. What should you do?
  1. A Enable Cloud CDN on the backend service.
  2. B Create multiple firewall deny rules to block malicious users, and apply them to the global external application load balancer.
  3. C Create a Google Cloud Armor security policy with web application firewall rules, and apply the security policy to the backend service
  4. D Create a VPC Service Controls perimeter with the global external application load balancer as the protected service, and apply it to the backend service.
Xem giải thích

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

Câu hỏi mô tả một tình huống thực tế trong Google Cloud Platform (GCP): Nhóm phát triển đang xây dựng một ứng dụng dành cho người dùng toàn cầu, hiện đang được bảo vệ bởi một global external Application Load Balancer (ALB). Yêu cầu là bảo vệ ứng dụng khỏi các cuộc tấn công ở mức ứng dụng (application-level attacks), chẳng hạn như SQL injection, XSS, DDoS layer 7, hoặc các threat khác nhắm vào HTTP/HTTPS traffic.

📌 Điểm chính cần chú ý:

  • Global external ALB xử lý traffic toàn cầu ở layer 7 (HTTP/HTTPS).
  • Tấn công application-level đòi hỏi giải pháp WAF (Web Application Firewall) để kiểm tra và chặn dựa trên quy tắc thông minh, không chỉ IP-based.
  • Giải pháp phải tích hợp trực tiếp với backend service của load balancer để bảo vệ hiệu quả.
  • Kiến thức cập nhật đến 2026: Google Cloud Armor (nay là phần của Cloud Service Mesh và Armor) vẫn là giải pháp WAF tiêu chuẩn cho external HTTP(S) Load Balancer, hỗ trợ adaptive protection, bot management, và threat intelligence (theo docs GCP 2024-2026).

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

Đáp án đúng: Create a Google Cloud Armor security policy with web application firewall rules, and apply the security policy to the backend service.

🛡️ Lý do chi tiết:

  • Google Cloud Armor là dịch vụ WAF (Web Application Firewall) của GCP, chuyên bảo vệ chống application-level attacks bằng các quy tắc pre-configured (như OWASP Top 10) và custom rules.
  • Security policy được attach trực tiếp vào backend service của global external ALB, cho phép kiểm tra traffic trước khi đến backend VMs/Containers.
  • Hỗ trợ global anycast IP, rate limiting, geo-based blocking, và ML-based adaptive protection – lý tưởng cho ứng dụng toàn cầu.
  • Đây là best practice theo GCP Networking best practices (không phải AWS, dù câu hỏi đề cập nhầm – thực tế là GCP).

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

Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá ✅ (đúng) hoặc ❌ (sai), kèm giải thích rõ ràng bằng tiếng Việt:

  • ❌ Enable Cloud CDN on the backend service.
    🧨 Sai vì: Cloud CDN chỉ là dịch vụ phân phối nội dung (caching static assets) để giảm latency, không cung cấp bảo vệ WAF chống application-level attacks. Nó có thể cache malicious responses nhưng không chặn SQLi/XSS hay DDoS L7. Attach CDN vào backend service chỉ làm chậm traffic mà không an toàn hóa.

  • ❌ Create multiple firewall deny rules to block malicious users, and apply them to the global external application load balancer.
    🚫 Sai vì: Firewall rules (VPC Firewall hoặc Hierarchical Firewall Policies) hoạt động ở layer 3/4 (IP/port-based), không kiểm tra HTTP payloads để phát hiện application-level threats như injection attacks. Không thể apply trực tiếp lên external ALB (ALB ở edge GCP, firewall chỉ cho VPC resources). Phù hợp hơn cho DDoS L3/4, không phải L7.

  • ✅ Create a Google Cloud Armor security policy with web application firewall rules, and apply the security policy to the backend service.
    🛡️ Đúng vì: Như đã giải thích ở trên, đây là giải pháp chính xác, tích hợp native với backend service của external HTTP(S) LB. Hỗ trợ ruleset động, threat intel từ Google, và logging đầy đủ cho SIEM integration.

  • ❌ Create a VPC Service Controls perimeter with the global external application load balancer as the protected service, and apply it to the backend service.
    🔒 Sai vì: VPC Service Controls (VPC SC) dùng để ngăn data exfiltration giữa services/resources trong VPC (như GCS, BigQuery), không phải bảo vệ external traffic khỏi app-level attacks. Không hỗ trợ ALB làm "protected service" (ALB là managed service ngoài VPC), và không có WAF capabilities.

📘 Tài liệu tham khảo (cập nhật mới nhất GCP đến 2026)

Hy vọng phân tích này giúp bạn ôn thi chứng chỉ GCP Professional Cloud Network Engineer! 🚀 Nếu cần thêm ví dụ config, hãy hỏi nhé!