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

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

Câu hỏi tập trung vào việc cấu hình dịch vụ Intrusion Prevention Service (IPS) trên Cloud Next Generation Firewall (NGFW) Enterprise của Google Cloud. Bạn đã triển khai các firewall endpoints và cần kiểm tra (inspect) lưu lượng mạng của các VM.

🔍 Chi tiết ngữ cảnh:

• NGFW Enterprise là giải pháp firewall thế hệ mới trên Google Cloud, hỗ trợ IPS để phát hiện và chặn các cuộc tấn công mạng thời gian thực.
• Firewall endpoints được triển khai để bảo vệ traffic giữa các VM (Virtual Machines) trong VPC.
• Mục tiêu là hướng traffic từ VMs qua firewall endpoints để áp dụng IPS, thay vì chỉ mirror hoặc chain rules thông thường.
• Kiến thức cập nhật đến 2026: Theo tài liệu Google Cloud mới nhất (NGFW Enterprise GA từ 2023, cập nhật IPS profiles trong phiên bản 2025-2026), traffic inspect yêu cầu firewall rule match IP của VMs và apply security profile group chứa IPS.

📘 Nguồn tham khảo:

• Google Cloud NGFW Enterprise Documentation
• IPS Configuration Guide

✅ Đáp án đúng

Configure a firewall rule to match the source/destination IP addresses của the VMs, and use the apply_security_profile_group action.

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

• Đây là cách chuẩn xác để inspect traffic: Firewall rule match source/destination IP của VMs để capture đúng traffic, sau đó apply_security_profile_group kích hoạt IPS (và các profile khác như antivirus, URL filtering).
• IPS chỉ hoạt động khi traffic được proxied qua security profile group, không phải chỉ mirror hay goto_next.
• Phù hợp với best practice của Google Cloud cho hierarchical firewall policy trong NGFW Enterprise.

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

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 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 tài liệu Google Cloud.

• ❌ [SAI] Configure Packet Mirroring to match the source/destination IP addresses of the VMs.
  Phân tích: Packet Mirroring chỉ dùng để sao chép (mirror) traffic gửi đến công cụ monitoring bên ngoài (như SIEM), không inspect hay chặn bằng IPS. Nó không route traffic qua firewall endpoints để áp dụng security profiles, dẫn đến không kích hoạt IPS trên VMs. (Không phù hợp cho IPS real-time blocking).

• ❌ [SAI] Configure a firewall rule to match the source/destination IP addresses of the VMs, and use the goto_next action.
  Phân tích: goto_next chỉ chuyển tiếp traffic đến rule tiếp theo trong policy chain, không apply IPS. Rule này match IP đúng nhưng thiếu action để inspect (như security profile). Traffic sẽ bypass IPS mà không được kiểm tra sâu.

• ❌ [SAI] Configure a firewall rule to match the hostnames of the VMs, and use the apply_security_profile_group action.
  Phân tích: apply_security_profile_group đúng action cho IPS, nhưng match hostnames không khả thi ở layer 3/4 firewall rules của NGFW Enterprise (chỉ hỗ trợ IP/CIDR, tags, regions). Hostnames cần DNS resolution ở layer 7, không dùng cho VM traffic inspect cơ bản – dẫn đến rule không match traffic VMs hiệu quả.

• ✅ [ĐÚNG] Configure a firewall rule to match the source/destination IP addresses of the VMs, and use the apply_security_profile_group action.
  Phân tích: Hoàn hảo! Match IP addresses chính xác capture traffic VMs, kết hợp apply_security_profile_group để enable IPS inspection (với threat prevention profiles). Đây là bước bắt buộc trong setup NGFW endpoints cho VM protection, đảm bảo deep packet inspection và blocking tự động.

Hy vọng phân tích này giúp bạn nắm vững NGFW Enterprise! 🚀 Nếu cần ví dụ config chi tiết, hãy hỏi thêm nhé!

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

Câu hỏi mô tả tình huống: Tổ chức của bạn vừa expose một bộ dịch vụ qua global external Application Load Balancer (ALB) trên Google Cloud Platform (GCP). Sau khi test, bạn nhận thấy phản hồi ngắt quãng với mã lỗi HTTP 4xx (lỗi client) hoặc 5xx (lỗi server). Bạn đã enable và review health check logs nhưng vẫn cần xác định nguyên nhân lỗi.
Mục tiêu: Tìm cách identify the error một cách chính xác và hiệu quả nhất.
🛠️ Bối cảnh kỹ thuật (dựa trên GCP Load Balancing mới nhất 2024-2026): Global external ALB xử lý L7 traffic, health checks kiểm tra backend VMs/Instance Groups. Lỗi 4xx/5xx có thể do backend unhealthy, config sai, logging chưa enable, hoặc policies như Cloud Armor. Health check logs chỉ show backend health, không chi tiết error response → cần logging backend service để xem statusDetails trong Cloud Logging (tính năng logging chi tiết cho backend errors từ phiên bản mới nhất).

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

Đáp án đúng: Validate the health of the backend service. Enable logging for the backend service and identify the error response in Cloud Logging. Review the statusDetails log field.

Lý do:

• ✅ Validate health backend service: Xác nhận backend (Instance Group hoặc NEG) healthy qua Health Check dashboard.
• ✅ Enable logging cho backend service: Backend service logging (trong GCP Console > Load Balancing > Backend Services) capture chi tiết HTTP response codes, headers, và statusDetails (field mới nhất cung cấp lý do cụ thể lỗi 4xx/5xx như "BACKEND_FAILED_TO_HANDLE_REQUEST" hoặc "ORIGIN_UNAVAILABLE").
• ✅ Review statusDetails in Cloud Logging: Logs filterable, giúp pinpoint lỗi chính xác (ví dụ: timeout, overload). Đây là bước best practice theo GCP troubleshooting guide cho intermittent errors sau health checks. Không xâm phạm config, nhanh chóng.
  🛠️ Hiệu quả cao: Giải quyết trực tiếp mà không thay đổi architecture.

📋 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, giữ nguyên văn bản gốc tiếng Anh:

• ❌ [SAI] Access a VM in the VPC through SSH to access the backend VM directly. If the request is successful from the VM, increase the quantity of backends.
  Phương án này sai vì: SSH thủ công chỉ test isolated, không simulate load balancer traffic (proxy headers, session affinity). Nếu thành công thì tăng backends? → Không giải quyết root cause như config sai hoặc overload intermittent. Rủi ro security (SSH expose), không scalable, vi phạm least privilege. Không dùng logging → không identify error chính xác.

• ❌ [SAI] Delete the load balancer and backend services. Create a new Passthrough Network Load Balancer. Configure a failover group of VMs for the backend.
  Phương án này sai vì: Thay đổi từ Application LB (L7, global) sang Passthrough Network LB (L4, regional) là overkill, phá hủy config hiện tại (URLs, SSL, paths). Failover group chỉ cho MIGs, không fix 4xx/5xx mà có thể do backend logic. Dùng Network LB mất features ALB như content-based routing. Không validate logging trước → disruptive, downtime cao.

• ✅ [ĐÚNG] Validate the health of the backend service. Enable logging for the backend service and identify the error response in Cloud Logging. Review the statusDetails log field.
  Như đã giải thích ở phần đáp án đúng: Bước chuẩn theo GCP best practices, enable logging nhanh (1-click), statusDetails cung cấp insight sâu (ví dụ: "RESPONSE_SENT_BY_BACKEND" với mã lỗi cụ thể). Không downtime, chính xác cao.

• ❌ [SAI] Validate the health of the backend service. Disable any Cloud Armor policies on the backend service, and identify any error response in Cloud Logging. Review the statusDetails log field.
  Phương án này sai vì: Disable Cloud Armor (WAF) assume lỗi do policies (block 4xx), nhưng câu hỏi không đề cập Cloud Armor → premature optimization. Có thể làm expose lỗ hổng security. Validate health + logging là đúng, nhưng disable policy là unnecessary step đầu tiên; nên check logs trước để confirm nếu Cloud Armor gây lỗi (statusDetails sẽ show "CLOUDFLOOD_BLOCKED").

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

• GCP Load Balancing Logging: cloud.google.com/load-balancing/docs/backend-service#logging → Chi tiết statusDetails field.
• Troubleshoot ALB Errors: cloud.google.com/load-balancing/docs/https/verify-response → Health checks + backend logging.
• Cloud Logging for Load Balancers: cloud.google.com/logging/docs/view/advanced-queries#statusdetails → Query logs mới nhất.
• Cloud Armor Troubleshooting: cloud.google.com/armor/docs/troubleshooting → Xác nhận không disable ngay.

Hy vọng phân tích giúp bạn nắm vững! 🚀 Nếu cần lab thực hành, dùng GCP Console demo backend logging.

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

Câu hỏi mô tả một kiến trúc mạng hiện tại của công ty với hai VPC (Virtual Private Cloud) được kết nối qua một instance dual-NIC (hai network interface) hoạt động như một bump-in-the-wire firewall (tức là một thiết bị trung gian kiểm soát lưu lượng giữa hai VPC mà không thay đổi địa chỉ IP nguồn/đích). Các luồng dữ liệu (flows) giữa các cặp subnet ở hai VPC đang hoạt động bình thường. Bất ngờ, có cảnh báo rằng tất cả các luồng giữa hai VPC ngừng hoạt động. Nhiệm vụ là khắc phục sự cố (troubleshoot), và cần chọn hai hành động phù hợp nhất.

🔍 Bối cảnh kỹ thuật (dựa trên Google Cloud VPC mới nhất đến 2026):

• Dual-NIC instance thường dùng cho các setup firewall tùy chỉnh (như với NGINX, pfSense), yêu cầu IP forwarding được kích hoạt để route traffic.
• Vấn đề đột ngột thường do thay đổi config (firewall rules, instance attributes) hoặc policy (như VPC Service Controls - VPC-SC).
• Không liên quan đến public IP hay backend service vì đây là internal traffic giữa VPCs.

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

• Google Cloud VPC Networking Docs (cập nhật 2024-2026: VPC Firewall Rules & IP Forwarding).
• Troubleshoot VPC Peering & Gateways.
• VPC Service Controls Overview.

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

Hai đáp án đúng là:

1. Use Cloud Logging to verify that there were no modifications to the VPC firewall rules or policies that were applied to the two network interfaces of the dual-NIC instance.
2. Verify that the dual-Nic instance has the --can-Ip-Forward attribute enabled.

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

• Vấn đề xảy ra đột ngột sau khi flows đang work tốt, nên ưu tiên kiểm tra thay đổi gần đây qua Cloud Logging (logs firewall rules/policies trên hai NIC). Đây là bước troubleshoot đầu tiên theo best practice GCP.
• Dual-NIC instance cần --can-ip-forward (gcloud compute instances set-tagging hoặc metadata) để forward traffic giữa NICs. Nếu bị disable (do auto-config hoặc thay đổi), toàn bộ flows sẽ drop ngay lập tức – khớp với triệu chứng "none of the flows working".

📋 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 một cách chi tiết:

• ❌ Verify that a VPC Service Controls perimeter has not been enabled for the project that contains the two VPCs and the dual-NIC instance.
  Sai vì: VPC Service Controls (VPC-SC) dùng để bảo vệ dữ liệu nhạy cảm bằng cách tạo perimeter giới hạn data exfiltration, nhưng nó không block traffic nội bộ giữa VPCs trong cùng project trừ khi config explicit dry-run hoặc egress rules chặn flows cụ thể. Flows đang work trước đó, và VPC-SC thường không gây drop đột ngột toàn bộ traffic giữa subnets mà không có alert riêng. Không phải bước troubleshoot ưu tiên đầu tiên.

• ✅ Use Cloud Logging to verify that there were no modifications to the VPC firewall rules or policies that were applied to the two network interfaces of the dual-NIC instance.
  Đúng vì: Cloud Logging (trước là Stackdriver) ghi lại tất cả thay đổi firewall rules, hierarchical firewall policies, và VPC Network tags áp dụng lên NICs. Với dual-NIC, mỗi NIC thuộc VPC riêng, nên rules thay đổi (allow/deny) có thể drop flows đột ngột. Bước này xác định root cause nhanh chóng qua query logs (ví dụ: resource.type="gce_firewall_rule").

• ❌ Verify that a public IP address has not been assigned to any network interface of the dual-NIC instance.
  Sai vì: Public IP chỉ ảnh hưởng external traffic (internet), không liên quan đến internal flows giữa VPCs (private IPs). Dual-NIC firewall setup dùng private IPs, và assign public IP không làm drop internal routing trừ khi SNAT config sai – nhưng không khớp triệu chứng "suddenly none working".

• ✅ Verify that the dual-NIC instance has the --can-Ip-Forward attribute enabled.
  Đúng vì: Flag --can-ip-forward (set qua gcloud hoặc metadata enable-ip-forward: true) bắt buộc cho instance forward packets giữa NICs (IP forwarding). Mặc định là false; nếu bị disable (do restart, update, hoặc script), kernel drop tất cả routed traffic ngay lập tức. Đây là nguyên nhân phổ biến nhất cho bump-in-the-wire failure.

• ❌ Verify that the dual-NIC instance has not been added to a backend service.
  Sai vì: Backend service thuộc Load Balancer (HTTP(S)/TCP/UDP) dùng để health-check và route external/internal traffic đến instance group. Thêm instance vào backend không block internal VPC flows trừ khi health-check fail dẫn đến removal, nhưng flows giữa VPCs độc lập với LB backend và không gây drop đột ngột toàn bộ.

🧩 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 kích hoạt TLS inspection trong Cloud Next Generation Firewall Enterprise (Cloud NGFW Enterprise) trên Google Cloud Platform (GCP). Công ty đã triển khai Cloud NGFW Enterprise và đã tạo sẵn một CA pool cùng CA trong Certificate Authority Service (CAS).

Mục tiêu chính: Để Cloud NGFW có thể kiểm tra và giải mã lưu lượng TLS/SSL, cần cấp quyền cho service account của Network Security Service Agent, tạo chính sách kiểm tra TLS liên kết với CA pool, cấu hình các VPC endpoint associations sử dụng chính sách đó, và bật cờ TLS inspection trong quy tắc firewall policy.

Quy trình này đảm bảo firewall có thể yêu cầu chứng chỉ từ CA pool để thực hiện man-in-the-middle inspection an toàn, tránh lỗi chứng chỉ không tin cậy. Đây là tính năng cốt lõi của Cloud NGFW Enterprise, giúp bảo mật sâu hơn cho lưu lượng mã hóa. (Kiến thức cập nhật theo tài liệu GCP mới nhất đến 2026, không thay đổi lớn so với phiên bản 2024).

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

• Cloud NGFW TLS Inspection Docs
• Certificate Authority Service Integration

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

Đáp án đúng: Phương án đầu tiên
Lý do: Đây là quy trình chuẩn xác và đầy đủ theo hướng dẫn chính thức của Google Cloud.

• Cấp role privateca.certificateRequester cho service account để yêu cầu chứng chỉ từ CA pool một cách tự động.
• Tạo TLS inspection policy liên kết CA pool làm nền tảng cho inspection.
• Cấu hình VPC endpoint associations sử dụng policy này để áp dụng cho các endpoint Private Service Connect.
• Bật flag TLS inspection trong quy tắc firewall policy để kích hoạt thực tế.
  Tất cả các bước đều khớp với best practices, đảm bảo TLS inspection hoạt động mượt mà mà không gặp lỗi quyền hạn hoặc cấu hình thiếu. ✅

🛠️ Giải thích chi tiết tất cả các phương án

Dưới đây là phân tích từng phương án. Tôi giữ nguyên văn bản gốc bằng tiếng Anh, chỉ đánh dấu đúng/sai và giải thích hoàn toàn bằng tiếng Việt:

• Phương án 1 (ĐÚNG):
  Grant the network security service agent service account the privateca.certificateRequester role. Create a TLS inspection policy linking to the CA pool. Configure your VPC endpoint associations to use the TLS inspection policy. Flip the TLS inspection flag in your firewall policy rules to true.
  ✅ Đúng vì: Như đã giải thích ở trên, đây là quy trình đầy đủ, chính xác theo docs GCP. Role certificateRequester cho phép service account yêu cầu cert động từ CAS, TLS policy là bắt buộc để liên kết CA pool, VPC associations áp dụng policy cho traffic, và flag kích hoạt inspection. Hoàn hảo!

• Phương án 2 (SAI):
  Grant the network security service agent service account the privateca.poolReader role. Create a TLS inspection policy linking to the CA pool. Configure your VPC endpoint associations to use the TLS inspection policy. Flip the TLS inspection flag in your firewall policy rules to true.
  ❌ Sai vì: Role privateca.poolReader chỉ cho phép đọc thông tin CA pool (như metadata), không cho phép yêu cầu chứng chỉ mới. Cloud NGFW cần role certificateRequester để tự động generate cert cho inspection, nên bước này sẽ thất bại với lỗi quyền hạn.

• Phương án 3 (SAI):
  Grant the network security service agent service account the privateca.certificateRequester role. Create a trust config in Certificate Manager Flip the TLS inspection flag in your firewall policy rules to true.
  ❌ Sai vì: Thiếu các bước quan trọng như tạo TLS inspection policy và cấu hình VPC endpoint associations. "Trust config in Certificate Manager" (Certificate Manager Service - CMS) dùng cho public trust store, không liên kết trực tiếp với private CA pool cho NGFW inspection. Chỉ bật flag mà thiếu policy sẽ không hoạt động.

• Phương án 4 (SAI):
  Grant the network security service agent service account the privateca.certificateRequester role. Create a trust config in Certificate Manager. Flip the TLS inspection flag in your firewall policy rules to true.
  ❌ Sai vì: Tương tự phương án 3, thiếu TLS inspection policy và VPC associations. Certificate Manager chỉ quản lý public cert, không thay thế được CA pool private cho TLS decryption trong NGFW. Quy trình không đầy đủ, dẫn đến inspection thất bại.

Kết luận: Chỉ phương án 1 bao quát toàn bộ workflow chính thức. Nếu triển khai sai, bạn sẽ gặp lỗi như "permission denied" hoặc "no TLS policy found". Hãy kiểm tra console GCP để verify! 🚀

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

Câu hỏi này thuộc chủ đề bảo mật mạng trên Google Cloud, cụ thể là quản lý cấu hình Cloud Next Generation Firewall (Cloud NGFW). Bạn vừa tiếp quản trách nhiệm bảo mật mạng và muốn kiểm tra các quy tắc firewall policy để đảm bảo không có quy tắc nào cho phép lưu lượng ingress (vào) từ internet đến các VM và dịch vụ của tổ chức. Yêu cầu quan trọng là tránh công việc thủ công (manual work), nghĩa là cần một công cụ tự động hóa để phân tích và phát hiện vấn đề.

Mục tiêu chính:

• Tập trung vào ingress traffic từ internet (thường là từ 0.0.0.0/0 hoặc các nguồn công khai).
• Sử dụng tính năng tự động của Google Cloud để review và insights mà không cần kiểm tra tay từng rule.

📘 Kiến thức cập nhật (đến 2026): Theo tài liệu Google Cloud mới nhất (phiên bản Cloud NGFW và Firewall Insights v2+), Firewall Insights cung cấp các insights tự động như "Overly permissive rules" để phát hiện rules cho phép traffic từ internet một cách dễ dàng, không cần manual review. (Nguồn: Google Cloud Firewall Insights Documentation, cập nhật 2025).

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

Đáp án đúng: Enable "Overly permissive rules insights" in Firewall Insights. Review results for rules that show allowed ingress traffic from internet sources.

Lý do 🛠️:

• Tính năng "Overly permissive rules insights" trong Firewall Insights được thiết kế chính xác để tự động phát hiện các quy tắc firewall cho phép traffic ingress từ internet (như 0.0.0.0/0), bao gồm cả Cloud NGFW policies.
• Nó cung cấp insights trực quan, báo cáo tự động với danh sách rules vi phạm, giúp review nhanh chóng mà không cần manual work.
• Hoàn hảo cho yêu cầu: Tránh thủ công, tập trung vào ingress từ internet. Kích hoạt API Firewall Insights và enable insight này là bước đơn giản nhất.

📋 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:

• [SAI] Review the firewall policy rules associated with the VPC, and filter for rules that allow ingress from 0.0.0.0/0.
  ❌ Sai vì: Đây là phương pháp thủ công hoàn toàn (manual review và filter rules trong VPC firewall policies), vi phạm yêu cầu "avoid manual work". Nó chỉ kiểm tra legacy VPC firewall, không tối ưu cho Cloud NGFW (hierarchical policies) và không tự động insights. Phù hợp cho kiểm tra nhỏ nhưng không scale cho toàn tổ chức.

• [ĐÚNG] Enable "Overly permissive rules insights" in Firewall Insights. Review results for rules that show allowed ingress traffic from internet sources.
  ✅ Đúng vì: Như đã giải thích ở trên, đây là tính năng tự động hóa cao cấp của Firewall Insights, phát hiện chính xác overly permissive ingress rules từ internet (bao gồm 0.0.0.0/0) trên Cloud NGFW và VPC firewalls. Kết quả hiển thị rõ ràng với remediation suggestions, tiết kiệm thời gian. (Nguồn: Firewall Insights Overly Permissive Rules).

• [SAI] Run Connectivity Tests from multiple external sources to double-check ingress traffic settings.
  ❌ Sai vì: Connectivity Tests (trong Network Intelligence Center) dùng để test kết nối cụ thể từ nguồn ngoài, không phải để review toàn bộ rules policy. Nó yêu cầu chạy test thủ công từ nhiều nguồn (manual effort), không tự động liệt kê rules permissive, và chỉ kiểm tra kết quả traffic chứ không phân tích policy gốc.

• [SAI] Enable the Network Analyzer API and review the "VPC Network" category insights.
  ❌ Sai vì: Network Analyzer (trước là VPC Flow Logs analyzer) tập trung vào traffic patterns và anomalies (như VPC Network insights), không chuyên sâu về firewall rules permissive hay ingress từ internet. Nó không có insight cụ thể cho "overly permissive rules" trên Cloud NGFW, và vẫn cần manual review logs – không tránh được manual work.

🏆 Kết luận và khuyến nghị

Sử dụng Firewall Insights là cách tối ưu nhất cho Professional Cloud Network Engineer, giúp tuân thủ nguyên tắc least privilege và zero-trust. Hãy kích hoạt ngay để có dashboard realtime! Nếu cần thực hành, thử trên Google Cloud Console > Security > Firewall Insights. (Nguồn bổ sung: Google Cloud Networking Best Practices 2025). 🚀

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

Câu hỏi mô tả tình huống mạng hybrid trong Google Cloud Platform (GCP) (không phải AWS, mặc dù người dùng đề cập AWS – có thể là nhầm lẫn vì các vùng như us-east4 và us-west1 là đặc trưng của GCP). Công ty có kết nối Cloud Interconnect (kết nối dành riêng hoặc đối tác) giữa môi trường on-premises và GCP tại hai vùng us-east4 và us-west1. Sau khi thay đổi để advertise thêm routes (quảng bá tuyến đường động qua BGP) đến us-west1, một số đích on-premises không còn reachable từ us-east4. Nhiệm vụ là troubleshoot để kiểm tra xem có routes bị dropped (bị loại bỏ) không.

Nguyên nhân tiềm năng (dựa trên kiến thức GCP cập nhật đến 2026):

• Cloud Router xử lý dynamic routes từ BGP trên Interconnect có giới hạn unique destinations (tối đa ~2500-5000 tùy loại, theo phiên bản mới nhất từ GCP docs 2024-2026).
• Nếu vượt giới hạn per-region (regional routing mode), routes sẽ bị dropped tự động.
• Vấn đề xảy ra sau khi advertise thêm routes đến vùng khác → cần kiểm tra metrics trong Cloud Monitoring để xác định dropped routes, tập trung vào regional routing_mode vì vấn đề cục bộ ở us-east4.
  🛠️ Mục tiêu: Sử dụng metric phù hợp để query và review attribute routing_mode (regional/global).

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

Đáp án đúng: Query the dynamic_routes/learned_routes/any_dropped_unique_destinations metric and review the regional routing_mode metric attribute.

Lý do:

• Metric any_dropped_unique_destinations là gauge metric chính xác (giá trị 1 nếu có bất kỳ route nào bị drop do vượt unique destinations limit, 0 nếu không) – cập nhật từ GCP Cloud Router metrics (2024+).
• Regional routing_mode phù hợp vì Interconnect routes được xử lý per-region (us-east4 độc lập với us-west1), và dropped routes chỉ ảnh hưởng cục bộ vùng đó. Advertise thêm routes đến us-west1 có thể gián tiếp gây vượt limit ở us-east4 nếu shared BGP session.
• Điều này giúp troubleshoot nhanh: Query metric này trong Cloud Monitoring với filter region=us-east4 và routing_mode=REGIONAL để xác nhận drop.
  📘 Nguồn: GCP Docs - Cloud Router Metrics & Route Limits and Dropped Routes (cập nhật 2025).

🧩 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 bằng tiếng Anh, đánh dấu ✅/❌, và giải thích bằng tiếng Việt:

• ❌ [SAI] Query the dynamic_routes/learned_routes/dropped_unique_destinations metric and review the global routing_mode metric attribute.
  Giải thích sai: Metric dropped_unique_destinations không tồn tại hoặc không chuẩn (GCP dùng any_dropped_unique_destinations để báo có drop hay không). Global routing_mode sai vì routes Interconnect xử lý regional (per-region limit), không phải global (áp dụng VPC-wide). Sử dụng sẽ không phát hiện drop ở us-east4 chính xác.

• ❌ [SAI] Query the dynamic_routes/learned_routes/unique_destinations_limit metric and review the global routing_mode metric attribute.
  Giải thích sai: Metric unique_destinations_limit chỉ hiển thị giới hạn tối đa (không báo dropped routes thực tế). Global routing_mode không phù hợp cho Interconnect hybrid (regional mới đúng). Không giúp troubleshoot dropped routes sau thay đổi advertise.

• ✅ [ĐÚNG] Query the dynamic_routes/learned_routes/any_dropped_unique_destinations metric and review the regional routing_mode metric attribute.
  Giải thích đúng: Metric any_dropped_unique_destinations chính xác phát hiện có route bị drop (1= có drop). Regional routing_mode khớp vì limit áp dụng per-region (us-east4), giúp xác định vấn đề sau advertise thêm routes đến us-west1 gây vượt ngưỡng cục bộ.
  🛠️ Cách dùng: Trong Cloud Monitoring, filter: metric.type="cloudrouter.googleapis.com/router/any_dropped_unique_destinations" AND resource.labels.routing_mode="REGIONAL" AND resource.labels.region="us-east4".

• ❌ [SAI] Query the dynamic_routes/learned_routes/dropped_unique_destinations metric and review the regional routing_mode metric attribute.
  Giải thích sai: Metric dropped_unique_destinations không phải metric chuẩn (thiếu "any_" prefix, GCP dùng any_dropped_unique_destinations để boolean check). Dù regional routing_mode đúng, metric sai nên query không ra kết quả dropped routes hữu ích.

Tóm tắt troubleshoot thêm 🚀: Sau khi xác nhận drop qua metric, kiểm tra BGP session (gcloud compute routers describe), route filters, và tăng limit nếu cần (nâng cấp HA VPN/Interconnect). Tham khảo GCP Best Practices Hybrid Connectivity 2026.

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

Câu hỏi mô tả tình huống tổ chức có tài nguyên trong hai VPC khác nhau, thuộc hai Google Cloud project riêng biệt, cần kết nối lẫn nhau. ✅ Đã xác nhận không có chồng chéo địa chỉ IP giữa hai VPC. Đặc biệt, một VPC sử dụng Privately Used Public IP (PUPI) ranges – đây là các dải địa chỉ IP công khai (public IP) nhưng được sử dụng như địa chỉ riêng tư (private) bên trong VPC, không route ra Internet (theo RFC 6890 và hướng dẫn GCP).

Yêu cầu: Kích hoạt kết nối với chi phí thấp hơn (lower cost) và hiệu suất cao hơn (higher performance) so với các phương pháp khác như VPN. 🛠️ Phương pháp lý tưởng phải hỗ trợ peering giữa các project khác nhau, xử lý được PUPI mà không cần NAT hay gateway phức tạp.

✅ Đáp án đúng: [ĐÚNG] Create a VPC Peering between the two VPCs that allows the export and import of subnet routes with public IP addresses. Create the necessary ingress VPC firewall rules that target the specific resources by using IP ranges as the source filter.

Lý do lựa chọn đáp án đúng 📘:

• VPC Peering là giải pháp chi phí thấp nhất và hiệu suất cao nhất (gần như zero-latency, không qua gateway) cho kết nối giữa VPC cross-project, đặc biệt khi không overlap IP.
• Với PUPI ranges, cần cấu hình peering export/import subnet routes with public IP addresses (tính năng được hỗ trợ từ GCP 2021 và cập nhật ổn định đến 2026) để route các subnet public IP được dùng private. Không dùng "custom routes" vì PUPI cần xử lý cụ thể subnet routes public.
• Ingress VPC firewall rules sử dụng IP ranges làm source filter là chính xác, an toàn và linh hoạt cho traffic từ peering (không cần tags hay service accounts).
• So sánh: HA VPN đắt hơn (giờ tính phí tunnel) và chậm hơn (encrypt overhead).

Nguồn tham khảo:

• GCP VPC Peering docs (2024-2026): Hỗ trợ PUPI với "subnet routes with public IP".
• PUPI best practices: Yêu cầu peering config đặc biệt.
• Firewall rules for peering.

📋 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, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá dựa trên tính đúng đắn, chi phí, hiệu suất và hỗ trợ PUPI theo docs GCP mới nhất (2026).

• ❌ [SAI] Create a HA VPN between the two VPCs that includes the PUPI ranges in the Custom Route Advertisements of the Cloud Router. Create the necessary ingress VPC firewall rules that target the specific resources by using network tags as the source filter.
  Phương án này dùng HA VPN (Dynamic routing với Cloud Router), có thể advertise custom routes cho PUPI. Tuy nhiên: ❌ Không phải lower cost/higher perf (VPN tính phí theo giờ tunnel + data, latency cao hơn peering ~10-50ms). Network tags làm source filter sai vì tags chỉ dùng cho target instances, không filter source IP từ VPN/peering (phải dùng IP ranges). Không ưu tiên so với peering.

• ❌ [SAI] Create a HA VPN between the two VPCs that includes the PUPI ranges in the Custom Route Advertisements of the Cloud Router. Create the necessary ingress VPC firewall rules that target the specific resources by using IP ranges as the source filter.
  Tương tự A, dùng HA VPN với custom routes hỗ trợ PUPI qua BGP. IP ranges source filter đúng, nhưng ❌ Vẫn fail về cost/perf: VPN đắt (khoảng 0.05$/giờ/tunnel) và chậm hơn peering. GCP khuyến nghị peering cho intra-GCP connectivity cross-project thay vì VPN.

• ❌ [SAI] Create a VPC Peering between the two VPCs that allows the export and import of custom routes. Create the necessary ingress VPC firewall rules that target the specific resources by using service accounts as the source filter.
  VPC Peering đúng hướng (low cost/high perf, cross-project OK), nhưng ❌ Custom routes không hỗ trợ đầy đủ PUPI – cần cụ thể "subnet routes with public IP addresses" để exchange public subnet routes private-used. Service accounts source filter sai hoàn toàn: VPC firewall không hỗ trợ IAM service accounts làm source (chỉ IP ranges, tags cho target). Không work.

• ✅ [ĐÚNG] Create a VPC Peering between the two VPCs that allows the export and import of subnet routes with public IP addresses. Create the necessary ingress VPC firewall rules that target the specific resources by using IP ranges as the source filter.
  Hoàn hảo! 🏆 Peering config chính xác cho PUPI (export/import public subnet routes), firewall IP ranges source chuẩn. Đáp ứng lower cost (free ngoài data egress), higher perf (direct route). Cross-project peering chỉ cần IAM permission compute.networks.peerWithNetwork.

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

Câu hỏi mô tả tình huống trong môi trường Google Cloud Platform (GCP), nơi tổ chức đã tái kiến trúc để sử dụng Network Connectivity Center (NCC) – một dịch vụ quản lý kết nối mạng hub-and-spoke topology, giúp kết nối các VPC (Virtual Private Cloud) một cách tập trung và an toàn.

• Vấn đề chính: Khi cố gắng thêm VPC mới tên vpc-dev làm spoke (các VPC kết nối với hub), hệ thống báo lỗi do xung đột không gian IP (IP space) với một spoke hiện có tên vpc-pre-prod. Điều này xảy ra vì NCC yêu cầu các spoke không được có overlap IP ranges khi export routes giữa các spoke qua hub (để tránh routing loop hoặc blackhole routes).
• Yêu cầu: Hoàn thành migration nhanh chóng và hiệu quả (quickly and efficiently), nghĩa là ưu tiên giải pháp ít can thiệp nhất, không làm gián đoạn dịch vụ hiện tại.
• Bối cảnh kiến thức GCP (cập nhật đến 2026): NCC hỗ trợ VPC spokes từ năm 2022, và tính năng --exclude-export-ranges được giới thiệu để xử lý chính xác trường hợp overlap IP mà không cần thay đổi hạ tầng. Flag này cho phép loại trừ các dải IP cụ thể khỏi việc export routes khi tạo spoke.

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

• Network Connectivity Center documentation
• Creating VPC spokes – Mô tả lệnh gcloud network-connectivity spokes vpc create với flag --exclude-export-ranges.
• GCP Release Notes 2024-2026: Không có thay đổi lớn về NCC spokes, vẫn giữ nguyên cơ chế exclude ranges.

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

Đáp án đúng: Exclude the conflicting IP range by using the --exclude-export-ranges flag when creating the VPC spoke for vpc-dev.

Lý do 🛠️:

• Đây là giải pháp chính thức và hiệu quả nhất từ GCP. Flag --exclude-export-ranges được sử dụng khi tạo spoke cho vpc-dev (qua lệnh gcloud network-connectivity spokes vpc create), cho phép loại trừ dải IP xung đột của vpc-pre-prod khỏi việc export routes.
• Không cần xóa VM, subnet hay spoke hiện có → Nhanh chóng, không gián đoạn migration.
• Đảm bảo routes chỉ export những phần IP không overlap, tránh lỗi mà không ảnh hưởng spoke vpc-pre-prod.

📋 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 bằng tiếng Anh. Mỗi phương án được đánh giá với lý do rõ ràng dựa trên tài liệu GCP mới nhất:

• [SAI] Delete the VMs associated with the conflicting subnets, then delete the conflicting subnets in vpc-dev. Recreate the subnets with a new IP range and redeploy the previously-deleted VMs in the new subnets. Add the VPC spoke for vpc-dev.
  ❌ Sai vì: Phương án này tốn kém thời gian và rủi ro cao (downtime cho VM, redeploy toàn bộ), vi phạm yêu cầu "quickly and efficiently". Không cần thiết vì GCP cung cấp flag exclude mà không thay đổi IP ranges thực tế của VPC. Đây là cách thủ công lỗi thời, không khuyến khích trong NCC.

• [ĐÚNG] Exclude the conflicting IP range by using the --exclude-export-ranges flag when creating the VPC spoke for vpc-dev.
  ✅ Đúng vì: Như đã giải thích ở trên. Flag này áp dụng chính xác tại bước tạo spoke cho vpc-dev, loại trừ IP overlap (ví dụ: --exclude-export-ranges="10.0.0.0/16" nếu đó là dải xung đột). Hiệu quả 100%, hỗ trợ CIDR ranges động.

• [SAI] Exclude the conflicting IP range by using the --exclude-export-ranges flag in the hub when attaching the VPC spoke for vpc-dev.
  ❌ Sai vì: Flag --exclude-export-ranges không tồn tại ở hub hoặc khi "attaching" spoke (NCC không có khái niệm attach như vậy). Nó chỉ dùng khi tạo spoke qua gcloud network-connectivity spokes vpc create. Sử dụng sai vị trí sẽ báo lỗi lệnh.

• [SAI] Remove the conflicting VPC spoke for vpc-pre-prod from the set of VPC spokes in Network Connectivity Center. Add the VPC spoke for vpc-dev. Add the previously removed vpc-pre-prod as a VPC spoke.
  ❌ Sai vì: Không hiệu quả và gây gián đoạn – phải remove/add lại vpc-pre-prod, dẫn đến mất kết nối tạm thời cho workload pre-prod (có thể ảnh hưởng production). Vi phạm nguyên tắc migration nhanh, trong khi exclude flag giải quyết mà không động đến spoke hiện có.

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

Câu hỏi mô tả tình huống: Đội ngũ networking đã kích hoạt Cloud CDN cho một dịch vụ hướng ngoại (external-facing service) được expose qua external Application Load Balancer (ALB). Đội ngũ ứng dụng (application team) đã định nghĩa sẵn nội dung nào nên được cache trong các responses từ backend. Tuy nhiên, sau khi test load balancer, không thấy cải thiện performance nào. Nhiệm vụ là giải quyết vấn đề này để Cloud CDN hoạt động đúng, cache nội dung theo ý định của application team.

Nguyên nhân cốt lõi 📉: Mặc định khi enable Cloud CDN, nó sử dụng chế độ CACHE_ALL_STATIC, chỉ cache các nội dung static (dựa trên file extension như .jpg, .css), không tôn trọng các header cache từ backend (như Cache-Control, Expires). Vì application team đã define cache trong responses, cần thay đổi chế độ để Cloud CDN lấy theo header từ origin (backend) nhằm cache đúng nội dung mong muốn, từ đó cải thiện performance.

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

Đáp án đúng: Configure the USE_ORIGIN_HEADERS caching mode on Cloud CDN to ensure Cloud CDN caches content depending on responses to requests from the backends.

Lý do 🛠️:

• Chế độ USE_ORIGIN_HEADERS cho phép Cloud CDN tôn trọng hoàn toàn các header cache từ backend (như Cache-Control, Cache-Private, Expires, Vary), giúp cache chính xác nội dung mà application team đã define trong responses.
• Điều này giải quyết vấn đề không cải thiện performance, vì giờ CDN sẽ cache động theo header origin thay vì chỉ static files.
• Theo tài liệu Google Cloud mới nhất (2024-2026), đây là chế độ khuyến nghị khi backend đã tự quản lý cache policy.

📋 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 bằng tiếng Anh, với lý do đúng/sai bằng tiếng Việt:

• ❌ [SAI] Configure the CACHE_ALL_STATIC caching mode on Cloud CDN to ensure Cloud CDN caches all static content as well as content defined by the backends.
  Lý do sai 🚫: Chế độ CACHE_ALL_STATIC (mặc định) chỉ cache nội dung static dựa trên extension file (như .html, .js, .css), bỏ qua header từ backend. Nó không cache "content defined by the backends" như mô tả, nên không giải quyết vấn đề thiếu performance cải thiện.

• ❌ [SAI] Configure the FORCE_CACHE_ALL caching mode on Cloud CDN to ensure all appropriate content is cached.
  Lý do sai 🚫: Chế độ FORCE_CACHE_ALL bắt buộc cache TẤT CẢ nội dung, bỏ qua header từ origin (Cache-Control: no-cache/private sẽ bị ignore). Điều này có thể cache cả nội dung không nên cache (như dữ liệu cá nhân hóa), dẫn đến lỗi bảo mật hoặc stale content, không phù hợp khi application team đã define cụ thể.

• ✅ [ĐÚNG] Configure the USE_ORIGIN_HEADERS caching mode on Cloud CDN to ensure Cloud CDN caches content depending on responses to requests from the backends.
  Lý do đúng 🟢: Như đã giải thích ở trên, chế độ này sử dụng header từ backend để quyết định cache (Cache-Control, Expires, etc.), khớp chính xác với việc application team đã define trong responses, đảm bảo performance cải thiện mà không override policy origin.

• ❌ [SAI] Configure the CACHE_ALL_STATIC caching mode on Cloud CDN to ensure Cloud CDN cache content depending on responses to requests from the backends.
  Lý do sai 🚫: Tương tự lựa chọn đầu, CACHE_ALL_STATIC không depend on responses từ backend, chỉ dựa trên static extension. Mô tả "depending on responses" là sai lệch hoàn toàn với hành vi thực tế của chế độ này.

📘 Tài liệu tham khảo

• Google Cloud CDN Caching Modes (cập nhật 2024): Cloud CDN Documentation - Cache Modes.
• External Application Load Balancer with CDN (best practices 2025-2026): Load Balancing with CDN.
• Troubleshooting CDN Performance: CDN Troubleshooting Guide.

Lưu ý cuối 💡: Để implement, sử dụng gcloud CLI: gcloud compute backend-services update [BACKEND_SERVICE] --cdn --cache-mode USE_ORIGIN_HEADERS. Test lại với curl kiểm tra header X-Cache!

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

Câu hỏi tập trung vào việc cấu hình chính sách bảo mật mạng trong Google Cloud để kiểm soát lưu lượng SMTP (TCP port 25) đến môi trường cloud. Yêu cầu cụ thể:

• Chặn toàn bộ lưu lượng SMTP đến từ mọi nguồn, ngoại trừ từ mạng nội bộ doanh nghiệp (corporate network).
• Chỉ cho phép SMTP từ corporate network đến một số VPC cụ thể trải rộng trên nhiều Google Cloud projects.
• Sử dụng hierarchical firewall policy (chính sách tường lửa phân cấp) để áp dụng quy tắc từ cấp tổ chức (organization level), kết hợp với quy tắc tường lửa tại cấp VPC/project.

Mục tiêu chính: Tạo lớp bảo vệ "deny by default" cho SMTP, nhưng linh hoạt cho phép ở các VPC được chỉ định. Hierarchical firewall policies trong Google Cloud cho phép đánh giá quy tắc theo thứ tự ưu tiên (priority) từ cấp cao (org/folder/project) xuống cấp thấp (VPC firewall rules), với các hành động như allow, deny, hoặc goto_next (tiếp tục đánh giá quy tắc tiếp theo). 📘
(Kiến thức cập nhật đến 2026: Hierarchical Firewalls hỗ trợ quy tắc ingress/egress dựa trên IP source/destination, ports, và tags; đánh giá theo thứ tự priority thấp hơn trước - ví dụ pri 10000 trước pri 10010. Nguồn: Google Cloud VPC Hierarchical Firewall Policies).

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

Đáp án đúng là lựa chọn thứ 3 (đã được đánh dấu [ĐÚNG] trong câu hỏi).

🛠️ Lý do chi tiết:

• Bước 1: Quy tắc ingress hierarchical firewall priority 10000 với source = corporate network, TCP port 25, action = goto_next. Quy tắc này có ưu tiên cao nhất, khớp lưu lượng từ corporate và tiếp tục đánh giá quy tắc thấp hơn (không chặn ngay, cho phép VPC cụ thể quyết định).
• Bước 2: Quy tắc priority 10010 (thấp hơn) với source = 0.0.0.0/0 (mọi nguồn), TCP port 25, action = deny. Chặn toàn bộ SMTP từ nguồn khác corporate ngay tại cấp tổ chức.
• Bước 3: Associate policy tại organization level để áp dụng rộng rãi trên tất cả projects/VPCs, đảm bảo "deny by default".
• Bước 4: Tại firewall policies của các VPC cụ thể, thêm quy tắc allow TCP port 25. Vì goto_next từ bước 1, lưu lượng từ corporate sẽ đến được quy tắc allow này; các VPC khác không có allow sẽ bị deny ngầm (hoặc VPC fw default deny).

Kết quả: ✅ Đáp ứng chính xác yêu cầu - chặn toàn bộ SMTP trừ corporate, và chỉ cho phép ở VPCs được chọn. Hoàn hảo với cơ chế evaluation order của hierarchical firewalls! 🏆

🔍 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 bằng tiếng Anh. Mỗi phương án được đánh giá dựa trên logic đánh giá quy tắc hierarchical firewall (priority thấp đánh giá trước, action quyết định flow).

• [SAI] 1. Configure an ingress hierarchical firewall rule with priority 10000 specifying the 0.0.0.0/0 source, TCP port 25, and the deny action.
  2. Configure an egress hierarchical firewall rule with priority 10010 specifying the source of your corporate network as TCP port 25 and the goto_next action.
  3. Associate the hierarchical firewall policy at the organization level.
  4. Configure firewall policy rules allowing TCP port 25 in the firewall policies associated with the respective VPCs that require that access.
  ❌ Sai vì:

  • Bước 1 deny 0.0.0.0/0 priority cao nhất → chặn TẤT CẢ SMTP ngay lập tức, kể cả từ corporate (không phân biệt source).
  • Bước 2 dùng egress (lưu lượng đi ra) thay vì ingress (đến vào) → sai hướng traffic (SMTP là inbound). Action goto_next ở egress cũng vô nghĩa.
  • Các bước còn lại không cứu vãn được vì rule đầu đã deny hết. Không đáp ứng "allow từ corporate". 🚫

• [SAI] 1. Configure an ingress hierarchical firewall rule with priority 10000 specifying the 0.0.0.0/0 source, TCP port 25, and the allow action.
  2. Associate the hierarchical firewall policy at the organization level.
  3. Configure firewall policy rules to deny TCP port 25 in the firewall policies associated with the respective VPCs that do not require that access.
  ❌ Sai vì:

  • Bước 1 allow 0.0.0.0/0 priority cao nhất → cho phép TẤT CẢ SMTP từ mọi nguồn tại org level, vi phạm yêu cầu "block all except corporate".
  • Bước 3 cố deny ở VPC không cần → muộn màng, vì rule org đã allow rồi (không có deny sau allow). Mở cửa quá rộng, không an toàn. 🔓

• [ĐÚNG] 1. Configure an ingress hierarchical firewall rule with priority 10000 specifying the source of your corporate network, TCP port 25, and the goto_next action.
  2. Configure an ingress hierarchical firewall rule with priority 10010 specifying the 0.0.0.0/0 source, TCP port 25, and the deny action.
  3. Associate the hierarchical firewall policy at the organization level.
  4. Configure firewall policy rules allowing TCP port 25 in the firewall policies associated with the respective VPCs that require that access.
  ✅ Đúng hoàn toàn (như giải thích ở phần trên). Sử dụng goto_next thông minh để "bypass deny" cho corporate, kết hợp allow granular ở VPC. Hoàn hảo! 🎯

• [SAI] 1. Configure an ingress hierarchical firewall rule with priority 10000 specifying the 0.0.0.0/0 source, TCP port 25, and the deny action.
  2. Associate the hierarchical firewall policy at the organization level.
  3. Configure firewall policy rules allowing TCP port 25 in the firewall policies associated with the respective VPCs that require that access.
  ❌ Sai vì:

  • Bước 1 deny 0.0.0.0/0 priority cao nhất → chặn TẤT CẢ SMTP, kể cả từ corporate (không có rule riêng cho corporate trước).
  • Bước 3 allow ở VPC cụ thể → không bao giờ đến được, vì org rule đã deny hết. Thiếu goto_next hoặc rule corporate-first. Đơn giản nhưng thất bại cơ bản. ⛔

Tóm tắt takeaway 📚: Hierarchical firewalls mạnh ở việc layer rules (org → VPC), luôn ưu tiên "allow specific → deny all" với goto_next để linh hoạt. Tham khảo thêm: GCP Firewall Rules Evaluation. Nếu cần lab thực hành, dùng GCP Console → VPC Network → Firewall Policies! 🧑‍💻