Ngân hàng đề — Google Cloud Professional Cloud Developer
Tìm thấy 358 câu.
This is a case study. Case studies are not timed separately. You can use as much exam time as you would like to complete each case. However, there may be additional case studies and sections on this exam. You must manage your time to ensure that you are able to complete all questions included on this exam in the time provided.
To answer the questions included in a case study, you will need to reference information that is provided in the case study. Case studies might contain exhibits and other resources that provide more information about the scenario that is described in the case study. Each question is independent of the other questions in this case study.
At the end of this case study, a review screen will appear. This screen allows you to review your answers and to make changes before you move to the next section of the exam. After you begin a new section, you cannot return to this section.
To start the case study -
To display the first question in this case study, click the Next button. Use the buttons in the left pane to explore the content of the case study before you answer the questions. Clicking these buttons displays information such as business requirements, existing environment, and problem statements. If the case study has an
All Information tab, note that the information displayed is identical to the information displayed on the subsequent tabs. When you are ready to answer a question, click the Question button to return to the question.
Company Overview -
HipLocal is a community application designed to facilitate communication between people in close proximity. It is used for event planning and organizing sporting events, and for businesses to connect with their local communities. HipLocal launched recently in a few neighborhoods in Dallas and is rapidly growing into a global phenomenon. Its unique style of hyper-local community communication and business outreach is in demand around the world.
Executive Statement -
We are the number one local community app; it's time to take our local community services global. Our venture capital investors want to see rapid growth and the same great experience for new local and virtual communities that come online, whether their members are 10 or 10000 miles away from each other.
Solution Concept -
HipLocal wants to expand their existing service, with updated functionality, in new regions to better serve their global customers. They want to hire and train a new team to support these regions in their time zones. They will need to ensure that the application scales smoothly and provides clear uptime data.
Existing Technical Environment -
HipLocal's environment is a mix of on-premises hardware and infrastructure running in Google Cloud Platform. The HipLocal team understands their application well, but has limited experience in global scale applications. Their existing technical environment is as follows:
* Existing APIs run on Compute Engine virtual machine instances hosted in GCP.
* State is stored in a single instance MySQL database in GCP.
* Data is exported to an on-premises Teradata/Vertica data warehouse.
* Data analytics is performed in an on-premises Hadoop environment.
* The application has no logging.
* There are basic indicators of uptime; alerts are frequently fired when the APIs are unresponsive.
Business Requirements -
HipLocal's investors want to expand their footprint and support the increase in demand they are seeing. Their requirements are:
* Expand availability of the application to new regions.
* Increase the number of concurrent users that can be supported.
* Ensure a consistent experience for users when they travel to different regions.
* Obtain user activity metrics to better understand how to monetize their product.
* Ensure compliance with regulations in the new regions (for example, GDPR).
* Reduce infrastructure management time and cost.
* Adopt the Google-recommended practices for cloud computing.
Technical Requirements -
* The application and backend must provide usage metrics and monitoring.
* APIs require strong authentication and authorization.
* Logging must be increased, and data should be stored in a cloud analytics platform.
* Move to serverless architecture to facilitate elastic scaling.
* Provide authorized access to internal apps in a secure manner.
HipLocal is configuring their access controls.
Which firewall configuration should they implement?
- A Block all traffic on port 443.
- B Allow all traffic into the network.
- C Allow traffic on port 443 for a specific tag.
- D Allow all traffic on port 443 into the network.
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 phần case study của kỳ thi chứng chỉ Google Cloud (không phải AWS như mô tả ban đầu, mà là Google Cloud Platform - GCP), mô tả tình huống thực tế về công ty HipLocal – một ứng dụng cộng đồng hyper-local đang mở rộng toàn cầu. HipLocal hiện chạy trên môi trường hỗn hợp: phần lớn trên GCP (Compute Engine cho APIs, MySQL single instance), kết hợp on-premises (Teradata/Vertica, Hadoop).
Bối cảnh chính:
- Mục tiêu kinh doanh: Mở rộng quy mô toàn cầu, hỗ trợ nhiều user đồng thời, trải nghiệm nhất quán giữa các vùng, thu thập metrics user activity, tuân thủ quy định (như GDPR), giảm chi phí quản lý hạ tầng, áp dụng best practices của Google Cloud.
- Yêu cầu kỹ thuật: Cung cấp metrics/monitoring, authentication/authorization mạnh cho APIs, tăng logging và lưu vào cloud analytics, chuyển sang serverless để scale elastic, truy cập an toàn vào internal apps.
- Vấn đề cụ thể: HipLocal đang cấu hình access controls (kiểm soát truy cập), và câu hỏi tập trung vào firewall configuration trong GCP VPC (Virtual Private Cloud). Firewall rules ở GCP dùng để kiểm soát traffic vào/ra instances (như Compute Engine VMs chạy APIs), thường dựa trên IP ranges, ports, và network tags để đảm bảo bảo mật mà vẫn cho phép traffic cần thiết (ví dụ: port 443 cho HTTPS APIs).
Câu hỏi yêu cầu chọn cấu hình firewall tối ưu để cân bằng giữa bảo mật (không mở rộng quá mức, tránh rủi ro) và chức năng (cho phép APIs hoạt động với authentication mạnh, scale global). Theo best practices GCP (cập nhật đến 2026), firewall rules nên least privilege (chỉ allow traffic cần thiết), sử dụng tags để apply rules cụ thể trên instances, tránh allow all traffic để giảm surface tấn công. 📘 Nguồn tham khảo: GCP VPC Firewall Rules (phiên bản mới nhất 2026 nhấn mạnh hierarchical firewall policies và tags cho micro-segmentation).
✅ Đáp án đúng và lý do lựa chọn
Đáp án đúng: Allow traffic on port 443 for a specific tag.
Lý do 🛠️:
- Port 443 là chuẩn cho HTTPS (secure APIs của HipLocal), cần allow để users truy cập ứng dụng toàn cầu mà không block traffic hợp lệ.
- Sử dụng specific tag (network tags trên Compute Engine instances) cho phép apply rule chính xác chỉ trên các VMs cần thiết (ví dụ: tag "web-server" cho API servers), tuân thủ principle of least privilege – giảm rủi ro tấn công từ traffic không mong muốn.
- Phù hợp technical requirements: Hỗ trợ strong auth/authz (HTTPS + tags), scale elastic, monitoring/uptime. Khi mở rộng regions (multi-region), tags giúp quản lý firewall dễ dàng qua IAM và Cloud Monitoring.
- Best practice GCP: Default deny-all + explicit allow với tags/protocols/ports, tránh open-all. Điều này giúp giảm infrastructure management time/cost và đảm bảo compliance (GDPR yêu cầu secure access). ✅ Hoàn hảo cho case study HipLocal!
📋 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. Tôi giữ nguyên văn bản gốc tiếng Anh của phương án, chỉ giải thích bằng tiếng Việt với emoji để dễ theo dõi:
-
Block all traffic on port 443.
❌ Sai hoàn toàn. Việc block toàn bộ port 443 sẽ ngăn chặn tất cả HTTPS traffic vào APIs, khiến ứng dụng HipLocal không thể truy cập được từ users (bao gồm global expansion). Điều này vi phạm business requirements (expand availability, concurrent users) và technical (APIs cần auth mạnh nhưng phải accessible). Không có lý do nào block port chính của web/app. 🛑 Rủi ro: App downtime 100%! -
Allow all traffic into the network.
❌ Sai và nguy hiểm. Allow toàn bộ traffic (bất kỳ port/protocol/IP nào) vào VPC network là vi phạm bảo mật cơ bản (zero-trust model của GCP). HipLocal cần strong auth cho APIs, compliance GDPR – open-all tạo lỗ hổng tấn công DDoS/exploit. Không scale an toàn, tăng management cost. GCP khuyên dùng default deny + specific rules. 🚫 Không bao giờ dùng trong production! -
Allow traffic on port 443 for a specific tag.
✅ Đúng (như đã giải thích ở trên). Đây là cấu hình tối ưu, secure và scalable. Tags cho phép granular control (ví dụ: chỉ VMs có tag "api-prod" nhận traffic 443 từ anywhere hoặc specific CIDR). Hỗ trợ multi-region, monitoring qua Cloud Logging/Monitoring. Best practice từ GCP docs! 🎯 Lý tưởng cho HipLocal. -
Allow all traffic on port 443 into the network.
❌ Sai vì quá rộng. Allow toàn bộ traffic port 443 (không restrict source IP hay tags) vẫn mở cửa cho tấn công brute-force/scan từ internet, dù chỉ HTTPS. HipLocal cần authorized access (strong authz), không phải open-broadcast. Vi phạm least privilege, tăng rủi ro ở scale global. Nên dùng tags/IP allowlists thay thế. ⚠️ Tốt hơn block nhưng vẫn kém an toàn.
Kết luận 🌟: Lựa chọn đúng giúp HipLocal scale global an toàn, giảm chi phí, theo Google-recommended practices. Nếu thi thật, hãy kiểm tra Firewall rules trong GCP Console để visualize! 📘 Tài liệu bổ sung: GCP Best Practices for VPC Design & Compute Engine Tags.
This is a case study. Case studies are not timed separately. You can use as much exam time as you would like to complete each case. However, there may be additional case studies and sections on this exam. You must manage your time to ensure that you are able to complete all questions included on this exam in the time provided.
To answer the questions included in a case study, you will need to reference information that is provided in the case study. Case studies might contain exhibits and other resources that provide more information about the scenario that is described in the case study. Each question is independent of the other questions in this case study.
At the end of this case study, a review screen will appear. This screen allows you to review your answers and to make changes before you move to the next section of the exam. After you begin a new section, you cannot return to this section.
To start the case study -
To display the first question in this case study, click the Next button. Use the buttons in the left pane to explore the content of the case study before you answer the questions. Clicking these buttons displays information such as business requirements, existing environment, and problem statements. If the case study has an
All Information tab, note that the information displayed is identical to the information displayed on the subsequent tabs. When you are ready to answer a question, click the Question button to return to the question.
Company Overview -
HipLocal is a community application designed to facilitate communication between people in close proximity. It is used for event planning and organizing sporting events, and for businesses to connect with their local communities. HipLocal launched recently in a few neighborhoods in Dallas and is rapidly growing into a global phenomenon. Its unique style of hyper-local community communication and business outreach is in demand around the world.
Executive Statement -
We are the number one local community app; it's time to take our local community services global. Our venture capital investors want to see rapid growth and the same great experience for new local and virtual communities that come online, whether their members are 10 or 10000 miles away from each other.
Solution Concept -
HipLocal wants to expand their existing service, with updated functionality, in new regions to better serve their global customers. They want to hire and train a new team to support these regions in their time zones. They will need to ensure that the application scales smoothly and provides clear uptime data.
Existing Technical Environment -
HipLocal's environment is a mix of on-premises hardware and infrastructure running in Google Cloud Platform. The HipLocal team understands their application well, but has limited experience in global scale applications. Their existing technical environment is as follows:
* Existing APIs run on Compute Engine virtual machine instances hosted in GCP.
* State is stored in a single instance MySQL database in GCP.
* Data is exported to an on-premises Teradata/Vertica data warehouse.
* Data analytics is performed in an on-premises Hadoop environment.
* The application has no logging.
* There are basic indicators of uptime; alerts are frequently fired when the APIs are unresponsive.
Business Requirements -
HipLocal's investors want to expand their footprint and support the increase in demand they are seeing. Their requirements are:
* Expand availability of the application to new regions.
* Increase the number of concurrent users that can be supported.
* Ensure a consistent experience for users when they travel to different regions.
* Obtain user activity metrics to better understand how to monetize their product.
* Ensure compliance with regulations in the new regions (for example, GDPR).
* Reduce infrastructure management time and cost.
* Adopt the Google-recommended practices for cloud computing.
Technical Requirements -
* The application and backend must provide usage metrics and monitoring.
* APIs require strong authentication and authorization.
* Logging must be increased, and data should be stored in a cloud analytics platform.
* Move to serverless architecture to facilitate elastic scaling.
* Provide authorized access to internal apps in a secure manner.
HipLocal's data science team wants to analyze user reviews.
How should they prepare the data?
- A Use the Cloud Data Loss Prevention API for redaction of the review dataset.
- B Use the Cloud Data Loss Prevention API for de-identification of the review dataset.
- C Use the Cloud Natural Language Processing API for redaction of the review dataset.
- D Use the Cloud Natural Language Processing API for de-identification of the review dataset.
Xem giải thích
🧩 Phân tích nội dung câu hỏi
Câu hỏi cụ thể: Trong case study của HipLocal – một ứng dụng cộng đồng hyper-local đang mở rộng toàn cầu trên Google Cloud Platform (GCP) – đội ngũ data science muốn phân tích dữ liệu user reviews (đánh giá từ người dùng). Câu hỏi yêu cầu: "How should they prepare the data?" (Làm thế nào để chuẩn bị dữ liệu?).
Bối cảnh chi tiết:
- HipLocal có yêu cầu kinh doanh và kỹ thuật như mở rộng khu vực, đảm bảo tuân thủ quy định (ví dụ GDPR), thu thập metrics người dùng, và di chuyển sang serverless.
- Dữ liệu user reviews chứa thông tin nhạy cảm (PII - Personally Identifiable Information) từ đánh giá người dùng, cần được xử lý an toàn trước khi phân tích để tránh vi phạm quyền riêng tư.
- Mục tiêu: Chuẩn bị dữ liệu cho phân tích mà vẫn bảo mật, phù hợp với Technical Requirements (logging, monitoring, compliance) và Business Requirements (tuân thủ GDPR ở vùng mới).
- Đây là câu hỏi độc lập trong case study, tập trung vào công cụ GCP để de-identification hoặc redaction dữ liệu reviews trước khi đưa vào phân tích (như BigQuery hoặc Dataflow).
Mục đích câu hỏi: Kiểm tra kiến thức về bảo mật dữ liệu trên GCP, đặc biệt phân biệt Cloud DLP API (chuyên de-identification/redaction PII) và Cloud Natural Language API (chuyên phân tích ngôn ngữ tự nhiên, không phải bảo mật dữ liệu). Kiến thức cập nhật đến 2026: GCP DLP v2+ hỗ trợ de-identification tự động với ML để detect PII (email, phone, name), tích hợp serverless.
✅ Đáp án đúng và lý do lựa chọn
Đáp án đúng: Use the Cloud Data Loss Prevention API for de-identification of the review dataset.
Lý do chi tiết:
🛠️ Cloud Data Loss Prevention (DLP) API là công cụ chuyên dụng của GCP để bảo vệ dữ liệu nhạy cảm, hỗ trợ de-identification (ẩn danh hóa) bằng cách detect và transform PII (như thay thế tên/email bằng token, mask số điện thoại) mà KHÔNG xóa dữ liệu. Điều này lý tưởng cho user reviews vì:
- Giữ nguyên dữ liệu để phân tích sentiment/insights (data science team cần).
- Tuân thủ GDPR (pseudonymization được coi là de-identification).
- Tích hợp dễ dàng với BigQuery/Dataflow cho pipeline serverless.
- Phù hợp Google-recommended practices cho compliance và elastic scaling.
❌ Không dùng redaction (xóa hoàn toàn) vì sẽ mất dữ liệu cần thiết cho phân tích. Cloud Natural Language API không xử lý PII protection.
📋 Giải thích tất cả các phương án (đúng/sai)
Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá ✅ (đúng) hoặc ❌ (sai), với lý do bằng tiếng Việt:
-
Use the Cloud Data Loss Prevention API for redaction of the review dataset.
❌ Sai. Cloud DLP API hỗ trợ redaction (xóa PII hoàn toàn), nhưng không phù hợp vì xóa dữ liệu sẽ làm mất thông tin cần thiết cho phân tích user reviews (data science team cần giữ context để monetize). De-identification tốt hơn để pseudonymize mà vẫn analyze được. -
Use the Cloud Data Loss Prevention API for de-identification of the review dataset.
✅ Đúng. Như giải thích trên, DLP API detect >100 loại PII tự động (infoTypes), transform bằng methods như REPLACE/MASK, lý tưởng cho reviews chứa tên/địa chỉ. Hỗ trợ batch processing serverless, tích hợp Compliance Controls đến 2026. -
Use the Cloud Natural Language Processing API for redaction of the review dataset.
❌ Sai. Cloud Natural Language (NLP) API chuyên phân tích syntax/sentiment/entity recognition (như extract tên từ reviews), KHÔNG hỗ trợ redaction/de-identification PII. Dùng NLP trước DLP có thể, nhưng không thay thế DLP cho bảo mật. -
Use the Cloud Natural Language Processing API for de-identification of the review dataset.
❌ Sai. NLP API không có tính năng de-identification/redaction; nó chỉ phân tích ngôn ngữ (entities như PERSON/LOCATION). Sử dụng sai sẽ không bảo vệ PII, vi phạm GDPR và technical req về secure access.
📘 Tài liệu tham khảo (cập nhật GCP 2026)
- Cloud DLP API Docs: Google Cloud DLP Overview – Chi tiết de-identification methods (Risk Analysis, Inspect & Transform).
- DLP vs NLP Comparison: DLP Best Practices – Khuyến nghị dùng DLP cho PII trước analytics.
- Case Study Context: HipLocal sample từ Google Cloud Professional Cloud Developer exam (certification guide 2024-2026).
- GDPR Integration: GCP Compliance – DLP hỗ trợ pseudonymization cho EU regs.
Hy vọng phân tích này giúp bạn ôn thi hiệu quả! 🚀 Nếu cần thêm case study khác, hãy hỏi nhé!
This is a case study. Case studies are not timed separately. You can use as much exam time as you would like to complete each case. However, there may be additional case studies and sections on this exam. You must manage your time to ensure that you are able to complete all questions included on this exam in the time provided.
To answer the questions included in a case study, you will need to reference information that is provided in the case study. Case studies might contain exhibits and other resources that provide more information about the scenario that is described in the case study. Each question is independent of the other questions in this case study.
At the end of this case study, a review screen will appear. This screen allows you to review your answers and to make changes before you move to the next section of the exam. After you begin a new section, you cannot return to this section.
To start the case study -
To display the first question in this case study, click the Next button. Use the buttons in the left pane to explore the content of the case study before you answer the questions. Clicking these buttons displays information such as business requirements, existing environment, and problem statements. If the case study has an
All Information tab, note that the information displayed is identical to the information displayed on the subsequent tabs. When you are ready to answer a question, click the Question button to return to the question.
Company Overview -
HipLocal is a community application designed to facilitate communication between people in close proximity. It is used for event planning and organizing sporting events, and for businesses to connect with their local communities. HipLocal launched recently in a few neighborhoods in Dallas and is rapidly growing into a global phenomenon. Its unique style of hyper-local community communication and business outreach is in demand around the world.
Executive Statement -
We are the number one local community app; it's time to take our local community services global. Our venture capital investors want to see rapid growth and the same great experience for new local and virtual communities that come online, whether their members are 10 or 10000 miles away from each other.
Solution Concept -
HipLocal wants to expand their existing service, with updated functionality, in new regions to better serve their global customers. They want to hire and train a new team to support these regions in their time zones. They will need to ensure that the application scales smoothly and provides clear uptime data.
Existing Technical Environment -
HipLocal's environment is a mix of on-premises hardware and infrastructure running in Google Cloud Platform. The HipLocal team understands their application well, but has limited experience in global scale applications. Their existing technical environment is as follows:
* Existing APIs run on Compute Engine virtual machine instances hosted in GCP.
* State is stored in a single instance MySQL database in GCP.
* Data is exported to an on-premises Teradata/Vertica data warehouse.
* Data analytics is performed in an on-premises Hadoop environment.
* The application has no logging.
* There are basic indicators of uptime; alerts are frequently fired when the APIs are unresponsive.
Business Requirements -
HipLocal's investors want to expand their footprint and support the increase in demand they are seeing. Their requirements are:
* Expand availability of the application to new regions.
* Increase the number of concurrent users that can be supported.
* Ensure a consistent experience for users when they travel to different regions.
* Obtain user activity metrics to better understand how to monetize their product.
* Ensure compliance with regulations in the new regions (for example, GDPR).
* Reduce infrastructure management time and cost.
* Adopt the Google-recommended practices for cloud computing.
Technical Requirements -
* The application and backend must provide usage metrics and monitoring.
* APIs require strong authentication and authorization.
* Logging must be increased, and data should be stored in a cloud analytics platform.
* Move to serverless architecture to facilitate elastic scaling.
* Provide authorized access to internal apps in a secure manner.
In order for HipLocal to store application state and meet their stated business requirements, which database service should they migrate to?
- A Cloud Spanner
- B Cloud Datastore
- C Cloud Memorystore as a cache
- D Separate Cloud SQL clusters for each region
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 phần case study của kỳ thi chứng chỉ Google Cloud (cụ thể là Professional Cloud Developer hoặc tương tự), mô tả tình huống thực tế về công ty HipLocal – một ứng dụng cộng đồng hyper-local đang mở rộng toàn cầu.
-
Tổng quan case study: HipLocal hiện chạy trên Google Cloud Platform (GCP) với môi trường hỗn hợp (on-premises và GCP). API chạy trên Compute Engine VM, trạng thái ứng dụng (application state) lưu trên single instance MySQL ở GCP (không hỗ trợ scale global). Không có logging đầy đủ, chỉ có chỉ số uptime cơ bản. Họ muốn mở rộng sang các vùng mới, hỗ trợ concurrent users cao hơn, trải nghiệm nhất quán (consistent experience) khi user di chuyển giữa các vùng, thu thập metrics, tuân thủ quy định (như GDPR), giảm chi phí quản lý hạ tầng, và áp dụng best practices của Google Cloud (serverless, elastic scaling).
-
Yêu cầu kinh doanh chính 📈: Mở rộng availability sang vùng mới, tăng concurrent users, consistent experience跨 vùng, metrics user activity, compliance, giảm management time/cost.
-
Yêu cầu kỹ thuật chính 🛠️: Usage metrics/monitoring, strong authz, tăng logging vào cloud analytics, move to serverless, elastic scaling, secure access nội bộ.
-
Câu hỏi cụ thể: Để lưu trữ application state (trạng thái ứng dụng, như dữ liệu MySQL hiện tại) và đáp ứng đầy đủ business requirements, họ nên migrate sang database service nào?
Câu hỏi tập trung vào việc chọn DB global-scale, strongly consistent, relational (vì MySQL là relational), serverless, low management, phù hợp mở rộng multi-region mà không mất tính nhất quán.
✅ Đáp án đúng: Cloud Spanner
Lý do lựa chọn 🏆:
Cloud Spanner là lựa chọn lý tưởng vì nó đáp ứng toàn bộ yêu cầu global scale và consistent experience.
- Globally distributed & strongly consistent: Hỗ trợ multi-region replication tự động, đảm bảo dữ liệu nhất quán mạnh (strong consistency) ngay cả khi user di chuyển giữa các vùng (ví dụ: Dallas sang châu Âu), phù hợp với "consistent experience for users when they travel to different regions" và compliance GDPR (dữ liệu replicate cross-region an toàn).
- Relational & scale: Hỗ trợ SQL chuẩn (dễ migrate từ MySQL), horizontal scaling tự động đến hàng triệu QPS, elastic scaling serverless (không quản lý server).
- Giảm management: Fully managed, tích hợp monitoring/metrics (Cloud Monitoring), logging vào Cloud Logging/BigQuery, phù hợp "reduce infrastructure management time and cost" và "adopt Google-recommended practices".
- Phù hợp application state: Lưu state relational như MySQL, hỗ trợ transaction ACID global. Đến năm 2026, Spanner vẫn là gold standard cho global OLTP (theo GCP updates, hỗ trợ Spanner AutoScaling và Regional Configurations mới).
📘 Tài liệu tham khảo:
- Cloud Spanner Documentation (Google Cloud, cập nhật 2024-2026).
- Migrate to Spanner from MySQL.
- AWS? (Lưu ý: Case study là GCP, không AWS; có thể nhầm lẫn, nhưng Spanner tương đương Amazon Aurora Global Database).
🔍 Giải thích tất cả các phương án
-
Cloud Spanner ✅ Đúng: Như phân tích trên, nó cung cấp global strong consistency, relational SQL, serverless scaling, multi-region replication tự động, metrics/logging tích hợp, giảm management hoàn hảo cho global expansion và consistent experience. Migrate từ MySQL dễ dàng với schema tương thích.
-
Cloud Datastore ❌ Sai: Đây là NoSQL document DB (Firestore trước đây), eventually consistent (không strong consistency), không phù hợp application state relational từ MySQL. Không đảm bảo "consistent experience" cross-region realtime, và khó monetize metrics phức tạp. Phù hợp app NoSQL scale cao nhưng không match relational state hoặc strong consistency yêu cầu.
-
Cloud Memorystore as a cache ❌ Sai: Memorystore (Redis/Memcached) chỉ là in-memory cache tạm thời, không lưu persistent state (dữ liệu mất khi restart). Không thay thế DB cho application state, chỉ dùng làm cache bổ sung. Không scale global consistent, không relational, và tăng management thay vì serverless chính.
-
Separate Cloud SQL clusters for each region ❌ Sai: Cloud SQL (MySQL/Postgres managed) hỗ trợ multi-region read replicas, nhưng không strong consistency tự động giữa clusters (cần app-level sync phức tạp, latency cao). Tăng management (quản lý nhiều clusters), chi phí cao, không elastic serverless thực sự, vi phạm "reduce infrastructure management" và "consistent experience" seamless. Không Google-recommended cho global state.
💡 Lời khuyên: Chọn Spanner giúp HipLocal đạt 99.999% uptime global, tích hợp IAM cho authz, và export metrics vào BigQuery cho analytics! 🚀
Which deployment strategy should you use?
- A Blue/green deployment
- B Canary deployment
- C Rolling deployment
- D Recreate deployment
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 tập trung vào chiến lược triển khai (deployment strategy) trong môi trường sản xuất (production) trên AWS. Cụ thể:
- Ứng dụng đang chạy phiên bản hiện tại.
- Khi triển khai phiên bản mới, cần chuyển toàn bộ lưu lượng truy cập sản xuất (all production traffic) sang phiên bản mới.
- Đồng thời, giữ nguyên phiên bản cũ để có thể quay lại (revert) nếu phiên bản mới gặp vấn đề.
Mục tiêu chính là zero-downtime deployment với khả năng rollback nhanh chóng, đảm bảo tính sẵn sàng cao (high availability). Đây là kịch bản phổ biến trên các dịch vụ AWS như Amazon ECS, EKS, Elastic Beanstalk, hoặc CodeDeploy (cập nhật đến năm 2026, AWS tiếp tục hỗ trợ các strategy này với cải tiến như integration với AWS App Runner và Lambda).
📘 Tài liệu tham khảo:
- AWS Documentation: Deployment types in CodeDeploy (Blue/Green).
- AWS Well-Architected Framework: Deployment Strategies.
✅ Đáp án đúng: Blue/green deployment
Lý do chọn đáp án này 🛠️:
Chiến lược Blue/green hoàn hảo phù hợp vì:
- Blue là môi trường cũ (production hiện tại).
- Green là môi trường mới (triển khai song song, không ảnh hưởng traffic cũ).
- Khi green sẵn sàng, chuyển toàn bộ traffic sang green (sử dụng Elastic Load Balancing - ELB hoặc Route 53).
- Nếu có vấn đề, rollback ngay lập tức bằng cách switch traffic về blue (chỉ mất vài giây).
- Không có downtime, giữ nguyên phiên bản cũ để revert. Đây là strategy được AWS khuyến nghị cho production critical apps (cập nhật 2026: hỗ trợ tự động hóa qua AWS Proton và CodeDeploy Blue/Green hooks).
🔍 Giải thích tất cả các phương án
-
✅ Blue/green deployment
Đúng vì triển khai hai môi trường song song, route toàn bộ traffic sang new version khi ready, và giữ old version để revert dễ dàng. Lý tưởng cho zero-downtime và rollback nhanh (AWS CodeDeploy hỗ trợ native). -
❌ Canary deployment
Sai vì chỉ route một phần nhỏ traffic (ví dụ 5-10%) sang new version để test dần dần, không chuyển toàn bộ traffic ngay. Phù hợp testing rủi ro thấp, nhưng không match yêu cầu "all production traffic" và rollback phức tạp hơn (AWS hỗ trợ qua CodeDeploy hoặc ALB traffic shifting). -
❌ Rolling deployment
Sai vì cập nhật dần dần từng instance (replace old bằng new theo batch), có thể gây disruption nhẹ và không giữ full old version để revert toàn bộ. Traffic vẫn mixed, không đảm bảo "all traffic to new" sạch sẽ (mặc định trong ECS/ASG, cập nhật 2026: improved với min healthy percent). -
❌ Recreate deployment
Sai vì shutdown toàn bộ old version rồi deploy new (all-or-nothing), gây downtime và không giữ previous version để revert. Chỉ phù hợp non-critical apps (Kubernetes/EKS strategy, không khuyến nghị production AWS).
🧠 Lưu ý bổ sung: Trong AWS 2026, Blue/Green được ưu tiên với AWS Lambda (via Aliases/Versions) và AppConfig cho feature flags, giúp scale toàn cầu mà không lo revert. Nếu dùng ECS, config task definition với blue/green qua CodeDeploy!
Kubernetes Engine. You need to determine how to containerize the application. Your approach should follow Google-recommended best practices for availability.
What should you do?
- A Package each component in a separate container. Implement readiness and liveness probes.
- B Package the application in a single container. Use a process management tool to manage each component.
- C Package each component in a separate container. Use a script to orchestrate the launch of the components.
- D Package the application in a single container. Use a bash script as an entrypoint to the container, and then spawn each component as a background job.
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 di chuyển (porting) một ứng dụng stack Apache/MySQL/PHP từ một máy đơn lẻ sang Google Kubernetes Engine (GKE). Nhiệm vụ chính là container hóa ứng dụng theo các best practices được Google khuyến nghị, đặc biệt nhấn mạnh vào tính sẵn sàng (availability).
- Bối cảnh: Ứng dụng gốc chạy trên một máy duy nhất với nhiều thành phần (Apache cho web server, MySQL cho database, PHP cho logic ứng dụng). Khi chuyển sang GKE (một nền tảng Kubernetes managed trên Google Cloud), cần container hóa để tận dụng lợi ích của container orchestration như scaling, self-healing, và high availability.
- Yêu cầu cốt lõi: Theo best practices của Google (cập nhật đến 2026), container hóa phải đảm bảo mỗi container chỉ chạy một process chính (one process per container), dễ dàng scale độc lập từng thành phần, và sử dụng readiness/liveness probes để Kubernetes kiểm tra sức khỏe pod, tự động restart nếu lỗi, từ đó tăng availability.
- Mục tiêu: Tránh các cách làm cũ kỹ như multi-process trong single container, vì chúng làm phức tạp việc quản lý lifecycle, logging, và scaling trong Kubernetes.
📘 Tài liệu tham khảo:
- Google Cloud GKE Best Practices: Containerizing Applications (cập nhật 2025).
- GKE Probes Documentation (readiness/liveness probes cho availability).
✅ Đáp án đúng
Package each component in a separate container. Implement readiness and liveness probes.
Lý do lựa chọn:
- 🛠️ Đây là best practice chuẩn của Google cho GKE: Tách riêng từng thành phần (Apache, MySQL, PHP) vào container riêng để Kubernetes có thể scale, deploy, và manage độc lập (ví dụ: scale web pods mà không ảnh hưởng DB).
- 📡 Readiness probe kiểm tra pod sẵn sàng nhận traffic (trả về HTTP 200 từ Apache), liveness probe kiểm tra pod còn sống (restart nếu crash). Điều này đảm bảo high availability qua self-healing tự động.
- ✅ Phù hợp với nguyên tắc "one process per container" (PID 1 là process duy nhất), dễ debug, logging (stdout/stderr), và tuân thủ CNCF/Kubernetes standards đến 2026.
📋 Giải thích tất cả các phương án
-
✅ Package each component in a separate container. Implement readiness and liveness probes.
🟢 Đúng: Như đã giải thích, cách này tối ưu cho GKE, hỗ trợ horizontal scaling (HPA), rolling updates an toàn, và probes đảm bảo 99.9%+ availability. Không có multi-process nên tránh signal handling issues (SIGTERM). -
❌ Package the application in a single container. Use a process management tool to manage each component.
🔴 Sai: Single container chạy multi-process (Apache + MySQL + PHP) vi phạm "one process per container". Process manager (như supervisord) khó config probes chính xác cho từng process, dẫn đến pod không self-heal đúng, scaling kém, và logging rối loạn. Google khuyến cáo tránh vì giảm availability. -
❌ Package each component in a separate container. Use a script to orchestrate the launch of the components.
🔴 Sai: Tách container tốt nhưng dùng script orchestrate launch (như init script) không thay thế probes. Script chỉ khởi động, không monitor runtime health, nên Kubernetes không detect crash kịp thời, làm giảm availability. Best practice yêu cầu probes thay vì script thủ công. -
❌ Package the application in a single container. Use a bash script as an entrypoint to the container, and then spawn each component as a background job.
🔴 Sai: Single container với bash script spawn background jobs (Apache &bg, MySQL &bg) là anti-pattern. Bash không handle signals tốt (SIGKILL mất dữ liệu), probes không target process cụ thể, logging kém, và không scale được từng component. Google cấm cách này từ GKE 1.20+ (2021) vì ảnh hưởng reliability.
🧠 Kết luận: Chọn đáp án đúng giúp ứng dụng đạt multi-zone HA trên GKE với Deployment/StatefulSet, kết hợp Service discovery (ClusterIP cho MySQL). Test bằng kubectl apply và monitor qua Cloud Monitoring!
- A When creating your instances, configure a startup script using the gcloud command to determine the project name that indicates the correct environment.
- B In each project, configure a metadata key ג€environmentג€ whose value is the environment it serves. Use your deployment tool to query the instance metadata and configure the application based on the ג€environmentג€ value.
- C Deploy your chosen deployment tool on an instance in each project. Use a deployment job to retrieve the appropriate configuration file from your version control system, and apply the configuration when deploying the application on each instance.
- D During each instance launch, configure an instance custom-metadata key named ג€environmentג€ whose value is the environment the instance serves. Use your deployment tool to query the instance metadata, and configure the application based on the ג€environmentג€ value.
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 triển khai ứng dụng trên Compute Engine instances thuộc nhiều project riêng biệt trên Google Cloud Platform (GCP), tương ứng với các môi trường phát triển: development (dev), QA, staging, và production (prod).
- Ứng dụng code giống nhau trên tất cả instances, nhưng cấu hình (configuration) khác nhau tùy môi trường.
- Mục tiêu: Trong quá trình deployment, mỗi instance tự động nhận config phù hợp với môi trường của project mà nó thuộc về, đồng thời giảm thiểu số bước cấu hình (minimize the number of steps).
- Bối cảnh chính: Sử dụng instance metadata (dữ liệu metadata của instance) để query thông tin môi trường một cách tự động, không cần can thiệp thủ công nhiều.
✅ Đây là câu hỏi kiểm tra kiến thức về project metadata và instance metadata trong GCP Compute Engine (cập nhật đến 2026, không thay đổi lớn từ phiên bản hiện tại).
✅ Đáp án đúng và lý do lựa chọn
Đáp án đúng:
In each project, configure a metadata key ג€environmentג€ whose value is the environment it serves. Use your deployment tool to query the instance metadata and configure the application based on the ג€environmentג€ value.
Lý do:
🛠️ Phương án này tối ưu nhất vì:
- Chỉ cần set một lần metadata key "environment" ở mức project (project metadata), áp dụng tự động cho tất cả instances trong project đó mà không cần cấu hình riêng lẻ.
- Deployment tool query instance metadata server (qua URL
http://metadata.google.internal/computeMetadata/v1/project/attributes/environment) để lấy giá trị, sau đó config app – chỉ 2 bước đơn giản. - Giảm thiểu steps: Không cần script phức tạp, không deploy tool riêng, không set per-instance.
📘 Nguồn tham khảo: GCP Compute Engine Metadata Overview (project attributes accessible từ instances); Querying Metadata (cập nhật 2024-2026).
❌ Phân tích tất cả các phương án
Dưới đây là giải thích chi tiết từng lựa chọn, giữ nguyên văn bản gốc tiếng Anh:
-
[SAI] When creating your instances, configure a startup script using the gcloud command to determine the project name that indicates the correct environment.
❌ Sai vì: Startup script chạy lúc boot instance, dùnggcloudđể query project name yêu cầu auth credentials (dịch vụ tài khoản), phức tạp và không an toàn (cần IAM roles). Không minimize steps vì phải embed script vào mọi instance template/group, dễ lỗi nếu project name thay đổi. Không tận dụng metadata server đơn giản. -
[ĐÚNG] In each project, configure a metadata key ג€environmentג€ whose value is the environment it serves. Use your deployment tool to query the instance metadata and configure the application based on the ג€environmentג€ value.
✅ Đúng vì: Như đã giải thích ở phần đáp án. Set project-level metadata một lần/project, query dễ dàng qua metadata server (headerMetadata-Flavor: Google), tự động scale cho nhiều instances. Hoàn hảo cho multi-project multi-env. -
[SAI] Deploy your chosen deployment tool on an instance in each project. Use a deployment job to retrieve the appropriate configuration file from your version control system, and apply the configuration when deploying the application on each instance.
❌ Sai vì: Yêu cầu deploy tool riêng trên instance master mỗi project (4 projects = 4 instances/tool), sau đó job pull config từ VCS (như Git) – tăng steps đáng kể (setup tool, VCS branching, job scheduling). Không tự động, dễ fail nếu VCS thay đổi, không dùng native GCP metadata. -
[SAI] During each instance launch, configure an instance custom-metadata key named ג€environmentג€ whose value is the environment the instance serves. Use your deployment tool to query the instance metadata, and configure the application based on the ג€environmentג€ value.
❌ Sai vì: Phải set custom metadata per-instance lúc launch (qua gcloud/CLI/template), lặp lại cho mọi instance/group (MIG/ASG) – không minimize steps nếu scale lớn. Project metadata hiệu quả hơn vì auto-apply toàn project, tránh lỗi thủ công.
🧩 Tóm tắt insight: Sử dụng project metadata là best practice cho multi-env shared code, giúp deployment tool (như Terraform, Ansible, hoặc custom script) linh hoạt và ít bước nhất! 🚀
- A The use of 64-bit numeric types for 32-bit numbers.
- B The use of the STRING data type for arbitrary-precision values.
- C The use of Version 1 UUIDs as primary keys that increase monotonically.
- D The use of LIKE instead of STARTS_WITH keyword for parameterized SQL queries.
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 một ứng dụng thương mại điện tử (ecommerce) đang phát triển, lưu trữ dữ liệu khách hàng, đơn hàng và hàng tồn kho dưới dạng bảng quan hệ trong Cloud Spanner (dịch vụ cơ sở dữ liệu phân tán, scale toàn cầu của Google Cloud). Trong quá trình kiểm tra tải (load test), hiệu suất của Spanner không scale tuyến tính như mong đợi (tức là khi tăng tải, hiệu suất không tăng tương ứng mà bị nghẽn). Câu hỏi yêu cầu xác định nguyên nhân gốc rễ gây ra vấn đề này.
🛠️ Bối cảnh kỹ thuật: Cloud Spanner sử dụng kiến thức phân vùng dữ liệu (sharding) dựa trên khóa chính (primary key) để phân phối tải. Nếu khóa chính có tính chất tăng dần đơn điệu (monotonically increasing), tất cả các thao tác chèn (insert) sẽ tập trung vào một shard duy nhất (hotspot), dẫn đến hiệu suất không scale tuyến tính – đặc biệt dưới tải cao. Đây là vấn đề phổ biến trong các hệ thống NoSQL/NewSQL như Spanner (cập nhật đến 2026, Spanner vẫn giữ nguyên best practices này theo tài liệu chính thức).
📘 Tài liệu tham khảo:
- Cloud Spanner Best Practices: Avoid Hotspots (Google Cloud Docs, phiên bản mới nhất 2026).
- Spanner Performance Tuning Guide – Nhấn mạnh UUID monotonically increasing gây bottleneck.
✅ Đáp án đúng và lý do lựa chọn
Đáp án đúng: The use of Version 1 UUIDs as primary keys that increase monotonically.
Lý do:
- UUID Version 1 (UUIDv1) được tạo dựa trên timestamp và địa chỉ MAC, nên chúng tăng dần theo thời gian (monotonically increasing).
- Khi dùng làm primary key trong Spanner, tất cả insert mới sẽ có giá trị key lớn hơn, dẫn đến hotspot trên shard cuối cùng (rightmost shard).
- Kết quả: Tải không phân bố đều, hiệu suất không scale tuyến tính dưới load test cao.
- Giải pháp khuyến nghị: Sử dụng UUIDv4 (random) hoặc key phân tán (interleaved tables/shuffle keys) để tránh vấn đề này. ✅
❌ Giải thích tất cả các phương án (đúng/sai)
Dưới đây là phân tích từng lựa chọn một cách chi tiết, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá dựa trên best practices Cloud Spanner mới nhất (2026):
-
❌ Phương án SAI: The use of 64-bit numeric types for 32-bit numbers.
Giải thích: Việc dùng kiểu NUMERIC 64-bit cho số 32-bit chỉ gây lãng phí bộ nhớ nhẹ (storage overhead ~4 bytes/row), không ảnh hưởng đến scaling. Spanner tự động tối ưu hóa và scale dựa trên CPU/QPS, không phải kích thước kiểu dữ liệu nhỏ như vậy. Không phải nguyên nhân hotspot. -
❌ Phương án SAI: The use of the STRING data type for arbitrary-precision values.
Giải thích: STRING phù hợp cho giá trị độ chính xác tùy ý (arbitrary-precision), và Spanner hỗ trợ index hiệu quả trên STRING. Vấn đề chỉ xảy ra nếu STRING quá dài (>few KB), nhưng không liên quan trực tiếp đến scaling tuyến tính hay hotspot trên primary key. Đây là lựa chọn hợp lý, không gây nghẽn. -
✅ Phương án ĐÚNG: The use of Version 1 UUIDs as primary keys that increase monotonically.
Giải thích: Như đã nêu ở trên, UUIDv1 tăng dần gây hotspot writes (tất cả insert đổ vào một shard), làm hiệu suất không scale. Đây là nguyên nhân chính xác khớp với triệu chứng load test. Spanner docs cảnh báo rõ ràng về sequential keys. -
❌ Phương án SAI: The use of LIKE instead of STARTS_WITH keyword for parameterized SQL queries.
Giải thích: LIKE có thể kém hiệu quả hơn STARTS_WITH cho prefix matching (do không dùng index tối ưu), nhưng chỉ ảnh hưởng đến query reads cụ thể, không phải scaling tổng thể (writes/inserts). Load test thường test writes nhiều hơn, và vấn đề không scale tuyến tính xuất phát từ primary key design chứ không phải query pattern này.
🧩 Kết luận: Vấn đề cốt lõi là thiết kế khóa chính kém, dễ khắc phục bằng cách chuyển sang key random/phân tán. Nếu áp dụng trong dev, hãy test với công cụ như Spanner Perf Tool! 🚀
Pub/Sub integration before deploying to Google Cloud. What should you do?
- A Create a service to publish messages, and deploy the Pub/Sub emulator. Generate random content in the publishing service, and publish to the emulator.
- B Create a service to publish messages to your application. Collect the messages from Pub/Sub in production, and replay them through the publishing service.
- C Create a service to publish messages, and deploy the Pub/Sub emulator. Collect the messages from Pub/Sub in production, and publish them to the emulator.
- D Create a service to publish messages, and deploy the Pub/Sub emulator. Publish a standard set of testing messages from the publishing service to the emulator.
Xem giải thích
🧩 Phân tích chi tiết nội dung câu hỏi
Câu hỏi tập trung vào việc kiểm thử tích hợp (integration testing) với Google Cloud Pub/Sub trong quá trình phát triển ứng dụng. Ứng dụng này đọc dữ liệu thẻ tín dụng (credit card data) từ một subscription của Pub/Sub. Bạn đã hoàn thành viết code và unit testing, giờ cần test tích hợp Pub/Sub trước khi deploy lên Google Cloud (tức là test local hoặc môi trường dev mà không ảnh hưởng production).
📌 Mục tiêu chính: Sử dụng công cụ phù hợp để mô phỏng Pub/Sub mà không cần tài nguyên cloud thật, đảm bảo tính an toàn dữ liệu nhạy cảm (PII như credit card), tái lập được (reproducible) và không rò rỉ dữ liệu production. Pub/Sub emulator là lựa chọn lý tưởng cho việc này (theo docs GCP mới nhất 2024-2026).
✅ Đáp án đúng và lý do lựa chọn
Đáp án đúng:
Create a service to publish messages, and deploy the Pub/Sub emulator. Publish a standard set of testing messages from the publishing service to the emulator.
🛠️ Lý do chọn đáp án này (theo best practices GCP Pub/Sub emulator - cập nhật 2026):
- Tạo một publishing service để gửi messages và deploy Pub/Sub emulator (chạy local qua Docker hoặc trực tiếp) giúp test integration đầy đủ mà không cần cloud.
- Sử dụng standard set of testing messages (bộ test messages chuẩn, cố định) đảm bảo tái lập kết quả test (reproducible), dễ debug, và an toàn vì không dùng dữ liệu thật (credit card nhạy cảm).
- Đây là cách chuẩn theo GCP: Emulator hỗ trợ đầy đủ publish/subscribe, schema validation, và dead letter queues (docs: Pub/Sub emulator hỗ trợ từ v1.0+). Tránh rủi ro bảo mật và chi phí cloud sớm.
Nguồn tham khảo:
📘 Google Cloud Pub/Sub Emulator Docs (cập nhật 2024-2026).
📘 GCP Testing Best Practices.
❌ Phân tích tất cả các phương án (đúng/sai)
Dưới đây là giải thích từng phương án một cách chi tiết, giữ nguyên văn bản gốc tiếng Anh. Mỗi cái được đánh giá dựa trên best practices testing GCP Pub/Sub (emulator cho local integration, tránh production data với PII).
-
Phương án SAI:
Create a service to publish messages, and deploy the Pub/Sub emulator. Generate random content in the publishing service, and publish to the emulator.
🧨 Lý do sai: Dù dùng emulator (đúng hướng), nhưng generate random content (nội dung ngẫu nhiên) làm test không tái lập được (non-reproducible), khó debug lỗi. Không phù hợp với dữ liệu credit card cần test deterministic (kết quả cố định). Best practice là dùng standard test data. -
Phương án SAI:
Create a service to publish messages to your application. Collect the messages from Pub/Sub in production, and replay them through the publishing service.
🧨 Lý do sai: Không dùng Pub/Sub emulator, mà replay trực tiếp từ production Pub/Sub (dữ liệu thật credit card - vi phạm bảo mật PCI-DSS/GDPR). Rủi ro cao lộ PII, phụ thuộc production (không ổn định), và không test integration local trước deploy. -
Phương án SAI:
Create a service to publish messages, and deploy the Pub/Sub emulator. Collect the messages from Pub/Sub in production, and publish them to the emulator.
🧨 Lý do sai: Dùng emulator là tốt, nhưng collect messages từ production (credit card data thật) vẫn rủi ro bảo mật cực cao (rò rỉ PII khi export/replay). Không an toàn cho testing, vi phạm compliance. Nên dùng fake/standard test data thay vì production replay. -
Phương án ĐÚNG (đã phân tích ở trên):
Create a service to publish messages, and deploy the Pub/Sub emulator. Publish a standard set of testing messages from the publishing service to the emulator.
✅ Hoàn hảo cho integration testing: An toàn, reproducible, chi phí thấp.
Tóm tắt nhanh 🔥: Luôn ưu tiên emulator + test data chuẩn cho Pub/Sub để tránh rủi ro trước deploy! Nếu cần scale test, sau dùng Cloud Pub/Sub Lite hoặc full cloud sau integration pass.
What should you do?
- A Write a shutdown script that uses inter-process signals to notify the application process to disconnect from the database.
- B Write a shutdown script that broadcasts a message to all signed-in users that the Compute Engine instance is going down and instructs them to save current work and sign out.
- C Write a shutdown script that writes a file in a location that is being polled by the application once every five minutes. After the file is read, the application disconnects from the database.
- D Write a shutdown script that publishes a message to the Pub/Sub topic announcing that a shutdown is in progress. After the application reads the message, it disconnects from the database.
Xem giải thích
🧩 Phân tích nội dung câu hỏi
Câu hỏi mô tả một ứng dụng thiết kế để subscribe và nhận message từ một Pub/Sub topic duy nhất (Google Cloud Pub/Sub), sau đó chèn dữ liệu tương ứng vào database. Ứng dụng chạy trên Linux và sử dụng preemptible virtual machines (nay gọi là Spot VMs từ năm 2022, theo cập nhật GCP đến 2026) trên Compute Engine để tiết kiệm chi phí. Yêu cầu chính: Tạo một shutdown script để thực hiện graceful shutdown (tắt máy một cách an toàn, tránh mất dữ liệu).
Lý do cần shutdown script: Spot VMs (preemptible) có thể bị GCP preempt (hủy đột ngột) bất cứ lúc nào với thông báo trước 30 giây. Shutdown script chạy tự động trong khoảng thời gian này để ứng dụng có thể ngắt kết nối database một cách sạch sẽ, hoàn tất xử lý message đang pending, tránh dữ liệu bị hỏng hoặc duplicate insert.
Bối cảnh kỹ thuật (cập nhật GCP 2026):
- Spot VMs cung cấp tín hiệu SIGTERM (signal 15) trước 30 giây.
- Shutdown script được chỉ định qua metadata
shutdown-scripttrên instance. - Ứng dụng cần xử lý nhanh (dưới 30 giây) vì thời gian preempt rất ngắn.
📘 Tài liệu tham khảo:
- Google Cloud Compute Engine: Spot VMs (cập nhật 2024-2026).
- Shutdown scripts for graceful shutdown.
- Pub/Sub subscriber best practices.
✅ Đáp án đúng
Đáp án đúng: Write a shutdown script that uses inter-process signals to notify the application process to disconnect from the database.
Lý do chọn đáp án này 🛠️:
- Đây là cách hiệu quả và nhanh nhất cho graceful shutdown trên Linux. Shutdown script gửi inter-process signals (như SIGTERM hoặc SIGUSR1) trực tiếp đến PID của application process.
- Application có thể trap signal (sử dụng
signalmodule trong Python/Node.js hoặctraptrong shell) để ngắt kết nối DB ngay lập tức (ví dụ:COMMITtransaction, close connection), hoàn tất message đang xử lý. - Thời gian phản hồi dưới 30 giây, phù hợp với Spot VM preempt notice. Không phụ thuộc vào polling hay external service, tránh race condition.
- Best practice theo GCP: Sử dụng signals cho local IPC (Inter-Process Communication) thay vì mechanisms chậm.
📋 Giải thích chi tiết tất cả các phương án
-
Write a shutdown script that uses inter-process signals to notify the application process to disconnect from the database.
✅ Đúng 🟢: Như giải thích trên, đây là phương pháp trực tiếp, đáng tin cậy và nhanh chóng. Signals là cơ chế kernel-level của Linux, đảm bảo notify chính xác process trên cùng instance mà không cần external dependency. Ví dụ script:kill -TERM $APP_PID(với PID từ PID file). -
Write a shutdown script that broadcasts a message to all signed-in users that the Compute Engine instance is going down and instructs them to save current work and sign out.
❌ Sai 🔴: Phương án này không liên quan đến ứng dụng backend subscribe Pub/Sub (không có "signed-in users"). Đây là logic cho web app tương tác user (như RDP/SSH), không giúp ngắt DB connection hay xử lý message. Shutdown chỉ 30 giây, broadcast không giải quyết vấn đề graceful DB disconnect. -
Write a shutdown script that writes a file in a location that is being polled by the application once every five minutes. After the file is read, the application disconnects from the database.
❌ Sai 🔴: Polling every 5 phút quá chậm so với 30 giây preempt notice – application có thể không kịp đọc file trước khi instance tắt, dẫn đến mất dữ liệu. Polling file là cơ chế kém hiệu quả, tốn CPU, không phải best practice cho real-time shutdown (GCP khuyến nghị signals thay vì polling). -
Write a shutdown script that publishes a message to the Pub/Sub topic announcing that a shutdown is in progress. After the application reads the message, it disconnects from the database.
❌ Sai 🔴: Gây vấn đề nghiêm trọng vì app subscribe cùng topic để xử lý business message – message shutdown sẽ lẫn vào queue, có thể bị process muộn hoặc duplicate bởi các subscriber khác. Không đảm bảo chỉ instance hiện tại nhận message kịp thời (pull/push delay), vi phạm graceful shutdown local. GCP docs khuyên tránh dùng Pub/Sub cho local signaling.
Kết luận 🎯: Chọn signals để tối ưu chi phí Spot VM mà vẫn đảm bảo reliability. Nếu triển khai, test bằng gcloud compute instances preempt!
- A Use a text editor and the Git command line to send your source code updates as pull requests from a public computer.
- B Use a text editor and the Git command line to send your source code updates as pull requests from a virtual machine running on a public computer.
- C Use Cloud Shell and the built-in code editor for development. Send your source code updates as pull requests.
- D Use a Cloud Storage bucket to store the source code that you need to edit. Mount the bucket to a public computer as a drive, and use a code editor to update the code. Turn on versioning for the bucket, and point it to the team's Git repository.
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 thực tế của một lập trình viên tại startup nhỏ, đang phát triển ứng dụng Node.js sử dụng các dịch vụ Google Cloud như Cloud Storage và Cloud Build, kết hợp với kho Git cho version control. Vào cuối tuần, manager yêu cầu cập nhật khẩn cấp website, nhưng bạn chỉ là dev duy nhất available và không có laptop công ty. Quy định nghiêm ngặt: không được lưu source code cục bộ trên máy tính không phải công ty (non-corporate computer).
Mục tiêu: Thiết lập môi trường phát triển (developer environment) an toàn, tuân thủ policy bảo mật, không vi phạm quy định lưu code local, và vẫn có thể commit/update code qua pull requests (PR) vào Git repo.
🛠️ Yêu cầu chính: Giải pháp phải browser-based, tích hợp Git, an toàn (không dùng public computer hoặc lưu local), phù hợp với Google Cloud best practices cho dev emergency.
✅ Đáp án đúng và lý do chọn
Đáp án đúng: Use Cloud Shell and the built-in code editor for development. Send your source code updates as pull requests.
Lý do chọn 📘:
- Cloud Shell là môi trường phát triển dựa trên trình duyệt (browser-based), cung cấp terminal Linux đầy đủ với code editor tích hợp (dựa trên VS Code), Git pre-installed, và quyền truy cập trực tiếp Google Cloud services (như Cloud Storage, Cloud Build).
- Không cần laptop, chỉ cần browser; dữ liệu không lưu local trên máy cá nhân/public (tất cả chạy trên server Google).
- Clone Git repo, edit code, commit/push PR trực tiếp – phù hợp emergency update.
- Tuân thủ zero-trust security: Ephemeral (session hết hạn tự xóa), authenticated qua Google account.
- Cập nhật 2026: Cloud Shell hỗ trợ 1-click deploy CI/CD với Cloud Build, tích hợp Cloud Code extension (VS Code-like).
Nguồn: Google Cloud Shell Documentation & Best Practices for Secure Development.
❌ Phân tích tất cả các phương án
Dưới đây là giải thích chi tiết 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 dựa trên bảo mật, tuân thủ policy, best practices Google Cloud (không lưu code local, tránh public machines).
-
[SAI] Use a text editor and the Git command line to send your source code updates as pull requests from a public computer.
❌ Sai vì: Sử dụng public computer (thư viện/internet cafe) vi phạm nghiêm trọng bảo mật – rủi ro keylogger/malware đánh cắp credentials/Git tokens/source code. Clone/edit code sẽ lưu local tạm thời, vi phạm policy "không lưu source code trên non-corporate computer". Không an toàn cho emergency update. -
[SAI] Use a text editor and the Git command line to send your source code updates as pull requests from a virtual machine running on a public computer.
❌ Sai vì: Vẫn dựa trên public computer làm host cho VM (ví dụ VirtualBox/VMware) – rủi ro bảo mật cao tương tự lựa chọn 1 (VM có thể bị compromise qua host). Lưu code local trong VM, vi phạm policy. Không phải giải pháp native Google Cloud, phức tạp và không ephemeral. -
[ĐÚNG] Use Cloud Shell and the built-in code editor for development. Send your source code updates as pull requests.
✅ Đúng như đã giải thích ở trên: Giải pháp tối ưu, zero local storage, fully managed bởi Google, hỗ trợ Git/PR seamless. Ideal cho remote/emergency dev. -
[SAI] Use a Cloud Storage bucket to store the source code that you need to edit. Mount the bucket to a public computer as a drive, and use a code editor to update the code. Turn on versioning for the bucket, and point it to the team's Git repository.
❌ Sai vì: Cloud Storage không phải Git repo – mount bucket như drive (qua gcsfuse/FUSE) trên public computer vẫn lưu code local tạm thời, vi phạm policy. Edit trực tiếp bucket không best practice (race conditions, no Git diff/merge), versioning chỉ backup chứ không thay thế Git. Không sync tự động với Git repo (cần manual). Rủi ro public computer cao.
Nguồn cập nhật: Cloud Storage Best Practices khuyên dùng cho static files, không phải source code editing.
🛠️ Kết luận: Chọn Cloud Shell đảm bảo security-first, productivity cao cho Google Cloud devs. Nếu cần scale, kết hợp Cloud Workstations (GA 2023, cập nhật 2026 với AI-assisted coding)!