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

Đáp án

A và B.

• A — Mất khả dụng ở Availability Zone chứa primary
• B — Hỏng ổ lưu trữ trên primary

Vì sao đúng

Đề hỏi những sự kiện nào khiến RDS TỰ ĐỘNG chuyển đổi sang standby — và nguyên tắc chung là: chỉ sự cố ảnh hưởng tới PRIMARY mới kích hoạt.

Cơ chế Multi-AZ:

Primary (AZ-a)  ──ĐỒNG BỘ──>  Standby (AZ-b)
    ↓ primary gặp sự cố
RDS phát hiện, tự động chuyển đổi
    ↓ CNAME endpoint trỏ sang standby cũ
Standby trở thành primary mới

Danh sách đầy đủ các sự kiện kích hoạt chuyển đổi tự động: | Sự kiện | Trong đáp án | |---|---| | Mất khả dụng cả một AZ | ✅ A | | Hỏng ổ lưu trữ trên primary | ✅ B | | Hỏng chính instance primary | | | Thay đổi loại instance của primary | | | Vá lỗi hệ điều hành của primary | | | Chuyển đổi thủ công (RebootDBInstance với failover) | |

Vì sao sự cố trên STANDBY không kích hoạt: standby không phục vụ lưu lượng nào cả — nó chỉ nhận bản sao dữ liệu. Nó hỏng thì dịch vụ vẫn chạy bình thường trên primary; AWS chỉ dựng lại một standby mới ở nền.

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

• **C. Hỏng ổ lưu trữ trên DB instance thứ hai (standby) — đây là phương án gần nhất và nghe đối xứng với B, nhưng nó không kích hoạt chuyển đổi: primary vẫn khoẻ và đang phục vụ. Chuyển đổi sang một standby đang hỏng là vô nghĩa.
• **E. Hỏng đơn vị tính toán trên DB instance thứ hai — cùng lý do: sự cố ở standby không ảnh hưởng tới việc phục vụ.
• **D. Read Replica gặp sự cố — Read Replica hoàn toàn tách biệt với cơ chế Multi-AZ: nó là bản sao bất đồng bộ phục vụ mở rộng đọc. Nó hỏng thì chỉ mất dung lượng đọc, primary và standby không bị ảnh hưởng.

Ghi nhớ

Multi-AZ và Read Replica — bảng phân biệt quan trọng nhất về RDS: | | Multi-AZ | Read Replica | |---|---|---| | Sao chép | ĐỒNG BỘ | BẤT ĐỒNG BỘ | | Mục đích | SẴN SÀNG CAO | MỞ RỘNG ĐỌC | | Phục vụ truy vấn đọc | ❌ KHÔNG | ✅ CÓ | | Chuyển đổi | tự động | thủ công (promote) | | Mất dữ liệu khi chuyển | ❌ RPO = 0 | có thể | | Khác Region | ❌ | ✅ |

Nguyên tắc gọn để nhớ:

Chỉ sự cố ở PRIMARY mới kích hoạt chuyển đổi. Standby là bản chờ thụ động; nó hỏng thì AWS lặng lẽ dựng lại cái khác.

Cơ chế chuyển đổi endpoint — điểm kỹ thuật cần biết:

Endpoint là một bản ghi CNAME
    csdl.abc123.ap-northeast-1.rds.amazonaws.com
        ↓ trỏ tới tên máy chủ của primary hiện tại
Khi chuyển đổi: CNAME được cập nhật trỏ sang máy mới
    → ĐỊA CHỈ IP THAY ĐỔI, tên endpoint KHÔNG đổi

Ba việc ứng dụng cần làm để tận dụng chuyển đổi tự động: | Việc | Lý do | |---|---| | Luôn dùng ENDPOINT, không hard-code IP | IP thay đổi sau chuyển đổi | | Đặt TTL cache DNS thấp | JVM cache DNS VĨNH VIỄN theo mặc định | | Có logic thử lại kết nối | có 60–120 giây gián đoạn |

Dòng giữa là bẫy kinh điển với ứng dụng Java: đặt networkaddress.cache.ttl=5 trong java.security, nếu không ứng dụng vẫn cố kết nối tới IP cũ sau khi chuyển đổi.

Hai chế độ Multi-AZ của RDS: | Chế độ | Đặc điểm | |---|---| | Multi-AZ instance deployment | một standby, KHÔNG phục vụ đọc | | Multi-AZ DB cluster | HAI replica CÓ phục vụ đọc, chuyển đổi dưới 35 giây |

Chế độ thứ hai (MySQL và PostgreSQL) khắc phục đúng nhược điểm "standby nằm không" — đáng cân nhắc cho triển khai mới.

Ba lưu ý về Multi-AZ: | Lưu ý | Chi tiết | |---|---| | Chi phí gần gấp đôi | trả tiền cho cả standby | | Bảo trì gần như không gián đoạn | AWS vá standby trước, chuyển đổi, rồi vá cái còn lại | | KHÔNG thay thế cho sao lưu | xoá nhầm dữ liệu thì standby cũng xoá theo |

Dòng cuối quan trọng: Multi-AZ chống sự cố hạ tầng, không chống lỗi con người. Cho vế đó cần automated backup và point-in-time recovery.

Và một cách kiểm chứng đáng làm: chủ động kích hoạt chuyển đổi thử bằng reboot-db-instance --force-failover. Nó cho biết ứng dụng của bạn thực sự chịu được bao lâu gián đoạn — thay vì phát hiện điều đó lần đầu trong một sự cố thật.

Đáp án

A — Thiết lập một AWS Control Tower Landing Zone. Bật các guardrail đóng gói sẵn để thực thi chính sách hoặc phát hiện vi phạm.

Vì sao đúng

Đề nêu ba yêu cầu, và Control Tower là dịch vụ được tạo ra chính xác cho chúng: | Yêu cầu | Cơ chế | |---|---| | Đơn giản hoá việc tạo nhiều tài khoản AWS | Account Factory | | Mỗi OU tạo tài khoản với cấu hình đã duyệt sẵn | Landing Zone với baseline chuẩn | | Chuẩn hoá baseline và cấu hình mạng | guardrail và blueprint |

Control Tower dựng sẵn cả một môi trường nhiều tài khoản:

AWS Control Tower Landing Zone tạo ra:
    ├─ AWS Organizations với cấu trúc OU chuẩn
    ├─ Tài khoản Log Archive (tập trung CloudTrail và Config)
    ├─ Tài khoản Audit (truy cập chỉ đọc cho đội bảo mật)
    ├─ AWS IAM Identity Center cho SSO
    ├─ Guardrail (SCP + Config rule) áp tự động
    └─ Account Factory để cấp phát tài khoản mới

Vế "least amount of effort" là điểm quyết định: Control Tower dựng toàn bộ những thứ trên bằng vài cú nhấp, thay vì tự cấu hình từng phần.

Hai loại guardrail: | Loại | Cơ chế | Ví dụ | |---|---|---| | Preventive | SCP — CHẶN hành động | cấm tắt CloudTrail | | Detective | AWS Config rule — PHÁT HIỆN vi phạm | phát hiện bucket S3 công khai |

Và Account Factory là câu trả lời trực tiếp cho "launch new accounts with preapproved configurations":

Người dùng yêu cầu tài khoản mới qua Service Catalog
    ↓ Account Factory tạo tài khoản
    ↓ tự động áp: OU, guardrail, VPC chuẩn, log tập trung, SSO
Tài khoản sẵn sàng dùng với baseline đã duyệt

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

• C. Thiết lập AWS Config aggregator trên tài khoản gốc để tổng hợp dữ liệu đa tài khoản, đa Region; triển khai conformance pack để chuẩn hoá baseline — đây là phương án gần nhất và conformance pack thật sự chuẩn hoá được cấu hình, nhưng nó chỉ ĐÁNH GIÁ TUÂN THỦ — nó không tạo tài khoản và không cấu hình mạng. Nó giải quyết một phần nhỏ của yêu cầu.
• B. Cấu hình AWS RAM để khởi chạy tài khoản AWS mới và chuẩn hoá baseline — nhầm chức năng: RAM CHIA SẺ TÀI NGUYÊN giữa các tài khoản (subnet, Transit Gateway, Route 53 Resolver rule). Nó không tạo tài khoản.
• D. Tập trung việc tạo tài khoản bằng Systems Manager OpsCenter; thực thi chính sách bằng Security Hub — nhầm cả hai dịch vụ: OpsCenter quản lý sự vụ vận hành (OpsItem), không tạo tài khoản. Security Hub tổng hợp finding bảo mật, không thực thi chính sách.

Ghi nhớ

Ba dịch vụ quản lý nhiều tài khoản — phân biệt vai trò: | Dịch vụ | Việc | |---|---| | AWS Organizations | NỀN TẢNG: gom tài khoản, thanh toán hợp nhất, SCP | | AWS Control Tower | DỰNG và quản trị môi trường theo chuẩn — chạy TRÊN Organizations | | AWS RAM | CHIA SẺ tài nguyên giữa các tài khoản |

Ba cái này chồng lên nhau chứ không thay thế nhau:

Organizations  → khung tổ chức
Control Tower  → tự động dựng tài khoản + guardrail
RAM            → chia sẻ tài nguyên

Năm thành phần mà Control Tower Landing Zone tạo ra: | Thành phần | Việc | |---|---| | Cấu trúc OU chuẩn | Security OU, Sandbox OU | | Tài khoản Log Archive | CloudTrail và Config log tập trung, bất biến | | Tài khoản Audit | truy cập chỉ đọc chéo tài khoản cho đội bảo mật | | IAM Identity Center | SSO cho toàn tổ chức | | Account Factory | cấp phát tài khoản mới theo mẫu |

Ba mức của guardrail: | Mức | Ý nghĩa | |---|---| | Mandatory | bắt buộc, không tắt được | | Strongly recommended | AWS khuyến nghị mạnh | | Elective | tuỳ chọn theo nhu cầu |

Ví dụ guardrail hay dùng:

Preventive: cấm tắt CloudTrail
            cấm xoá log trong Log Archive
            giới hạn Region được phép dùng
Detective:  phát hiện bucket S3 công khai
            phát hiện EBS chưa mã hoá
            phát hiện root user chưa bật MFA

Ba lưu ý khi triển khai Control Tower: | Lưu ý | Chi tiết | |---|---| | Có thể áp cho tổ chức ĐANG CÓ | tính năng "enroll existing account" | | Một số Region không hỗ trợ | kiểm tra trước | | Guardrail dùng SCP và Config | Config tính phí theo configuration item — chi phí ẩn |

Dòng cuối đáng lưu ý về ngân sách: detective guardrail chạy trên AWS Config, và Config tính phí theo số configuration item được ghi. Với tổ chức lớn, khoản này đáng kể.

Và một lựa chọn thay thế cho tổ chức đã có sẵn hạ tầng phức tạp: AWS Organizations + CloudFormation StackSets + SCP tự viết cho toàn quyền kiểm soát. Nó nhiều công hơn hẳn, nhưng phù hợp khi Control Tower quá cứng nhắc với mô hình quản trị đã có.

Đáp án

A và C.

• A — Được thiết kế cho dữ liệu ít được truy cập hơn
• C — Được thiết kế cho dữ liệu cần truy cập NHANH khi có nhu cầu

Vì sao đúng

Hai phát biểu này mô tả đúng bản chất của S3 Standard-Infrequent Access — và chúng bổ sung cho nhau chứ không mâu thuẫn:

"Infrequent Access" nói về TẦN SUẤT truy cập
    → dữ liệu ít khi được đọc          ← A

KHÔNG nói về TỐC ĐỘ khi truy cập
    → khi cần đọc thì NHANH NHƯ Standard  ← C

Đây là điểm hay bị hiểu nhầm nhất về Standard-IA: | | Standard | Standard-IA | Glacier Flexible | |---|---|---|---| | Độ trễ lần đọc đầu | mili giây | mili giây — GIỐNG Standard | 1 phút – 12 giờ | | Thông lượng | cao | cao — giống Standard | thấp | | Chi phí lưu trữ | cao | rẻ hơn ~45% | rẻ hơn nữa | | Phí truy xuất | không | CÓ, theo GB | có, cao hơn | | Độ bền | 11 số 9 | 11 số 9 — giống nhau | 11 số 9 |

Standard-IA khác Standard CHỈ ở mô hình giá, không khác về hiệu năng.

Và tình huống của đề khớp hoàn hảo: báo cáo tài chính hiếm khi được xem, nhưng khi kiểm toán viên yêu cầu thì phải có ngay. Đó chính xác là trường hợp Standard-IA được thiết kế cho.

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

• **B. Nó tự động chuyển dữ liệu sang tầng truy cập tiết kiệm nhất mà không cần công vận hành nào — đây là phương án gần nhất và mô tả đúng một lớp lưu trữ của S3, nhưng đó là S3 Intelligent-Tiering, không phải Standard-IA. Standard-IA không tự chuyển tầng — bạn phải đặt lifecycle rule.
• D. Nó cung cấp độ trễ CAO và thông lượng THẤP — sai hoàn toàn: Standard-IA có cùng độ trễ mili giây và cùng thông lượng như Standard. Mô tả này đúng với Glacier Flexible Retrieval hoặc Deep Archive.
• E. Lý tưởng để lưu trữ dài hạn (archiving) — sai lớp lưu trữ: archiving là việc của các lớp Glacier. Standard-IA dành cho dữ liệu vẫn cần truy cập ngay khi có nhu cầu, chỉ là ít khi.

Ghi nhớ

Các lớp lưu trữ S3 — bảng cần thuộc: | Lớp | Độ trễ | Chi phí lưu trữ | Phí truy xuất | |---|---|---|---| | Standard | mili giây | cao nhất | không | | Intelligent-Tiering | mili giây | tự tối ưu | không | | Standard-IA | mili giây | ~45% rẻ hơn | có | | One Zone-IA | mili giây | rẻ hơn nữa | có | | Glacier Instant Retrieval | mili giây | rẻ | có, cao hơn | | Glacier Flexible Retrieval | 1 phút – 12 giờ | rẻ hơn | có | | Glacier Deep Archive | 12–48 giờ | ~1 USD/TB/tháng | có, cao nhất |

Chú ý: bốn lớp đầu và Glacier Instant Retrieval đều có độ trễ mili giây — "rẻ hơn" không đồng nghĩa với "chậm hơn".

Ràng buộc thời gian lưu tối thiểu: | Lớp | Tối thiểu | |---|---| | Standard-IA, One Zone-IA | 30 ngày | | Glacier Instant / Flexible | 90 ngày | | Glacier Deep Archive | 180 ngày |

Xoá trước thời hạn vẫn bị tính đủ phí — nên đừng chuyển dữ liệu ngắn hạn sang các lớp này.

Bẫy chi phí quan trọng của Standard-IA:

Chuyển dữ liệu VẪN được truy cập thường xuyên sang Standard-IA
    → tiết kiệm phí lưu trữ
    → NHƯNG phí truy xuất có thể VƯỢT khoản tiết kiệm
    → tổng chi phí ĐẮT HƠN Standard

Standard-IA chỉ tiết kiệm khi dữ liệu thật sự ít được đọc — thường dưới một lần mỗi tháng.

S3 Intelligent-Tiering giải quyết đúng vấn đề đó: | Đặc điểm | Chi tiết | |---|---| | Tự theo dõi mẫu truy cập từng object | | | Tự chuyển tầng | Frequent → Infrequent → Archive Instant → Deep Archive | | KHÔNG có phí truy xuất | chỉ phí giám sát nhỏ theo object |

Với dữ liệu mà bạn không đoán được mẫu truy cập, Intelligent-Tiering thường là lựa chọn an toàn hơn cả Standard lẫn Standard-IA.

Standard-IA và One Zone-IA — khác biệt duy nhất: | | Standard-IA | One Zone-IA | |---|---|---| | Số AZ | ít nhất 3 | 1 | | Độ bền | 11 số 9 | 11 số 9 (trong AZ đó) | | Khả dụng | 99,9% | 99,5% | | Chi phí | | rẻ hơn ~20% |

One Zone-IA chỉ nên dùng cho dữ liệu tái tạo được — nếu AZ đó mất, dữ liệu mất luôn.

Và với báo cáo tài chính như đề mô tả, nhớ thêm một yếu tố tuân thủ: cân nhắc bật Object Lock để đảm bảo báo cáo không bị sửa hay xoá trong thời hạn lưu trữ bắt buộc — Object Lock hoạt động ở mọi lớp lưu trữ, kể cả Standard-IA.

Đáp án

C — Tạo bucket S3 Standard với S3 Object Lock ở chế độ COMPLIANCE, rồi cấu hình lifecycle rule chuyển tệp sang Amazon S3 Glacier Deep Archive sau 3 năm.

Vì sao đúng

Đề nêu bốn yêu cầu, và C đáp ứng cả bốn: | Yêu cầu | Cơ chế | |---|---| | Giữ được phiên bản cũ khi tệp bị sửa | Object Lock BẮT BUỘC bật versioning | | Dữ liệu ở trạng thái BẤT BIẾN ít nhất 3 năm | Object Lock chế độ COMPLIANCE | | Sau đó chuyển sang lưu trữ dài hạn | lifecycle rule → Glacier Deep Archive | | Truy cập một lần mỗi năm | Deep Archive phù hợp |

Từ khoá "immutable state" quyết định phải dùng Object Lock, không chỉ versioning:

Versioning một mình:
    → giữ được phiên bản cũ
    → NHƯNG người có quyền vẫn XOÁ VĨNH VIỄN được phiên bản
    → KHÔNG phải "bất biến"

Object Lock chế độ COMPLIANCE:
    → KHÔNG AI xoá hay sửa được trong thời hạn
    → kể cả root user, kể cả AWS
    → đúng nghĩa "immutable"

Và Object Lock tự động bao gồm versioning — nên yêu cầu thứ nhất được đáp ứng luôn:

aws s3api create-bucket --bucket ho-so-tuan-thu   --object-lock-enabled-for-bucket

aws s3api put-object-lock-configuration --bucket ho-so-tuan-thu   --object-lock-configuration '{
    "ObjectLockEnabled": "Enabled",
    "Rule": {"DefaultRetention": {"Mode": "COMPLIANCE", "Years": 3}}}'

Lifecycle rule cho giai đoạn sau:

{"Rules": [{
  "Status": "Enabled",
  "Transitions": [{"Days": 1095, "StorageClass": "DEEP_ARCHIVE"}]
}]}

Deep Archive khớp với "accessed once a year": truy xuất mất 12–48 giờ, nhưng chi phí lưu trữ chỉ khoảng 1 USD/TB/tháng.

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

• A. Bucket S3 Standard với object-level versioning và lifecycle chuyển sang Deep Archive sau 3 năm — đây là phương án gần nhất và đáp ứng ba trong bốn yêu cầu, nhưng nó thiếu tính bất biến: versioning giữ được phiên bản cũ, nhưng không ngăn được việc xoá vĩnh viễn. Đề nói rõ "immutable state".
• **B. Bucket S3 Standard và bật Object Lock ở chế độ GOVERNANCE — hai vấn đề: chế độ GOVERNANCE gỡ được bởi người có quyền s3:BypassGovernanceRetention — không đủ "bất biến"; và nó thiếu hoàn toàn vế chuyển sang lưu trữ dài hạn.
• D. Bucket One-Zone-IA với versioning và lifecycle chuyển sang Deep Archive — hai vấn đề: One Zone-IA chỉ lưu ở MỘT AZ — trái yêu cầu "highly available"; và vẫn thiếu tính bất biến.

Ghi nhớ

Hai chế độ của Object Lock — bảng phân biệt cốt lõi: | | GOVERNANCE | COMPLIANCE | |---|---|---| | Gỡ trước hạn | ✅ với s3:BypassGovernanceRetention | ❌ KHÔNG AI — kể cả root | | Rút ngắn thời hạn | ✅ | ❌ | | Kéo dài thời hạn | ✅ | ✅ | | Dùng khi | bảo vệ khỏi xoá nhầm | yêu cầu pháp lý nghiêm ngặt |

Từ khoá trong đề thi:

"immutable", "WORM", "cannot be deleted by anyone", "root user must be restricted" → COMPLIANCE "prevent accidental deletion" → GOVERNANCE hoặc versioning

Hai cơ chế khoá của Object Lock: | Cơ chế | Kết thúc khi | |---|---| | Retention period | tới ngày đã định ← câu này | | Legal hold | có người gỡ tường minh — VÔ THỜI HẠN |

Hai cơ chế độc lập và cộng dồn — object chỉ xoá được khi cả hai hết hiệu lực.

Ba điều kiện để dùng Object Lock:

① Versioning phải BẬT (Object Lock tự bật nó)
② Object Lock bật lúc TẠO bucket
③ Đặt retention cho từng object hoặc default cho bucket

Cảnh báo nghiêm túc về COMPLIANCE:

Đặt nhầm thời hạn → KHÔNG xoá được, KHÔNG rút ngắn được
                  → AWS Support cũng không gỡ hộ
                  → trả tiền lưu trữ đủ thời hạn đó

Luôn kiểm thử ở GOVERNANCE trước.

Object Lock hoạt động ở MỌI lớp lưu trữ — đây là chi tiết khiến phương án C khả thi: object bị khoá vẫn chuyển sang Deep Archive được, nên bạn giữ được tính bất biến mà vẫn giảm chi phí đáng kể.

Ba ứng dụng của Object Lock chế độ COMPLIANCE: | Ứng dụng | Chi tiết | |---|---| | Tuân thủ quy định | SEC 17a-4(f), FINRA, CFTC ← câu này | | Bảo vệ log kiểm toán | kẻ chiếm root cũng không xoá được dấu vết | | Chống ransomware | bản sao lưu không bị mã hoá hay xoá |

(Câu #8191 trong cùng lô này đặt gần như cùng một tình huống với cùng bộ phương án. Khác biệt duy nhất là ở cách diễn đạt yêu cầu — xem ghi chú ở câu đó.)

Và một lưu ý về chi phí Deep Archive: nó rẻ nhất về lưu trữ nhưng phí truy xuất và thời gian chờ 12–48 giờ là đáng kể. Với dữ liệu truy cập một lần mỗi năm như đề mô tả thì hợp lý; nhưng nếu tần suất tăng lên vài lần mỗi năm, Glacier Instant Retrieval thường là điểm cân bằng tốt hơn.

Đáp án

A và B.

• B — Gán một IAM role cho EC2 instance
• A — Bật Multi-Factor Authentication (MFA)

Vì sao đúng

Đề nêu hai nhóm chủ thể cần bảo vệ, và mỗi đáp án phục vụ một nhóm: | Chủ thể | Cơ chế | |---|---| | EC2 instance truy cập S3 và Redshift | B — IAM role | | Quản trị viên hệ thống triển khai và kiểm thử | A — MFA |

B — IAM role là cách duy nhất đúng để dịch vụ AWS truy cập dịch vụ AWS khác:

Instance profile gắn IAM role vào EC2
    ↓ ứng dụng gọi API AWS
SDK tự lấy thông tin đăng nhập TẠM THỜI từ IMDS
    ↓ tự làm mới trước khi hết hạn
    → KHÔNG có access key nào lưu trên máy

Ba lợi ích so với lưu access key: | Lợi ích | Chi tiết | |---|---| | Thông tin đăng nhập TẠM THỜI | tự xoay vòng, hết hạn sau vài giờ | | Không có bí mật trên đĩa | không có gì để rò rỉ | | Không phải xoay vòng thủ công | bỏ hẳn một quy trình vận hành |

A — MFA bảo vệ danh tính con người:

Mật khẩu bị lộ (lừa đảo, dùng lại, rò rỉ)
    → KHÔNG đủ để đăng nhập
    → còn cần mã từ thiết bị vật lý

Với quản trị viên có quyền triển khai vào môi trường sản xuất, MFA là biện pháp bảo vệ có tỷ lệ hiệu quả trên công sức cao nhất.

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

• **D. Gán một IAM user cho mỗi EC2 instance — đây là phương án gần nhất và về mặt kỹ thuật làm được, nhưng nó là thực hành sai: IAM user đi kèm access key dài hạn phải lưu trên máy — đúng thứ mà IAM role sinh ra để loại bỏ. Và nó không mở rộng được với Auto Scaling.
• **C. Lưu AWS Access Key trong EC2 instance — thực hành nguy hiểm nhất: khoá nằm trên đĩa, đi vào AMI, xuất hiện trong bản sao lưu, và ai có shell trên máy là lấy được.
• **E. Lưu AWS Access Key trong ACM — nhầm chức năng: ACM quản lý chứng chỉ TLS/SSL, không phải kho lưu bí mật. Nếu cần lưu bí mật thì dùng Secrets Manager hoặc SSM Parameter Store.

Ghi nhớ

Nguyên tắc quan trọng nhất về xác thực trên AWS:

Dịch vụ AWS gọi dịch vụ AWS khác thì dùng IAM ROLE, không dùng access key.

Chuỗi tìm kiếm thông tin đăng nhập của AWS SDK:

① Tham số trong mã
② Biến môi trường
③ ~/.aws/credentials
④ ~/.aws/config
⑤ Container credentials (ECS/EKS)
⑥ IMDS (IAM role của EC2)   ← ĐỨNG CUỐI

Hệ quả: nếu ai đó từng chạy aws configure trên instance, tệp credentials sẽ ghi đè IAM role — và triệu chứng là lời gọi API thực hiện dưới danh nghĩa một IAM user lạ.

Ba loại thiết bị MFA: | Loại | Đặc điểm | |---|---| | Ứng dụng ảo (TOTP) | Google Authenticator, Authy — phổ biến nhất | | Khoá bảo mật (FIDO2/WebAuthn) | YubiKey — chống lừa đảo tốt nhất | | Thiết bị phần cứng TOTP | token vật lý |

FIDO2 vượt trội cho tài khoản quan trọng: nó ràng buộc vào tên miền thật, nên trang lừa đảo không lấy được mã — điều mà TOTP không chống được.

Ba cách bắt buộc MFA bằng chính sách:

// Chặn mọi thao tác nếu không có MFA
{"Effect": "Deny", "NotAction": ["iam:ChangePassword", "sts:GetSessionToken"],
 "Resource": "*",
 "Condition": {"BoolIfExists": {"aws:MultiFactorAuthPresent": "false"}}}

Dùng BoolIfExists chứ không phải Bool — khoá này vắng mặt trong request bằng access key dài hạn, và Bool sẽ không khớp nên Deny không áp dụng.

Ba biện pháp bổ sung cho instance role: | Biện pháp | Lợi ích | |---|---| | Quyền tối thiểu, giới hạn Resource cụ thể | thiệt hại có hạn nếu bị lạm dụng | | Bắt buộc IMDSv2 | chống SSRF lấy thông tin đăng nhập | | Điều kiện aws:SourceVpce | token lấy được cũng không dùng từ ngoài VPC |

Dòng cuối là biện pháp mạnh mà ít người dùng: nó biến việc đánh cắp thông tin đăng nhập từ instance thành gần như vô dụng — kẻ tấn công phải ở trong VPC của bạn mới dùng được.

Và với quản trị viên, lựa chọn hiện đại hơn cả IAM user + MFA là IAM Identity Center: nó cấp thông tin đăng nhập tạm thời qua SSO, tích hợp MFA sẵn, và quản lý quyền cho nhiều tài khoản ở một chỗ — không còn IAM user dài hạn nào cả.

Đáp án

A — Khởi chạy một Amazon SQS queue và cấu hình ECS task thứ hai đọc từ đó. Tạo một IAM role mà ECS task assume để truy cập S3 bucket và SQS queue. Khai IAM Role trong trường taskRoleArn của task definition.

Vì sao đúng

Đề mô tả một kiến trúc xử lý bất đồng bộ chuẩn, và A hoàn thiện đúng hai mảnh còn thiếu: | Mảnh | Cơ chế | |---|---| | Hàng đợi giữa hai task | Amazon SQS | | Quyền cho task truy cập S3 và SQS | IAM task role qua taskRoleArn |

SQS là dịch vụ đúng cho mẫu producer–consumer mà đề mô tả:

Task 1: nhận request → lưu ảnh vào S3 input → GỬI thông điệp vào queue
                                                    ↓
Task 2: ĐỌC thông điệp → tải ảnh về → xử lý → ghi vào S3 output

Và taskRoleArn là trường ĐÚNG — đây là điểm kỹ thuật cần phân biệt:

taskRoleArn      → quyền mà CHÍNH ỨNG DỤNG trong container dùng
                   để gọi API AWS (S3, SQS, DynamoDB...)

executionRoleArn → quyền mà ECS AGENT dùng để KHỞI CHẠY task
                   (kéo image từ ECR, ghi log vào CloudWatch)

Nhầm hai trường này là lỗi phổ biến nhất khi cấu hình ECS: ứng dụng báo AccessDenied khi gọi S3 dù bạn đã cấp quyền — vì quyền được đặt nhầm vào execution role.

{
  "family": "xu-ly-anh",
  "taskRoleArn": "arn:aws:iam::111122223333:role/ecs-task-xu-ly-anh",
  "executionRoleArn": "arn:aws:iam::111122223333:role/ecsTaskExecutionRole",
  "containerDefinitions": [...]
}

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

• D. Khởi chạy một Amazon MQ queue; tạo IAM role; đặt tuỳ chọn EnableTaskIAMRole là true trong task definition — đây là phương án gần nhất về mặt cũng dùng một dịch vụ hàng đợi, nhưng nó sai ở hai điểm: Amazon MQ là message broker được quản lý cho ActiveMQ/RabbitMQ — nó dành cho việc di chuyển ứng dụng đã dùng các giao thức đó (JMS, AMQP), quá nặng cho nhu cầu đơn giản này. Và không có tuỳ chọn EnableTaskIAMRole trong task definition.
• C. Khởi chạy Amazon Data Firehose; ...; khai ARN của IAM Role trong trường taskDefinitionArn — sai cả dịch vụ lẫn trường: Firehose là đường ống giao dữ liệu luồng vào S3/Redshift/OpenSearch, không phải hàng đợi để consumer đọc. Và taskDefinitionArn là định danh của chính task definition, không phải nơi khai IAM role.
• B. Khởi chạy một Amazon AppStream 2.0 queue — AppStream 2.0 là dịch vụ phát ứng dụng desktop qua trình duyệt. Nó không có "queue" nào cả.

Ghi nhớ

Hai IAM role của ECS task — bảng phải thuộc: | Role | Ai dùng | Quyền điển hình | |---|---|---| | taskRoleArn | ỨNG DỤNG trong container | S3, SQS, DynamoDB, KMS | | executionRoleArn | ECS agent khi khởi chạy | ECR pull, CloudWatch Logs, Secrets Manager (lấy biến môi trường) |

Managed policy cho execution role: AmazonECSTaskExecutionRolePolicy.

Triệu chứng khi nhầm hai role: | Triệu chứng | Nguyên nhân | |---|---| | Task không khởi chạy được, lỗi kéo image | thiếu quyền ở execution role | | Task chạy nhưng ứng dụng báo AccessDenied | thiếu quyền ở task role |

Bốn dịch vụ nhắn tin của AWS — chọn đúng: | Dịch vụ | Mô hình | Dùng khi | |---|---|---| | Amazon SQS | hàng đợi, một consumer mỗi thông điệp | tách rời, xử lý bất đồng bộ ← câu này | | Amazon SNS | pub/sub, nhiều người nhận | phát tán tới nhiều đích | | Amazon MQ | broker ActiveMQ/RabbitMQ | di chuyển ứng dụng dùng JMS, AMQP, MQTT | | Kinesis Data Streams | luồng, phát lại được | phân tích thời gian thực, nhiều consumer |

Quy tắc chọn:

Ứng dụng mới trên AWS → SQS Di chuyển ứng dụng đã dùng chuẩn nhắn tin mở → Amazon MQ

Hai loại SQS queue: | Loại | Đặc điểm | |---|---| | Standard | thông lượng gần như không giới hạn, có thể trùng và lệch thứ tự | | FIFO | đúng thứ tự, xử lý chính xác một lần, giới hạn thông lượng |

Với xử lý ảnh, Standard queue là đủ — nhưng consumer nên được viết idempotent (xử lý cùng thông điệp hai lần cho cùng kết quả).

Ba cấu hình quan trọng của SQS: | Cấu hình | Việc | |---|---| | VisibilityTimeout | thời gian thông điệp bị ẩn khi đang xử lý — đặt DÀI HƠN thời gian xử lý | | Dead-letter queue | thông điệp lỗi sau N lần thử chuyển sang đây | | Long polling (ReceiveMessageWaitTimeSeconds) | giảm số lời gọi API rỗng và chi phí |

Dòng đầu là lỗi hay gặp: nếu xử lý ảnh mất 5 phút mà visibility timeout là 30 giây, thông điệp sẽ xuất hiện lại và bị xử lý nhiều lần — sinh ra ảnh trùng lặp trong bucket output.

Và một cải thiện đáng cân nhắc cho kiến trúc này: mở rộng ECS service theo độ sâu hàng đợi bằng target tracking trên metric ApproximateNumberOfMessagesVisible chia cho số task — nó khớp dung lượng xử lý với khối lượng công việc thực tế, thay vì mở rộng theo CPU vốn là chỉ báo gián tiếp.

Đáp án

A — Tạo một elastic network interface (ENI) phụ và trỏ địa chỉ IPv4 riêng của nó tới tên miền của ứng dụng. Gắn ENI mới vào instance chính. Nếu instance ngừng hoạt động, chuyển ENI phụ sang instance khác.

Vì sao đúng

Đề mô tả một ràng buộc cụ thể: tên miền trỏ tới địa chỉ IPv4 RIÊNG của network interface, và instance là Spot nên có thể bị thu hồi bất cứ lúc nào.

ENI là tài nguyên ĐỘC LẬP với instance — đó là chìa khoá:

ENI mang theo:
    ├─ địa chỉ IPv4 riêng (cố định)
    ├─ địa chỉ MAC
    ├─ security group
    └─ địa chỉ IP phụ

Instance bị chấm dứt
    ↓ ENI phụ VẪN TỒN TẠI (nếu DeleteOnTermination = false)
    ↓ gắn sang instance khác
Địa chỉ IP riêng ĐI THEO
    → tên miền vẫn trỏ đúng, KHÔNG cần đổi DNS

Đây là mẫu "floating IP" quen thuộc trong hạ tầng truyền thống, và ENI là cách AWS thực hiện nó.

Vì sao dùng ENI PHỤ chứ không phải ENI chính: | ENI | Đặc điểm | |---|---| | Primary (eth0) | KHÔNG tháo rời được khỏi instance | | Secondary | tháo và gắn sang máy khác tự do |

Nên phải tạo một ENI phụ ngay từ đầu và trỏ DNS vào IP của nó — không thể chuyển ENI chính.

aws ec2 create-network-interface --subnet-id subnet-0abc   --private-ip-address 10.0.1.100 --groups sg-0abc

aws ec2 attach-network-interface --network-interface-id eni-0abc   --instance-id i-0new --device-index 1

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

• B. Gắn Elastic IP vào ENI chính và trỏ IP đó tới tên miền; tự động chuyển EIP sang instance phụ bằng AWS Transit Gateway — đây là phương án gần nhất và EIP thật sự chuyển được giữa các instance, nhưng nó sai ở hai điểm: đề nói tên miền trỏ tới IP RIÊNG, còn EIP là IP CÔNG KHAI — và instance nằm trong private subnet; và Transit Gateway không di chuyển EIP — nó là hub kết nối mạng.
• C. Dùng AWS Network Firewall để tháo ENI chính của instance và chuyển sang instance mới khi có sự cố — nhầm chức năng: Network Firewall lọc lưu lượng mạng, nó không quản lý ENI. Và ENI chính không tháo rời được.
• D. Thiết lập AWS Transfer for FTPS ở chế độ Implicit FTPS để tự động tắt source/destination check và gắn lại ENI sang instance khác — hoàn toàn không liên quan: AWS Transfer Family là dịch vụ truyền tệp. Nó không tương tác gì với ENI.

Ghi nhớ

Ba loại ENI của một EC2 instance: | Loại | Đặc điểm | |---|---| | Primary (eth0) | tạo cùng instance, KHÔNG tháo được | | Secondary | tạo riêng, tháo và gắn tự do | | Trunk | cho ECS awsvpc trunking |

Những gì ENI mang theo khi chuyển:

✓ Địa chỉ IPv4 riêng chính và phụ
✓ Địa chỉ IPv6
✓ Elastic IP (nếu có gắn)
✓ Địa chỉ MAC
✓ Security group
✓ Source/destination check

Địa chỉ MAC đi theo là chi tiết hữu ích: một số phần mềm có giấy phép gắn với MAC address, và ENI giữ được nó khi chuyển máy.

Ba trường hợp dùng ENI phụ: | Trường hợp | Chi tiết | |---|---| | IP dự phòng chuyển máy được | ← câu này | | Thiết bị mạng quản lý riêng | tách mạng quản trị khỏi mạng dữ liệu | | Ứng dụng đa mạng | instance nằm trong nhiều subnet |

Ràng buộc quan trọng: ENI chỉ gắn được vào instance trong CÙNG Availability Zone — vì subnet gắn với một AZ. Nên instance dự phòng phải nằm cùng AZ với instance chính.

Ba cách đạt tính sẵn sàng cao cho EC2 — theo mức độ: | Cách | Đặc điểm | |---|---| | Chuyển ENI thủ công hoặc bằng script | đơn giản, nhanh, cùng AZ ← câu này | | Auto Scaling group với ELB | tự động, đa AZ — mạnh nhất | | Route 53 health check + failover | đa Region |

Dòng giữa thường là câu trả lời đúng cho ứng dụng web thật — nhưng đề ràng buộc rằng tên miền trỏ tới IP riêng của ENI, nên giải pháp phải giữ được chính IP đó.

Ba lưu ý về Spot Instance liên quan tới tình huống này: | Lưu ý | Chi tiết | |---|---| | Có cảnh báo 2 phút trước khi thu hồi | qua IMDS hoặc EventBridge | | Nên tự động hoá việc chuyển ENI | Lambda nghe sự kiện EC2 Spot Instance Interruption Warning | | Dùng Spot cho workload chịu được gián đoạn | dashboard nội bộ là phù hợp |

Dòng giữa biến giải pháp thủ công thành tự động:

{"source": ["aws.ec2"],
 "detail-type": ["EC2 Spot Instance Interruption Warning"]}

→ Lambda tháo ENI và gắn sang instance dự phòng trong vòng hai phút cảnh báo.

Và một lưu ý về DeleteOnTermination: với ENI phụ, mặc định là false — nên nó sống sót khi instance bị chấm dứt. Nhưng hãy kiểm tra lại giá trị này, vì nếu vô tình đặt true thì ENI sẽ biến mất cùng instance và toàn bộ thiết kế sụp đổ.

Đáp án

A — Thiết lập failover routing policy trong Route 53 bằng cách thêm health check trên endpoint dịch vụ chính. Cấu hình Route 53 chuyển truy vấn DNS sang bản ghi phụ khi tài nguyên chính không lành mạnh. Cấu hình NACL và route table cho phép Route 53 gửi request tới các endpoint trong health check. Bật Evaluate Target Health.

Vì sao đúng

Đề nêu yêu cầu chính xác: chỉ chuyển lưu lượng sang môi trường khôi phục thảm hoạ KHI môi trường chính gặp sự cố — và đó là định nghĩa của failover routing policy.

Cách hoạt động:

Route 53 hosted zone:
    Bản ghi PRIMARY   → endpoint ở Region chính  + health check
    Bản ghi SECONDARY → endpoint ở Region DR

Health check thất bại N lần liên tiếp
    ↓ Route 53 ngừng trả về bản ghi primary
    ↓ trả về bản ghi secondary
Người dùng được định tuyến sang môi trường DR

aws route53 change-resource-record-sets --hosted-zone-id Z123   --change-batch '{"Changes": [{
    "Action": "CREATE",
    "ResourceRecordSet": {
      "Name": "ung-dung.congty.vn", "Type": "A",
      "SetIdentifier": "chinh", "Failover": "PRIMARY",
      "HealthCheckId": "hc-abc123",
      "AliasTarget": {"DNSName": "alb-chinh...", "EvaluateTargetHealth": true, ...}
    }}]}'

Và EvaluateTargetHealth là chi tiết quan trọng: với alias record trỏ tới ALB hoặc CloudFront, bật cờ này khiến Route 53 tự động kiểm tra sức khoẻ của chính target — không cần health check riêng cho mọi trường hợp.

Vì sao failover chứ không phải weighted (phương án C):

Failover routing:  primary nhận 100% lưu lượng khi khoẻ
                   → DR chỉ nhận khi primary CHẾT     ← đúng yêu cầu

Weighted routing:  chia lưu lượng theo tỷ lệ
                   → DR LUÔN nhận một phần lưu lượng   ← sai yêu cầu

Đề nói rõ "route the live traffic to the DR environment ONLY IN THE EVENT that the primary experiences an outage".

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

• C. Thiết lập Weighted routing policy với health check trên cả hai môi trường; bật Evaluate Target Health — đây là phương án gần nhất và có nhiều chi tiết đúng, nhưng weighted routing chia lưu lượng liên tục cho cả hai. Nó dùng cho A/B testing hoặc triển khai dần, không phải cho khôi phục thảm hoạ.
• B. Thiết lập CloudWatch Events rule giám sát endpoint DNS chính và tạo Lambda gọi ChangeResourceRecordSets — tự viết lại tính năng đã có sẵn: Route 53 failover làm chính việc này mà không cần mã. Và EventBridge không giám sát được endpoint DNS — nó phản ứng với sự kiện, không chủ động kiểm tra sức khoẻ.
• D. Thiết lập CloudWatch Alarm giám sát endpoint DNS chính và Lambda gọi ChangeResourceRecordSets — cùng vấn đề: thêm mã và thêm chỗ hỏng cho việc mà Route 53 đã làm sẵn, tin cậy hơn và nhanh hơn.

Ghi nhớ

Các chính sách định tuyến của Route 53 — bảng cần thuộc: | Chính sách | Định tuyến theo | |---|---| | Simple | một bản ghi, không điều kiện | | Failover | primary khi khoẻ, secondary khi hỏng ← câu này | | Weighted | tỷ lệ phần trăm — A/B testing, triển khai dần | | Latency | Region cho độ trễ thấp nhất | | Geolocation | vị trí địa lý của người dùng | | Geoproximity | khoảng cách địa lý, có bias | | Multivalue answer | trả nhiều IP, có health check | | IP-based | theo dải IP của client |

Câu hỏi phân biệt:

"chỉ khi primary hỏng", "disaster recovery" → Failover "chia tỷ lệ", "canary", "A/B" → Weighted "độ trễ thấp nhất" → Latency "tuân thủ theo quốc gia" → Geolocation

Ba loại health check của Route 53: | Loại | Kiểm tra | |---|---| | Endpoint | gọi HTTP/HTTPS/TCP tới một địa chỉ | | Calculated | kết hợp kết quả của nhiều health check khác | | CloudWatch alarm | theo trạng thái của một alarm — dùng cho endpoint riêng tư |

Loại thứ ba giải quyết một hạn chế quan trọng: Route 53 health check đến từ Internet công cộng, nên nó không kiểm tra được endpoint trong private subnet. Với tài nguyên riêng tư, dùng CloudWatch alarm làm nguồn.

Ba đặc điểm của health check: | Đặc điểm | Chi tiết | |---|---| | Kiểm tra từ nhiều vị trí toàn cầu | tránh báo động giả do sự cố mạng cục bộ | | Ngưỡng mặc định 3 lần liên tiếp | | | Chu kỳ 30 giây (hoặc 10 giây fast) | thời gian phát hiện ~90 giây |

Bốn chiến lược khôi phục thảm hoạ — đề mô tả mức thứ ba: | Chiến lược | RTO | Chi phí | |---|---|---| | Backup & Restore | giờ | thấp nhất | | Pilot Light | chục phút | thấp | | Warm Standby | phút | vừa ← đề này | | Multi-Site Active/Active | gần 0 | cao nhất |

Warm standby nghĩa là môi trường DR đang chạy ở quy mô nhỏ — nên Route 53 chuyển sang được ngay, và bạn mở rộng nó sau khi đã nhận lưu lượng.

Và một lưu ý về TTL: đặt TTL thấp (60 giây hoặc ít hơn) cho bản ghi failover. TTL cao nghĩa là trình phân giải DNS của người dùng vẫn cache địa chỉ cũ sau khi Route 53 đã chuyển — kéo dài thời gian gián đoạn thực tế vượt xa RTO bạn tính toán.

Đáp án

A — Tạo một IAM role và gán nó cho EC2 instance.

Vì sao đúng

Đề hỏi cách tốt nhất để EC2 instance truy cập S3 và các dịch vụ AWS khác — và IAM role là câu trả lời duy nhất đúng.

Cách hoạt động:

IAM role gắn vào instance qua INSTANCE PROFILE
    ↓ ứng dụng gọi API AWS
AWS SDK tự lấy thông tin đăng nhập TẠM THỜI từ IMDS
    (http://169.254.169.254/latest/meta-data/iam/security-credentials/)
    ↓ SDK tự làm mới trước khi hết hạn
    → KHÔNG có access key nào được lưu ở đâu cả

Ba lợi ích so với mọi cách khác: | Lợi ích | Chi tiết | |---|---| | Thông tin đăng nhập TẠM THỜI | hết hạn sau vài giờ, tự xoay vòng | | Không có bí mật trên đĩa | không có gì để rò rỉ hay đánh cắp | | Sửa quyền không cần đụng tới instance | sửa policy là có hiệu lực ngay |

Dòng cuối là lợi ích vận hành lớn: cần thêm quyền cho ứng dụng thì sửa IAM policy — không phải đăng nhập vào từng máy để cập nhật khoá.

Và nó mở rộng tự nhiên với Auto Scaling: mọi instance mới khởi chạy từ launch template đều tự có role, không cần cấu hình gì thêm.

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

• **B. Lưu API credentials trong EC2 instance — đây là phương án gần nhất về mặt cũng cấp được quyền, nhưng nó là thực hành nguy hiểm nhất: khoá nằm trên đĩa, đi vào AMI khi bạn tạo image, xuất hiện trong bản sao lưu, và ai có shell trên máy là lấy được. Đây là nguyên nhân số một của các sự cố rò rỉ thông tin đăng nhập AWS.
• **D. Lưu API credentials trong một bastion host — không giải quyết vấn đề: instance ứng dụng vẫn cần thông tin đăng nhập để gọi S3. Đặt chúng ở một máy khác chỉ thêm một bước và một điểm hỏng.
• **C. Thêm API credentials vào Security Group và gán cho instance — nhầm khái niệm cơ bản: security group là tường lửa ảo lọc lưu lượng mạng theo IP, cổng và giao thức. Nó không lưu trữ dữ liệu và không liên quan gì tới xác thực.

Ghi nhớ

Nguyên tắc nền tảng nhất về xác thực trên AWS:

Dịch vụ AWS gọi dịch vụ AWS khác thì dùng IAM ROLE, không bao giờ dùng access key.

Chuỗi tìm kiếm thông tin đăng nhập của AWS SDK:

① Tham số truyền trực tiếp trong mã
② Biến môi trường
③ ~/.aws/credentials
④ ~/.aws/config
⑤ Container credentials
⑥ IMDS — IAM role của EC2      ← ĐỨNG CUỐI

Hệ quả thực tế quan trọng: nếu ai đó từng chạy aws configure trên máy, tệp ~/.aws/credentials ghi đè IAM role. Triệu chứng là lời gọi API thực hiện dưới danh nghĩa một IAM user lạ:

aws sts get-caller-identity
# Mong đợi: "Arn": "arn:aws:sts::...:assumed-role/role-ung-dung/i-0abc"
# Nếu thấy: "Arn": "arn:aws:iam::...:user/ai-do"  → có tệp credentials cần xoá

Ba biện pháp siết chặt cho instance role: | Biện pháp | Lợi ích | |---|---| | Quyền tối thiểu, Resource cụ thể | đừng dùng s3:* và Resource: "*" | | Bắt buộc IMDSv2 | chống SSRF lấy thông tin đăng nhập | | Điều kiện aws:SourceVpce | token bị đánh cắp không dùng được từ ngoài VPC |

IMDSv2 đáng bật cho mọi instance:

aws ec2 modify-instance-metadata-options --instance-id i-0abc   --http-tokens required --http-put-response-hop-limit 1

Nó yêu cầu một token PUT trước khi đọc metadata — chặn được kiểu tấn công SSRF nơi kẻ tấn công lừa ứng dụng web gọi tới địa chỉ metadata.

hop-limit = 1 là cấu hình quan trọng cho container: nó ngăn container thoát ra lấy thông tin đăng nhập của host.

Ba loại role liên quan tới EC2: | Loại | Việc | |---|---| | Instance profile role | quyền instance dùng để gọi API AWS | | Service-linked role | dịch vụ AWS thao tác thay bạn | | Cross-account role | truy cập tài nguyên ở tài khoản khác |

Và một lưu ý về việc gắn role: thay đổi instance profile có hiệu lực trong vài phút mà không cần khởi động lại instance. Nhưng SDK có thể còn cache thông tin đăng nhập cũ tới khi chúng hết hạn — nên nếu cần hiệu lực tức thì, hãy khởi động lại tiến trình ứng dụng.

Đáp án

A — Dùng Amazon GuardDuty để giám sát hoạt động độc hại trên S3.

Vì sao đúng

Đề nêu hai yêu cầu, và GuardDuty đáp ứng cả hai: | Yêu cầu | Cơ chế | |---|---| | Cấu hình truy cập dữ liệu đúng chuẩn tuân thủ | GuardDuty phát hiện cấu hình bị lạm dụng | | Cảnh báo khi có rủi ro truy cập trái phép hoặc mẫu truy cập đáng ngờ | GuardDuty S3 Protection |

Cụm "suspicious access patterns" là điểm quyết định — nó đòi PHÂN TÍCH HÀNH VI, không chỉ ghi log:

CloudTrail:   GHI LẠI mọi lời gọi API
              → "IP 203.0.113.45 đã gọi GetObject lúc 3h sáng"
              → dữ liệu thô, không có kết luận

GuardDuty:    PHÂN TÍCH và ĐÁNH GIÁ
              → "IP này chưa từng truy cập bucket này trong 45 ngày qua"
              → "IP này nằm trong danh sách đe doạ đã biết"
              → "Đây là mẫu truy cập bất thường"  ← sinh FINDING

GuardDuty S3 Protection phát hiện được: | Loại phát hiện | Ví dụ | |---|---| | Truy cập từ IP độc hại đã biết | UnauthorizedAccess:S3/MaliciousIPCaller | | Truy cập từ Tor | UnauthorizedAccess:S3/TorIPCaller | | Hành vi API bất thường | Discovery:S3/AnomalousBehavior | | Thông tin đăng nhập bị lạm dụng | UnauthorizedAccess:S3/MaliciousIPCaller.Custom | | Chính sách bị nới lỏng đáng ngờ | Policy:S3/BucketBlockPublicAccessDisabled |

Dòng cuối trả lời trực tiếp vế "configuration for data access is in line with compliance standards" — GuardDuty cảnh báo khi ai đó tắt Block Public Access hoặc nới lỏng bucket policy.

Và GuardDuty tự động tích hợp với EventBridge và Security Hub, nên việc gửi cảnh báo chỉ là thêm một rule:

{"source": ["aws.guardduty"],
 "detail-type": ["GuardDuty Finding"],
 "detail": {"severity": [{"numeric": [">=", 7]}]}}

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

• B. Dùng AWS CloudTrail để giám sát và phát hiện mẫu truy cập trên S3 — đây là phương án gần nhất và CloudTrail là NGUỒN DỮ LIỆU thiết yếu, nhưng nó chỉ GHI LẠI, không PHÁT HIỆN: nó không tự phân tích hành vi, không so với đường cơ sở, và không sinh cảnh báo nào. (GuardDuty thực ra dùng chính CloudTrail làm một trong các nguồn của nó.)
• D. Dùng Amazon Inspector để cảnh báo khi phát hiện vi phạm bảo mật trên S3 — sai phạm vi: Inspector quét lỗ hổng phần mềm (CVE) trên EC2, ECR và Lambda. Nó không giám sát S3 chút nào.
• C. Dùng Amazon Rekognition để giám sát và nhận diện mẫu trên S3 — nhầm nghĩa của từ "nhận diện mẫu": Rekognition là dịch vụ thị giác máy tính — nhận diện khuôn mặt, vật thể và nội dung trong ảnh và video. Nó không liên quan tới bảo mật truy cập.

Ghi nhớ

Bốn dịch vụ bảo mật của AWS — bảng phân biệt cốt lõi: | Dịch vụ | Phát hiện | Nguồn dữ liệu | |---|---|---| | GuardDuty | MỐI ĐE DOẠ đang diễn ra | Flow Logs, DNS, CloudTrail, S3 data event | | Macie | DỮ LIỆU NHẠY CẢM | nội dung object S3 | | Inspector | LỖ HỔNG phần mềm | EC2, ECR, Lambda | | Security Hub | tổng hợp và chấm điểm chuẩn | finding từ ba cái trên |

Câu hỏi phân biệt:

"suspicious access", "malicious activity", "threat detection" → GuardDuty "sensitive data", "PII", "credit card in S3" → Macie "vulnerabilities", "CVE", "patch" → Inspector "ai đã làm gì" (chỉ ghi log) → CloudTrail

Ba nguồn dữ liệu nền tảng của GuardDuty: | Nguồn | Phát hiện | Bạn phải bật? | |---|---|---| | VPC Flow Logs | hoạt động mạng bất thường | ❌ GuardDuty đọc trực tiếp | | DNS logs | domain độc hại, DNS tunneling | ❌ | | CloudTrail | hoạt động API bất thường | ❌ |

Cột cuối đáng nhớ: GuardDuty không đòi bạn bật ba nguồn này — nó truy cập qua hạ tầng nội bộ của AWS. Bạn không tốn phí CloudTrail hay Flow Logs vì GuardDuty.

Các tính năng bảo vệ mở rộng — phải bật riêng, có tính phí: | Tính năng | Bảo vệ | |---|---| | S3 Protection | data event của S3 ← câu này | | Malware Protection | quét mã độc trên EBS | | EKS/ECS Runtime Monitoring | hành vi bất thường trong container | | RDS Protection | đăng nhập bất thường vào Aurora | | Lambda Protection | hoạt động mạng của Lambda |

S3 Protection cần bật tường minh — nó không nằm trong cấu hình mặc định của GuardDuty.

Ba lớp bảo vệ nên có cho bucket chứa dữ liệu nhạy cảm: | Lớp | Vai trò | |---|---| | Ngăn chặn | Block Public Access, bucket policy chặt, mã hoá | | Phát hiện | GuardDuty (mối đe doạ) + Macie (dữ liệu nhạy cảm) | | Kiểm toán | CloudTrail data event |

Ba lớp này bổ sung nhau, không thay thế nhau — và đề chỉ hỏi về lớp giữa.

Và một lưu ý về triển khai đa tài khoản: GuardDuty hỗ trợ delegated administrator trong AWS Organizations, cho phép một tài khoản bảo mật thấy finding của mọi tài khoản thành viên — và tài khoản mới gia nhập tự động được bảo vệ. Nhớ rằng GuardDuty là dịch vụ khu vực, nên phải bật ở mọi Region đang dùng.