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

Tìm thấy 611 câu.

Câu 101 Modernize Infrastructure and Applications with Google Cloud

A development team's primary goal is to focus exclusively on writing application code and not spend any time managing servers, configuring operating systems, or worrying about scaling infrastructure.

Which computing model best aligns with this goal?

  1. A Serverless Computing
  2. B Infrastructure as a Service (IaaS)
  3. C On-premises
  4. D Physical Servers
Xem giải thích

Đáp án

A — Serverless Computing (điện toán serverless).

Vì sao đúng

Đề liệt kê đúng ba thứ mà serverless loại bỏ: quản máy chủ, cấu hình hệ điều hành, và lo chuyện mở rộng.

⚠ Ba yêu cầu ↔ serverless:

"KHÔNG quản máy chủ"
    → không có máy chủ nào để quản

"KHÔNG cấu hình hệ điều hành"
    → ⚠ nhà cung cấp lo hoàn toàn

"KHÔNG lo chuyện mở rộng hạ tầng"
    → ⚠ tự mở rộng theo tải,
      kể cả co về 0
        ↓
    → chỉ còn việc VIẾT MÃ

⚠ "Serverless" không có nghĩa là không có máy chủ:

Vẫn có máy chủ ở đâu đó
        ↓
    ⚠ Nhưng BẠN không thấy,
      không quản, không trả tiền
      cho lúc nó nhàn rỗi
        ↓
    ⚠ Đơn vị tính tiền không còn là
      "máy chủ mỗi giờ" mà là
      "request và thời gian chạy"

⚠ Bốn đặc điểm của serverless:

⚠ Không quản hạ tầng
⚠ Tự mở rộng theo tải
⚠ CO VỀ 0 khi rảnh
⚠ Trả tiền theo mức dùng thật

⚠ Gần trùng với #13274 (lô 139) — đề đó mô tả ứng dụng di động có lưu lượng thất thường, muốn tập trung viết mã và giảm chi phí lúc rảnh, và cùng khoá serverless. Hoàn toàn nhất quán.

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

  • B (IaaS) — phương án gần nhất về mặt "cũng là mô hình đám mây", nhưng với IaaS bạn nhận máy ảo trống và phải tự cài, tự vá hệ điều hành, tự cấu hình mở rộng — đúng ba việc đề nói họ không muốn làm.

  • C (on-premises) và D (máy chủ vật lý) — phải tự lo mọi thứ, kể cả phần cứng. Ngược hoàn toàn.

Ghi nhớ

⚠ Mức trách nhiệm theo mô hình — bảng phải thuộc: | Mô hình | Bạn quản | |---|---| | On-premises | ⚠ mọi thứ, kể cả phần cứng | | IaaS | hệ điều hành trở lên | | PaaS | mã và dữ liệu | | ⚠ Serverless | ⚠ CHỈ mã và dữ liệu, không lo mở rộng | | SaaS | không gì cả |

Từ khoá nhận diện:

"chỉ viết mã, không quản gì, không lo mở rộng" → serverless "cần kiểm soát hệ điều hành" → IaaS "co về 0" → serverless "tải ổn định 24/7 ở mức cao" → ⚠ VM + cam kết dài hạn có khi RẺ HƠN

Các dịch vụ serverless của Google Cloud Dịch vụ
Cloud Run ⚠ container serverless — mặc định nên chọn
Cloud Run Functions hàm theo sự kiện
App Engine Standard PaaS từ mã nguồn
BigQuery ⚠ kho dữ liệu serverless
Firestore CSDL serverless
Pub/Sub, Dataflow, Workflows đều serverless
Cloud Storage lưu trữ serverless
⚠ Đánh đổi của serverless Đánh đổi
Cold start ⚠ request đầu tiên chậm hơn
Giới hạn thời gian chạy không hợp cho tác vụ rất dài
Không trạng thái ⚠ phải để trạng thái ở kho ngoài
Ít kiểm soát môi trường không cấu hình kernel
Khoá chân nhiều hơn giảm bằng container và chuẩn mở
Khi nào serverless KHÔNG rẻ hơn Trường hợp
Tải ổn định, chạy liên tục ở mức cao ⚠ VM + CUD rẻ hơn
Cần GPU đặc thù
Tác vụ chạy nhiều giờ
Nguyên tắc ⚠ serverless thắng khi tải THẤT THƯỜNG
⚠ Điều kiện tiên quyết Điều kiện
Ứng dụng phải KHÔNG TRẠNG THÁI instance bị huỷ bất cứ lúc nào
Khởi động nhanh ảnh hưởng cold start
Ghi log ra stdout nền tảng thu thập
Xử lý được thông điệp trùng ⚠ idempotent
Đặt max-instances chặn chi phí

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chi phí lúc rảnh có bằng 0 không | billing report theo ngày | | Cold start ảnh hưởng bao nhiêu | đo p99 sau khoảng nghỉ | | Ứng dụng có thật sự không trạng thái không | ⚠ thử khởi động lại instance giữa chừng |

Và một điểm hay bị hiểu sai về serverless đáng nói rõ: nó không tự động rẻ hơn, nó rẻ hơn cho một hình dạng tải nhất định. Với lưu lượng thất thường hoặc thấp thì lợi ích rất lớn; với một dịch vụ chạy hết công suất 24 giờ mỗi ngày thì một máy ảo có cam kết dài hạn thường vẫn là lựa chọn kinh tế hơn.

Câu 102 Scaling with Google Cloud Operations

A company's finance team wants to proactively monitor and control their Google Cloud spending. They need to receive an email notification if their projected monthly spending is on track to exceed their allocated budget of $5,000, so they can take action before costs get out of control.

What is the simplest way to achieve this goal?

  1. A Write a custom Cloud Function to analyze billing data and send an email.
  2. B Review Google's transparency reports for cost information.
  3. C Manually check the Cloud Billing report every day.
  4. D Set a budget alert in Cloud Billing with a threshold and notification rule.
Xem giải thích

Đáp án

D — Đặt cảnh báo ngân sách trong Cloud Billing với ngưỡng và quy tắc thông báo.

Vì sao đúng

Đề đòi ba thứ, và Budget alert cho cả ba một cách sẵn có:

⚠ Ba yêu cầu ↔ budget alert:

1. "GIÁM SÁT CHỦ ĐỘNG"
     → cảnh báo tự bắn, không phải
       ngồi chờ ai đó mở báo cáo

2. ⚠ "CHI TIÊU DỰ BÁO sẽ vượt
    ngân sách 5.000 USD"
     → ⚠ cảnh báo theo chi phí
       DỰ BÁO, không chỉ thực tế

3. "ĐƠN GIẢN NHẤT"
     → cấu hình bằng giao diện,
       không viết mã

⚠ Cảnh báo theo dự báo — điểm mấu chốt của đề:

Chi phí THỰC TẾ đạt 90%
    → biết khi đã gần hết tiền

⚠ Chi phí DỰ BÁO đạt 100%
    → Google nhìn ĐÀ TIÊU hiện tại
      và chiếu tới cuối tháng
        ↓
    ⚠ Báo NGAY TỪ GIỮA THÁNG
      rằng đà này sẽ vượt ngân sách
        ↓
    → đúng chữ "proactively" và
      "on track to exceed" của đề

⚠ Vì sao ba phương án kia kém hơn:

VIẾT CLOUD FUNCTION RIÊNG
    → ⚠ dựng lại thứ đã có sẵn
    → thêm mã phải bảo trì
    → ⚠ script chết thì mất cảnh báo

XEM BÁO CÁO THỦ CÔNG MỖI NGÀY
    → ⚠ BỊ ĐỘNG, tốn người
    → nghỉ phép là không ai xem

ĐỌC BÁO CÁO MINH BẠCH
    → ⚠ tài liệu về yêu cầu dữ liệu
      từ chính phủ
    → KHÔNG có thông tin chi phí

⚠ Gần trùng với #13255 (lô 138) — đề đó cũng là bộ phận tài chính muốn được báo ở các mốc phần trăm, và cùng khoá budget alert. Nhất quán.

⚠ Đối chiếu #13294 (lô 139) — đề đó khoá Resource Quota vì yêu cầu là CHẶN CỨNG số lượng tài nguyên. Câu này chỉ đòi CẢNH BÁO. Hai câu không mâu thuẫn — khác nhau ở chỗ "báo cho tôi" hay "không cho phép".

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

  • A (viết Cloud Function riêng) — phương án gần nhất về mặt kỹ thuật và làm được, nhưng vi phạm yêu cầu "đơn giản nhất": bạn tự dựng lại tính năng đã có sẵn, miễn phí, và phải bảo trì nó mãi.

  • C (xem báo cáo thủ công mỗi ngày) — bị động, tốn nhân lực, và dễ bỏ sót.

  • B (đọc báo cáo minh bạch của Google) — tài liệu về việc Google xử lý yêu cầu dữ liệu từ cơ quan chính phủ, không liên quan tới chi phí.

Ghi nhớ

⚠ Công cụ quản chi phí — bảng phải thuộc: | Công cụ | Tác dụng | |---|---| | Budget & alerts | ⚠ CẢNH BÁO chủ động theo ngưỡng %, thực tế hoặc dự báo | | Billing reports | xem và phân tích — bị động | | Billing export → BigQuery | phân tích sâu bằng SQL | | ⚠ Quotas | ⚠ CHẶN CỨNG số lượng tài nguyên | | Recommender | gợi ý cắt giảm | | Labels | quy chi phí về đội |

Từ khoá nhận diện:

"báo cho tôi khi tiêu tới X%" → budget alert "không cho tạo quá N tài nguyên" → ⚠ quota "phân tích chi phí theo nhãn" → billing export + BigQuery "cấm hành vi ở mọi project" → Organization Policy

⚠ Ba hiểu lầm về budget alert Sự thật
"Đạt ngân sách thì dịch vụ tự dừng" ⚠ SAI — chỉ gửi cảnh báo
"Chỉ cảnh báo được ở 100%" đặt bao nhiêu ngưỡng cũng được
"Chỉ theo chi phí thực tế" ⚠ CÓ cả cảnh báo theo DỰ BÁO
Phạm vi đặt ngân sách Phạm vi
Toàn tài khoản thanh toán tổng quan
Theo project hay dùng nhất
Theo dịch vụ ví dụ chỉ theo dõi BigQuery
Theo nhãn ⚠ theo đội hoặc môi trường
Theo folder theo phòng ban
Kênh nhận thông báo Kênh
Email tới người quản lý thanh toán mặc định
Cloud Monitoring channel Slack, PagerDuty
Pub/Sub ⚠ để tự động hoá phản ứng
⚠ Muốn chặn chi tiêu thật sự Cách
Budget alert → Pub/Sub → Cloud Function
Function gỡ liên kết tài khoản thanh toán
Hậu quả ⚠ MỌI dịch vụ trong project DỪNG
Dùng cho môi trường học tập, thử nghiệm
⚠ KHÔNG dùng cho production
Việc nên làm định kỳ để kiểm soát chi phí Việc
Gắn nhãn mọi tài nguyên ⚠ để biết chi phí của ai
Xem Recommender hằng tháng
Đặt hạn mức byte quét cho BigQuery
Tắt máy dev ngoài giờ
Mua CUD cho tải ổn định

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cảnh báo có tới đúng người không | ⚠ thử hạ ngưỡng xuống rất thấp | | Tiền đi đâu nhiều nhất | billing report theo dịch vụ và SKU | | Có tài nguyên nằm không nào | Recommender — Idle resources |

Và một thói quen nên thành quy định nội bộ: tạo ngân sách và gắn nhãn cho mọi project mới ngay khi tạo. Chi phí đám mây hiếm khi tăng vọt vì một quyết định lớn — nó bò lên từ những tài nguyên nhỏ không ai nhận là của mình, và nhãn là thứ duy nhất trả lời được câu hỏi đó sau ba tháng.

Câu 103 Trust and Security with Google Cloud
An organization wants to protect its web application, hosted on Google Cloud, from common web attacks like SQL injection and Distributed Denial-of-Service (DDoS) attacks. Which Google Cloud security product is designed for this purpose?
  1. A Cloud Key Management Service (KMS)
  2. B Cloud IAM
  3. C Security Command Center
  4. D Cloud Armor
Xem giải thích

Đáp án

D — Cloud Armor.

Vì sao đúng

Đề nêu hai loại tấn công, và Cloud Armor là sản phẩm duy nhất trong danh sách xử lý cả hai:

⚠ Hai mối đe doạ ↔ Cloud Armor:

1. SQL INJECTION
     → ⚠ tấn công TẦNG 7 (ứng dụng)
     → ⚠ Cloud Armor có luật WAF
       dựng sẵn theo OWASP Top 10

2. DDoS
     → ⚠ tấn công TẦNG 3/4 (mạng)
     → ⚠ hạ tầng biên của Google
       hấp thụ, Cloud Armor lọc thêm

⚠ Cloud Armor đứng ở đâu:

    Người dùng + kẻ tấn công
            ↓
    Mạng biên toàn cầu của Google
            ↓
    ⚠ CLOUD ARMOR  ← lọc TẠI ĐÂY
       ├── luật WAF (SQLi, XSS)
       ├── chặn theo IP và quốc gia
       ├── rate limiting
       └── Adaptive Protection
            ↓
    Cloud Load Balancing
            ↓
    Ứng dụng web
        ↓
    ⚠ Lưu lượng xấu bị chặn từ BIÊN,
      chưa hề chạm tới máy chủ

⚠ Vì sao ba phương án kia không chặn được:

CLOUD KMS
    → quản lý KHOÁ MÃ HOÁ
    → không liên quan tới lưu lượng

CLOUD IAM
    → ⚠ ai được truy cập tài nguyên
    → kẻ tấn công DDoS KHÔNG cần
      đăng nhập

SECURITY COMMAND CENTER
    → ⚠ PHÁT HIỆN cấu hình sai và
      rủi ro trong môi trường CỦA BẠN
    → là bảng điều khiển quan sát,
      ⚠ KHÔNG chặn lưu lượng

⚠ Gần trùng với #13246 (lô 138) — đề đó là công ty game lo bị tấn công DDoS, và cùng khoá Cloud Armor. Hoàn toàn nhất quán. Câu này nêu thêm SQL injection, tức là cả vế WAF của sản phẩm.

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

  • C (Security Command Center) — phương án gần nhất và bị nhầm nhiều: nó thật sự là sản phẩm bảo mật quan trọng, nhưng vai trò là phát hiện và báo cáo rủi ro (bucket công khai, VM có lỗ hổng, quyền quá rộng). Nó không đứng chặn lưu lượng vào.

  • B (Cloud IAM) — kiểm soát danh tính đã xác thực; tấn công web đến từ người dùng ẩn danh trên Internet.

  • A (Cloud KMS) — quản lý khoá mã hoá, không liên quan.

Ghi nhớ

⚠ Sản phẩm bảo mật Google Cloud — bảng phải thuộc: | Sản phẩm | Vai trò | |---|---| | Cloud Armor | ⚠ CHẶN ở biên — DDoS và WAF | | Security Command Center | ⚠ PHÁT HIỆN rủi ro trong môi trường của bạn | | Cloud IAM | ai được làm gì | | Cloud KMS | khoá mã hoá | | VPC Service Controls | vành đai chống rò rỉ dữ liệu | | Identity-Aware Proxy | kiểm soát truy cập ứng dụng theo danh tính | | Cloud Audit Logs | ai đã làm gì |

Từ khoá nhận diện:

"DDoS, SQL injection, XSS, WAF" → Cloud Armor "phát hiện bucket công khai, quyền quá rộng" → Security Command Center "chặn dữ liệu chảy ra ngoài" → VPC Service Controls "ai được truy cập" → IAM

Cloud Armor làm được gì Khả năng
Chống DDoS tầng 3/4 ⚠ tự động cùng hạ tầng biên
WAF tầng 7 luật OWASP Top 10 dựng sẵn
Chặn/cho theo IP và CIDR
Lọc theo QUỐC GIA
Rate limiting giới hạn request mỗi IP
Adaptive Protection ⚠ học đường nền, phát hiện bất thường bằng ML
⚠ Chế độ preview thử luật mà chưa chặn thật
Bot Management phân biệt người và bot
⚠ OWASP Top 10 — các luật dựng sẵn Loại
SQL injection (SQLi) ⚠ đề này
Cross-site scripting (XSS)
Local/Remote file inclusion
Remote code execution
Protocol attack
Scanner detection
Vì sao chặn ở BIÊN mới hiệu quả Lý do
Lưu lượng bị chặn trước khi vào VPC
Không tốn tài nguyên máy chủ để lọc
Mạng biên Google rất lớn hấp thụ được đợt tấn công khổng lồ
⚠ Ngược lại lọc bằng tường lửa trên máy chủ = máy chủ vẫn gục
Bảo mật nhiều lớp — Cloud Armor chỉ là một Lớp
Biên Cloud Armor
Mạng VPC firewall, Private Service Connect
Danh tính IAM, IAP
Ứng dụng ⚠ vẫn phải viết mã an toàn — truy vấn tham số hoá
Dữ liệu CMEK, policy tag
Giám sát Security Command Center, Audit Logs

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Luật có chặn nhầm người thật không | ⚠ chạy preview và đọc log vài ngày | | Đang bị tấn công kiểu gì | bảng Cloud Armor trong console | | Backend có chịu nổi không | thử tải trước mùa cao điểm |

Và một điều Cloud Armor không thay thế được: viết mã an toàn. Luật WAF chặn được phần lớn mẫu tấn công đã biết, nhưng lớp phòng thủ thật sự cho SQL injection vẫn là truy vấn tham số hoá trong chính ứng dụng — WAF là lưới an toàn, không phải bức tường duy nhất.

Câu 104 Trust and Security with Google Cloud

A financial services company stores customer account information, transaction records, and personal identification documents in Google Cloud. They must ensure this sensitive data is protected from unauthorized employees, external attackers, and accidental exposure. In cloud security's CIA triad (Confidentiality, Integrity, Availability), what does "confidentiality" ensure?

  1. A That data is accurate and has not been improperly modified.
  2. B That data and services are available and accessible when needed.
  3. C That all actions performed by users are logged for review.
  4. D That data is protected from unauthorized access or disclosure.
Xem giải thích

Đáp án

D — Rằng dữ liệu được bảo vệ khỏi truy cập hoặc tiết lộ trái phép.

Vì sao đúng

Confidentiality (bảo mật) là trụ cột trả lời câu hỏi: ai được nhìn thấy dữ liệu này?

⚠ Ba trụ cột và ba định nghĩa:

CONFIDENTIALITY (bảo mật)
    → ⚠ chỉ ĐÚNG NGƯỜI được xem
    → chống truy cập và tiết lộ trái phép
    → ⚠ đề này

INTEGRITY (toàn vẹn)
    → dữ liệu CHÍNH XÁC,
      không bị sửa đổi trái phép
    → ⚠ chính là phương án A

AVAILABILITY (sẵn sàng)
    → dữ liệu và dịch vụ DÙNG ĐƯỢC
      khi cần
    → ⚠ chính là phương án B

⚠ Ba mối đe doạ trong đề, ba lớp bảo vệ:

"NHÂN VIÊN không có thẩm quyền"
    → ⚠ IAM quyền tối thiểu
    → policy tag cho cột nhạy cảm
    → audit log

"KẺ TẤN CÔNG bên ngoài"
    → ⚠ Cloud Armor, VPC Service Controls
    → mã hoá, MFA

"LỘ LỌT DO SƠ SUẤT"
    → ⚠ Organization Policy cấm
      bucket công khai
    → Security Command Center
    → Sensitive Data Protection

⚠ Vì sao phương án C (ghi log) không phải confidentiality:

Ghi log mọi hành động
        ↓
    ⚠ Đó là AUDITING
    → phát hiện SAU khi việc đã xảy ra
        ↓
    ⚠ Nó HỖ TRỢ cả ba trụ cột
      nhưng KHÔNG PHẢI định nghĩa
      của bất kỳ trụ cột nào

Bổ sung cho #13286 (lô 139) — câu đó hỏi tên của bộ ba (CIA); câu này hỏi định nghĩa của một trụ cột. Hai câu nhất quán và ghép thành hiểu biết đầy đủ.

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

  • A (dữ liệu chính xác, không bị sửa đổi sai) — phương án gần nhất, nhưng đây là định nghĩa của Integrity, trụ cột thứ hai.

  • B (dữ liệu và dịch vụ dùng được khi cần) — định nghĩa của Availability.

  • C (mọi hành động của người dùng được ghi log) — đó là Auditing, một cơ chế hỗ trợ chứ không phải một trụ cột của CIA.

Ghi nhớ

⚠ Bộ ba CIA — bảng phải thuộc: | Trụ cột | Đảm bảo | Bị phá khi | |---|---|---| | Confidentiality | ⚠ chỉ đúng người xem được | rò rỉ dữ liệu | | Integrity | dữ liệu chính xác, không bị sửa trộm | sửa đổi trái phép, ransomware | | Availability | dùng được khi cần | ⚠ DDoS, sự cố hạ tầng |

Từ khoá nhận diện:

"bảo vệ khỏi truy cập trái phép" → Confidentiality "dữ liệu không bị sửa" → Integrity "dịch vụ luôn dùng được" → Availability "ghi lại ai làm gì" → ⚠ Auditing — không phải trụ cột CIA

Công cụ cho Confidentiality trên Google Cloud Công cụ
IAM quyền tối thiểu ⚠ lớp quan trọng nhất
Mã hoá khi lưu và khi truyền mặc định
CMEK / Cloud KMS khoá tự quản
Policy tag ⚠ bảo mật mức CỘT trong BigQuery
Row access policy mức dòng
VPC Service Controls vành đai chống rò rỉ
Sensitive Data Protection ⚠ tìm và che PII
Confidential Computing bảo vệ cả lúc CPU xử lý
⚠ Ba nguyên nhân rò rỉ dữ liệu thực tế Nguyên nhân
Cấu hình sai ⚠ bucket để công khai — phổ biến nhất
Quyền quá rộng Editor cho cả công ty
Khoá lọt vào kho mã nguồn
Điểm chung ⚠ thuộc NỬA TRÁCH NHIỆM CỦA KHÁCH HÀNG
Bảo vệ khỏi "nhân viên không thẩm quyền" Biện pháp
Cấp quyền theo NHÓM, quyền tối thiểu
Policy tag cho cột chứa PII ⚠ che ngay ở tầng dữ liệu
Bật Data Access audit log biết ai đã đọc gì
IAM Recommender thu hẹp quyền không dùng tới
Tách môi trường dev và prod
Rà soát quyền định kỳ
Ba trụ cột thường xung đột nhau Xung đột
Siết Confidentiality tối đa ⚠ Availability giảm — người thật cũng bị chặn
Tối đa Availability ⚠ nhiều bản sao hơn để rò rỉ
Kết luận an toàn thông tin là nghệ thuật CÂN BẰNG
Cách quyết ngành nào ưu tiên trụ cột nào

Ba câu hỏi kiểm chứng: | Câu hỏi | Trụ cột | |---|---| | Ai đọc được dữ liệu này? | Confidentiality | | Làm sao biết nó chưa bị sửa? | Integrity | | Mất bao lâu để phục hồi? | Availability |

Và một phép thử rất đơn giản cho trụ cột Confidentiality mà ít tổ chức làm thường xuyên: liệt kê tất cả những người thật sự có thể đọc dữ liệu nhạy cảm nhất của bạn. Con số đó gần như luôn lớn hơn nhiều so với dự đoán, vì quyền được cấp thì hay được nhớ còn quyền cần gỡ thì thường bị quên.

Câu 105 Modernize Infrastructure and Applications with Google Cloud
A retail company wants to securely share its product catalog data with its business partners to create new B2B opportunities. They need a robust, scalable, and secure way to create, manage, and publish their APIs. Which Google Cloud service is designed for this purpose?
  1. A

    Cloud Run Functions
  2. B Cloud Load Balancing
  3. C Cloud CDN
  4. D Apigee API Management
Xem giải thích

Đáp án

D — Apigee API Management.

Vì sao đúng

Đề nêu bốn yêu cầu, và tất cả đều là năng lực của một nền tảng quản lý API trọn vòng đời:

⚠ Bốn yêu cầu ↔ Apigee:

1. "CHIA SẺ AN TOÀN dữ liệu danh mục
    sản phẩm cho ĐỐI TÁC"
     → xác thực, phân quyền theo đối tác

2. "TẠO CƠ HỘI KINH DOANH B2B MỚI"
     → ⚠ API như một SẢN PHẨM

3. "MẠNH MẼ, MỞ RỘNG ĐƯỢC, AN TOÀN"
     → chính sách bảo mật, rate limit

4. ⚠ "TẠO, QUẢN LÝ và CÔNG BỐ API"
     → ⚠ ba động từ này chính là
       "full lifecycle API management"

⚠ Vòng đời API mà Apigee bao phủ:

THIẾT KẾ  → đặc tả OpenAPI
    ↓
BẢO MẬT   → OAuth, API key, JWT
    ↓
TRIỂN KHAI→ proxy trước backend
    ↓
⚠ CÔNG BỐ → cổng lập trình viên,
             đối tác TỰ đăng ký
    ↓
THEO DÕI  → phân tích theo đối tác
    ↓
KIẾM TIỀN → gói giá, hoá đơn
    ↓
NGỪNG     → quản phiên bản, thông báo

⚠ Vì sao đối tác B2B cần cổng lập trình viên:

Không có cổng
        ↓
    ⚠ Mỗi đối tác phải email hỏi
      tài liệu, xin khoá
    ⚠ Đội bạn thành bộ phận
      hỗ trợ thủ công
        ↓
Có cổng lập trình viên
        ↓
    ⚠ Đối tác tự đọc tài liệu,
      tự đăng ký, tự lấy khoá,
      tự thử trong sandbox
        ↓
    → mở rộng ra hàng trăm đối tác
      mà không tăng nhân sự

⚠ Gần trùng với #13269 và #13304 (lô 139) — cả ba đề đều là mở dịch vụ nội bộ ra cho đối tác bên ngoài với hạn ngạch và phân tích, và cả ba cùng khoá Apigee. Hoàn toàn nhất quán. Mẫu đề lặp: đối tác + API là sản phẩm + quản trọn vòng đời → luôn là Apigee.

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

  • B (Cloud Load Balancing) — phương án gần nhất về mặt "cũng đứng trước backend", nhưng nó chỉ phân phối lưu lượng: không xác thực đối tác, không hạn ngạch theo khách hàng, không cổng lập trình viên, không phân tích thương mại.

  • C (Cloud CDN) — đệm nội dung tĩnh ở biên để giảm độ trễ. Không quản lý API.

  • A (Cloud Run Functions) — nơi chạy mã, là backend đứng sau lớp quản lý API.

Ghi nhớ

⚠ Ba lựa chọn quản lý API — bảng phải thuộc: | Sản phẩm | Dùng khi | |---|---| | Apigee | ⚠ API là SẢN PHẨM — đối tác ngoài, kiếm tiền, cổng lập trình viên | | API Gateway | API serverless nhẹ cho Cloud Run / Functions | | Cloud Endpoints | API nội bộ, nhẹ | | Load Balancing | chỉ chia lưu lượng | | Cloud CDN | đệm nội dung tĩnh |

Từ khoá nhận diện:

"đối tác, B2B, công bố API, kiếm tiền, phân tích" → Apigee "API nội bộ đơn giản" → API Gateway / Endpoints "chống DDoS và WAF" → Cloud Armor "đệm ảnh và CSS ở biên" → Cloud CDN

Năng lực riêng của Apigee Năng lực
Developer portal ⚠ tài liệu, tự đăng ký, sandbox
API product gói nhiều API thành sản phẩm
Monetization ⚠ tính phí theo lượt gọi hoặc theo gói
Chính sách không cần code xác thực, biến đổi, cache
Analytics theo đối tác, API, mã lỗi
Quản lý phiên bản v1 và v2 song song
Advanced API Security phát hiện lạm dụng và bot
⚠ Ba mô hình chia sẻ API Mô hình
Private / nội bộ giữa các đội trong công ty
⚠ Partner đối tác được chọn — đề này
Public ai đăng ký cũng dùng được
Khác nhau ở cách xác thực, hạn ngạch và hợp đồng
Bảo mật cho API đối tác Biện pháp
API key định danh ứng dụng
OAuth 2.0 ⚠ phân quyền theo phạm vi (scope)
mTLS xác thực hai chiều cho đối tác quan trọng
Rate limit và quota bảo vệ backend
Kiểm tra mối đe doạ chặn payload độc hại
Ghi log và cảnh báo
Thiết kế API tốt cho B2B Việc
Tài liệu OpenAPI đầy đủ ⚠ đối tác đánh giá bạn qua tài liệu
Sandbox có dữ liệu mẫu
Đánh phiên bản rõ ràng /v1/, /v2/
Chính sách ngừng hỗ trợ có báo trước ⚠ đối tác cần thời gian sửa
Mã lỗi nhất quán, dễ hiểu
SLA rõ ràng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đối tác mất bao lâu để gọi thành công lần đầu | ⚠ thước đo tốt nhất của trải nghiệm | | Ai dùng nhiều nhất | Apigee analytics | | Backend chịu nổi không | đặt rate limit TRƯỚC khi mở |

Và một cách nghĩ giúp chọn đúng công cụ trong mọi câu hỏi kiểu này: khi đề nhắc tới đối tác, hợp đồng, gói dịch vụ hay doanh thu, câu trả lời đã rời khỏi địa hạt hạ tầng. Load balancer và CDN giải bài toán kỹ thuật; Apigee giải bài toán thương mại của việc biến API thành sản phẩm.

Câu 106 Modernize Infrastructure and Applications with Google Cloud

A junior developer asks a senior engineer: "I keep hearing about containers and virtual machines in our deployment discussions. I understand they're both used to run applications in isolated environments, but what's the fundamental technical difference between how a container works versus how a VM works?"

  1. A Containers run on physical hardware, while VMs run on top of an operating system.
  2. B Containers are less portable than VMs.
  3. C VMs virtualize the hardware, while containers virtualize the operating system.
  4. D VMs always start up faster than containers.
Xem giải thích

Đáp án

C — Máy ảo ảo hoá PHẦN CỨNG, còn container ảo hoá HỆ ĐIỀU HÀNH.

Vì sao đúng

Đây là khác biệt kỹ thuật nền tảng giữa hai công nghệ, và mọi khác biệt khác (kích thước, tốc độ khởi động, mức cách ly) đều bắt nguồn từ nó.

⚠ Hai tầng ảo hoá:

        MÁY ẢO                 CONTAINER
   ┌──────────────┐       ┌──────────────┐
   │  Ứng dụng    │       │  Ứng dụng    │
   │  Thư viện    │       │  Thư viện    │
   │ ⚠ OS KHÁCH   │       └──────────────┘
   │  (cả nhân)   │        Container runtime
   └──────────────┘       ┌──────────────┐
   ⚠ HYPERVISOR           │ ⚠ OS CHỦ     │
    (ảo hoá phần cứng)    │  (dùng CHUNG │
   ┌──────────────┐       │   NHÂN)      │
   │  OS máy chủ  │       └──────────────┘
   └──────────────┘         Phần cứng
     Phần cứng

⚠ Hệ quả trực tiếp của khác biệt này:

VM mang theo CẢ MỘT HỆ ĐIỀU HÀNH
        ↓
    ⚠ nặng hàng GB
    ⚠ khởi động mất PHÚT
    ⚠ cách ly MẠNH (ranh giới phần cứng ảo)
    ⚠ chạy được OS KHÁC hệ chủ
      (Windows trên Linux)

CONTAINER dùng CHUNG NHÂN với hệ chủ
        ↓
    ⚠ nhẹ hàng MB
    ⚠ khởi động trong GIÂY
    ⚠ cách ly ở mức TIẾN TRÌNH
    ⚠ ⚠ PHẢI cùng hệ nhân với hệ chủ

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

"Container chạy trên PHẦN CỨNG,
 VM chạy trên HỆ ĐIỀU HÀNH"
    → ⚠ đảo ngược hoàn toàn

"Container KÉM DI ĐỘNG hơn VM"
    → ⚠ ngược lại: container là
      công nghệ di động NHẤT

"VM LUÔN khởi động nhanh hơn container"
    → ⚠ ngược lại hoàn toàn

Bổ sung cho #13290 (lô 139) — câu đó hỏi công nghệ nào đóng gói ứng dụng cùng phụ thuộc (container); câu này hỏi khác biệt kỹ thuật với VM. Hai câu nhất quán.

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

  • A (container chạy trên phần cứng, VM chạy trên hệ điều hành) — phương án gần nhất về mặt "cũng nói về hai tầng", nhưng đảo ngược: hypervisor của VM nằm gần phần cứng hơn, còn container chạy trên hệ điều hành chủ.

  • B (container kém di động hơn VM) — sai: khả năng chạy nhất quán ở mọi nơi là ưu điểm lớn nhất của container.

  • D (VM luôn khởi động nhanh hơn container) — sai: VM mất vài phút, container mất vài giây.

Ghi nhớ

⚠ VM và container — bảng phải thuộc: | | Máy ảo | Container | |---|---|---| | Ảo hoá | ⚠ PHẦN CỨNG | ⚠ HỆ ĐIỀU HÀNH | | Mang theo | cả một OS khách | chỉ ứng dụng + thư viện | | Kích thước | GB | MB | | Khởi động | ⚠ phút | ⚠ giây | | Cách ly | ⚠ mạnh hơn | mức tiến trình | | Nhân OS | riêng | ⚠ DÙNG CHUNG với hệ chủ | | Chạy OS khác hệ chủ | ⚠ được | ⚠ KHÔNG |

Từ khoá nhận diện:

"ảo hoá phần cứng, hypervisor" → VM "ảo hoá hệ điều hành, chung nhân" → container "nhẹ, khởi động nhanh, di động" → container "cách ly mạnh, chạy Windows trên Linux" → VM

⚠ Khi nào VM vẫn tốt hơn Trường hợp
Cần cách ly MẠNH ⚠ nhiều khách hàng khác nhau chung hạ tầng
Cần OS khác hệ chủ Windows trên nền Linux
Cần quyền kernel, driver đặc thù
Phần mềm cũ không container hoá được
Giấy phép ràng buộc phần cứng sole-tenant node
Khi nào container tốt hơn Trường hợp
Microservices ⚠ hàng chục thành phần nhỏ
CI/CD nhanh build và triển khai trong giây
Mật độ cao hàng trăm container trên một máy
Nhất quán giữa các môi trường ⚠ xoá bỏ "trên máy tôi chạy được"
Mở rộng nhanh
⚠ Hai công nghệ thường dùng CÙNG NHAU Cách
Container chạy TRÊN máy ảo ⚠ đó chính là cách GKE hoạt động
Node của GKE là máy ảo Compute Engine
Pod là container chạy trên node đó
Kết quả có cả cách ly của VM và tính nhẹ của container
Cách ly của container có thể tăng cường Cách
gVisor / GKE Sandbox ⚠ thêm một lớp nhân người dùng
Confidential GKE Nodes mã hoá bộ nhớ
⚠ Đừng chạy container bằng root
Đặt seccomp và AppArmor
Namespace và network policy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ứng dụng có container hoá được không | ⚠ kiểm phụ thuộc hệ điều hành | | Image có quá lớn không | so với base image tối thiểu | | Có chạy bằng root không | kiểm USER trong Dockerfile |

Và một hệ quả của việc container dùng chung nhân mà nhiều người mới học bỏ qua: container Linux không chạy được trên nhân Windows và ngược lại. Docker trên máy Windows thật ra đang chạy một máy ảo Linux ẩn phía sau — và điều đó giải thích vì sao container "nhẹ" trên laptop của bạn lại không nhẹ như trên máy chủ Linux thật.

Câu 107 Modernize Infrastructure and Applications with Google Cloud
A development team wants to deploy a complex, containerized application. They need a managed environment that handles the orchestration, scaling, and management of their containers using the industry-standard open-source system. Which Google Cloud service is designed for this purpose?
  1. A Compute Engine
  2. B Google Kubernetes Engine (GKE)
  3. C Cloud Storage
  4. D

    Cloud Run Functions
Xem giải thích

Đáp án

B — Google Kubernetes Engine (GKE).

Vì sao đúng

Đề nêu bốn yêu cầu, và cụm quyết định là "hệ thống mã nguồn mở tiêu chuẩn của ngành":

⚠ Bốn yêu cầu ↔ GKE:

1. "ỨNG DỤNG PHỨC TẠP, ĐÓNG GÓI
    TRONG CONTAINER"
     → cần điều phối thật sự

2. "MÔI TRƯỜNG CÓ QUẢN LÝ"
     → Google lo control plane

3. "ĐIỀU PHỐI, MỞ RỘNG, QUẢN LÝ
    container"
     → Deployment, HPA, self-healing

4. ⚠ "HỆ THỐNG MÃ NGUỒN MỞ
    TIÊU CHUẨN CỦA NGÀNH"
     → ⚠ đây chính là KUBERNETES

⚠ Vì sao Kubernetes là "chuẩn của ngành":

Do Google tạo ra rồi MỞ MÃ NGUỒN
        ↓
    Nay do CNCF quản lý
        ↓
    ⚠ Chạy trên MỌI đám mây:
      GKE, EKS, AKS, và tại chỗ
        ↓
    ⚠ Cùng một tệp YAML,
      cùng một kỹ năng của đội
        ↓
    → giảm rủi ro khoá chân
      nhà cung cấp

⚠ GKE cho gì hơn Kubernetes tự dựng:

Tự dựng Kubernetes
    → ⚠ tự vận hành control plane
    → tự vá, tự nâng cấp, tự sao lưu etcd
        ↓
GKE
    → ⚠ Google quản control plane
    → tự nâng cấp, tự vá
    → tích hợp sẵn IAM, VPC,
      Cloud Logging, Load Balancer
    → ⚠ Autopilot: quản cả node

⚠ Gần trùng với #13326 (cùng lô này) và #13248 (lô 138) — cả ba đề đều nói về điều phối container quy mô lớn, và cả ba cùng khoá GKE. Hoàn toàn nhất quán. Mẫu đề lặp: container + điều phối + chuẩn mã nguồn mở → luôn là GKE.

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

  • A (Compute Engine) — phương án gần nhất nếu hiểu "môi trường có quản lý" một cách lỏng lẻo, nhưng nó chỉ cung cấp máy ảo trống; bạn sẽ phải tự cài và tự vận hành Kubernetes trên đó.

  • D (Cloud Run Functions) — dành cho hàm nhỏ theo sự kiện, không điều phối container.

  • C (Cloud Storage) — lưu tệp, không chạy gì cả.

Ghi nhớ

⚠ Chọn nền tảng container — bảng phải thuộc: | Nhu cầu | Chọn | |---|---| | ⚠ Nhiều container phụ thuộc nhau, cần điều phối | ⚠ GKE | | Một dịch vụ container, co về 0 | Cloud Run | | Hàm theo sự kiện | Cloud Run Functions | | Cần kiểm soát OS | Compute Engine |

Từ khoá nhận diện:

"Kubernetes, chuẩn mã nguồn mở, điều phối cụm" → GKE "một dịch vụ, serverless, co về 0" → Cloud Run "chạy trên nhiều đám mây" → ⚠ Kubernetes / GKE Enterprise "hàm nhỏ" → Cloud Run Functions

Hai chế độ GKE Chế độ
Autopilot ⚠ Google quản node, trả theo POD — khuyên dùng
Standard tự quản node pool
Autopilot lo giúp kích cỡ node, vá, bảo mật mặc định
Standard cần khi GPU, DaemonSet, cấu hình node đặc thù
Khái niệm Kubernetes cần nhớ Khái niệm
Pod đơn vị nhỏ nhất
Deployment quản số bản sao và cập nhật dần
Service ⚠ DNS ổn định + cân bằng tải nội bộ
Ingress / Gateway đưa ra Internet
ConfigMap / Secret cấu hình và bí mật
HPA / VPA mở rộng ngang / dọc
Namespace chia nhóm
StatefulSet ứng dụng có trạng thái
⚠ GKE tích hợp với Google Cloud Tích hợp
Workload Identity ⚠ pod dùng IAM, KHÔNG cần khoá tệp
Cloud Load Balancing qua Ingress
Cloud Logging / Monitoring tự động
Artifact Registry kho image
Binary Authorization ⚠ chỉ image đã ký mới chạy
Backup for GKE sao lưu tải công việc
⚠ Cái giá của GKE Cái giá
Phí quản lý cụm có hạn mức miễn phí cho một cụm
Node luôn chạy ⚠ KHÔNG co về 0
Cần kỹ năng Kubernetes ⚠ chi phí lớn nhất và ít được nói tới nhất
Chỉ đáng khi thật sự có nhiều dịch vụ phức tạp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Pod có khoẻ không | kubectl get pods — ⚠ RESTARTS cao là xấu | | Cụm có đủ tài nguyên không | kubectl top nodes | | Đã đặt requests/limits chưa | ⚠ thiếu là pod bị đuổi bất ngờ |

Và một lựa chọn nên cân nhắc nghiêm túc với mọi cụm GKE mới: bắt đầu bằng Autopilot. Nó lấy đi phần lớn công việc vận hành node — vốn là nơi tiêu tốn thời gian nhất của các đội mới dùng Kubernetes — mà vẫn giữ nguyên toàn bộ API Kubernetes chuẩn mà bạn cần.

Câu 108 Digital Transformation with Google Cloud
When a business calculates the Total Cost of Ownership (TCO) for moving from on-premises to the cloud, what costs should be considered beyond the direct price of servers or virtual machines?
  1. A Only the cost of the software licenses.
  2. B Costs related to physical data center space, cooling, power, and IT staff for hardware maintenance.
  3. C The cost of the company's marketing budget.
  4. D The salaries of the entire company's employee base.
Xem giải thích

Đáp án

B — Chi phí liên quan tới không gian trung tâm dữ liệu, làm mát, điện năng và nhân sự CNTT bảo trì phần cứng.

Vì sao đúng

Total Cost of Ownership (TCO) là tổng chi phí sở hữu, không chỉ giá mua thiết bị. Đề hỏi những khoản ngoài giá máy chủ, và phương án B liệt kê đúng những khoản lớn nhất bị bỏ sót.

⚠ Tảng băng chi phí trung tâm dữ liệu:

    PHẦN NHÌN THẤY
    ┌────────────────────┐
    │  Giá máy chủ       │  ← ai cũng tính
    └────────────────────┘
    ━━━━━━━━━━━━━━━━━━━━━━
    PHẦN CHÌM ⚠
    │ Không gian, tủ rack
    │ ⚠ Điện năng
    │ ⚠ Làm mát
    │ Mạng và thiết bị mạng
    │ ⚠ NHÂN SỰ vận hành
    │ Giấy phép phần mềm
    │ Bảo trì và bảo hành
    │ Dự phòng điện (UPS)
    │ ⚠ Năng lực dư thừa mua sẵn
    │ Chi phí cơ hội

⚠ Hai khoản lớn nhất hay bị quên:

1. ĐIỆN VÀ LÀM MÁT
     → ⚠ thường bằng 30–50%
       chi phí phần cứng
     → máy chủ toả nhiệt,
       làm mát cũng tốn điện

2. ⚠ NHÂN SỰ
     → lương kỹ sư vận hành
     → trực đêm và cuối tuần
     → ⚠ và CHI PHÍ CƠ HỘI:
       thời gian đó không dành
       cho việc tạo giá trị

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

"CHỈ giấy phép phần mềm"
    → ⚠ đúng nhưng THIẾU rất nhiều
    → chữ "chỉ" làm nó sai

"Ngân sách MARKETING"
    → ⚠ không liên quan tới hạ tầng

"Lương TOÀN BỘ nhân viên công ty"
    → ⚠ quá rộng — chỉ tính nhân sự
      liên quan tới vận hành hạ tầng

Bổ sung cho #13291 (lô 139) — câu đó về CapEx → OpEx; câu này về những khoản tạo nên TCO thật. Hai câu ghép thành bức tranh tài chính đầy đủ của việc lên đám mây.

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

  • A (chỉ chi phí giấy phép phần mềm) — phương án gần nhất vì giấy phép thật sự là một phần của TCO, nhưng chữ "chỉ" làm nó sai: nó bỏ qua điện, làm mát, mặt bằng và nhân sự.

  • D (lương toàn bộ nhân viên công ty) — quá rộng; TCO hạ tầng chỉ tính phần nhân sự liên quan tới vận hành hạ tầng.

  • C (ngân sách marketing) — hoàn toàn không liên quan.

Ghi nhớ

⚠ Các thành phần của TCO hạ tầng — bảng nên thuộc: | Nhóm | Khoản | |---|---| | Phần cứng | máy chủ, lưu trữ, thiết bị mạng | | Cơ sở vật chất | ⚠ mặt bằng, tủ rack, điện, làm mát, UPS | | Con người | ⚠ lương vận hành, trực, đào tạo | | Phần mềm | giấy phép hệ điều hành và ứng dụng | | Bảo trì | hợp đồng bảo hành, thay thế | | Rủi ro | ⚠ chi phí của thời gian ngừng dịch vụ | | Cơ hội | ⚠ thời gian không dành cho sản phẩm |

Từ khoá nhận diện:

"tổng chi phí sở hữu, ngoài giá máy" → TCO "chuyển từ mua sang thuê" → CapEx → OpEx "trả theo mức dùng" → OpEx "lợi tức đầu tư" → ROI

⚠ Chi phí phía đám mây cũng phải tính đủ Khoản
Tính toán và lưu trữ phần ai cũng nhớ
⚠ Truyền dữ liệu ra (egress) khoản hay gây bất ngờ nhất
Dịch vụ có quản lý thường đắt hơn tự dựng nhưng ít việc hơn
⚠ Chi phí di cư một lần công sức, thời gian, chạy song song
Đào tạo lại đội ngũ
Gói hỗ trợ tính theo % chi tiêu
⚠ Đám mây KHÔNG tự động rẻ hơn Điểm
Rehost mà không tối ưu ⚠ thường ĐẮT hơn
Máy chạy 24/7 không cần thiết
Không dùng cam kết dài hạn
Không dọn tài nguyên mồ côi
Sự thật đám mây rẻ hơn khi được VẬN HÀNH tốt
Công cụ ước tính và tối ưu Công cụ
Pricing Calculator ước tính trước
Migration Center ⚠ đánh giá TCO dựa trên hạ tầng hiện tại
Recommender rightsizing, tài nguyên nằm không
CUD / Spot VM giảm giá
Billing export → BigQuery phân tích sâu
FinOps ⚠ văn hoá quản chi phí liên tục
Lợi ích khó quy ra tiền nhưng rất thật Lợi ích
Tốc độ ra sản phẩm ⚠ thường lớn hơn cả tiết kiệm chi phí
Không phải đoán nhu cầu 5 năm tới
Mở rộng ra vùng mới trong vài phút
Đội tập trung vào sản phẩm
Độ tin cậy cao hơn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | TCO hiện tại thật sự là bao nhiêu | ⚠ hỏi cả bộ phận cơ sở vật chất và nhân sự | | Tỉ lệ sử dụng máy chủ hiện tại | thường thấp hơn nhiều so với tưởng tượng | | Có phần cứng nào chưa khấu hao xong không | ảnh hưởng thời điểm di cư |

Và một con số rất đáng đi tìm trước khi so sánh TCO: tỉ lệ sử dụng thực tế của máy chủ hiện tại. Rất nhiều trung tâm dữ liệu chạy ở mức dưới 20% công suất trung bình — nghĩa là bốn phần năm chi phí điện, làm mát và mặt bằng đang dành cho năng lực chưa bao giờ được dùng tới.

Câu 109 Modernize Infrastructure and Applications with Google Cloud

A team wants to build a standard web application and deploy it without having to manage the underlying infrastructure, operating system, or web server software. They need a Platform as a Service (PaaS) solution.

Which Google Cloud product is designed for this purpose?

  1. A App Engine
  2. B Compute Engine
  3. C Google Kubernetes Engine (GKE)
  4. D Cloud Storage
Xem giải thích

Đáp án

A — App Engine.

Vì sao đúng

Đề nói rõ họ muốn một giải pháp PaaS, và liệt kê đúng ba tầng mà PaaS gánh hộ:

⚠ Ba yêu cầu ↔ App Engine:

"KHÔNG quản HẠ TẦNG bên dưới"
"KHÔNG quản HỆ ĐIỀU HÀNH"
"KHÔNG quản PHẦN MỀM MÁY CHỦ WEB"
        ↓
    ⚠ Đúng ba tầng mà PaaS lo hộ
        ↓
"ứng dụng web TIÊU CHUẨN"
        ↓
    ⚠ không có yêu cầu đặc biệt
      về môi trường
        ↓
    → APP ENGINE

⚠ App Engine lo những gì:

Bạn đưa: ⚠ MÃ NGUỒN + app.yaml
        ↓
Google lo:
    ⚠ máy chủ và hệ điều hành
    ⚠ máy chủ web và runtime
    ⚠ vá bảo mật
    ⚠ tự mở rộng, kể cả co về 0
    ⚠ HTTPS và chứng chỉ TLS
    ⚠ cân bằng tải
    ⚠ log và giám sát

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

COMPUTE ENGINE
    → ⚠ IaaS: máy ảo trống
    → tự cài OS, tự cài web server

GKE
    → ⚠ CaaS: cần container,
      cần vận hành cụm
    → không phải "không quản gì"

CLOUD STORAGE
    → ⚠ lưu trữ đối tượng
    → phục vụ được trang TĨNH
      nhưng không chạy được
      ứng dụng động

⚠ Gần trùng với #13341 (cùng lô này) — đề đó cũng là lập trình viên muốn PaaS, chỉ tải mã nguồn lên, và cùng khoá App Engine. Hoàn toàn nhất quán.

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

  • C (GKE) — phương án gần nhất trong các nền tảng chạy ứng dụng, nhưng nó là CaaS: bạn cần đóng gói container và vẫn phải hiểu Kubernetes. Xa với yêu cầu "không quản hạ tầng".

  • B (Compute Engine) — IaaS, phải tự cài hệ điều hành và máy chủ web — đúng ba thứ đề nói không muốn làm.

  • D (Cloud Storage) — chỉ lưu và phục vụ tệp tĩnh, không chạy mã ứng dụng.

Ghi nhớ

⚠ Bốn mô hình và sản phẩm tương ứng — bảng phải thuộc: | Mô hình | Sản phẩm Google | Bạn quản | |---|---|---| | IaaS | Compute Engine | hệ điều hành trở lên | | CaaS | GKE | container và cụm | | PaaS | ⚠ App Engine, Cloud Run | ⚠ chỉ mã và dữ liệu | | SaaS | Google Workspace | không gì cả |

Từ khoá nhận diện:

"PaaS, chỉ viết mã, không quản OS và web server" → App Engine "đã có container" → Cloud Run "cần kiểm soát OS" → Compute Engine "trang tĩnh, chỉ HTML và ảnh" → ⚠ Cloud Storage + CDN

Hai môi trường App Engine Môi trường
Standard ⚠ mã nguồn, runtime hỗ trợ, CO VỀ 0
Flexible container tuỳ biến, ⚠ KHÔNG co về 0
Runtime Standard Python, Java, Go, Node.js, PHP, Ruby
App Engine hay Cloud Run — chọn thế nào
Chưa có container, dùng runtime phổ biến App Engine Standard
Đã có container, hoặc ngôn ngữ lạ ⚠ Cloud Run
Cả hai serverless, co về 0, HTTPS tự động
Xu hướng ⚠ dự án mới thường chọn Cloud Run
⚠ Giới hạn cần biết của App Engine Giới hạn
Một ứng dụng App Engine mỗi project
⚠ Vùng chọn một lần, KHÔNG đổi được
Standard: không ghi hệ thống tệp trừ /tmp
Standard: không SSH
Chỉ runtime được hỗ trợ
Tính năng đáng dùng của App Engine Tính năng
⚠ Traffic splitting chia % lưu lượng giữa các phiên bản
Nhiều phiên bản song song quay lui dễ
dispatch.yaml định tuyến theo đường dẫn
Cron jobs tác vụ theo lịch
Task Queue xử lý nền
Tên miền riêng + TLS tự động
Trang tĩnh thì dùng gì Lựa chọn
Cloud Storage + Cloud CDN ⚠ rẻ nhất cho trang hoàn toàn tĩnh
Firebase Hosting tiện cho ứng dụng web hiện đại
App Engine khi có phần động

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Runtime có được hỗ trợ không | danh sách trong tài liệu | | Chi phí lúc rảnh | ⚠ Standard co về 0, Flexible thì không | | Có phụ thuộc hệ thống lạ không | nếu có → Cloud Run |

Và một quyết định nên cân nhắc kỹ trước khi gõ lệnh tạo ứng dụng App Engine: chọn vùng. Nó gắn với project vĩnh viễn và không đổi được — muốn chuyển sang vùng khác thì phải tạo project mới, cấu hình lại và trỏ lại tên miền từ đầu.

Câu 110 Scaling with Google Cloud Operations
An operations team needs to maintain high availability for a critical application. They define a goal that the application's latency, measured every minute, must be below 300ms. What is this specific, measurable goal called in Site Reliability Engineering (SRE) terms?
  1. A Service Level Agreement (SLA)
  2. B Service Level Objective (SLO)
  3. C Service Level Indicator (SLI)
  4. D Error Budget
Xem giải thích

Đáp án

B — Service Level Objective (SLO).

Vì sao đúng

Đề mô tả một mục tiêu cụ thể, đo được, do đội tự đặt ra: độ trễ phải dưới 300ms. Đó chính là định nghĩa của SLO.

⚠ Ba khái niệm, ba vai:

SLI — Service Level Indicator
    → ⚠ CHỈ SỐ được đo
    → "độ trễ, đo mỗi phút"
    → là con số thô

SLO — Service Level Objective
    → ⚠ MỤC TIÊU đặt trên SLI đó
    → "phải DƯỚI 300ms"
    → ⚠ nội bộ, do đội tự cam kết
    → đề này

SLA — Service Level Agreement
    → ⚠ HỢP ĐỒNG với khách hàng
    → có bồi thường nếu vi phạm

⚠ Cách phân biệt trong chính lời đề:

"độ trễ, ĐO MỖI PHÚT"
        ↓
    ⚠ phần này là SLI (chỉ số)

"phải DƯỚI 300ms"
        ↓
    ⚠ phần này là NGƯỠNG
        ↓
    SLI + ngưỡng + khoảng thời gian
        = ⚠ SLO
        ↓
    Đề hỏi "mục tiêu cụ thể, đo được"
        ↓
    → SLO

⚠ SLO luôn chặt hơn SLA:

SLA với khách: 99,5%
SLO nội bộ:    ⚠ 99,9%
        ↓
    ⚠ Chừa BIÊN AN TOÀN
        ↓
    Vi phạm SLO → đội biết trước
      và có thời gian xử lý
    Vi phạm SLA → ⚠ mất tiền
      và mất uy tín

Bổ sung cho #13264 (lô 138) và #13309 (lô 139) — hai câu đó về SRE nói chung và error budget. Câu này định nghĩa SLO, khái niệm gốc mà error budget được tính ra từ đó (error budget = 100% − SLO). Cả ba nhất quán.

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

  • C (SLI) — phương án gần nhất và là bẫy chính: SLI là chỉ số được đo (độ trễ), còn SLO là mục tiêu đặt trên chỉ số đó (dưới 300ms). Đề hỏi "mục tiêu", không hỏi "chỉ số".

  • A (SLA) — cam kết với khách hàng có bồi thường. Đề mô tả mục tiêu nội bộ của đội vận hành.

  • D (Error budget) — là phần được phép hỏng, tính từ SLO. Nó là hệ quả của SLO, không phải bản thân mục tiêu.

Ghi nhớ

⚠ SLI, SLO, SLA, Error budget — bảng phải thuộc: | Khái niệm | Là gì | Ví dụ | |---|---|---| | SLI | ⚠ CHỈ SỐ đo được | "tỉ lệ request dưới 300ms" | | SLO | ⚠ MỤC TIÊU nội bộ trên SLI | "99,9% request dưới 300ms" | | SLA | ⚠ HỢP ĐỒNG với khách, có bồi thường | "99,5%, không đạt thì hoàn tiền" | | Error budget | 100% − SLO | "0,1% ≈ 43 phút/tháng" |

Từ khoá nhận diện:

"mục tiêu nội bộ, cụ thể, đo được" → SLO "chỉ số được đo" → SLI "cam kết với khách, có bồi thường" → SLA "phần được phép hỏng" → error budget

⚠ Bốn tín hiệu vàng — nguồn SLI phổ biến Tín hiệu
Latency ⚠ độ trễ — đề này
Traffic lưu lượng
Errors tỉ lệ lỗi
Saturation mức bão hoà tài nguyên
Đặt SLO như thế nào cho đúng Nguyên tắc
Dựa trên TRẢI NGHIỆM NGƯỜI DÙNG ⚠ không dựa vào con số đẹp
Đo đường nền trước vài tuần
Đặt mức "đủ tốt", không phải cao nhất
Ghi rõ KHOẢNG THỜI GIAN ⚠ "trong 28 ngày trượt"
Thống nhất với bên nghiệp vụ
Rà soát định kỳ
⚠ Vì sao đo p99 chứ không đo trung bình Lý do
Trung bình che giấu đuôi phân bố
Ví dụ ⚠ trung bình 40ms nhưng p99 là 2 giây
Nghĩa là 1% người dùng có trải nghiệm tệ
Thực hành ⚠ SLO nên đặt trên PERCENTILE, không phải trung bình
Công cụ trên Google Cloud Công cụ
Cloud Monitoring — SLO ⚠ tính năng SLO dựng sẵn
Error budget burn rate alert ⚠ cảnh báo khi tiêu ngân sách quá nhanh
Cloud Trace phân tích độ trễ theo dịch vụ
Uptime checks đo từ nhiều nơi trên thế giới
⚠ SLA của Google Cloud khác SLO của bạn Điểm
SLA của Google cam kết cho DỊCH VỤ NỀN TẢNG
SLO của bạn ⚠ cho ỨNG DỤNG của bạn
Lưu ý ⚠ SLO của bạn KHÔNG THỂ cao hơn SLA của các dịch vụ bạn phụ thuộc
Tính toán nhân xác suất của các thành phần

Ba việc kiểm chứng: | Việc | Câu hỏi | |---|---| | SLO có viết ra và có ai theo dõi không | | | Đang đo percentile hay trung bình | ⚠ trung bình là dấu hiệu chưa chín | | SLO có cao hơn SLA của dịch vụ phụ thuộc không | nếu có thì nó bất khả thi |

Và một sai lầm rất phổ biến khi mới đặt SLO: chọn con số nghe cho oai thay vì con số người dùng cần. Một API nội bộ chạy mỗi đêm không cần 99,99% — đặt mục tiêu đó chỉ tạo ra áp lực vô ích và tiêu sạch ngân sách kỹ thuật vào chỗ không ai được lợi.