Ngân hàng đề — Google Cloud Digital Leader

Tìm thấy 611 câu.

Câu 171 Digital Transformation with Google Cloud

A traditional retail bank with 150-year history operates branches nationwide but is losing customers to mobile-first fintech competitors offering instant account opening, AI-powered financial advice, and real-time payment notifications. The executive leadership is debating whether to pursue digital transformation or continue optimizing existing legacy systems.

What is the most fundamental change in perspective required for successful digital transformation?

  1. A Viewing all public cloud providers as identical commodities.
  2. B Viewing technology as a necessary but static cost center.
  3. C Viewing technology as a strategic enabler for business innovation and growth.
  4. D Focusing only on reducing short-term IT costs.
Xem giải thích

Đáp án

C — Coi công nghệ là ĐÒN BẨY CHIẾN LƯỢC cho đổi mới và tăng trưởng kinh doanh.

Vì sao đúng

Câu hỏi là về thay đổi CĂN BẢN NHẤT trong tư duy, và đó là chuyển từ nhìn công nghệ như một khoản chi phí sang nhìn nó như nguồn tạo ra giá trị.

⚠ Hai cách nhìn:

CÔNG NGHỆ LÀ TRUNG TÂM CHI PHÍ
    → mục tiêu: ⚠ GIỮ CHO NÓ CHẠY
      với chi phí thấp nhất
    → đo bằng: ngân sách CNTT
      trên doanh thu
    → quyết định: cắt giảm
        ↓
    ⚠ Không ai kỳ vọng CNTT tạo
      ra doanh thu

⚠ CÔNG NGHỆ LÀ ĐÒN BẨY CHIẾN LƯỢC
    → mục tiêu: ⚠ TẠO SẢN PHẨM
      và trải nghiệm mới
    → đo bằng: doanh thu từ kênh số,
      tốc độ ra tính năng
    → quyết định: đầu tư có chọn lọc
        ↓
    ⚠ CNTT ngồi cùng bàn khi
      bàn chiến lược

⚠ Vì sao đây là thay đổi CĂN BẢN NHẤT:

Mọi thứ khác đều theo sau nó
        ↓
    Coi là chi phí
        ↓
    ⚠ → cắt ngân sách → không
      tuyển được người giỏi
    ⚠ → không dám thử nghiệm
    ⚠ → hệ thống cũ dần
        ↓
    Coi là đòn bẩy
        ↓
    ⚠ → đầu tư vào năng lực
    ⚠ → chấp nhận thử và sai
    ⚠ → ra sản phẩm mới

⚠ Áp vào ngân hàng trong đề:

Đối thủ fintech làm được gì:
    ⚠ mở tài khoản TỨC THÌ
    ⚠ tư vấn tài chính bằng AI
    ⚠ thông báo giao dịch thời gian thực
        ↓
    → đó không phải "tối ưu hệ
      thống cũ"
    → ⚠ đó là SẢN PHẨM MỚI được
      tạo ra bằng công nghệ
        ↓
    ⚠ Không thể đạt được bằng
      tư duy "giữ cho hệ thống chạy"

Nhất quán với #13398 (cùng lô này) về động lực chuyển đổi số, và #13382 (cùng lô) về rủi ro khi không chuyển đổi. Cả ba cùng một bức tranh.

Vì sao các phương án khác sai

  • D (chỉ tập trung giảm chi phí CNTT ngắn hạn) — phương án gần nhất về mặt "cũng là một quan điểm quản trị", nhưng nó chính là tư duy cũ mà chuyển đổi số phải thay đổi.

  • B (coi công nghệ là trung tâm chi phí cần thiết nhưng tĩnh) — cũng mô tả tư duy cũ.

  • A (coi mọi nhà cung cấp đám mây là như nhau) — không phải thay đổi tư duy về chuyển đổi số, và cũng không đúng.

Ghi nhớ

⚠ Chuyển đổi số gồm ba phần — bảng nên thuộc: | Phần | Nội dung | |---|---| | Công nghệ | đám mây, dữ liệu, AI | | Quy trình | ⚠ tự động hoá, rút ngắn phê duyệt | | ⚠ Con người và văn hoá | ⚠ phần khó nhất và quyết định nhất | | Sai lầm phổ biến | ⚠ coi đó là dự án công nghệ thuần tuý |

Từ khoá nhận diện:

"công nghệ là đòn bẩy chiến lược" → thay đổi tư duy căn bản "đối thủ nhanh hơn, khách kỳ vọng cao hơn" → động lực "mất thị phần vì chậm" → rủi ro "ra tính năng nhanh" → agility

⚠ Dấu hiệu tổ chức vẫn coi CNTT là chi phí Dấu hiệu
CNTT báo cáo cho bộ phận tài chính
Ngân sách CNTT bị cắt đầu tiên khi khó khăn
Không ai từ CNTT dự họp chiến lược ⚠
Đo thành công bằng "hệ thống không sập"
Không có ngân sách cho thử nghiệm ⚠
Dấu hiệu chuyển đổi thật sự Dấu hiệu
Có ngân sách cho thử nghiệm và thất bại
Đo bằng chỉ số NGHIỆP VỤ ⚠ doanh thu số, tỉ lệ giữ chân khách
Đội sản phẩm và kỹ thuật ngồi chung
Triển khai hằng tuần thay vì hằng quý
Lãnh đạo nói được về công nghệ
Bốn con đường hiện đại hoá Con đường
Rehost nhanh nhất, lợi ích ít nhất
Replatform điểm ngọt
Refactor lợi ích lớn nhất
Rebuild / Replace ⚠ tạo sản phẩm số mới hoàn toàn
Với ngân hàng trong đề ⚠ thường cần cả bốn cho các hệ thống khác nhau
Bắt đầu từ đâu Bước
Chọn MỘT hành trình khách hàng đau nhất ⚠ ví dụ: mở tài khoản
Đo thời gian và tỉ lệ bỏ dở hiện tại
Làm thí điểm với đội nhỏ, có quyền quyết
Đo kết quả và công bố nội bộ ⚠ thắng lợi nhỏ tạo động lực
Nhân rộng

Ba câu hỏi kiểm chứng cho ban lãnh đạo: | Câu hỏi | Vì sao | |---|---| | Công nghệ xuất hiện ở đâu trong chiến lược | ⚠ nếu chỉ ở mục "chi phí" thì chưa đổi | | Ngân sách cho thử nghiệm là bao nhiêu | | | Khách mất bao lâu để mở một tài khoản | so với đối thủ |

Và một điều làm nên khác biệt giữa các ngân hàng chuyển đổi thành công và thất bại: họ ngừng hỏi "cái này tốn bao nhiêu" và bắt đầu hỏi "cái này giúp ta bán thêm được gì". Cùng một khoản đầu tư, nhưng hai câu hỏi đó dẫn tới hai bộ quyết định hoàn toàn khác nhau.

Câu 172 Scaling with Google Cloud Operations

A technology company is evaluating whether to adopt DevOps practices across their engineering organization. The leadership team is reviewing the five key DevOps objectives to understand the cultural and operational changes required.

Which of the following represents one of the five key objectives that defines successful DevOps adoption?

  1. A Increase the number of organizational silos.
  2. B Implement change slowly and infrequently.
  3. C Avoid using automation and tooling.
  4. D Accepting failure as normal.
Xem giải thích

Đáp án

D — Chấp nhận thất bại là chuyện bình thường.

Vì sao đúng

Đây là một trong năm mục tiêu cốt lõi của DevOps, và cũng là mục tiêu khó chấp nhận nhất về mặt văn hoá — nhưng là nền tảng cho bốn mục tiêu còn lại.

⚠ Năm mục tiêu của DevOps:

1. ⚠ GIẢM SILO giữa các bộ phận
2. ⚠ CHẤP NHẬN THẤT BẠI LÀ
   CHUYỆN BÌNH THƯỜNG    ← đề này
3. ⚠ THỰC HIỆN THAY ĐỔI DẦN DẦN,
   THƯỜNG XUYÊN
4. ⚠ TẬN DỤNG CÔNG CỤ và TỰ ĐỘNG HOÁ
5. ⚠ ĐO LƯỜNG MỌI THỨ

⚠ Vì sao "chấp nhận thất bại" lại là mục tiêu:

Trong hệ thống phức tạp
        ↓
    ⚠ Sự cố là ĐIỀU CHẮC CHẮN
      XẢY RA, không phải ngoại lệ
        ↓
    Nếu coi thất bại là điều
    ĐÁNG XẤU HỔ
        ↓
    ⚠ Người ta GIẤU sự cố
    ⚠ Không dám triển khai
    ⚠ Đổ lỗi cho nhau
    ⚠ → hệ thống KHÔNG được cải thiện
        ↓
    Nếu coi thất bại là BÌNH THƯỜNG
        ↓
    ⚠ Báo cáo sớm và trung thực
    ⚠ Mổ xẻ KHÔNG QUY TỘI
    ⚠ Sửa HỆ THỐNG, không phạt người
    ⚠ → dám triển khai thường xuyên

⚠ Ba phương án kia là NGƯỢC LẠI của ba mục tiêu:

"TĂNG số ốc đảo tổ chức"
    → ⚠ ngược mục tiêu 1

"Thay đổi CHẬM và HIẾM"
    → ⚠ ngược mục tiêu 3

"TRÁNH dùng tự động hoá và công cụ"
    → ⚠ ngược mục tiêu 4
        ↓
    ⚠ Ba phương án sai được tạo ra
      bằng cách ĐẢO NGƯỢC ba mục tiêu

Nhất quán với #13321 (lô 140) — câu đó về DevOps là triết lý văn hoá phá bỏ silo, và với #13264 (lô 138) về SRE và blameless postmortem. Cả ba cùng một hệ giá trị.

Vì sao các phương án khác sai

  • B (thực hiện thay đổi chậm và hiếm) — phương án gần nhất về mặt "nghe như thận trọng", nhưng đó là ĐẢO NGƯỢC mục tiêu thứ ba: DevOps chủ trương thay đổi nhỏ và thường xuyên vì mỗi lần triển khai ít rủi ro hơn.

  • A (tăng số ốc đảo tổ chức) — đảo ngược mục tiêu giảm silo.

  • C (tránh dùng tự động hoá và công cụ) — đảo ngược mục tiêu tự động hoá.

Ghi nhớ

⚠ Năm mục tiêu của DevOps — bảng phải thuộc: | Mục tiêu | Nội dung | |---|---| | Giảm silo | ⚠ dev và ops làm việc cùng nhau | | ⚠ Chấp nhận thất bại là bình thường | ⚠ blameless, học từ sự cố | | Thay đổi dần và thường xuyên | ⚠ triển khai nhỏ, nhiều lần | | Tận dụng công cụ và tự động hoá | CI/CD, IaC | | Đo lường mọi thứ | ⚠ chỉ số DORA, SLO |

Từ khoá nhận diện:

"văn hoá, phá silo, chấp nhận thất bại" → DevOps "SLO, error budget, do Google khởi xướng" → SRE "bảo mật trong CI/CD" → DevSecOps "sprint, backlog" → Agile

⚠ Vì sao thay đổi NHỎ lại AN TOÀN hơn Lý do
Ít mã thay đổi → ít chỗ có thể sai
Dễ tìm nguyên nhân khi hỏng ⚠ chỉ có một thay đổi để nghi ngờ
Quay lui dễ và nhanh
Ngược lại ⚠ triển khai lớn mỗi quý = hàng trăm thay đổi cùng lúc
Nghịch lý ⚠ triển khai THƯỜNG XUYÊN hơn lại ÍT sự cố hơn
⚠ Blameless postmortem — cách làm Cách
Tập trung vào HỆ THỐNG, không vào người
Giả định ⚠ con người làm đúng theo thông tin họ CÓ lúc đó
Hỏi ⚠ "vì sao hệ thống cho phép điều này xảy ra?"
Không hỏi "ai làm hỏng?"
Kết quả hệ thống được sửa, người không bị phạt
Hệ quả ⚠ người ta BÁO CÁO sự cố sớm hơn
⚠ Bốn chỉ số DORA — "đo lường mọi thứ" Chỉ số
Deployment frequency triển khai bao nhiêu lần
Lead time for changes từ commit tới production
Change failure rate % triển khai gây sự cố
Time to restore service ⚠ phục hồi mất bao lâu
Phát hiện quan trọng ⚠ đội tốt vừa NHANH HƠN vừa ỔN ĐỊNH HƠN
Công cụ hỗ trợ trên Google Cloud Công cụ
Cloud Build CI/CD
Cloud Deploy triển khai theo giai đoạn
Artifact Registry kho image
Terraform hạ tầng dưới dạng mã
Cloud Monitoring / Logging / Trace đo lường
Error Reporting gom lỗi thành nhóm

Ba câu hỏi kiểm chứng cho một đội: | Câu hỏi | Vì sao | |---|---| | Sự cố gần nhất kết thúc thế nào | ⚠ có ai bị khiển trách không | | Bao lâu triển khai một lần | hằng tuần hay hằng quý | | Có ai ngại báo cáo sự cố không | ⚠ dấu hiệu văn hoá quy tội |

Và một phép thử rất thẳng cho biết văn hoá DevOps đã thật sự hình thành chưa: hỏi xem lần gần nhất có người tự nguyện báo cáo lỗi của chính mình là khi nào. Ở nơi thất bại được coi là bình thường, chuyện đó xảy ra hằng tuần; ở nơi không, nó không bao giờ xảy ra — và các sự cố chỉ lộ ra khi đã quá muộn.

Câu 173 Innovating with Google Cloud Artificial Intelligence

An online travel agency wants to show personalized hotel recommendations to users based on their past searches and bookings. They want to use an ML model to predict which hotels a user is most likely to be interested in.

This is an example of what kind of business value created by ML?

  1. A Automating infrastructure management.
  2. B Unlocking unstructured data.
  3. C Improving customer experience and engagement.
  4. D Scaling business decisions.
Xem giải thích

Đáp án

C — Cải thiện trải nghiệm và mức độ gắn kết của khách hàng.

Vì sao đúng

Đề mô tả gợi ý khách sạn cá nhân hoá dựa trên lịch sử tìm kiếm và đặt phòng — giá trị trực tiếp của nó là khách tìm được thứ họ muốn nhanh hơn và gắn bó hơn với nền tảng.

⚠ Chuỗi giá trị trong đề:

Lịch sử tìm kiếm và đặt phòng
        ↓
    ⚠ Mô hình học SỞ THÍCH của
      từng người
        ↓
    Gợi ý khách sạn PHÙ HỢP
        ↓
    ⚠ Khách tìm được nhanh hơn
    ⚠ Ít phải lọc qua hàng nghìn
      lựa chọn không liên quan
        ↓
    → trải nghiệm tốt hơn
    → ⚠ tỉ lệ chuyển đổi và
      quay lại cao hơn

⚠ Bốn nhóm giá trị kinh doanh của ML:

⚠ CẢI THIỆN TRẢI NGHIỆM KHÁCH HÀNG
    → gợi ý, cá nhân hoá, chatbot
    → ⚠ đề này

MỞ KHOÁ DỮ LIỆU PHI CẤU TRÚC
    → ⚠ phân tích ảnh, âm thanh,
      văn bản tự do

TỰ ĐỘNG HOÁ QUYẾT ĐỊNH Ở QUY MÔ LỚN
    → duyệt vay, phát hiện gian lận,
      dự báo nhu cầu

TỰ ĐỘNG HOÁ VẬN HÀNH
    → dự đoán hỏng hóc thiết bị

⚠ Vì sao ba phương án kia không đúng trọng tâm:

"TỰ ĐỘNG HOÁ QUẢN LÝ HẠ TẦNG"
    → ⚠ đó là giá trị của
      tự động hoá vận hành,
      không phải của gợi ý

"MỞ KHOÁ DỮ LIỆU PHI CẤU TRÚC"
    → ⚠ dữ liệu tìm kiếm và đặt
      phòng là CÓ CẤU TRÚC

"MỞ RỘNG QUYẾT ĐỊNH KINH DOANH
 Ở QUY MÔ LỚN"
    → ⚠ đúng một phần, nhưng
      trọng tâm của đề là
      TRẢI NGHIỆM KHÁCH HÀNG

Vì sao các phương án khác sai

  • D (mở rộng quyết định kinh doanh ở quy mô lớn) — phương án gần nhất và đúng một phần: hệ gợi ý đúng là ra hàng triệu quyết định nhỏ. Nhưng mục đích và giá trị chính mà đề nhấn mạnh là cá nhân hoá cho người dùng, tức là trải nghiệm.

  • B (mở khoá dữ liệu phi cấu trúc) — dữ liệu tìm kiếm và đặt phòng là có cấu trúc.

  • A (tự động hoá quản lý hạ tầng) — không liên quan tới bài toán gợi ý.

Ghi nhớ

⚠ Bốn nhóm giá trị kinh doanh của ML — bảng nên thuộc: | Nhóm | Ví dụ | |---|---| | ⚠ Trải nghiệm khách hàng | ⚠ gợi ý, cá nhân hoá, chatbot, tìm kiếm thông minh | | Mở khoá dữ liệu phi cấu trúc | ảnh, âm thanh, văn bản tự do | | Quyết định ở quy mô lớn | duyệt vay, gian lận, dự báo | | Tự động hoá vận hành | bảo trì dự đoán, phân loại ticket |

Từ khoá nhận diện:

"gợi ý, cá nhân hoá cho từng người" → trải nghiệm khách hàng "phân tích ảnh, ghi âm, văn bản tự do" → mở khoá dữ liệu phi cấu trúc "dự báo, phát hiện gian lận" → quyết định ở quy mô lớn "dự đoán máy sắp hỏng" → tự động hoá vận hành

Các cách xây hệ gợi ý trên Google Cloud Cách
MATRIX_FACTORIZATION trong BigQuery ML ⚠ lọc cộng tác bằng SQL
Vertex AI Search for Commerce ⚠ giải pháp gợi ý dựng sẵn cho bán lẻ
Two-tower model trên Vertex AI tuỳ biến sâu
Gemini với ngữ cảnh người dùng gợi ý kèm giải thích
Bắt đầu bằng ⚠ giải pháp dựng sẵn, tuỳ biến sau
⚠ Ba kiểu hệ gợi ý Kiểu
Content-based ⚠ dựa trên đặc điểm khách sạn
Collaborative filtering ⚠ "người giống bạn cũng thích..."
Hybrid kết hợp cả hai — thường tốt nhất
⚠ Vấn đề chung cold start — người dùng mới chưa có lịch sử
⚠ Cold start — xử lý thế nào Cách
Người dùng MỚI chưa có lịch sử
Giải ⚠ gợi ý phổ biến theo điểm đến, theo mùa
Hỏi vài câu lúc đăng ký
Dùng tín hiệu ngữ cảnh ⚠ thiết bị, vị trí, thời điểm
Khách sạn MỚI chưa ai đặt dùng content-based
Đo giá trị của hệ gợi ý Chỉ số
Tỉ lệ nhấp vào gợi ý (CTR)
⚠ Tỉ lệ chuyển đổi thành đặt phòng thước đo thật
Giá trị đơn trung bình
Tỉ lệ quay lại
⚠ Cách đo đúng A/B testing so với không có gợi ý
⚠ Cân nhắc về đạo đức và riêng tư Điểm
Minh bạch ⚠ cho người dùng biết vì sao được gợi ý
Cho phép tắt cá nhân hoá
Tránh "bong bóng lọc" ⚠ luôn gợi ý cùng một kiểu
Tuân thủ GDPR dữ liệu hành vi cũng là dữ liệu cá nhân
Không phân biệt giá theo nhóm nhạy cảm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gợi ý có tốt hơn "phổ biến nhất" không | ⚠ A/B test — luôn cần đường cơ sở | | Người dùng mới thấy gì | kiểm cold start | | Có bị lặp lại một kiểu không | ⚠ đo độ đa dạng của gợi ý |

Và một đường cơ sở luôn nên đo trước khi tự hào về hệ gợi ý: danh sách "khách sạn được đặt nhiều nhất". Nó không cần mô hình nào cả, và trong nhiều trường hợp lại cho tỉ lệ chuyển đổi không tệ chút nào — nên nếu mô hình phức tạp không vượt được nó, thì công sức bỏ ra chưa đem lại giá trị thật.

Câu 174 Exploring Data Transformation with Google Cloud
An organization has large, existing Hadoop and Spark workloads running in their on-premises data center. They want to migrate these workloads to a fully managed, cost-effective service on Google Cloud that lets them continue using the familiar open-source ecosystem. Which Google Cloud service is designed for this?
  1. A Compute Engine
  2. B Cloud SQL
  3. C Dataproc
  4. D BigQuery
Xem giải thích

Đáp án

C — Dataproc.

Vì sao đúng

Đề nêu ba yêu cầu, và cụm quyết định là "tiếp tục dùng hệ sinh thái mã nguồn mở quen thuộc":

⚠ Ba yêu cầu ↔ Dataproc:

1. "TẢI CÔNG VIỆC HADOOP và SPARK
    ĐANG CÓ"
     → ⚠ đã có mã Spark/Hadoop viết sẵn

2. "DỊCH VỤ CÓ QUẢN LÝ, TIẾT KIỆM"
     → Google lo cụm

3. ⚠ "TIẾP TỤC dùng hệ sinh thái
    MÃ NGUỒN MỞ QUEN THUỘC"
     → ⚠ không phải viết lại

⚠ Dataproc cho gì:

Cụm Hadoop/Spark có quản lý
        ↓
    ⚠ Dựng cụm trong ~90 GIÂY
      (tự dựng mất hàng giờ)
    ⚠ Chạy nguyên mã Spark, Hive,
      Pig, Presto sẵn có
    ⚠ Tích hợp Cloud Storage,
      BigQuery, IAM
    ⚠ ⚠ CỤM TẠM THỜI:
      dựng → chạy job → XOÁ
        ↓
    → chỉ trả tiền lúc thật sự chạy

⚠ Mẫu "cụm phù du" — chỗ tiết kiệm lớn nhất:

Tại chỗ
    → cụm chạy 24/7, dùng ~20%

Dataproc
    → ⚠ mỗi job một cụm riêng
    → dữ liệu để ở CLOUD STORAGE,
      không để trong HDFS của cụm
    → chạy xong XOÁ cụm
        ↓
    ⚠ Thêm Spot VM cho worker
      → giảm thêm rất nhiều

⚠ Vì sao ba phương án kia không hợp:

COMPUTE ENGINE
    → ⚠ tự cài và tự vận hành
      Hadoop — chính là việc họ
      muốn bỏ

BIGQUERY
    → ⚠ kho phân tích bằng SQL
    → ⚠ phải VIẾT LẠI job Spark
      thành SQL

CLOUD SQL
    → CSDL giao dịch, sai hoàn toàn

Vì sao các phương án khác sai

  • D (BigQuery) — phương án gần nhất về mặt "cũng phân tích quy mô lớn", và về lâu dài thường là đích đến tốt hơn. Nhưng nó đòi viết lại job Spark thành SQL, trái với yêu cầu "tiếp tục dùng hệ sinh thái quen thuộc".

  • A (Compute Engine) — tự dựng Hadoop trên máy ảo; vẫn phải tự vận hành, đúng thứ họ muốn thoát khỏi.

  • B (Cloud SQL) — CSDL quan hệ cho tải giao dịch; sai hoàn toàn loại.

Ghi nhớ

⚠ Chọn engine xử lý dữ liệu — bảng phải thuộc: | Nhu cầu | Chọn | |---|---| | ⚠ Đã có mã Hadoop/Spark | ⚠ Dataproc | | Viết mới, cần cả lô lẫn luồng | Dataflow (Apache Beam) | | Biến đổi bằng SQL trong kho | Dataform | | Kéo thả, không viết mã | Cloud Data Fusion | | Phân tích bằng SQL | BigQuery |

Từ khoá nhận diện:

"Spark, Hadoop, Hive, đã có sẵn" → Dataproc "viết mới pipeline, cả lô lẫn luồng" → Dataflow "nhận luồng sự kiện" → Pub/Sub "SQL trên dữ liệu lớn" → BigQuery

⚠ Dataproc — thực hành tốt Thực hành
⚠ Cụm phù du (ephemeral) dựng cho từng job rồi xoá
⚠ Dữ liệu ở Cloud Storage, KHÔNG ở HDFS tách lưu trữ khỏi tính toán
Spot VM cho worker phụ ⚠ giảm chi phí đáng kể
Autoscaling policy thêm bớt worker theo tải
Dataproc Serverless ⚠ chạy Spark KHÔNG cần cụm
Component Gateway truy cập giao diện web của Spark
⚠ Dataproc Serverless — lựa chọn hiện đại hơn Điểm
Không dựng cụm nào cả
Gửi job Spark là chạy
⚠ Không phải chọn kích cỡ máy
Trả theo tài nguyên job dùng
Hợp với ⚠ job Spark rời rạc, không cần cụm lâu dài
Con đường hiện đại hoá sau khi lên đám mây Bước
1 Dataproc — chạy nguyên mã cũ (replatform)
2 Chuyển dữ liệu sang Cloud Storage / BigQuery
3 ⚠ Viết lại dần job đơn giản thành SQL BigQuery
4 Job phức tạp giữ ở Dataproc Serverless hoặc Dataflow
⚠ không phải viết lại tất cả cùng lúc
So sánh chi phí Điểm
Cụm 24/7 ⚠ đắt nhất, dùng ít nhất
Cụm phù du rẻ hơn nhiều
Spot VM rẻ thêm nữa
Dataproc Serverless ⚠ không có cụm nhàn rỗi
BigQuery thường rẻ nhất nếu viết được bằng SQL

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cụm có nhàn rỗi không | ⚠ xem thời gian cụm sống so với thời gian chạy job | | Dữ liệu còn ở HDFS không | nên chuyển sang Cloud Storage | | Job nào viết lại được bằng SQL | ⚠ ứng viên chuyển sang BigQuery |

Và một thay đổi tư duy quan trọng khi chuyển Hadoop lên đám mây: cụm không còn là tài sản cố định mà là thứ dùng xong thì vứt. Ở trung tâm dữ liệu, cụm phải sống mãi vì dữ liệu nằm trong HDFS của nó; trên đám mây, dữ liệu ở Cloud Storage nên cụm chỉ là công cụ tính toán tạm thời.

Câu 175 Exploring Data Transformation with Google Cloud

A company wants to analyze user interaction data from their mobile game in real time to offer personalized promotions. The data arrives as a continuous, unbounded stream of events.

Which Google Cloud service is designed to ingest and deliver these real-time event streams?

  1. A Cloud Storage
  2. B Cloud SQL
  3. C BigQuery
  4. D Pub/Sub
Xem giải thích

Đáp án

D — Pub/Sub.

Vì sao đúng

Đề mô tả đúng loại dữ liệu và đúng vai trò mà Pub/Sub đảm nhận trong kiến trúc luồng.

⚠ Ba manh mối ↔ Pub/Sub:

1. "dữ liệu tương tác người dùng
    THỜI GIAN THỰC"
     → cần độ trễ thấp

2. ⚠ "LUỒNG SỰ KIỆN LIÊN TỤC,
    KHÔNG GIỚI HẠN (unbounded)"
     → ⚠ đúng định nghĩa dữ liệu luồng

3. ⚠ "NHẬN và CHUYỂN GIAO"
     (ingest and deliver)
     → ⚠ đúng vai trò của Pub/Sub

⚠ Vị trí trong kiến trúc:

Hàng nghìn thiết bị chơi game
        ↓
    ⚠ PUB/SUB  ← "cửa trước"
      nhận vào, đệm lại, tách rời
        ↓
    DATAFLOW
      xử lý, làm giàu, gộp cửa sổ
        ↓
   ┌────────┴────────┐
BIGQUERY        Bigtable / API
(phân tích)     (khuyến mãi
                 thời gian thực)

⚠ Vì sao cần lớp đệm ở giữa:

Nếu game ghi THẲNG vào hệ xử lý
        ↓
    ⚠ Hệ xử lý chậm → MẤT sự kiện
    ⚠ Lượng người chơi tăng vọt
      → hệ xử lý gục
    ⚠ Mỗi bên gửi phải biết
      địa chỉ bên nhận
        ↓
Pub/Sub ở giữa:
    ⚠ TÁCH RỜI gửi và nhận
    ⚠ ĐỆM khi hạ nguồn chậm
    ⚠ Tự mở rộng
    ⚠ Giữ thông điệp tới 7 ngày

Nhất quán với #13260 (lô 138) — Pub/Sub là "cửa trước" của dữ liệu luồng, và #13303 (lô 139) — Pub/Sub làm bus thông điệp giữa microservice. Cùng một sản phẩm, các vai trò bổ sung nhau. Hoàn toàn nhất quán.

Vì sao các phương án khác sai

  • C (BigQuery) — phương án gần nhất vì BigQuery có nhận được dữ liệu luồng (qua Storage Write API hoặc managed subscription). Nhưng nó là đích đến để phân tích, không phải lớp nhận và đệm; nó không tách rời bên gửi khỏi bên nhận.

  • A (Cloud Storage) — lưu tệp, phù hợp với xử lý theo lô. Ghi hàng nghìn sự kiện nhỏ mỗi giây thành từng đối tượng là cách dùng sai.

  • B (Cloud SQL) — CSDL giao dịch; không chịu nổi luồng sự kiện quy mô này.

Ghi nhớ

⚠ Vòng đời dữ liệu — bảng phải thuộc: | Giai đoạn | Sản phẩm | |---|---| | ⚠ Nhận (ingest) | ⚠ Pub/Sub (luồng), Datastream (CDC), Storage Transfer (lô) | | Xử lý | Dataflow, Dataproc, Dataform | | Lưu | Cloud Storage, BigQuery, Bigtable | | Phân tích | BigQuery | | Trực quan hoá | Looker |

Từ khoá nhận diện:

"nhận luồng sự kiện, cửa trước, unbounded" → Pub/Sub "biến đổi, làm giàu, gộp cửa sổ" → Dataflow "phân tích, báo cáo" → BigQuery "đọc trạng thái người chơi mili-giây" → Bigtable / Memorystore

Vì sao Pub/Sub hợp vai "cửa trước" Lý do
Tự mở rộng không khai trước dung lượng
Toàn cầu một topic phục vụ mọi vùng
Tách rời gửi và nhận ⚠ hai bên không cần biết nhau
Đệm khi hạ nguồn chậm
Giữ thông điệp tới 7 ngày
Giao ít nhất một lần, có tuỳ chọn exactly-once
Ordering key giữ thứ tự theo khoá
⚠ Fan-out — thế mạnh lớn nhất Điểm
MỘT topic, NHIỀU subscription
⚠ Mỗi subscription nhận MỘT BẢN SAO đầy đủ
Ví dụ trong đề ⚠ một luồng sự kiện, ba bên dùng: khuyến mãi, phân tích, chống gian lận
Thêm bên dùng mới ⚠ chỉ tạo thêm subscription, không đụng game
Bốn khái niệm của Pub/Sub Khái niệm
Topic nơi bên gửi đẩy vào
Subscription ⚠ mỗi cái một bản sao đầy đủ
Push / Pull ai chủ động
Dead-letter topic thông điệp giao hỏng nhiều lần
⚠ Theo dõi Pub/Sub Chỉ số
num_undelivered_messages ⚠ dồn ứ
oldest_unacked_message_age ⚠ dữ liệu cũ tới mức nào
send_request_count tốc độ publish
⚠ Hạn giữ mặc định 7 ngày — quá là MẤT dữ liệu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có bị dồn ứ không | metric num_undelivered_messages | | Dữ liệu có tươi không | oldest_unacked_message_age | | Bên nhận xử lý được trùng không | ⚠ kiểm tính idempotent |

Và một lợi ích của Pub/Sub chỉ lộ rõ khi sản phẩm lớn lên: thêm một bên tiêu thụ mới không cần đụng gì tới game. Hôm nay chỉ có hệ khuyến mãi đọc luồng sự kiện; ngày mai đội chống gian lận cũng muốn cùng dữ liệu đó — chỉ cần một subscription mới, và bản game đang chạy trên điện thoại người dùng không hề biết có gì thay đổi.

Câu 176 Innovating with Google Cloud Artificial Intelligence
A company wants to build a machine learning model to categorize customer support emails into different topics like "Billing," "Technical Issue," or "Account Question." They have a large dataset of historical emails that have already been labeled with the correct topic. Which Google Cloud AI solution would allow them to build a high-quality, custom model based on their own data?
  1. A AutoML Text Classification.
  2. B BigQuery ML to predict a numerical value.
  3. C The Text-to-Speech API.
  4. D The Vision AI API.
Xem giải thích

Đáp án

A — AutoML Text Classification.

Vì sao đúng

Đề đặt công ty này đúng vào giữa thang giải pháp AI: có dữ liệu riêng đã gán nhãn, cần mô hình chất lượng cao trên dữ liệu của chính họ, nhưng không nói tới đội ML.

⚠ Ba manh mối ↔ AutoML:

1. ⚠ "PHÂN LOẠI email theo chủ đề
    RIÊNG: Billing, Technical Issue,
    Account Question"
     → ⚠ nhãn RIÊNG của nghiệp vụ,
       không API sẵn nào biết

2. ⚠ "tập dữ liệu LỚN đã được
    GÁN NHÃN sẵn"
     → ⚠ có đủ nguyên liệu huấn luyện

3. "mô hình CHẤT LƯỢNG CAO,
    TUỲ BIẾN, dựa trên dữ liệu
    của chính họ"
     → ⚠ đúng vị trí của AutoML

⚠ Quy trình AutoML Text:

Tải lên CSV/JSONL:
    văn bản email + nhãn chủ đề
        ↓
    AutoML tự:
      - chọn kiến trúc mô hình
      - tinh chỉnh siêu tham số
      - chia train / valid / test
      - dùng transfer learning
        ↓
    Xem trang Evaluate:
      precision, recall,
      ⚠ ma trận nhầm lẫn
        ↓
    Triển khai → endpoint
        ↓
    ⚠ Không viết mã mô hình nào

⚠ Vì sao ba phương án kia sai:

BIGQUERY ML "để dự đoán một
GIÁ TRỊ SỐ"
    → ⚠ chính lời phương án đã sai:
      đây là bài toán PHÂN LOẠI,
      không phải hồi quy

TEXT-TO-SPEECH API
    → ⚠ chữ → GIỌNG NÓI
    → ngược hướng hoàn toàn

VISION AI API
    → ⚠ xử lý ẢNH, không phải
      văn bản

Nhất quán với #13380 (lô 141) và #13273 (lô 139) — cả ba đề đều là có dữ liệu riêng đã gán nhãn + muốn ít lập trình, và cả ba cùng khoá AutoML. Hoàn toàn nhất quán.

Vì sao các phương án khác sai

  • B (BigQuery ML để dự đoán một giá trị số) — phương án gần nhất về mặt "cũng là công cụ ML", nhưng chính lời phương án tự loại mình: đây là bài toán phân loại nhãn, không phải dự đoán số. (BigQuery ML thật ra có LOGISTIC_REG để phân loại, nhưng phương án nêu sai mục đích.)

  • C (Text-to-Speech API) — chuyển chữ thành giọng nói.

  • D (Vision AI API) — xử lý ảnh.

Ghi nhớ

⚠ Ba mức giải pháp AI — bảng phải thuộc: | Mức | Khi nào | |---|---| | API dựng sẵn | nhãn PHỔ QUÁT, không cần dữ liệu riêng | | ⚠ AutoML | ⚠ nhãn RIÊNG + có dữ liệu gán nhãn + ít lập trình | | Mô hình tuỳ biến | cần kiểm soát kiến trúc, có đội ML |

Từ khoá nhận diện:

"chủ đề riêng của công ty, đã gán nhãn" → AutoML "cảm xúc, thực thể chung" → Natural Language API "dữ liệu bảng biểu, biết SQL" → BigQuery ML "phân loại email tự động" → ⚠ AutoML Text hoặc Gemini

⚠ Vì sao Natural Language API không đủ Lý do
Nó phân loại vào hơn 700 chủ đề CHUNG
Ví dụ ⚠ "/Business & Industrial/Finance"
Nhưng đề cần ⚠ "Billing", "Technical Issue", "Account Question"
Đó là phân loại RIÊNG của quy trình hỗ trợ khách hàng
Kết luận phải huấn luyện trên nhãn của chính họ
Chuẩn bị dữ liệu cho AutoML Text Yêu cầu
Tối thiểu ~50 mẫu mỗi nhãn ⚠ 1.000+ thì tốt hơn nhiều
Nhãn nên cân bằng lệch quá thì mô hình thiên vị
Nhãn phải NHẤT QUÁN ⚠ người gán hiểu giống nhau
Định dạng CSV hoặc JSONL trên Cloud Storage
⚠ chất lượng nhãn quan trọng hơn thuật toán
⚠ Đọc trang đánh giá Chỉ số
Precision dự đoán đúng bao nhiêu phần
Recall bắt được bao nhiêu phần
⚠ Ma trận nhầm lẫn ⚠ nhãn nào bị lẫn với nhãn nào
Ngưỡng tin cậy kéo để đổi cân bằng
Hành động nhãn yếu → thu thập thêm dữ liệu cho nhãn đó
⚠ Thiết kế quy trình phân loại email Bước
Tin cậy CAO ⚠ định tuyến tự động
Tin cậy THẤP ⚠ đưa cho người phân loại
Ghi lại quyết định của người ⚠ làm dữ liệu huấn luyện lại
Theo dõi drift chủ đề mới xuất hiện theo thời gian
Huấn luyện lại định kỳ
Lựa chọn hiện đại hơn Lựa chọn
Gemini với prompt và vài ví dụ ⚠ có khi không cần huấn luyện gì cả
Ưu nhanh, linh hoạt, giải thích được
Nhược ⚠ chi phí mỗi lần gọi, độ trễ cao hơn
Thực hành ⚠ thử Gemini trước, so với AutoML

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mô hình có tốt hơn quy tắc từ khoá không | ⚠ luôn cần đường cơ sở | | Nhãn nào yếu nhất | ma trận nhầm lẫn | | Nhãn có nhất quán không | ⚠ cho hai người gán lại 100 email và so |

Và một việc nên làm trước khi huấn luyện bất kỳ mô hình phân loại nào: kiểm tra xem chính con người có gán nhãn nhất quán không. Nếu hai nhân viên hỗ trợ phân loại cùng một email vào hai chủ đề khác nhau, thì không mô hình nào học được ranh giới đó — và vấn đề nằm ở định nghĩa chủ đề, không ở thuật toán.

Câu 177 Scaling with Google Cloud Operations

A global e-commerce platform runs its entire payment processing system on Google Cloud. During a major sales event, the payment service experiences a critical outage that prevents customers from completing purchases, costing the company thousands of dollars per minute. The engineering team needs immediate expert assistance from Google Cloud support with guaranteed response within 1 hour, available 24/7/365.

Which Google Cloud Customer Care support level must the company have to meet this requirement?

  1. A Basic Support
  2. B Premium Support
  3. C Standard Support
  4. D Enhanced Support
Xem giải thích

Đáp án

B — Premium Support.

Vì sao đúng

Đề mô tả một sự cố P1 điển hình: hệ thanh toán ngừng hoạt động giữa đợt bán hàng lớn, thiệt hại hàng nghìn đô mỗi phút. Với mức nghiêm trọng này, gói Premium là lựa chọn phù hợp nhất.

⚠ Vì sao tình huống này là P1:

"hệ thanh toán NGỪNG HOẠT ĐỘNG"
"khách KHÔNG hoàn tất mua hàng được"
"thiệt hại HÀNG NGHÌN ĐÔ MỖI PHÚT"
        ↓
    ⚠ Sản xuất không dùng được
    ⚠ Ảnh hưởng doanh thu trực tiếp
        ↓
    → P1 — Critical impact

⚠ Mục tiêu phản hồi P1 theo từng gói:

BASIC     → ⚠ KHÔNG có hỗ trợ kỹ thuật
STANDARD  → 4 giờ, GIỜ LÀM VIỆC
ENHANCED  → ⚠ 1 giờ, 24/7
PREMIUM   → ⚠ 15 PHÚT, 24/7, có TAM

⚠ Vì sao Premium phù hợp với tình huống này:

Thiệt hại hàng nghìn đô MỖI PHÚT
        ↓
    ⚠ Mỗi phút chờ đợi là tiền thật
        ↓
    Premium: mục tiêu 15 phút
    Enhanced: mục tiêu 1 giờ
        ↓
    ⚠ Chênh lệch 45 phút
      = hàng chục nghìn đô
        ↓
    + ⚠ Premium có TAM — người đã
      hiểu sẵn kiến trúc của bạn,
      điều phối khi có sự cố lớn

Ghi nhớ về chất lượng câu hỏi

Đề viết yêu cầu là "phản hồi được bảo đảm trong vòng 1 giờ, 24/7/365". Theo tài liệu chính thức của Google Cloud Customer Care, mục tiêu phản hồi P1 là:

  • Enhanced Support: 1 giờ, 24/7
  • Premium Support: 15 phút, 24/7

Xét đúng câu chữ "trong vòng 1 giờ", thì Enhanced đã đáp ứng và là gói TỐI THIỂU thoả yêu cầu. Premium cũng thoả (15 phút < 1 giờ) nhưng vượt xa mức cần.

Khoá đáp án giữ nguyên là B (Premium) — đề dùng chữ "must have" cùng bối cảnh thiệt hại hàng nghìn đô mỗi phút, hàm ý mức hỗ trợ cao nhất. Nhưng khi đi thi, hãy nhớ đúng con số: nếu một câu khác hỏi "gói TỐI THIỂU nào cho phản hồi P1 trong 1 giờ" thì đáp án là Enhanced.

Đối chiếu #13293 (lô 139): câu đó khoá Premium cho yêu cầu "mục tiêu phản hồi 15 phút" — và đó là con số chỉ Premium mới có. Hai câu nhất quán về bảng số liệu; chỉ khác ở chỗ đề này diễn đạt ngưỡng lỏng hơn.

Vì sao các phương án khác sai

  • D (Enhanced Support) — phương án gần nhất, và như đã nêu ở trên, về mặt con số nó đáp ứng đúng ngưỡng "1 giờ". Nó bị loại vì đề nhấn mạnh mức độ nghiêm trọng và cụm "hỗ trợ chuyên gia ngay lập tức", cùng việc không có TAM.

  • C (Standard Support) — chỉ giờ làm việc, P1 mục tiêu 4 giờ. Không thoả "24/7/365".

  • A (Basic Support) — miễn phí, chỉ có tài liệu, cộng đồng và hỗ trợ về thanh toán; không có hỗ trợ kỹ thuật.

Ghi nhớ

⚠ Bốn gói hỗ trợ — bảng PHẢI THUỘC SỐ: | Gói | P1 | Giờ | |---|---|---| | Basic | ⚠ không có hỗ trợ kỹ thuật | — | | Standard | 4 giờ | giờ làm việc | | Enhanced | ⚠ 1 giờ | 24/7 | | Premium | ⚠ 15 phút | 24/7, có TAM |

Từ khoá nhận diện:

"15 phút, TAM, mức cao nhất" → Premium "1 giờ, 24/7" → ⚠ Enhanced "chỉ giờ làm việc" → Standard "chỉ tài liệu và diễn đàn" → Basic (miễn phí)

⚠ Bốn mức ưu tiên Mức
P1 — Critical ⚠ sản xuất NGỪNG hoạt động
P2 — High suy giảm nghiêm trọng nhưng còn chạy
P3 — Medium ảnh hưởng vừa, có cách đi vòng
P4 — Low câu hỏi chung
⚠ đặt sai mức làm chậm chính bạn
⚠ Cam kết là PHẢN HỒI, không phải GIẢI QUYẾT Điểm
Google cam kết ⚠ trong bao lâu sẽ có KỸ SƯ bắt tay vào
Google KHÔNG cam kết ⚠ trong bao lâu SỬA XONG
Lý do thời gian sửa phụ thuộc bản chất sự cố
Khi làm bài ⚠ mọi phương án nói "đảm bảo GIẢI QUYẾT trong X" đều SAI
Premium còn có gì Quyền lợi
Technical Account Manager ⚠ hiểu sẵn kiến trúc, điều phối sự cố lớn
Rà soát kiến trúc và vận hành
Hỗ trợ chuẩn bị sự kiện lớn ⚠ đúng thứ công ty này cần trước đợt sale
Đào tạo và tín dụng học tập
Ưu tiên nâng cấp trong hàng đợi
⚠ Chi phí tính theo % chi tiêu, có mức sàn
⚠ Chuẩn bị TRƯỚC sự kiện lớn Việc
Báo cho TAM về đợt sale ⚠ Premium hỗ trợ event readiness
Xin nâng quota trước
Thử tải mô phỏng đỉnh
Cấp vai techSupportEditor ⚠ để đội mở được case P1
Có runbook và người trực

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đang ở gói nào | console — mục Support | | Ai được mở case P1 | ⚠ kiểm vai IAM TRƯỚC khi cần | | Gói có xứng với rủi ro không | so chi phí gói với thiệt hại mỗi giờ ngừng dịch vụ |

Và một phép tính rất đơn giản để quyết định gói hỗ trợ: so chi phí gói với thiệt hại của một giờ ngừng dịch vụ. Với công ty mất hàng nghìn đô mỗi phút, chênh lệch 45 phút giữa Enhanced và Premium đã đủ trả tiền gói Premium cho nhiều tháng.

Câu 178 Scaling with Google Cloud Operations

A development team's Google Cloud bill suddenly spikes from $2,000 to $15,000 per month. The team lead receives a budget alert notification but doesn't know which service, project, or resource is driving the unexpected cost increase.

What is the most effective first step to diagnose the root cause of this spending spike?

  1. A Ignore the alert, as projections are often inaccurate.
  2. B Use the Cloud Billing cost breakdown reports to see which services and projects are responsible for the spending.
  3. C Delete all resources in the project to stop further spending.
  4. D Contact Google Cloud support and ask for a refund.
Xem giải thích

Đáp án

B — Dùng báo cáo bóc tách chi phí của Cloud Billing để xem dịch vụ và project nào chịu trách nhiệm cho khoản chi tiêu đó.

Vì sao đúng

Đề hỏi bước ĐẦU TIÊN hiệu quả nhất để CHẨN ĐOÁN nguyên nhân gốc — và chẩn đoán thì phải bắt đầu bằng nhìn vào số liệu.

⚠ Quy trình chẩn đoán đúng:

Nhận cảnh báo ngân sách
        ↓
1. ⚠ MỞ BILLING REPORT
     → nhóm theo PROJECT
     → nhóm theo SERVICE
     → nhóm theo SKU
     → ⚠ so sánh tháng này với
       tháng trước
        ↓
2. Khoanh vùng: dịch vụ nào tăng
        ↓
3. Đi sâu: tài nguyên nào,
   ai tạo ra (audit log)
        ↓
4. Xử lý: tắt, chỉnh cỡ, hoặc
   chấp nhận nếu có lý do

⚠ Bốn chiều bóc tách quan trọng nhất:

⚠ THEO PROJECT
    → project nào tăng

⚠ THEO SERVICE
    → Compute? BigQuery? Networking?

⚠ THEO SKU
    → chi tiết nhất: loại máy nào,
      byte quét, egress...

⚠ THEO LABEL
    → đội nào, môi trường nào
    → ⚠ chỉ có nếu ĐÃ gắn nhãn

⚠ Vì sao ba phương án kia sai:

"BỎ QUA cảnh báo vì dự báo
 thường không chính xác"
    → ⚠ chi tiêu ĐÃ tăng thật
      từ 2.000 lên 15.000
    → không phải dự báo

"XOÁ HẾT tài nguyên trong project"
    → ⚠ PHÁ HUỶ hệ thống đang chạy
    → chưa biết nguyên nhân đã
      xử lý bằng cách nguy hiểm nhất

"LIÊN HỆ Google xin HOÀN TIỀN"
    → ⚠ chi phí phát sinh từ
      tài nguyên BẠN tạo ra
    → không phải lỗi của Google

Nhất quán với #13369 (lô 141) — câu đó về billing reports để xem và phân tích chi phí. Câu này là ứng dụng vào một tình huống chẩn đoán cụ thể. Cũng nhất quán với #13411 (lô 141, FinOps) về giai đoạn Inform.

Vì sao các phương án khác sai

  • C (xoá hết tài nguyên trong project để dừng chi tiêu) — phương án gần nhất về mặt "có hành động dứt khoát", nhưng cực kỳ nguy hiểm: nó phá huỷ hệ thống đang chạy trước khi biết nguyên nhân. Chẩn đoán phải đi trước xử lý.

  • A (bỏ qua cảnh báo) — chi phí đã tăng thật, không phải dự báo.

  • D (liên hệ Google xin hoàn tiền) — chi phí phát sinh từ tài nguyên bạn tạo ra; đây không phải lỗi tính tiền.

Ghi nhớ

⚠ Công cụ chi phí — dùng lúc nào: | Công cụ | Việc | |---|---| | ⚠ Billing reports | ⚠ CHẨN ĐOÁN — xem chi phí đã phát sinh | | Budget & alerts | CẢNH BÁO chủ động | | Billing export → BigQuery | ⚠ phân tích sâu bằng SQL | | Recommender | gợi ý cắt giảm | | Pricing Calculator | ước tính trước | | Quota | chặn cứng |

Từ khoá nhận diện:

"chi phí tăng, tìm nguyên nhân" → billing reports "báo cho tôi khi tới X%" → budget alert "phân tích theo nhãn bằng SQL" → billing export + BigQuery "không cho tạo quá N máy" → quota

⚠ Nguyên nhân chi phí tăng vọt thường gặp Nguyên nhân
Máy ảo lớn quên tắt ⚠ nhất là máy có GPU
BigQuery SELECT * trên bảng lớn ⚠ một truy vấn có thể rất đắt
Truy vấn chạy theo lịch bị lặp
⚠ Phí truyền dữ liệu ra (egress) hay bị quên nhất
Autoscaling không có max
Log giữ quá lâu
Môi trường thử nghiệm quên xoá
⚠ Đi sâu tới tài nguyên cụ thể Cách
Billing report → nhóm theo SKU biết loại chi phí
Billing export → BigQuery ⚠ truy vấn tới từng resource
Cloud Audit Logs ⚠ AI đã tạo tài nguyên đó, LÚC NÀO
Asset Inventory tài nguyên nào đang tồn tại
Kết hợp trả lời được "cái gì, của ai, từ bao giờ"
Sau khi chẩn đoán xong thì làm gì Việc
Tắt/xoá tài nguyên thừa ⚠ sau khi xác nhận với chủ sở hữu
Chỉnh cỡ máy Recommender
Đặt max-instances và quota chặn tái diễn
Bắt buộc gắn nhãn ⚠ để lần sau biết ngay của ai
Đặt hạn mức byte quét BigQuery
Xem lại ngân sách và ngưỡng
⚠ Phòng ngừa quan trọng hơn chữa cháy Việc
Nhãn bắt buộc trên mọi tài nguyên ⚠ điều kiện tiên quyết
Ngân sách cho từng project
Billing export bật sẵn ⚠ dữ liệu không hồi tố được
Xem Recommender hằng tháng
Quota cho môi trường thử nghiệm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dịch vụ nào tăng nhiều nhất | billing report, so hai tháng | | Ai tạo ra tài nguyên đó | ⚠ Cloud Audit Logs | | Có tài nguyên nào không nhãn không | ⚠ chính là chỗ khó truy nhất |

Và một lý do khiến bước gắn nhãn nên làm trước mọi thứ khác: không có nhãn thì báo cáo chi phí chỉ cho bạn biết "BigQuery tốn 8.000 đô", chứ không cho biết đội nào đã chạy truy vấn đó. Chẩn đoán dừng lại ở đó, và cuộc điều tra chuyển thành đi hỏi từng người.

Câu 179 Exploring Data Transformation with Google Cloud

A data analyst has written a complex SQL query in BigQuery to identify the top-selling products from the last quarter. They want to save and share this query with their team so that others can run it without having to rewrite it.

What BigQuery feature allows them to do this?

  1. A Exporting the query results to a CSV file.
  2. B Creating a saved query or a view.
  3. C Taking a screenshot of the query and emailing it.
  4. D Copying the query into a shared text document.
Xem giải thích

Đáp án

B — Tạo một saved query hoặc một view.

Vì sao đúng

BigQuery có sẵn hai cơ chế để lưu và chia sẻ truy vấn, và cả hai đều giải quyết đúng nhu cầu của đề.

⚠ Hai cách, hai mục đích hơi khác nhau:

SAVED QUERY
    → ⚠ lưu chính CÂU LỆNH SQL
    → chia sẻ cho đội hoặc
      toàn project
    → người khác mở ra, chạy,
      hoặc SỬA
    → ⚠ hợp khi truy vấn còn
      thay đổi, cần tuỳ biến

VIEW
    → ⚠ lưu truy vấn thành một
      ĐỐI TƯỢNG giống BẢNG
    → `SELECT * FROM ban_hang.top_sp`
    → ⚠ người dùng KHÔNG cần
      biết SQL bên trong
    → ⚠ hợp khi muốn CHUẨN HOÁ
      và tái dùng

⚠ Vì sao view thường tốt hơn cho việc chia sẻ:

Đội khác muốn dùng kết quả
        ↓
    Saved query
        → phải mở ra và chạy
        → ⚠ mỗi người có thể sửa
          thành phiên bản riêng
        ↓
    View
        → dùng như một bảng
        → ⚠ MỘT định nghĩa duy nhất
        → sửa view là mọi báo cáo
          đổi theo
        → ⚠ nối được vào Looker,
          Sheets, truy vấn khác

⚠ Vì sao ba phương án kia không phải giải pháp:

XUẤT KẾT QUẢ RA CSV
    → ⚠ chỉ là ẢNH CHỤP một thời điểm
    → ⚠ không chạy lại được
    → dữ liệu cũ ngay ngày hôm sau

CHỤP MÀN HÌNH rồi gửi email
    → ⚠ không chạy được

DÁN SQL vào tài liệu chia sẻ
    → ⚠ có thể dùng tạm nhưng:
      không có phiên bản,
      không phân quyền,
      dễ trôi thành nhiều bản khác nhau

Vì sao các phương án khác sai

  • D (dán truy vấn vào tài liệu chia sẻ) — phương án gần nhất về mặt "cũng chia sẻ được SQL", và nhiều đội thật sự làm vậy. Nhưng nó không có quản lý phiên bản, không có phân quyền, và nhanh chóng trôi thành nhiều bản khác nhau.

  • A (xuất kết quả ra CSV) — chỉ là ảnh chụp một thời điểm, không chạy lại được.

  • C (chụp màn hình rồi gửi email) — không dùng lại được ở bất kỳ nghĩa nào.

Ghi nhớ

⚠ Các cách tái dùng truy vấn trong BigQuery — bảng nên thuộc: | Cách | Đặc điểm | |---|---| | Saved query | lưu SQL, chia sẻ, người khác sửa được | | ⚠ View | ⚠ dùng như BẢNG, một định nghĩa duy nhất | | Materialized view | ⚠ kết quả được LƯU, tự cập nhật tăng dần | | Table function | view có THAM SỐ | | Stored procedure / UDF | logic phức tạp, tái dùng | | Scheduled query | ⚠ chạy định kỳ, ghi ra bảng |

Từ khoá nhận diện:

"lưu và chia sẻ truy vấn" → saved query hoặc view "dùng như bảng, không cần biết SQL" → ⚠ view "truy vấn nặng, chạy nhiều lần" → ⚠ materialized view "chạy hằng đêm ghi ra bảng" → scheduled query

⚠ View và Materialized view — khác nhau
View ⚠ chạy LẠI truy vấn mỗi lần gọi
luôn thấy dữ liệu mới nhất, không tốn lưu trữ
Materialized view ⚠ kết quả được LƯU SẴN
⚠ nhanh hơn và rẻ hơn nhiều nếu gọi thường xuyên
tự cập nhật tăng dần khi bảng gốc đổi
Chọn MV khi truy vấn nặng, gọi nhiều lần, dữ liệu ít đổi
⚠ Authorized view — chia sẻ an toàn Điểm
Vấn đề ⚠ người xem view thường cần quyền trên BẢNG GỐC
Giải ⚠ authorized view — cấp quyền cho VIEW, không cho bảng
Kết quả đội khác thấy kết quả nhưng KHÔNG thấy bảng nguồn
Hữu ích khi bảng gốc có cột nhạy cảm
Tương tự authorized dataset, authorized routine
Tổ chức view theo lớp Lớp
Raw bảng nguyên trạng
Staging view làm sạch
⚠ Mart ⚠ view đã mô hình hoá cho nghiệp vụ
Công cụ ⚠ Dataform quản chuỗi phụ thuộc và kiểm thử
Lợi ích một định nghĩa chỉ số dùng chung
⚠ Lưu ý về chi phí Điểm
View KHÔNG lưu dữ liệu không tốn phí lưu trữ
⚠ Nhưng mỗi lần gọi là một truy vấn tính tiền theo byte quét
View lồng nhiều tầng ⚠ có thể quét rất nhiều mà không ai để ý
Giảm bằng materialized view, phân vùng, gom cụm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | View quét bao nhiêu byte | ⚠ xem ước tính khi gọi | | Có ai cần quyền bảng gốc không | → dùng authorized view | | Truy vấn có nên thành materialized view không | nếu gọi nhiều lần mỗi ngày |

Và một lợi ích của view mà đề không nhắc tới nhưng quan trọng hơn cả việc chia sẻ: nó tạo ra một định nghĩa duy nhất cho một chỉ số. Khi cả đội cùng gọi top_selling_products thay vì mỗi người tự viết một câu SQL, các con số trong cuộc họp cuối cùng cũng khớp nhau.

Câu 180 Trust and Security with Google Cloud

A financial services company is deploying critical applications on Google Compute Engine virtual machines. The security team is reviewing the shared responsibility model to understand which security tasks Google handles versus which tasks the company must manage themselves. According to the shared responsibility model for Compute Engine (Infrastructure as a Service), which of the following is a security responsibility that Google handles?

  1. A Configuring firewall rules for the virtual machine.
  2. B Managing user access and IAM roles.
  3. C Securing the hypervisor and the physical network infrastructure.
  4. D Patching the guest operating system on a virtual machine.
Xem giải thích

Đáp án

C — Bảo mật hypervisor và hạ tầng mạng vật lý.

Vì sao đúng

Với IaaS (Compute Engine), ranh giới trách nhiệm nằm ngay phía trên tầng ảo hoá: từ hypervisor trở xuống là của Google.

⚠ Ranh giới với Compute Engine:

    ỨNG DỤNG              ← ⚠ BẠN
    DỮ LIỆU               ← ⚠ BẠN
    RUNTIME, THƯ VIỆN     ← ⚠ BẠN
    ⚠ HỆ ĐIỀU HÀNH KHÁCH  ← ⚠ BẠN
    ⚠ FIREWALL và IAM     ← ⚠ BẠN
  ────────── ranh giới ──────────
    ⚠ HYPERVISOR          ← Google
    ⚠ HỆ ĐIỀU HÀNH MÁY CHỦ ← Google
    ⚠ MẠNG VẬT LÝ         ← Google
    PHẦN CỨNG, TITAN      ← Google
    TRUNG TÂM DỮ LIỆU     ← Google

⚠ Ba phương án kia đều thuộc về KHÁCH HÀNG:

"CẤU HÌNH LUẬT TƯỜNG LỬA cho VM"
    → ⚠ VPC firewall là của BẠN
    → Google cung cấp công cụ,
      bạn quyết định luật

"QUẢN LÝ TRUY CẬP và VAI IAM"
    → ⚠ LUÔN là của bạn,
      ở MỌI mô hình dịch vụ

"VÁ HỆ ĐIỀU HÀNH KHÁCH trên VM"
    → ⚠ với IaaS là của BẠN
    → Google KHÔNG vào VM của bạn

⚠ Bẫy tinh vi: host OS và guest OS:

HOST OS
    → hệ điều hành chạy trên
      máy chủ VẬT LÝ của Google
    → ⚠ Google lo

GUEST OS
    → hệ điều hành TRONG máy ảo
      của bạn
    → ⚠ BẠN lo
        ↓
    ⚠ Chỉ khác một chữ nhưng
      đổi hoàn toàn trách nhiệm

Nhất quán với #13288 (lô 139), #13334 (lô 140), #13390 và #13395 (lô 141) — cả năm câu cùng về mô hình trách nhiệm chung, nhìn từ các góc khác nhau. Hoàn toàn nhất quán.

Vì sao các phương án khác sai

  • D (vá hệ điều hành khách trên VM) — phương án gần nhất và là bẫy chính vì chỉ khác một chữ: host OS là của Google, guest OS là của bạn. Với IaaS, bạn phải tự vá.

  • A (cấu hình luật tường lửa cho VM) — Google cung cấp VPC firewall, nhưng bạn quyết định luật.

  • B (quản lý truy cập và vai IAM) — ⚠ luôn là của khách hàng ở mọi mô hình.

Ghi nhớ

⚠ Trách nhiệm theo mô hình — bảng phải thuộc: | Tầng | IaaS | PaaS | SaaS | |---|---|---|---| | Dữ liệu, IAM | ⚠ BẠN | ⚠ BẠN | ⚠ BẠN — luôn luôn | | Ứng dụng | BẠN | BẠN | Google | | Runtime | BẠN | Google | Google | | ⚠ Hệ điều hành KHÁCH | ⚠ BẠN | Google | Google | | ⚠ Hypervisor, mạng vật lý, phần cứng | ⚠ Google | Google | Google |

Từ khoá nhận diện:

"hypervisor, mạng vật lý, phần cứng, trung tâm dữ liệu" → Google "guest OS, firewall rules, IAM, dữ liệu" → khách hàng "an ninh CỦA đám mây" → Google "an ninh TRONG đám mây" → khách hàng

⚠ Những gì LUÔN là của bạn Việc
Dữ liệu — phân loại, quyết định lưu gì
IAM và phân quyền ⚠ nguyên nhân số một của sự cố thật
Cấu hình dịch vụ bucket công khai, firewall mở
Mã ứng dụng
Tuân thủ pháp luật
Google lo gì ở tầng hạ tầng Việc
An ninh vật lý trung tâm dữ liệu nhiều lớp, sinh trắc học
⚠ Chip Titan và verified boot gốc tin cậy phần cứng
Hypervisor và cách ly giữa VM
⚠ Mạng xương sống và mã hoã khi truyền
Vá firmware và host OS
Huỷ ổ đĩa theo quy trình
Công cụ giúp bạn làm phần của mình Công cụ
VM Manager / OS Config ⚠ quản bản vá hàng loạt
OS Login quản SSH bằng IAM
Shielded VM verified boot trong VM
Security Command Center phát hiện cấu hình sai
IAM Recommender thu hẹp quyền
Organization Policy đặt lằn ranh cứng
⚠ Vì sao PaaS giảm gánh nặng Điểm
Không còn guest OS để vá
Không còn runtime để cập nhật
Bề mặt tấn công nhỏ hơn nhiều
Đánh đổi ít kiểm soát hơn
Với đội nhỏ ⚠ đây thường là lựa chọn AN TOÀN hơn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | VM đã vá tới đâu | ⚠ VM Manager — báo cáo tuân thủ | | Firewall có mở quá không | rà luật VPC | | Ai có quyền quá rộng | IAM Recommender |

Và một quan sát nhất quán qua mọi sự cố đám mây lớn từng được công bố: phần Google chịu trách nhiệm gần như không bao giờ là nguyên nhân. Bucket cấu hình sai, khoá lọt lên GitHub, máy ảo chưa vá suốt hai năm — tất cả đều nằm ở nửa còn lại của mô hình.