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

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

Câu hỏi tập trung vào tình huống quản lý một instance Cloud SQL for PostgreSQL trên Google Cloud. Bạn có một primary instance ở region 1 và một read replica ở region 2 (replica đọc chéo vùng - cross-region read replica). Khi region 1 bị failure (suy giảm toàn bộ), bạn cần khôi phục instance để có thể sử dụng lại nhanh chóng nhất, giảm thiểu mất dữ liệu (minimize data loss) và tuân thủ best practices được Google khuyến nghị.

Mục tiêu chính là high availability (HA) và disaster recovery (DR) cho Cloud SQL PostgreSQL: Không chỉ backup/restore (có thể mất dữ liệu nhiều), mà ưu tiên failover từ replica để giữ tính nhất quán dữ liệu cao nhất có thể. Google khuyến nghị kiểm tra replication lag trước khi promote replica thành primary mới, đảm bảo dữ liệu đã sync gần như real-time. 📘

Kiến thức cập nhật (tính đến 2026): Theo tài liệu Google Cloud mới nhất (Cloud SQL PostgreSQL phiên bản hỗ trợ đến Postgres 16+), cross-region read replicas hỗ trợ manual failover bằng cách promote replica. Tự động failover chỉ áp dụng cho HA replicas trong cùng region (với failover replica). Cross-region không tự động failover.
Nguồn tham khảo:

• Cloud SQL PostgreSQL: Regional and cross-region replicas
• Failover and promote replicas
• Monitoring replication lag

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

Đáp án đúng: Check "Lag Bytes" in the monitoring dashboard for the primary instance in the read replica instance. Check the replication status using pg_catalog.pg_last_wal_receive_lsn(). Then, fail over to region 2 by promoting the read replica instance.

Lý do:
🛠️ Đây là quy trình Google-recommended cho cross-region failover để minimize data loss:

• Kiểm tra Lag Bytes trên Cloud Monitoring dashboard (metrics của replica) để xem lượng dữ liệu chưa sync (nên < vài MB để loss thấp).
• Sử dụng query pg_catalog.pg_last_wal_receive_lsn() trên replica để xác nhận WAL (Write-Ahead Log) đã nhận từ primary (kiểm tra replication status chi tiết).
• Sau đó, promote read replica thành primary mới ở region 2 qua Console/gcloud/SQL Admin API → Instance nhanh chóng available, chỉ mất dữ liệu chưa replicate (thường rất ít nếu lag thấp).
  ✅ Quy trình này an toàn, nhanh (phút), và theo best practices DR cho cross-region replicas. Không dùng backup vì restore chậm và mất dữ liệu từ điểm backup cuối.

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

• [SAI] Restore the Cloud SQL instance from the automatic backups in region 3.
  ❌ Sai vì: Automatic backups mặc định lưu trong cùng region với primary (region 1), không tự động ở region 3. Restore từ backup sẽ mất dữ liệu sau điểm backup cuối (có thể hàng giờ), không minimize data loss. Cross-region replica hiệu quả hơn. Không phải best practice cho failover.

• [SAI] Restore the Cloud SQL instance from the automatic backups in another zone in region 1.
  ❌ Sai vì: Region 1 đang failure toàn bộ → Không truy cập được backups ở zone khác trong region 1. Restore vẫn mất dữ liệu lớn, thời gian dài (rebuild từ PITR), và không dùng replica sẵn có ở region 2. Vi phạm nguyên tắc minimize loss và HA.

• [ĐÚNG] Check "Lag Bytes" in the monitoring dashboard for the primary instance in the read replica instance. Check the replication status using pg_catalog.pg_last_wal_receive_lsn(). Then, fail over to region 2 by promoting the read replica instance.
  ✅ Đúng như đã giải thích ở phần trên: Kiểm tra lag → Promote replica → Failover tối ưu, nhanh, loss thấp.

• [SAI] Check your instance operational log for the automatic failover status. Look for time, type, and status of the operations. If the failover operation is successful, no action is necessary. Otherwise, manually perform gcloud sql instances failover .
  ❌ Sai vì: Automatic failover chỉ áp dụng cho HA configuration trong cùng region (với failover replica), KHÔNG hỗ trợ cross-region read replicas. Không có auto-failover ở đây. Lệnh gcloud sql instances failover dùng cho HA intra-region, không promote cross-region replica (phải dùng promote-replica). Operational log không liên quan đến cross-region failure.

Hy vọng phân tích này giúp bạn nắm vững Cloud SQL HA/DR! 🚀 Nếu cần demo gcloud hoặc query chi tiết, hãy hỏi thêm.

🧩 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 xử lý tình huống chứng chỉ server (server certificate) sắp hết hạn trên một instance Cloud SQL for MySQL (dịch vụ cơ sở dữ liệu MySQL được quản lý bởi Google Cloud).

• Bối cảnh vấn đề: Chứng chỉ server cũ đang sắp expire (hết hạn), và yêu cầu tránh restart instance để không gây gián đoạn dịch vụ (downtime).
• Mục tiêu: Thực hiện hành động phù hợp trong console hoặc gcloud của Cloud SQL để cấp mới chứng chỉ mà không cần restart instance.
• Kiến thức liên quan (cập nhật đến 2026): Theo tài liệu chính thức Google Cloud (phiên bản mới nhất), Cloud SQL hỗ trợ rotation server certificate không downtime bằng cách tạo chứng chỉ mới song song với cái cũ. Instance sẽ tự động chuyển sang cert mới sau vài phút, cert cũ vẫn hoạt động đến 60 ngày sau để tránh gián đoạn client kết nối. Không liên quan đến AWS RDS (vì câu hỏi chỉ rõ "Cloud SQL for MySQL").

📘 Nguồn tham khảo:

• Cloud SQL SSL/TLS certificates docs (Google Cloud, cập nhật 2024-2026).
• Cloud SQL instance management best practices.

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

Đáp án đúng: Create a new server certificate, and download it.
Lý do: 🛠️ Đây là quy trình chuẩn của Cloud SQL để rotate server certificate mà không cần restart instance. Bạn tạo cert mới qua console/gcloud, download nó và cập nhật cho client. Instance tự động sử dụng cert mới sau 1-5 phút, cert cũ vẫn valid đến hết hạn (tối đa 60 ngày), đảm bảo zero-downtime. Phương án này an toàn, tuân thủ best practices của Google Cloud.

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

• [SAI] Issue a rollback, and download your server certificate.
  ❌ Sai vì: "Rollback" không tồn tại trong quy trình quản lý certificate của Cloud SQL. Rollback thường dùng cho database changes (như schema), không áp dụng cho cert. Thao tác này sẽ không giải quyết hết hạn cert và có thể gây lỗi, không tránh được restart nếu force apply.

• [SAI] Create a new client certificate, and download it.
  ❌ Sai vì: Client certificate dùng cho phía client kết nối đến server, không phải server certificate (dùng để xác thực server). Tạo client cert mới chỉ ảnh hưởng đến client auth, không thay thế server cert sắp expire, dẫn đến kết nối SSL vẫn fail khi cert server hết hạn.

• [ĐÚNG] Create a new server certificate, and download it.
  ✅ Đúng vì: Như đã giải thích ở trên, đây là cách chính thức để rotate server cert không downtime. Tạo cert mới → download → client cập nhật root CA → instance auto-switch sau vài phút. Hoàn hảo cho production!

• [SAI] Reset your SSL configuration, and download your server certificate.
  ❌ Sai vì: "Reset SSL configuration" sẽ xóa toàn bộ SSL setup hiện tại, buộc restart instance để apply (gây downtime). Không có tùy chọn reset an toàn mà tránh restart trong docs Cloud SQL, và nó làm mất cert cũ đột ngột, ảnh hưởng client kết nối ngay lập tức.

🧩 Lời khuyên thực hành: Luôn monitor cert expiry qua Cloud Monitoring/Alerting, và test kết nối với cert mới trước khi deploy rộng. Nếu dùng gcloud: gcloud sql ssl certificates create new-cert --instance=your-instance.

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

Câu hỏi mô tả tình huống công ty đang di chuyển toàn bộ ứng dụng legacy sang Google Cloud. Các ứng dụng on-premises sử dụng Oracle 12c với Oracle Real Application Cluster (RAC) để đảm bảo high availability (HA) và Oracle Data Guard cho disaster recovery (DR). Yêu cầu giải pháp phải:

• Minimal code changes (thay đổi code tối thiểu, giữ nguyên ứng dụng legacy).
• Cung cấp HA tương đương on-premises (hỗ trợ RAC đầy đủ).
• Low latency network (mạng độ trễ thấp cho ứng dụng legacy đã migrate). 📌 Mục tiêu chính: Tìm giải pháp Google Cloud gần giống nhất với môi trường Oracle RAC/Data Guard on-prem, tránh managed services yêu cầu refactor code lớn.

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

Đáp án đúng: Migrate the databases to Bare Metal Solution for Oracle.
🛠️ Lý do: Bare Metal Solution for Oracle cung cấp phần cứng dedicated (bare metal servers) được chứng nhận Oracle, hỗ trợ Oracle RAC và Data Guard đầy đủ mà không cần thay đổi code ứng dụng. Nó đảm bảo HA tương đương on-premises với cluster RAC multi-node, DR qua Data Guard, và low latency network nhờ kết nối trực tiếp high-speed (như 100 Gbps) trong Google Cloud. Đây là lựa chọn lý tưởng cho migration Oracle legacy lớn, theo best practices Google Cloud (cập nhật đến 2026).
📘 Nguồn tham khảo:

• Google Cloud Bare Metal Solution for Oracle
• Oracle on Google Cloud Best Practices (phiên bản mới nhất 2024-2026 hỗ trợ Oracle 19c/21c tương tự 12c migration).

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

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

• ❌ [SAI] Migrate the databases to Cloud Spanner.
  🧩 Cloud Spanner là distributed SQL database globally consistent, không tương thích Oracle RAC/Data Guard. Phải refactor code lớn (thay đổi schema, queries) vì dùng Spanner SQL dialect. Không hỗ trợ low latency local cluster (nó scale global), không phù hợp legacy Oracle 12c. Không đáp ứng minimal code changes hoặc HA Oracle-native.

• ❌ [SAI] Migrate the databases to Cloud SQL, and enable a standby database.
  🛠️ Cloud SQL for Oracle (hỗ trợ từ 2023, cập nhật 2026) là managed service với standby database cho HA/DR, nhưng KHÔNG hỗ trợ Oracle RAC (chỉ failover đơn giản, không multi-node cluster). Yêu cầu code changes cho managed features (như auto-backup), và latency cao hơn do fully managed layer. Không giữ nguyên HA on-premises đầy đủ.

• ❌ [SAI] Migrate the databases to Compute Engine using regional persistent disks.
  📦 Compute Engine VM cho phép self-managed Oracle RAC, dùng regional persistent disks cho HA storage. Tuy nhiên, phải setup thủ công RAC/Data Guard (tốn công, không certified bare metal), code có thể cần tweak cho networking, và latency không thấp bằng bare metal (do virtualization overhead). Không phải giải pháp "minimal changes" hoặc optimized cho Oracle enterprise.

• ✅ [ĐÚNG] Migrate the databases to Bare Metal Solution for Oracle.
  🏆 Như đã giải thích ở trên: Bare metal dedicated, hỗ trợ RAC/Data Guard native, zero code changes, low latency (direct hardware interconnect). Hoàn hảo cho migration legacy Oracle lớn-scale.

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

Câu hỏi mô tả một ứng dụng cổng thanh toán toàn cầu quan trọng (mission-critical global payments gateway) đang đánh giá các lựa chọn cơ sở dữ liệu trên Google Cloud. Ứng dụng cần:

• Khả dụng 24/7 cho người dùng toàn cầu 📱🌍: Phải hỗ trợ phân bố toàn cầu.
• Horizontally scalable (mở rộng ngang): Tự động mở rộng theo chiều ngang.
• Hỗ trợ open source databases (cơ sở dữ liệu mã nguồn mở): Như PostgreSQL hoặc tương tự.
• Automatically shardable (tự động phân mảnh): Tự động chia dữ liệu thành shards.
• Fully managed (quản lý hoàn toàn): Google quản lý mọi thứ.
• 99.999% availability (khả dụng 99.999% - "five nines"): SLA cao nhất.
• Strong transactional consistency (tính nhất quán giao dịch mạnh): Đảm bảo ACID đầy đủ, không eventual consistency.

Đây là yêu cầu điển hình cho hệ thống thanh toán cần toàn cầu hóa cao, độ tin cậy cực cao và giao dịch an toàn 🛡️️.

✅ Đáp án đúng: Select Cloud Spanner

Lý do chọn Cloud Spanner:

• Cloud Spanner là dịch vụ cơ sở dữ liệu quan hệ phân bố toàn cầu (globally distributed relational database) duy nhất trên Google Cloud đáp ứng TẤT CẢ yêu cầu:
  • ✅ Horizontally scalable & automatically shardable: Tự động sharding dữ liệu qua các node toàn cầu, hỗ trợ petabyte-scale.
  • ✅ Fully managed: Google quản lý hoàn toàn, bao gồm replication, backup.
  • ✅ 99.999% availability: SLA chính thức 99.999% cho multi-region configurations.
  • ✅ Strong transactional consistency: Sử dụng TrueTime (đồng hồ nguyên tử) để đảm bảo external consistency và ACID transactions toàn cầu.
  • ✅ Hỗ trợ open source: Hỗ trợ PostgreSQL dialect (từ 2021, cập nhật đến 2026 với Spanner PostgreSQL interface đầy đủ).
• Hoàn hảo cho payments gateway vì xử lý hàng triệu giao dịch/giây với độ trễ thấp toàn cầu. 🏆

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

Dưới đây là phân tích từng lựa chọn một cách chi tiết, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá dựa trên yêu cầu câu hỏi, sử dụng kiến thức Google Cloud mới nhất (cập nhật đến 2026: Cloud Spanner v2.1+ với enhanced PostgreSQL support).

• [SAI] Select Bare Metal Solution for Oracle.
  ❌ Sai vì: Bare Metal Solution là dịch vụ bare metal (phần cứng vật lý) cho Oracle Database, KHÔNG phải fully managed (bạn tự quản lý OS, DB). Không hỗ trợ auto-sharding toàn cầu, chỉ chạy Oracle (không open source thuần), SLA chỉ ~99.99% (không đạt 99.999%). Phù hợp on-prem migration, không cho app scalable toàn cầu. 🛑

• [SAI] Select Cloud SQL.
  ❌ Sai vì: Cloud SQL là managed relational DB (MySQL/PostgreSQL/SQL Server, hỗ trợ open source), nhưng KHÔNG horizontally scalable toàn cầu (regional chỉ, max ~100k IOPS/node). SLA multi-zone chỉ 99.99%, không auto-shard tự động như Spanner, consistency mạnh nhưng không global (dùng read replicas). Không đủ cho payments 24/7 toàn cầu. 🔒

• [SAI] Select Bigtable.
  ❌ Sai vì: Bigtable là NoSQL wide-column store, fully managed & horizontally scalable với auto-sharding, hỗ trợ 99.999% availability (multi-region). Nhưng KHÔNG strong transactional consistency (eventual consistency mặc định, chỉ single-row transactions), không relational/SQL đầy đủ (không open source relational). Không phù hợp giao dịch phức tạp như payments. 📊

• [ĐÚNG] Select Cloud Spanner.
  ✅ Đúng vì: Như giải thích trên, đáp ứng 100% yêu cầu với global distribution, TrueTime cho consistency, PostgreSQL support, và SLA 99.999%. Lý tưởng cho mission-critical apps. 🌟

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

• Cloud Spanner Docs: cloud.google.com/spanner/docs - SLA & features (99.999% multi-region).
• So sánh Databases: cloud.google.com/products/databases - Overview Spanner vs. others.
• PostgreSQL in Spanner: cloud.google.com/spanner/docs/postgresql - Open source support.
• SLA Details: cloud.google.com/spanner/sla - Chính thức 99.999%.
• Bigtable/Cloud SQL Limits: Tương ứng docs, xác nhận không match requirements.

Hy vọng phân tích này giúp bạn nắm vững! Nếu cần demo hoặc case study, hãy hỏi nhé 🛠️️.

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

Câu hỏi tập trung vào tình huống bạn là DBA (Database Administrator) quản lý Cloud SQL for PostgreSQL trên Google Cloud Platform (GCP). Yêu cầu chính là triển khai cơ chế xác thực không cần mật khẩu (password-less authentication) cho các ứng dụng, nhằm cho phép truy cập đọc (read) và ghi (write) vào cơ sở dữ liệu.

📘 Chi tiết ngữ cảnh:

• Cloud SQL là dịch vụ cơ sở dữ liệu quản lý trên GCP, hỗ trợ PostgreSQL.
• Password-less authentication nghĩa là sử dụng token tạm thời hoặc chứng chỉ từ hệ thống IAM thay vì username/password truyền thống, giúp tăng bảo mật và dễ dàng tích hợp với các ứng dụng cloud-native.
• Mục tiêu là read/write access, không chỉ read-only, nên cần cơ chế hỗ trợ đầy đủ quyền truy cập.

Câu hỏi kiểm tra kiến thức về các phương thức xác thực trong Cloud SQL PostgreSQL, dựa trên tài liệu GCP cập nhật đến năm 2026 (phiên bản Cloud SQL IAM authentication v2, hỗ trợ PostgreSQL 15+ với IAM roles chi tiết hơn).

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

Đáp án đúng: Use Identity and Access Management (IAM) authentication.

🛠️ Lý do chi tiết:

• IAM authentication trong Cloud SQL cho PostgreSQL cho phép xác thực không mật khẩu bằng cách sử dụng IAM service account hoặc user account để tạo token ngắn hạn (JWT), thay thế username/password.
• Hỗ trợ read/write access đầy đủ thông qua các IAM roles như roles/cloudsql.client và database roles tương ứng (ví dụ: cloudsqlsuperuser hoặc custom roles).
• Quy trình: Kích hoạt IAM auth trên instance Cloud SQL, cấp IAM policy binding, ứng dụng sử dụng gcloud hoặc ADC (Application Default Credentials) để generate token và connect qua postgres://user@instance/?auth=iam.
• Ưu điểm: Tích hợp liền mạch với GCP services, tự động rotate credentials, audit logs qua Cloud Audit Logs.
• Cập nhật 2026: Hỗ trợ IAM database auth với workload identity federation cho hybrid/multi-cloud.

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

Dưới đây là phân tích từng lựa chọn, với đánh dấu ✅ (đúng) hoặc ❌ (sai), giữ nguyên văn bản gốc tiếng Anh:

• ✅ Use Identity and Access Management (IAM) authentication.
  🛠️ Đúng vì: Như đã giải thích ở trên, đây là cơ chế chính thức của GCP cho Cloud SQL PostgreSQL, hỗ trợ password-less auth với read/write đầy đủ. Tài liệu: Cloud SQL IAM database authentication.

• ❌ Use Managed Active Directory authentication.
  🧩 Sai vì: Managed Active Directory (qua Cloud Directory Services hoặc Microsoft AD) chỉ hỗ trợ xác thực cho Cloud SQL for SQL Server, không áp dụng cho PostgreSQL. Nó yêu cầu Kerberos ticket (không password-less thuần túy) và không tích hợp IAM cho read/write PostgreSQL.

• ❌ Use Cloud SQL federated queries.
  🛠️ Sai vì: Federated queries là tính năng cho phép query dữ liệu từ external databases (như BigQuery federated queries với Cloud SQL), không phải cơ chế xác thực. Nó không cung cấp authentication cho applications connect trực tiếp đến PostgreSQL instance.

• ❌ Use PostgreSQL database's built-in authentication.
  📘 Sai vì: Các phương thức built-in của PostgreSQL (như SCRAM-SHA-256, MD5) bắt buộc sử dụng password hoặc certificate (không hoàn toàn password-less). Không tích hợp với GCP IAM và không phù hợp cho applications cloud-native cần token-based auth.

📚 Tài liệu tham khảo

• Cloud SQL for PostgreSQL: IAM authentication (cập nhật 2025-2026)
• Cloud SQL authentication overview
• GCP IAM best practices for databases
• Kiểm tra thực tế: Sử dụng gcloud sql instances patch --database-flags=cloudsql.iam_authentication=on để enable.

Hy vọng phân tích này giúp bạn nắm vững kiến thức! 🚀 Nếu cần ví dụ code connect, hãy hỏi thêm.

🧩 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 (migration) một cụm PostgreSQL on-premises dung lượng 2 TB sang máy ảo Ubuntu trên Compute Engine (Google Cloud). Mục tiêu chính là thiết lập môi trường mới, seed dữ liệu vào instance mới với thời gian downtime tối thiểu (minimum downtime).

• Bối cảnh kỹ thuật: PostgreSQL là cơ sở dữ liệu tự quản lý (self-managed) trên VM Compute Engine. Không sử dụng Cloud SQL (managed service), nên cần tự xử lý backup/restore thủ công.
• Yêu cầu cốt lõi: Sử dụng physical replication hoặc Point-in-Time Recovery (PITR) dựa trên Write-Ahead Logs (WAL) để đảm bảo dữ liệu đồng bộ liên tục mà không cần tắt nguồn (source) database quá lâu. Quy trình phải hỗ trợ backup online, lưu trữ trung gian qua Cloud Storage bucket, và recovery để target (Google Cloud server) "bắt kịp" source trước khi cutover.
• Thách thức: Với 2 TB dữ liệu lớn, phương pháp dump/export thông thường (như pg_dump) sẽ gây downtime cao hoặc không hỗ trợ WAL sync. Cần pg_basebackup (physical base backup online) + WAL archiving qua bucket để min downtime.
• Kiến thức cập nhật (2026): Theo tài liệu Google Cloud mới nhất (Database Migration guides, Compute Engine VM self-managed DB), sử dụng Cloud Storage cho WAL shipping trong PITR. PostgreSQL 16+ ưu tiên postgresql.conf thay recovery.conf (deprecated từ PG12), nhưng quy trình cốt lõi vẫn giữ (signal file như standby.signal + restore_command). Phương pháp này hỗ trợ logical replication hybrid nếu cần, nhưng ưu tiên physical cho min downtime.
  📘 Nguồn tham khảo:
  • Google Cloud: Migrating PostgreSQL to Compute Engine
  • PostgreSQL Docs: Continuous Archiving & PITR (v16)
  • Google Cloud Storage for WAL

✅ Đáp án đúng

Phương án đúng là lựa chọn được đánh dấu [ĐÚNG]:

1. Take a full backup while the database is online.
2. Create a bucket in Cloud Storage.
3. Transfer the backup to the bucket you just created.
4. Restore the backup into the Google Cloud primary server.
5. Create a recovery.conf file in the $PG_DATA directory.
6. Stop the source database.
7. Transfer the write ahead logs to the bucket you created before.
8. Start the PostgreSQL service.
9. Wait until Google Cloud primary server syncs with the running primary server.

Lý do chọn đáp án này 🛠️:
Đây là quy trình chuẩn PITR với WAL archiving cho migration PostgreSQL physical replication, đảm bảo downtime chỉ vài phút (chỉ lúc cutover: stop source → archive final WAL → promote target).

• Bước 1-3: pg_basebackup online tạo physical backup đầy đủ (không block writes), upload bucket làm archive storage.
• Bước 4-5: Restore basebackup vào target VM, config recovery.conf (hoặc tương đương PG12+) với restore_command fetch WAL từ bucket (gsutil).
• Bước 6-7: Stop source để tránh WAL mới, copy WAL còn lại lên bucket (source WAL archiving liên tục trước đó).
• Bước 8-9: Start target → tự động apply WAL từ bucket đến consistent state, sync hoàn tất nhanh (target catch-up).
  Kết quả: Dữ liệu đồng bộ 100% với min downtime, phù hợp 2TB lớn. ✅

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

Dưới đây là phân tích từng phương án một cách chi tiết, giữ nguyên text gốc bằng tiếng Anh. Mỗi phương án được đánh giá đúng/sai dựa trên tính khả thi, min downtime, và tính chính xác kỹ thuật PostgreSQL/Google Cloud.

• Phương án SAI đầu tiên:

  1. Take a full export while the database is offline.
  2. Create a bucket in Cloud Storage.
  3. Transfer the dump file to the bucket you just created.
  4. Import the dump file into the Google Cloud primary server.
  

  ❌ Lý do sai: Sử dụng "export" (pg_dump/pg_dumpall) offline → yêu cầu tắt database hoàn toàn (full downtime hàng giờ cho 2TB, vi phạm min downtime). pg_dump là logical dump (SQL script), không phải physical backup → không hỗ trợ WAL recovery/import WAL. Chỉ phù hợp small DB hoặc schema-only, không cho cluster lớn. Không có WAL sync → dữ liệu không real-time. 🕒

• Phương án B (SAI):

  B.1. Take a full export while the database is offline.
  2. Create a bucket in Cloud Storage.
  3. Transfer the dump file to the bucket you just created.
  4. Restore the backup into the Google Cloud primary server.
  

  ❌ Lý do sai: Tương tự phương án trên, vẫn offline export (pg_dump) gây full downtime lớn. Dù dùng "restore backup" ở bước 4 (gợi ý physical?), nhưng bước 1 là "export" + "dump file" → vẫn logical, không consistent với physical restore. Không có WAL/mechanism sync → miss data changes, không min downtime. 🔄

• Phương án ĐÚNG (như đã giải thích chi tiết ở trên): ✅ Hoàn hảo cho PITR physical replication. Toàn bộ quy trình online + WAL đảm bảo sync continuous, downtime chỉ cutover ngắn. 🏆

• Phương án SAI cuối cùng:

  1. Take a full export while the database is online.
  2. Create a bucket in Cloud Storage.
  3. Transfer the dump file and write-ahead logs to the bucket you just created.
  4. Restore the dump file into the Google Cloud primary server.
  5. Create a recovery.conf file in the $PG_DATA directory.
  6. Stop the source database.
  7. Transfer the write-ahead logs to the bucket you created before.
  8. Start the PostgreSQL service.
  9. Wait until the Google Cloud primary server syncs with the running primary server.
  

  ❌ Lý do sai: Mix logical export (pg_dump online) với physical WAL recovery → không tương thích. pg_dump tạo dump file (SQL/text), không thể restore + apply WAL (WAL chỉ cho physical backup như pg_basebackup). Bước 4 "restore dump" ok cho logical, nhưng recovery.conf + WAL apply sẽ lỗi/fail (crash recovery không nhận dump). Transfer WAL thừa/thiếu → sync không work. Gây inconsistency cao, không reliable cho production migration. ⚠️

Kết luận 📘: Chọn phương án physical backup online + WAL archiving là best practice cho Google Cloud Compute Engine PostgreSQL migration. Nếu dùng PG12+, thay recovery.conf bằng postgresql.conf + standby.signal để tương thích! 🚀

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

✅ Giải thích câu hỏi:
Câu hỏi mô tả tình huống bạn đã triển khai một instance Cloud SQL for SQL Server (dịch vụ cơ sở dữ liệu SQL Server được quản lý trên Google Cloud). Ngoài ra, bạn tạo một cross-region read replica (bản sao đọc chỉ định ở vùng khác) để phục vụ mục đích disaster recovery (DR) - khôi phục thảm họa. Công ty yêu cầu duy trì và giám sát Recovery Point Objective (RPO) dưới 5 phút, nghĩa là khoảng thời gian mất dữ liệu tối đa chấp nhận được phải nhỏ hơn 5 phút (RPO đo lường độ trễ sao chép dữ liệu từ primary sang replica). Nhiệm vụ là xác minh (verify) rằng cross-region read replica đáp ứng RPO này, tức là kiểm tra độ trễ sao chép (replication lag) phải <5 phút một cách liên tục và đáng tin cậy.

🛠️ Bối cảnh kỹ thuật (cập nhật đến 2026):
Cloud SQL for SQL Server hỗ trợ asynchronous read replicas cross-region từ phiên bản mới nhất (hỗ trợ SQL Server 2017/2019/2022). RPO được xác định bởi replication lag (độ trễ sao chép), và Google Cloud cung cấp metrics thời gian thực qua Cloud Monitoring. Không sử dụng Always On Availability Groups vì Cloud SQL không hỗ trợ tính năng native Always On của SQL Server (yêu cầu setup thủ công trên Compute Engine hoặc Azure).

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

• Cloud SQL for SQL Server: Monitor replication lag (Google Cloud Docs, cập nhật 2025).
• Cloud Monitoring metrics for Cloud SQL (metric: cloudsql.googleapis.com/database/sql/replica/lag).
• RPO best practices for Cloud SQL DR.

✅ Đáp án đúng: Use the Cloud Monitoring dashboard with available metrics from Cloud SQL.

Lý do lựa chọn:
🟢 Phương án này là chính xác nhất vì Cloud Monitoring cung cấp metrics chuyên dụng như cloudsql.googleapis.com/database/sql/replica/lag (đo độ trễ sao chép tính bằng giây), cho phép thiết lập dashboard tùy chỉnh, alerts và query Prometheus-style để verify RPO <5 phút (300 giây) thời gian thực. Đây là cách khuyến nghị chính thức từ Google Cloud để giám sát replica lag cross-region, đảm bảo tuân thủ SLA và DR. Các phiên bản Cloud SQL 2025-2026 hỗ trợ metric này với độ chính xác cao (granularity 1 phút).

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

• Use Cloud SQL instance monitoring.
  ❌ Sai: Cloud SQL instance monitoring (trong Console > Insights tab) chỉ cung cấp overview cơ bản như CPU, storage, connections, nhưng không có metric chi tiết về replication lag cho RPO. Nó không đủ để verify chính xác <5 phút, chỉ phù hợp giám sát tổng quát, không phải DR-specific.

• Use the Cloud Monitoring dashboard with available metrics from Cloud SQL.
  ✅ Đúng (như đã giải thích ở trên): Sử dụng dashboard trong Cloud Monitoring với metrics như replica lag để query, chart và alert trực tiếp, hỗ trợ cross-region và RPO verification tự động.

• Use Cloud SQL logs.
  ❌ Sai: Cloud SQL logs (qua Cloud Logging) ghi lỗi replication hoặc sự kiện (như "replica lag exceeded"), nhưng không cung cấp metric định lượng thời gian thực cho lag <5 phút. Logs là reactive (sau sự cố), không proactive để monitor RPO liên tục.

• Use the SQL Server Always On Availability Group dashboard.
  ❌ Sai: Always On Availability Groups là tính năng SQL Server Enterprise native (không được hỗ trợ trong Cloud SQL for SQL Server - chỉ read replicas managed). Không có dashboard Always On trong Cloud SQL Console hoặc Monitoring. Sử dụng sẽ không tồn tại hoặc không áp dụng, dẫn đến verify sai RPO (Always On dùng cho sync/async AG trên Compute Engine hoặc Azure, không phải Cloud SQL).

🛡️ Lưu ý cuối: Để triển khai tốt nhất, thiết lập alert policy trên metric replica lag >300s và kết hợp Database Insights cho full observability. Nếu cần HA mạnh hơn, xem xét regional replicas thay cross-region cho RPO thấp hơn.

🧩 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 di chuyển (migrate) một cơ sở dữ liệu PostgreSQL mission-critical từ on-premises lên Cloud SQL (dịch vụ managed PostgreSQL của Google Cloud). Yêu cầu chính là:

• Chịu được lỗi zonal (zonal failure: sự cố trong một zone cụ thể của region).
• Thời gian downtime < 5 phút (Recovery Time Objective - RTO < 5 phút).
• Không mất bất kỳ giao dịch nào (Recovery Point Objective - RPO = 0, tức zero data loss).
• Tuân thủ các thực hành được Google khuyến nghị (Google-recommended practices).

📘 Bối cảnh: Cloud SQL hỗ trợ high availability (HA) để tạo standby instance trong zone khác cùng region, sử dụng synchronous replication đảm bảo zero data loss và failover tự động nhanh chóng. Đây là cách tiếp cận chuẩn cho mission-critical workloads. (Kiến thức cập nhật đến 2026: Cloud SQL for PostgreSQL v15+ vẫn giữ HA regional với RTO ~60 giây đến vài phút, RPO=0).

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

Đáp án đúng: Enable high availability (HA) for the database to make it regional.

Lý do:

• HA configuration tự động tạo primary và standby instance trong hai zone khác nhau cùng region, sử dụng synchronous streaming replication (dữ liệu được replicate real-time, zero data loss).
• Failover tự động khi phát hiện zonal failure, RTO < 5 phút (thường ~60 giây), và RPO = 0 (không mất transaction).
• Đây là Google-recommended practice cho migration mission-critical PostgreSQL sang Cloud SQL, dễ thiết lập qua Console/CLI/gcloud và hỗ trợ migration tools như Database Migration Service (DMS).
• 🛠️ Cách thực hiện: Trong quá trình tạo instance Cloud SQL, enable HA → instance trở thành regional (không chỉ zonal).

Nguồn tham khảo:

• Cloud SQL for PostgreSQL High Availability (Google Cloud Docs, cập nhật 2024-2026).
• Best practices for Cloud SQL HA.

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

• ✅ Enable high availability (HA) for the database to make it regional.
  🟢 Đúng vì: Như giải thích trên, HA đảm bảo regional redundancy chống zonal failure, RTO <5 phút, RPO=0 với synchronous replication. Đây là giải pháp native, đơn giản, và được Google ưu tiên khuyến nghị cho production workloads.

• ❌ Take nightly snapshots of the primary database instance, and restore them in a secondary zone.
  🔴 Sai vì: Snapshots chỉ chụp hàng đêm (không real-time), dẫn đến mất dữ liệu từ snapshot cuối đến thời điểm failure (RPO cao, có thể hàng giờ). Restore thủ công tốn downtime >5 phút (thường hàng giờ), không tự động, và không phải recommended practice cho zero data loss.

• ❌ Build a change data capture (CDC) pipeline to read transactions from the primary instance, and replicate them to a secondary instance.
  🔴 Sai vì: CDC (như Debezium hoặc custom) là asynchronous hoặc có lag, không đảm bảo RPO=0 (có thể mất transactions nếu pipeline fail). Phức tạp để build/maintain, không phải Google-recommended cho Cloud SQL (thay vào đó dùng native HA hoặc read replicas). Không tự động failover nhanh <5 phút.

• ❌ Create a read replica in another region, and promote the read replica if a failure occurs.
  🔴 Sai vì: Read replica cross-region dùng asynchronous replication, RPO >0 (lag có thể giây/phút, mất data). Promote thủ công tốn >5 phút, chỉ phù hợp disaster recovery (DR) region-level chứ không phải zonal failure (vẫn trong region). Google recommend cross-region replicas cho read scaling, không phải HA.

🧮 Tóm tắt so sánh: | Yêu cầu | HA Regional | Snapshots | CDC | Cross-region Replica | |---------|-------------|-----------|-----|----------------------| | Zonal failure | ✅ | ❌ | ❌ | ❌ (region-level) | | RTO <5p | ✅ | ❌ | ❌ | ❌ | | RPO=0 | ✅ | ❌ | ❌ | ❌ | | Google-recommended | ✅ | ❌ | ❌ | ❌ |

💡 Lời khuyên: Sử dụng Database Migration Service (DMS) để migrate on-prem PostgreSQL sang Cloud SQL HA, đảm bảo continuous replication trong quá trình migrate. Kiểm tra docs mới nhất để confirm!

🧩 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 ứng dụng từ on-premises lên Google Cloud, cụ thể là triển khai ứng dụng trên Compute Engine VM (thuộc một project riêng) và cơ sở dữ liệu trên Cloud SQL (thuộc project khác). Vấn đề chính là cấu hình mạng (network) để hai thành phần này có thể giao tiếp an toàn, riêng tư (private connectivity) mà không cần public IP, tránh rủi ro bảo mật và độ trễ cao.

🛠️ Bối cảnh quan trọng:

• Compute Engine VM và Cloud SQL nằm ở hai project riêng biệt, nên không thể dùng default network trực tiếp.
• Mục tiêu: Kết nối private IP giữa VM và Cloud SQL, tuân thủ best practice của Google Cloud (cập nhật đến 2026: Shared VPC và Private Service Connect là ưu tiên cho multi-project setup).
• Không dùng public IP để tránh expose database ra internet.

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

• Cloud SQL Private IP overview (Google Cloud Docs, 2024).
• Shared VPC for multi-project (Best practice cho Cloud SQL + Compute Engine cross-project).
• VPC Network Peering limitations (Không lý tưởng cho Cloud SQL private service).

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

Đáp án đúng: Create a Shared VPC that both the application VMs and Cloud SQL instances will use.

Lý do 🏆:

• Shared VPC (hay VPC chia sẻ) cho phép một host project quản lý VPC chính, sau đó chia sẻ subnet với service project (project của VM và Cloud SQL).
• VM trên Compute Engine (service project) có thể dùng private IP để kết nối trực tiếp đến Cloud SQL (cũng trên Shared VPC), đảm bảo latency thấp, bảo mật cao (không route qua internet).
• Đây là best practice chính thức của Google Cloud cho multi-project setups với Cloud SQL (hỗ trợ Private Service Connect từ 2022, cập nhật 2026 vẫn ưu tiên Shared VPC cho scalability).
• Tránh peering phức tạp hoặc public exposure. Dễ quản lý firewall rules tập trung ở host project.

📋 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 bằng tiếng Anh. Mỗi phương án được đánh dấu ✅ (đúng) hoặc ❌ (sai), kèm lý do cụ thể dựa trên kiến thức GCP mới nhất.

• [SAI] Create a new VPC network in each project, and use VPC Network Peering to connect the two together.
  ❌ Sai vì: VPC Peering chỉ hỗ trợ transitive routing hạn chế và không lý tưởng cho Cloud SQL private IP. Cloud SQL yêu cầu allocated IP range riêng (từ 2024), peering có thể gây conflict routes hoặc không hỗ trợ full private connectivity cross-project mà không dùng Private Service Connect (phức tạp hơn Shared VPC). Dẫn đến lỗi kết nối hoặc expose public IP. (Xem limitations peering docs).

• [ĐÚNG] Create a Shared VPC that both the application VMs and Cloud SQL instances will use.
  ✅ Đúng vì: Như giải thích ở trên, Shared VPC cho phép host project chia sẻ toàn bộ subnet, VM và Cloud SQL dùng chung mạng private. Hỗ trợ IAM permissions granular, scale dễ dàng cho enterprise (cập nhật 2026: Tích hợp AlloyDB/Cloud SQL Enterprise Plus). Đây là giải pháp chuẩn và được khuyến nghị cho migration cross-project.

• [SAI] Use the default networks, and leverage Cloud VPN to connect the two together.
  ❌ Sai vì: Default networks ở hai project khác nhau không kết nối trực tiếp (không route private). Cloud VPN dùng cho on-premises hybrid, tạo tunnel encrypted nhưng overkill, độ trễ cao (encryption overhead), và vẫn cần public IP endpoint. Không phù hợp internal GCP traffic; vi phạm best practice private connectivity.

• [SAI] Place both the application VMs and the Cloud SQL instances in the default network of each project.
  ❌ Sai vì: Default network giới hạn trong project riêng, không có route tự động giữa projects. VM không thể truy cập private IP của Cloud SQL cross-project, buộc dùng public IP (rủi ro bảo mật cao, không khuyến khích). Phải cấu hình authorized networks thủ công, dễ lỗi scale.

🧠 Kết luận: Shared VPC là lựa chọn tối ưu, giúp migration suôn sẻ và tuân thủ zero-trust model của Google Cloud! Nếu cần lab thực hành, dùng Qwiklabs "Shared VPC with Cloud SQL".

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

Câu hỏi mô tả tình huống thực tế trong môi trường DevOps sử dụng Terraform để triển khai ứng dụng và cơ sở dữ liệu Cloud SQL (dịch vụ managed database của Google Cloud Platform - GCP). Vấn đề chính là:

• Mỗi khi có thay đổi ứng dụng mới (new application change), toàn bộ môi trường bị torn down (terraform destroy) và recreated (terraform apply lại từ đầu).
• Lớp database persistent (dữ liệu lâu dài) bị mất hoàn toàn vì resource Cloud SQL bị xóa theo.
• Mục tiêu: Ngăn chặn việc database bị drop/destroy khi chạy terraform destroy, đảm bảo dữ liệu không bị mất mà vẫn cho phép tear down các phần khác (như app).

Đây là vấn đề phổ biến khi sử dụng IaC (Infrastructure as Code) như Terraform với môi trường ephemeral (tạm thời), cần bảo vệ resource critical như database. Giải pháp tập trung vào lifecycle management của Terraform resource cho google_sql_database_instance.

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

• Terraform Google Provider - google_sql_database_instance (cập nhật đến phiên bản 6.x năm 2026).
• Google Cloud SQL Documentation - Terraform Integration.

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

Đáp án đúng: Set Terraform deletion_protection to true.

Lý do:

• Trong resource google_sql_database_instance của Terraform Google Provider, thuộc tính deletion_protection = true sẽ ngăn chặn việc destroy resource khi chạy terraform destroy.
• Khi set true, Terraform sẽ báo lỗi và từ chối xóa instance Cloud SQL, bảo vệ dữ liệu persistent. Bạn vẫn có thể tear down các resource khác (như app servers). Để xóa sau này, phải set lại false rồi destroy.
• Đây là giải pháp trực tiếp, an toàn nhất cho kịch bản tear down/recreate lặp lại, phù hợp best practice IaC. ✅

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

• Set Terraform deletion_protection to true.
  ✅ Đúng. Như giải thích trên, thuộc tính này (boolean, mặc định false) explicitly bảo vệ instance khỏi destroy. Hoàn hảo cho trường hợp database persistent trong pipeline CI/CD.

• Rerun terraform apply.
  ❌ Sai. Lệnh terraform apply chỉ áp dụng thay đổi (create/update), không ngăn destroy khi chạy terraform destroy. Vấn đề gốc là tear down xóa hết, rerun apply chỉ recreate từ đầu (mất data), không giải quyết root cause.

• Create a read replica.
  ❌ Sai. Read replica (bản sao chỉ đọc) dùng cho high availability/read scaling, không prevent destroy primary instance. Nếu primary bị drop, replica cũng không tự động promote persistent data mà cần manual failover (vẫn mất data gốc nếu destroy toàn bộ).

• Use point-in-time-recovery (PITR) to recover the database.
  ❌ Sai. PITR (Point-in-Time Recovery) là tính năng backup của Cloud SQL để khôi phục data đến thời điểm cụ thể sau khi mất (từ automated backups). Nó chỉ dùng để recover sau sự cố, không prevent destroy ban đầu. Phải enable PITR trước, nhưng vẫn không giữ instance persistent.

Kết luận: Giải pháp đúng tận dụng lifecycle protection của Terraform, tránh rủi ro data loss trong automation. Nếu cần tùy chỉnh, kết hợp với lifecycle { prevent_destroy = true } cho các resource khác! 🚀