Ngân hàng đề — AWS Certified CloudOps Engineer Associate

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

Đề đặt bạn vào vai SysOps Administrator đang viết một CloudFormation template bằng YAML. Template tạo ra hai resource: một EC2 instance và một RDS resource. Yêu cầu cuối cùng là: sau khi resource được tạo xong, output ra connection endpoint của RDS database.

Cụm từ quyết định đáp án là "output the connection endpoint for the RDS database" — nói cách khác, thứ cần lấy không phải là bản thân resource, không phải là một tham số bạn tự khai, mà là một thuộc tính (attribute) của resource chỉ tồn tại sau khi CloudFormation đã tạo xong nó. Endpoint address của một RDS instance là giá trị do AWS sinh ra lúc runtime, chỉ biết được khi stack chạy.

Đây chính là ranh giới phân biệt bốn intrinsic function trong danh sách: cái nào lấy được thuộc tính con của một resource đã tạo, chứ không chỉ lấy được "giá trị của resource" nói chung.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng theo tệp là A — !GetAtt.

Fn::GetAtt (viết tắt YAML là !GetAtt) trả về giá trị của một attribute thuộc về một resource trong template. Cú pháp là tên logic của resource cộng với tên attribute, ví dụ trong tài liệu AWS: !GetAtt myELB.DNSName (bản JSON là "Fn::GetAtt" : [ "myELB", "DNSName" ]) để lấy DNS name của một load balancer.

Áp vào tình huống của đề: RDS resource có các attribute liên quan tới endpoint kết nối, và cách duy nhất trong danh sách này để moi chúng ra trong khối Outputs là !GetAtt trỏ tới tên logic của RDS resource cộng với tên attribute endpoint tương ứng. Đúng như phần mô tả chung: intrinsic function tồn tại để gán giá trị cho những property chưa có cho tới lúc runtime — và endpoint của database là ví dụ kinh điển của loại giá trị đó.

❌ Vì sao các phương án còn lại sai

B — !Ref: Đây là phương án gần đúng nhất và cũng là bẫy chính. Ref trả về giá trị của một parameter hoặc một resource được chỉ định — tức là một giá trị duy nhất, mặc định gắn với đối tượng đó, chứ không cho bạn chọn attribute nào. Với resource, giá trị mặc định Ref trả về thường là định danh của resource (chẳng hạn tên/ID), không phải endpoint kết nối. Muốn nói rõ "tôi cần cái endpoint, không phải cái ID" thì bắt buộc phải dùng GetAtt để nêu tên attribute. Ref không có chỗ nào để diễn đạt điều đó.

C — !Sub: Fn::Sub thay thế biến trong một chuỗi đầu vào bằng giá trị bạn cung cấp, dùng để dựng command hay output có chứa giá trị chưa biết trước khi tạo/cập nhật stack. Nó là công cụ ghép chuỗi, không phải công cụ lấy giá trị. Nếu bạn muốn xuất ra một connection string đầy đủ, Sub có thể giúp ghép các mảnh lại — nhưng bản thân mảnh endpoint vẫn phải lấy từ nơi khác. Đề chỉ hỏi hàm nào trả về giá trị cần thiết, và Sub không phải là hàm tạo ra giá trị đó.

D — !FindInMap: Fn::FindInMap trả về giá trị ứng với các khoá trong một map hai cấp khai trong mục Mappings — ví dụ điển hình là RegionMap gắn AMI với từng AWS region. Toàn bộ dữ liệu nó đọc là thứ bạn tự viết cứng vào template từ trước. Endpoint của RDS thì ngược lại: nó chưa tồn tại lúc bạn viết template, nên không thể nằm sẵn trong Mappings. Phương án này lệch hẳn về bản chất, không chỉ lệch chi tiết.

📌 Điểm cần nhớ

• Quy tắc phân biệt nhanh: cần một attribute cụ thể của resource → !GetAtt; cần chính resource hay parameter đó → !Ref. Endpoint, DNS name, ARN, địa chỉ… đều là attribute, nên đều thuộc nhóm GetAtt.
• Cú pháp !GetAtt <TênLogicResource>.<TênAttribute> — dấu chấm là chỗ bạn nêu rõ mình muốn attribute nào, và đó cũng chính là thứ Ref không có.
• !Sub là hàm ghép chuỗi, không phải hàm lấy giá trị; nó thường đi kèm GetAtt/Ref chứ không thay thế được chúng.
• !FindInMap chỉ đọc dữ liệu tĩnh do bạn khai trong Mappings. Hễ đề nhắc tới giá trị "chỉ biết sau khi tạo xong" thì loại nó ngay.
• Mẹo đọc đề dạng này: tìm cụm từ chỉ thời điểm giá trị xuất hiện ("once your resources are created", "at runtime", "after the stack is created"). Giá trị sinh lúc runtime luôn đẩy đáp án về phía GetAtt.

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

Đề mô tả một systems administrator đang cấu hình alarm cho EC2 status check, để gửi thông báo tới một SNS topic. Câu hỏi cuối cùng chỉ hỏi đúng một điều: chọn CloudWatch metric nào.

Cụm từ quyết định nằm ở vế cuối của câu mô tả: "when the instance fails either the instance check or system status check". Đây là ràng buộc phân biệt duy nhất, vì:

• EC2 phát ra ba metric status check khác nhau trong namespace AWS/EC2, mỗi cái theo dõi một phạm vi khác nhau.
• Nếu đề chỉ nói "instance status check" thì đáp án sẽ khác; nếu chỉ nói "system status check" thì lại khác nữa.
• Chữ either… or… báo rằng ta cần một metric duy nhất bao trùm cả hai loại kiểm tra, chứ không phải hai alarm riêng lẻ hay một metric chuyên biệt.

Nói cách khác: bài toán là "một alarm, một SNS topic, kích hoạt khi bất kỳ loại status check nào hỏng".

✅ Vì sao đáp án đúng là đúng

Đáp án đúng là B — StatusCheckFailed.

Metric này báo cáo liệu instance có vượt qua CẢ instance status check LẪN system status check trong phút vừa rồi hay không. Giá trị của nó là nhị phân: 0 nghĩa là qua hết, 1 nghĩa là có hỏng. Chính vì nó tổng hợp cả hai loại kiểm tra vào một chỉ số duy nhất, nên chỉ cần một check nào đó hỏng là metric nhảy lên 1 — khớp chính xác với yêu cầu "either… or…" trong đề.

Đây là metric duy nhất trong danh sách cho phép cấu hình một alarm duy nhất đẩy notification sang SNS topic mà vẫn bắt được cả hai tình huống hỏng. Theo tài liệu, các metric status check được phát ở tần suất một phút và mặc định không tính phí; với instance vừa khởi chạy, dữ liệu chỉ xuất hiện sau khi instance hoàn tất giai đoạn khởi tạo, tức là vài phút sau khi vào trạng thái running.

❌ Vì sao các phương án còn lại sai

A — StatusCheckFailed_Instance: Đây là metric có thật và rất gần đúng, nên là distractor mạnh nhất. Nó báo cáo instance có vượt qua instance status check hay không (cũng là giá trị 0/1, cũng theo phút). Chỗ nó hỏng: phạm vi hẹp hơn đề yêu cầu. Instance status check chỉ soi các vấn đề nằm ở chính instance (phần mềm/cấu hình mạng của instance, kernel treo, hệ điều hành hỏng…). Dùng metric này thì khi system status check hỏng — tức là vấn đề của hạ tầng vật lý bên dưới — alarm sẽ im lặng, và administrator sẽ không nhận được notification. Muốn dùng A thì phải dựng thêm một alarm nữa cho vế còn lại, trong khi đề chỉ hỏi một metric.

C — CombinedStatusCheckFailed: Cái tên nghe rất hợp lý — "combined" đúng nghĩa là "gộp cả hai", đúng cái mà đề đang cần — nên đây là bẫy đánh vào trực giác. Nhưng metric này không tồn tại; nó là tên bịa ra làm mồi nhử. Trong AWS/EC2 không có metric nào tên như vậy, nên chọn nó thì alarm không có dữ liệu nào để bám vào. Bài học: đừng chọn metric chỉ vì tên nghe khớp mô tả — phải nhớ đúng danh sách tên metric thật.

D — StatusCheckFailed_System: Cũng là metric có thật, đối xứng với A. Nó báo cáo instance có vượt qua system status check hay không (0/1, theo phút). System status check theo dõi các vấn đề ở tầng hạ tầng AWS bên dưới instance — thứ mà thường phải stop/start instance (để chuyển sang host khác) mới khắc phục được. Nó sai vì lý do ngược với A: bỏ sót hoàn toàn nhóm lỗi thuộc về chính instance. Đề yêu cầu bắt cả hai, D chỉ bắt một nửa.

📌 Điểm cần nhớ

• Namespace AWS/EC2 có ba metric status check thật: StatusCheckFailed (tổng hợp cả hai), StatusCheckFailed_Instance (chỉ instance check), StatusCheckFailed_System (chỉ system check). Nhớ đúng ba cái tên này là giải được cả họ câu hỏi dạng này.
• Đọc kỹ từ nối trong đề: "either… or…" / "both" → chọn metric tổng hợp StatusCheckFailed; đề nêu đích danh một loại check → chọn đúng biến thể có hậu tố _Instance hoặc _System.
• Cả ba metric đều là giá trị nhị phân 0 = passed, 1 = failed theo từng phút, nên alarm thường đặt ngưỡng dạng "≥ 1". Với instance mới khởi chạy, phải đợi qua giai đoạn khởi tạo mới có số liệu — đừng tưởng thiếu dữ liệu là cấu hình sai.
• Phân biệt bản chất hai loại check để chọn hành động khắc phục: instance status check hỏng thường nằm ở phía instance (OS, kernel, cấu hình mạng của instance); system status check hỏng nằm ở hạ tầng bên dưới. Đây cũng là lý do người ta hay ghép alarm với recovery/restart action tương ứng.
• Cảnh giác với phương án mang cái tên "nghe quá vừa vặn" như CombinedStatusCheckFailed — trong đề thi AWS, distractor bịa tên là kiểu bẫy phổ biến.

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

Đề mô tả một nhóm quản trị hệ thống đang cấu hình các metric của Amazon EC2 gửi sang Amazon CloudWatch, và họ cần một metric giúp "identify the processing power required to run an application on the selected instance" — nhận biết lượng năng lực xử lý mà ứng dụng cần khi chạy trên instance đã chọn.

Cụm từ quyết định là "processing power required to run an application" đi kèm với "on the selected instance". Hai chi tiết này gộp lại có nghĩa: cần một metric đo mức tiêu thụ CPU của chính instance đó, tính trên phần compute đã được cấp cho instance. Đây là metric EC2 tiêu chuẩn mà CloudWatch thu thập sẵn, không phải metric đếm tài nguyên và cũng không phải metric riêng của một cơ chế thanh toán CPU nào đó.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng theo tệp là D — CPUUtilization.

CPUUtilization cho biết phần trăm số compute unit đã cấp cho instance đang được sử dụng tại thời điểm đo. Đơn vị của nó là Percent. Chính vì nó phản ánh trực tiếp mức chiếm dụng CPU của workload đang chạy, đây là metric dùng để xác định năng lực xử lý mà ứng dụng cần trên instance đang xét: theo dõi nó qua thời gian sẽ thấy ứng dụng ăn bao nhiêu phần CPU, từ đó biết instance hiện tại có thừa hay thiếu sức.

Một lưu ý mà tài liệu AWS nêu rõ: tuỳ loại instance, công cụ đo bên trong hệ điều hành có thể hiển thị con số thấp hơn CloudWatch khi instance không được cấp trọn một processor core. Khi đối chiếu hai nguồn số liệu mà thấy lệch, đó là nguyên nhân thường gặp chứ không phải metric sai.

❌ Vì sao các phương án còn lại sai

A — CPUProcessPower: đây là metric không tồn tại, được đặt ra thuần tuý làm mồi nhử. Tên nghe rất khớp với chữ "processing power" trong đề nên dễ bị chọn theo phản xạ khớp từ khoá. Bài học ở đây là chọn theo tên nghe giống đề là cách rơi bẫy nhanh nhất; phải nhớ danh mục metric có thật của EC2.

B — CPUCreditUsage: metric này có thật, nhưng đo thứ khác — số CPU credit mà instance đã tiêu cho hoạt động CPU, đơn vị là Credits (vCPU-minutes). Đây là phương án gần đúng nhất vì nó cũng liên quan tới CPU, nhưng nó nói về cơ chế credit của các họ instance burstable, tức là về việc instance còn "ngân sách" để bùng công suất hay không, chứ không phải mức chiếm dụng CPU của ứng dụng. Nó cũng chỉ có sẵn ở tần suất năm phút, và nếu chọn chu kỳ dài hơn thì phải dùng thống kê Sum thay vì Average. Với một câu hỏi chung về "năng lực xử lý mà ứng dụng cần" — không hề nhắc tới burstable hay hết credit — thì đây là metric hẹp và sai trọng tâm.

C — ResourceCount: metric này đếm số lượng tài nguyên thuộc loại được chỉ định đang chạy trong tài khoản, phân loại theo các dimension gắn kèm. Nó trả lời câu hỏi "có bao nhiêu cái", hoàn toàn không nói gì về tải xử lý bên trong một instance cụ thể. Đề đã khoanh vùng vào "the selected instance" nên một metric ở mức tài khoản không thể là đáp án.

📌 Điểm cần nhớ

• CPUUtilization là metric EC2 chuẩn cho câu hỏi dạng "ứng dụng cần bao nhiêu năng lực xử lý" — đơn vị Percent, đo phần compute đã cấp đang được dùng.
• Tên metric nghe khớp y hệt từ khoá trong đề (CPUProcessPower) thường là mồi nhử bịa ra; hãy kiểm tra metric đó có thật trong danh mục EC2 không trước khi chọn.
• CPUCreditUsage chỉ liên quan tới cơ chế credit của instance burstable, đơn vị Credits, tần suất năm phút và nên dùng thống kê Sum khi chu kỳ dài hơn — chỉ chọn khi đề nhắc tới credit hoặc hiện tượng tụt hiệu năng do cạn credit.
• Phân biệt metric mức instance (CPUUtilization, CPUCreditUsage) với metric mức tài khoản (ResourceCount): đề khoanh vùng vào "the selected instance" thì mọi metric đếm tài nguyên toàn tài khoản đều loại được ngay.
• Số CloudWatch báo có thể cao hơn số công cụ trong OS hiển thị khi instance không được cấp trọn một core — chênh lệch này là bình thường.

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

Đề mô tả một tổ chức có nhiều AWS account tách theo mảng nghiệp vụ. Một user thuộc account Finance cần đọc báo cáo nằm trong S3 bucket của hai account khác (HR và Audit), rồi copy các báo cáo đó về S3 bucket của chính account Finance.

Có hai cụm từ quyết định đáp án:

• "multiple AWS accounts" / truy cập từ account này sang account kia — đây là bài toán cross-account access, nên chỉ một phía cấp quyền là không đủ.
• "copy these reports back to the S3 bucket in the Finance account" — user phải đồng thời giữ được quyền trên tài nguyên của chính account Finance (để ghi vào bucket đích) trong lúc đang đọc bucket ở account khác.

Cụm thứ hai là ràng buộc phân biệt giữa hai hướng làm cross-account: dùng IAM role để assume, hay dùng resource-based policy. Cả hai đều là cách hợp lệ để chia sẻ S3 giữa các account, nhưng chỉ một cách giữ được quyền hai bên cùng lúc.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng theo tệp là B: tạo identity-based policy trong account Finance cho phép user gửi request tới S3 bucket của HR và Audit, đồng thời tạo resource-based policy (bucket policy) ở HR và Audit cho phép principal đến từ Finance truy cập bucket tương ứng.

Hai loại policy này khác nhau ở chỗ gắn vào đâu: identity-based policy gắn vào IAM user, group hoặc role và mô tả identity đó được làm gì; resource-based policy gắn thẳng vào tài nguyên (S3 bucket, SQS queue, KMS key...) và mô tả ai được động vào tài nguyên đó. Khi đánh giá một request, AWS xét cả hai cùng nhau: trước hết tìm Deny — có Deny là chặn ngay; sau đó tìm Allow — chỉ cần một statement cho phép là request đi qua, không quan trọng Allow nằm ở identity-based hay resource-based policy.

Nhưng quy tắc "một Allow là đủ" chỉ áp dụng trong cùng một account. Với request đi từ account A sang account B, yêu cầu chặt hơn: principal ở account A phải có identity-based policy cho phép gọi tới tài nguyên ở account B, và resource-based policy ở account B phải cho phép principal đó. Thiếu bất kỳ vế nào thì request thất bại. Vì vậy phương án duy nhất mô tả đủ cả hai vế mới là phương án đúng.

Cách dùng resource-based policy cũng khớp với yêu cầu copy: user vẫn làm việc với danh tính gốc trong account Finance, không phải đánh đổi quyền hiện có để nhận quyền của role — nên vẫn ghi được vào bucket Finance trong khi đọc bucket HR/Audit.

❌ Vì sao các phương án còn lại sai

A. Tạo IAM role ở HR và Audit để user Finance assume — Đây không phải cấu hình sai về kỹ thuật, và là lý do nó gần đúng nhất. Vấn đề nằm ở đặc điểm của AssumeRole: khi assume một role ở account khác, principal tạm thời từ bỏ bộ quyền gốc của mình để nhận bộ quyền của role. Trong lúc đang mang credentials của role ở HR/Audit, user không còn quyền của chính mình ở Finance nữa, nên thao tác "copy về bucket Finance" bị gãy ở nửa sau. Resource-based policy không có nhược điểm này — principal vẫn ở account tin cậy và giữ nguyên quyền của mình, đúng kiểu tác vụ sao chép dữ liệu qua lại giữa hai account.

C. Chỉ tạo resource-based policy ở HR và Audit — Thiếu đúng một vế. Chỉ cần resource-based policy là đủ khi request phát sinh trong cùng một AWS account. Ở đây request đi xuyên account, nên vẫn phải có identity-based policy phía Finance cho phép user gọi ra bucket bên ngoài. Bỏ vế này thì request bị từ chối ngay ở phía account của người gọi.

D. Tạo "resource-level permissions" ở HR và Audit — Phương án này đánh vào việc dễ nhầm lẫn thuật ngữ. Resource-level permissions không phải resource-based policy: nó chỉ nói tới khả năng dùng ARN để chỉ đích danh từng tài nguyên trong một policy (thay vì Resource: "*"), tức vẫn là một chi tiết bên trong policy chứ không phải một loại policy gắn vào tài nguyên. Resource-based policy thì gắn trực tiếp lên tài nguyên và chỉ được một số service hỗ trợ. Diễn đạt của phương án D vì thế không mô tả được cơ chế cấp quyền cross-account cần thiết.

📌 Điểm cần nhớ

• Cross-account thì cần policy ở cả hai đầu: identity-based policy ở account của người gọi và resource-based policy ở account chứa tài nguyên. Trong cùng một account thì một Allow ở bất kỳ bên nào là đủ.
• Thứ tự đánh giá luôn là: quét Deny trước — có là chặn; rồi mới quét Allow.
• AssumeRole đánh đổi quyền, resource-based policy thì không. Đề bài nào có yêu cầu thao tác đồng thời trên tài nguyên của cả hai account (copy, sync, di chuyển dữ liệu) thì nghiêng về resource-based policy; role phù hợp hơn khi chỉ cần làm việc trong account đích.
• Phân biệt resource-based policy (policy gắn vào tài nguyên, chỉ một số service hỗ trợ) với resource-level permissions (chỉ định tài nguyên bằng ARN bên trong policy) — hai khái niệm khác nhau, đề thi hay dùng cặp này làm bẫy.

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

Một công ty bán lẻ chuyển hạ tầng lên AWS Cloud. Họ đã viết sẵn nhiều script tuỳ chỉnh để giám sát các instance chạy ứng dụng, và muốn tái sử dụng chính những script đó trên AWS. Từ đó, đội phát triển đặt câu hỏi: làm thế nào để tắt (disable) các status check có sẵn của Amazon EC2.

Cụm từ quyết định đáp án là "disable the pre-existing Amazon EC2 status checks" — đề không hỏi cách thay thế cơ chế giám sát, cũng không hỏi cách bỏ qua kết quả check, mà hỏi thẳng vào khả năng tắt chúng.

Điểm mấu chốt để phân biệt bốn phương án là chỗ này: status check là cơ chế được xây dựng sẵn bên trong Amazon EC2 (built into EC2), không phải một tính năng mà người dùng bật/tắt hay cấu hình. Vì vậy câu trả lời không nằm ở "tắt ở đâu", mà ở "không tắt được". Mỗi phương án sai đều cố gán cho status check một mức độ điều khiển nào đó — tắt một nửa, tắt qua console khác, hoặc xoá khỏi cấu hình — và đó chính là chỗ chúng hỏng.

Lưu ý thêm: việc công ty muốn dùng script giám sát riêng hoàn toàn hợp lệ, nhưng chuyện đó không liên quan tới việc EC2 có cho tắt status check hay không. Hai thứ chạy song song, không loại trừ nhau.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng theo tệp là D — "Status checks are built into Amazon EC2, so they cannot be disabled or deleted".

Với instance status monitoring, Amazon EC2 tự động thực hiện kiểm tra trên mọi instance đang chạy để phát hiện các vấn đề về phần cứng và phần mềm. Người dùng xem được kết quả các check này để nhận diện những sự cố cụ thể có thể ngăn instance chạy ứng dụng.

Các check chạy định kỳ và trả về kết quả pass hoặc fail. Nếu tất cả đều pass, trạng thái tổng thể của instance là OK; nếu một hoặc nhiều check fail, trạng thái tổng thể là impaired. Vì cơ chế này được nhúng thẳng vào Amazon EC2 nên nó không thể bị disable và cũng không thể bị delete — đúng như phát biểu của phương án D.

Điều người dùng làm được là phản ứng với kết quả: khi một status check fail, CloudWatch metric tương ứng được tăng lên. Từ metric đó có thể tạo CloudWatch alarm — ví dụ alarm cảnh báo khi status check fail trên một instance cụ thể, hoặc alarm tự động recover instance khi nó rơi vào trạng thái impaired do sự cố ở tầng hạ tầng bên dưới. Nhưng đó là dùng kết quả check, không phải tắt check.

❌ Vì sao các phương án còn lại sai

A — "Check phần cứng không tắt được, nhưng check phần mềm thì tắt được": đây là phương án gần đúng nhất và cũng gài bẫy khéo nhất, vì nó nói đúng một nửa sự thật — EC2 thật sự kiểm tra cả hardware issues lẫn software issues. Nhưng nó bịa thêm một sự phân biệt không tồn tại: không có nhóm check nào trong hai nhóm đó được phép tắt. Cả hai đều là phần tích hợp sẵn của EC2. Ai chỉ nhớ mơ hồ "có hai loại check" rất dễ chọn phương án này.

B — "Status check gắn với CloudWatch metrics, tắt được từ CloudWatch metrics console": phần tiền đề đúng, phần kết luận sai. Kết quả status check đúng là được đẩy sang CloudWatch dưới dạng metric, và đó là lý do lập được alarm. Nhưng quan hệ ở đây một chiều: CloudWatch là nơi nhận và hiển thị kết quả, không phải nơi điều khiển việc EC2 có chạy check hay không. Trong CloudWatch console bạn xoá được alarm mình tạo ra, chứ không tắt được bản thân status check.

C — "Không disable được, nhưng delete được khỏi active configuration": phương án này thừa nhận đúng vế đầu rồi hỏng ở vế sau, bằng cách dựng ra một khái niệm không có thật — "active configuration" của status check. Status check không tồn tại như một mục cấu hình mà người dùng thêm vào hoặc gỡ ra khỏi instance; nó là hành vi mặc định của nền tảng. Không disable được thì cũng không delete được, hai vế không tách rời như phương án này ngụ ý.

📌 Điểm cần nhớ

• Status check của Amazon EC2 là cơ chế built-in: không disable được, không delete được, áp dụng cho mọi instance đang chạy — cả check hardware lẫn check software.
• Trạng thái tổng thể của instance là OK khi mọi check pass, và impaired khi có ít nhất một check fail.
• CloudWatch là nơi tiêu thụ kết quả status check chứ không phải nơi điều khiển: từ metric có thể tạo alarm để cảnh báo, hoặc alarm tự động recover instance bị impaired.
• Gặp câu hỏi có dạng "làm sao tắt tính năng X", hãy kiểm tra trước xem X có phải tính năng tuỳ chọn không. Với các cơ chế nền tảng như EC2 status check, đáp án đúng thường là "không tắt được", còn các phương án sai sẽ gợi ý một chỗ tắt nghe rất hợp lý (console khác, tắt một phần, xoá khỏi cấu hình).
• Việc dùng script giám sát riêng và việc EC2 chạy status check là hai thứ song song — có cái này không có nghĩa là bỏ được cái kia.

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

Đề mô tả một CloudFront distribution có origin là Amazon S3 bucket, chạy ổn định từ trước tới nay, rồi vài giờ gần đây bắt đầu trả lỗi:

The authorization header is malformed; the region '<AWS Region>' is wrong; expecting '<AWS Region>'

Có ba cụm từ trong đề quyết định đáp án:

• "has worked fine so far" — cấu hình vốn đúng. Vậy nguyên nhân không phải lỗi thiết kế ban đầu, mà là một thứ vừa thay đổi.
• "the region ... is wrong; expecting ..." — thông báo nói về hai Region khác nhau: Region mà CloudFront ký request tới, và Region mà S3 thực sự đang phục vụ bucket. Đây là lỗi ở tầng ký SigV4, không phải lỗi mạng hay lỗi timeout.
• "authorization header is malformed" — chữ authorization dễ khiến người đọc nghĩ tới khoá/quyền, nhưng ở đây header đó do chính CloudFront tạo ra khi ký request tới origin S3. Nó "malformed" vì được ký cho sai Region.

Ghép lại: CloudFront vẫn nhớ Region cũ của bucket, còn bucket thì đã nằm ở Region khác.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng theo tệp là B.

CloudFront khi lấy object từ origin S3 sẽ ký request theo Signature Version 4, và chữ ký gắn liền với Region của bucket mà distribution đang lưu trong cấu hình origin. Nếu bucket bị xoá ở Region này rồi tạo lại cùng tên ở Region khác, tên origin không đổi nên cấu hình trông vẫn "đúng", nhưng chữ ký lại mang Region cũ. S3 nhận request, thấy Region trong chữ ký không khớp Region thật của bucket, và trả về HTTP 400 Bad Request kèm đúng thông báo trong đề.

Điều này cũng giải thích vì sao lỗi xuất hiện đột ngột sau một thời gian chạy tốt: mọi thứ vẫn nguyên vẹn cho tới lúc có người di chuyển bucket. Cách sửa là cập nhật lại distribution để nó trỏ tới bucket ở Region hiện tại — cập nhật origin domain name/Region trong cấu hình origin, chứ không phải đụng vào bản thân bucket.

❌ Vì sao các phương án còn lại sai

A. Origin không phản hồi kịp trước khi request hết hạn, do firewall hoặc Security Group chặn. Đây là mô tả của một lớp lỗi hoàn toàn khác: khi origin im lặng quá lâu, CloudFront trả Gateway Timeout (504), không phải 400 với thông báo về Region. Ngoài ra, S3 là dịch vụ managed truy cập qua endpoint công khai — nó không nằm sau Security Group như một EC2 instance, nên phần lý giải cũng không áp được vào tình huống origin là S3.

C. API key dùng để authorize thuộc Region khác với Region của bucket. Nghe rất hợp tai vì cũng nói tới "sai Region", nhưng AWS không có khái niệm access key gắn theo Region — credential của IAM là toàn cục. Đây là phương án bịa ra để đánh lạc hướng đúng người đã đọc lướt thông báo lỗi và chỉ bắt được chữ authorization.

D. CloudFront distribution và S3 phải nằm cùng một Region; hãy chuyển một trong hai. Đây là phương án gần đúng nhất và cũng nguy hiểm nhất, vì nó nhắc tới đúng hai dịch vụ trong đề. Nhưng nó sai ở tiền đề: CloudFront không phải dịch vụ theo Region. Nó chạy trên mạng lưới edge location và regional edge cache toàn cầu, và hoàn toàn bình thường khi phục vụ một bucket đặt ở bất kỳ Region nào. Không hề tồn tại yêu cầu "cùng Region" giữa distribution và origin, nên hành động "chuyển một tài nguyên cho cùng Region" vừa không cần thiết vừa không chữa được lỗi. Vấn đề thật là distribution đang ghi nhớ sai Region, chứ không phải hai bên khác Region.

📌 Điểm cần nhớ

• Đọc mã lỗi trước khi đọc lời văn: 400 Bad Request với thông báo về Region là vấn đề ký request/cấu hình origin; 504 Gateway Timeout mới là chuyện origin không phản hồi kịp.
• Tên bucket là toàn cục nhưng bucket thì thuộc về một Region cụ thể. Xoá rồi tạo lại cùng tên ở Region khác sẽ để lại mọi cấu hình trỏ tới nó ở trạng thái "trông thì đúng mà chạy thì hỏng".
• CloudFront là dịch vụ toàn cầu, không cần và không thể "đặt cùng Region" với origin. Bất kỳ phương án nào yêu cầu điều đó đều đáng nghi.
• Access key/credential của IAM không gắn với Region; phương án nào nói "key thuộc Region X" là phương án bịa.
• Với lỗi xuất hiện đột ngột trên hệ thống vốn chạy tốt, hãy tìm thay đổi gần đây thay vì rà lại thiết kế ban đầu.

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

Đề mô tả một hạ tầng EC2 nằm trong Auto Scaling Group, phía trước là Elastic Load Balancer, và toàn bộ được quản lý bằng một môi trường Elastic Beanstalk. Yêu cầu: tự động thay thế các EC2 instance không khoẻ.

Hai cụm từ trong đề quyết định đáp án, và chúng tách bài toán thành hai câu hỏi nhỏ:

1. "automate the replacement of unhealthy Amazon EC2 instances" — quyết định giá trị của health check type. Mặc định ASG dùng health check kiểu EC2, chỉ nhìn status check của máy ảo (hardware, network, hệ điều hành). Ứng dụng chết mà máy vẫn chạy thì status check vẫn xanh, ASG không thay thế gì cả. Muốn ASG hành động theo tình trạng ứng dụng thì phải chuyển sang kiểu ELB — lúc đó ASG tin vào kết quả health check của load balancer.
2. "this AWS architecture is maintained via an Elastic Beanstalk environment" — quyết định cách thay đổi. Beanstalk là lớp quản lý đứng trên ASG và ELB; nó tự dựng lại các tài nguyên đó theo định nghĩa môi trường. Sửa tay ở console của dịch vụ bên dưới thì thay đổi không bền vững.

Bốn phương án chính là bốn tổ hợp của hai trục này: chiều đổi (EC2 → ELB hay ELB → EC2) và nơi đổi (console EC2 hay configuration file). Chỉ một tổ hợp đúng cả hai.

✅ Vì sao đáp án đúng là đúng

C — đổi health check type của Auto Scaling group từ EC2 sang ELB, bằng configuration file của môi trường Beanstalk.

Vế thứ nhất giải quyết đúng vấn đề nghiệp vụ. Status check của EC2 chỉ phủ sức khoẻ của bản thân instance, không phủ ứng dụng, web server hay container đang chạy bên trong. Khi ứng dụng sập, load balancer phát hiện được và ngừng gửi traffic tới instance đó — nhưng tự nó chỉ loại khỏi target, chứ không thay thế instance. Việc thay thế là của Auto Scaling group, mà ASG chỉ thay thế khi chính nó coi instance là unhealthy. Chuyển health check type sang ELB là cách nối hai mảnh đó lại: kết luận unhealthy của load balancer trở thành tín hiệu để ASG terminate và launch instance mới.

Vế thứ hai giải quyết đúng vấn đề vận hành. Với môi trường Elastic Beanstalk, cách cấu hình được hỗ trợ là dùng configuration file (.ebextensions) — cấu hình nằm trong chính định nghĩa môi trường, nên mọi lần Beanstalk cập nhật hay dựng lại tài nguyên đều áp lại thiết lập này. Đó cũng là điều "automate" trong đề đòi hỏi: không phải một thao tác thủ công lặp lại, mà một cấu hình sống cùng môi trường.

❌ Vì sao các phương án còn lại sai

A — sửa trực tiếp trong console EC2, đổi health check type thành EC2. Sai cả hai trục. EC2 đã là giá trị mặc định, nên đây gần như là không làm gì; và kiểu EC2 chính là nguyên nhân khiến instance có ứng dụng chết vẫn không bị thay thế. Thêm nữa, sửa từ console EC2 là đụng thẳng vào tài nguyên do Beanstalk quản lý.

B — sửa trực tiếp trong console EC2, đổi health check type thành ELB. Đây là phương án gần đúng nhất, và cũng là bẫy chính của câu hỏi. Giá trị đích hoàn toàn chính xác: ELB đúng là kiểu health check cần thiết. Chỗ hỏng nằm ở nơi thực hiện. Với tài nguyên do Elastic Beanstalk tạo ra, thay đổi cấu hình thực hiện trực tiếp từ console của dịch vụ bên dưới không được bảo toàn — Beanstalk có thể dựng lại hoặc cập nhật tài nguyên theo định nghĩa môi trường và ghi đè lên thiết lập sửa tay. Kết quả: giải pháp có vẻ chạy ngay lúc bấm, rồi âm thầm mất hiệu lực về sau. Với một yêu cầu nói rõ là "automate", một cấu hình không bền vững thì không đạt.

D — dùng configuration file, nhưng đổi từ ELB sang EC2. Đúng nơi, sai chiều. Cách làm (configuration file của Beanstalk) là cách được hỗ trợ, nhưng chiều đổi bị đảo ngược. Đưa health check type về EC2 là quay lại đúng trạng thái mặc định gây ra vấn đề: ASG chỉ nhìn status check của máy ảo, bỏ qua kết luận của load balancer về sức khoẻ ứng dụng. Instance chạy ứng dụng đã chết sẽ nằm lại đó, không được thay thế.

📌 Điểm cần nhớ

• EC2 health check ≠ application health check. Status check của EC2 chỉ nói máy ảo còn sống; ứng dụng sập bên trong một instance khoẻ mạnh sẽ không bị phát hiện.
• ELB phát hiện, ASG thay thế. Load balancer chỉ ngừng gửi traffic tới instance unhealthy; muốn instance đó bị terminate và tạo lại thì Auto Scaling group phải dùng health check type là ELB.
• Trong môi trường Elastic Beanstalk, cấu hình tài nguyên bên dưới phải đi qua configuration file (.ebextensions). Sửa trực tiếp trong console của ASG, ELB hay EC2 — hoặc cài gói, tạo file, chạy lệnh ngay trên instance — đều là thay đổi không bền vững.
• Với dạng câu hỏi có Beanstalk trong đề, hãy tách thành hai kiểm tra riêng: giá trị cấu hình có đúng không và cấu hình có được áp theo cách Beanstalk quản lý không. Phương án sai thường chỉ hỏng một trong hai.

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

Đề mô tả một tình huống rất cụ thể: một quản lý mới được tuyển vào đã có sẵn một Gemalto MFA device dùng từ công ty cũ, và câu hỏi là làm sao cấu hình chính thiết bị đó cho tài khoản AWS ở công ty mới.

Cụm từ quyết định đáp án là "his existing Gemalto MFA device" — thiết bị phần cứng đã được đăng ký và gắn với một bên khác từ trước. Cụm thứ hai đáng chú ý là "he used in his earlier company": nó xác nhận thiết bị không phải hàng mới mua, mà đã có lịch sử sử dụng bên ngoài AWS.

Điểm mấu chốt nằm ở cách hardware MFA token hoạt động: AWS MFA cần biết được secret duy nhất nằm trong thiết bị thì mới sinh và đối chiếu được mã OTP. Secret đó không phải thứ nhập tay hay tự tạo lại được từ phía người dùng — nó được nạp vào thiết bị lúc sản xuất và bàn giao cho bên phát hành. Câu hỏi đang kiểm tra xem thí sinh có hiểu ràng buộc này hay không, chứ không kiểm tra thao tác trên console.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng là A — AWS MFA does not support the use of your existing Gemalto device.

Lý do: AWS MFA dựa vào việc nắm giữ một secret duy nhất gắn với hardware MFA device (ở đây là Gemalto). Vì ràng buộc bảo mật quy định các secret như vậy không bao giờ được chia sẻ giữa nhiều bên, AWS không thể tiếp nhận secret của một thiết bị Gemalto đã được cấp phát cho tổ chức khác. Hệ quả là không có cách nào "chuyển" hay "đăng ký lại" thiết bị cũ sang AWS.

Chỉ hardware MFA device mua mới, tương thích, từ Gemalto mới dùng được với AWS MFA — vì khi đó secret đi thẳng từ nhà sản xuất tới AWS, không qua bên thứ ba nào khác.

Nói cách khác, giới hạn ở đây là giới hạn về mô hình tin cậy, không phải giới hạn kỹ thuật của thiết bị hay thiếu tính năng trên console.

❌ Vì sao các phương án còn lại sai

B — cần "formal approval" giữa AWS và công ty cũ để dùng chung thiết bị. Đây là phương án bịa hoàn toàn, đặt vào chỉ để gây nhiễu. Không tồn tại quy trình phê duyệt nào giữa AWS và công ty cũ của nhân viên để chia sẻ secret của MFA device. Câu này còn nói sai cả nguyên tắc: ràng buộc bảo mật ở đây là không chia sẻ, chứ không phải "chỉ chia sẻ trong trường hợp ngoại lệ có phê duyệt".

C — secret phải được "generate lại" với AWS MFA để thiết bị Gemalto hoạt động. Đây là phương án gần đúng nhất và cũng là bẫy chính: nửa đầu của nó đúng — AWS MFA thật sự dựa vào một secret duy nhất gắn với hardware MFA device. Nhưng nửa sau sai ở kết luận: không có thao tác nào cho phép sinh lại secret của một hardware token đã tồn tại rồi nạp nó sang AWS. Secret nằm trong thiết bị phần cứng; nếu "tạo lại" được từ phía người dùng thì chính cơ chế bảo mật của hardware MFA đã vô nghĩa. Phương án này mô tả đúng cơ chế nhưng suy ra một kết luận không có thật.

D — dùng lại được thiết bị Gemalto vì Gemalto không chia sẻ secret giữa nhiều bên. Phương án này đảo ngược đúng sự thật. Chính vì secret của hardware MFA device không được chia sẻ giữa nhiều bên nên AWS mới không dùng lại được thiết bị đã cấp cho tổ chức khác — lập luận trong câu D lấy đúng nguyên nhân rồi rút ra kết luận ngược lại. Đặc điểm "không chia sẻ secret giữa nhiều bên" mà mệnh đề này mô tả đúng ra thuộc về U2F security key: loại khoá đó dùng lại được với AWS MFA, còn hardware token kiểu Gemalto thì không.

📌 Điểm cần nhớ

• Hardware MFA device (Gemalto) phải mua mới cho AWS. Thiết bị đã cấp phát cho tổ chức khác không đăng ký lại với AWS MFA được, vì secret bên trong không được phép chia sẻ giữa nhiều bên.
• U2F security key thì ngược lại — dùng lại được. U2F không dựa trên secret dùng chung giữa các bên, nên một khoá đang dùng ở nơi khác vẫn đăng ký thêm với AWS MFA được. Đây là cặp đối lập hay bị ra đề nhất trong nhóm câu hỏi này.
• Đọc kỹ mệnh đề "vì sao" trong từng phương án. Ở câu này, cả C và D đều nêu một dữ kiện đúng về secret rồi gắn vào một kết luận sai. Phương án gần đúng thường sai ở vế sau chứ không sai ở vế đầu.
• Ràng buộc ở đây là mô hình tin cậy, không phải thao tác cấu hình. Khi đề hỏi "làm sao cấu hình X", câu trả lời hợp lệ vẫn có thể là "không hỗ trợ" — đừng loại đáp án chỉ vì nó không mô tả một bước thao tác nào.

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

Đề mô tả một ứng dụng web y tế chạy trên nhiều Amazon EC2 instance, đứng sau một Application Load Balancer (ALB). Chi tiết quan trọng nhất là sự tương phản giữa hai môi trường: ứng dụng chạy tốt ở development và test, nhưng trên production thì người dùng liên tục bị đăng xuất và phải đăng nhập lại nhiều lần trong một giờ.

Cụm từ quyết định đáp án là "users are getting logged off and are being asked to log in several times in an hour" — đây là triệu chứng kinh điển của việc mất session state, kết hợp với chi tiết ngầm rằng production có nhiều target sau ALB còn môi trường dev/test thường chỉ có một instance. Khi session được lưu cục bộ trên từng EC2 instance, ALB phân phối các request kế tiếp của cùng một người dùng sang instance khác, instance đó không biết gì về phiên đăng nhập nên bắt đăng nhập lại. Đề còn hỏi hai vế: cách sửa và biện pháp phòng ngừa tái diễn — nghĩa là câu trả lời phải là một thay đổi cấu hình mang tính khắc phục, không phải một bước điều tra.

✅ Vì sao đáp án đúng là đúng

A. Enable Sticky Sessions on Application Load Balancer.

Sticky sessions là cơ chế để ALB định tuyến các request của cùng một client tới cùng một target trong target group. Đây chính xác là thứ cần cho ứng dụng lưu state phiên trên bản thân server, để người dùng có trải nghiệm liên tục.

Cách hoạt động: khi ALB nhận request đầu tiên từ một client, nó chọn một target, sinh ra một cookie tên AWSALB mã hoá thông tin về target đã chọn, mã hoá cookie đó rồi gắn kèm vào response. Client gửi lại cookie này ở các request sau, ALB đọc được và định tuyến tiếp về đúng target cũ. Nếu cookie không giải mã được, hoặc trỏ tới một target đã bị deregister hoặc unhealthy, ALB sẽ chọn target mới và cập nhật lại cookie. Vì cơ chế dựa trên cookie nên client bắt buộc phải hỗ trợ cookie.

Sticky sessions được bật ở cấp target group, và có thể đặt thời lượng dính (stickiness duration) cho cookie do load balancer sinh ra. Thời lượng này được làm mới theo mỗi request, nên chừng nào client còn gửi request trước khi hết hạn thì phiên dính vẫn tiếp tục — đúng nghĩa "phòng ngừa tái diễn" mà đề yêu cầu.

❌ Vì sao các phương án còn lại sai

B. Routing configuration — đặt lại protocol và port cho đúng. Mặc định load balancer định tuyến request tới target bằng protocol và port đã khai khi tạo target group; ngoài ra có thể ghi đè port khi đăng ký từng target. Đây là cấu hình quyết định có kết nối tới được target hay không. Nếu sai protocol/port thì triệu chứng sẽ là target fail health check hoặc lỗi kết nối/5xx hàng loạt, chứ không phải người dùng đăng nhập được rồi bị đá ra. Nó không liên quan gì tới việc mất session.

C. Slow start mode để instance kịp "warm up" nên không mất cached data. Slow start là tính năng có thật: mặc định một target nhận đủ phần request của nó ngay khi đăng ký và pass health check đầu tiên, còn slow start cho target thời gian khởi động trước khi nhận đủ tải. Đây là phương án gần đúng nhất vì nó cũng nói về "cache" và cũng là một thiết lập trên target group. Nhưng nó hỏng ở chỗ: slow start chỉ điều tiết tốc độ tăng lưu lượng cho target mới đăng ký, nó hoàn toàn không ràng buộc một client cụ thể phải quay về đúng instance đang giữ phiên của họ. Người dùng vẫn bị nhảy qua lại giữa các instance, và vẫn bị đăng xuất y như cũ.

D. Bật logging trên ALB và đọc log để xem lỗi. Đây là một bước chẩn đoán hợp lý trong đời thực, nhưng đề đã cung cấp đủ triệu chứng để kết luận nguyên nhân là session data, và đề hỏi thẳng "how will you fix this issue" — bật log không sửa gì cả. Người dùng vẫn tiếp tục bị đăng xuất sau khi bật log. Hơn nữa vế thứ hai của đề đòi biện pháp phòng ngừa tái diễn, mà log thì không ngăn được điều gì.

📌 Điểm cần nhớ

• Triệu chứng "chạy tốt ở dev/test nhưng hỏng ở production, người dùng bị đăng xuất liên tục" gần như luôn trỏ tới session state lưu cục bộ trên instance cộng với việc production có nhiều target — cách khắc phục ở tầng load balancer là sticky sessions.
• Sticky sessions bật ở cấp target group, không phải cấp load balancer hay cấp listener; cookie AWSALB do ALB sinh ra và yêu cầu client hỗ trợ cookie.
• Phân biệt rõ hai tính năng dễ lẫn của target group: slow start điều tiết lưu lượng cho target mới, còn stickiness ràng buộc client với target cũ. Chỉ cái thứ hai giải quyết vấn đề phiên đăng nhập.
• Khi đề hỏi "fix this issue", hãy loại các phương án chỉ mang tính quan sát/chẩn đoán (bật logging, xem metric) — chúng cung cấp thông tin chứ không thay đổi hành vi hệ thống.

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

Đề mô tả một Aurora cluster có primary instance chết vì sự cố sập nguyên một Availability Zone, rồi hỏi SysOps Administrator phải làm gì để đưa database trở lại hoạt động.

Cụm từ quyết định đáp án nằm ngay ở câu thứ hai của đề: "The primary instance and all the reader instances are in the same AZ" — primary và toàn bộ reader instance nằm chung một AZ. Không có cụm này thì câu trả lời sẽ hoàn toàn khác, vì cơ chế failover mặc định của Aurora sẽ tự lo liệu. Cụm từ thứ hai bổ trợ là "an outage that has affected an entire AZ": hỏng ở mức AZ chứ không phải hỏng một instance đơn lẻ.

Ghép hai ràng buộc lại: mọi compute instance của cluster đều nằm trong đúng cái AZ vừa sập. Cluster này về bản chất là một triển khai single-AZ ở tầng instance, dù storage layer của Aurora vẫn nhân bản qua nhiều AZ.

✅ Vì sao đáp án đúng là đúng

B — You must manually create one or more new DB instances in another AZ.

Cơ chế failover tự động của Aurora hoạt động bằng cách thăng cấp một reader instance có sẵn lên làm primary. Nó cần một ứng viên còn sống để thăng cấp. Ở tình huống này không còn ứng viên nào: mọi reader đều nằm trong AZ đã sập, nên chúng cũng không truy cập được y như primary.

Theo đúng tài liệu AWS mà phần giải thích tiếng Anh trích dẫn: nếu cluster chỉ có một DB instance duy nhất, hoặc nếu primary và tất cả reader nằm cùng một AZ, thì quản trị viên phải tự tay tạo một hay nhiều DB instance mới ở AZ khác. Đây là hành động thủ công, Aurora không làm thay.

Điểm đáng yên tâm: dữ liệu không mất. Storage volume của Aurora tách rời khỏi tầng compute và tự nhân bản qua nhiều AZ trong Region, nên instance mới tạo ở AZ khác sẽ gắn vào chính volume cũ. Việc cần khôi phục ở đây là tầng compute, không phải tầng dữ liệu.

❌ Vì sao các phương án còn lại sai

A — Aurora promotes an existing replica in another AZ to a new primary instance, so nothing needs to be done. Đây là phương án gần đúng nhất, và nó mô tả chính xác hành vi của Aurora — nhưng chỉ với cluster có cấu hình multi-AZ ở tầng instance. Nó hỏng ở chỗ mâu thuẫn trực tiếp với dữ kiện đề bài: đề nói rõ không hề tồn tại replica nào ở AZ khác. Không có ứng viên thì không có gì để thăng cấp, và vế "nothing needs to be done" biến nó thành sai hoàn toàn. Đây đúng là loại phương án bẫy người đọc lướt qua ràng buộc trong đề.

C — Aurora automatically creates a new primary instance in the same AZ. Cũng gần đúng, vì Aurora thật sự có hai đường failover với single-master replication: thăng cấp một Aurora Replica sẵn có, hoặc tạo một primary instance mới. Nó hỏng ở chữ "in the same AZ": cái AZ đó đang sập. Không thể provision compute mới trong một AZ không phục vụ được. Cơ chế tự động của Aurora không tự ý nhảy sang AZ khác thay bạn trong tình huống này — đó chính là lý do đáp án đúng đòi thao tác thủ công.

D — For a cluster using single-master replication, Aurora can create up to 15 read-only Aurora Replicas to serve requests from users. Câu này là một phát biểu đúng về mặt kiến thức chung (giới hạn số Aurora Replica trong một cluster, và chúng có thể trải qua nhiều AZ trong Region), nhưng nó không trả lời câu hỏi. Đề hỏi hành động khôi phục khi AZ đã sập, còn phương án này chỉ nêu một khả năng thiết kế. Read replica cũng chỉ phục vụ đọc, không thay thế vai trò primary. Quan trọng hơn: trong tình huống này số replica tối đa là bao nhiêu không có ý nghĩa gì, vì tất cả replica đang có đều nằm trong AZ đã chết.

📌 Điểm cần nhớ

• Failover tự động của Aurora chỉ chạy được khi còn ứng viên sống ở AZ khác. Đọc đề thấy "all instances in the same AZ" là biết ngay cơ chế tự động bị vô hiệu, phải can thiệp tay.
• Phân biệt hai tầng của Aurora: storage tự nhân bản qua nhiều AZ nên dữ liệu an toàn, còn compute (DB instance) chỉ đặt ở đúng AZ bạn chọn. Sập AZ là mất compute, không mất data.
• Muốn có khả năng chịu lỗi mức AZ thật sự thì phải rải reader instance sang các AZ khác nhau ngay từ lúc thiết kế, không phải lúc sự cố xảy ra.
• Với câu trắc nghiệm kiểu này, một phương án phát biểu đúng về sản phẩm (như D) vẫn có thể sai vì không đáp lại câu hỏi được đặt ra. Luôn kiểm tra phương án có khớp với ràng buộc cụ thể trong kịch bản hay không.