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

Tìm thấy 333 câu.

Câu 31
You need to upgrade the EHR connection to comply with their requirements. The new connection design must support business-critical needs and meet the same network and security policy requirements. What should you do?
  1. A Add a new Dedicated Interconnect connection.
  2. B Upgrade the bandwidth on the Dedicated Interconnect connection to 100 G.
  3. C Add three new Cloud VPN connections.
  4. D Add a new Carrier Peering connection.
Xem giải thích

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

Câu hỏi này thuộc lĩnh vực Google Cloud Networking (cụ thể là Cloud Interconnect), liên quan đến việc nâng cấp kết nối EHR (Electronic Health Record - hệ thống hồ sơ y tế điện tử) để đáp ứng các yêu cầu tuân thủ. Tình huống giả định rằng hiện tại đã có một kết nối Dedicated Interconnect đang hoạt động, nhưng cần nâng cấp để hỗ trợ nhu cầu kinh doanh quan trọng (business-critical needs) như độ tin cậy cao, độ trễ thấp, và băng thông lớn hơn, đồng thời giữ nguyên các yêu cầu chính sách mạng và bảo mật (network and security policy requirements).

Các điểm chính cần đáp ứng:

  • Business-critical: Yêu cầu kết nối private, độ trễ thấp, độ khả dụng cao (SLA 99.9%), không qua Internet công cộng.
  • Tuân thủ policy: Không thay đổi cấu hình bảo mật (private IP, VLAN attachment, firewall rules), tránh gián đoạn dịch vụ.
  • Nâng cấp: Không chỉ tăng băng thông đơn lẻ mà phải scale tổng thể mà không ảnh hưởng kết nối hiện tại.

Mục tiêu là chọn giải pháp tối ưu, không gián đoạn, private và scalable theo best practices của Google Cloud (cập nhật đến 2026: Dedicated Interconnect hỗ trợ tối đa 10 Gbps/link, bundle nhiều link để đạt >50 Gbps).

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

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

Đáp án đúng: Add a new Dedicated Interconnect connection.
🛠️ Lý do: Dedicated Interconnect là kết nối private cao cấp từ on-premises đến Google Cloud qua đối tác Layer 1/2 (như Equinix), đảm bảo độ trễ thấp (<100ms), bảo mật cao (không qua public Internet), và SLA 99.9%. Để nâng cấp mà không gián đoạn, best practice là thêm connection mới (có thể bundle VLAN attachments thành LAG - Link Aggregation Group lên đến 8x10Gbps = 80Gbps). Điều này giữ nguyên policy hiện tại, hỗ trợ business-critical (redundancy tự nhiên), và scalable linh hoạt. Không cần thay đổi config cũ, chỉ add mới song song.

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

  • [ĐÚNG] Add a new Dedicated Interconnect connection.
    ✅ Đúng vì: Như phân tích trên, đây là cách scale chuẩn (add multiple 10Gbps links để đạt tổng băng thông cao hơn, ví dụ 20-80Gbps qua LAG). Không gián đoạn traffic hiện tại, tuân thủ đầy đủ security policy (private, VLAN-based), và phù hợp business-critical với redundancy cao. Theo docs GCP 2026, đây là recommended method cho high-throughput upgrades.

  • [SAI] Upgrade the bandwidth on the Dedicated Interconnect connection to 100 G.
    ❌ Sai vì: Dedicated Interconnect không hỗ trợ upgrade single connection lên 100Gbps (tối đa chỉ 10Gbps/link kể từ 2017 và vẫn giữ đến 2026). Việc "upgrade bandwidth" đòi hỏi provisioning mới từ nhà cung cấp (Colocation provider), gây downtime lớn (có thể vài giờ/ngày), vi phạm yêu cầu "meet the same network and security policy" (cần re-provision VLAN). Không scalable và không phải best practice.

  • [SAI] Add three new Cloud VPN connections.
    ❌ Sai vì: Cloud VPN (HA VPN hoặc Classic VPN) sử dụng IPsec qua Internet công cộng, dẫn đến độ trễ cao (>150ms), throughput thấp (max 3-5Gbps/tunnel), và không private thực sự (dễ bị tấn công MITM). Không đáp ứng business-critical (SLA chỉ 99.9% nhưng throughput biến động), và vi phạm security policy (public routing thay vì private VLAN). Chỉ dùng cho low-critical, không scale cho EHR.

  • [SAI] Add a new Carrier Peering connection.
    ❌ Sai vì: Carrier Peering là public peering (Layer 3, BGP-based) cho traffic outbound đến Internet/Google services, không phải private on-premises connection. Không hỗ trợ VLAN attachments, không private (public IP), độ trễ cao hơn Interconnect, và không meet security policy (không kiểm soát được traffic như Dedicated). Chỉ dùng cho peering với carriers, không phù hợp upgrade EHR business-critical.

🧠 Tóm tắt insight: Luôn ưu tiên Dedicated/Partner Interconnect cho hybrid cloud critical workloads trên GCP. Scale bằng "add new" thay vì "upgrade single" để tránh downtime! 🚀

Câu 32
Mountkirk Games wants to set up a continuous delivery pipeline. Their architecture includes many small services that they want to be able to update and roll back quickly. Mountkirk Games has the following requirements:
✑ Services are deployed redundantly across multiple regions in the US and Europe
✑ Only frontend services are exposed on the public internet
✑ They can provide a single frontend IP for their fleet of services
✑ Deployment artifacts are immutable
Which set of products should they use?
  1. A Google Cloud Storage, Google Cloud Dataflow, Google Compute Engine
  2. B Google Cloud Storage, Google App Engine, Google Network Load Balancer
  3. C Google Kubernetes Registry, Google Container Engine, Google HTTP(S) Load Balancer
  4. D Google Cloud Functions, Google Cloud Pub/Sub, Google Cloud Deployment Manager
Xem giải thích

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

📘 Nội dung câu hỏi:
Câu hỏi mô tả tình huống của công ty Mountkirk Games, một nhà phát triển trò chơi trực tuyến, muốn thiết lập dòng chảy triển khai liên tục (continuous delivery pipeline) cho kiến trúc microservices với nhiều dịch vụ nhỏ. Họ cần cập nhật và rollback nhanh chóng. Các yêu cầu cụ thể bao gồm:

  • ✅ Dịch vụ được triển khai redundantly (dư thừa) trên nhiều vùng (regions) ở Mỹ và châu Âu → Yêu cầu hỗ trợ triển khai đa vùng, multi-cluster để đảm bảo tính sẵn sàng cao (HA).
  • ✅ Chỉ frontend services được expose ra internet công cộng → Backend phải được bảo vệ, không expose trực tiếp.
  • ✅ Cung cấp single frontend IP cho toàn bộ fleet dịch vụ → Cần global load balancer để thống nhất IP duy nhất, hỗ trợ multi-region.
  • ✅ Deployment artifacts immutable → Sử dụng artifacts không thay đổi (như container images) để đảm bảo tính nhất quán và dễ rollback.

Câu hỏi yêu cầu chọn bộ sản phẩm Google Cloud phù hợp nhất để đáp ứng tất cả các yêu cầu này. Đây là case study kinh điển từ kỳ thi Google Cloud Professional Cloud Architect, tập trung vào container orchestration, global load balancing và immutable deployments.

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

Đáp án đúng: Google Kubernetes Registry, Google Container Engine, Google HTTP(S) Load Balancer

Lý do chi tiết:
🛠️ Bộ sản phẩm này hoàn hảo vì:

  • Google Kubernetes Registry (nay là Artifact Registry hoặc Container Registry): Lưu trữ immutable container images (artifacts) để triển khai nhanh, hỗ trợ multi-region replication.
  • Google Container Engine (nay là Google Kubernetes Engine - GKE): Quản lý Kubernetes clusters đa vùng (multi-cluster), triển khai microservices redundantly ở US/Europe, hỗ trợ rolling updates/rollback nhanh cho services nhỏ. Chỉ expose frontend qua services/Ingress.
  • Google HTTP(S) Load Balancer (Global): Cung cấp single frontend IP toàn cầu, expose chỉ frontend ra public internet, route traffic đến GKE clusters multi-region với autoscaling và health checks.

Kết hợp tạo pipeline CD hoàn chỉnh: Build immutable images → Push to Registry → Deploy to GKE → Load balance globally. Phù hợp kiến thức cập nhật 2026 (GKE Anthos multi-cluster, Artifact Registry GA).

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

🔍 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, giữ nguyên văn bản gốc bằng tiếng Anh, kèm giải thích sai/đúng bằng tiếng Việt với lý do cụ thể:

  • Google Cloud Storage, Google Cloud Dataflow, Google Compute Engine
    ❌ Sai. Google Cloud Storage chỉ lưu artifacts (không phải registry container chuyên dụng). Dataflow dành cho data processing/batch (không phù hợp microservices deployment). Compute Engine là VM thuần, không hỗ trợ container orchestration multi-region nhanh/rollback, thiếu global LB single IP.

  • Google Cloud Storage, Google App Engine, Google Network Load Balancer
    ❌ Sai. Storage chỉ lưu static files. App Engine là PaaPaS đơn giản, không hỗ trợ microservices phức tạp multi-region redundantly hoặc custom orchestration. Network Load Balancer chỉ TCP/UDP regional (không HTTP(S) global single IP cho frontend multi-region).

  • Google Kubernetes Registry, Google Container Engine, Google HTTP(S) Load Balancer
    ✅ Đúng. Như giải thích trên, bộ này khớp 100% yêu cầu: Immutable registry + Kubernetes multi-region + Global LB single IP cho frontend.

  • Google Cloud Functions, Google Cloud Pub/Sub, Google Cloud Deployment Manager
    ❌ Sai. Cloud Functions là serverless functions (không cho microservices full-state). Pub/Sub là messaging (không deployment). Deployment Manager là IaC template (không orchestration runtime multi-region hoặc LB single IP). Không hỗ trợ immutable artifacts hoặc expose chỉ frontend.

Câu 33 Chọn nhiều đáp án
For this question, refer to the Mountkirk Games case study. Mountkirk Games wants to design their solution for the future in order to take advantage of cloud and technology improvements as they become available. Which two steps should they take? (Choose two.)
  1. A Store as much analytics and game activity data as financially feasible today so it can be used to train machine learning models to predict user behavior in the future.
  2. B Begin packaging their game backend artifacts in container images and running them on Google Kubernetes Engine to improve the ability to scale up or down based on game activity.
  3. C Set up a CI/CD pipeline using Jenkins and Spinnaker to automate canary deployments and improve development velocity.
  4. D Adopt a schema versioning tool to reduce downtime when adding new game features that require storing additional player data in the database.
  5. E Implement a weekly rolling maintenance process for the Linux virtual machines so they can apply critical kernel patches and package updates and reduce the risk of 0-day vulnerabilities.
Xem giải thích

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

📖 Nội dung câu hỏi:
Câu hỏi dựa trên case study Mountkirk Games trong kỳ thi Google Cloud Professional Cloud Architect. Mountkirk Games là một công ty phát triển game multiplayer trực tuyến, đang chuyển đổi từ hạ tầng on-premises sang Google Cloud để hỗ trợ tăng trưởng nhanh chóng (hàng triệu người chơi đồng thời, dữ liệu lớn từ hoạt động game). Họ muốn thiết kế giải pháp hướng tới tương lai (future-proof), tận dụng các cải tiến cloud và công nghệ mới khi chúng xuất hiện. Câu hỏi yêu cầu chọn hai bước (Choose two) mà họ nên thực hiện để đạt mục tiêu này.
✅ Mục tiêu chính: Không chỉ giải quyết vấn đề hiện tại mà còn linh hoạt mở rộng, áp dụng ML/AI, containerization để scale động theo nhu cầu game (peak thời chơi cao). Kiến thức dựa trên Google Cloud best practices cập nhật đến 2026 (GKE phiên bản mới nhất hỗ trợ AI/ML integration, Anthos cho hybrid/multi-cloud).

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

  • Store as much analytics and game activity data as financially feasible today so it can be used to train machine learning models to predict user behavior in the future.
    Lý do: Bước này chuẩn bị dữ liệu lớn (big data) cho ML/AI tương lai, dự đoán hành vi người chơi (churn prediction, personalization). Mountkirk cần lưu trữ dữ liệu analytics/game telemetry trên BigQuery/Dataflow để train Vertex AI/ML models sau, tận dụng cloud improvements như AutoML hay generative AI (cập nhật 2025-2026). Đây là chiến lược data-driven future-proof.

  • Begin packaging their game backend artifacts in container images and running them on Google Kubernetes Engine to improve the ability to scale up or down based on game activity.
    Lý do: Containerize backend (Docker images) và chạy trên GKE (Kubernetes managed) cho phép auto-scaling linh hoạt theo traffic game (Horizontal Pod Autoscaler, Cluster Autoscaler). Điều này tận dụng công nghệ container native mới (GKE Enterprise 2026 hỗ trợ GPU/TPU cho game rendering), dễ migrate sang serverless (Cloud Run) hoặc multi-cloud (Anthos). Hoàn hảo cho workload biến động cao của game.

📘 Giải thích tất cả các phương án (dùng ✅ đúng, ❌ sai):

  • ✅ Store as much analytics and game activity data as financially feasible today so it can be used to train machine learning models to predict user behavior in the future.
    Giải thích: ✅ Đúng vì Mountkirk cần dữ liệu lịch sử để train ML models (Vertex AI) dự đoán retention, matchmaking. Lưu trữ rẻ trên BigQuery (partitioned tables, coldline storage) tận dụng cloud cost optimizations mới (2026), chuẩn bị cho AI advancements như Gemini models.

  • ✅ Begin packaging their game backend artifacts in container images and running them on Google Kubernetes Engine to improve the ability to scale up or down based on game activity.
    Giải thích: ✅ Đúng vì containerization + GKE là best practice cho microservices game backend, hỗ trợ autoscaling theo metrics (CPU/RPM). GKE 1.29+ (2026) tích hợp Istio, Knative cho scale-to-zero, future-proof cho edge computing/game streaming (AGONES).

  • ❌ Set up a CI/CD pipeline using Jenkins and Spinnaker to automate canary deployments and improve development velocity.
    Giải thích: ❌ Sai vì tuy CI/CD tốt, nhưng Jenkins/Spinnaker không phải lựa chọn future-proof nhất trên Google Cloud (deprecated dần). Nên dùng Cloud Build + Cloud Deploy (native, tích hợp GKE/ArgoCD 2026) để tận dụng serverless CI/CD, giảm vendor lock-in. Không trực tiếp liên quan "cloud/technology improvements".

  • ❌ Adopt a schema versioning tool to reduce downtime when adding new game features that require storing additional player data in the database.
    Giải thích: ❌ Sai vì schema versioning (như Liquibase) chỉ giải quyết downtime database hiện tại (Cloud SQL/Spanner), không phải bước "tương lai" tận dụng cloud mới. Mountkirk nên dùng Firestore hoặc Spanner với schema-less design để tránh vấn đề này từ gốc, tập trung vào NoSQL cho game data.

  • ❌ Implement a weekly rolling maintenance process for the Linux virtual machines so they can apply critical kernel patches and package updates and reduce the risk of 0-day vulnerabilities.
    Giải thích: ❌ Sai vì quản lý VM thủ công (Compute Engine) không future-proof; dễ lỗi, không scale. Nên migrate sang container/GKE hoặc serverless (Cloud Run/Functions) để tự động patch (2026 updates), tránh VM maintenance hoàn toàn. Không tận dụng cloud-native improvements.

🛠️ Khuyến nghị thực hiện:

  • Ưu tiên data lake (BigQuery) + GKE cho Mountkirk để scale 10x người chơi.
  • Test với load testing (Locust + GKE autoscaling).

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

Câu 34
Mountkirk Games wants to limit the physical location of resources to their operating Google Cloud regions. What should you do?
  1. A Configure an organizational policy which constrains where resources can be deployed.
  2. B Configure IAM conditions to limit what resources can be configured.
  3. C Configure the quotas for resources in the regions not being used to 0.
  4. D Configure a custom alert in Cloud Monitoring so you can disable resources as they are created in other regions.
Xem giải thích

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

Câu hỏi thuộc case study Mountkirk Games (một tình huống thực tế trong kỳ thi Google Cloud Professional Cloud Architect), nơi công ty muốn giới hạn vị trí vật lý (regions/zones) của các tài nguyên chỉ trong các Google Cloud regions mà họ đang vận hành.
✅ Mục tiêu chính: Ngăn chặn việc triển khai tài nguyên ở các regions không mong muốn, đảm bảo tuân thủ chính sách tổ chức (compliance), bảo mật dữ liệu và tối ưu chi phí.
🛠️ Bối cảnh: Mountkirk Games cần một giải pháp chủ động, bắt buộc (enforced) ở cấp độ tổ chức (organization level), không phải phản ứng sau khi tạo tài nguyên. Điều này liên quan đến các tính năng quản lý chính sách của Google Cloud như Organization Policies.

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

Đáp án đúng: Configure an organizational policy which constrains where resources can be deployed.
Lý do:

  • Organization Policies trong Google Cloud cho phép định nghĩa các ràng buộc (constraints) ở cấp tổ chức/folder/project, cụ thể như "resourcemanager.restrictAllowedRegions" hoặc "gcp.resourceLocations" (cập nhật đến 2026), để cấm triển khai tài nguyên ở các regions không được phép.
  • Đây là cách chủ động, ngăn chặn từ gốc (preventive enforcement), áp dụng toàn bộ tổ chức mà không cần can thiệp thủ công.
  • Phù hợp nhất với yêu cầu "limit the physical location", đảm bảo tuân thủ quy định địa lý (data residency).
    📘 Tài liệu tham khảo: Google Cloud Organization Policy Constraints & Restrict resource locations (phiên bản mới nhất 2026).

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

  • Configure an organizational policy which constrains where resources can be deployed.
    ✅ Đúng: Như đã giải thích ở trên, đây là phương pháp chuẩn, enforced ở cấp cao nhất, hỗ trợ nhiều loại tài nguyên (Compute Engine, GKE, v.v.) và dễ quản lý tập trung. Không thể bypass dễ dàng.

  • Configure IAM conditions to limit what resources can be configured.
    ❌ Sai: IAM conditions (như resource.location trong điều kiện) chỉ giới hạn quyền truy cập/action dựa trên thuộc tính tài nguyên, nhưng không ngăn chặn việc tạo tài nguyên ở regions không mong muốn. IAM là về "ai làm gì", không phải "tạo ở đâu". Không enforced toàn tổ chức mà chỉ per-identity/per-policy.

  • Configure the quotas for resources in the regions not being used to 0.
    ❌ Sai: Quotas (Service Quotas) có thể set = 0 ở regions không dùng (qua Cloud Console/CLI), ngăn tạo tài nguyên mới ở đó. Tuy nhiên, đây chỉ là giới hạn số lượng (soft limit), không phải ràng buộc vị trí enforced; có thể tăng quota thủ công, và không áp dụng retroactively cho tài nguyên hiện có. Không phải best practice cho compliance.

  • Configure a custom alert in Cloud Monitoring so you can disable resources as they are created in other regions.
    ❌ Sai: Cloud Monitoring chỉ phát hiện và cảnh báo (reactive) sau khi tài nguyên được tạo, không ngăn chặn. Việc "disable" thủ công sau đó tốn công sức, dễ bỏ sót, và không scale cho môi trường lớn. Không đáp ứng yêu cầu "limit" chủ động.

🛠️ Kết luận: Organizational Policy là lựa chọn tối ưu, scalable theo best practices Google Cloud (cập nhật 2026), giúp Mountkirk Games kiểm soát chặt chẽ regions mà không ảnh hưởng hiệu suất.

Câu 35
Your development team has created a structured API to retrieve vehicle data. They want to allow third parties to develop tools for dealerships that use this vehicle event data. You want to support delegated authorization against this data.
What should you do?
  1. A Build or leverage an OAuth-compatible access control system
  2. B Build SAML 2.0 SSO compatibility into your authentication system
  3. C Restrict data access based on the source IP address of the partner systems
  4. D Create secondary credentials for each dealer that can be given to the trusted third party
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 đề bảo mật và ủy quyền truy cập (delegated authorization) trong môi trường AWS. Cụ thể:

  • Đội ngũ phát triển đã xây dựng một API có cấu trúc (structured API) để truy xuất dữ liệu xe hơi (vehicle data), có thể liên quan đến các sự kiện xe (vehicle event data).
  • Mục tiêu: Cho phép bên thứ ba (third parties) phát triển công cụ (tools) dành cho các đại lý xe (dealerships), sử dụng dữ liệu này.
  • Yêu cầu chính: Hỗ trợ delegated authorization – nghĩa là ủy quyền gián tiếp, nơi bên thứ ba có thể truy cập dữ liệu thay mặt cho đại lý mà không cần chia sẻ thông tin đăng nhập trực tiếp, đảm bảo an toàn, kiểm soát phạm vi truy cập (scopes) và tuân thủ các tiêu chuẩn bảo mật hiện đại.

🛠️ Bối cảnh AWS liên quan: Trong AWS (cập nhật đến 2026), điều này thường được xử lý qua Amazon API Gateway kết hợp Amazon Cognito (hỗ trợ OAuth 2.0 và OpenID Connect - OIDC), cho phép cấp token truy cập tạm thời, có thể thu hồi, và kiểm soát chi tiết quyền hạn. Delegated auth giúp tránh chia sẻ credential gốc, giảm rủi ro lộ thông tin.

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

Đáp án đúng: Build or leverage an OAuth-compatible access control system

Lý do:

  • OAuth 2.0 (và các extension như OAuth 2.1 draft đến 2026) là tiêu chuẩn vàng cho delegated authorization trong API hiện đại. Nó cho phép bên thứ ba (client) lấy access token từ authorization server (như Cognito User Pools hoặc Cognito Identity Pools) thay mặt cho resource owner (dealership/user).
  • Trong AWS, bạn có thể xây dựng (build) hệ thống tùy chỉnh hoặc tận dụng (leverage) dịch vụ sẵn có như Cognito để cấp token JWT với scopes cụ thể (ví dụ: chỉ đọc vehicle event data).
  • Lợi ích: Token ngắn hạn, hỗ trợ refresh, introspection endpoint để kiểm tra token hợp lệ; tích hợp mượt mà với API Gateway Lambda Authorizer hoặc Cognito Authorizer.
  • Đây là cách an toàn nhất, scalable và tuân thủ best practices AWS Well-Architected Framework (Security Pillar).

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

  • Build or leverage an OAuth-compatible access control system ✅
    Đúng vì: Như đã giải thích ở trên, OAuth lý tưởng cho delegated auth với API. AWS Cognito hỗ trợ đầy đủ OAuth flows (Authorization Code, Client Credentials, Implicit) và tích hợp trực tiếp với API Gateway. Đến 2026, Cognito còn hỗ trợ OAuth 2.1 features như PAR (Pushed Authorization Requests) cho bảo mật cao hơn. 🛡️

  • Build SAML 2.0 SSO compatibility into your authentication system ❌
    Sai vì: SAML 2.0 chủ yếu dùng cho SSO (Single Sign-On) federation giữa identity providers (IdP) và service providers (SP), phù hợp với web apps doanh nghiệp (như tích hợp Active Directory). Nó không hỗ trợ delegated authorization cho API một cách mượt mà – SAML assertions không phải là bearer token linh hoạt cho REST APIs. Trong AWS, SAML dùng cho IAM roles federation (như AssumeRoleWithSAML), nhưng không thay thế OAuth cho third-party API access. 🧨

  • Restrict data access based on the source IP address of the partner systems ❌
    Sai vì: Giới hạn theo IP không phải delegated authorization mà chỉ là network-level control thô sơ. Nó dễ bị bypass (VPN, IP spoofing), không kiểm soát user/dealership cụ thể, và không scalable cho third parties động. AWS WAF hoặc Security Groups hỗ trợ IP whitelisting, nhưng AWS khuyến cáo KHÔNG dùng làm primary auth (theo Security Best Practices 2026). Rủi ro cao với DDoS hoặc IP changes. 🚫

  • Create secondary credentials for each dealer that can be given to the trusted third party ❌
    Sai vì: Tạo secondary credentials (như IAM access keys hoặc API keys) nghĩa là chia sẻ credential trực tiếp, vi phạm nguyên tắc least privilege và delegated auth. Third party có quyền toàn bộ như dealer gốc, dễ lạm dụng, khó thu hồi. AWS IAM khuyến cáo tránh chia sẻ long-lived credentials; thay vào đó dùng temporary tokens qua STS (Security Token Service). Rủi ro cao về compliance (GDPR/SOC2). 🔒❌

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

Hy vọng phân tích này giúp bạn nắm vững! 🚀 Nếu cần sâu hơn về triển khai AWS, hãy hỏi nhé.

Câu 36
For this question, refer to the TerramEarth case study. You need to implement a reliable, scalable GCP solution for the data warehouse for your company,
TerramEarth.
Considering the TerramEarth business and technical requirements, what should you do?
  1. A Replace the existing data warehouse with BigQuery. Use table partitioning.
  2. B Replace the existing data warehouse with a Compute Engine instance with 96 CPUs.
  3. C Replace the existing data warehouse with BigQuery. Use federated data sources.
  4. D Replace the existing data warehouse with a Compute Engine instance with 96 CPUs. Add an additional Compute Engine preemptible instance with 32 CPUs.
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 case study TerramEarth – một công ty sản xuất xe tự lái, thu thập dữ liệu lớn từ hơn 2 tỷ xe (khoảng 600 byte/xe/phút), dẫn đến 2.5 PB dữ liệu mới mỗi ngày. Họ cần một giải pháp data warehouse đáng tin cậy và có khả năng mở rộng trên GCP (Google Cloud Platform) để thay thế hệ thống data warehouse hiện tại (on-premises, gặp vấn đề về scalability và độ tin cậy).

Yêu cầu kinh doanh & kỹ thuật chính của TerramEarth:

  • Xử lý dữ liệu lớn thời gian thực (real-time telemetry data).
  • Phân tích dữ liệu lịch sử (historical data).
  • Scalable & reliable: Không downtime, tự động scale theo nhu cầu.
  • Chi phí tối ưu: Tránh over-provisioning tài nguyên.
  • Tích hợp với các dịch vụ GCP khác như Pub/Sub, Dataflow cho ingestion.

📘 Nguồn tham khảo:

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

Đáp án đúng: Replace the existing data warehouse with BigQuery. Use table partitioning.

Lý do 🛠️:

  • BigQuery là dịch vụ data warehouse serverless, fully managed trên GCP, hoàn hảo cho workload lớn của TerramEarth (petabyte-scale analytics). Nó tự động scale theo query workload mà không cần quản lý infrastructure.
  • Table partitioning (chia bảng theo cột thời gian như ngày/tháng) giúp query nhanh hơn 10-100x, giảm chi phí scan dữ liệu (chỉ scan partition cần thiết), và tối ưu cho dữ liệu thời gian (time-series data từ xe). Điều này khớp yêu cầu scalable & cost-effective.
  • Giải pháp này thay thế hoàn toàn DW cũ, migrate dữ liệu vào BigQuery qua Storage Transfer Service hoặc Dataflow.
  • Cập nhật 2026: BigQuery hỗ trợ partitioning + clustering tự động, giảm latency cho IoT data.

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

  • Phương án đúng: Replace the existing data warehouse with BigQuery. Use table partitioning.
    ✅ Đúng vì: BigQuery là lựa chọn lý tưởng cho data warehouse scalable (serverless, columnar storage, ML integration). Partitioning tối ưu cho dữ liệu lớn theo thời gian của TerramEarth, giảm chi phí & tăng performance (query chỉ scan partition liên quan). Không cần lo maintenance như VM.

  • Phương án sai: Replace the existing data warehouse with a Compute Engine instance with 96 CPUs.
    ❌ Sai vì: Compute Engine (VM) yêu cầu manual scaling, không tự động handle 2.5 PB/ngày. 96 CPUs fixed không đủ cho peak load, tốn kém (over-provision), và không managed như BigQuery. TerramEarth cần serverless để reliable.

  • Phương án sai: Replace the existing data warehouse with BigQuery. Use federated data sources.
    ❌ Sai vì: Federated queries chỉ query external data sources (như Cloud SQL, on-prem DB) mà không load dữ liệu vào BigQuery, dẫn đến latency cao & chi phí scan liên tục. TerramEarth cần migrate đầy đủ dữ liệu vào BigQuery để phân tích nhanh, không phải federated (chỉ dùng cho hybrid scenarios).

  • Phương án sai: Replace the existing data warehouse with a Compute Engine instance with 96 CPUs. Add an additional Compute Engine preemptible instance with 32 CPUs.
    ❌ Sai vì: Kết hợp VM thường + preemptible (rẻ nhưng có thể bị GCP kill bất kỳ lúc nào, chỉ 24h max) làm hệ thống không reliable (downtime cao). Không scalable tự động, phức tạp setup cluster (cần thêm tools như Kubernetes), không phù hợp data warehouse workload của TerramEarth.

🏆 Kết luận & khuyến nghị

Giải pháp đúng tận dụng strength của GCP ecosystem (BigQuery + partitioning) để đáp ứng 100% yêu cầu Terram Earth. Nếu implement, thêm Dataflow cho ETL và Cloud Composer cho orchestration.

📘 Tài liệu bổ sung (2026):

Câu 37
For this question, refer to the TerramEarth case study. TerramEarth has a legacy web application that you cannot migrate to cloud. However, you still want to build a cloud-native way to monitor the application. If the application goes down, you want the URL to point to a "Site is unavailable" page as soon as possible. You also want your Ops team to receive a notification for the issue. You need to build a reliable solution for minimum cost. What should you do?
  1. A Create a scheduled job in Cloud Run to invoke a container every minute. The container will check the application URL. If the application is down, switch the URL to the "Site is unavailable" page, and notify the Ops team.
  2. B Create a cron job on a Compute Engine VM that runs every minute. The cron job invokes a Python program to check the application URL. If the application is down, switch the URL to the "Site is unavailable" page, and notify the Ops team.
  3. C Create a Cloud Monitoring uptime check to validate the application URL. If it fails, put a message in a Pub/Sub queue that triggers a Cloud Function to switch the URL to the "Site is unavailable" page, and notify the Ops team.
  4. D Use Cloud Error Reporting to check the application URL. If the application is down, switch the URL to the "Site is unavailable" page, and notify the Ops team.
Xem giải thích

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

Câu hỏi thuộc case study TerramEarth (một công ty sản xuất thiết bị nông nghiệp lớn, có ứng dụng web legacy không thể migrate lên cloud). Yêu cầu xây dựng giải pháp cloud-native để monitor ứng dụng này trên Google Cloud Platform (GCP). Cụ thể:

  • Mục tiêu chính: Kiểm tra tình trạng ứng dụng (URL) liên tục. Nếu ứng dụng down, ngay lập tức chuyển hướng URL sang trang "Site is unavailable".
  • Yêu cầu bổ sung: Gửi thông báo cho Ops team.
  • Tiêu chí: Giải pháp phải reliable (đáng tin cậy, tự động), minimum cost (chi phí thấp nhất, ưu tiên serverless để tránh tài nguyên idle).
  • Thách thức: Ứng dụng legacy on-prem, nên cần monitor từ cloud mà không can thiệp sâu.

Giải pháp phải tận dụng các dịch vụ GCP serverless như Monitoring, Pub/Sub, Cloud Functions để đạt hiệu suất cao, chi phí thấp (pay-per-use), và phản ứng nhanh (uptime check tự động mỗi 1-5 phút tùy config). Kiến thức dựa trên GCP phiên bản mới nhất đến 2026: Cloud Monitoring hỗ trợ uptime checks đa vùng, tích hợp Pub/Sub/Cloud Functions mượt mà (xem GCP docs 2024-2026 updates).

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

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

Đáp án đúng: Create a Cloud Monitoring uptime check to validate the application URL. If it fails, put a message in a Pub/Sub queue that triggers a Cloud Function to switch the URL to the "Site is unavailable" page, and notify the Ops team.

Lý do 🛠️:

  • Cloud-native & Reliable: Uptime check của Cloud Monitoring tự động ping URL từ nhiều vị trí toàn cầu (multi-region), phát hiện downtime chỉ trong 1-5 phút (nhanh nhất có thể), không cần polling thủ công.
  • Tích hợp hoàn hảo: Khi fail → gửi event vào Pub/Sub (queue serverless, decoupled), trigger Cloud Function (chạy on-demand) để switch DNS/URL (qua Cloud DNS hoặc external DNS API) và gửi notify (qua Cloud Monitoring alerts hoặc email/Slack).
  • Minimum cost: Toàn bộ serverless (pay-per-check ~0.001$/check/tháng), không VM/idle resources. Phù hợp best practice GCP Architect (HA, scalable).
  • ASAP response: Event-driven, không delay như cron/scheduled.

📋 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. Mỗi phương án được đánh giá dựa trên reliability, cost, cloud-native, và tốc độ phản ứng.

  • ❌ [SAI] Create a scheduled job in Cloud Run to invoke a container every minute. The container will check the application URL. If the application is down, switch the URL to the "Site is unavailable" page, and notify the Ops team.
    Lý do sai 🧨: Polling thủ công mỗi phút bằng Cloud Run (container serverless) tốn kém hơn (bill theo invocation + CPU/memory), không reliable bằng uptime check chuyên dụng (không multi-region probing). Không tận dụng Monitoring native, vi phạm "cloud-native best practice". Cost cao hơn ~10x so với uptime check.

  • ❌ [SAI] Create a cron job on a Compute Engine VM that runs every minute. The cron job invokes a Python program to check the application URL. If the application is down, switch the URL to the "Site is unavailable" page, and notify the Ops team.
    Lý do sai 🚫: Sử dụng VM Compute Engine luôn chạy → cost cao (fixed VM hourly fee, dù idle), không serverless/scalable. Cron job kém reliable (VM down thì miss check), không cloud-native (legacy-like). Không đạt "minimum cost" và phản ứng chậm nếu VM lag.

  • ✅ [ĐÚNG] Create a Cloud Monitoring uptime check to validate the application URL. If it fails, put a message in a Pub/Sub queue that triggers a Cloud Function to switch the URL to the "Site is unavailable" page, and notify the Ops team.
    Lý do đúng 🌟: Như đã giải thích ở phần trên – tối ưu nhất về cost, reliability, tốc độ (uptime check native + event-driven Pub/Sub/Cloud Functions). Hỗ trợ alerting tích hợp (Ops notify via email/SMS/Teams). Đúng chuẩn GCP Professional Cloud Architect exam.

  • ❌ [SAI] Use Cloud Error Reporting to check the application URL. If the application is down, switch the URL to the "Site is unavailable" page, and notify the Ops team.
    Lý do sai 🔍: Cloud Error Reporting chỉ thu thập/analyze errors từ logs/app crashes (cần agent trên app), KHÔNG dùng để check external URL uptime. Không phát hiện downtime HTTP (404/500), không trigger action tự động. Sai hoàn toàn mục đích, không reliable cho monitoring external legacy app.

Tóm tắt lợi ích giải pháp đúng 🎯: Tiết kiệm ~90% cost so với VM/cron, uptime SLA 99.99%, dễ scale. Khuyến nghị implement thêm Cloud DNS cho switch URL nhanh (TTL thấp)!

Câu 38
As part of Dress4Win's plans to migrate to the cloud, they want to be able to set up a managed logging and monitoring system so they can handle spikes in their traffic load.
They want to ensure that:
* The infrastructure can be notified when it needs to scale up and down to handle the ebb and flow of usage throughout the day
* Their administrators are notified automatically when their application reports errors.
* They can filter their aggregated logs down in order to debug one piece of the application across many hosts
Which Google StackDriver features should they use?
  1. A Logging, Alerts, Insights, Debug
  2. B Monitoring, Trace, Debug, Logging
  3. C Monitoring, Logging, Alerts, Error Reporting
  4. D Monitoring, Logging, Debug, Error Report
Xem giải thích

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

Câu hỏi này xuất phát từ case study Dress4Win trong kỳ thi Google Cloud Professional Cloud Architect. Dress4Win đang lập kế hoạch di chuyển lên cloud (Google Cloud) và cần thiết lập hệ thống logging và monitoring được quản lý (managed) để xử lý các đỉnh tải traffic (spikes). Các yêu cầu cụ thể bao gồm:

  • Thông báo cho infrastructure khi cần scale up/down để xử lý biến động sử dụng hàng ngày (ebb and flow of usage) → Cần metrics theo dõi và alerting dựa trên ngưỡng.
  • Thông báo tự động cho administrators khi ứng dụng báo lỗi (errors) → Cần cơ chế phát hiện và notify lỗi ứng dụng.
  • Lọc logs tổng hợp để debug một phần ứng dụng trên nhiều host → Cần logging mạnh mẽ với khả năng query/filter logs cross-host.

Câu hỏi yêu cầu chọn các tính năng Stackdriver (nay là Google Cloud Observability) phù hợp nhất. Stackdriver là nền tảng quan sát (observability) của Google Cloud, bao gồm Monitoring, Logging, Alerting, Error Reporting, Trace, Debug, v.v. (Cập nhật đến 2026: Các dịch vụ này đã được nâng cấp với AI-powered insights trong Cloud Monitoring và Logging, hỗ trợ multi-cloud/hybrid).

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

✅ Đáp án đúng: Monitoring, Logging, Alerts, Error Reporting

Lý do lựa chọn:

  • 🛠️ Monitoring: Theo dõi metrics (CPU, traffic) và gửi thông báo để kích hoạt autoscaling (scale up/down dựa trên ngưỡng).
  • 📊 Logging: Thu thập và tổng hợp logs từ nhiều host, hỗ trợ filter/query để debug cụ thể (ví dụ: dùng Log Explorer để lọc logs theo service/host).
  • 🚨 Alerts: Tạo chính sách alerting dựa trên metrics/logs để notify admins tự động (email/Slack) khi có lỗi hoặc ngưỡng vượt quá.
  • 🔍 Error Reporting: Tự động phát hiện, nhóm và notify lỗi ứng dụng (app errors) từ logs, giúp admins phản ứng nhanh mà không cần manual check.

Bộ tứ này bao quát toàn bộ 3 yêu cầu một cách chính xác và hiệu quả nhất trong Google Cloud Observability (Stackdriver cũ).

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

  • ❌ Logging, Alerts, Insights, Debug
    Phương án này sai vì thiếu Monitoring (cần thiết cho scale notifications qua metrics). Insights (có thể ám chỉ Log Analytics Insights, nay là AI features) không trực tiếp notify scale hoặc errors. Debug chỉ dùng cho code-level debugging (như Cloud Debugger), không phù hợp cho aggregated logs hay scaling. Không bao quát đầy đủ yêu cầu traffic spikes và app errors.

  • ❌ Monitoring, Trace, Debug, Logging
    Phương án này sai vì thay Alerts và Error Reporting bằng Trace (dùng cho distributed tracing latency) và Debug (code breakpoints). Trace hữu ích cho performance nhưng không notify scale/errors tự động; Debug không liên quan đến logs tổng hợp hay alerting. Thiếu notify admins về errors.

  • ✅ Monitoring, Logging, Alerts, Error Reporting
    Như đã giải thích ở trên, đây là bộ tính năng hoàn hảo, khớp chính xác từng yêu cầu: monitoring cho scale, logging cho filter/debug, alerts cho notify, error reporting cho app errors.

  • ❌ Monitoring, Logging, Debug, Error Report
    Phương án này sai vì dùng Debug thay Alerts (Debug chỉ debug code live, không notify scale/admins), và Error Report (thiếu 'ing') không phải tên chính thức (phải là Error Reporting). Không có alerting tự động cho scale up/down hoặc admins.

Câu 39
For this question, refer to the Dress4Win case study. To be legally compliant during an audit, Dress4Win must be able to give insights in all administrative actions that modify the configuration or metadata of resources on Google Cloud.
What should you do?
  1. A Use Observability Trace to create a Trace list analysis.
  2. B Use Observability Monitoring to create a dashboard on the project's activity.
  3. C Enable Cloud Identity-Aware Proxy in all projects, and add the group of Administrators as a member.
  4. D Use the Activity page in the GCP Console and Observability Logging to provide the required insight.
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 case study Dress4Win (một doanh nghiệp thời trang cần migrate lên Google Cloud Platform - GCP), tập trung vào yêu cầu tuân thủ pháp lý trong quá trình audit. Cụ thể, Dress4Win phải cung cấp insights (thông tin chi tiết) về tất cả các hành động quản trị (administrative actions) có thể thay đổi cấu hình (configuration) hoặc metadata của các tài nguyên trên Google Cloud.

📌 Yêu cầu chính: Cần một giải pháp để theo dõi, ghi nhận và báo cáo các hoạt động admin này một cách đáng tin cậy, giúp đáp ứng kiểm toán pháp lý (compliance audit). Điều này liên quan đến Cloud Audit Logs - dịch vụ ghi log các hành động hệ thống và admin trên GCP, cập nhật đến năm 2026 với các tính năng nâng cao trong Google Cloud Observability (bao gồm Logging, Monitoring, Trace).

🛠️ Bối cảnh kiến thức GCP mới nhất (2026):

  • Activity page trong GCP Console hiển thị tổng quan các hoạt động gần đây, bao gồm audit logs.
  • Cloud Audit Logs (trong Observability Logging) ghi chi tiết admin activity, data access, policy changes, và metadata modifications – chính xác phù hợp với yêu cầu "administrative actions that modify configuration or metadata".
  • Không cần cấu hình phức tạp, chỉ cần enable logging mặc định cho admin activity (miễn phí cho audit logs).

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

Đáp án đúng: Use the Activity page in the GCP Console and Observability Logging to provide the required insight.

Lý do chi tiết:

  • Activity page trong GCP Console cung cấp cái nhìn nhanh chóng, dễ truy cập về lịch sử hoạt động (bao gồm admin actions như tạo/sửa/xóa resources, thay đổi config/metadata).
  • Observability Logging (Cloud Logging) lưu trữ đầy đủ Cloud Audit Logs – loại log chuyên biệt ghi lại tất cả hành động admin (Admin Activity audit logs), bao gồm changes to configuration (ví dụ: IAM policy updates, resource metadata edits).
  • Giải pháp này đơn giản, không tốn kém, đáp ứng ngay yêu cầu audit mà không cần tool bổ sung. Logs có thể export ra BigQuery/Cloud Storage cho phân tích sâu.
  • Hoàn hảo cho compliance vì audit logs là immutable (không thể sửa đổi), giữ nguyên tính toàn vẹn pháp lý.

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

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

  • Use Observability Trace to create a Trace list analysis.
    ❌ Sai vì: Observability Trace dùng để theo dõi latency và performance của ứng dụng (distributed tracing), không ghi admin actions hay config changes. Trace chỉ capture request traces từ services như Cloud Run/App Engine, không phù hợp audit admin metadata modifications. 🕳️ Không liên quan đến compliance logs.

  • Use Observability Monitoring to create a dashboard on the project's activity.
    ❌ Sai vì: Observability Monitoring (Cloud Monitoring) tập trung vào metrics, alerts, uptime (CPU, traffic,...), không phải chi tiết hành động admin cụ thể. Dashboard có thể visualize activity cao cấp nhưng thiếu granularity cho config/metadata changes và không thay thế audit logs. 📊 Chỉ hỗ trợ monitoring, không phải auditing.

  • Enable Cloud Identity-Aware Proxy in all projects, and add the group of Administrators as a member.
    ❌ Sai vì: Cloud Identity-Aware Proxy (IAP) là proxy bảo mật truy cập (context-aware access đến apps/resources), giúp kiểm soát ai truy cập gì. Nó không ghi logs admin actions hay cung cấp insights về config changes. Thêm admin group chỉ enable access, không phải auditing. 🔒 Bảo mật, không phải logging/audit.

  • Use the Activity page in the GCP Console and Observability Logging to provide the required insight.
    ✅ Đúng vì: Như đã giải thích ở trên – kết hợp Activity page (quick view) và Logging (deep audit logs) cung cấp đầy đủ, chính xác insights về admin actions modifying config/metadata. Đáp ứng 100% yêu cầu audit compliance mà không cần setup thêm. 🎯 Giải pháp chuẩn GCP!

🧠 Kết luận: Đây là câu hỏi kiểm tra kiến thức về Cloud Audit Logs trong GCP Security & Compliance. Nên enable audit logging mặc định và thiết lập log sinks cho production để tự động hóa audit. Nếu cần sâu hơn, integrate với Security Command Center!

Câu 40
A news feed web service has the following code running on Google App Engine. During peak load, users report that they can see news articles they already viewed.
What is the most likely cause of this problem? 
import news
from flask import Flask, redirect, request
from flask.ext.api import status
from google.appengine.api import users

app = Flask(__name__)
sessions = {}

@app.route("/")
def homepage():
    user = users.get_current_user()
    if not user:
        return "Invalid login", status.HTTP_401_UNAUTHORIZED

    if user not in sessions:
        sessions[user] = {"viewed": []}

    news_articles = news.get_new_news(user, sessions[user]["viewed"])
    sessions[user]["viewed"] += [n["id"] for n in news_articles]

    return news.render(news_articles)

if __name__ == "__main__":
    app.run()
  1. A The session variable is local to just a single instance
  2. B The session variable is being overwritten in Cloud Datastore
  3. C The URL of the API needs to be modified to prevent caching
  4. D The HTTP Expires header needs to be set to -1 stop caching
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 web service news feed được triển khai trên Google App Engine (một dịch vụ PaaS của Google Cloud), sử dụng framework Flask. Code xử lý như sau:

  • Kiểm tra user hiện tại qua users.get_current_user().
  • Sử dụng biến sessions = {} (một dictionary toàn cục) để lưu trạng thái "viewed" articles của từng user.
  • Lấy news mới qua news.get_new_news(user, sessions[user]["viewed"]), sau đó cập nhật list viewed vào sessions.
  • Trả về rendered news articles.

Vấn đề: Trong peak load (tải cao), users báo cáo thấy lại news articles đã xem. Lý do chính là App Engine tự động scale bằng cách tạo nhiều instances (máy ảo độc lập) để xử lý traffic. Biến sessions là in-memory local (chỉ tồn tại trong RAM của instance đó), không được chia sẻ giữa các instances. Khi user request hit instance khác, sessions[user]["viewed"] rỗng → hiển thị lại articles cũ.

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

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

Đáp án đúng: The session variable is local to just a single instance
Lý do: 🛠️ Biến sessions là dictionary toàn cục nhưng local (in-memory), chỉ tồn tại trên một instance duy nhất. App Engine standard environment scale horizontally (nhiều instances), request từ cùng user có thể phân bổ ngẫu nhiên → instance mới không biết "viewed" list → users thấy lại articles. Giải pháp: Chuyển sessions sang durable storage như Cloud Datastore, Firestore, hoặc Memcache để share cross-instances.

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

  • ✅ The session variable is local to just a single instance
    🧩 Đúng: Như phân tích trên, đây là nguyên nhân gốc rễ. App Engine không share memory giữa instances (kiến trúc serverless multi-tenant), peak load làm instances tăng → session mất đồng bộ.

  • ❌ The session variable is being overwritten in Cloud Datastore
    🛠️ Sai: Code không sử dụng Cloud Datastore (không import ndb hoặc db). Sessions chỉ là dict local, không có overwrite từ Datastore. Vấn đề là thiếu persistence, không phải overwrite.

  • ❌ The URL of the API needs to be modified to prevent caching
    🛠️ Sai: Vấn đề không phải caching client-side/browser (vì code render news mới dựa trên viewed list). Thay đổi URL (như query params) chỉ tránh cache static, không giải quyết session state cross-instances.

  • ❌ The HTTP Expires header needs to be set to -1 stop caching
    🛠️ Sai: Set Expires: -1 hoặc Cache-Control: no-cache chỉ ngăn browser/CDN cache response, nhưng vấn đề là server-side state (session không share). News vẫn được filter sai trên instance khác, dù không cache.