Ngân hàng đề — AWS Certified SysOps Administrator Associate

Đáp án

D — Dùng AWS SECRETS MANAGER: tạo secret cho CSDL, chọn đúng loại CSDL để Secrets Manager tự dùng Lambda xoay mật khẩu, đặt lịch xoay 30 ngày, và sửa các hàm Lambda đọc mật khẩu từ đó.

Vì sao đúng

Đề yêu cầu hai thứ — không lưu mật khẩu dạng thô, và xoay mật khẩu mỗi 30 ngày — kèm điều kiện ít công vận hành nhất. Secrets Manager là dịch vụ duy nhất làm cả hai sẵn có.

⚠ Điểm mấu chốt — xoay mật khẩu là việc KHÓ, và Secrets Manager làm sẵn:

Xoay mật khẩu CSDL đúng cách đòi:
    1. Sinh mật khẩu mới
    2. Đặt mật khẩu mới VÀO CSDL
    3. Cập nhật secret
    4. Không được để ứng dụng đứt trong lúc chuyển
        ↓
    Bước 4 là chỗ tự làm hay hỏng nhất
        ↓
Secrets Manager giải bằng chiến lược BỐN NHÃN
        ↓
    AWSCURRENT  → bản đang dùng
    AWSPENDING  → bản mới, đang được kiểm thử
    AWSPREVIOUS → bản trước đó, giữ để lùi lại
        ↓
    Bốn bước: createSecret → setSecret →
              testSecret → finishSecret
        ↓
    → chỉ đổi AWSCURRENT khi bản mới ĐÃ TEST XONG

⚠ Và tích hợp sẵn với RDS là điểm mấu chốt:

Tạo secret → chọn "Credentials for RDS database"
        ↓
    Chọn instance RDS trong danh sách
        ↓
    AWS TỰ TẠO hàm Lambda xoay mật khẩu
      (từ template có sẵn cho MySQL/PostgreSQL/
       Oracle/SQL Server/MariaDB)
        ↓
    Đặt chu kỳ: 30 ngày
        ↓
    → không viết một dòng mã xoay nào

⚠ Cách hàm Lambda đọc secret:

Gọi GetSecretValue qua SDK
        ↓
    Quyền: secretsmanager:GetSecretValue trong role
        ↓
    Nên CACHE trong bộ nhớ, làm mới khi lỗi xác thực
      (dùng thư viện caching chính thức của AWS)
        ↓
    → giảm số lời gọi API và giảm độ trễ

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

• C (dùng SSM Parameter Store kiểu SecureString, tự viết Lambda xoay, hẹn giờ bằng EventBridge) — đây là phương án gần nhất và hoàn toàn khả thi, cũng thoả yêu cầu "không lưu dạng thô". Nhưng Parameter Store không có cơ chế xoay tích hợp: bạn phải tự viết, tự kiểm thử, tự xử lý cửa sổ chuyển đổi để ứng dụng không đứt. Trái với yêu cầu "ít công vận hành nhất".

• A (mã hoá mật khẩu bằng KMS rồi lưu vào biến môi trường, tự viết Lambda xoay) — thoả yêu cầu mã hoá, nhưng mỗi lần xoay phải cập nhật biến môi trường của TỪNG hàm Lambda — tức là triển khai lại từng hàm. Rất nhiều việc và rất dễ sót.

• B (lưu thẳng mật khẩu vào biến môi trường) — vi phạm luôn yêu cầu đầu tiên: biến môi trường của Lambda hiện ra dạng thô trên console với bất kỳ ai đọc được cấu hình hàm.

Ghi nhớ

⚠ Secrets Manager ↔ Parameter Store — bảng phải thuộc: | | Secrets Manager | Parameter Store | |---|---|---| | Xoay tự động | CÓ, tích hợp sẵn với RDS/Redshift/DocumentDB | không — phải tự viết | | Chi phí | có phí mỗi secret mỗi tháng + phí API | Standard MIỄN PHÍ | | Mã hoá | luôn dùng KMS | SecureString dùng KMS | | Sao chép đa Region | có sẵn | không | | Chia sẻ giữa tài khoản | resource policy | không trực tiếp | | Dùng khi | bí mật cần XOAY | cấu hình, tham số không nhạy cảm |

Từ khoá nhận diện:

"xoay mật khẩu tự động" → Secrets Manager, luôn luôn "lưu cấu hình, miễn phí" → Parameter Store "ít công vận hành nhất" → dịch vụ có sẵn tính năng, không tự viết "mật khẩu trong biến môi trường" → luôn SAI "khoá truy cập của EC2/Lambda tới AWS" → IAM role, không phải secret

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lịch xoay đã bật chưa | describe-secret → RotationEnabled, RotationRules | | Lần xoay gần nhất | LastRotatedDate | | Xoay có hỏng không | CloudWatch Logs của hàm xoay, và alarm trên lỗi của nó |

Và một việc rất nên làm sau khi bật xoay tự động: đặt CloudWatch alarm cho lỗi của chính hàm xoay. Xoay mật khẩu là loại tác vụ chạy mỗi 30 ngày một lần, nên nếu nó hỏng lặng lẽ thì bạn sẽ chỉ biết vào lúc tệ nhất — khi mật khẩu cũ hết hiệu lực và ứng dụng đồng loạt mất kết nối tới CSDL.

Đáp án

B và C — Tạo AWS Systems Manager Automation document để sửa luật security group, VÀ dùng luật AWS CONFIG để phát hiện security group cho phép SSH từ 0.0.0.0/0.

Vì sao đúng

Đề đòi hai vế: phát hiện cấu hình sai, và tự động sửa. Đây đúng là mô hình chuẩn Config + Automation của AWS.

⚠ Điểm mấu chốt — hai mảnh ghép, mỗi mảnh một việc:

PHÁT HIỆN
        ↓
    Luật Config quản lý sẵn:
      restricted-ssh
      (kiểm security group có mở port 22 từ 0.0.0.0/0)
        ↓
    Vi phạm → NON_COMPLIANT
        ↓
KHẮC PHỤC
        ↓
    Gắn REMEDIATION ACTION vào chính luật đó
        ↓
    SSM Automation document:
      AWS-DisablePublicAccessForSecurityGroup
        ↓
    → gỡ luật SSH mở toang, TỰ ĐỘNG

⚠ Vì sao Config là công cụ đúng thay vì tự bắt sự kiện:

Config ĐÁNH GIÁ LẠI khi cấu hình thay đổi
        ↓
    → bắt được luật vừa bị thêm

VÀ Config còn đánh giá theo CHU KỲ
        ↓
    → bắt được cả những security group ĐÃ SAI TỪ TRƯỚC
      khi luật mới được bật
        ↓
    Đây là điều một bộ bắt sự kiện thuần tuý
    KHÔNG làm được

⚠ Nhiều Region thì dùng conformance pack:

Đề nói "nhiều Region"
        ↓
    Config là dịch vụ THEO TỪNG REGION
        ↓
    → phải bật ở MỌI Region đang dùng
        ↓
    Cách nhân rộng:
      Conformance Pack triển khai theo tổ chức
      hoặc CloudFormation StackSets
        ↓
    Tổng hợp kết quả: Config AGGREGATOR

Xem thêm câu #11792: cùng mô hình Config phát hiện + SSM Automation khắc phục, ở đó áp cho một loại tài nguyên khác.

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

• A (dùng EventBridge bắt thay đổi security group rồi gọi Lambda để sửa) — đây là phương án gần nhất và thực sự chạy được, nhưng nó là cách tự làm lại thứ Config đã có sẵn: phải viết và bảo trì Lambda, và không bắt được các security group đã sai từ trước vì chỉ phản ứng với sự kiện thay đổi. Không có báo cáo tuân thủ nào đi kèm.

• D (dùng GuardDuty để cảnh báo khi security group mở SSH) — GuardDuty phát hiện HÀNH VI ĐE DOẠ (đào tiền ảo, gọi tới hạ tầng độc hại, dò quét), không kiểm tra cấu hình có tuân thủ hay không. Việc đó là của Config.

• E (dùng CloudTrail theo dõi thay đổi rồi gửi thông báo qua SNS) — chỉ dừng ở thông báo, không có bước tự sửa mà đề yêu cầu.

Ghi nhớ

⚠ Bốn dịch vụ bảo mật — đừng lẫn vai trò: | Dịch vụ | Việc | |---|---| | Config | CẤU HÌNH có tuân thủ không — và khắc phục được | | GuardDuty | HÀNH VI đe doạ — phân tích log, dùng ML | | Inspector | LỖ HỔNG phần mềm trên EC2, container, Lambda | | Security Hub | TỔNG HỢP phát hiện, chấm điểm theo chuẩn | | CloudTrail | AI đã làm gì — nguồn dữ liệu, không tự phán xét |

Từ khoá nhận diện:

"phát hiện cấu hình sai VÀ tự sửa" → Config rule + SSM Automation "phát hiện hành vi bất thường" → GuardDuty "quét lỗ hổng CVE" → Inspector "nhìn tổng thể nhiều tài khoản, nhiều Region" → Security Hub + Config aggregator "NGĂN không cho tạo luật đó" → SCP, mạnh hơn cả phát hiện

Ba việc kiểm chứng: | Việc | Cách | |---|---| | SG nào đang vi phạm | Config → luật restricted-ssh → Non-compliant resources | | Khắc phục có chạy không | Systems Manager → Automation → Executions | | Có ai mở lại không | CloudTrail, tìm AuthorizeSecurityGroupIngress |

Và một lưu ý về chế độ khắc phục nên chọn: bắt đầu bằng chế độ chờ duyệt tay, đừng bật tự động ngay. Một luật SSH mở toang đôi khi lại là đường vào duy nhất mà một đội nào đó đang dùng cho công việc thật — tự động gỡ nó lúc nửa đêm sẽ biến một vấn đề bảo mật thành một sự cố vận hành, và lần sau sẽ không ai cho bạn bật lại cơ chế này nữa.

Đáp án

C — Dùng VAULT LOCK POLICY của Glacier.

Vì sao đúng

Yêu cầu là tuân thủ: dữ liệu phải được giữ ít nhất 7 năm và không ai được xoá sớm. Chỉ vault lock policy tạo ra ràng buộc không thể đảo ngược.

⚠ Điểm mấu chốt — vault lock khoá chính sách lại vĩnh viễn:

Vault ACCESS policy
        ↓
    Giống bucket policy — kiểm soát ai làm gì
        ↓
    SỬA ĐƯỢC bất cứ lúc nào
        ↓
    → không dùng cho tuân thủ được:
      ai sửa được chính sách thì cũng xoá được dữ liệu

Vault LOCK policy
        ↓
    Chứa các điều kiện tuân thủ, ví dụ:
      "chặn xoá archive dưới 2555 ngày tuổi"
        ↓
    Sau khi KHOÁ: KHÔNG SỬA, KHÔNG GỠ được
        ↓
    → kể cả tài khoản gốc cũng không
    → đây mới là WORM thật sự

⚠ Quy trình khoá gồm hai bước, có 24 giờ để hối hận:

1. InitiateVaultLock
      → chính sách vào trạng thái IN PROGRESS
      → nhận về một lockId
        ↓
2. Trong 24 GIỜ: kiểm thử thật
      → thử xoá một archive, phải bị từ chối
      → thử các thao tác nghiệp vụ, phải vẫn chạy
        ↓
3a. CompleteVaultLock (kèm lockId)
      → LOCKED — VĨNH VIỄN, không quay lại
3b. AbortVaultLock
      → huỷ, sửa chính sách rồi làm lại
        ↓
    Quá 24 giờ mà không complete → tự huỷ

⚠ Ví dụ điều kiện cho yêu cầu 7 năm:

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "glacier:DeleteArchive",
  "Condition": {
    "NumericLessThan": {
      "glacier:ArchiveAgeInDays": "2555"
    }
  }
}

2555 ngày ≈ 7 năm
        ↓
    → archive chưa đủ 7 năm tuổi thì KHÔNG XOÁ được

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

• D (vault access policy) — đây là phương án gần nhất và cú pháp gần như y hệt, nhưng nó sửa và gỡ được bất cứ lúc nào. Với yêu cầu tuân thủ, một chính sách có thể bị gỡ thì không có giá trị chứng minh nào.

• A (vault notification) — chỉ gửi thông báo qua SNS khi một công việc lấy dữ liệu hoàn tất. Không kiểm soát gì về việc xoá.

• B (data retrieval policy) — kiểm soát tốc độ và chi phí LẤY dữ liệu ra (giới hạn GB mỗi giờ, hoặc chỉ dùng mức miễn phí). Không liên quan tới việc giữ dữ liệu.

Ghi nhớ

⚠ Bốn loại chính sách của Glacier — bảng phải thuộc: | Chính sách | Việc | |---|---| | Vault Lock policy | ràng buộc TUÂN THỦ, khoá vĩnh viễn — WORM | | Vault Access policy | ai được làm gì — sửa được | | Data Retrieval policy | giới hạn tốc độ/chi phí LẤY dữ liệu | | Vault Notification | báo qua SNS khi job xong |

Từ khoá nhận diện:

"giữ N năm, không ai được xoá" → Vault Lock, hoặc S3 Object Lock compliance "phân quyền truy cập vault" → Vault Access policy "chi phí lấy dữ liệu tăng vọt" → Data Retrieval policy "báo khi lấy xong" → Vault Notification "WORM, SEC 17a-4, bất biến" → Vault Lock hoặc Object Lock compliance

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Vault đã khoá chưa | get-vault-lock → trường State | | Chính sách khoá nội dung gì | cũng chính lệnh đó, trường Policy | | Có ai thử xoá không | CloudTrail, tìm DeleteArchive bị từ chối |

Và một lời nhắc rất nghiêm túc về bước kiểm thử 24 giờ: hãy thực sự dùng hết cửa sổ đó. Vault Lock là một trong số rất ít thao tác trên AWS không có đường lùi — chính sách viết sai một điều kiện sẽ khoá luôn cả những thao tác nghiệp vụ hợp lệ, và cách sửa duy nhất còn lại là xoá cả vault sau khi mọi archive đã hết thời hạn giữ, tức là bảy năm nữa.

Đáp án

B — Tần suất request tới S3 quá cao.

Vì sao đúng

Mã lỗi 503 Service Unavailable từ S3 gần như luôn có nghĩa là SlowDown — bạn đang vượt ngưỡng thông lượng của một prefix.

⚠ Điểm mấu chốt — S3 giới hạn theo PREFIX:

Mỗi PREFIX trong bucket chịu được:
        ↓
    3.500 PUT/COPY/POST/DELETE mỗi giây
    5.500 GET/HEAD mỗi giây
        ↓
Website tĩnh với hàng nghìn người dùng
        ↓
    Nếu mọi tệp nằm ở CÙNG MỘT prefix
    (ví dụ đều ở gốc bucket)
        ↓
    → toàn bộ lưu lượng dồn vào một ngưỡng
    → vượt ngưỡng → 503 SlowDown

⚠ Cách chữa — theo thứ tự hiệu quả:

1. ĐẶT CLOUDFRONT TRƯỚC BUCKET   ← tốt nhất
        ↓
    Nội dung tĩnh được cache ở edge
    → phần lớn request KHÔNG chạm tới S3
    → vừa hết 503, vừa nhanh hơn, vừa rẻ hơn

2. CHIA NHIỀU PREFIX
        ↓
    /images/, /css/, /js/, /2026/01/…
    → mỗi prefix một hạn ngạch riêng

3. THỬ LẠI CÓ BACKOFF LUỸ THỪA
        ↓
    SDK của AWS đã làm sẵn — chỉ cần bật/giữ

4. S3 tự mở rộng theo thời gian
        ↓
    → nhưng cần vài phút tới vài chục phút
      để thích nghi với mẫu truy cập mới

⚠ Phân biệt với các mã lỗi khác của S3:

403 AccessDenied      → quyền, chính sách, presigned URL sai
404 NoSuchKey         → không có tệp đó
400 Bad Request       → request sai định dạng
503 SlowDown          → VƯỢT NGƯỠNG  ← đề này
500 Internal Error    → lỗi phía AWS, cứ thử lại

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

• C (presigned URL đã hết hạn nên không còn tồn tại) — đây là phương án gần nhất về mặt "có gì đó hết hiệu lực", nhưng presigned URL hết hạn trả về 403 Forbidden, không phải 503. (Và một website tĩnh công khai thì không dùng presigned URL.)

• A (người dùng không có quyền truy cập website) — thiếu quyền trả về 403, và triệu chứng sẽ xuất hiện ngay từ đầu với mọi người, chứ không phải sau khi lượng truy cập tăng lên.

• D (có vấn đề với dịch vụ S3 Transfer Acceleration) — website tĩnh không dùng Transfer Acceleration, và nếu có sự cố dịch vụ thì mã lỗi sẽ khác.

Ghi nhớ

⚠ Mã lỗi S3 và nguyên nhân — bảng phải thuộc: | Mã | Tên | Nguyên nhân | |---|---|---| | 503 | SlowDown | vượt ngưỡng request mỗi prefix | | 403 | AccessDenied | chính sách, ACL, presigned hết hạn, Block Public Access | | 404 | NoSuchKey / NoSuchBucket | sai key hoặc sai tên bucket | | 400 | InvalidRequest | thiếu header, sai chữ ký | | 500 | InternalError | lỗi phía AWS — thử lại | | 301 | PermanentRedirect | gọi sai Region của bucket |

Từ khoá nhận diện:

"503 từ S3" → quá tải, dùng CloudFront "403" → quyền hoặc chính sách "website tĩnh, nhiều người dùng toàn cầu" → CloudFront, gần như luôn đúng "cần thông lượng cao hơn" → chia nhiều prefix "tải lên chậm từ xa" → Transfer Acceleration

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có bao nhiêu 503 | CloudWatch → 5xxErrors của bucket (bật request metrics) | | Request tập trung vào prefix nào | S3 server access log hoặc CloudTrail data events | | CloudFront đã đỡ được chưa | CacheHitRate, và số request tới S3 giảm bao nhiêu |

Và một nhận xét đáng nói về chính kiến trúc trong đề: phục vụ một website tĩnh cho hàng nghìn người dùng toàn cầu bằng S3 trần là điều gần như không nên làm. CloudFront giải quyết cùng lúc bốn vấn đề — quá tải, độ trễ, chi phí truyền dữ liệu và việc phải mở bucket ra công khai — nên trong hầu hết đề thi lẫn hệ thống thật, "S3 + CloudFront" mới là cặp mặc định, còn "S3 một mình" chỉ hợp với môi trường nội bộ hoặc lưu lượng nhỏ.

Đáp án

D — Phải sửa luật NETWORK ACL để cho phép lưu lượng ĐI RA tới máy tính tại chỗ.

Vì sao đúng

Hai dòng flow log trong đề đã trả lời gần như trọn vẹn — chỉ cần đọc đúng.

⚠ Điểm mấu chốt — đọc hai dòng log:

Dòng 1:  3.104.75.244 → 172.31.10.10   ACCEPT
        ↓
    Gói ping ĐI VÀO đã được CHẤP NHẬN
    → security group inbound ĐÚNG
    → NACL inbound ĐÚNG
    → gói tin ĐÃ TỚI được máy EC2

Dòng 2:  172.31.10.10 → 3.104.75.244   REJECT
        ↓
    Gói trả lời ĐI RA bị TỪ CHỐI
        ↓
    → chỉ có một thứ chặn được chiều ra ở đây

⚠ Vì sao chắc chắn là NACL chứ không phải security group:

SECURITY GROUP có trạng thái (stateful)
        ↓
    Đã cho gói vào → gói trả lời TỰ ĐỘNG được ra
    → KHÔNG cần luật outbound nào
    → nên SG không thể là thủ phạm của dòng REJECT

NETWORK ACL KHÔNG có trạng thái (stateless)
        ↓
    Chiều vào và chiều ra được xét ĐỘC LẬP
    → cho vào rồi vẫn phải có luật cho RA
    → thiếu luật ra → REJECT
        ↓
    → thủ phạm là NACL, chiều OUTBOUND

⚠ Sửa thế nào — và một lưu ý về giao thức:

Ping dùng ICMP, không dùng TCP/UDP
        ↓
    → KHÔNG có khái niệm "cổng tạm" ở đây
    → phải mở ICMP chiều ra tới 3.104.75.244
        ↓
Nhưng nếu là TCP (SSH, HTTP…) thì
        ↓
    Chiều ra phải mở DẢI CỔNG TẠM
      1024-65535
        ↓
    → đây là lỗi NACL phổ biến nhất

Xem thêm câu #11631, #11686, #11721, #11727, #11730, #11793 và #11799: cùng chùm NACL không nhớ trạng thái. Mọi câu đều quy về một nguyên tắc — NACL phải mở cả hai chiều, security group thì không.

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

• A (sửa luật security group để cho phép lưu lượng ra tới máy tại chỗ) — đây là phương án gần nhất vì cũng nói đúng chiều (outbound), nhưng sai ở loại thành phần: security group có trạng thái, gói trả lời cho một kết nối đã được chấp nhận luôn được đi ra, bất kể luật outbound.

• C (sửa security group để cho phép lưu lượng vào) — dòng log đầu tiên đã là ACCEPT, chứng minh chiều vào hoàn toàn thông.

• B (sửa NACL để cho phép lưu lượng vào) — cũng bị chính dòng ACCEPT đầu tiên bác bỏ.

Ghi nhớ

⚠ Security Group ↔ Network ACL — bảng phải thuộc: | | Security Group | Network ACL | |---|---|---| | Trạng thái | CÓ (stateful) | KHÔNG (stateless) | | Phạm vi | ENI / instance | cả SUBNET | | Luật | chỉ có Allow | Allow VÀ Deny | | Thứ tự xét | xét tất cả, hợp lại | theo SỐ THỨ TỰ, dừng ở luật khớp đầu tiên | | Mặc định | vào: chặn hết, ra: mở hết | NACL mặc định mở cả hai chiều | | Chiều ra của gói trả lời | tự động cho qua | PHẢI CÓ LUẬT |

Từ khoá nhận diện:

"flow log: vào ACCEPT, ra REJECT" → NACL thiếu luật OUTBOUND "vào REJECT" → security group hoặc NACL inbound "kết nối TCP hỏng một chiều" → NACL thiếu DẢI CỔNG TẠM 1024-65535 "cần CHẶN một IP cụ thể" → NACL (SG không có luật Deny) "timeout" → gói bị bỏ im lặng — SG, NACL, hoặc route table

Ba việc kiểm chứng: | Việc | Cách | |---|---| | NACL nào đang gắn vào subnet | describe-network-acls --filters Name=association.subnet-id,Values=... | | Gói bị chặn ở đâu | VPC Flow Logs — tìm dòng REJECT và xem hướng | | Đường đi lý thuyết | VPC Reachability Analyzer — chỉ ra đúng thành phần chặn |

Và một công cụ nên dùng trước khi ngồi đọc log dòng nào: VPC Reachability Analyzer. Nó phân tích đường đi từ nguồn tới đích mà không cần gửi gói tin nào, rồi nói thẳng "bị chặn tại network ACL nào, luật số mấy" — nhanh hơn nhiều so với việc bật flow log rồi chờ dữ liệu tới, và đặc biệt hữu ích khi đường đi có nhiều chặng như trong kiến trúc VPN của đề này.

Đáp án

A — Bật DATA EVENT logging trong AWS CloudTrail.

Vì sao đúng

Đề yêu cầu theo dõi thao tác tải lên và tải xuống từng đối tượng — đó là data event, không phải management event.

⚠ Điểm mấu chốt — hai loại sự kiện của CloudTrail:

MANAGEMENT EVENT  (bật mặc định, miễn phí)
        ↓
    Thao tác trên chính TÀI NGUYÊN:
      CreateBucket, DeleteBucket,
      PutBucketPolicy, PutBucketAcl
        ↓
    → KHÔNG ghi việc đọc/ghi từng đối tượng

DATA EVENT  (phải bật riêng, CÓ PHÍ)  ← đề này
        ↓
    Thao tác trên DỮ LIỆU:
      s3:GetObject, s3:PutObject, s3:DeleteObject
      (và lambda:Invoke, dynamodb:GetItem…)
        ↓
    → đúng thứ đề cần: tải lên và tải xuống

⚠ Và bản ghi CloudTrail có đủ bốn thông tin đề đòi:

userIdentity.accountId    → TÀI KHOẢN của người gọi
userIdentity.arn / type   → IAM user hoặc ROLE
eventTime                 → THỜI ĐIỂM gọi API
sourceIPAddress           → ĐỊA CHỈ IP nguồn
        ↓
    Cộng thêm:
      eventName, requestParameters (bucket, key),
      errorCode nếu bị từ chối,
      userAgent

⚠ Cấu hình cho gọn — đừng bật cho toàn bộ S3:

Bật data event có phí theo SỐ SỰ KIỆN
        ↓
    Bật cho MỌI bucket trong tài khoản
      → hoá đơn có thể rất lớn
        ↓
    Nên:  chỉ chọn ĐÚNG bucket nhạy cảm
          hoặc dùng advanced event selector
          lọc theo prefix
        ↓
    Ví dụ: chỉ ghi PutObject và GetObject
           trên arn:aws:s3:::bucket-nhay-cam/

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

• C (bật management event logging trong CloudTrail) — đây là phương án gần nhất và cùng dịch vụ, nhưng management event chỉ ghi thao tác trên cấu hình bucket, không ghi việc đọc/ghi từng đối tượng. Đây chính là điểm phân biệt mà câu hỏi nhắm tới.

• B và D (Amazon Inspector) — Inspector là dịch vụ quét LỖ HỔNG cho EC2, container và Lambda. Không có "user event logging" hay "bucket event logging" trong Inspector; nó hoàn toàn không ghi log truy cập S3.

Ghi nhớ

⚠ Management event ↔ Data event — bảng phải thuộc: | | Management event | Data event | |---|---|---| | Ghi gì | thao tác trên tài nguyên | thao tác trên DỮ LIỆU | | Ví dụ S3 | CreateBucket, PutBucketPolicy | GetObject, PutObject, DeleteObject | | Ví dụ khác | RunInstances, CreateUser | lambda:Invoke, dynamodb:PutItem | | Bật sẵn | CÓ (90 ngày trong Event history) | KHÔNG — phải bật riêng | | Chi phí | bản đầu miễn phí | CÓ PHÍ theo số sự kiện | | Khối lượng | ít | rất lớn |

Từ khoá nhận diện:

"ai đã tải lên / tải xuống đối tượng nào" → CloudTrail DATA EVENT "ai đã đổi chính sách bucket" → management event "phân tích request HTTP tới bucket" → S3 server access log (rẻ hơn, nhưng ít chi tiết về danh tính) "quét lỗ hổng" → Inspector "phát hiện truy cập bất thường vào S3" → GuardDuty S3 Protection

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Data event đã bật chưa | get-event-selectors --trail-name ... | | Có bản ghi nào chưa | Athena, truy vấn eventName = 'GetObject' | | Đang tốn bao nhiêu | Cost Explorer, lọc dịch vụ CloudTrail |

Và một cấu hình nên chốt ngay khi bật data event: chỉ chọn đúng những bucket cần kiểm toán, và dùng advanced event selector để lọc theo prefix. Một bucket phục vụ ứng dụng có thể sinh hàng triệu GetObject mỗi ngày — bật không giới hạn thì chi phí ghi log dễ dàng vượt qua chi phí lưu trữ chính dữ liệu đó, và bạn sẽ phải tắt nó đi đúng lúc đang cần nó nhất.

Đáp án

C và E — Loại instance của CSDL bị THAY ĐỔI, và LỖI LƯU TRỮ trên node chính.

Vì sao đúng

RDS Multi-AZ chỉ failover khi node chính hoặc AZ của nó thực sự không phục vụ được, hoặc khi một thao tác quản trị yêu cầu điều đó.

⚠ Điểm mấu chốt — danh sách nguyên nhân failover chính thức:

1. Node chính hoặc cả AZ MẤT KẾT NỐI / hỏng
2. LỖI LƯU TRỮ trên node chính           ← phương án E
3. ĐỔI LOẠI INSTANCE (scale up/down)     ← phương án C
4. VÁ LỖI hệ điều hành hoặc động cơ CSDL
5. Failover THỦ CÔNG (reboot with failover)
        ↓
    Điểm chung: node chính KHÔNG CÒN
    phục vụ được, hoặc đang được thay thế

⚠ Vì sao đổi loại instance lại gây failover — và đó là điều TỐT:

Đổi cỡ Multi-AZ
        ↓
    1. AWS đổi cỡ node DỰ PHÒNG trước
    2. FAILOVER sang node đã đổi cỡ
    3. Đổi cỡ node cũ (nay là dự phòng)
        ↓
    → gián đoạn chỉ đúng lúc failover (60-120 giây)
    → thay vì tắt máy chính vài phút
        ↓
    Đây là cách AWS GIẢM gián đoạn,
    không phải một sự cố

⚠ Cơ chế Multi-AZ hoạt động thế nào:

Node chính  ──(sao chép ĐỒNG BỘ)──▶  node dự phòng
      ở AZ 1                            ở AZ 2
        ↓
    Dự phòng KHÔNG phục vụ truy vấn nào
        ↓
    Khi failover:
      bản ghi DNS của endpoint được trỏ sang AZ 2
        ↓
    → ENDPOINT KHÔNG ĐỔI
    → ứng dụng chỉ cần kết nối lại
    → nhớ đặt TTL của DNS cache ngắn trong JVM

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

• D (lỗi hỏng dữ liệu — database corruption) — đây là phương án gần nhất và nghe rất hợp lý, nhưng dữ liệu hỏng được sao chép ĐỒNG BỘ sang node dự phòng, nên failover không giải quyết được gì — RDS vì thế không failover vì lý do này. Cách xử lý là khôi phục theo thời điểm (PITR).

• A (tranh chấp ĐỌC trên node dự phòng) — node dự phòng không phục vụ truy vấn đọc nào cả, nên không có tranh chấp nào để nói tới.

• B (tranh chấp GHI trên node chính) — tải cao không phải là điều kiện failover. CSDL sẽ chậm đi, nhưng vẫn đang phục vụ, nên RDS giữ nguyên node chính.

Ghi nhớ

⚠ Nguyên nhân failover ↔ KHÔNG phải nguyên nhân — bảng phải thuộc: | Gây failover | KHÔNG gây failover | |---|---| | Mất AZ hoặc mất node chính | tải cao, tranh chấp ghi | | Lỗi lưu trữ trên node chính | dữ liệu hỏng (corruption) | | Đổi loại instance | truy vấn chậm | | Vá hệ điều hành / động cơ CSDL | hết dung lượng kết nối | | Reboot with failover (thủ công) | thay đổi parameter group |

Từ khoá nhận diện:

"vì sao Multi-AZ failover" → mất AZ, lỗi lưu trữ, đổi cỡ, vá lỗi "dữ liệu bị hỏng" → PITR, không phải failover "tải đọc cao" → read replica, Multi-AZ không giúp "muốn dự phòng ĐỌC ĐƯỢC" → Multi-AZ DB Cluster (3 node, 2 node đọc được) "failover mất bao lâu" → thường 60-120 giây

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Vì sao failover | RDS Events, dòng có Multi-AZ instance failover | | Đang chạy ở AZ nào | describe-db-instances --query '...AvailabilityZone' | | Ứng dụng chịu được không | chủ động failover ở môi trường staging |

Và một cấu hình rất hay bị bỏ sót ở phía ứng dụng Java: JVM mặc định cache kết quả phân giải DNS vĩnh viễn. Khi RDS failover, endpoint trỏ sang IP mới nhưng ứng dụng vẫn gọi vào IP cũ — nên nó tiếp tục lỗi rất lâu sau khi CSDL đã khoẻ trở lại, và người vận hành thì nhìn thấy một sự cố dài hàng chục phút cho một lần failover chỉ mất một phút.

Đáp án

A — Tạo Amazon EFS file system, tạo phiên bản launch template mới với user data gắn kết EFS, rồi cho Auto Scaling group dùng template mới và thay dần máy cũ.

Vì sao đúng

Đề cần nhiều máy Linux cùng đọc ghi MỘT bộ tệp chung, và dữ liệu phải nhất quán. Đó chính xác là định nghĩa của hệ thống tệp chia sẻ, và trên AWS cho Linux thì đó là EFS.

⚠ Điểm mấu chốt — EFS là hệ thống tệp gắn kết được từ nhiều máy cùng lúc:

EFS
        ↓
    Giao thức NFS v4.1
        ↓
    Gắn kết đồng thời từ HÀNG NGHÌN máy EC2
      trên nhiều AZ trong cùng VPC
        ↓
    Ngữ nghĩa file system thật:
      khoá tệp, quyền POSIX, ghi có thứ tự
        ↓
    → mọi máy thấy CÙNG một nội dung
    → đúng yêu cầu "nhất quán dữ liệu"

⚠ Và vì sao gắn kết trong user data của launch template:

ASG khởi chạy máy MỚI bất cứ lúc nào
        ↓
    Máy mới phải TỰ gắn kết EFS
        ↓
    User data trong launch template:
        ↓
      yum install -y amazon-efs-utils
      mount -t efs fs-0123abcd:/ /du-lieu-chung
        ↓
    Hoặc thêm dòng vào /etc/fstab để tự gắn khi khởi động lại
        ↓
    → mọi máy, kể cả máy sinh ra lúc 3 giờ sáng,
      đều có sẵn bộ tệp chung

⚠ Cách thay máy cũ:

Tạo phiên bản MỚI của launch template
        ↓
    Trỏ ASG sang phiên bản đó
        ↓
    INSTANCE REFRESH
        ↓
    → ASG thay máy theo lô, giữ tỉ lệ khoẻ mạnh tối thiểu
    → không cần tự tay tắt từng máy

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

• B (lưu tệp chung trên S3 và gắn kết S3 lúc khởi động) — đây là phương án gần nhất và S3 đúng là chia sẻ được, nhưng S3 là kho đối tượng, không phải hệ thống tệp. Gắn kết bằng công cụ như Mountpoint hay s3fs thì không có khoá tệp, không hỗ trợ ghi đè một phần tệp, và tính nhất quán không giống file system — trái với yêu cầu của đề.

• D (dùng một volume EBS Multi-Attach và định kỳ đồng bộ bằng Lambda) — EBS Multi-Attach chỉ dùng được với volume io1/io2 (đề đang dùng gp3 — không hỗ trợ), chỉ trong CÙNG MỘT AZ, và đòi hệ thống tệp cluster-aware (như GFS2). Một file system thường như ext4 gắn từ nhiều máy sẽ hỏng dữ liệu. Và "định kỳ đồng bộ" thì đã không còn là nhất quán.

• C (dùng ElastiCache cluster để chia sẻ và bảo đảm nhất quán) — ElastiCache là cache khoá-giá trị trong bộ nhớ, không phải hệ thống tệp. Không gắn kết được, không lưu tệp được.

Ghi nhớ

⚠ Bốn loại lưu trữ của AWS — bảng phải thuộc: | Loại | Dịch vụ | Gắn từ nhiều máy | |---|---|---| | File (NFS, Linux) | EFS | CÓ — hàng nghìn máy, nhiều AZ | | File (SMB, Windows) | FSx for Windows File Server | có | | Block | EBS | thường KHÔNG (Multi-Attach: io1/io2, cùng AZ) | | Object | S3 | có, nhưng không phải file system | | Hiệu năng cao (HPC) | FSx for Lustre | có |

Từ khoá nhận diện:

"nhiều EC2 Linux dùng chung tệp" → EFS "nhiều máy Windows dùng chung" → FSx for Windows "lưu tệp cho ứng dụng web, truy cập qua HTTP" → S3 "đĩa riêng cho một máy" → EBS "HPC, machine learning, thông lượng cực cao" → FSx for Lustre

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Máy đã gắn kết chưa | df -h và mount | grep efs | | Vì sao gắn hỏng | thường là security group cổng 2049 hoặc thiếu mount target ở AZ đó | | Có nghẽn thông lượng không | CloudWatch: PercentIOLimit, BurstCreditBalance |

Và một chi tiết dễ làm hỏng cả kiến trúc vào lúc bất tiện nhất: phải có mount target ở MỌI AZ mà Auto Scaling group có thể khởi chạy máy. Thiếu một AZ thì mọi thứ vẫn chạy êm cho tới ngày ASG quyết định mở rộng sang đúng AZ đó — và máy mới sẽ khởi động thành công, qua health check của EC2, rồi phục vụ lỗi vì không có bộ tệp chung nào được gắn.

Đáp án

C — Tạo VPC endpoint cho S3, và tạo BUCKET POLICY giới hạn mọi thao tác S3 trên bucket đó theo điều kiện nguồn là VPC endpoint.

Vì sao đúng

Đề đòi hai thứ: dữ liệu không đi qua internet công cộng, và truy cập chỉ từ các máy trong mạng riêng. Mỗi thành phần giải một vế.

⚠ Vế thứ nhất — VPC endpoint giữ lưu lượng trong mạng AWS:

VPC Gateway Endpoint cho S3
        ↓
    Thêm một tuyến vào route table của subnet:
      prefix list của S3  →  endpoint
        ↓
    Lưu lượng đi thẳng qua hạ tầng AWS
        ↓
    → KHÔNG qua Internet Gateway
    → KHÔNG qua NAT Gateway
    → KHÔNG ra internet công cộng
        ↓
    Và gateway endpoint MIỄN PHÍ

⚠ Vế thứ hai — bucket policy khoá bucket lại theo endpoint:

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": [
    "arn:aws:s3:::bucket-cua-toi",
    "arn:aws:s3:::bucket-cua-toi/*"
  ],
  "Condition": {
    "StringNotEquals": {
      "aws:sourceVpce": "vpce-0123456789abcdef0"
    }
  }
}

    → mọi request KHÔNG đi qua đúng endpoint đó
      đều bị TỪ CHỐI
        ↓
    → kể cả người có khoá hợp lệ, gọi từ internet
    → đây là vế "chỉ EC2 trong mạng riêng"

⚠ Vì sao phải là BUCKET POLICY chứ không phải IAM POLICY:

IAM policy (phương án B)
        ↓
    Chỉ áp cho danh tính ĐƯỢC GẮN chính sách đó
        ↓
    → một role khác, một tài khoản khác,
      một người dùng mới tạo
      VẪN truy cập bucket từ internet được
        ↓
Bucket policy
        ↓
    Áp cho MỌI người gọi, mọi danh tính, mọi tài khoản
        ↓
    → đây mới là "giới hạn truy cập vào BUCKET"

Xem thêm câu #11824: cùng sự phân biệt bucket policy ↔ IAM policy, ở đó là để ép mã hoá khi tải lên.

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

• B (VPC endpoint + IAM POLICY giới hạn theo endpoint) — đây là phương án gần nhất, điều kiện aws:sourceVpce hoàn toàn đúng, chỉ sai chỗ gắn chính sách vào đâu: IAM policy chỉ ràng buộc danh tính được gắn, nên bucket vẫn mở với mọi danh tính khác.

• D (tạo NAT gateway và định tuyến lưu lượng S3 qua NAT) — NAT Gateway đưa lưu lượng RA INTERNET, vi phạm thẳng yêu cầu "dữ liệu không đi qua mạng công cộng". Lại còn tốn phí xử lý dữ liệu trong khi gateway endpoint miễn phí.

• A (dựng đường hầm VPN giữa private subnet và endpoint công khai của S3) — không có cơ chế nào như vậy. VPN của AWS nối VPC với mạng tại chỗ hoặc VPC khác, không nối tới endpoint công khai của một dịch vụ.

Ghi nhớ

⚠ Hai loại VPC endpoint — bảng phải thuộc: | | Gateway endpoint | Interface endpoint (PrivateLink) | |---|---|---| | Dịch vụ | CHỈ S3 và DynamoDB | hầu hết dịch vụ AWS | | Chi phí | MIỄN PHÍ | phí theo giờ + theo GB | | Cơ chế | tuyến trong route table | ENI có IP riêng trong subnet | | Từ mạng tại chỗ | KHÔNG dùng được | dùng được qua VPN/Direct Connect | | DNS | dùng tên miền công khai của S3 | private DNS đè lên tên miền công khai |

Từ khoá nhận diện:

"không được đi qua internet" → VPC endpoint "chỉ máy trong VPC được truy cập bucket" → bucket policy + aws:sourceVpce "giới hạn theo cả VPC, không chỉ một endpoint" → aws:sourceVpc "máy TẠI CHỖ cũng cần truy cập riêng tư" → interface endpoint, không phải gateway "giảm phí NAT" → gateway endpoint cho S3 và DynamoDB

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lưu lượng có đi qua endpoint không | VPC Flow Logs — không thấy đích là IP công cộng của S3 | | Chính sách có chặn đúng không | thử aws s3 ls từ ngoài VPC — phải nhận 403 | | Endpoint đã vào route table chưa | describe-route-tables, tìm vpce- |

Và một lời khuyên rất thực tế trước khi áp bucket policy loại này: luôn thử ở một bucket kiểm thử trước, và giữ sẵn một lối vào cho quản trị. Một điều kiện StringNotEquals viết nhầm endpoint id sẽ khoá tất cả mọi người ra khỏi bucket — kể cả bạn, kể cả tài khoản gốc — và cách gỡ duy nhất khi đó là dùng tài khoản gốc để xoá bucket policy, một thao tác mà không phải tổ chức nào cũng thực hiện được nhanh.

Đáp án

C — Bật ORGANIZATIONAL VIEW trong AWS Health.

Vì sao đúng

Đề muốn gom cảnh báo Health của mọi tài khoản trong tổ chức về một chỗ, và AWS Health có sẵn đúng tính năng đó.

⚠ Điểm mấu chốt — organizational view là gì:

Bật ở TÀI KHOẢN QUẢN LÝ của Organizations
        ↓
    Health Dashboard hiển thị sự kiện của
    TẤT CẢ tài khoản thành viên
        ↓
    Tài khoản mới tham gia tổ chức
        ↓
    → TỰ ĐỘNG được đưa vào, không phải cấu hình gì
        ↓
    Đây chính là lý do nó là "hiệu quả nhất"
    khi công ty vừa thêm 10 tài khoản

⚠ Bật thế nào:

1. Tổ chức phải ở chế độ ALL FEATURES
2. Đăng nhập TÀI KHOẢN QUẢN LÝ
3. AWS Health → Organizational view → Enable
        ↓
    Hoặc:  aws health enable-health-service-access-
           for-organization
        ↓
    → Không tốn thêm chi phí
    → Không phải đụng vào từng tài khoản

⚠ Muốn tự động phản ứng thì ghép thêm EventBridge:

AWS Health phát sự kiện vào EventBridge
        ↓
    Quy tắc bắt sự kiện Health cấp TỔ CHỨC
      (chỉ ở tài khoản quản lý, Region us-east-1)
        ↓
    → SNS báo cho đội trực
    → Lambda tự xử lý (ví dụ: máy sắp bị retire
      thì stop/start trước)
    → Systems Manager Incident Manager

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

• D (dùng CloudWatch Events ở từng tài khoản rồi chuyển tiếp về một CloudWatch Logs tập trung) — đây là phương án gần nhất và thực sự chạy được, nhưng nó đòi cấu hình ở TỪNG tài khoản: 10 tài khoản mới nghĩa là 10 lần thiết lập, và mỗi tài khoản thêm về sau lại một lần nữa. Trái với yêu cầu "hiệu quả nhất".

• A (Lambda hỏi AWS Health API rồi ghi vào Aurora) — tự dựng lại một tính năng đã có sẵn, kèm hàm Lambda phải bảo trì, một CSDL phải trả tiền, và Health API đòi gói hỗ trợ Business trở lên.

• B (dùng Health API ghi sự kiện vào bucket S3) — cùng vấn đề như A: tự làm lại, và S3 không phải nơi để xem cảnh báo, phải dựng thêm công cụ truy vấn.

Ghi nhớ

⚠ Hai mặt của AWS Health — bảng phải thuộc: | | Nội dung | |---|---| | Service Health Dashboard | tình trạng chung của dịch vụ AWS — công khai, ai cũng xem được | | Personal Health Dashboard | sự kiện ảnh hưởng tới CHÍNH tài nguyên của bạn | | Organizational view | gom Personal Health của MỌI tài khoản trong tổ chức | | Health API | truy vấn bằng chương trình — cần gói Business/Enterprise | | EventBridge | phát sự kiện Health để tự động hoá |

Từ khoá nhận diện:

"gom cảnh báo Health nhiều tài khoản" → organizational view "tự động phản ứng khi có sự kiện" → EventBridge + Lambda/SNS "máy sắp bị retire" → sự kiện Health AWS_EC2_INSTANCE_RETIREMENT_SCHEDULED "gom log nhiều tài khoản" → CloudWatch Logs cross-account, hoặc trail cấp tổ chức "nhìn tuân thủ nhiều tài khoản" → Config aggregator, không phải Health

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Organizational view đã bật chưa | describe-health-service-status-for-organization | | Có sự kiện nào đang mở | describe-events-for-organization | | Cảnh báo có tới đội trực không | gửi thử một sự kiện qua EventBridge test |

Và một điều kiện dễ bị vướng khi triển khai: Health API chỉ dùng được với gói hỗ trợ Business trở lên. Bản thân organizational view trên console thì xem được, nhưng nếu kế hoạch của bạn là tự động hoá bằng API hoặc EventBridge thì cần kiểm tra gói hỗ trợ trước — nhiều đội dựng xong cả luồng tự động rồi mới phát hiện lời gọi API trả về lỗi từ chối truy cập.