Ngân hàng đề — AWS Certified Cloud Practitioner

Đáp án

*C — Một hoặc nhiều trung tâm dữ liệu ở cùng một vị trí

Vì sao đúng

Availability Zone là một hoặc nhiều trung tâm dữ liệu riêng biệt, mỗi cái có nguồn điện, làm mát, mạng và an ninh vật lý riêng, đặt trong cùng một khu vực địa lý.

Hai vế của định nghĩa đều quan trọng:

• "Một hoặc nhiều" — số trung tâm dữ liệu trong một AZ thay đổi; một AZ có thể chỉ gồm một trung tâm dữ liệu.
• "Cùng một vị trí" — các trung tâm dữ liệu trong một AZ nằm gần nhau để độ trễ giữa chúng rất thấp, nhưng vẫn tách biệt về hạ tầng nên một sự cố không ảnh hưởng cả nhóm.

Các AZ khác nhau trong cùng Region thì cách nhau hàng chục kilômét — đủ xa để tránh sự cố chung, đủ gần để độ trễ giữa chúng chỉ ở mức mili giây một chữ số.

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

• *D. Một hoặc nhiều trung tâm dữ liệu ở nhiều vị trí — sai ở vế cuối; đó mô tả Region chứ không phải AZ. Đây là phương án nhiễu chính.
• A và *B. Một hoặc nhiều rack máy chủ — sai về đơn vị: AZ được định nghĩa theo trung tâm dữ liệu, không theo rack. Một trung tâm dữ liệu chứa hàng nghìn rack.

Đáp án

D — Chi phí bản quyền phần mềm ứng dụng

Vì sao đúng

Sau khi chuyển lên AWS, công ty vẫn phải trả tiền bản quyền cho phần mềm của mình — hệ điều hành thương mại, cơ sở dữ liệu, phần mềm doanh nghiệp. AWS cung cấp hạ tầng chứ không cấp giấy phép cho phần mềm bạn chọn cài.

Có hai cách xử lý bản quyền trên AWS:

• License Included — giá giấy phép đã gộp vào giá instance (ví dụ EC2 chạy Windows, RDS cho SQL Server).
• Bring Your Own License (BYOL) — dùng giấy phép sẵn có; với giấy phép tính theo nhân hoặc socket thì cần Dedicated Host để chứng minh tuân thủ.

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

Ba phương án còn lại đều là chi phí AWS gánh và đã tính vào giá dịch vụ:

• A. Chi phí hạ tầng phần cứng trên AWS Cloud — AWS mua và thay thế phần cứng.
• B. Chi phí an ninh vật lý của trung tâm dữ liệu AWS — bảo vệ, kiểm soát ra vào, camera.
• C. Chi phí điện cho máy chủ trên AWS Cloud — điện và làm mát.

Chính việc không còn phải chi ba khoản này là một trong sáu lợi thế của điện toán đám mây.

Đáp án

A — Simple routing (định tuyến đơn giản)

Vì sao đúng

Simple routing là chính sách cơ bản nhất của Route 53: một bản ghi trỏ tới một tài nguyên duy nhất, ví dụ một máy chủ web.

Nó phù hợp khi bạn không cần phân chia lưu lượng, không cần chuyển dự phòng, không cần tối ưu theo vị trí — chỉ cần tên miền trỏ tới đúng một nơi.

Hai đặc điểm cần nhớ:

• Không hỗ trợ health check — Route 53 vẫn trả về địa chỉ đó dù máy chủ đã chết.
• Nếu khai nhiều giá trị trong một bản ghi simple, Route 53 trả về tất cả theo thứ tự ngẫu nhiên và client tự chọn — bạn không điều khiển được tỷ lệ.

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

Ba phương án còn lại đều dựng cho tình huống nhiều tài nguyên:

• B. Failover routing — có chính và dự phòng, chuyển đổi theo health check.
• C. Weighted routing — chia lưu lượng theo tỷ lệ bạn đặt.
• D. Latency-based routing — chọn endpoint có độ trễ thấp nhất với từng người dùng.

Lưu ý về một chính sách gần giống

Multivalue answer routing cũng trả về nhiều giá trị nhưng có health check — nó là phiên bản "simple có kiểm tra sức khoẻ", và thường là lựa chọn tốt hơn simple khi có nhiều máy chủ.

Đáp án

D và E — AWS Business Support và AWS Enterprise Support

Vì sao đúng

Truy cập lập trình tới AWS Support Center thực hiện qua AWS Support API, và API này chỉ dùng được từ gói Business trở lên:

Support API cho phép tạo, cập nhật, truy vấn và đóng ticket bằng mã — hữu ích khi bạn muốn tích hợp với hệ thống quản lý sự cố nội bộ (ServiceNow, Jira) hoặc tự động mở ticket khi hệ thống giám sát phát hiện vấn đề.

Nó cũng cho truy cập Trusted Advisor bằng API, nên bạn tự động hoá được việc kiểm tra tuân thủ thực hành tốt.

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

• C. Developer Support và B. Basic Support — chưa có Support API.
• A. "AWS Corporate Support" — không tồn tại; năm gói của AWS là Basic, Developer, Business, Enterprise On-Ramp và Enterprise. Đây là bẫy tên gọi.

Ghi chú

Enterprise On-Ramp cũng có Support API, nhưng nó không nằm trong các phương án của câu hỏi.

Đáp án

B và E — Amazon S3 Standard và Amazon S3 Intelligent-Tiering

Vì sao đúng

Phí lấy dữ liệu (data retrieval fee) là khoản tính thêm mỗi khi bạn đọc dữ liệu, và nó chỉ áp cho các lớp lưu trữ giá rẻ:

Intelligent-Tiering là lớp đáng chú ý nhất: nó tự chuyển đối tượng giữa các tầng theo mẫu truy cập, và không tính phí lấy dữ liệu ở bất kỳ tầng nào. Đổi lại, nó tính một khoản phí giám sát nhỏ cho mỗi đối tượng.

Đây chính là lý do Intelligent-Tiering đáng dùng khi không đoán được mẫu truy cập: bạn không bao giờ bị bất ngờ vì phí lấy dữ liệu.

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

• D. S3 Standard-IA, A. S3 One Zone-IA, C. S3 Glacier Flexible Retrieval — cả ba đều tính phí lấy dữ liệu. Đó chính là đánh đổi để có phí lưu trữ rẻ, và là lý do dữ liệu bị đọc thường xuyên hơn dự kiến có thể tốn hơn S3 Standard.

Đáp án

B — Business (Kinh doanh)

Vì sao đúng

AWS Cloud Adoption Framework có sáu góc nhìn, và Business là một trong số đó:

Ba góc nhìn đầu thiên về con người và quy trình, ba góc nhìn sau thiên về kỹ thuật.

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

• A. "Architecture", C. "Process", D. "Product" — cả ba đều không phải góc nhìn của AWS CAF. Chúng là những từ nghe rất hợp lý trong ngữ cảnh quản trị CNTT, nên rất dễ chọn nhầm.

Cách loại chúng là nhớ đúng sáu cái tên. Riêng "Architecture" là bẫy gần nhất vì nội dung kiến trúc có trong CAF — nhưng nó nằm trong góc nhìn Platform.

Đáp án

B và D — chia sẻ Reserved Instance giữa các tài khoản thành viên, và giảm giá theo khối lượng gộp chung

Vì sao đúng

Cả hai lợi ích đều đến từ thanh toán hợp nhất (consolidated billing):

• B. Chia sẻ Reserved Instance — khi bật RI sharing, mức giảm giá của RI mua ở một tài khoản áp được cho mức sử dụng phù hợp ở bất kỳ tài khoản nào trong tổ chức. RI thừa của bộ phận này tự động che phủ cho bộ phận kia.
• D. Giảm giá theo khối lượng gộp chung — mức sử dụng của tất cả tài khoản được cộng lại để tính bậc giá. Nhờ vậy cả tổ chức đạt bậc rẻ hơn so với từng tài khoản riêng lẻ. Áp cho EC2, S3, và nhiều dịch vụ có giá bậc thang khác.

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

Ba phương án còn lại đều là việc của dịch vụ khác, không phải Organizations:

• A. Triển khai bản vá lên EC2 ở các tài khoản thành viên — đó là Systems Manager Patch Manager.
• E. Kiểm tra lỗ hổng trên EC2 ở các tài khoản thành viên — đó là Amazon Inspector.
• C. Cấp phát Spot Instance ở các tài khoản thành viên — Spot là mô hình giá của EC2; bạn tạo nó trong từng tài khoản, Organizations không làm việc này.

Điểm chung của ba phương án sai: chúng là thao tác kỹ thuật trên tài nguyên, còn Organizations lo quản trị tài khoản và thanh toán. (Organizations hỗ trợ việc quản trị đa tài khoản qua SCP và tích hợp với các dịch vụ trên, nhưng bản thân nó không thực hiện các thao tác đó.)

Đáp án

A — VPC Interface Endpoint

Vì sao đúng

Đây là chi tiết cần nhớ chính xác: chỉ có hai dịch vụ hỗ trợ gateway endpoint — Amazon S3 và DynamoDB. Mọi dịch vụ khác, trong đó có SQS, dùng interface endpoint.

Interface endpoint (dựa trên AWS PrivateLink) tạo một elastic network interface có địa chỉ IP riêng ngay trong subnet của bạn. Mọi lời gọi API tới SQS đi qua đó — không ra Internet, không cần internet gateway hay NAT gateway.

Cấu hình kèm theo: bật private DNS để tên sqs.<region>.amazonaws.com tự phân giải về địa chỉ riêng, nhờ vậy ứng dụng và SDK không phải sửa gì.

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

• C. VPC Gateway Endpoint — không hỗ trợ SQS; chỉ dùng được cho S3 và DynamoDB. Đây là bẫy chính, và bảng dưới là thứ đáng nhớ:

  	Gateway endpoint	Interface endpoint
  Dịch vụ	Chỉ S3 và DynamoDB	Mọi dịch vụ khác
  Chi phí	Miễn phí	Tính phí giờ và phí dữ liệu
  Truy cập từ tại chỗ	Không	Có

• B. Internet Gateway — mở đường ra Internet, ngược với yêu cầu "riêng tư".

• D. AWS Direct Connect — nối trung tâm dữ liệu tại chỗ với AWS; đề hỏi kết nối từ VPC.

Đáp án

C và D — Internet Gateway và Subnet

Vì sao đúng

Cả hai đều là thành phần cấu thành của một VPC:

• D. Subnet — phân đoạn địa chỉ IP bên trong VPC, mỗi subnet nằm trong đúng một Availability Zone. Đây là nơi bạn đặt tài nguyên.
• C. Internet Gateway — gắn vào VPC để tài nguyên trong public subnet ra được Internet. Mỗi VPC gắn được tối đa một internet gateway.

Các thành phần khác của VPC: bảng định tuyến, network ACL, security group, NAT gateway, VPC endpoint, elastic network interface, và virtual private gateway.

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

• E. API Gateway — dịch vụ được quản lý để bạn xây API cho ứng dụng; nó nằm ngoài VPC. (Bạn tích hợp nó với tài nguyên trong VPC qua VPC Link, nhưng bản thân nó không phải thành phần của VPC.) Đây là phương án nhiễu chính vì tên có chữ "Gateway".
• A. AWS Storage Gateway — cầu nối cho ứng dụng tại chỗ truy cập lưu trữ đám mây; cũng có chữ "Gateway" nhưng không phải thành phần mạng.
• B. Object — đơn vị dữ liệu của Amazon S3, không liên quan tới VPC.

Ghi nhớ

Ba dịch vụ có chữ "Gateway" mà không thuộc VPC: API Gateway, Storage Gateway, và Transit Gateway (nó nối các VPC với nhau nhưng là tài nguyên độc lập, không nằm trong VPC nào).

Đáp án

C — Dùng được cả read replica lẫn Multi-AZ cho khôi phục thảm hoạ

Vì sao đúng

Cả hai đều đóng góp vào khôi phục thảm hoạ, chỉ ở mức độ và cách thức khác nhau:

• Multi-AZ — bản chờ đồng bộ ở AZ khác, tự động chuyển dự phòng khi bản chính hỏng. Đây là cơ chế khôi phục chính.
• Read replica — nhân bản bất đồng bộ, và nâng cấp thủ công thành bản chính độc lập được. Đặc biệt hữu ích khi replica nằm ở Region khác, vì Multi-AZ chỉ bảo vệ trong một Region.

Vì vậy khẳng định "dùng cả hai cho khôi phục thảm hoạ" là đúng.

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

Ba phương án còn lại đều dùng chữ "chỉ (only)" — và đó là chỗ làm chúng sai:

• D. Read replica chỉ để tăng hiệu năng đọc, Multi-AZ chỉ để khôi phục thảm hoạ — bỏ mất khả năng nâng cấp replica thành bản chính. Đây là phương án nhiễu chính vì nó mô tả đúng mục đích thiết kế của mỗi cái.
• B — đảo ngược hai vai trò.
• *A. Dùng cả hai để tăng hiệu năng đọc — sai ở Multi-AZ: bản chờ không phục vụ truy vấn nào, nó chỉ đứng chờ.

Bảng đối chiếu