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

Tìm thấy 269 câu.

Câu 51
As a travel booking company, your web application runs on App Engine and uses CloudSQL and Cloud Storage for data storage. You have recently experienced a spike in website traffic that has resulted in increased latency for user requests, CPU usage, and the number of processes running the application. Despite the drop in traffic, users still experience high latency, and requests for content from CloudSQL database and Cloud Storage are also slow. You have not made any changes to the website, and no errors are reported to users. With a predicted spike in website traffic in the near future, what steps can you take to ensure there is no latency for users?
  1. A Convert the GCS buckets to Multi-Regional storage.
  2. B Migrate the application from App Engine to Compute Engine.
  3. C Configure CloudSQL instances for high availability.
  4. D Add more idle instances to the App Engine configuration.
Xem giải thích

Đáp án

D — Thêm idle instance vào cấu hình App Engine.

Vì sao đúng

Đề mô tả triệu chứng rất đặc trưng: độ trễ cao KÉO DÀI ngay cả khi lưu lượng đã giảm, không có lỗi báo về, không thay đổi gì trên website.

⚠ Chuỗi nguyên nhân:

⚠ Lưu lượng tăng đột biến
        ↓
⚠ App Engine phải KHỞI ĐỘNG
  instance mới
        ↓
⚠ Khởi động nguội (cold start) chậm
        ↓
⚠ Request phải CHỜ instance sẵn sàng
        ↓
⚠ Độ trễ cao, kể cả với request
  tới CloudSQL và Cloud Storage

⚠ Idle instance (minimum instances) giữ sẵn instance đã khởi động — request tới là phục vụ ngay, không phải chờ khởi động nguội.

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

  • C (cấu hình CloudSQL ở chế độ sẵn sàng cao) — ⚠ bẫy hợp lý: HA cho CSDL là tốt, nhưng ⚠ nó giải bài toán chịu lỗi, không giải bài toán độ trễ do khởi động nguội.

  • A (chuyển bucket sang Multi-Regional) — ⚠ không đúng nguyên nhân: request tới Cloud Storage chậm là hệ quả của instance chưa sẵn sàng, không phải do vị trí bucket.

  • B (chuyển ứng dụng từ App Engine sang Compute Engine) — ⚠ thay đổi kiến trúc lớn cho một vấn đề có thể sửa bằng cấu hình.

Ghi nhớ

⚠ Cấu hình co giãn của App Engine — bảng phải thuộc: | Tham số | Tác dụng | |---|---| | ⚠ min_idle_instances | ⚠ giữ sẵn instance chờ — đề này | | max_idle_instances | ⚠ trần instance nhàn rỗi, kiểm soát chi phí | | min_pending_latency | ⚠ chờ bao lâu trước khi tạo instance mới | | max_pending_latency | ⚠ ngưỡng buộc tạo instance mới | | min_instances (Flexible) | ⚠ số instance tối thiểu luôn chạy |

Từ khoá nhận diện:

"độ trễ cao khi tải tăng, kéo dài sau đó" → ⚠ khởi động nguội → idle instance "chịu lỗi CSDL" → ⚠ HA — vấn đề khác "vị trí bucket" → ⚠ không phải nguyên nhân "chuyển sang Compute Engine" → ⚠ thay đổi quá lớn

⚠ Vì sao cold start gây độ trễ dây chuyền Lý do
⚠ Instance mới phải tải mã, khởi tạo runtime
⚠ Mở lại kết nối tới CSDL ⚠ connection pool phải dựng lại
⚠ Cache trong bộ nhớ trống rỗng
⚠ Kết quả ⚠ mọi truy vấn đều chậm, kể cả tới dịch vụ khác
Đây là lý do ⚠ request tới CloudSQL và GCS cũng chậm
⚠ Đánh đổi của idle instance Đánh đổi
⚠ Tốn tiền cho instance chạy không
⚠ Nhưng độ trễ ổn định hơn nhiều
Đặt bao nhiêu ⚠ theo tải nền + biên cho đột biến
⚠ Cân nhắc ⚠ tăng trước các đợt cao điểm dự đoán được
⚠ Giảm cold start ngoài idle instance Cách
⚠ Giảm thời gian khởi động ứng dụng ⚠ hiệu quả lâu dài nhất
⚠ Warmup request ⚠ App Engine hỗ trợ
⚠ Giảm kích thước gói triển khai
Khởi tạo lười phần không cần ngay

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thời gian khởi động instance là bao lâu | ⚠ con số quyết định mọi thứ | | Có bao nhiêu instance được tạo trong đợt đột biến | | | Chi phí idle instance so với thiệt hại độ trễ | |

Và dấu hiệu nhận ra vấn đề cold start: độ trễ cao ngay cả với những thao tác lẽ ra rất nhanh, và nó kéo dài sau khi tải đã giảm. Đó là lúc nên nhìn vào cấu hình co giãn trước khi nghi ngờ cơ sở dữ liệu hay lưu trữ.

Câu 52
As an Electric vehicle manufacturer, you have a well-defined Service Level Objective (SLO) for your vehicle charging service. The development team deploys new releases of the service multiple times a week. In the event of a major incident that causes the service to miss its SLO, what steps should be taken before the incident occurs to shift the development team's focus from working on features to improving service reliability? Additionally, what Google Cloud Services can be utilized to ensure efficient management of the charging service?
  1. A Collaborate with all service stakeholders to establish a suitable policy for error budget.
  2. B Engage in discussions with the development team to limit the release frequency to a maximum of one time per week.
  3. C Incorporate a Jenkins pipeline plugin that restricts the deployment of new releases if your service is not meeting the SLO.
  4. D Ensure that the product team prioritizes service reliability over the release of new features through negotiations.
Xem giải thích

Đáp án

A — Phối hợp với mọi bên liên quan của dịch vụ để thống nhất một chính sách error budget phù hợp.

Vì sao đúng

Đề nhấn mạnh "TRƯỚC khi sự cố xảy ra" — nghĩa là cần một thoả thuận có sẵn quyết định điều gì xảy ra khi cạn error budget.

⚠ Chính sách error budget là gì:

⚠ SLO = 99,9% → error budget = 0,1%
        ↓
⚠ Chính sách quy định TRƯỚC:
   → ⚠ cạn budget thì DỪNG phát hành
     tính năng
   → ⚠ chuyển toàn đội sang việc
     độ tin cậy
   → ⚠ tới khi budget hồi phục
        ↓
⚠ Quyết định TỰ ĐỘNG, không tranh cãi
  lúc đang căng thẳng

⚠ Điểm mấu chốt: đây là thoả thuận được ĐỒNG THUẬN TRƯỚC, nên không ai phải thương lượng khi sự cố đang xảy ra.

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

  • D (thương lượng để đội sản phẩm ưu tiên độ tin cậy hơn tính năng) — ⚠ bẫy gần nhất: đúng hướng nhưng ⚠ thương lượng từng lần thì mỗi lần lại tranh cãi. ⚠ Chính sách error budget biến việc đó thành quy tắc tự động.

  • C (thêm plugin Jenkins chặn phát hành khi không đạt SLO) — ⚠ thực thi kỹ thuật KHÔNG có thoả thuận: ⚠ áp đặt công cụ mà chưa có đồng thuận sẽ bị vô hiệu hoá hoặc lách.

  • B (giới hạn phát hành tối đa một lần mỗi tuần) — ⚠ giải pháp thô: ⚠ giảm tần suất phát hành không tự động tăng độ tin cậy, và ⚠ đi ngược thực hành DevOps (phát hành nhỏ, thường xuyên thường an toàn hơn).

Ghi nhớ

⚠ Error budget — khái niệm cốt lõi — bảng phải thuộc: | Khái niệm | Nội dung | |---|---| | ⚠ SLO | ⚠ mục tiêu độ tin cậy, ví dụ 99,9% | | ⚠ Error budget | ⚠ phần được phép lỗi: 100% − SLO | | ⚠ Chính sách error budget | ⚠ quy định làm gì khi cạn — đề này | | Burn rate | ⚠ tốc độ tiêu ngân sách lỗi |

Từ khoá nhận diện:

"trước khi sự cố xảy ra, chuyển trọng tâm sang độ tin cậy" → ⚠ chính sách error budget "thương lượng từng lần" → ⚠ không bền vững "chặn bằng công cụ mà chưa thoả thuận" → ⚠ sẽ bị lách "giảm tần suất phát hành" → ⚠ không tự tăng độ tin cậy

⚠ Vì sao error budget là ý tưởng hay Lý do
⚠ Biến mâu thuẫn TỐC ĐỘ ↔ ĐỘ TIN CẬY thành SỐ
⚠ Còn budget → được phát hành nhanh ⚠ khuyến khích đổi mới
⚠ Cạn budget → dừng, sửa ⚠ tự động, không tranh cãi
⚠ Cả hai đội cùng nhìn một con số
Điểm hay nhất ⚠ không ai phải "cầu xin" thời gian sửa nợ kỹ thuật
⚠ Chính sách nên quy định gì Quy định
⚠ Cạn budget thì làm gì ⚠ đóng băng tính năng
⚠ Ai có quyền quyết định ngoại lệ
⚠ Khi nào budget được đặt lại ⚠ theo cửa sổ trượt 28 ngày chẳng hạn
⚠ Burn rate nào thì cảnh báo sớm
Ai ký duyệt chính sách ⚠ phải có cả sản phẩm lẫn kỹ thuật
⚠ Vì sao SLO 100% là sai Lý do
⚠ Error budget = 0 → không được phát hành gì
⚠ Chi phí tăng vọt ở những số 9 cuối
⚠ Người dùng thường không phân biệt được
Nguyên tắc ⚠ SLO phải phản ánh mức người dùng thật sự cần

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có chính sách error budget bằng văn bản chưa | | | Đội sản phẩm có ký vào không | ⚠ không có đồng thuận thì chính sách vô nghĩa | | Đã từng thực sự đóng băng tính năng chưa | ⚠ chưa bao giờ = chính sách hình thức |

Và điều làm nên sức mạnh của error budget: nó biến một cuộc tranh cãi chính trị thành một con số ai cũng nhìn thấy. Không còn chuyện "đội SRE lúc nào cũng bảo chậm lại" — chỉ còn ngân sách còn hay hết.

Câu 53
How can a Pet care service company redesign their environment using Google Cloud Services to reduce bugs and outages in production, and enable testers to load test new features without slowing down the production systems?
  1. A To promptly identify failures, establish an automated testing script in the production environment.
  2. B To safeguard the production environment and prevent any modifications from developers, establish a single managed update annually.
  3. C Set up a development environment with reduced server capacity and restrict access exclusively to developers and testers.
  4. D Set up a coding environment for development purposes and a testing environment for configuration, experimentation, and load testing.
Xem giải thích

Đáp án

D — Lập một môi trường phát triển để viết mã, và một môi trường kiểm thử riêng cho cấu hình, thử nghiệm và kiểm thử tải.

Vì sao đúng

Đề nêu hai mục tiêu, và tách hai môi trường giải được cả hai:

⚠ Hai mục tiêu:

"giảm lỗi và sự cố trên SẢN XUẤT"
    → ⚠ bắt lỗi sớm ở môi trường trước

"tester chạy KIỂM THỬ TẢI mà
 KHÔNG làm chậm sản xuất"
    → ⚠ môi trường kiểm thử RIÊNG

⚠ Vì sao cần HAI môi trường riêng biệt:

⚠ Môi trường PHÁT TRIỂN
   → ⚠ lập trình viên thay đổi liên tục
   → ⚠ hay hỏng, đó là bình thường

⚠ Môi trường KIỂM THỬ
   → ⚠ ổn định, giống sản xuất
   → ⚠ chịu được tải test nặng
        ↓
⚠ Trộn chung thì test tải sẽ bị
  ảnh hưởng bởi thay đổi đang dở

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

  • C (một môi trường phát triển năng lực thấp, chỉ lập trình viên và tester truy cập) — ⚠ bẫy gần nhất: nhưng ⚠ năng lực thấp thì không kiểm thử tải có ý nghĩa được, và ⚠ trộn hai mục đích vào một môi trường.

  • A (chạy script kiểm thử tự động trên môi trường SẢN XUẤT) — ⚠ nguy hiểm: đúng thứ đề nói phải tránh — làm chậm sản xuất và ảnh hưởng người dùng thật.

  • B (chỉ cập nhật một lần mỗi năm để bảo vệ sản xuất) — ⚠ đi ngược mọi thực hành DevOps: ⚠ phát hành hiếm và lớn rủi ro hơn nhiều so với phát hành nhỏ và thường xuyên.

Ghi nhớ

⚠ Các môi trường điển hình — bảng phải thuộc: | Môi trường | Mục đích | |---|---| | ⚠ Development | ⚠ lập trình viên viết và thử mã | | ⚠ Testing / QA | ⚠ kiểm thử chức năng, kiểm thử TẢI — đề này | | Staging | ⚠ giống sản xuất nhất, kiểm cuối | | Production | ⚠ người dùng thật | | ⚠ Nguyên tắc | ⚠ càng gần sản xuất càng phải giống sản xuất |

Từ khoá nhận diện:

"giảm lỗi trên sản xuất + kiểm thử tải riêng" → ⚠ tách môi trường "test trên sản xuất" → ⚠ nguy hiểm "cập nhật một lần mỗi năm" → ⚠ đi ngược DevOps "năng lực thấp" → ⚠ không test tải được

⚠ Vì sao phát hành THƯỜNG XUYÊN an toàn hơn Lý do
⚠ Thay đổi nhỏ → dễ tìm nguyên nhân khi hỏng
⚠ Quay lui dễ hơn
⚠ Đội quen với quy trình phát hành
⚠ Phản hồi nhanh hơn
Ngược lại ⚠ phát hành lớn hiếm hoi = rủi ro tích tụ
⚠ Môi trường kiểm thử tải cần gì Cần
⚠ Cấu hình GIỐNG sản xuất ⚠ không thì kết quả vô nghĩa
⚠ Dữ liệu có khối lượng tương đương
⚠ Cách ly mạng khỏi sản xuất
Có thể tạo và huỷ theo nhu cầu ⚠ tiết kiệm chi phí
⚠ Không dùng dữ liệu THẬT của khách ⚠ hoặc phải che PII
⚠ Chi phí môi trường và cách giảm Cách
⚠ Tạo môi trường theo yêu cầu, huỷ sau khi xong
⚠ Dùng preemptible cho môi trường test
⚠ Tự tắt ngoài giờ làm việc
Hạ tầng dạng mã ⚠ dựng lại nhanh, giống hệt nhau

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Môi trường test có giống sản xuất không | ⚠ khác nhiều thì test vô nghĩa | | Test tải có chạm vào sản xuất không | ⚠ kiểm cấu hình mạng | | Dữ liệu test có phải dữ liệu thật không | |

Và sai lầm tốn kém nhất về môi trường: kiểm thử tải trên môi trường nhỏ hơn sản xuất rồi ngoại suy. Hệ thống không co giãn tuyến tính — kết quả từ môi trường tí hon thường cho cảm giác an toàn giả.

Câu 54
As a social impact investment platform company, you want to ensure that images deployed to your application services in Google Kubernetes Engine (GKE) are only from the centrally-managed GoogleContainerRegistry (GCR) image registry in the altostrat-images project. How can you achieve this goal while minimizing development time?
  1. A The task is to develop a personalized builder for Cloud Build, which has the capability of solely pushing pictures to gcr.io/altostrat-images.
  2. B Ensure that every image in gcr.io/altostrat-images is tagged and verify that the said tag exists during image deployment.
  3. C Incorporate a whitelist name pattern of gcr.io/altostrat-images/ in the Binary Authorization policy.
  4. D Incorporate a verification mechanism in the deployment pipeline to ensure that every manifest solely comprises of images originating from gcr.io/altostrat-images.
Xem giải thích

Đáp án

C — Thêm mẫu tên được cho phép gcr.io/altostrat-images/ vào chính sách Binary Authorization.

Vì sao đúng

Đề cần chặn image không đến từ một registry cụ thể, với thời gian phát triển tối thiểu.

⚠ Vì sao whitelist tên là cách nhanh nhất:

⚠ Binary Authorization hỗ trợ
  allowlist theo MẪU TÊN
        ↓
⚠ Chỉ cần khai một dòng chính sách
        ↓
⚠ Mọi image ngoài mẫu đó bị TỪ CHỐI
        ↓
⚠ KHÔNG phải viết code, không phải
  ký từng image

⚠ Gần trùng với #14961 (chính lô này) — câu kia hỏi công cụ nào để chỉ cho triển khai image từ pipeline tin cậy (dùng attestation), câu này hỏi cách giới hạn theo registry cụ thể (dùng whitelist tên). ⚠ Cùng công cụ, hai cơ chế trong cùng chính sách.

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

  • D (thêm bước kiểm tra trong pipeline triển khai để xác minh manifest chỉ chứa image từ registry đó) — ⚠ bẫy mạnh nhất: làm được nhưng ⚠ tốn công viết và bảo trì, và ⚠ ai bỏ qua pipeline vẫn deploy được — không phải cơ chế thực thi ở cluster.

  • B (gắn tag cho mọi image và kiểm tra tag khi triển khai) — ⚠ tag dễ giả mạo: ai cũng gắn được tag đó cho image của mình.

  • A (viết builder tuỳ chỉnh cho Cloud Build chỉ đẩy được vào registry đó) — ⚠ kiểm soát sai đầu: chặn ở khâu đẩy image, ⚠ không chặn được ai đó triển khai image từ nơi khác.

Ghi nhớ

⚠ Hai cơ chế của Binary Authorization — bảng phải thuộc: | Cơ chế | Kiểm gì | |---|---| | ⚠ Allowlist tên registry | ⚠ image ĐẾN TỪ ĐÂU — đề này | | ⚠ Attestation | ⚠ image đã qua QUY TRÌNH nào | | Kết hợp | ⚠ vừa đúng nguồn vừa đúng quy trình | | Chế độ | ⚠ enforce hoặc dry-run |

Từ khoá nhận diện:

"chỉ từ registry X, ít công sức" → ⚠ whitelist trong Binary Authorization "đã qua pipeline tin cậy" → ⚠ attestation "kiểm trong pipeline" → ⚠ bỏ qua được, không phải thực thi "kiểm tra tag" → ⚠ tag dễ giả mạo

⚠ Vì sao thực thi ở CLUSTER mạnh hơn ở PIPELINE Lý do
⚠ Pipeline có thể bị bỏ qua ⚠ ai có quyền kubectl là deploy thẳng được
⚠ Cluster là điểm CUỐI, không né được
⚠ Áp cho MỌI cách triển khai
Nguyên tắc ⚠ kiểm soát càng gần nơi thực thi càng khó lách
⚠ Chiến lược registry tập trung Chiến lược
⚠ Một project riêng cho registry ⚠ altostrat-images trong đề
⚠ Quyền đẩy image rất hẹp ⚠ chỉ pipeline CI
⚠ Quyền đọc rộng cho các cluster
⚠ Quét lỗ hổng tự động
Lưu ý ⚠ Artifact Registry đang thay thế Container Registry
⚠ Triển khai Binary Authorization an toàn Bước
⚠ 1. Bật chế độ dry-run trước ⚠ xem sẽ chặn những gì
⚠ 2. Rà danh sách bị chặn
⚠ 3. Bổ sung ngoại lệ cần thiết
⚠ 4. Chuyển sang enforce
Có cơ chế break-glass ⚠ cho sự cố khẩn cấp, có ghi vết

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử deploy image từ registry khác | ⚠ phải bị chặn | | Ai có quyền đẩy vào registry trung tâm | | | Break-glass có ghi vết không | |

Và nguyên tắc chọn điểm đặt kiểm soát: càng gần nơi hành động thật sự xảy ra thì càng khó lách. Kiểm trong pipeline chỉ chặn được người đi qua pipeline; kiểm ở cluster chặn được tất cả.

Câu 55
As an online grocery delivery service company, you need to design a new application for deployment both inside and outside Google Cloud Platform (GCP). You want to collect detailed metrics such as system resource utilization using centralized GCP services while minimizing the amount of work required to set up this collection system. What steps should you take?
  1. A To transmit function timing data to Google Cloud for in-depth analysis, install the Cloud Profiler package and set it up.
  2. B One solution is to utilize a timing library to instrument the code, and then expose the metrics through a health check endpoint that is scraped by Google Cloud.
  3. C In order to analyze the data, it is recommended to install an Application Performance Monitoring (APM) tool in both locations and then configure it to export the data to a central data storage location.
  4. D Configure the application to emit debug messages with timing information by importing the Cloud Debugger package.
Xem giải thích

Đáp án

A — Cài đặt và cấu hình gói Cloud Profiler để gửi dữ liệu thời gian thực thi hàm về Google Cloud phân tích.

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

⚠ Đề bài và khoá đáp án không khớp hoàn toàn.

Phần Nội dung
⚠ Đề hỏi ⚠ "chỉ số chi tiết như MỨC DÙNG TÀI NGUYÊN HỆ THỐNG"
⚠ Khoá ⚠ Cloud Profiler — đo THỜI GIAN THỰC THI HÀM

⚠ Theo kiến thức chuẩn, thu thập mức dùng tài nguyên hệ thống (CPU, RAM, đĩa) từ cả trong lẫn ngoài Google Cloud là việc của Ops Agent gửi về Cloud Monitoring.

⚠ KHÔNG sửa khoá — ghi chú để người ôn biết. ⚠ Trong bốn phương án đã cho, A vẫn là phương án hợp lý nhất vì ba phương án còn lại đều tệ hơn rõ rệt.

Vì sao vẫn chọn được A

⚠ Ba phương án kia sai rõ ràng hơn:

⚠ B — tự viết thư viện đo thời gian
   → ⚠ nhiều công sức, đề nói TỐI THIỂU

⚠ C — cài công cụ APM bên thứ ba ở
   hai nơi rồi xuất về kho chung
   → ⚠ đề nói dùng DỊCH VỤ GCP tập trung

⚠ D — Cloud Debugger để ghi thông báo
   debug kèm thời gian
   → ⚠ SAI công cụ hoàn toàn

⚠ Cloud Profiler có ưu điểm khớp đề: chạy được cả trong lẫn ngoài Google Cloud, ⚠ cài đặt tối thiểu (chỉ thêm thư viện), ⚠ gửi về dịch vụ tập trung của GCP.

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

  • B (tự viết thư viện đo thời gian, phơi chỉ số qua health check endpoint) — ⚠ nhiều công sức nhất, và ⚠ health check endpoint không phải nơi phơi chỉ số.

  • C (cài công cụ APM ở cả hai nơi rồi xuất về kho tập trung) — ⚠ đi ngược yêu cầu dùng dịch vụ GCP và ⚠ tăng chi phí, tăng công vận hành.

  • D (dùng Cloud Debugger để ghi thông báo debug kèm thời gian) — ⚠ sai công cụ: Debugger để xem trạng thái biến, không phải thu thập chỉ số.

Ghi nhớ

⚠ Thu thập chỉ số từ môi trường lai — bảng phải thuộc: | Cần gì | Công cụ | |---|---| | ⚠ Mức dùng CPU, RAM, đĩa | ⚠ Ops Agent → Cloud Monitoring | | ⚠ Thời gian thực thi hàm, hồ sơ CPU | ⚠ Cloud Profiler — khoá của đề | | ⚠ Độ trễ liên dịch vụ | ⚠ Cloud Trace | | Log | ⚠ Ops Agent → Cloud Logging | | Lỗi ứng dụng | ⚠ Error Reporting |

Từ khoá nhận diện:

"mức dùng tài nguyên hệ thống" → ⚠ Ops Agent + Cloud Monitoring "hàm nào tốn CPU" → ⚠ Cloud Profiler "chậm ở dịch vụ nào" → ⚠ Cloud Trace "xem giá trị biến" → ⚠ Debugger — không phải chỉ số

⚠ Ops Agent làm được gì Việc
⚠ Thu thập LOG và CHỈ SỐ trong một agent
⚠ Chạy trên Compute Engine, VM tại chỗ, đám mây khác
⚠ Chỉ số hệ thống: CPU, RAM, đĩa, mạng
Chỉ số ứng dụng qua plugin
⚠ Thay thế ⚠ agent Logging và Monitoring riêng lẻ trước đây
⚠ Cloud Profiler đặc điểm Đặc điểm
⚠ Lấy mẫu liên tục, tác động rất nhỏ ⚠ chạy được cả trên sản xuất
⚠ Chỉ ra HÀM nào tốn CPU, bộ nhớ
⚠ Chạy được ngoài Google Cloud
Cần thêm thư viện vào ứng dụng ⚠ công sức nhỏ
⚠ Kiến trúc quan sát cho môi trường lai Kiến trúc
⚠ Ops Agent trên mọi máy ⚠ trong và ngoài GCP
⚠ Gửi về Cloud Monitoring và Logging
⚠ Profiler và Trace nhúng trong ứng dụng
Một nơi xem tất cả ⚠ đúng yêu cầu "tập trung" của đề

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cần chỉ số hệ thống hay chỉ số ứng dụng | ⚠ quyết định chọn công cụ | | Máy ngoài GCP có kết nối được không | ⚠ cần đường mạng và xác thực | | Chi phí thu thập chỉ số là bao nhiêu | |

Và điều cần phân biệt rõ trong nhóm công cụ này: Ops Agent đo MÁY, Profiler đo MÃ NGUỒN, Trace đo ĐƯỜNG ĐI của request. Ba câu hỏi khác nhau, ba công cụ khác nhau.

Câu 56
As an expert in Google Cloud, what is the first step a food delivery company should take to mitigate the impact of latency experienced by thousands of users during login on their web application hosted on Compute Engine?
  1. A Increase the size of the virtual machines that are currently running the login services.
  2. B Revert the latest deployment.
  3. C Examine the Cloud monitoring.
  4. D To check if the issue is resolved, roll out a fresh update.
Xem giải thích

Đáp án

B — Quay lui (rollback) bản triển khai gần nhất.

Vì sao đúng

Đề nhấn hai chữ: "bước ĐẦU TIÊN" và "GIẢM TÁC ĐỘNG" cho hàng nghìn người dùng đang bị ảnh hưởng.

⚠ Nguyên tắc SRE: GIẢM THIỂU trước, chẩn đoán sau:

⚠ Người dùng đang chịu ảnh hưởng NGAY
        ↓
⚠ Quay lui = cách NHANH NHẤT
  đưa hệ thống về trạng thái đã biết
  là TỐT
        ↓
⚠ Sau khi ổn định mới bình tĩnh
  tìm nguyên nhân

⚠ Quay lui trước không phải là bỏ qua chẩn đoán — nó là mua thời gian để chẩn đoán tử tế.

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

  • C (xem Cloud Monitoring) — ⚠ bẫy tinh vi nhất: quan sát là việc cần làm, nhưng ⚠ không GIẢM TÁC ĐỘNG. Trong lúc bạn xem biểu đồ, người dùng vẫn đang gặp lỗi. ⚠ Nếu đã biết vấn đề bắt đầu sau một lần triển khai thì quay lui trước.

  • A (tăng kích thước máy ảo chạy dịch vụ đăng nhập) — ⚠ đoán mò nguyên nhân: chưa biết có phải do thiếu tài nguyên hay không.

  • D (phát hành một bản cập nhật mới để xem có hết không) — ⚠ nguy hiểm: ⚠ đẩy mã chưa kiểm chứng lên trong lúc đang có sự cố có thể làm tình hình tệ hơn.

Ghi nhớ

⚠ Thứ tự xử lý sự cố — bảng phải thuộc: | Bước | Việc | |---|---| | ⚠ 1. GIẢM THIỂU | ⚠ quay lui, chuyển traffic, tắt tính năng — đề này | | ⚠ 2. Ổn định | ⚠ xác nhận người dùng đã ổn | | ⚠ 3. Chẩn đoán | ⚠ bình tĩnh tìm nguyên nhân | | 4. Sửa gốc | | | 5. Postmortem | |

Từ khoá nhận diện:

"bước đầu tiên, giảm tác động" → ⚠ quay lui hoặc chuyển traffic "xem monitoring" → ⚠ quan sát, không giảm tác động "đẩy bản mới lên để thử" → ⚠ nguy hiểm khi đang có sự cố "tăng máy" → ⚠ đoán nguyên nhân

⚠ Ba cách giảm thiểu nhanh nhất Cách
⚠ Quay lui bản triển khai ⚠ nhanh nhất nếu vấn đề do phát hành
⚠ Chuyển traffic sang vùng khác
⚠ Tắt tính năng bằng feature flag ⚠ nhanh hơn quay lui toàn bộ
Điểm chung ⚠ đưa về trạng thái ĐÃ BIẾT là tốt
⚠ Điều kiện để quay lui được nhanh Điều kiện
⚠ Quy trình quay lui đã được THỬ ⚠ không thử thì lúc cần sẽ lúng túng
⚠ Biết bản trước là bản nào ⚠ cần quản lý phiên bản tốt
⚠ Thay đổi CSDL phải tương thích ngược ⚠ chỗ khó nhất khi quay lui
Tự động hoá quay lui
⚠ Khi nào KHÔNG quay lui được Khi nào
⚠ Đã có thay đổi lược đồ CSDL không tương thích ngược
⚠ Dữ liệu mới đã ghi theo định dạng mới
⚠ Vấn đề không do phát hành gây ra
Vì thế ⚠ thiết kế thay đổi CSDL theo nhiều bước tương thích ngược

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Quay lui mất bao lâu | ⚠ thử trong lúc bình thường | | Thay đổi CSDL gần nhất có tương thích ngược không | | | Có feature flag để tắt nhanh không | |

Và nguyên tắc cứu người trong sự cố: cầm máu trước, chẩn đoán sau. Hiểu vì sao hỏng là quan trọng, nhưng không quan trọng bằng việc người dùng ngừng gặp lỗi.

Câu 57
As a Google Cloud Professional Cloud DevOps Engineer, you work for an online grocery delivery service company that uses Google Kubernetes Engine (GKE) to deploy their mobile application across multiple regions. You receive a report that customers in a particular region are unable to access the application. What would be your initial step to resolve the issue while following Site Reliability Engineering practices?
  1. A Cloud Monitoring can be utilized to monitor any sudden increase in the usage of CPU or memory for the impacted region.
  2. B To the cluster, include an additional node pool comprising of machine types that have high CPU and high memory.
  3. C Redirect the user traffic from the troubled region to other regions that are not experiencing any problems.
  4. D To inspect error messages in the logs, you can utilize Cloud Logging and filter based on the affected region's clusters.
Xem giải thích

Đáp án

C — Chuyển hướng lưu lượng người dùng từ vùng đang gặp sự cố sang các vùng khác đang hoạt động bình thường.

Vì sao đúng

Đề nêu tình huống: khách hàng ở MỘT vùng không truy cập được, ứng dụng chạy nhiều vùng, và hỏi bước ĐẦU TIÊN theo thực hành SRE.

⚠ Vì sao chuyển traffic là bước đầu:

⚠ Có sẵn các vùng khác đang khoẻ
        ↓
⚠ Chuyển traffic = người dùng hết lỗi
  NGAY LẬP TỨC
        ↓
⚠ Vùng hỏng không còn phục vụ ai
        ↓
⚠ Bình tĩnh chẩn đoán vùng đó

⚠ Đây chính là áp dụng nguyên tắc "giảm thiểu trước, chẩn đoán sau" trong bối cảnh đa vùng.

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

  • D (dùng Cloud Logging lọc log của cluster vùng bị ảnh hưởng để tìm lỗi) — ⚠ bẫy mạnh nhất: đây là việc đúng và cần làm, nhưng ⚠ là bước THỨ HAI. Trong lúc đọc log, khách hàng vùng đó vẫn không dùng được.

  • A (dùng Cloud Monitoring xem CPU và bộ nhớ vùng đó có tăng đột biến không) — ⚠ cũng là chẩn đoán, không phải giảm thiểu.

  • B (thêm node pool máy cấu hình cao vào cluster) — ⚠ đoán nguyên nhân và chậm: ⚠ chưa biết có phải thiếu tài nguyên không, và ⚠ thêm node mất thời gian.

Ghi nhớ

⚠ Thứ tự SRE khi có sự cố vùng — bảng phải thuộc: | Bước | Việc | |---|---| | ⚠ 1. Chuyển traffic khỏi vùng hỏng | ⚠ giảm thiểu — đề này | | ⚠ 2. Xác nhận người dùng đã ổn | | | ⚠ 3. Chẩn đoán vùng hỏng | ⚠ log, chỉ số | | 4. Sửa và đưa vùng trở lại | | | 5. Postmortem | |

Từ khoá nhận diện:

"bước đầu tiên, một vùng hỏng, có vùng khác" → ⚠ chuyển traffic "đọc log tìm lỗi" → ⚠ chẩn đoán, bước sau "thêm node" → ⚠ đoán nguyên nhân

⚠ Điều kiện để chuyển traffic được nhanh Điều kiện
⚠ Kiến trúc ĐA VÙNG thật sự ⚠ các vùng khác đủ năng lực gánh
⚠ Load balancer toàn cầu ⚠ Global Load Balancer của Google Cloud
⚠ Health check tự phát hiện vùng hỏng ⚠ lý tưởng là tự chuyển
Dữ liệu có sẵn ở vùng khác ⚠ nếu có trạng thái
⚠ Đã DIỄN TẬP ⚠ chuyển vùng lần đầu không nên là lúc có sự cố
⚠ Vấn đề cần tính khi dồn traffic Vấn đề
⚠ Các vùng còn lại có gánh nổi không ⚠ phải có năng lực dư
⚠ Độ trễ tăng cho người dùng vùng đó ⚠ chấp nhận được so với không dùng được
⚠ Dữ liệu có sẵn ở vùng đích không
Chi phí truyền dữ liệu liên vùng
⚠ Lý tưởng là tự động Tự động
⚠ Health check phát hiện vùng hỏng
⚠ Load balancer tự chuyển hướng
⚠ Không cần con người can thiệp
Khi đó ⚠ sự cố vùng chỉ là một dòng trong báo cáo, không phải một đêm mất ngủ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Các vùng còn lại có đủ năng lực không | ⚠ tính trước, không đợi lúc cần | | Chuyển traffic có tự động không | | | Đã diễn tập mất một vùng chưa | ⚠ chaos engineering |

Và điều đáng đầu tư hơn cả quy trình xử lý sự cố: làm cho việc chuyển traffic khỏi một vùng trở nên tự động. Khi đó sự cố vùng không còn là sự cố với người dùng — chỉ còn là việc cần sửa vào giờ hành chính.

Câu 58
In your Blockchain-based payment system company, you use Spinnaker to deploy your payment application and have created a canary deployment stage in the pipeline. Your payment application has a blockchain-based in-memory cache that loads payment objects at start time. You want to automate the comparison of the canary payment version against the production payment version using Google Cloud Services. How should you configure the canary analysis?
  1. A Can you contrast the canary deployment with the current production version?
  2. B The performance of a canary can be evaluated by comparing it to the average performance of a sliding window that includes previous production versions.
  3. C In contrast to a new deployment of the previous production version, how does the canary differ?
  4. D Can you contrast a canary deployment with deploying a new version of the current production version?
Xem giải thích

Đáp án

D — So sánh bản canary với một lần TRIỂN KHAI MỚI của chính phiên bản đang chạy trên sản xuất.

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

⚠ Cả bốn phương án bị viết thành CÂU HỎI thay vì câu trả lời ("Can you contrast…?", "How does the canary differ…?"). ⚠ Đây là lỗi trình bày của bộ đề.

⚠ Nội dung khoá vẫn ĐÚNG CHUẨN phân tích canary — chỉ cách diễn đạt bị hỏng. ⚠ Đọc theo ý chứ không theo dạng câu.

Vì sao đúng

Đây là nguyên tắc quan trọng nhất của phân tích canary: so sánh canary với một BASELINE MỚI TRIỂN KHAI, không so với instance sản xuất đang chạy lâu ngày.

⚠ Vì sao không so với instance sản xuất cũ:

⚠ Instance chạy lâu có:
   → ⚠ CACHE ĐÃ ẤM
   → ⚠ JIT đã tối ưu
   → ⚠ connection pool đã sẵn sàng
        ↓
⚠ Canary vừa khởi động thì LẠNH
        ↓
⚠ So sánh là KHÔNG CÔNG BẰNG
   → ⚠ canary luôn trông tệ hơn

⚠ Đề nhắc rõ ứng dụng có "in-memory cache nạp lúc khởi động" — chính là lý do phải so với baseline cùng tuổi.

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

  • A (so canary với phiên bản sản xuất HIỆN TẠI đang chạy) — ⚠ bẫy mạnh nhất và là sai lầm phổ biến nhất: so với instance đã ấm cache là so sánh lệch.

  • B (so với trung bình cửa sổ trượt của các phiên bản sản xuất trước) — ⚠ trộn nhiều biến số: các phiên bản trước chạy trong điều kiện tải khác nhau.

  • C (so với một lần triển khai mới của phiên bản TRƯỚC ĐÓ) — ⚠ sai phiên bản: baseline phải là phiên bản đang chạy hiện tại, không phải phiên bản cũ hơn.

Ghi nhớ

⚠ Nguyên tắc phân tích canary — bảng phải thuộc: | Nguyên tắc | Nội dung | |---|---| | ⚠ So với BASELINE MỚI TRIỂN KHAI | ⚠ cùng tuổi với canary — đề này | | ⚠ Cùng cấu hình, cùng lượng traffic | | | ⚠ Cùng khoảng thời gian quan sát | | | ⚠ So các chỉ số giống nhau | ⚠ độ trễ, tỷ lệ lỗi, tài nguyên | | Mục đích | ⚠ chỉ còn MỘT biến khác nhau: phiên bản mã |

Từ khoá nhận diện:

"so canary với baseline mới triển khai" → ⚠ đúng chuẩn "so với sản xuất đang chạy" → ⚠ lệch vì cache ấm "trung bình các phiên bản trước" → ⚠ trộn biến số "so với phiên bản cũ hơn" → ⚠ sai baseline

⚠ Vì sao "cache ấm" làm hỏng so sánh Lý do
⚠ Instance chạy lâu có cache đầy ⚠ truy vấn nhanh hơn nhiều
⚠ Canary vừa khởi động, cache rỗng
⚠ Chênh lệch KHÔNG phải do mã mới
Hệ quả ⚠ canary tốt vẫn bị đánh trượt
⚠ Các chỉ số nên so trong canary Chỉ số
⚠ Tỷ lệ lỗi ⚠ quan trọng nhất
⚠ Độ trễ p50, p95, p99
⚠ Mức dùng CPU và bộ nhớ
Số ngoại lệ trong log
⚠ Chỉ số nghiệp vụ ⚠ tỷ lệ hoàn tất giao dịch
⚠ Lưu ý khi chạy canary Lưu ý
⚠ Chờ đủ lâu để cache ấm ở CẢ HAI bên
⚠ Đủ lưu lượng để có ý nghĩa thống kê
⚠ Tự động quay lui khi vượt ngưỡng
Traffic phải phân bổ ngẫu nhiên ⚠ không thiên lệch theo loại người dùng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Baseline có cùng tuổi với canary không | ⚠ lỗi phổ biến nhất | | Đã chờ cache ấm chưa | | | Lưu lượng có đủ để kết luận không | |

Và sai lầm kinh điển khi làm canary: so bản mới vừa khởi động với bản cũ đã chạy nhiều ngày. Kết quả là canary nào cũng trượt, và đội mất niềm tin vào chính cơ chế bảo vệ mình.

Câu 59
As an electric vehicle manufacturer, some of your production services are running in Google Kubernetes Engine (GKE) in the eu-west-1 region while your build system is based in the us-west-1 region. To ensure efficient transfer of container images to the cluster, what steps should you take to push the images to a scalable registry, possibly using Google Cloud Services?
  1. A The images should be uploaded to a private image registry that is hosted on a Compute Engine instance located in the eu-west-1 region.
  2. B Use the eu.gcr.io hostname to upload the images to Google Container Registry (GCR).
  3. C The images should be pushed to Google Container Registry (GCR) by utilizing the gcr.io hostname.
  4. D Use the us.gcr.io hostname to upload the images to Google Container Registry (GCR).
Xem giải thích

Đáp án

B — Đẩy image vào Google Container Registry qua hostname eu.gcr.io.

Vì sao đúng

Đề nêu tình huống địa lý: cluster ở eu-west-1, hệ thống build ở us-west-1. Cần image gần cluster để kéo nhanh.

⚠ Vì sao chọn host theo vùng của CLUSTER:

⚠ Image được ĐẨY một lần
⚠ Nhưng được KÉO nhiều lần
   → ⚠ mỗi lần scale, mỗi node mới,
     mỗi lần restart pod
        ↓
⚠ Tối ưu cho việc KÉO, không phải ĐẨY
        ↓
⚠ Đặt registry gần CLUSTER → eu.gcr.io

⚠ Các hostname của GCR:

⚠ gcr.io    → mặc định, lưu ở Mỹ
⚠ us.gcr.io → Hoa Kỳ
⚠ eu.gcr.io → châu Âu
⚠ asia.gcr.io → châu Á

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

  • D (dùng us.gcr.io) — ⚠ bẫy tự nhiên: đặt gần hệ thống build. Nhưng ⚠ sai hướng tối ưu — kéo image nhiều hơn đẩy rất nhiều lần.

  • C (dùng gcr.io mặc định) — ⚠ mặc định lưu ở Hoa Kỳ, cùng vấn đề như D.

  • A (tự dựng registry riêng trên một VM ở eu-west-1) — ⚠ đi ngược yêu cầu "registry có khả năng mở rộng": ⚠ tự vận hành registry trên một VM là điểm hỏng đơn và tăng công vận hành.

Ghi nhớ

⚠ Chọn vị trí registry — bảng phải thuộc: | Nguyên tắc | Nội dung | |---|---| | ⚠ Đặt gần nơi KÉO image | ⚠ tức là gần cluster — đề này | | Kéo nhiều hơn đẩy rất nhiều | | | Giảm độ trễ khởi động pod | | | ⚠ Giảm phí truyền dữ liệu liên vùng | |

Từ khoá nhận diện:

"cluster ở vùng X, build ở vùng Y" → ⚠ registry đặt gần CLUSTER "tự dựng registry trên VM" → ⚠ điểm hỏng đơn, tăng toil "gcr.io mặc định" → ⚠ lưu ở Hoa Kỳ

⚠ Artifact Registry thay thế Container Registry Lưu ý
⚠ Google khuyến nghị dùng Artifact Registry ⚠ Container Registry đang ngừng dần
⚠ Artifact Registry chọn region cụ thể ⚠ không chỉ multi-region
⚠ Hỗ trợ nhiều loại artefact ⚠ không chỉ container
Tích hợp quét lỗ hổng
Đề này ⚠ dùng GCR nên trả lời theo GCR
⚠ Vì sao độ trễ kéo image quan trọng Lý do
⚠ Ảnh hưởng thời gian khởi động pod
⚠ Khi autoscale, node mới phải kéo image
⚠ Image lớn qua liên lục địa rất chậm
Ảnh hưởng thời gian phục hồi sự cố
Giảm bằng ⚠ image nhỏ + registry gần + image streaming
⚠ Cách giảm thời gian kéo image Cách
⚠ Image base tối giản ⚠ distroless, alpine
⚠ Multi-stage build
⚠ Registry cùng vùng với cluster
Image streaming trên GKE ⚠ pod chạy trước khi kéo xong
Node có cache image

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Registry có cùng vùng với cluster không | | | Image lớn bao nhiêu | ⚠ ảnh hưởng trực tiếp thời gian khởi động | | Có phí truyền liên vùng không | |

Và nguyên tắc chung khi đặt vị trí tài nguyên: tối ưu cho thao tác diễn ra NHIỀU LẦN, không phải thao tác diễn ra một lần. Image đẩy một lần nhưng kéo hàng nghìn lần — nên vị trí phải theo phía kéo.

Câu 60
As a digital product design agency company, how can you deploy a new service to production using a Managed Instance Group (MIG) in Google Cloud that can automatically scale and be deployed over multiple regions, while planning for capacity and ensuring that the service has a large number of resources for each instance?
  1. A Ensure that the resource demands do not exceed the quota limits for each region.
  2. B Use Cloud Trace to monitor outcomes and evaluate the essential quantity of resources.
  3. C When configuring the MIG, it is recommended to utilize the n1-highcpu-96 machine type.
  4. D The service should be deployed in a single region and a global load balancer should be utilized to direct traffic to that region.
Xem giải thích

Đáp án

A — Đảm bảo nhu cầu tài nguyên không vượt quá hạn mức (quota) của từng vùng.

Vì sao đúng

Đề nêu ba yếu tố: tự động co giãn, triển khai nhiều vùng, và mỗi instance cần rất nhiều tài nguyên.

⚠ Vì sao quota là vấn đề then chốt:

⚠ Quota được cấp THEO TỪNG VÙNG
        ↓
⚠ Instance cần nhiều tài nguyên
   → ⚠ nhiều vCPU, nhiều RAM
        ↓
⚠ Autoscaler muốn thêm máy
   → ⚠ CHẠM QUOTA
   → ⚠ KHÔNG thêm được
        ↓
⚠ Dịch vụ không co giãn được đúng lúc
  cần nhất

⚠ Đây là lỗi âm thầm nhất khi lập kế hoạch năng lực — mọi thứ ổn cho tới khi cần mở rộng thật.

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

  • C (dùng máy n1-highcpu-96 khi cấu hình MIG) — ⚠ bẫy hợp lý: máy to cho nhiều tài nguyên. Nhưng ⚠ không giải quyết vấn đề quota, và ⚠ chọn loại máy cụ thể mà chưa đo nhu cầu là đoán mò.

  • D (triển khai một vùng rồi dùng global load balancer trỏ về vùng đó) — ⚠ đi ngược yêu cầu đa vùng: ⚠ một vùng là điểm hỏng đơn, và global LB trỏ về một vùng thì không có ý nghĩa dự phòng.

  • B (dùng Cloud Trace để theo dõi và đánh giá lượng tài nguyên cần thiết) — ⚠ sai công cụ: Cloud Trace đo độ trễ liên dịch vụ, ⚠ không phải công cụ lập kế hoạch năng lực.

Ghi nhớ

⚠ Lập kế hoạch năng lực đa vùng — bảng phải thuộc: | Việc | Nội dung | |---|---| | ⚠ Kiểm quota TỪNG vùng | ⚠ CPU, IP, đĩa, GPU — đề này | | ⚠ Xin tăng quota TRƯỚC | ⚠ duyệt mất thời gian | | ⚠ Tính dư cho lỗi một vùng | | | Kiểm thử tải thật | | | Theo dõi mức dùng quota | ⚠ đặt cảnh báo khi gần chạm |

Từ khoá nhận diện:

"nhiều vùng, tài nguyên lớn, autoscale" → ⚠ kiểm quota từng vùng "chọn loại máy cụ thể" → ⚠ chưa đo mà đã chọn "một vùng + global LB" → ⚠ điểm hỏng đơn "Cloud Trace để đo tài nguyên" → ⚠ sai công cụ

⚠ Các loại quota hay chạm Quota
⚠ CPU theo vùng ⚠ phổ biến nhất
⚠ Địa chỉ IP ngoài
⚠ Dung lượng đĩa SSD
⚠ GPU ⚠ rất hạn chế, phải xin trước
Số instance trong MIG
⚠ Lưu ý ⚠ quota khác nhau giữa các vùng
⚠ Vì sao chạm quota nguy hiểm Lý do
⚠ Autoscaler im lặng KHÔNG thêm được máy
⚠ Thường phát hiện đúng lúc tải cao
⚠ Xin tăng quota mất thời gian ⚠ không kịp trong sự cố
Phòng ngừa ⚠ cảnh báo khi dùng tới 70–80% quota
⚠ Cân nhắc khi chọn loại máy Cân nhắc
⚠ Máy rất lớn = ít instance = hạt thô ⚠ mất một máy là mất nhiều năng lực
⚠ Máy nhỏ hơn, nhiều instance hơn ⚠ chịu lỗi tốt hơn, co giãn mịn hơn
⚠ Nhưng máy quá nhỏ thì tốn overhead
Nguyên tắc ⚠ đo nhu cầu thật rồi mới chọn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Quota từng vùng là bao nhiêu | ⚠ kiểm TRƯỚC khi triển khai | | Có cảnh báo khi gần chạm quota chưa | | | Mất một vùng thì các vùng còn lại có đủ quota không | |

Và cạm bẫy thầm lặng nhất khi triển khai đa vùng: quota được cấp riêng cho từng vùng và thường không đồng đều. Vùng chính có thể rộng rãi trong khi vùng dự phòng chật hẹp — và bạn chỉ phát hiện điều đó vào đúng lúc cần chuyển traffic sang.