Ngân hàng đề — AWS Certified Solutions Architect Professional

Đáp án

D — Dùng AWS Systems Manager Patch Manager để vá CẢ máy chủ tại chỗ LẪN EC2 instance, và dùng Systems Manager để sinh báo cáo tuân thủ vá lỗi.

Vì sao đúng

Đề đòi đúng một thứ: một công cụ duy nhất cho cả hai môi trường, làm được cả vá lẫn báo cáo. Systems Manager là dịch vụ AWS duy nhất quản lý được máy chủ nằm ngoài AWS như một tài nguyên hạng nhất.

⚠ Điểm mấu chốt: Systems Manager coi máy tại chỗ là "hybrid activation" — sau khi đăng ký, chúng không khác gì EC2:

Tạo hybrid activation trong Systems Manager
        ↓
    Cài SSM Agent lên máy chủ tại chỗ, đăng ký bằng mã activation
        ↓
    Máy xuất hiện trong Fleet Manager với id dạng mi-xxxxx (thay vì i-xxxxx)
        ↓
    → mọi tính năng dùng chung: Patch Manager, Run Command, Session Manager, Inventory

Đây là điều nhiều người không biết và là lý do phương án C tồn tại như một cái bẫy. Sau khi đăng ký, không cần cơ chế riêng nào cho máy tại chỗ — chúng dùng đúng patch baseline, đúng maintenance window, đúng báo cáo tuân thủ.

# đăng ký máy tại chỗ vào Systems Manager
aws ssm create-activation \
  --default-instance-name may-chu-dc1 \
  --iam-role SSMServiceRole --registration-limit 50

# vá theo lịch bằng maintenance window, dùng chung cho cả hai môi trường
aws ssm send-command \
  --document-name AWS-RunPatchBaseline \
  --targets Key=tag:MoiTruong,Values=production \
  --parameters Operation=Install

# báo cáo tuân thủ
aws ssm list-compliance-summaries
aws ssm describe-instance-patch-states --instance-ids mi-0abc123

⚠ Hai chế độ của AWS-RunPatchBaseline — nhầm là vá lúc không định vá: | Operation | Việc | |---|---| | Scan | chỉ kiểm tra và báo cáo, KHÔNG cài gì | | Install | cài bản vá, có thể khởi động lại máy |

Quy trình an toàn là Scan trước để biết hiện trạng, rồi Install trong maintenance window.

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

• C (Patch Manager cho EC2, Run Command cho máy tại chỗ, Systems Manager sinh báo cáo) — đây là phương án gần nhất và mọi thành phần trong đó đều là công cụ thật, dùng đúng tên: Patch Manager có thật, Run Command có thật, cả hai đều thuộc Systems Manager. Nó chỉ sai ở một giả định ngầm — rằng máy tại chỗ cần một cơ chế khác. Không cần. Sau khi đăng ký bằng hybrid activation, Patch Manager quản lý chúng y hệt EC2. Dùng Run Command để tự viết kịch bản vá cho nửa đội máy nghĩa là tự tay dựng lại thứ Patch Manager đã làm sẵn: tự quản patch baseline, tự xử lý phân loại bản vá, tự gom dữ liệu tuân thủ. Đề còn nói rõ mục tiêu là thoát khỏi việc dùng nhiều bộ công cụ — phương án này tái tạo đúng vấn đề đó dưới một cái tên khác.

• B (EventBridge kích hoạt SSM patch remediation, Inspector sinh báo cáo tuân thủ vá lỗi) — sai ở vế báo cáo. Amazon Inspector đánh giá lỗ hổng (CVE), không sinh báo cáo tuân thủ vá lỗi. Hai thứ này gần nhau nhưng khác nhau: Inspector trả lời "máy này có lỗ hổng nào đang mở", còn patch compliance trả lời "máy này đã cài đủ bản vá theo baseline chưa". Một máy có thể tuân thủ baseline mà vẫn có CVE chưa có bản vá, và ngược lại. Đề hỏi "report on patch status" — đó là Systems Manager.

• A (AWS OpsWorks vá máy, Athena sinh báo cáo) — sai dịch vụ ở cả hai vế. OpsWorks là dịch vụ quản lý cấu hình dựa trên Chef/Puppet, không phải công cụ quản lý bản vá, và nó đã ngừng hoạt động từ tháng 5/2024. Athena là công cụ truy vấn SQL trên S3 — nó chỉ có thể truy vấn báo cáo mà ai đó đã sinh ra và đổ vào S3, chứ tự nó không sinh ra dữ liệu tuân thủ.

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

⚠ AWS OpsWorks đã ngừng hoạt động từ 26/5/2024:

AWS thông báo end-of-life cho OpsWorks Stacks và OpsWorks for Chef/Puppet
        ↓
    Không nhận khách mới, rồi dừng hẳn dịch vụ
        ↓
    → phương án A đã lỗi thời về mặt sự kiện, ngoài chuyện vốn đã sai về chức năng

Đây là dấu hiệu tuổi đời của bộ đề. Khoá đáp án vẫn đúng vì A sai vì nhiều lý do khác nữa, nhưng khi ôn thi nên nhớ rằng mọi phương án nhắc tới OpsWorks trong đề hiện đại đều đã lỗi thời.

Ghi nhớ

⚠ Bốn khả năng chính của Systems Manager — bảng phải thuộc: | Khả năng | Việc | |---|---| | Patch Manager | vá theo baseline, báo cáo tuân thủ | | Run Command | chạy lệnh tuỳ ý trên đội máy | | Session Manager | shell vào máy không cần SSH, không cần cổng mở | | Inventory | kiểm kê phần mềm cài đặt | | State Manager | giữ máy ở trạng thái cấu hình mong muốn | | Automation | runbook nhiều bước |

Từ khoá nhận diện:

"on-premises servers AND EC2 instances" + một công cụ → Systems Manager với hybrid activation "deploy patches and report on patch status" → Patch Manager "Inspector sinh báo cáo tuân thủ vá lỗi" → SAI, Inspector làm CVE "Run Command cho máy tại chỗ" khi đã có Patch Manager → SAI, tự làm lại thứ đã có "OpsWorks" → dịch vụ đã ngừng hoạt động (5/2024)

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Máy đã đăng ký chưa | aws ssm describe-instance-information | | Trạng thái vá của một máy | aws ssm describe-instance-patch-states | | Bản vá nào còn thiếu | aws ssm describe-instance-patches --filters Key=State,Values=Missing |

Và một lời khuyên: hãy theo dõi số máy XUẤT HIỆN trong describe-instance-information, đừng chỉ nhìn tỷ lệ tuân thủ. Đây là lỗi im lặng kinh điển của quản lý bản vá: một máy mất SSM Agent, hoặc mất quyền IAM, hoặc mất đường ra tới endpoint SSM, sẽ biến mất khỏi danh sách được quản lý — và vì nó không còn trong danh sách, nó cũng không xuất hiện như một máy không tuân thủ. Báo cáo hiện "100% tuân thủ" trông giống hệt nhau dù bạn đang vá đủ mọi máy hay đang chỉ vá những máy còn báo cáo về. Con số cần canh là mẫu số, không phải tỷ lệ.

Đáp án

B — Dùng tính năng Block Public Access của S3, đặt IgnorePublicAcls thành TRUE cho bucket.

Vì sao đúng

Câu này kiểm tra một điều rất cụ thể: bốn tuỳ chọn của Block Public Access làm bốn việc khác nhau, và phải chọn đúng cái khớp với nguyên nhân. Manh mối nằm ở chỗ ứng dụng dùng signed URL và phải tiếp tục chạy được.

⚠ Điểm mấu chốt: signed URL không phụ thuộc vào ACL hay bucket policy — nó mang chữ ký của một danh tính có quyền:

Chặn ACL công khai (IgnorePublicAcls = true)
        ↓
    Mọi ACL cấp quyền cho "AllUsers" bị bỏ qua
        ↓
    Người truy cập ẩn danh → AccessDenied
        ↓
    Signed URL vẫn hoạt động: nó được ký bằng thông tin đăng nhập của ứng dụng
        ↓
    → khoá được cửa công khai mà không đụng gì tới luồng ứng dụng

Đây là lý do B là đáp án. Presigned URL mang chữ ký SigV4 của một principal có quyền s3:GetObject; S3 xác thực chữ ký đó chứ không cần bất kỳ quyền công khai nào. Khoá cửa công khai lại không làm gãy nó.

# xem hiện trạng
aws s3api get-public-access-block --bucket bao-cao-nguoi-dung

# bật cả bốn — cách làm đúng trong thực tế
aws s3api put-public-access-block --bucket bao-cao-nguoi-dung \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

# kiểm chứng: truy cập ẩn danh phải bị từ chối
curl -I https://bao-cao-nguoi-dung.s3.amazonaws.com/bao-cao/nguoi-khac.pdf

⚠ BlockPublicAcls và IgnorePublicAcls khác nhau ở chỗ có xử lý được ACL ĐANG TỒN TẠI hay không:

BlockPublicAcls = true
        ↓
    Chặn việc ĐẶT MỚI ACL công khai
        ↓
    → ACL công khai đã có từ trước vẫn tiếp tục có hiệu lực

IgnorePublicAcls = true
        ↓
    BỎ QUA mọi ACL công khai, kể cả cái đã có sẵn
        ↓
    → chặn được ngay lập tức, đúng thứ đề cần

Đề nói tình trạng phơi nhiễm đang diễn ra — có nghĩa quyền công khai đã tồn tại rồi. Vì thế phải là IgnorePublicAcls, thứ vô hiệu hoá cái đang có, chứ không phải cái chỉ ngăn cái sẽ đến.

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

• A (đặt BlockPublicPolicy thành TRUE) — đây là phương án gần nhất và nó cùng thuộc đúng tính năng, cùng hướng giải quyết: Block Public Access đúng là công cụ cần dùng. Nó chỉ nhắm sai cơ chế và sai thời điểm. BlockPublicPolicy xử lý bucket policy, không xử lý ACL — mà đề mô tả "public access is currently enabled", tình huống điển hình của ACL công khai. Quan trọng hơn: BlockPublicPolicy chỉ chặn việc gắn bucket policy công khai mới, nó không vô hiệu hoá policy công khai đang có hiệu lực. Kể cả nếu nguyên nhân là bucket policy thì bật cờ này cũng không dừng được rò rỉ đang xảy ra — thứ làm việc đó là RestrictPublicBuckets. Đây là bẫy tinh vi nhất của câu hỏi vì nó đòi phân biệt hai trục cùng lúc: ACL với policy, và ngăn cái mới với vô hiệu cái cũ.

• C (bật server access logging rồi theo dõi log) — ghi nhận chứ không ngăn chặn. Sau khi bật, dữ liệu vẫn phơi ra y như cũ; bạn chỉ có thêm một bản ghi chi tiết về việc ai đang lấy nó. Với một sự cố lộ dữ liệu đang diễn ra, đây là bước điều tra bổ sung, không phải biện pháp khắc phục.

• D (bật mã hoá mặc định cho mọi object) — nhầm mối đe doạ. Mã hoá phía máy chủ bảo vệ dữ liệu lúc nằm yên trên đĩa, chống lại việc ai đó chiếm được phương tiện lưu trữ vật lý. Nó không ảnh hưởng gì tới kiểm soát truy cập: một request được cấp quyền — kể cả request ẩn danh tới object công khai — vẫn nhận về nội dung đã được S3 giải mã sẵn. Bật mã hoá xong thì kẻ đọc trộm vẫn đọc được y hệt.

Ghi nhớ

⚠ Bốn tuỳ chọn Block Public Access — bảng phải thuộc, đây là bảng ra thi nhiều nhất về S3: | Tuỳ chọn | Tác động lên | Ngăn cái mới hay vô hiệu cái cũ | |---|---|---| | BlockPublicAcls | ACL | ngăn đặt mới | | IgnorePublicAcls | ACL | vô hiệu cái đang có | | BlockPublicPolicy | bucket policy | ngăn gắn mới | | RestrictPublicBuckets | bucket policy | vô hiệu cái đang có (chỉ còn principal trong tài khoản và dịch vụ AWS) |

Quy tắc nhớ: Block = ngăn cái mới, Ignore/Restrict = vô hiệu cái đang có.

Từ khoá nhận diện:

"public access is currently enabled" → cần vô hiệu cái đang có → Ignore/Restrict "without modifying the application workflow" → giữ signed URL, không chuyển sang CloudFront "ACL" → cặp BlockPublicAcls / IgnorePublicAcls "bucket policy" → cặp BlockPublicPolicy / RestrictPublicBuckets "bật mã hoá để chống truy cập trái phép" → LUÔN SAI, mã hoá không phải kiểm soát truy cập

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Còn phơi ra không | tab Access trong console hiện nhãn "Publicly accessible" | | Kiểm thử thật | curl không kèm thông tin xác thực — phải nhận AccessDenied | | Signed URL còn chạy không | phát một URL từ ứng dụng và mở thử |

Và một lời khuyên: hãy bật cả bốn tuỳ chọn ở cấp tài khoản, đừng chỉ sửa từng bucket một. Block Public Access đặt được ở cấp tài khoản, và khi đó nó phủ lên mọi bucket hiện có lẫn mọi bucket sẽ được tạo. Sửa từng bucket là một cuộc chạy đua bạn không thể thắng: chỉ cần một người tạo bucket mới cho một dự án thử nghiệm, hoặc một template CloudFormation cũ dựng lại một bucket với cấu hình cũ, là lỗ hổng quay lại — và nó quay lại một cách hoàn toàn im lặng, vì bucket mới thì không ai đi kiểm tra, và dữ liệu bên trong vẫn phục vụ bình thường cho tới ngày có người bên ngoài tìm thấy nó.

Đáp án

B, D — hai chỗ còn lại có thể chặn quyền dù IAM policy đã cấp đủ:

• B — Kiểm tra SCP đặt ở các OU.
• D — Kiểm tra permissions boundary đặt cho IAM user đó.

Vì sao đúng

Đề đã loại sẵn một khả năng: IAM policy của người dùng đã cấp read-only cho mọi bucket, kiến trúc sư đã xác nhận. Vậy quyền bị chặn ở một tầng khác. Chi tiết "no bucket listed" cũng rất đáng chú ý — ngay cả ListAllMyBuckets cũng không chạy, nghĩa là thứ đang chặn có phạm vi rộng chứ không phải luật riêng của một bucket.

⚠ Điểm mấu chốt: quyền hiệu dụng là GIAO của tất cả các tầng — thêm một tầng chỉ có thể thu hẹp:

Quyền hiệu dụng
        = SCP (trần tổ chức)
        ∩ Permissions boundary (trần của entity)
        ∩ IAM identity policy (quyền được cấp)
        ∩ Resource policy (bucket policy, nếu có)
        ↓
    → chỉ cần MỘT tầng không cho là không có quyền

B — vì sao SCP đứng đầu danh sách nghi vấn. Đề nói rõ đây là tài khoản thành viên trong AWS Organizations. SCP là tầng cao nhất, áp cho toàn bộ tài khoản, và người quản trị trong chính tài khoản đó không nhìn thấy nó trong giao diện IAM của mình. Một SCP chặn s3:* ở OU sẽ tạo ra đúng triệu chứng của đề — access denied, không bucket nào hiện ra — trong khi mọi thứ trong IAM trông hoàn hảo.

D — vì sao permissions boundary là nghi vấn thứ hai. Boundary là một policy gắn thẳng vào IAM user, đặt trần cho những gì user đó làm được. Nó không hiện ra khi bạn chỉ đọc các policy được đính kèm:

# xem user có boundary không — chỗ này hay bị bỏ sót
aws iam get-user --user-name lap-trinh-vien \
  --query 'User.PermissionsBoundary'

# xem SCP đang áp cho tài khoản
aws organizations list-policies-for-target \
  --target-id 444455556666 --filter SERVICE_CONTROL_POLICY

⚠ Công cụ chẩn đoán đúng là IAM Policy Simulator, vì nó tính cả bốn tầng:

aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::444455556666:user/lap-trinh-vien \
  --action-names s3:ListAllMyBuckets s3:GetObject

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

• E (kiểm bucket policy của mọi bucket) — đây là phương án gần nhất và bucket policy thật sự là một tầng có thể từ chối: một Deny tường minh trong bucket policy chặn được cả principal đã có quyền IAM. Nhưng nó không khớp với triệu chứng cụ thể của đề. Chi tiết quyết định là "no bucket listed" — thao tác liệt kê bucket là s3:ListAllMyBuckets, một hành động ở cấp tài khoản, không gắn với bucket nào cả, nên không bucket policy nào ảnh hưởng tới nó. Bucket policy chỉ có thể chặn truy cập vào từng bucket cụ thể; nó không thể làm cho danh sách bucket trống rỗng. Ngoài ra, phải có Deny giống hệt nhau trên mọi bucket mới ra được triệu chứng đồng loạt như vậy — trong khi một SCP hoặc một boundary giải thích được toàn bộ chỉ bằng một nguyên nhân.

• A (kiểm xem IAM role phù hợp đã gắn vào IAM user chưa) — không có khái niệm này. Role không "gắn vào" user. User có thể assume một role qua sts:AssumeRole, và đó là một hành động chủ động sinh ra thông tin đăng nhập tạm thời riêng — không phải một thứ được đính kèm. Đề cũng nói người dùng đăng nhập bằng chính thông tin đăng nhập của user, không nhắc gì tới role.

• C (kiểm ACL của mọi bucket) — ACL là cơ chế kiểm soát truy cập cũ, và với bối cảnh hiện nay thì gần như chắc chắn không phải nguyên nhân: từ tháng 4/2023, bucket mới tắt ACL theo mặc định (chế độ Bucket owner enforced). Kể cả khi còn bật, ACL cấp quyền theo từng object hoặc từng bucket — nó cũng không giải thích được vì sao danh sách bucket trống.

Ghi nhớ

⚠ Bốn tầng quyết định quyền hiệu dụng — bảng phải thuộc, theo thứ tự đánh giá: | Tầng | Trả lời | Ai nhìn thấy | |---|---|---| | SCP | tổ chức có cho phép không | chỉ tài khoản quản lý | | Permissions boundary | trần của entity này tới đâu | quản trị trong tài khoản, nếu nhớ đi tìm | | Identity policy | principal được cấp gì | dễ thấy nhất | | Resource policy | tài nguyên cho ai vào | trên chính tài nguyên |

Từ khoá nhận diện:

"member account in AWS Organizations" + access denied bất ngờ → nghi SCP trước tiên "IAM policy đã đúng nhưng vẫn bị từ chối" → SCP hoặc permissions boundary "no bucket listed" → ListAllMyBuckets bị chặn — cấp tài khoản, không phải bucket policy "attach an IAM role to an IAM user" → LUÔN SAI, không tồn tại khái niệm này "kiểm ACL" trong bối cảnh hiện đại → gần như luôn không phải nguyên nhân

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mô phỏng quyền đủ bốn tầng | aws iam simulate-principal-policy | | Xem lời gọi bị từ chối | CloudTrail, lọc errorCode = AccessDenied | | Xem boundary | aws iam get-user --query 'User.PermissionsBoundary' |

Và một lời khuyên: hãy đọc trường errorMessage trong sự kiện CloudTrail bị từ chối, đừng chỉ đọc errorCode. Với các lời gọi bị chặn, CloudTrail thường ghi rõ tầng nào đã từ chối — có khi nêu đích danh "with an explicit deny in a service control policy". Đó là câu trả lời trực tiếp cho một câu hỏi mà người ta thường mất nhiều giờ để đoán, vì cả SCP lẫn permissions boundary đều không hiện ra ở bất kỳ chỗ nào trong giao diện IAM mà người quản trị tài khoản thường mở ra xem. Họ nhìn vào policy đính kèm, thấy quyền đầy đủ, và kết luận rằng chuyện này là không thể xảy ra.

Đáp án

B, C, E — ba bước cho đường ống xử lý ảnh co giãn theo tải:

• C — Ứng dụng di động tải ảnh thẳng lên S3; S3 sinh tin nhắn vào SQS standard queue mỗi lần có ảnh mới.
• E — Lambda function xử lý ảnh, được kích hoạt bởi tin nhắn trong hàng đợi SQS.
• B — Amazon SNS gửi push notification về ứng dụng khi xử lý xong.

Vì sao đúng

Đề mô tả tải rất lệch: hàng nghìn ảnh mỗi phút từ 8 giờ sáng tới 5 giờ chiều các ngày trong tuần, gần như không có gì vào lúc khác. Đó là hình thái mà kiến trúc dựa trên hàng đợi và serverless phục vụ tốt nhất.

⚠ Điểm mấu chốt: SQS nằm giữa để đỉnh tải KHÔNG truyền thẳng vào tầng xử lý:

Đỉnh 8h sáng: hàng nghìn ảnh mỗi phút đổ vào S3
        ↓
    Mỗi ảnh sinh một tin nhắn SQS — hàng đợi phình ra, không ai hỏng
        ↓
    Lambda đọc theo lô, tự tăng số lời gọi đồng thời theo độ sâu hàng đợi
        ↓
    → xử lý bắt kịp dần; nếu có lỗi thì tin nhắn nằm lại, không mất
        ↓
    Ban đêm: hàng đợi rỗng → Lambda không chạy → không tốn tiền

Vì sao tải thẳng lên S3 (C) mà không qua máy chủ. Ảnh độ phân giải cao đi qua tầng ứng dụng sẽ tiêu băng thông và bộ nhớ của chính tầng đó. Cho ứng dụng di động dùng presigned URL để PUT thẳng vào S3 là mẫu chuẩn: máy chủ chỉ phát URL, còn dữ liệu đi thẳng.

Vì sao standard queue chứ không FIFO. Ảnh của những người dùng khác nhau không có quan hệ thứ tự. Standard queue cho thông lượng gần như không giới hạn; FIFO bị giới hạn 300 thao tác mỗi giây (3.000 khi gom lô) — đúng chỗ sẽ nghẽn vào giờ cao điểm.

Vì sao SNS cho thông báo (B). SNS có sẵn tích hợp với APNs (iOS) và FCM (Android) qua platform application, nên gửi push notification tới thiết bị là việc có sẵn:

# đăng ký thiết bị
aws sns create-platform-endpoint \
  --platform-application-arn arn:aws:sns:ap-southeast-1:111122223333:app/APNS/AnhApp \
  --token <device-token>

# gửi thông báo khi xử lý xong
aws sns publish --target-arn <endpoint-arn> \
  --message '{"APNS":"{\"aps\":{\"alert\":\"Ảnh của bạn đã xử lý xong\"}}"}' \
  --message-structure json

⚠ Visibility timeout của SQS phải LỚN HƠN thời gian chạy tối đa của Lambda:

Visibility timeout ngắn hơn thời gian xử lý
        ↓
    Tin nhắn hiện lại trong hàng đợi khi Lambda vẫn đang xử lý nó
        ↓
    Một Lambda khác nhận cùng tin nhắn đó
        ↓
    → cùng một ảnh bị xử lý hai lần, và không có lỗi nào báo cho bạn

Khuyến nghị: visibility timeout ít nhất gấp 6 lần timeout của hàm.

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

• D (S3 event notification đẩy tin nhắn vào hàng đợi Amazon MQ) — đây là phương án gần nhất và ý tưởng dùng hàng đợi làm bộ đệm là hoàn toàn đúng: nó nhận ra đúng vấn đề kiến trúc. Nhưng nó sai ở hai chỗ. Thứ nhất, S3 event notification không gửi được tới Amazon MQ — các đích được hỗ trợ chỉ gồm SQS, SNS, Lambda và EventBridge. Thứ hai, Amazon MQ là message broker có quản lý chạy trên broker instance (ActiveMQ hoặc RabbitMQ), tức là có máy phải cấp phát, phải trả tiền 24/7 và phải tự co giãn — hoàn toàn ngược với tải chỉ có 9 tiếng mỗi ngày của đề. Amazon MQ sinh ra để giữ tương thích với ứng dụng cũ dùng JMS/AMQP khi di chuyển lên cloud, không phải để dựng hệ thống mới.

• A (S3 Batch Operations xử lý ảnh dựa trên tin nhắn hàng đợi) — sai công cụ. S3 Batch Operations chạy theo job trên một bản kê object có sẵn (S3 Inventory hoặc file CSV), dùng cho các thao tác hàng loạt trên hàng triệu object đã tồn tại — sao chép, đổi tag, khôi phục từ Glacier. Nó không phải bộ xử lý theo sự kiện và không đọc tin nhắn từ hàng đợi.

• F (Amazon SES gửi thông báo về ứng dụng di động) — SES gửi email, không gửi push notification. Đề nói người dùng nhận thông báo trong ứng dụng di động. Email là kênh khác, trải nghiệm khác, và không phải thứ đề mô tả.

Ghi nhớ

⚠ Bốn dịch vụ nhắn tin — bảng phải thuộc: | Dịch vụ | Mô hình | Hợp với | |---|---|---| | SQS | hàng đợi, một người tiêu thụ mỗi tin nhắn | tách tầng, đệm đỉnh tải | | SNS | pub/sub, phát tán tới nhiều bên | push notification, fan-out | | EventBridge | bus sự kiện, định tuyến theo luật | tích hợp giữa các dịch vụ, SaaS | | Amazon MQ | broker có quản lý (JMS/AMQP) | di chuyển ứng dụng cũ, không dùng cho hệ thống mới |

Từ khoá nhận diện:

"thousands of uploads per minute" + "minimal activity at other times" → serverless + hàng đợi "push notifications to the mobile app" → SNS "send notifications" qua SES tới ứng dụng di động → SAI, SES là email "S3 event to Amazon MQ" → LUÔN SAI, S3 không gửi tới MQ "S3 Batch Operations" để xử lý theo sự kiện → SAI, đó là job trên bản kê

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có đang tụt lại không | ApproximateAgeOfOldestMessage | | Có xử lý trùng không | so số ảnh vào với số bản ghi kết quả | | Có tin nhắn hỏng không | độ sâu của dead-letter queue |

Và một lời khuyên: hãy đặt cảnh báo trên độ sâu của dead-letter queue, ngay từ ngày đầu. Đây là chỗ công việc biến mất một cách lặng lẽ nhất trong kiến trúc hàng đợi: một tấm ảnh làm hàm xử lý ném lỗi sẽ được thử lại đủ số lần rồi rơi vào DLQ — và ở đó nó nằm im. Hàng đợi chính vẫn rỗng, Lambda vẫn báo không có lỗi, biểu đồ vẫn phẳng đẹp, vì theo mọi chỉ số bạn đang theo dõi thì hệ thống đã xử lý xong mọi thứ. Người dùng có ảnh nằm trong DLQ thì chỉ đơn giản là không bao giờ nhận được thông báo, và họ sẽ cho rằng ứng dụng bị lỗi chứ không báo cho ai.

Đáp án

D — Đặt DISABLED cho Auto-assign public IP khi chạy task, và cấu hình NAT gateway trong một PUBLIC subnet để định tuyến request ra Internet.

Vì sao đúng

Thông báo lỗi nói chính xác điều gì đang xảy ra: CannotPullContainerError ... request canceled while waiting for connection khi gọi tới ECR. Task không có đường ra Internet để kéo image về.

⚠ Điểm mấu chốt: NAT gateway phải nằm trong PUBLIC subnet, dù nó phục vụ private subnet:

Task trong private subnet
        ↓
    Bảng định tuyến của private subnet: 0.0.0.0/0 → NAT gateway
        ↓
    NAT gateway đặt trong PUBLIC subnet
        ↓
    Bảng định tuyến của public subnet: 0.0.0.0/0 → Internet gateway
        ↓
    → NAT có đường ra thật, nên nó chuyển tiếp được lưu lượng cho private subnet

Đây là điểm phân biệt duy nhất giữa phương án A và D, và nó là kiến thức nền của mạng VPC. NAT gateway tự nó cần đường ra Internet. Đặt nó trong private subnet thì chính nó cũng bị mắc kẹt — không có route tới Internet gateway, nên nó chẳng chuyển tiếp được gì cả. Nó cũng cần một Elastic IP, thứ chỉ có ý nghĩa trong subnet công khai.

# NAT gateway trong PUBLIC subnet
aws ec2 create-nat-gateway \
  --subnet-id subnet-public-1a \
  --allocation-id eipalloc-abc123

# private subnet trỏ ra qua NAT
aws ec2 create-route --route-table-id rtb-private \
  --destination-cidr-block 0.0.0.0/0 \
  --nat-gateway-id nat-abc123

⚠ Với Fargate, việc kéo image do TASK EXECUTION ROLE làm, và nó cần đường mạng của task:

Fargate task khởi động trong private subnet
        ↓
    Agent kéo image từ ECR — dùng chính mạng của task
        ↓
    Không có đường ra → CannotPullContainerError
        ↓
    → task chết trước khi container chạy dòng mã đầu tiên

Đây là lý do lỗi xuất hiện ngay lúc khởi động chứ không phải khi ứng dụng gọi ra ngoài.

Cách thay thế không cần NAT: dùng VPC endpoint. Cần đủ bốn cái, thiếu một là vẫn hỏng:

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

• A (DISABLED public IP + NAT gateway trong PRIVATE subnet) — đây là phương án gần nhất và nó chỉ khác đáp án đúng đúng một từ: phần "DISABLED public IP" là chuẩn, ý tưởng dùng NAT gateway cũng chuẩn. Nó chết ở chỗ đặt NAT sai subnet. NAT gateway trong private subnet không có đường ra Internet của chính nó, nên nó trở thành một ngõ cụt tốn tiền: tài nguyên tạo thành công, trạng thái hiện Available, không có lỗi nào ở khâu tạo — và task vẫn nhận đúng thông báo CannotPullContainerError như trước. Đây là bẫy hay nhất của câu này vì mọi thứ khác đều đúng và cấu hình sai vẫn "dựng lên được".

• B (ENABLED cho Auto-assign public IP) — về kỹ thuật thì task sẽ kéo được image, nhưng nó vi phạm ràng buộc của đề: task phải chạy trong private subnet và không có kết nối trực tiếp ra Internet. Gán IP công cộng nghĩa là đặt task vào đường đi trực tiếp từ Internet, đúng thứ kiến trúc đang cố tránh. Ngoài ra, tuỳ chọn này chỉ có tác dụng nếu subnet có route tới Internet gateway — trong private subnet thì nó vô nghĩa.

• C (bật dual-stack trong cài đặt ECS và dùng network mode awsvpc) — không liên quan tới nguyên nhân. Dual-stack là chuyện IPv4/IPv6, không tạo ra đường ra Internet. Còn awsvpc là network mode bắt buộc của Fargate — nó đã được dùng sẵn, không phải thứ cần bật thêm. Phương án này đổi hai thiết lập không liên quan tới lỗi.

Ghi nhớ

⚠ Bốn cách để tài nguyên trong private subnet ra được Internet — bảng phải thuộc: | Cách | Chiều | Ghi chú | |---|---|---| | NAT gateway (trong public subnet) | chỉ đi ra | có quản lý, tính tiền theo giờ + theo GB | | NAT instance | chỉ đi ra | tự quản, rẻ hơn, phải tự lo HA | | VPC endpoint | không qua Internet | rẻ hơn NAT nếu chỉ cần vài dịch vụ AWS | | Egress-only Internet gateway | chỉ đi ra, chỉ IPv6 | tương đương NAT cho IPv6 |

Từ khoá nhận diện:

CannotPullContainerError → task không có đường ra tới ECR "private subnet" + "no direct internet connectivity" → NAT gateway hoặc VPC endpoint "NAT gateway in a private subnet" → LUÔN SAI, NAT phải ở public subnet "enable auto-assign public IP" khi đề đòi private → vi phạm ràng buộc "dual-stack" để chữa lỗi kéo image → không liên quan

Không có thuộc tính nào tên là "public" — định nghĩa nằm ở bảng định tuyến.

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Route có đúng không | xem bảng định tuyến của private subnet có 0.0.0.0/0 → nat-xxx | | NAT có ở public subnet không | subnet của NAT phải có route tới igw | | Endpoint có đủ không | thiếu S3 gateway endpoint là kéo image vẫn hỏng |

Và một lời khuyên: hãy kiểm bảng định tuyến của subnet chứa NAT gateway, không chỉ của subnet chứa task. Đây là cấu hình sai không tạo ra bất kỳ tín hiệu nào ở khâu triển khai: NAT gateway đặt nhầm vào private subnet vẫn được tạo thành công, vẫn chuyển sang trạng thái Available, vẫn hiện màu xanh trong console và vẫn tính tiền theo giờ đầy đủ. Không có cảnh báo, không có kiểm tra tính hợp lệ nào từ phía AWS. Thứ duy nhất cho bạn biết là task vẫn tiếp tục chết với đúng thông báo lỗi cũ — và vì bạn vừa mới thêm một NAT gateway, phản xạ tự nhiên là đi tìm nguyên nhân ở chỗ khác.

Đáp án

B — Triển khai AWS Systems Manager Agent lên các EC2 instance và truy cập chúng bằng Session Manager, giới hạn quyền cho những người được phép quản lý máy.

Vì sao đúng

Đề mô tả một tình huống bảo mật tệ: RDP và SSH mở cho 0.0.0.0/0, đã có dấu hiệu bị dò quét. Yêu cầu là "giải pháp an toàn nhất". Session Manager là câu trả lời vì nó xoá bỏ hoàn toàn lớp bề mặt tấn công thay vì thu hẹp nó.

⚠ Điểm mấu chốt: Session Manager đảo ngược chiều kết nối — agent gọi RA, không có ai gọi VÀO:

SSM Agent trên máy chủ động mở kết nối HTTPS ra endpoint Systems Manager
        ↓
    Người quản trị gọi StartSession qua API của AWS
        ↓
    Phiên làm việc đi qua kênh mà agent đã mở sẵn
        ↓
    → security group KHÔNG cần mở cổng vào nào, kể cả cổng 22 hay 3389
        ↓
    → không có gì để quét, không có gì để tấn công vét cạn

Đây là khác biệt căn bản với mọi phương án còn lại. Bastion host, VPN, máy chủ quản trị — tất cả đều thu hẹp danh sách ai được kết nối vào; Session Manager làm cho không còn kết nối vào nào tồn tại.

Lợi ích đi kèm cũng đáng kể: không còn khoá SSH để quản lý. Không phải phát khoá, không phải xoay khoá, không phải lo khoá của nhân viên đã nghỉ việc. Quyền truy cập chỉ là quyền IAM, thu hồi tức thì.

# mở phiên, không cần khoá, không cần cổng
aws ssm start-session --target i-0abc123

# giới hạn ai vào được máy nào bằng tag

{
  "Effect": "Allow",
  "Action": "ssm:StartSession",
  "Resource": "arn:aws:ec2:*:*:instance/*",
  "Condition": {"StringEquals": {"ssm:resourceTag/Doi": "vanhanh"}}
}

⚠ Máy trong private subnet cần đường tới endpoint SSM — thiếu là máy biến mất khỏi danh sách quản lý:

Máy private không có NAT và không có VPC endpoint
        ↓
    SSM Agent không gọi ra được
        ↓
    → máy KHÔNG xuất hiện trong danh sách managed instance
        ↓
    → và vì không xuất hiện, nó cũng không bị báo là có vấn đề

Cần ba interface endpoint: ssm, ssmmessages, ec2messages.

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

• A (VPN IPSec nối mạng công ty với VPC, security group chỉ cho phép SSH/RDP từ mạng công ty) — đây là phương án gần nhất và nó thật sự cải thiện tình hình rất nhiều: thay 0.0.0.0/0 bằng dải IP công ty là một bước tiến lớn, và VPN mã hoá đường truyền. Nhưng nó vẫn kém an toàn hơn theo ba cách. Thứ nhất, cổng 22 và 3389 vẫn mở — chỉ là mở hẹp hơn; bất kỳ ai vào được mạng công ty (máy nhân viên bị nhiễm mã độc, một cổng Wi-Fi khách cấu hình lỏng) đều tới được. Thứ hai, vẫn phải quản lý khoá SSH và mật khẩu RDP, với toàn bộ gánh nặng xoay vòng và thu hồi. Thứ ba, đề nói rõ hiện không có kết nối nào tới mạng công ty — phương án này đòi dựng và vận hành thêm cả một hạ tầng VPN. Nó cũng không có ghi log phiên làm việc sẵn.

• C (dựng máy chủ quản trị trong mạng công ty, chỉ cho phép SSH/RDP từ máy đó) — cùng những hạn chế của A nhưng thêm một điểm hỏng đơn lẻ. Máy chủ quản trị đó trở thành mục tiêu giá trị nhất trong toàn hệ thống: chiếm được nó là chiếm được mọi máy. Phương án này còn ngầm giả định đã có kết nối tới VPC, thứ đề nói là không có.

• D (bastion host Linux với Elastic IP trong public subnet, cho phép truy cập từ 0.0.0.0/0) — không cải thiện gì cả, chỉ đổi chỗ vấn đề. Vẫn là một cổng SSH phơi ra toàn Internet, chỉ khác là giờ chỉ có một máy hứng chịu thay vì nhiều máy. Một bastion mở cho 0.0.0.0/0 sẽ bị dò quét trong vòng vài phút sau khi có IP công cộng. Ngoài ra bastion Linux không phục vụ được RDP cho máy Windows một cách trực tiếp.

Ghi nhớ

⚠ Bốn cách quản trị máy chủ, xếp theo mức an toàn: | Cách | Cổng vào cần mở | Quản lý khoá | Log phiên | |---|---|---|---| | Session Manager | không có | không cần | có sẵn | | VPN + SSH | 22/3389 từ mạng riêng | có | tự dựng | | Bastion host | 22 từ dải hẹp | có | tự dựng | | SSH mở ra Internet | 22 từ mọi nơi | có | không |

Từ khoá nhận diện:

"most secure solution for managing instances" → Session Manager "no bastion / no open ports / no SSH keys" → Session Manager "malicious attempts to access" + cổng mở 0.0.0.0/0 → bỏ hẳn cổng vào "bastion host allowing 0.0.0.0/0" → LUÔN SAI, không cải thiện gì "no connectivity to the corporate network" → loại các phương án đòi VPN sẵn có

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Máy đã sẵn sàng chưa | aws ssm describe-instance-information | | Đã đóng cổng chưa | kiểm security group không còn rule 22/3389 từ 0.0.0.0/0 | | Log phiên có ghi không | mở một phiên rồi kiểm S3 hoặc CloudWatch Logs |

Và một lời khuyên: hãy thật sự gỡ các rule 22 và 3389 khỏi security group sau khi Session Manager chạy được, đừng để lại "phòng khi cần". Đây là chỗ việc cải thiện bảo mật thường dừng lại giữa chừng: đội vận hành triển khai Session Manager, dùng nó hằng ngày, và mọi người tin rằng hệ thống đã được bảo vệ — trong khi các rule cũ vẫn nằm nguyên đó vì không ai muốn là người xoá đi đường lùi. Cổng mở không dùng đến thì cũng bị quét y hệt cổng đang dùng; nó không sinh ra lưu lượng nào để bạn nhận thấy, không xuất hiện trong bất kỳ báo cáo nào, và giá trị bảo mật của toàn bộ việc chuyển đổi là bằng không cho tới khi rule cuối cùng bị gỡ.

Đáp án

C — Tạo AWS Cost and Usage Report (CUR) từ tài khoản quản lý của AWS Organizations, rồi cho mỗi đội xem qua dashboard Amazon QuickSight.

Vì sao đúng

Đề có một chi tiết quyết định: cần báo cáo cho từng OU, gộp chi phí của mọi tài khoản trong OU đó. Chỉ một nơi có dữ liệu của tất cả các tài khoản.

⚠ Điểm mấu chốt: CUR tạo ở tài khoản thành viên chỉ thấy chi phí của CHÍNH nó:

CUR ở tài khoản quản lý
        ↓
    Chứa mọi dòng chi phí của MỌI tài khoản trong tổ chức
        ↓
    Có cột linked_account_id → gộp theo OU được
        ↓
    → một báo cáo, cắt lát theo bất kỳ chiều nào

CUR ở tài khoản thành viên
        ↓
    Chỉ có chi phí của riêng tài khoản đó
        ↓
    → muốn có số của cả OU thì phải gom thủ công từ hàng chục báo cáo

Đây là lý do C đúng còn A sai, dù hai phương án nhìn rất giống nhau.

Cách gộp theo OU trong thực tế. CUR không có cột OU — nó có line_item_usage_account_id. Bạn ánh xạ tài khoản sang OU bằng một bảng tra cứu:

-- CUR trong S3, truy vấn bằng Athena
SELECT ou.ten_ou,
       sum(cur.line_item_unblended_cost) AS chi_phi
FROM cur_bao_cao cur
JOIN bang_ou ou ON ou.tai_khoan_id = cur.line_item_usage_account_id
WHERE cur.line_item_usage_start_date >= date '2026-08-01'
GROUP BY ou.ten_ou
ORDER BY chi_phi DESC;

Bảng ánh xạ đó lấy từ Organizations:

aws organizations list-accounts-for-parent --parent-id ou-abc1-dev

⚠ CUR phải bật tích hợp Athena thì mới truy vấn được — không phải mặc định:

Tạo CUR ở dạng CSV nén gzip
        ↓
    Athena đọc được nhưng chậm và tốn tiền quét
        ↓
    → nên chọn Parquet + "Athena integration"
        ↓
    → AWS tự tạo bảng và crawler, phân vùng theo tháng

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

• A (tạo CUR trong TỪNG tài khoản thành viên, xem qua QuickSight) — đây là phương án gần nhất và QuickSight ở đây hoàn toàn đúng, cách hiển thị giống hệt đáp án đúng. Nó chỉ sai ở chỗ tạo báo cáo. Với hàng trăm tài khoản, đây là hàng trăm CUR riêng biệt, mỗi cái ghi vào một bucket riêng, mỗi cái phải cấu hình và giám sát riêng. Tệ hơn, để có con số của một OU bạn vẫn phải gom thủ công các báo cáo lại — và mỗi lần tài khoản được thêm vào hoặc chuyển sang OU khác, bạn lại phải nhớ tạo hoặc gỡ CUR tương ứng. Nó tạo ra đúng thứ dữ liệu bạn cần nhưng ở dạng vụn nát nhất có thể.

• D (tạo CUR cho mỗi OU bằng AWS Cost Explorer) — nhầm lẫn hai dịch vụ khác nhau. Cost Explorer không tạo ra CUR. Cost Explorer là giao diện phân tích trực quan với dữ liệu đã tổng hợp sẵn; CUR là bộ dữ liệu chi tiết nhất, xuất ra S3 dưới dạng tệp. Chúng là hai sản phẩm riêng. Ngoài ra không có cách nào tạo CUR "cho một OU" — CUR được tạo ở cấp tài khoản (quản lý hoặc thành viên), rồi mới lọc theo OU khi truy vấn.

• B (tạo CUR bằng AWS OpsWorks, xem qua OpsWorks Stacks) — sai hoàn toàn về vai trò dịch vụ. OpsWorks là quản lý cấu hình dựa trên Chef/Puppet — nó không liên quan gì tới hoá đơn hay báo cáo chi phí. Nó cũng đã ngừng hoạt động từ tháng 5/2024.

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

⚠ AWS OpsWorks đã ngừng hoạt động (26/5/2024):

Phương án B nhắc tới một dịch vụ không còn tồn tại
        ↓
    Nó vốn đã sai vì OpsWorks chưa bao giờ làm việc về chi phí
        ↓
    → nhưng đây là dấu hiệu tuổi đời của bộ đề, nên nhớ khi ôn

Ghi nhớ

⚠ Bốn công cụ chi phí — bảng phải thuộc: | Công cụ | Mức chi tiết | Dùng để | |---|---|---| | Cost and Usage Report (CUR) | chi tiết nhất — từng dòng, từng giờ, từng tài nguyên | phân tích sâu, tự dựng báo cáo | | Cost Explorer | tổng hợp sẵn, giao diện trực quan | xem nhanh, dự báo | | Budgets | ngưỡng và cảnh báo | kiểm soát chi tiêu | | Cost Anomaly Detection | học máy phát hiện bất thường | bắt chi phí tăng đột ngột |

Từ khoá nhận diện:

"costs for each OU" / "all accounts within the OU" → CUR ở tài khoản quản lý "CUR in each member account" → SAI, mỗi cái chỉ thấy chính nó "create a CUR using Cost Explorer" → LUÔN SAI, hai dịch vụ khác nhau "OpsWorks" cho bất kỳ việc gì về chi phí → LUÔN SAI, và dịch vụ đã ngừng "visualize through QuickSight" → đúng, đây là cách chuẩn để hiển thị CUR

Ba việc kiểm chứng: | Việc | Cách | |---|---| | CUR đã đổ dữ liệu chưa | kiểm bucket S3, tệp về theo ngày | | Bảng ánh xạ OU còn đúng không | so list-accounts-for-parent với bảng tra cứu | | Số có khớp hoá đơn không | tổng unblended_cost phải khớp hoá đơn tháng |

Và một lời khuyên: hãy dựng lại bảng ánh xạ tài khoản-sang-OU theo lịch, đừng chép tay một lần rồi thôi. Đây là chỗ báo cáo chi phí sai một cách lặng lẽ nhất: tài khoản được tạo mới, hoặc bị chuyển từ OU này sang OU khác, và bảng tra cứu tĩnh của bạn không biết điều đó. Truy vấn vẫn chạy, dashboard vẫn hiện số, không có lỗi nào cả — nhưng chi phí của tài khoản mới đơn giản là không thuộc về OU nào và biến mất khỏi mọi báo cáo, hoặc tệ hơn, bị tính cho đội cũ. Con số duy nhất giúp bạn phát hiện là tổng của tất cả các OU: nếu nó không khớp với hoá đơn của cả tổ chức, có tài khoản đang rơi ra ngoài.

Đáp án

B, C, F — ba thay đổi kiến trúc để ứng dụng Java sẵn sàng cao trên AWS:

• B — Chuyển cơ sở dữ liệu sang Amazon RDS for MySQL, cấu hình Multi-AZ.
• C — Đặt các instance ứng dụng trong Auto Scaling group, cấu hình để tự thay máy khi máy hỏng.
• F — Lưu phiên người dùng trong Amazon ElastiCache, dùng ALB phân tải giữa các instance.

Vì sao đúng

Đề nêu hai vấn đề kiến trúc của ứng dụng hiện tại, và ba phương án đúng chữa từng lớp một.

⚠ Điểm mấu chốt: phiên lưu cục bộ là thứ khiến ứng dụng KHÔNG THỂ sẵn sàng cao, dù có bao nhiêu máy:

Phiên lưu trong bộ nhớ của từng máy ứng dụng
        ↓
    Máy hỏng, Auto Scaling thay bằng máy mới
        ↓
    Mọi phiên trên máy cũ biến mất
        ↓
    → người dùng bị đăng xuất giữa chừng, giỏ hàng trống
        ↓
    → hệ thống "sẵn sàng cao" theo chỉ số, nhưng người dùng vẫn mất việc đang làm

Đây là điểm quan trọng nhất của câu hỏi. Thêm máy và thêm bộ cân bằng tải chỉ tạo ra dự phòng ở tầng hạ tầng; nếu trạng thái vẫn nằm trên từng máy thì việc mất một máy vẫn gây gián đoạn thật cho người dùng. Đưa phiên ra kho ngoài (ElastiCache) làm tầng ứng dụng trở nên stateless — lúc đó mọi máy tương đương nhau và thay thế được tự do.

Trước:  người dùng ──► máy A (phiên nằm trong RAM của A)
                       máy A chết → mất phiên

Sau:    người dùng ──► ALB ──► máy bất kỳ
                                   ↓
                            ElastiCache (Redis) giữ phiên
                                   ↓
                       → máy nào chết cũng không ảnh hưởng

B — vì sao Multi-AZ chứ không phải read replica. Multi-AZ giữ một bản dự phòng đồng bộ ở AZ khác và tự động chuyển đổi khi bản chính hỏng. Đó là tính sẵn sàng. Read replica là bất đồng bộ và dùng để chia tải đọc, không phải để tự chuyển dự phòng.

aws rds create-db-instance \
  --db-instance-identifier app-mysql --engine mysql \
  --db-instance-class db.r6g.large --multi-az \
  --allocated-storage 100

⚠ ElastiCache cũng phải sẵn sàng cao, nếu không nó thành điểm hỏng đơn lẻ mới:

Đưa toàn bộ phiên vào một node Redis duy nhất
        ↓
    Node đó chết
        ↓
    → mất phiên của TẤT CẢ người dùng cùng lúc
        ↓
    → phải bật Multi-AZ với automatic failover

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

• E (chuyển CSDL sang EC2 ở nhiều AZ, cấu hình Multi-AZ để đồng bộ) — đây là phương án gần nhất và mục tiêu của nó đúng: đặt cơ sở dữ liệu ở nhiều AZ thật sự là điều cần làm. Nhưng nó chọn sai cách. "Multi-AZ" là tính năng của RDS, không phải thứ bạn bật trên EC2 — trên EC2 bạn phải tự dựng sao chép MySQL, tự viết cơ chế phát hiện hỏng, tự chuyển dự phòng, tự lo sao lưu và vá lỗi. Đó là hàng tháng công việc để làm lại thứ RDS cung cấp sẵn bằng một cờ. Đề cũng nói mục tiêu là "highly available solution", và tự dựng thường cho ra độ sẵn sàng thấp hơn vì cơ chế tự chuyển dự phòng viết tay là chỗ hay hỏng nhất.

• A (đưa nội dung Java lên S3 static website hosting, bật cross-Region replication) — sai về bản chất ứng dụng. S3 static website hosting chỉ phục vụ tệp tĩnh; nó không chạy được mã Java, không có servlet container, không xử lý được request động. Đây là ứng dụng Java tuỳ biến, không phải trang tĩnh.

• D (chạy ứng dụng ở nhiều Region, dùng ALB phân tải giữa các instance) — hai vấn đề. Thứ nhất, đề hỏi tính sẵn sàng cao, mà chuẩn cho việc đó là nhiều AZ trong một Region — nhiều Region là giải pháp cho thảm hoạ vùng, phức tạp và tốn kém hơn nhiều. Thứ hai, và đây là lỗi kỹ thuật rõ ràng: ALB là dịch vụ trong phạm vi một Region, nó không phân tải được giữa các Region. Muốn vậy phải dùng Route 53 hoặc Global Accelerator.

Ghi nhớ

⚠ Ba lớp phải xử lý để có tính sẵn sàng cao — bảng phải thuộc: | Lớp | Cách làm | |---|---| | Tầng web/ứng dụng | Auto Scaling group trải nhiều AZ + ELB | | Trạng thái phiên | đưa ra ngoài: ElastiCache, DynamoDB, hoặc sticky session (kém hơn) | | Tầng dữ liệu | RDS Multi-AZ, hoặc Aurora |

Từ khoá nhận diện:

"servers maintain sessions locally" → phải đưa phiên ra ngoài "highly available" → nhiều AZ, không phải nhiều Region "Multi-AZ on EC2 instances" → LUÔN SAI, Multi-AZ là tính năng của RDS "ALB distributing across Regions" → LUÔN SAI, ALB trong một Region "S3 static website hosting" cho ứng dụng Java → SAI, không chạy được mã

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mất một máy có mất phiên không | huỷ một instance, xem người dùng có bị đăng xuất không | | Multi-AZ có chuyển được không | aws rds reboot-db-instance --force-failover | | Máy có trải đều AZ không | kiểm phân bố instance trong Auto Scaling group |

Và một lời khuyên: hãy huỷ thật một instance trong giờ thấp điểm và quan sát xem phiên người dùng có sống sót không. Đây là thứ mà không chỉ số nào cho bạn biết: sau khi bạn thêm ALB và Auto Scaling group, mọi bảng điều khiển đều báo kiến trúc sẵn sàng cao — health check xanh, số instance đủ, ALB phân tải đều. Nếu phiên vẫn nằm trong bộ nhớ máy, hệ thống vẫn đạt mọi tiêu chí kỹ thuật về tính sẵn sàng trong khi người dùng thì bị đăng xuất mỗi lần có máy bị thay. Sự cố đó không xuất hiện trong log máy chủ, không làm tăng tỷ lệ lỗi HTTP, và tới tai bạn dưới dạng những lời phàn nàn mơ hồ rằng "trang web hay bị đăng xuất".

Đáp án

A, D — hai thay đổi để rút ngắn thời gian tải ảnh từ châu Âu lên bucket ở us-west-1:

• D — Bật S3 Transfer Acceleration cho bucket.
• A — Triển khai lại ứng dụng để dùng S3 multipart upload.

Vì sao đúng

Đề nói rõ ba điều: ảnh độ phân giải cao, tải LÊN, và người dùng ở xa bucket. Hai phương án đúng nhắm vào hai nguyên nhân khác nhau của cùng một triệu chứng.

⚠ Điểm mấu chốt: Transfer Acceleration đưa dữ liệu vào mạng xương sống của AWS ngay tại điểm biên gần nhất:

Người dùng ở châu Âu
        ↓
    Tải lên điểm biên CloudFront gần nhất (Frankfurt, London...)
        ↓
    Từ điểm biên, dữ liệu đi trên mạng RIÊNG của AWS tới us-west-1
        ↓
    → tránh được phần lớn chặng Internet công cộng, nơi mất gói và độ trễ cao nhất

Đây là lý do Transfer Acceleration khác hẳn CloudFront: cùng dùng mạng lưới điểm biên, nhưng theo chiều ngược lại. CloudFront tối ưu việc phân phối xuống; Transfer Acceleration tối ưu việc đưa lên.

aws s3api put-bucket-accelerate-configuration \
  --bucket anh-san-pham --accelerate-configuration Status=Enabled

# dùng endpoint tăng tốc — khác endpoint thường
aws s3 cp anh-lon.jpg s3://anh-san-pham/ \
  --endpoint-url https://s3-accelerate.amazonaws.com

A — vì sao multipart bổ trợ cho D. Multipart chia tệp thành nhiều phần và tải song song, nên tận dụng được băng thông tốt hơn nhiều so với một luồng đơn. Quan trọng không kém: khi một phần lỗi, chỉ phải tải lại phần đó thay vì cả tệp — điều rất đáng giá với kết nối di động không ổn định:

⚠ Multipart bỏ dở để lại phần đã tải và VẪN TÍNH TIỀN lưu trữ:

Tải lên bị đứt giữa chừng
        ↓
    Các phần đã tải nằm lại trong bucket
        ↓
    KHÔNG hiện ra trong danh sách object
        ↓
    → nhưng vẫn tính tiền lưu trữ, mãi mãi, cho tới khi có lifecycle rule dọn

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

• E (tạo CloudFront distribution với bucket S3 làm origin) — đây là phương án gần nhất và nó dùng đúng mạng lưới điểm biên, đúng ý tưởng "đưa AWS đến gần người dùng hơn". Nhưng nó nhắm sai chiều. CloudFront được tối ưu cho việc phân phối nội dung xuống người dùng, không phải cho việc tải lên. CloudFront có hỗ trợ phương thức PUT/POST đi qua tới origin, nhưng nó không tăng tốc gì cho chiều lên — không có cơ chế tối ưu đường truyền như Transfer Acceleration, và nội dung tải lên thì tất nhiên không cache được. Với một bài toán thuần về upload, CloudFront là công cụ đúng cho vấn đề khác. Đây là bẫy hay của câu này vì hai dịch vụ dùng chung hạ tầng điểm biên nên rất dễ lẫn.

• B (dùng byte-range fetch ở ứng dụng khách) — byte-range fetch là kỹ thuật TẢI XUỐNG: lấy một đoạn của object đã có trên S3, dùng để tải song song hoặc chỉ lấy phần đầu tệp. Nó không áp dụng được cho việc tải lên. Đây là "anh em đối xứng" của multipart upload, và đề cố ý đặt cả hai vào để kiểm tra xem có phân biệt được chiều nào không.

• C (bật S3 Intelligent-Tiering cho bucket) — lớp lưu trữ không ảnh hưởng tới tốc độ truyền. Intelligent-Tiering tự chuyển object giữa các tầng truy cập để tiết kiệm chi phí lưu trữ dựa trên tần suất truy cập. Nó không đụng gì tới đường mạng, độ trễ hay thông lượng khi tải lên.

Ghi nhớ

⚠ Bốn cách tăng tốc truyền dữ liệu với S3 — bảng phải thuộc: | Cách | Chiều | Khi nào | |---|---|---| | Transfer Acceleration | lên | người dùng ở xa Region của bucket | | Multipart upload | lên | tệp lớn, mạng không ổn định | | CloudFront | xuống | phân phối nội dung cho nhiều người | | Byte-range fetch | xuống | tải song song một object lớn |

Từ khoá nhận diện:

"users in Europe uploading to a US bucket" → Transfer Acceleration "high-resolution images" / tệp lớn → multipart upload "upload times" → loại mọi phương án về phân phối xuống "byte-range fetches" cho bài toán upload → SAI, đó là kỹ thuật tải xuống "Intelligent Tiering" để tăng tốc → SAI, đó là chuyện chi phí lưu trữ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Transfer Acceleration có nhanh hơn thật không | công cụ so tốc độ của AWS cho từng Region | | Có phần tải dở nào không | aws s3api list-multipart-uploads --bucket <ten> | | Thời gian tải thực tế | đo từ chính máy người dùng ở châu Âu, không đo từ máy dev |

Và một lời khuyên: hãy đặt lifecycle rule AbortIncompleteMultipartUpload ngay khi bật multipart, đừng để sau. Đây là khoản chi phí ẩn điển hình của S3: mỗi lần tải lên bị đứt — mạng di động rớt, người dùng đóng ứng dụng, pin hết — các phần đã tải vẫn nằm lại trong bucket và vẫn được tính tiền lưu trữ đầy đủ. Chúng không xuất hiện khi bạn liệt kê object, không hiện trong console ở chế độ xem thông thường, và tổng dung lượng bucket mà bạn nhìn thấy cũng không tính chúng. Cách duy nhất phát hiện là chủ động gọi list-multipart-uploads — và với một ứng dụng di động có hàng nghìn lượt tải lên mỗi ngày, phần rác tích luỹ có thể vượt xa phần dữ liệu thật trước khi có ai nghĩ tới việc đi tìm.

Đáp án

B — Kiểm tra security group của các EC2 instance, đảm bảo nó cho phép lưu lượng vào từ văn phòng khách hàng.

Vì sao đúng

Câu này xoay quanh một đặc điểm của Network Load Balancer mà rất nhiều người hiểu sai: NLB không có security group (đề nói thẳng điều đó), và khi target được đăng ký theo instance-id, NLB giữ nguyên IP nguồn của khách.

⚠ Điểm mấu chốt: NLB giữ nguyên IP nguồn, nên security group của EC2 nhìn thấy IP của KHÁCH chứ không phải IP của NLB:

Khách ở văn phòng, IP công cộng 203.0.113.10
        ↓
    Kết nối tới NLB
        ↓
    NLB chuyển tiếp, GIỮ NGUYÊN IP nguồn 203.0.113.10
        ↓
    EC2 nhận gói tin có source = 203.0.113.10
        ↓
    → security group của EC2 phải cho phép 203.0.113.10, không phải cho phép NLB

Đây là khác biệt căn bản với Application Load Balancer. ALB kết thúc kết nối rồi mở kết nối mới tới target, nên EC2 thấy IP của ALB và security group phải cho phép security group của ALB. Với NLB đăng ký theo instance-id thì hoàn toàn ngược lại.

Chi tiết health check xanh cũng là một manh mối bị bỏ qua. Health check của NLB xuất phát từ chính các node NLB, có IP thuộc dải subnet của NLB. Nếu security group của EC2 cho phép dải subnet đó nhưng không cho phép IP của khách, ta có đúng bức tranh của đề: health check qua, người dùng thật bị chặn.

# xem security group của EC2 đang cho ai vào
aws ec2 describe-security-groups --group-ids sg-ec2-app \
  --query 'SecurityGroups[0].IpPermissions'

# mở cho dải IP của văn phòng khách
aws ec2 authorize-security-group-ingress --group-id sg-ec2-app \
  --protocol tcp --port 443 --cidr 203.0.113.0/24

⚠ Đăng ký theo instance-id và theo IP cho ra hành vi khác nhau: | Kiểu đăng ký target | EC2 thấy IP nguồn là | |---|---| | Instance ID | IP thật của khách | | IP address | IP riêng của node NLB |

Đây là điều nhiều người không biết, và nó đổi hoàn toàn cách viết security group.

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

• C (kiểm security group của EC2 cho phép vào từ các subnet của NLB) — đây là phương án gần nhất và nó gần như đúng, chỉ sai về nguồn cần cho phép: đúng là phải sửa security group của EC2 chứ không phải của NLB, và với kiểu đăng ký theo IP address thì đây sẽ là câu trả lời chính xác. Nhưng đề nói rõ target được đăng ký theo instance-id, nghĩa là IP nguồn được giữ nguyên và EC2 nhìn thấy IP của khách. Cho phép dải subnet của NLB thì chỉ đủ để health check thành công — đúng như hiện trạng đề mô tả — mà vẫn chặn lưu lượng thật của người dùng. Đây là bẫy tinh vi nhất của câu hỏi vì nó khớp hoàn hảo với triệu chứng "health check xanh nhưng khách không vào được", chỉ có điều nó mô tả nguyên nhân chứ không phải cách chữa.

• A (kiểm security group của NLB cho phép vào từ Elastic IP của NLB) — hai lỗi cùng lúc. Thứ nhất, đề đã nói NLB không được gắn security group — không có gì để kiểm. Thứ hai, kể cả nếu có, việc cho phép chính Elastic IP của NLB cũng vô nghĩa: lưu lượng đến từ khách, không đến từ chính nó.

• D (kiểm security group của NLB cho phép vào từ security group của EC2) — cũng dựa trên một thứ không tồn tại trong bài toán này, và còn sai chiều: lưu lượng đi từ khách qua NLB tới EC2, không đi từ EC2 lên NLB.

Ghi nhớ

⚠ Bốn khác biệt giữa ALB và NLB về mạng — bảng phải thuộc: | | ALB | NLB | |---|---|---| | Tầng | 7 (HTTP/HTTPS) | 4 (TCP/UDP/TLS) | | Security group | bắt buộc có | tuỳ chọn — trước 8/2023 thì không có | | IP nguồn tại target | IP của ALB | IP thật của khách (nếu đăng ký theo instance-id) | | Địa chỉ | tên miền, IP thay đổi | Elastic IP tĩnh mỗi AZ |

Từ khoá nhận diện:

"NLB" + "registered by instance-id" → IP nguồn được giữ nguyên "targets are healthy but customers cannot connect" → health check qua, lưu lượng thật bị chặn "NLB has not been associated with a security group" → loại mọi phương án nói về SG của NLB ALB + target không nhận được lưu lượng → cho phép security group của ALB "allow ingress from the NLB subnets" khi đăng ký theo instance-id → chỉ đủ cho health check

Ba việc kiểm chứng: | Việc | Cách | |---|---| | EC2 thấy IP nguồn nào | đọc log web server trên chính máy đó | | Gói tin có tới không | VPC Flow Logs, tìm bản ghi REJECT | | Rule đang cho ai vào | describe-security-groups trên SG của EC2 |

Và một lời khuyên: hãy đọc log của web server trên chính EC2 để xem IP nguồn nó thật sự nhận được, đừng suy luận từ sơ đồ kiến trúc. Đây là chỗ hiểu nhầm dai dẳng nhất về NLB, và nó khó phát hiện chính vì hệ thống trông hoàn toàn khoẻ mạnh: target group xanh, health check qua đều, NLB báo active, không có lỗi nào ở bất kỳ đâu. Mọi chỉ số bạn quen theo dõi đều nói rằng bộ cân bằng tải đang hoạt động bình thường — bởi vì đúng là nó đang hoạt động bình thường. Thứ duy nhất không hoạt động là kết nối của người dùng thật, và họ không xuất hiện trong bất kỳ chỉ số nào vì gói tin của họ bị vứt bỏ trước khi tới được ứng dụng.