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

Tìm thấy 333 câu.

Câu 311
Company Overview -

KnightMotives is a car manufacturer specializing in autonomous, self-driving vehicles, including Battery Electric Vehicles (BEVs), hybrids and traditional internal combustion engine (ICE) vehicles. While KnightMotives has made strides with the in-vehicle experience in their BEV fleet, the hybrid and ICE vehicles have yet to implement these new systems and are viewed poorly by critics and drivers. The lack of modern in-vehicle technology in hybrid and ICE vehicles has resulted in declining sales and customer satisfaction.

KnightMotives wants to modernize the consumer experience across all vehicles within five years Artificial Intelligence offers a unique opportunity to revolutionize the in-vehicle experience, as well as the shopping buying and service/maintenance experience. Investment in this new technology will require a shift in financial priorities on a global scale.

KnightMotives also wants to improve their online ordering system, which is unreliable. Systems for customers to build their vehicle online for acquisition through a dealer are not delivering the data or reliability that dealers need, causing. A strain in the relationship between KnightMotives and dealers. Service technicians and sales staff need better tooling to enhance dealer successes, including built-to-order vehicles.


Solution Concept -

KnightMotives wants to shift from manufacturing cars to creating a complete and compelling “automotive experience.” Then strategy prioritizes delivering a consistent experience across all models, developing AI-powered features, generating new revenue from data monetization, adopting a digital focus to differentiate their brand from competitors, and developing better tools for mechanics and salespeople.


Existing Technical Environment -

KnightMotives's IT is largely on-premises with some applications on major cloud platforms. Their supply chain runs on an outdated mainframe, and Enterprise Resource Planning (ERP) is also outdated, making new promotions and dealer discounts difficult to implement. Dealers have no budget for new equipment. There is fragmentation across vehicles with multiple code bases, and significant technical debt from supporting backwards compatibility. Network connectivity to manufacturing plants and vehicle connectivity in rural areas are challenges.


Business Requirements -

Key business requirements include fostering a personalized relationship with the driver and delivering a cohesive experience across all models. Creating a better build-to-order model will reduce time on the lot and provide transparency for both dealers and customers. Additionally, KnightMotives seeks to monetize corporate data to finance new technology investments, as their current AI infrastructure is obsolete and corporate data remains siloed. Security is a paramount concern due to past data breaches Adherence to European Union (EU) data protection regulations, especially for emerging autonomous platforms, is critical.

KnightMotives plans to make significant investments in fully autonomous driving capabilities, with initial implementation targeting regions with favorable regulatory environments. Prioritizing employee upskilling, attracting top-tier talent, and fostering better communication between business and technical teams are also critical objectives.


Technical Requirements -

•Modernizing the in-vehicle experience includes developing a consistent user experience (UX) that seamlessly integrates AI-powered features across all models, updating in-vehicle hardware and software in legacy models to support new UX features and AI capabilities, and ensuring reliable network connectivity, especially in rural areas, to support real-time AI features and data transmission.
•Network upgrades are necessary to support increased data traffic and improve connectivity between plants and headquarters.
•IT infrastructure modernization requires adopting a hybrid cloud strategy to leverage the benefits of both on-premises and cloud infrastructure, and gradually modernizing or replacing legacy systems to improve efficiency and agility.
•Autonomous vehicle development and testing requires investing in cutting-edge AI and machine learning technologies, building a robust simulation environment, and ensuring compliance with evolving regulations related to autonomous vehicles.
•Data monetization and insights requires implementing a robust data management platform, strict data security and privacy measures, and a scalable AI/ML infrastructure.
•Increased focus on security and risk management involves implementing a comprehensive security framework to protect against cyber threats and data breaches, developing an incident response plan, and providing security awareness training to employees.
•Providing a delightful experience for dealers and customers requires improving the online build-to-order system; developing modern dealer tools to streamline dealer operations, including sales, service, and inventory management; and implementing a comprehensive Customer Relationship Management (CRM) system to track customer interactions personalize experiences, and improve customer satisfaction.


Executive Statement -

KnightMotives is committed to enhancing safety and saving lives by leveraging an extensive body of data — encompassing driving, road conditions, behavioral studies, and crash safety statistics — to create compelling digital experiences for drivers. Our AI consistently outperforms national safety statistics, ensuring the unique and coveted KnightMotives experience is aligned across all our vehicle models.

Michael Knight, KnightMotives CEO


For this question, refer to the KnightMotives Automotive case study. As part of its cloud strategy. KnightMotives wants to move its virtual machines (VMs) into Google Cloud. These VMs contain applications, database instances, and file servers. In the future, KnightMotives intends to modernize their landscape by adopting cloud native technologies on Google Cloud. During modernization, minimal latency and operational overhead between the old and new landscape will be crucial. You need to design the cloud architecture for the VM environment on Google Cloud while ensuring a future modernization track will meet the technical requirements. What should you do?
  1. A Create a Shared Virtual Private Cloud (VPC). and migrate the VMs to Compute Engine in a new project. During modernization, deploy each modernized workload in a dedicated Google Cloud project with its own VPC. Connect the two VPCs via an on-premises VPN.
  2. B Create a Shared Virtual Private Cloud (VPC). Migrate the VMs to Compute Engine in a new project. During modernization, deploy each modernized workload in a dedicated Google Cloud project using the Shared VPC.
  3. C Create a single private cloud on Google Cloud VMware Engine. Migrate the VMs using VMware HCX. During modernization, deploy the modernized workloads in a single Google Cloud project using a single VPC.
  4. D Create a single private cloud on Google Cloud VMware Engine. Migrate the VMs using VMware HCX. During modernization, deploy each modernized workload in a dedicated Google Cloud project with its own VPC.
Xem giải thích

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

Câu hỏi thuộc phần case study về công ty KnightMotives, một nhà sản xuất xe hơi tập trung vào xe tự lái, xe điện và xe lai. Họ đang gặp vấn đề với hệ thống IT cũ kỹ (on-premises, mainframe lỗi thời, ERP cũ), kết nối mạng kém (đặc biệt khu vực nông thôn), dữ liệu silo, bảo mật yếu và nhu cầu hiện đại hóa trải nghiệm người dùng, AI, hệ thống đặt hàng trực tuyến, cũng như công cụ cho đại lý.

Yêu cầu chính của KnightMotives:

  • Di chuyển các VM (chứa ứng dụng, database, file servers) từ on-premises/major clouds sang Google Cloud.
  • Sau đó, hiện đại hóa (modernize) sang cloud native technologies trên Google Cloud.
  • Quan trọng nhất: Đảm bảo minimal latency và operational overhead giữa môi trường cũ (VMs lift-and-shift) và mới (cloud native) trong quá trình chuyển đổi.
  • Phù hợp với Technical Requirements: Hybrid cloud strategy, nâng cấp mạng, hiện đại hóa IT, data monetization, security cao (tuân thủ EU regs), và hỗ trợ AI/ML scalable.

Mục tiêu thiết kế kiến trúc:

  • Migrate VMs sang Google Cloud (sử dụng Compute Engine hoặc tương đương).
  • Chuẩn bị đường track cho modernization (deploy workloads mới ở các project riêng biệt, kết nối low-latency).
  • Đáp ứng hybrid cloud: Kết hợp on-prem/cloud, nhưng tập trung Google Cloud public.

Câu hỏi kiểm tra kiến thức về migrate VM, Shared VPC (cho multi-project networking low-latency), và Google Cloud VMware Engine (private cloud option). Kiến thức cập nhật đến 2026: Shared VPC (trước đây gọi VPC Sharing) vẫn là best practice cho multi-project với zero-trust networking, latency <1ms intra-region; VMware Engine hỗ trợ HCX cho seamless migration nhưng là private cloud, không ideal cho cloud native public (GCP khuyến nghị Migrate to Compute Engine trước khi modernize sang GKE/Knative).

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

✅ Đáp án đúng: [ĐÚNG] Create a Shared Virtual Private Cloud (VPC). Migrate the VMs to Compute Engine in a new project. During modernization, deploy each modernized workload in a dedicated Google Cloud project using the Shared VPC.

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

  • Shared VPC (host project quản lý network, service projects dùng subnets shared) đảm bảo minimal latency (giao tiếp intra-VPC <1ms, không cần VPN/ peering phức tạp) và low operational overhead giữa VMs cũ (trên Compute Engine) và workloads mới (cloud native như GKE, Cloud Run).
  • Migrate lift-and-shift sang Compute Engine (new project) phù hợp hybrid cloud, dễ scale.
  • Modernization: Mỗi workload mới ở dedicated project (best practice cho isolation/security), nhưng dùng Shared VPC để kết nối seamless với legacy VMs → Giảm overhead, hỗ trợ network upgrades và rural connectivity.
  • Phù hợp case: Security cao (IAM/VPC controls), scalable cho AI/ML/data, tuân thủ EU regs qua Private Service Connect.

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

  • ❌ [SAI] Create a Shared Virtual Private Cloud (VPC). and migrate the VMs to Compute Engine in a new project. During modernization, deploy each modernized workload in a dedicated Google Cloud project with its own VPC. Connect the two VPCs via an on-premises VPN.

    • Phân tích sai: Shared VPC ban đầu tốt cho migrate Compute Engine, nhưng modernization dùng own VPC riêng + on-premises VPN gây high latency (VPN >50ms, overhead cao do NAT/routing) và operational complexity (quản lý peering/VPN tunnels). Không đáp ứng "minimal latency/overhead". VPN on-prem không liên quan vì focus Google Cloud internal.

  • ✅ [ĐÚNG] Create a Shared Virtual Private Cloud (VPC). Migrate the VMs to Compute Engine in a new project. During modernization, deploy each modernized workload in a dedicated Google Cloud project using the Shared VPC.

    • Phân tích đúng: Như trên, Shared VPC là giải pháp tối ưu cho multi-project (legacy + modern), zero-overhead networking (same VPC subnets), hỗ trợ hybrid cloud và future cloud native (GKE attach to Shared VPC). Minimal disruption, scale dễ dàng cho data/AI traffic.

  • ❌ [SAI] Create a single private cloud on Google Cloud VMware Engine. Migrate the VMs using VMware HCX. During modernization, deploy the modernized workloads in a single Google Cloud project using a single VPC.

    • Phân tích sai: VMware Engine là private cloud (chạy VMware stack trên GCP hardware), HCX migrate tốt nhưng không phải cloud native public (khó modernize sang GKE/Cloud Run). Single project/single VPC vi phạm isolation (security risk cao với data breaches history), không flexible cho dedicated workloads, tăng overhead khi scale AI/ML.

  • ❌ [SAI] Create a single private cloud on Google Cloud VMware Engine. Migrate the VMs using VMware HCX. During modernization, deploy each modernized workload in a dedicated Google Cloud project with its own VPC.

    • Phân tích sai: VMware Engine + HCX ổn cho lift-shift, nhưng modernization own VPC riêng gây latency/overhead cao (VPC peering 1-5ms + config phức tạp). Không hỗ trợ seamless hybrid public cloud native, contradict "adopting cloud native technologies on Google Cloud" và network upgrades minimal.

Kết luận 🚀: Shared VPC + Compute Engine là blueprint chuẩn cho migrate-then-modernize trên GCP (Land and Expand strategy), đảm bảo business continuity cho KnightMotives!

Câu 312
Company Overview -

KnightMotives is a car manufacturer specializing in autonomous, self-driving vehicles, including Battery Electric Vehicles (BEVs), hybrids and traditional internal combustion engine (ICE) vehicles. While KnightMotives has made strides with the in-vehicle experience in their BEV fleet, the hybrid and ICE vehicles have yet to implement these new systems and are viewed poorly by critics and drivers. The lack of modern in-vehicle technology in hybrid and ICE vehicles has resulted in declining sales and customer satisfaction.

KnightMotives wants to modernize the consumer experience across all vehicles within five years Artificial Intelligence offers a unique opportunity to revolutionize the in-vehicle experience, as well as the shopping buying and service/maintenance experience. Investment in this new technology will require a shift in financial priorities on a global scale.

KnightMotives also wants to improve their online ordering system, which is unreliable. Systems for customers to build their vehicle online for acquisition through a dealer are not delivering the data or reliability that dealers need, causing. A strain in the relationship between KnightMotives and dealers. Service technicians and sales staff need better tooling to enhance dealer successes, including built-to-order vehicles.


Solution Concept -

KnightMotives wants to shift from manufacturing cars to creating a complete and compelling “automotive experience.” Then strategy prioritizes delivering a consistent experience across all models, developing AI-powered features, generating new revenue from data monetization, adopting a digital focus to differentiate their brand from competitors, and developing better tools for mechanics and salespeople.


Existing Technical Environment -

KnightMotives's IT is largely on-premises with some applications on major cloud platforms. Their supply chain runs on an outdated mainframe, and Enterprise Resource Planning (ERP) is also outdated, making new promotions and dealer discounts difficult to implement. Dealers have no budget for new equipment. There is fragmentation across vehicles with multiple code bases, and significant technical debt from supporting backwards compatibility. Network connectivity to manufacturing plants and vehicle connectivity in rural areas are challenges.


Business Requirements -

Key business requirements include fostering a personalized relationship with the driver and delivering a cohesive experience across all models. Creating a better build-to-order model will reduce time on the lot and provide transparency for both dealers and customers. Additionally, KnightMotives seeks to monetize corporate data to finance new technology investments, as their current AI infrastructure is obsolete and corporate data remains siloed. Security is a paramount concern due to past data breaches Adherence to European Union (EU) data protection regulations, especially for emerging autonomous platforms, is critical.

KnightMotives plans to make significant investments in fully autonomous driving capabilities, with initial implementation targeting regions with favorable regulatory environments. Prioritizing employee upskilling, attracting top-tier talent, and fostering better communication between business and technical teams are also critical objectives.


Technical Requirements -

•Modernizing the in-vehicle experience includes developing a consistent user experience (UX) that seamlessly integrates AI-powered features across all models, updating in-vehicle hardware and software in legacy models to support new UX features and AI capabilities, and ensuring reliable network connectivity, especially in rural areas, to support real-time AI features and data transmission.
•Network upgrades are necessary to support increased data traffic and improve connectivity between plants and headquarters.
•IT infrastructure modernization requires adopting a hybrid cloud strategy to leverage the benefits of both on-premises and cloud infrastructure, and gradually modernizing or replacing legacy systems to improve efficiency and agility.
•Autonomous vehicle development and testing requires investing in cutting-edge AI and machine learning technologies, building a robust simulation environment, and ensuring compliance with evolving regulations related to autonomous vehicles.
•Data monetization and insights requires implementing a robust data management platform, strict data security and privacy measures, and a scalable AI/ML infrastructure.
•Increased focus on security and risk management involves implementing a comprehensive security framework to protect against cyber threats and data breaches, developing an incident response plan, and providing security awareness training to employees.
•Providing a delightful experience for dealers and customers requires improving the online build-to-order system; developing modern dealer tools to streamline dealer operations, including sales, service, and inventory management; and implementing a comprehensive Customer Relationship Management (CRM) system to track customer interactions personalize experiences, and improve customer satisfaction.


Executive Statement -

KnightMotives is committed to enhancing safety and saving lives by leveraging an extensive body of data — encompassing driving, road conditions, behavioral studies, and crash safety statistics — to create compelling digital experiences for drivers. Our AI consistently outperforms national safety statistics, ensuring the unique and coveted KnightMotives experience is aligned across all our vehicle models.

Michael Knight, KnightMotives CEO


For this question, refer to the KnightMotives Automotive case study. KnightMotives has developed and deployed a model on Vertex AI that can provide personalized recommendations in the new car configuration application. Customers will receive optional equipment recommendations that best suit their persona. Previous usage data from the car configuration application has been used for model training features. You know from past experience that customer behavior can change over time. For example, in times of economic certainty and rising stock markets, customers tend to purchase more expensive options. You want to detect when customer behavior gradually changes over time so you can adjust the model. What should you do?
  1. A Configure Model Monitoring, and select training-serving skew detection.
  2. B Configure Model Monitoring, and select prediction drift detection.
  3. C Configure Dataplex auto data quality on the prediction request data features using row-level rules.
  4. D Configure Dataplex auto data quality on the prediction request data features using aggregate rules.
Xem giải thích

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

Câu hỏi thuộc phần case study về KnightMotives Automotive, tập trung vào việc triển khai một mô hình Machine Learning (ML) trên Vertex AI (dịch vụ của Google Cloud) để cung cấp các khuyến nghị cá nhân hóa (personalized recommendations) trong ứng dụng cấu hình xe mới. Mô hình được huấn luyện dựa trên dữ liệu sử dụng trước đó từ ứng dụng cấu hình xe.

Vấn đề chính: Hành vi khách hàng có thể thay đổi dần dần theo thời gian (ví dụ: trong thời kỳ kinh tế ổn định và thị trường chứng khoán tăng, khách hàng mua nhiều tùy chọn đắt tiền hơn). Công ty muốn phát hiện sự thay đổi dần dần này để điều chỉnh mô hình kịp thời, đảm bảo mô hình vẫn chính xác và phù hợp với dữ liệu mới.

Yêu cầu kỹ thuật liên quan: Sử dụng công cụ giám sát mô hình để theo dõi sự thay đổi hành vi khách hàng qua dữ liệu đầu vào dự đoán (prediction inputs), phù hợp với Technical Requirements về AI/ML infrastructure, data monetization, và modernizing in-vehicle/ordering experience.

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

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

Configure Model Monitoring, and select prediction drift detection.

Lý do: Vertex AI Model Monitoring cho phép cấu hình prediction drift detection để phát hiện sự thay đổi dần dần (drift) trong phân phối dữ liệu đầu vào dự đoán (prediction features) hoặc đầu ra dự đoán theo thời gian. Điều này trực tiếp giải quyết vấn đề "customer behavior can change over time" bằng cách so sánh dữ liệu mới với baseline (dữ liệu tham chiếu từ quá khứ), giúp phát hiện drift sớm và kích hoạt retraining. Đây là tính năng tiêu chuẩn của Vertex AI (cập nhật mới nhất 2026), phù hợp với yêu cầu hybrid cloud và AI infrastructure modernization của KnightMotives. 🛠️

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

  • Configure Model Monitoring, and select training-serving skew detection.
    ❌ Sai: Training-serving skew detection chỉ so sánh sự khác biệt giữa dữ liệu huấn luyện (training data) và dữ liệu đầu vào dự đoán thực tế (serving data) tại một thời điểm, không theo dõi sự thay đổi dần dần theo thời gian. Nó phù hợp cho việc kiểm tra skew ban đầu khi deploy, nhưng không detect drift dài hạn như thay đổi hành vi khách hàng. Không khớp yêu cầu.

  • Configure Model Monitoring, and select prediction drift detection.
    ✅ Đúng: Như đã giải thích ở trên, đây là lựa chọn tối ưu để detect drift trong prediction data/features theo thời gian, sử dụng thống kê như KS test hoặc Jensen-Shannon divergence (cập nhật Vertex AI 2026). Giúp tự động alert và retrain mô hình.

  • Configure Dataplex auto data quality on the prediction request data features using row-level rules.
    ❌ Sai: Dataplex là dịch vụ quản lý dữ liệu và chất lượng dữ liệu (data cataloging/quality), không phải công cụ giám sát ML model. Row-level rules chỉ kiểm tra chất lượng từng hàng dữ liệu (ví dụ: missing values), không detect sự thay đổi phân phối (drift) theo thời gian trong context ML. Không liên quan đến Vertex AI monitoring.

  • Configure Dataplex auto data quality on the prediction request data features using aggregate rules.
    ❌ Sai: Tương tự phương án trên, aggregate rules trong Dataplex kiểm tra chất lượng dữ liệu tổng hợp (như tỷ lệ null aggregate), nhưng chỉ là data quality validation, không phải ML-specific drift detection. Không hỗ trợ theo dõi hành vi thay đổi động trong prediction data của Vertex AI.

🧠 Kết luận: Lựa chọn đúng tận dụng Vertex AI Model Monitoring – giải pháp native, scalable cho production ML tại Google Cloud, phù hợp chiến lược hybrid cloud và AI upskilling của KnightMotives. 🚀

Câu 313
Your team plans to use Vertex AI to develop and deploy machine learning models for various use cases for fraud detection, product recommendations, and customer churn prediction. You want to enhance the security posture of the Vertex AI and Workbench environment by restricting data exfiltration. What should you do?
  1. A Enable Private Google Access for the VPC network to allow Vertex AI services to access public Google services without traversing the public internet.
  2. B Enable VPC Flow Logs to monitor network traffic to and from Vertex AI services and to identify suspicious activity.
  3. C Create a service perimeter and include ml.googleapis.com and document.googleapis.com as protected services.
  4. D Create a service perimeter and include aiplatform.googleapis.com and notebooks.googleapis.com as protected services.
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 việc tăng cường bảo mật cho môi trường Vertex AI và Workbench trên Google Cloud bằng cách hạn chế rò rỉ dữ liệu (data exfiltration). Đội ngũ đang phát triển và triển khai các mô hình ML cho các trường hợp sử dụng như phát hiện gian lận (fraud detection), khuyến nghị sản phẩm (product recommendations), và dự đoán khách hàng rời bỏ (customer churn prediction).

Mục tiêu chính là sử dụng Service Perimeter (một phần của VPC Service Controls - VPC-SC) để bảo vệ các dịch vụ liên quan, ngăn chặn dữ liệu nhạy cảm bị chuyển ra ngoài perimeter một cách không được phép. Đây là best practice để bảo vệ tài nguyên ML khỏi các lỗ hổng exfiltration, đặc biệt với dữ liệu cá nhân hoặc kinh doanh nhạy cảm trong Vertex AI.

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

✅ Đáp án đúng

Create a service perimeter and include aiplatform.googleapis.com and notebooks.googleapis.com as protected services.

Lý do lựa chọn:

  • Đây là cách chính xác nhất để ngăn data exfiltration bằng VPC Service Controls. aiplatform.googleapis.com là API chính cho Vertex AI (bao gồm training, deployment, endpoints cho fraud detection, recommendations, churn prediction). notebooks.googleapis.com bảo vệ Vertex AI Workbench (môi trường notebooks để phát triển ML).
  • Service Perimeter sẽ chặn các API call ra ngoài nếu không được phép, đảm bảo dữ liệu ML không bị leak qua các dịch vụ không được kiểm soát. Đây là khuyến nghị mới nhất từ Google (2024+), phù hợp với kiến thức cập nhật đến 2026. 🛡️

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

  • ❌ Enable Private Google Access for the VPC network to allow Vertex AI services to access public Google services without traversing the public internet.
    Phương án này sai vì Private Google Access chỉ giúp truy cập các Google APIs qua private IP (không qua public internet), giảm rủi ro lộ IP public nhưng không ngăn data exfiltration. Nó không tạo boundary bảo vệ dữ liệu khỏi leak ra ngoài VPC, chỉ là network-level access control cơ bản. Không liên quan trực tiếp đến Vertex AI security perimeter.

  • ❌ Enable VPC Flow Logs to monitor network traffic to and from Vertex AI services and to identify suspicious activity.
    Phương án này sai vì VPC Flow Logs chỉ giám sát và log traffic (visibility tool), giúp phát hiện suspicious activity sau sự kiện nhưng không prevent exfiltration. Đây là công cụ reactive (phân tích sau), không phải proactive control như Service Perimeter cần thiết cho Vertex AI.

  • ❌ Create a service perimeter and include ml.googleapis.com and document.googleapis.com as protected services.
    Phương án này sai vì các API được chọn không chính xác. ml.googleapis.com là API cũ (Cloud ML Engine, đã deprecated từ 2022, thay bằng Vertex AI). document.googleapis.com là cho Google Docs (không liên quan đến ML). Không bảo vệ Vertex AI hoặc Workbench, dẫn đến lỗ hổng exfiltration ở các dịch vụ cốt lõi.

  • ✅ Create a service perimeter and include aiplatform.googleapis.com and notebooks.googleapis.com as protected services.
    Phương án này đúng như đã giải thích ở trên. Đây là dry-run và enforced mode chuẩn của VPC-SC cho Vertex AI (xác nhận qua Google Cloud console và docs 2026). Hoàn hảo cho use cases ML nhạy cảm! 🎯

Câu 314
You have an application that uses Vertex AI Feature Store to manage and serve product features for real-time recommendations. You want to monitor the performance and health of the application. You need to understand the overall duration of a request. What should you do?
  1. A Observe the Request size in your featurestore.
  2. B Monitor the Queries per second for your featurestore.
  3. C Measure the Latency of your requests.
  4. D Track the Online serving throughput of your requests.
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 tập trung vào việc giám sát hiệu suất và sức khỏe (performance and health) của một ứng dụng sử dụng Vertex AI Feature Store trên Google Cloud để quản lý và phục vụ các features sản phẩm cho hệ thống recommendations thời gian thực (real-time recommendations).
Yêu cầu cụ thể là cần hiểu tổng thời gian xử lý của một request (overall duration of a request). Đây là một metric quan trọng để đánh giá độ trễ (latency) trong việc truy vấn và phục vụ features từ Feature Store, giúp đảm bảo ứng dụng hoạt động mượt mà, đặc biệt trong môi trường real-time.
Vertex AI Feature Store hỗ trợ các metrics giám sát qua Cloud Monitoring, bao gồm latency, throughput, QPS (queries per second), v.v., theo tài liệu cập nhật mới nhất của Google Cloud (phiên bản 2024-2026).

✅ Đáp án đúng:
Measure the Latency of your requests.
Lý do chọn:
"Overall duration of a request" chính xác mô tả latency – thời gian từ khi gửi request đến khi nhận response đầy đủ. Trong Vertex AI Feature Store, metric Latency (thường đo bằng p50, p95, p99) được Cloud Monitoring cung cấp trực tiếp để theo dõi thời gian xử lý Online Serving requests. Điều này giúp phát hiện bottleneck, đảm bảo real-time performance. Sử dụng Vertex AI Monitoring hoặc Cloud Monitoring dashboards để đo lường.
(Nguồn: Google Cloud Docs - Vertex AI Feature Store Monitoring & Cloud Monitoring Metrics List, cập nhật 2025).

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

  • Observe the Request size in your featurestore.
    ❌ Sai: Phương án này chỉ theo dõi kích thước request (request size), liên quan đến lượng dữ liệu truyền (bytes), không phản ánh thời gian xử lý tổng thể (duration). Request size hữu ích cho việc tối ưu hóa chi phí hoặc bandwidth, nhưng không đo lường latency hay sức khỏe real-time.

  • Monitor the Queries per second for your featurestore.
    ❌ Sai: Queries per second (QPS) đo tần suất truy vấn, giúp đánh giá tải hệ thống (load), nhưng không cho biết thời gian mỗi request mất bao lâu (duration). QPS cao có thể đi kèm latency cao nếu có bottleneck, nhưng không trực tiếp trả lời yêu cầu.

  • Measure the Latency of your requests.
    ✅ Đúng: Như đã giải thích ở trên, đây là metric chính xác nhất cho overall duration, được Vertex AI Feature Store hỗ trợ qua các histogram metrics như featurestore.googleapis.com/online_serving/latency. Giúp monitor health và tối ưu recommendations.

  • Track the Online serving throughput of your requests.
    ❌ Sai: Throughput đo số lượng requests xử lý thành công mỗi giây, tập trung vào công suất (capacity), không phải thời gian xử lý từng request (duration). Throughput cao không đảm bảo latency thấp, và metric này (như featurestore.googleapis.com/online_serving/throughput) dùng cho scaling, không phải đo duration.

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

Câu 315
A large healthcare provider's primary electronic health record (EHR) application runs on Compute Engine instances with a Cloud SQL for PostgreSQL database, all located in the us-west1 region. A new regulatory mandate requires you to implement and document a business continuity plan (BCP). This plan must ensure that the EHR application can be fully recovered and operational in a different geographical region with a recovery time objective (RTO) of two hours and a recovery point objective (RPO) of 15 minutes. You need to design a disaster recovery strategy that meets these strict BCP requirements. What should you do?
  1. A Deploy active managed instance groups (MIGs) in both us-west1 and us-east1, fronted by a global external HTTP(S) Load Balancer. For the database, use a cross-region read replica in us-east1, and rely on load balancer health checks to automatically fail over all traffic during an outage.
  2. B Use Terraform to define the application’s compute infrastructure. During a disaster, configure the Cloud SQL database in us-west1 to use a cross-region read replica in us-east1, build the environment in us-east1, and promote the replica.
  3. C Take daily snapshots of the Compute Engine disks and Cloud SQL database. Copy these snapshots to a Cloud Storage bucket in us-east1. During a disaster, manually restore the virtual machines (VMs) and database from the latest snapshots
  4. D Deploy a regional MIG in us-west1 for high availability, and rely on the Google Cloud SLA to ensure the region remains online.
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 nhà cung cấp dịch vụ y tế lớn với ứng dụng hồ sơ sức khỏe điện tử (EHR) chính chạy trên các instance Compute Engine và cơ sở dữ liệu Cloud SQL for PostgreSQL, tất cả đều nằm trong vùng us-west1. Một quy định mới yêu cầu triển khai và tài liệu hóa Kế hoạch liên tục kinh doanh (BCP - Business Continuity Plan), đảm bảo ứng dụng EHR có thể phục hồi hoàn toàn và hoạt động ở một vùng địa lý khác với:

  • RTO (Recovery Time Objective): 2 giờ (thời gian tối đa để khôi phục hệ thống sau sự cố).
  • RPO (Recovery Point Objective): 15 phút (mất dữ liệu tối đa chấp nhận được).

Nhiệm vụ là thiết kế chiến lược phục hồi thảm họa (Disaster Recovery - DR) đáp ứng các yêu cầu nghiêm ngặt này. 🛠️ Yêu cầu chính: Phải hỗ trợ failover tự động hoặc nhanh chóng sang vùng khác (ví dụ: us-east1), đảm bảo dữ liệu đồng bộ gần thời gian thực (RPO 15 phút) và khôi phục nhanh (RTO 2 giờ), không chỉ HA trong vùng mà là DR cross-region.

📘 Kiến thức cập nhật GCP đến 2026: Theo tài liệu GCP mới nhất (Google Cloud Disaster Recovery strategies, Cloud SQL High Availability & DR - cập nhật 2025), chiến lược DR lý tưởng sử dụng Managed Instance Groups (MIGs) active-active, Global Load Balancer với health checks tự động failover, và cross-region read replicas cho Cloud SQL (hỗ trợ promotion nhanh dưới 1 giờ, replication lag thường <5-15 phút).

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

Đáp án đúng: Deploy active managed instance groups (MIGs) in both us-west1 and us-east1, fronted by a global external HTTP(S) Load Balancer. For the database, use a cross-region read replica in us-east1, and rely on load balancer health checks to automatically fail over all traffic during an outage.

Lý do:

  • MIGs active ở cả hai vùng đảm bảo ứng dụng luôn chạy song song (active-active), Global HTTP(S) LB với health checks tự động chuyển hướng traffic sang vùng lành mạnh trong vài phút (RTO << 2 giờ).
  • Cross-region read replica cho Cloud SQL PostgreSQL cho phép replication lag thấp (<15 phút, thường real-time), và có thể promote replica nhanh chóng nếu cần (tự động qua LB failover traffic).
  • Đáp ứng BCP đầy đủ: Tự động, cross-region, RTO/RPO đạt yêu cầu, không thủ công. 🏆 Hoàn hảo cho DR pilot light/active-active.

Nguồn tham khảo:

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

  • [ĐÚNG] Deploy active managed instance groups (MIGs) in both us-west1 and us-east1, fronted by a global external HTTP(S) Load Balancer. For the database, use a cross-region read replica in us-east1, and rely on load balancer health checks to automatically fail over all traffic during an outage.
    ✅ Đúng hoàn toàn: Như giải thích trên, triển khai active-active MIGs với Global LB cho failover tự động (health checks phát hiện outage trong giây/phút), kết hợp read replica cross-region đảm bảo RPO 15 phút (replication asynchronous nhưng lag thấp) và RTO <2 giờ. Đây là best practice DR cho ứng dụng stateful như EHR. 🛡️

  • [SAI] Use Terraform to define the application’s compute infrastructure. During a disaster, configure the Cloud SQL database in us-west1 to use a cross-region read replica in us-east1, build the environment in us-east1, and promote the replica.
    ❌ Sai: Sử dụng Terraform IaC tốt cho tái tạo infra, nhưng quy trình thủ công trong disaster (build env, promote replica) mất giờ đến ngày (>RTO 2 giờ). Read replica chỉ configure lúc disaster → không sẵn sàng trước, RPO không đảm bảo do lag + thời gian promote. Không tự động, không phù hợp BCP nghiêm ngặt. 🕒

  • [SAI] Take daily snapshots of the Compute Engine disks and Cloud SQL database. Copy these snapshots to a Cloud Storage bucket in us-east1. During a disaster, manually restore the virtual machines (VMs) and database from the latest snapshots.
    ❌ Sai nghiêm trọng: Snapshots hàng ngày chỉ RPO 24 giờ (mất dữ liệu lớn >15 phút). Khôi phục thủ công VMs/DB từ Storage mất nhiều giờ (create instances, attach disks, restore DB → >RTO 2 giờ). Chỉ là backup cơ bản, không phải DR cross-region thực thụ. 💥 Không đạt yêu cầu.

  • [SAI] Deploy a regional MIG in us-west1 for high availability, and rely on the Google Cloud SLA to ensure the region remains online.
    ❌ Sai cơ bản: Regional MIG chỉ HA trong vùng us-west1 (zone-redundant), không cross-region → nếu vùng outage (hiếm nhưng BCP yêu cầu), không failover được. SLA GCP (99.99% regional) không đảm bảo zero downtime cross-region, vi phạm yêu cầu khác geographical region. 🚫 Chỉ HA, không DR.

Kết luận tổng quát 🎯: Chiến lược đúng phải tự động, active-active cross-region để đáp ứng RTO/RPO nghiêm ngặt của ngành y tế. Các phương án sai chủ yếu thủ công hoặc không cross-region. Tham khảo thêm: GCP DR Best Practices Whitepaper 2025.

Câu 316
A financial services company is decommissioning one of its on-premises data centers. As part of this initiative, the company needs to perform a one-time migration of 500 ТВ of historical transaction archives to a Cloud Storage bucket for long-term retention. The data center’s internet egress is 1 Gbps, which is shared with critical business operations. You must complete the secure data transfer within a 60-day window to meet the decommissioning deadline. What should you do?
  1. A Provision a Partner Interconnect connection with a 10 Gbps capacity to accelerate the data transfer, and then use Storage Transfer Service.
  2. B Write a script that uses the gcloud storage cp --parallel command to upload the data in chunks over the public internet during off-peak hours.
  3. C Use Storage Transfer Service to create an agent-based transfer job that moves the data from the on-premises file servers directly to the Cloud Storage bucket.
  4. D Order a Transfer Appliance, copy the data to the appliance using your high-speed local network, and ship it back to Google to upload the data into your Cloud Storage bucket.
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ả tình huống một công ty dịch vụ tài chính đang tháo dỡ (decommission) một trung tâm dữ liệu on-premises. Họ cần di chuyển một lần duy nhất (one-time migration) khối lượng dữ liệu khổng lồ 500 TB lưu trữ lịch sử giao dịch (historical transaction archives) vào Cloud Storage bucket trên Google Cloud để lưu trữ dài hạn (long-term retention).

🔍 Thách thức chính:

  • Tốc độ egress internet của data center chỉ 1 Gbps (khoảng 125 MB/s), và bị chia sẻ với các hoạt động kinh doanh quan trọng (critical business operations), nên không thể sử dụng hết công suất mà không ảnh hưởng.
  • Phải hoàn thành trong vòng 60 ngày để kịp deadline tháo dỡ.
  • Yêu cầu chuyển dữ liệu an toàn (secure data transfer), đặc biệt với dữ liệu tài chính nhạy cảm.

🛠️ Mục tiêu: Tìm giải pháp tối ưu để upload 500 TB nhanh chóng, an toàn, không phụ thuộc vào internet egress hạn chế, phù hợp với quy mô lớn và thời hạn chặt chẽ. (Lưu ý: Kiến thức dựa trên Google Cloud cập nhật đến 2026, Transfer Appliance vẫn là giải pháp chuẩn cho data transfer >100 TB one-time theo docs chính thức).

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

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

Đáp án đúng: Order a Transfer Appliance, copy the data to the appliance using your high-speed local network, and ship it back to Google to upload the data into your Cloud Storage bucket.

Lý do 🏆:

  • Phù hợp hoàn hảo với one-time migration lớn (500 TB): Transfer Appliance (hay "Transfer Appliance v2" mới nhất 2026) là thiết bị vật lý dung lượng cao (lên đến 480 TB/appliance, có thể dùng nhiều cái), copy dữ liệu qua mạng nội bộ tốc độ cao (high-speed local network), tránh hoàn toàn internet egress.
  • An toàn và nhanh chóng: Dữ liệu được mã hóa AES-256, ship qua dịch vụ vận chuyển bảo mật (Google partner như UPS/FedEx), Google tự upload vào bucket. Thời gian: Copy local ~vài ngày, ship 2 chiều ~1 tuần, tổng <60 ngày dễ dàng.
  • Không ảnh hưởng business: Không dùng egress shared, lý tưởng cho financial data nhạy cảm.
  • Tiết kiệm chi phí dài hạn so với tăng bandwidth dedicated.

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

  • ❌ [SAI] Provision a Partner Interconnect connection with a 10 Gbps capacity to accelerate the data transfer, and then use Storage Transfer Service.
    Phân tích: Partner Interconnect cung cấp kết nối dedicated 10 Gbps, kết hợp STS có thể nhanh hơn internet public. Tuy nhiên sai vì: Setup Interconnect mất 2-4 tuần (provisioning, cross-connect), cộng thời gian transfer ~20-30 ngày cho 500 TB → vượt 60 ngày. Chi phí cao cho one-time, không cần thiết khi có Transfer Appliance rẻ hơn. Không phải lựa chọn nhanh nhất cho deadline chặt.

  • ❌ [SAI] Write a script that uses the gcloud storage cp --parallel command to upload the data in chunks over the public internet during off-peak hours.
    Phân tích: Lệnh gcloud storage cp --parallel upload parallel qua internet, off-peak giảm tải. Tuy nhiên sai vì: Egress chỉ 1 Gbps shared → tốc độ thực tế <<125 MB/s, thời gian transfer 500 TB >200 ngày (tính toán: 50010^12 bytes / (12510^6 B/s * 0.7 hiệu suất * 36002460) ≈ 250+ ngày). Không an toàn (public internet dễ rủi ro DDoS/leak cho financial data), vi phạm yêu cầu secure.

  • ❌ [SAI] Use Storage Transfer Service to create an agent-based transfer job that moves the data from the on-premises file servers directly to the Cloud Storage bucket.
    Phân tích: STS agent (Transfer Agent) cài trên server on-prem, transfer trực tiếp đến GCS, hỗ trợ resume. Tuy nhiên sai vì: Vẫn phụ thuộc egress internet 1 Gbps shared → tốc độ chậm tương tự lựa chọn B (>60 ngày), có thể gây gián đoạn business critical. Không tối ưu cho 500 TB one-time so với offline solution.

  • ✅ [ĐÚNG] Order a Transfer Appliance, copy the data to the appliance using your high-speed local network, and ship it back to Google to upload the data into your Cloud Storage bucket.
    Phân tích: Như đã giải thích ở trên – hoàn hảo cho quy mô lớn, bypass internet, secure, kịp deadline. Được AWS/GCP khuyến nghị cho >100 TB (GCP docs xác nhận).

🧠 Kết luận: Transfer Appliance là "best practice" cho migrate lớn on-prem to cloud khi bandwidth hạn chế! 🚀

Câu 317
A retail company s most critical application is its online payment processing system. The business has a requirement that the system must be able to survive a complete zonal outage while minimizing cost. You need a design solution that can handle a zonal failure. What should you do?
  1. A Deploy the application in an active-active configuration using managed instance groups (MIGs) in two different regions, fronted by a global external HTTP(S) Load Balancer and backed by a multi-regional database like Spanner.
  2. B Deploy the application on a regional MIG to provide high availability across multiple zones in the primary region.
  3. C Configure the regional MIG to use only Spot VMs to aggressively minimize operational costs while maintaining high availability.
  4. D Deploy the application on Compute Engine instances across multiple regions, and rely on daily snapshots for recovery to achieve the lowest possible cost.
Xem giải thích

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

Câu hỏi mô tả một công ty bán lẻ có ứng dụng quan trọng nhất là hệ thống xử lý thanh toán trực tuyến. Yêu cầu chính là:

  • Hệ thống phải chịu được sự cố toàn bộ một zone (zonal outage), nghĩa là nếu một zone trong region bị sập hoàn toàn, ứng dụng vẫn hoạt động bình thường.
  • Đồng thời tối ưu hóa chi phí (minimizing cost), tránh các giải pháp đắt đỏ không cần thiết.
    Nhiệm vụ là thiết kế giải pháp trên Google Cloud Platform (GCP) để xử lý zonal failure một cách hiệu quả nhất, dựa trên kiến thức cập nhật đến năm 2026 (theo tài liệu GCP mới nhất về Compute Engine và Managed Instance Groups - MIGs).

Mục tiêu cốt lõi: Đảm bảo high availability (HA) trong cùng một region (multi-zone), không cần multi-region vì chỉ yêu cầu chống zonal outage, giúp tiết kiệm chi phí so với các setup toàn cầu hoặc đa vùng.

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

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

Đáp án đúng:
Deploy the application on a regional MIG to provide high availability across multiple zones in the primary region.

Lý do chi tiết:
🛠️ Regional MIG (Managed Instance Group) tự động phân bổ các instance VM qua nhiều zone trong cùng một region chính (primary region), đảm bảo high availability (HA) và khả năng chịu lỗi zonal outage. Nếu một zone sập, MIG sẽ tự động heal bằng cách tạo instance mới ở zone khác trong region.
💰 Tối ưu chi phí: Chỉ dùng tài nguyên trong một region, rẻ hơn multi-region (không cần global LB hay multi-regional DB như Spanner). Phù hợp với yêu cầu "survive a complete zonal outage while minimizing cost".
✅ Đây là giải pháp standard và được khuyến nghị cho HA zonal trên GCP, với SLA 99.99% cho regional MIGs (cập nhật 2025).

❌ Phân tích tất cả các phương án

Dưới đây là giải thích từng phương án một, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá đúng/sai dựa trên yêu cầu (chịu zonal outage + minimize cost).

  • [SAI] Deploy the application in an active-active configuration using managed instance groups (MIGs) in two different regions, fronted by a global external HTTP(S) Load Balancer and backed by a multi-regional database like Spanner.
    ❌ Sai vì: Giải pháp này dùng multi-region active-active, chịu được cả regional outage (không chỉ zonal), nhưng quá đắt đỏ (global LB + Spanner có chi phí cao gấp nhiều lần regional setup). Yêu cầu chỉ cần chống zonal outage trong region, nên không cần thiết và vi phạm "minimizing cost". Spanner dù mạnh nhưng overkill cho payment app nếu không yêu cầu global consistency.

  • [ĐÚNG] Deploy the application on a regional MIG to provide high availability across multiple zones in the primary region.
    ✅ Đúng như đã giải thích ở trên: Regional MIG phân bổ instance đa zone trong region, tự heal zonal failure, chi phí thấp nhất phù hợp yêu cầu.

  • [SAI] Configure the regional MIG to use only Spot VMs to aggressively minimize operational costs while maintaining high availability.
    ❌ Sai vì: Spot VMs (trước đây gọi preemptible) có thể bị preempt bất kỳ lúc nào (preemption rate cao), không đảm bảo high availability cho ứng dụng critical như payment processing (rủi ro downtime cao). Dù rẻ hơn On-Demand VMs, nhưng vi phạm SLA và tính sẵn sàng, không phù hợp với "survive zonal outage" ổn định. GCP khuyến cáo dùng Spot chỉ cho fault-tolerant workloads (không phải critical apps).

  • [SAI] Deploy the application on Compute Engine instances across multiple regions, and rely on daily snapshots for recovery to achieve the lowest possible cost.
    ❌ Sai vì: Multi-region với daily snapshots chỉ cho recovery time dài (RTO >24h) và RPO cao (mất dữ liệu 1 ngày), không chịu được zonal outage real-time (chỉ backup, không HA tự động). Chi phí lưu trữ snapshot rẻ nhưng không đảm bảo availability cho payment system (downtime quá lớn). Không dùng MIG nên thiếu auto-scaling/healing.

Kết luận 🎯: Giải pháp regional MIG là cân bằng hoàn hảo giữa HA zonal và chi phí thấp, phù hợp best practices GCP 2025-2026! Nếu triển khai, kết hợp với Persistent Disk regional cho storage để tăng tính sẵn sàng.

Câu 318 Chọn nhiều đáp án
Your company is a global financial services provider that processes and analyzes a high volume of credit card transactions in real time for fraud detection. Your analytics team must run complex batch queries on the same transaction data for daily reporting. You need to design a data processing solution that can handle both real-time and batch processing of the transaction data while minimizing operational overhead and infrastructure management. What should you do?
  1. A Use Dataprep to ingest the transactions.
  2. B Use Dataflow to process the streaming data.
  3. C Use a Dataproc cluster for both the streaming and batch workloads.
  4. D Use BigQuery for the batch analytics reports.
  5. E Use Firestore to store and analyze the transaction data.
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 công ty cung cấp dịch vụ tài chính toàn cầu, xử lý và phân tích lượng lớn giao dịch thẻ tín dụng theo thời gian thực (real-time) để phát hiện gian lận (fraud detection). Đồng thời, đội ngũ phân tích cần chạy các truy vấn phức tạp theo lô (batch queries) trên cùng dữ liệu giao dịch để tạo báo cáo hàng ngày. Yêu cầu thiết kế giải pháp xử lý dữ liệu cả streaming (real-time) và batch, đồng thời giảm thiểu overhead vận hành và quản lý hạ tầng (tức là ưu tiên các dịch vụ serverless, managed để tránh tự quản lý cluster hay server).

Mục tiêu chính:

  • Real-time processing: Xử lý streaming data nhanh chóng cho fraud detection.
  • Batch processing: Chạy query phức tạp trên dữ liệu lớn cho báo cáo.
  • Tối ưu hóa: Serverless, scalable, low ops (không cần quản lý infra thủ công).

Giải pháp lý tưởng trên Google Cloud Platform (GCP) là kết hợp Dataflow cho streaming (dựa trên Apache Beam, fully managed) và BigQuery cho batch analytics (data warehouse serverless, hỗ trợ SQL phức tạp). 📘 Tài liệu tham khảo: Google Cloud Dataflow Docs (cập nhật 2024-2026 với Unified Streaming), BigQuery Best Practices.

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

Các đáp án đúng là hai lựa chọn sau, tạo thành giải pháp hoàn chỉnh:

  • Use Dataflow to process the streaming data: Dataflow là dịch vụ Apache Beam managed hoàn toàn trên GCP, lý tưởng cho streaming real-time (hỗ trợ Pub/Sub input, xử lý fraud detection với low latency). Nó serverless, auto-scale, không cần quản lý infra – phù hợp minimize overhead. 🛠️
  • Use BigQuery for the batch analytics reports: BigQuery là data warehouse serverless, chuyên batch queries phức tạp trên petabyte-scale data. Streaming data từ Dataflow có thể sink trực tiếp vào BigQuery, hỗ trợ ML integration cho fraud và báo cáo hàng ngày với SQL chuẩn. Siêu nhanh, chi phí theo query. ✅

Lý do tổng thể: Kết hợp này xử lý cả hai workload (streaming + batch) một cách unified, fully managed, scalable globally – đúng best practice GCP đến 2026.

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

  • ✅ Use Dataflow to process the streaming data
    Đúng: Dataflow xử lý streaming data real-time xuất sắc với pipeline Apache Beam, hỗ trợ windowing, stateful processing cho fraud detection. Nó ingest từ Pub/Sub/ Kafka, auto-scale theo traffic cao của giao dịch thẻ tín dụng, và sink output vào BigQuery hoặc Pub/Sub. Serverless 100%, zero infra management – giảm overhead tối đa. 🏆 (Cập nhật 2026: Hỗ trợ Dataflow Runner v2 cho hiệu suất cao hơn).

  • ❌ Use Dataprep to ingest the transactions
    Sai: Dataprep (nay tích hợp Trifacta) chỉ là tool ETL visual cho data preparation và cleaning, không hỗ trợ ingest streaming real-time với volume cao. Nó batch-oriented, không scalable cho fraud detection thời gian thực, và vẫn cần kết hợp dịch vụ khác – không minimize overhead.

  • ❌ Use a Dataproc cluster for both the streaming and batch workloads
    Sai: Dataproc là Hadoop/Spark cluster managed, có thể chạy cả Spark Streaming và batch, nhưng yêu cầu quản lý cluster (scale, lifecycle, tuning) – vi phạm yêu cầu "minimizing operational overhead". Không serverless như Dataflow/BigQuery, kém hiệu quả cho real-time global fraud.

  • ✅ Use BigQuery for the batch analytics reports
    Đúng: BigQuery chuyên batch analytics với SQL phức tạp trên dữ liệu lớn, hỗ trợ partitioning/clustering cho transaction data, BI tools (Looker), và ML (BigQuery ML cho fraud patterns). Streaming insert từ Dataflow trực tiếp, query hàng ngày siêu nhanh (seconds cho TB data). Serverless, pay-per-use – overhead zero. 🌟 (Cập nhật 2026: BigQuery Omni cho multi-cloud).

  • ❌ Use Firestore to store and analyze the transaction data
    Sai: Firestore là NoSQL document DB cho app mobile/web, hỗ trợ real-time sync nhưng không phù hợp analytics phức tạp (query hạn chế, không SQL full, kém scalable cho PB transaction data). Chi phí cao cho scan lớn, thiếu batch reporting – không thay thế BigQuery/Dataflow. 🚫

Câu 319
Your company uses a custom-built application running on a Compute Engine virtual machine (VM). This application processes real-time sales data and writes it to a zonal Persistent Disk. A recent internal audit requires that you implement a backup and recovery plan to protect against zonal failures. Your company has a strict policy that all backup data must be retained for at least 90 days and stored in a separate project with limited access. You need to implement a fully automated backup solution that meets these requirements with minimal operational overhead. What should you do?
  1. A Write a script to create daily backups of the Persistent Disk. Copy the backups to a different zone and apply a label to each snapshot to indicate the deletion date.
  2. B Use gcloud commands to create snapshots of the Persistent Disk. Store the snapshots in a regional Cloud Storage bucket and configure a lifecycle rule to delete objects older than 90 days.
  3. C Create a snapshot schedule to automatically create Persistent Disk snapshots and use a script to move and store them in a multi-regional Cloud Storage bucket.
  4. D Use the Backup and Disaster Recovery (DR) service to create a backup plan. Configure the backup plan to take daily snapshots and store them in a backup vault with a 90-day retention policy.
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ả một ứng dụng tùy chỉnh chạy trên máy ảo Compute Engine VM của Google Cloud, xử lý dữ liệu bán hàng thời gian thực và ghi vào zonal Persistent Disk. Một cuộc kiểm toán nội bộ yêu cầu triển khai kế hoạch sao lưu và khôi phục để bảo vệ chống lại sự cố zonal (lỗi ở một zone cụ thể). Công ty có chính sách nghiêm ngặt: Tất cả dữ liệu sao lưu phải giữ ít nhất 90 ngày và lưu trữ ở project riêng biệt với quyền truy cập hạn chế. Yêu cầu là giải pháp tự động hoàn toàn (fully automated), chi phí vận hành tối thiểu (minimal operational overhead), và bảo vệ dữ liệu khỏi zonal failures (có lẽ cần sao lưu regional/multi-regional hoặc cross-zone).

🛠️ Yêu cầu chính cần đáp ứng:

  • ✅ Tự động hóa hoàn toàn (không script thủ công).
  • ✅ Giữ dữ liệu ≥90 ngày.
  • ✅ Lưu ở project khác với quyền hạn chế.
  • ✅ Bảo vệ zonal failures (sao lưu ngoài zone).
  • ✅ Minimal overhead (dịch vụ managed, không custom script).

✅ Đáp án đúng:
Use the Backup and Disaster Recovery (DR) service to create a backup plan. Configure the backup plan to take daily snapshots and store them in a backup vault with a 90-day retention policy.

🔍 Lý do chọn đáp án đúng (bằng kiến thức GCP cập nhật đến 2026):
Dịch vụ Google Cloud Backup and DR (dựa trên Actifio, ra mắt 2023 và cập nhật liên tục) là giải pháp managed service hoàn hảo cho yêu cầu này. Nó cho phép:

  • Tạo backup plan tự động daily snapshots của Persistent Disk/VM.
  • Lưu trữ trong backup vault (hỗ trợ cross-project, quyền IAM hạn chế).
  • Retention policy chính xác 90 ngày (tự động xóa sau đó).
  • Bảo vệ zonal failures nhờ sao lưu regional/multi-regional và DR capabilities.
  • Fully automated, không cần script, overhead thấp (serverless).
    Giải pháp này tuân thủ chính sách audit, an toàn dữ liệu, và tích hợp sâu với Compute Engine. (Nguồn: Google Cloud Backup and DR docs - phiên bản 2026 xác nhận hỗ trợ PD snapshots với vault cross-project).

❌ Phân tích tất cả các phương án

  • [SAI] Write a script to create daily backups of the Persistent Disk. Copy the backups to a different zone and apply a label to each snapshot to indicate the deletion date.
    ❌ Sai vì: Phương án dùng script thủ công (cron job hoặc scheduler), không fully automated và tạo operational overhead cao (quản lý script, lỗi script, monitoring). Label không thay thế retention policy tự động; xóa thủ công sau 90 ngày vi phạm chính sách. Không hỗ trợ project riêng biệt dễ dàng, và copy cross-zone vẫn có rủi ro zonal nếu không multi-regional. Không phải giải pháp managed.

  • [SAI] Use gcloud commands to create snapshots of the Persistent Disk. Store the snapshots in a regional Cloud Storage bucket and configure a lifecycle rule to delete objects older than 90 days.
    ❌ Sai vì: Persistent Disk snapshots không lưu trực tiếp vào Cloud Storage bucket (chúng là metadata object của Google, không phải file export). Cần export snapshot thành image rồi upload GCS (phức tạp, không automated). gcloud commands yêu cầu script/automation thủ công, overhead cao. Lifecycle rule chỉ áp dụng object GCS, không phù hợp snapshot. Không đảm bảo project riêng và bảo vệ zonal đầy đủ (regional bucket vẫn zonal risk).

  • [SAI] Create a snapshot schedule to automatically create Persistent Disk snapshots and use a script to move and store them in a multi-regional Cloud Storage bucket.
    ❌ Sai vì: Snapshot schedules (qua Resource Manager) tự động tạo snapshots, nhưng script để move/export sang GCS phá hỏng tính fully automated và tăng overhead (quản lý script export). Snapshots không "move" dễ dàng sang GCS; cần custom workflow. Không hỗ trợ project riêng native, retention chỉ label thủ công (không tự động 90 ngày). Multi-regional GCS tốt hơn nhưng vẫn không managed như Backup and DR.

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

Câu 320
Your employer is a financial services company that recently acquired a popular fintech startup. The startup's core application is a monolithic Python application running on a managed instance group of Compute Engine virtual machines with a single, large PostgreSQL database. Your development team struggles with slow deployment cycles, and the monolithic design of the startup's core application makes it difficult to integrate new. ML-powered fraud detection models. You need a long-term strategy that improves developer agility and positions the company to leverage Google Cloud's advanced data and AI capabilities for future innovations. What should you do?
  1. A Deploy the ML fraud detection model to a Vertex AI endpoint. Create a REST API for the model and modify the monolithic Python application to call this endpoint for real-time fraud analysis.
  2. B Containerize the application, deploy it to Google Kubernetes Engine (GKE), and migrate the PostgreSQL database to Cloud SQL for PostgreSQL.
  3. C Propose a phased, event-driven migration to a microservices architecture. Use Pub/Sub for asynchronous communication and deploy the fraud models on Vertex AI endpoints.
  4. D Migrate the PostgreSQL database to Cloud SQL for PostgreSQL. Replicate the data into BigQuery using Datastream, and then train and deploy the fraud detection models directly within BigQuery using BigQuery ML.
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 một công ty dịch vụ tài chính (financial services) vừa mua lại startup fintech nổi tiếng. Ứng dụng cốt lõi của startup là một monolithic Python application (ứng dụng đơn khối lớn) chạy trên managed instance group (MIG) của Compute Engine (dịch vụ máy ảo trên Google Cloud), kết hợp với một PostgreSQL database lớn duy nhất. Đội ngũ phát triển gặp khó khăn với chu kỳ triển khai chậm (slow deployment cycles) và thiết kế monolithic khiến việc tích hợp các mô hình ML-powered fraud detection (phát hiện gian lận bằng AI/ML) trở nên phức tạp.

Yêu cầu là đề xuất chiến lược dài hạn (long-term strategy) để:

  • ✅ Cải thiện developer agility (tính linh hoạt cho dev).
  • 🚀 Vị thế hóa công ty tận dụng Google Cloud's advanced data và AI capabilities (các tính năng dữ liệu và AI tiên tiến như Vertex AI, Pub/Sub, BigQuery) cho đổi mới tương lai.

Mục tiêu chính là chuyển đổi từ monolithic sang kiến trúc hiện đại, hỗ trợ ML/AI, giảm độ trễ deploy và dễ mở rộng. Đây là câu hỏi kiểu Google Cloud Professional Cloud Architect, tập trung vào migration strategy và best practices cho microservices/event-driven architecture trên GCP (cập nhật đến 2026: Vertex AI vẫn là nền tảng ML chính, Pub/Sub hỗ trợ event-driven với SLA 99.95%, theo docs GCP mới nhất).

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

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

Đáp án đúng: Propose a phased, event-driven migration to a microservices architecture. Use Pub/Sub for asynchronous communication and deploy the fraud models on Vertex AI endpoints.

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

  • Đây là chiến lược dài hạn toàn diện, giải quyết gốc rễ vấn đề monolithic bằng cách phased migration (di chuyển theo giai đoạn, giảm rủi ro downtime).
  • Chuyển sang microservices event-driven với Pub/Sub (dịch vụ messaging asynchronous, hỗ trợ decoupling services, scale độc lập – lý tưởng cho fintech cần real-time fraud detection).
  • Tích hợp Vertex AI endpoints cho ML models, tận dụng GCP AI capabilities (prediction low-latency, auto-scaling, managed serving).
  • Cải thiện developer agility: Deploy độc lập từng microservice (CI/CD nhanh), dễ integrate ML mà không sửa monolithic lớn. Phù hợp GCP best practices 2026 cho hybrid monolithic-to-microservices.

🛠️ 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 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/sai với lý do cụ thể dựa trên yêu cầu câu hỏi (long-term strategy, agility, GCP AI leverage).

  • Phương án A: Deploy the ML fraud detection model to a Vertex AI endpoint. Create a REST API for the model and modify the monolithic Python application to call this endpoint for real-time fraud analysis.
    ❌ Sai vì chỉ giải quyết tích hợp ML tạm thời bằng cách sửa trực tiếp monolithic app (modify the monolithic Python application), không xử lý slow deployment cycles hay monolithic design. Không phải long-term strategy, dễ gây tight coupling và khó scale sau này. Vertex AI tốt nhưng thiếu migration architecture lớn.

  • Phương án B: Containerize the application, deploy it to Google Kubernetes Engine (GKE), and migrate the PostgreSQL database to Cloud SQL for PostgreSQL.
    ❌ Sai vì chỉ là lift-and-shift cơ bản (containerize + GKE + Cloud SQL), cải thiện deploy chút ít (qua Kubernetes) nhưng không giải quyết monolithic (vẫn single app lớn, khó integrate ML). Không leverage AI/data advanced (không đề cập Pub/Sub/Vertex AI), không phải phased/long-term cho agility cao.

  • Phương án C (Đúng): Propose a phased, event-driven migration to a microservices architecture. Use Pub/Sub for asynchronous communication and deploy the fraud models on Vertex AI endpoints.
    ✅ Đúng như đã giải thích ở trên. Toàn diện nhất: Phased migration giảm rủi ro, event-driven (Pub/Sub) decoupling services, Vertex AI cho ML fraud (real-time, scalable). Hoàn hảo cho fintech, cải thiện agility (deploy microservices độc lập) và future-proof với GCP AI/ML.

  • Phương án D: Migrate the PostgreSQL database to Cloud SQL for PostgreSQL. Replicate the data into BigQuery using Datastream, and then train and deploy the fraud detection models directly within BigQuery using BigQuery ML.
    ❌ Sai vì tập trung database-centric (Cloud SQL + Datastream + BigQuery ML), tốt cho analytics/batch ML nhưng không giải quyết monolithic app hay slow deploys. BigQuery ML phù hợp batch fraud (không real-time tốt như Vertex AI), thiếu microservices/event-driven. Không phải long-term agility cho dev team.

Kết luận 🎯: Phương án C là lựa chọn tối ưu, phù hợp Google Cloud Well-Architected Framework (Reliability, Performance Efficiency pillars). Khuyến nghị implement với Strangler Fig Pattern cho phased migration!