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

Đáp án

B — Cấu hình ASG co giãn theo NHU CẦU (dynamic scaling / scale based on demand).

Vì sao đúng

Đề nêu một điều kiện rất cụ thể: hành động co giãn phải bắt đầu NGAY KHI CPU vượt 50% — tức là phản ứng theo chỉ số thực tế, không theo lịch và không theo dự đoán.

⚠ Điểm mấu chốt — bốn kiểu co giãn và cái gì kích hoạt chúng:

Dynamic scaling (theo nhu cầu)      ← đáp án
        ↓
    CloudWatch alarm trên một CHỈ SỐ vượt ngưỡng
        ↓
    → phản ứng với tải THỰC TẾ đang diễn ra

Scheduled scaling
        ↓
    Theo LỊCH đã định trước (cron)
        ↓
    → cho mẫu tải BIẾT TRƯỚC

Predictive scaling
        ↓
    Học máy DỰ ĐOÁN tải rồi co giãn TRƯỚC
        ↓
    → cần lịch sử ít nhất 24 giờ, tốt nhất 14 ngày

Manual scaling
        ↓
    Tự tay đổi desired capacity

⚠ Và trong dynamic scaling còn ba kiểu chính sách:

Target Tracking          ← đơn giản nhất, nên ưu tiên
        ↓
    "Giữ CPUUtilization trung bình quanh 50%"
    → ASG tự tính cần thêm bớt bao nhiêu máy

Step Scaling
        ↓
    "Vượt 50% thêm 1 máy, vượt 70% thêm 3 máy"
    → kiểm soát chi tiết hơn theo từng bậc

Simple Scaling
        ↓
    Một hành động rồi chờ cooldown — cách CŨ

Với yêu cầu của đề, Target Tracking với ASGAverageCPUUtilization mục tiêu 50% là cấu hình gọn nhất.

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

• D (predictive scaling) — đây là phương án gần nhất và là một tính năng rất mạnh, nhưng nó co giãn TRƯỚC dựa trên dự đoán, không phải khi CPU vượt ngưỡng. Nó cũng cần lịch sử dữ liệu để học. (Trong thực tế, kết hợp predictive với dynamic là cấu hình tốt nhất — predictive lo phần nền, dynamic lo phần bất ngờ.)

• A (co giãn theo lịch) — chỉ hợp với mẫu tải biết trước: giờ hành chính, ngày khuyến mãi. Nó không nhìn tới CPU chút nào.

• C (co giãn theo sự kiện) — không phải một kiểu co giãn chính thức của ASG. Có thể dựng bằng EventBridge gọi API, nhưng đó là tự chế, và ngưỡng CPU thì đã có dynamic scaling lo.

Ghi nhớ

⚠ Bốn kiểu co giãn của Auto Scaling — bảng phải thuộc: | Kiểu | Kích hoạt bởi | |---|---| | Dynamic (theo nhu cầu) | CloudWatch alarm trên chỉ số | | Scheduled | thời điểm định trước | | Predictive | dự đoán bằng học máy | | Manual | người tự đổi desired capacity |

Từ khoá nhận diện:

"khi CPU vượt X%" → dynamic scaling "mỗi ngày 8 giờ sáng tăng lên" → scheduled scaling "tải theo chu kỳ, muốn co giãn trước" → predictive scaling "giữ một chỉ số quanh giá trị mục tiêu" → Target Tracking "thêm N máy theo từng bậc ngưỡng" → Step Scaling

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chính sách nào đang áp | describe-policies --auto-scaling-group-name <ten> | | Có co giãn dao động không | Activity history — scale out rồi scale in liên tục | | Alarm có kích hoạt không | describe-alarm-history |

Và một lời khuyên khi chọn chính sách: hãy bắt đầu bằng Target Tracking, và chỉ chuyển sang Step Scaling khi bạn thật sự cần kiểm soát theo bậc. Target Tracking tự tính toán số máy cần thêm bớt, tự tạo và quản lý các CloudWatch alarm bên dưới, và tự tránh dao động — ba việc mà nếu tự làm bằng Step Scaling thì bạn phải tinh chỉnh rất lâu mới đạt được kết quả tương đương.

Đáp án

C — Bạn được lấy MIỄN PHÍ 10 GB dữ liệu từ Amazon S3 Glacier mỗi tháng.

Vì sao đúng

Glacier có một hạn mức lấy dữ liệu miễn phí hằng tháng, và vượt qua nó là bắt đầu tính tiền.

⚠ Điểm mấu chốt — hạn mức miễn phí 10 GB mỗi tháng:

Các tháng trước: lấy dưới 10 GB
        ↓
    → không phát sinh phí lấy dữ liệu
    → đội vận hành tưởng việc lấy dữ liệu luôn miễn phí

Tháng này: lấy vượt 10 GB
        ↓
    → phần vượt bị tính tiền
    → xuất hiện khoản "retrieval charges" trên hoá đơn
        ↓
    → đúng như tình huống của đề

⚠ Và chi phí lấy dữ liệu phụ thuộc rất nhiều vào tốc độ bạn chọn:

Với Deep Archive thì chỉ có Standard (12 giờ) và Bulk (48 giờ).

⚠ Hai bẫy chi phí khác của lớp lưu trữ archive — đáng nhớ cùng lúc:

Thời gian lưu tối thiểu
        ↓
    Glacier Flexible Retrieval : 90 ngày
    Glacier Deep Archive       : 180 ngày
        ↓
    → xoá sớm hơn vẫn bị tính tiền cho đủ thời gian đó

Phí theo SỐ ĐỐI TƯỢNG
        ↓
    → hàng triệu tệp nhỏ tốn hơn nhiều so với vài tệp lớn
    → nên GOM tệp nhỏ lại trước khi archive

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

• D (miễn phí 5 GB mỗi tháng) — đây là phương án gần nhất và chỉ sai ở con số. Con số 5 GB là hạn mức miễn phí của S3 Standard trong gói Free Tier, không phải của Glacier retrieval.

• B (miễn phí lấy dữ liệu trong ba tháng đầu) — bịa; hạn mức miễn phí của Glacier là hằng tháng, không có ưu đãi theo giai đoạn.

• A (tài khoản thuộc nhiều AWS Organization) — không thể: một tài khoản AWS chỉ thuộc đúng MỘT tổ chức tại một thời điểm.

Ghi nhớ

⚠ Ba lớp Glacier — bảng phải thuộc: | Lớp | Thời gian lấy | Lưu tối thiểu | |---|---|---| | Glacier Instant Retrieval | mili giây | 90 ngày | | Glacier Flexible Retrieval | phút tới 5–12 giờ | 90 ngày | | Glacier Deep Archive | 12–48 giờ | 180 ngày |

Từ khoá nhận diện:

"phí lấy dữ liệu Glacier bất ngờ" → vượt hạn mức 10 GB/tháng "cần lấy ngay lập tức" → Glacier Instant Retrieval "rẻ nhất, chấp nhận chờ" → Deep Archive + Bulk retrieval "xoá sớm vẫn bị tính tiền" → thời gian lưu tối thiểu "không đoán được mẫu truy cập" → S3 Intelligent-Tiering

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã lấy bao nhiêu GB tháng này | Cost Explorer, lọc theo usage type Retrieval | | Dữ liệu đang ở lớp nào | head-object, xem StorageClass | | Có bao nhiêu đối tượng | S3 Storage Lens hoặc S3 Inventory |

Và một lời khuyên trước khi chuyển khối dữ liệu lớn xuống Glacier: hãy ước tính chi phí LẤY LẠI, không chỉ chi phí lưu trữ. Glacier rẻ tới mức khó tin khi cất, nhưng nếu một ngày nào đó bạn cần lấy toàn bộ ra — vì kiểm toán, vì di chuyển hệ thống, vì khôi phục thảm hoạ — thì hoá đơn của tháng đó có thể lớn hơn cả năm tiền lưu trữ cộng lại.

Đáp án

D — AWS CloudHSM.

Vì sao đúng

Cụm từ quyết định trong đề là "module mã hoá TỰ QUẢN, cô lập" — và đó chính là định nghĩa của CloudHSM.

⚠ Điểm mấu chốt — CloudHSM cho bạn thiết bị phần cứng riêng, AWS không truy cập được:

CloudHSM
        ↓
    Thiết bị HSM VẬT LÝ dành riêng cho bạn
        ↓
    → BẠN quản lý người dùng và khoá bên trong
    → AWS KHÔNG có quyền truy cập vào khoá
    → AWS chỉ lo phần cứng, mạng, sao lưu thiết bị
        ↓
    Đạt chuẩn FIPS 140-2 Level 3
        ↓
    → yêu cầu tuân thủ của ngành ngân hàng thường đòi mức này

⚠ So sánh với KMS — khác biệt nằm ở AI KIỂM SOÁT:

KMS (multi-tenant)
        ↓
    AWS vận hành, HSM DÙNG CHUNG giữa các khách hàng
    (khoá vẫn cô lập về mặt logic)
        ↓
    → AWS quản lý vòng đời phần cứng
    → chuẩn FIPS 140-2 Level 3 cho phần HSM
    → bạn kiểm soát qua key policy, KHÔNG chạm vào HSM

CloudHSM (single-tenant)
        ↓
    Cụm HSM RIÊNG của bạn trong VPC của bạn
        ↓
    → bạn tự tạo user, tự quản khoá, tự sao lưu logic
    → AWS KHÔNG BAO GIỜ thấy khoá của bạn

⚠ Và những việc chỉ CloudHSM làm được:

Tự quản lý người dùng HSM và quyền của họ
Dùng thư viện chuẩn: PKCS#11, JCE, CNG/KSP
Tự sinh và giữ khoá bất đối xứng cho ký số
Làm HSM cho Certificate Authority riêng
Bảo vệ khoá riêng SSL cho web server
Thực hiện các thao tác mật mã mà KMS không hỗ trợ

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

• C (KMS) — đây là phương án gần nhất và là dịch vụ quản lý khoá chính của AWS. Nhưng KMS dùng HSM chia sẻ do AWS vận hành; bạn không "tự quản" module nào. Với yêu cầu tuân thủ đòi module cô lập tự quản như trong đề, KMS chưa đủ. (Có KMS Custom Key Store dùng CloudHSM làm nền — nhưng khi đó bạn vẫn phải có CloudHSM.)

• A (S3 SSE) — chỉ là cách mã hoá dữ liệu trong S3, không phải một hệ thống quản lý khoá cho toàn tổ chức, và không có module phần cứng nào để bạn quản.

• B (GuardDuty) — dịch vụ phát hiện mối đe doạ. Không liên quan gì tới quản lý khoá.

Ghi nhớ

⚠ KMS và CloudHSM — bảng phải thuộc: | | AWS KMS | AWS CloudHSM | |---|---|---| | Mô hình | multi-tenant, AWS vận hành | single-tenant, cụm riêng của bạn | | AWS thấy khoá không | không (khoá không rời HSM) | KHÔNG, và AWS cũng không quản user | | Ai quản người dùng | IAM | bạn tự quản trong HSM | | Chuẩn | FIPS 140-2 Level 3 | FIPS 140-2 Level 3 | | Tích hợp dịch vụ AWS | rất sâu và rộng | hạn chế (qua custom key store) | | Chi phí | theo khoá + theo lời gọi | theo GIỜ mỗi HSM — đắt hơn nhiều | | Vận hành | AWS lo hết | bạn lo cụm, user, sao lưu logic |

Từ khoá nhận diện:

"module mã hoá tự quản, cô lập" → CloudHSM "FIPS 140-2 Level 3 với thiết bị riêng" → CloudHSM "quản lý khoá đơn giản, tích hợp sâu với AWS" → KMS "khoá nằm trong HSM của tôi nhưng vẫn dùng KMS" → KMS Custom Key Store "khoá nằm ở hệ thống NGOÀI AWS" → KMS External Key Store (XKS)

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cụm HSM có khoẻ không | describe-clusters, trạng thái ACTIVE | | Có đủ HSM cho sẵn sàng cao không | ít nhất 2, ở 2 AZ | | Ứng dụng kết nối được không | dùng công cụ cloudhsm_mgmt_util |

Và một cảnh báo rất nghiêm túc trước khi chọn CloudHSM: nếu bạn mất toàn bộ chứng chỉ của crypto officer, cụm HSM và mọi khoá bên trong sẽ mất VĨNH VIỄN, và AWS không thể giúp gì. Đó chính là cái giá của việc "AWS không có quyền truy cập" — nó là lý do bạn chọn CloudHSM, và cũng là rủi ro vận hành lớn nhất của nó. Hãy có quy trình lưu giữ chứng chỉ CO nghiêm ngặt trước khi đưa bất kỳ khoá sản xuất nào vào.

Đáp án

A — Tạo một gateway MỚI với dung lượng bộ đệm mà bạn cần.

Vì sao đúng

Storage Gateway có một ràng buộc mà nhiều người chỉ phát hiện khi cần tối ưu chi phí: đĩa đệm không thu nhỏ được.

⚠ Điểm mấu chốt — đĩa đã cấp làm cache là gắn vĩnh viễn với gateway đó:

Đĩa được cấp cho gateway làm cache
        ↓
    Gateway ghi cấu trúc dữ liệu nội bộ lên đó
        ↓
    → KHÔNG gỡ ra được
    → KHÔNG thu nhỏ được
    → KHÔNG thay bằng đĩa khác được
        ↓
    Chỉ THÊM đĩa cache mới là được
        ↓
    → muốn giảm dung lượng: TẠO GATEWAY MỚI

⚠ Quy trình chuyển sang gateway mới:

1. Dựng gateway MỚI với đĩa cache đúng kích thước cần
2. Kích hoạt và cấu hình file share / volume tương ứng
3. Chuyển client sang mount vào gateway mới
4. Xác nhận dữ liệu đã đồng bộ đầy đủ lên AWS
5. Xoá gateway cũ và giải phóng đĩa

⚠ Và bài học rút ra để lần sau không lặp lại:

Cấp đĩa cache theo NHU CẦU THỰC TẾ, không cấp thừa
        ↓
    Đo bằng chỉ số CachePercentUsed
        ↓
    → dưới 50% liên tục: cấp thừa, tốn tiền đĩa
    → trên 90% liên tục: thiếu, hiệu năng sẽ sập
        ↓
    Có thể THÊM đĩa cache về sau nếu thiếu
        ↓
    → nên bắt đầu vừa phải rồi mở rộng dần

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

• C (tắt gateway trước khi gỡ đĩa, rồi gắn đĩa khác) — đây là phương án gần nhất và nghe rất hợp lý về mặt vận hành. Nhưng gỡ đĩa cache — dù đã tắt gateway — sẽ làm hỏng gateway: gateway giữ trạng thái nội bộ trên đĩa đó và không tự dựng lại được. AWS khuyến cáo không làm việc này.

• B (gỡ đĩa cache của gateway hiện tại rồi resize xuống dung lượng cần) — cùng vấn đề: không gỡ được, không thu nhỏ được.

• D (giảm dung lượng thừa bằng cách giảm upload buffer từ console) — nhầm hai loại đĩa khác nhau: cache disk và upload buffer là hai thứ riêng biệt, và giảm cái này không giải phóng cái kia. Ngoài ra upload buffer cũng không thu nhỏ được.

Ghi nhớ

⚠ Hai loại đĩa cục bộ của Storage Gateway — bảng phải thuộc: | Loại đĩa | Việc | |---|---| | Cache disk | lưu dữ liệu HAY DÙNG để đọc nhanh tại chỗ | | Upload buffer | đệm dữ liệu CHỜ ĐẨY LÊN AWS | | Cả hai | THÊM được, KHÔNG gỡ, KHÔNG thu nhỏ | | Muốn giảm | tạo gateway mới |

Từ khoá nhận diện:

"giảm dung lượng đĩa cache" → tạo gateway mới "thêm dung lượng cache" → thêm đĩa, làm được ngay "cache đầy, hiệu năng sập" → CachePercentUsed "dữ liệu chưa lên AWS" → UploadBufferPercentUsed "gateway hỏng" → dựng gateway mới, khôi phục từ snapshot

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cache đang dùng bao nhiêu | chỉ số CachePercentUsed trong CloudWatch | | Tỷ lệ trúng cache | CacheHitPercent — quyết định cache có đủ không | | Đĩa nào đang làm gì | list-local-disks của Storage Gateway |

Và một lời khuyên khi lập kế hoạch dung lượng cho gateway mới: hãy dùng CacheHitPercent chứ đừng dùng CachePercentUsed để quyết định kích thước cache. Một cache dùng 40% nghe như đang thừa, nhưng nếu tỷ lệ trúng cache chỉ đạt 60% thì thực ra dữ liệu nóng của bạn đang bị đẩy ra liên tục — và trong trường hợp đó, thu nhỏ cache sẽ khiến hiệu năng tệ đi rõ rệt, đúng lúc bạn tưởng mình vừa tiết kiệm được tiền.

Đáp án

B — AWS Config sẽ KHÔNG gửi thông báo mới.

Vì sao đúng

AWS Config chỉ gửi thông báo khi có gì đó THAY ĐỔI — chứ không phải mỗi lần đánh giá lại.

⚠ Điểm mấu chốt — thông báo dựa trên THAY ĐỔI TRẠNG THÁI, không dựa trên lần chạy:

Lần đánh giá 1: COMPLIANT → NON_COMPLIANT
        ↓
    → CÓ thay đổi → GỬI thông báo

Lần đánh giá 2: NON_COMPLIANT → NON_COMPLIANT
        ↓
    → KHÔNG có thay đổi → KHÔNG gửi thông báo

Lần đánh giá 3: NON_COMPLIANT → COMPLIANT
        ↓
    → CÓ thay đổi → GỬI thông báo

⚠ Vì sao AWS thiết kế như vậy:

Một tài nguyên vi phạm có thể ở trạng thái đó hàng tuần
        ↓
    Nếu mỗi lần đánh giá đều gửi thông báo
        ↓
    → hàng nghìn thông báo trùng lặp mỗi ngày
    → đội vận hành sẽ lọc bỏ hết
    → mất tác dụng cảnh báo hoàn toàn
        ↓
    → chỉ báo khi có THAY ĐỔI là thiết kế đúng

⚠ Nhưng quy tắc VẪN CHẠY, và trạng thái vẫn được cập nhật:

Config vẫn đánh giá theo đúng chu kỳ
        ↓
    Vẫn ghi lại kết quả evaluation
    Vẫn cập nhật timestamp của lần đánh giá gần nhất
        ↓
    → chỉ là KHÔNG phát thông báo mới
        ↓
    → bảng compliance vẫn hiện đúng tình trạng hiện tại

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

• C (Config sẽ gửi thông báo với trạng thái hiện tại) — đây là phương án gần nhất và là điều nhiều người mong đợi. Nhưng Config chỉ gửi khi trạng thái ĐỔI, không gửi lại trạng thái không đổi.

• A (một khi bị đánh dấu non-compliant, quy tắc sẽ không chạy lại cho tới khi trạng thái đổi) — sai một cách vòng vo: quy tắc VẪN chạy theo chu kỳ — nếu không chạy thì làm sao biết trạng thái đã đổi hay chưa.

• D (Config không ghi lại thay đổi không đến từ hoạt động API, nên quy tắc không được kích hoạt) — nhầm sang một chuyện khác: đây là quy tắc periodic, nó chạy theo thời gian, không phụ thuộc vào việc có sự kiện API hay không.

Ghi nhớ

⚠ Khi nào AWS Config gửi thông báo — bảng phải thuộc: | Tình huống | Có thông báo | |---|---| | Trạng thái tuân thủ THAY ĐỔI | CÓ | | Trạng thái giữ nguyên sau đánh giá | KHÔNG | | Cấu hình tài nguyên thay đổi | CÓ (configuration item) | | Tài nguyên được tạo hoặc bị xoá | CÓ | | Quy tắc chạy mà không có gì đổi | KHÔNG |

Từ khoá nhận diện:

"vẫn non-compliant sau lần đánh giá tiếp theo" → KHÔNG có thông báo mới "muốn nhắc lại định kỳ về vi phạm" → tự dựng: EventBridge Scheduler + Lambda đọc compliance "ép đánh giá lại ngay" → start-config-rules-evaluation "tự sửa khi vi phạm" → remediation action "chặn từ đầu" → SCP, Config chỉ phát hiện SAU khi đã xảy ra

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tài nguyên nào đang vi phạm | get-compliance-details-by-config-rule | | Lần đánh giá gần nhất | describe-config-rule-evaluation-status | | Ép đánh giá lại | start-config-rules-evaluation |

Và một hệ quả vận hành cần lưu ý về hành vi này: một tài nguyên vi phạm sẽ chỉ báo cho bạn đúng MỘT LẦN, rồi im lặng mãi mãi. Nếu thông báo đầu tiên đó rơi vào lúc không ai để ý — cuối tuần, giữa một sự cố khác — thì vi phạm ấy có thể nằm lại nhiều tháng mà không có tín hiệu nào nhắc lại. Đó là lý do nên có một báo cáo tổng hợp định kỳ bên cạnh cơ chế thông báo theo sự kiện.

Đáp án

B — AMI có thể đã được mã hoá bằng CUSTOMER-MANAGED CMK. Cần cấp thêm quyền cho Auto Scaling Group để sửa lỗi.

Vì sao đúng

Chi tiết quyết định nằm ở nghịch lý mà đề nêu ra: người tạo ASG có quyền quản trị đầy đủ, mà vẫn không khởi chạy được instance.

⚠ Điểm mấu chốt — ASG không dùng quyền của BẠN, nó dùng quyền của SERVICE-LINKED ROLE:

Bạn tạo Auto Scaling group
        ↓
    Nhưng khi ASG khởi chạy instance
        ↓
    Nó dùng service-linked role của chính nó:
        AWSServiceRoleForAutoScaling
        ↓
    → quyền AdministratorAccess của BẠN
      KHÔNG áp cho role đó
        ↓
    → role đó phải được cấp quyền RIÊNG trên CMK

⚠ Bốn quyền mà service-linked role cần trên CMK — thiếu một là hỏng:

kms:Decrypt
kms:GenerateDataKeyWithoutPlaintext
kms:CreateGrant                     ← hay bị quên nhất
kms:DescribeKey
        ↓
    Cấp bằng cách sửa KEY POLICY của CMK:

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling"
  },
  "Action": ["kms:Decrypt", "kms:GenerateDataKeyWithoutPlaintext",
             "kms:CreateGrant", "kms:DescribeKey"],
  "Resource": "*"
}

⚠ Vì sao phải là CUSTOMER-MANAGED CMK chứ không phải AWS-managed key:

AWS managed key (aws/ebs)
        ↓
    Key policy KHÔNG SỬA ĐƯỢC
        ↓
    → không cấp quyền cho service-linked role được
    → nhưng AWS đã cấu hình sẵn cho các dịch vụ trong CÙNG tài khoản
        ↓
    → không phải nguồn gốc của lỗi này

Customer-managed CMK
        ↓
    Key policy SỬA ĐƯỢC — và mặc định KHÔNG cho ASG dùng
        ↓
    → đây chính là nguyên nhân

Xem thêm câu #11558 và #11566: cùng tình huống ASG với EBS mã hoá — một câu hỏi nguyên nhân của thông báo lỗi Client.InternalError, một câu hỏi cách sửa khi CMK ở tài khoản khác.

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

• A (AMI mã hoá bằng AWS-MANAGED CMK, cần cấp thêm quyền cho ASG) — đây là phương án gần nhất và chỉ sai một từ. Với AWS managed key thì không sửa key policy được, nên "cấp thêm quyền" là bất khả thi — và cũng không cần, vì AWS đã cấu hình sẵn cho dịch vụ trong cùng tài khoản.

• C (ASG cần service-linked role để truy cập KMS, hãy tạo role đó) — service-linked role được AWS TỰ TẠO khi bạn tạo ASG đầu tiên; bạn không tự tạo. Vấn đề không phải thiếu role, mà là role thiếu QUYỀN trên khoá.

• D (service-linked role có thể đã bị xoá) — nếu vậy thì ASG không hoạt động được chút nào, chứ không riêng gì instance có AMI mã hoá.

Ghi nhớ

⚠ Hai loại khoá KMS — bảng phải thuộc: | | AWS managed key (aws/ebs) | Customer managed key (CMK) | |---|---|---| | Sửa key policy | KHÔNG | CÓ | | Chia sẻ liên tài khoản | KHÔNG | CÓ | | Xoay khoá | tự động, không tắt được | bật thủ công | | Chi phí | miễn phí | có phí theo khoá + lời gọi | | Cấp quyền cho service-linked role | AWS lo sẵn | BẠN phải tự cấp |

Từ khoá nhận diện:

"ASG không khởi chạy được instance có AMI mã hoá" → key policy thiếu quyền cho service-linked role "có AdministratorAccess mà vẫn lỗi" → dịch vụ dùng ROLE của nó, không dùng quyền của bạn "Client.InternalError khi khởi chạy" → thường là quyền KMS "CMK ở tài khoản khác" → copy và mã hoá lại snapshot bằng CMK cùng tài khoản "chia sẻ AMI mã hoá" → phải là CMK, và chia sẻ cả quyền dùng khoá

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Vì sao ASG thất bại | Activity history của ASG — đọc StatusMessage | | Key policy có đủ không | get-key-policy, tìm AWSServiceRoleForAutoScaling | | Snapshot mã hoá bằng khoá nào | describe-snapshots, xem KmsKeyId |

Và một lời khuyên rút ra từ đặc thù của lỗi này: hãy kiểm thử một lần scale-out thật ngay sau khi đổi sang AMI mã hoá, đừng chờ tới lúc hệ thống tự scale. Đây là loại lỗi nằm im rất lâu — mọi thứ chạy hoàn hảo cho tới đúng đêm mà lưu lượng tăng và ASG cần thêm máy, rồi mọi instance mới đều chết ngay khi khởi chạy với một thông báo chẳng nói gì về nguyên nhân thật.

Đáp án

A, E — hai điều đúng:

• E — Chủ bucket KHÔNG có quyền trên những đối tượng do tài khoản AWS khác tạo ra.
• A — Tài khoản AWS đã tạo ra đối tượng phải cấp quyền cho chủ bucket TRƯỚC, thì chủ bucket mới uỷ quyền tiếp cho bên khác được.

Vì sao đúng

⚠ Điều E — sở hữu bucket không đồng nghĩa với sở hữu nội dung:

Tài khoản A tải đối tượng lên bucket của tài khoản B
        ↓
    Chủ sở hữu BUCKET  = B
    Chủ sở hữu ĐỐI TƯỢNG = A
        ↓
    → B sở hữu CÁI THÙNG nhưng KHÔNG sở hữu
      những gì bên trong
        ↓
    → B trả tiền lưu trữ, nhưng không đọc được nội dung

⚠ Điều A — chuỗi uỷ quyền phải bắt đầu từ chủ sở hữu đối tượng:

B muốn cấp quyền trên đối tượng cho tài khoản C
        ↓
    Nhưng B không sở hữu đối tượng
        ↓
    → B KHÔNG uỷ quyền được thứ mình không có
        ↓
    Trình tự đúng:
        1. A cấp quyền cho B (qua object ACL
           "bucket-owner-full-control")
        2. B mới cấp tiếp cho C

Đây là nguyên tắc chung của mọi hệ thống phân quyền: không ai trao được quyền mà mình không có.

⚠ Và cách làm hiện đại khiến toàn bộ vấn đề này biến mất:

S3 Object Ownership = BucketOwnerEnforced
        ↓
    → ACL bị VÔ HIỆU HOÁ hoàn toàn
    → CHỦ BUCKET LUÔN SỞ HỮU mọi đối tượng, bất kể ai ghi
        ↓
    → mặc định cho bucket tạo mới từ tháng 4/2023
    → AWS khuyến nghị dùng

Xem thêm câu #11748: cùng chủ đề nhưng ở góc xử lý sự cố — khi việc xuất dữ liệu đã hoàn tất và chủ bucket không đọc được, cách chữa là gọi PutObjectAcl.

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

• C (chủ bucket là chủ của MỌI đối tượng, bất kể tài khoản nào tải lên) — đây là phương án gần nhất và là điều ai cũng tưởng là đúng. Nó chỉ đúng khi bucket bật BucketOwnerEnforced; với chế độ ACL cũ mà đề đang mô tả thì hoàn toàn sai.

• D (chủ bucket nên cấp cross-account delegation cho người dùng ở tài khoản khác) — bỏ qua đúng vấn đề: chủ bucket không có quyền để mà uỷ quyền. Phải giải quyết bước A trước.

• B (dùng root user vì root có quyền trên mọi đối tượng tạo dưới nó) — sai: root của tài khoản B cũng không sở hữu đối tượng của tài khoản A. Quyền sở hữu đối tượng nằm ở tài khoản đã ghi, không phụ thuộc vào root hay IAM user.

Ghi nhớ

⚠ Ba chế độ Object Ownership — bảng phải thuộc: | Chế độ | Ai sở hữu đối tượng | |---|---| | BucketOwnerEnforced | CHỦ BUCKET, luôn luôn — ACL vô hiệu, mặc định mới, AWS khuyến nghị | | BucketOwnerPreferred | chủ bucket, nếu người ghi dùng bucket-owner-full-control | | ObjectWriter | người ghi — cách cũ, nguồn gốc của vấn đề trong đề |

Từ khoá nhận diện:

"chủ bucket không đọc được đối tượng" → object ownership liên tài khoản "phòng từ đầu" → BucketOwnerEnforced hoặc ép ACL bằng bucket policy "chữa sau khi đã ghi" → PutObjectAcl từ tài khoản đã ghi "root sở hữu mọi thứ" → SAI với đối tượng của tài khoản khác "chủ bucket luôn sở hữu" → chỉ đúng với BucketOwnerEnforced

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai sở hữu một đối tượng | get-object-acl --bucket ... --key ... | | Bucket đang ở chế độ nào | get-bucket-ownership-controls | | Có đối tượng nào thuộc tài khoản khác không | S3 Inventory báo cáo cột owner |

Và một lời khuyên nên áp dụng cho mọi bucket nhận dữ liệu từ bên ngoài: bật BucketOwnerEnforced ngay từ khi tạo bucket. Nó xoá sổ vĩnh viễn cả một lớp vấn đề — chủ bucket không đọc được dữ liệu mình đang trả tiền lưu trữ — và với những bucket cũ thì đây là một trong những thay đổi cấu hình đơn giản nhất mang lại lợi ích lớn nhất, miễn là bạn xác nhận trước rằng không có quy trình nào đang phụ thuộc vào ACL.

Đáp án

A — chính sách dùng "Effect": "Allow", hành động s3:GetObject và s3:ListBucket, với Resource gồm CẢ ARN của bucket LẪN ARN của các đối tượng bên trong (/*).

Vì sao đúng

Chính sách này đúng ở ba điểm mà các phương án khác đều sai một hoặc nhiều.

⚠ Điểm thứ nhất — hai hành động khác nhau cần hai loại Resource khác nhau:

s3:ListBucket    → thao tác trên CHÍNH BUCKET
        ↓
    Resource phải là:  arn:aws:s3:::mybucket

s3:GetObject     → thao tác trên ĐỐI TƯỢNG bên trong
        ↓
    Resource phải là:  arn:aws:s3:::mybucket/*
        ↓
    → thiếu một trong hai là chức năng tương ứng KHÔNG hoạt động
    → chỉ phương án A có ĐỦ CẢ HAI

⚠ Điểm thứ hai — tên hành động phải chính xác:

s3:GetObject     ✓ ĐÚNG — tải nội dung một đối tượng
s3:ListBucket    ✓ ĐÚNG — liệt kê đối tượng trong bucket
        ↓
s3:ReadObject    ✗ KHÔNG TỒN TẠI  (phương án B)
s3:GetBucket     ✗ KHÔNG TỒN TẠI  (phương án C)

⚠ Điểm thứ ba — Effect chỉ có đúng hai giá trị:

"Effect": "Allow"   ✓
"Effect": "Deny"    ✓
        ↓
"Effect": "deny"       ✗ PHÂN BIỆT CHỮ HOA/THƯỜNG  (phương án C)
"Effect": "read-only"  ✗ KHÔNG TỒN TẠI            (phương án D)

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

Cả bốn phương án đều viết urn:aws:s3::: — nhưng tiền tố ĐÚNG của ARN trên AWS là arn:aws:s3:::.

ARN = Amazon Resource Name
        ↓
    Luôn bắt đầu bằng "arn:"
        ↓
    "urn:" là một chuẩn định danh khác, KHÔNG dùng trên AWS
        ↓
    → chính sách viết "urn:" sẽ bị S3 TỪ CHỐI

Đây là lỗi đánh máy trong đề bài, xuất hiện đồng đều ở cả bốn phương án nên không ảnh hưởng tới việc chọn đáp án: A vẫn là phương án duy nhất đúng ở mọi khía cạnh còn lại. Nhưng khi viết chính sách thật, hãy nhớ luôn là arn:aws:s3:::.

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

• B (s3:ReadObject, và Resource chỉ có ARN bucket) — đây là phương án gần nhất và sai hai chỗ: s3:ReadObject không tồn tại (đúng phải là s3:GetObject), và Resource thiếu ARN đối tượng (/*) nên dù có đúng tên hành động thì cũng không đọc được tệp nào.

• C (Effect: "deny", Principal: ".", s3:GetBucket) — sai ba chỗ: deny viết thường (JSON của IAM phân biệt chữ hoa thường), Principal: "." vô nghĩa (phải là "*" hoặc một ARN), và s3:GetBucket không tồn tại.

• D (Effect: "read-only", Principal: "*.*") — sai hai chỗ rõ ràng: read-only không phải giá trị hợp lệ của Effect, và "*.*" không phải cú pháp principal hợp lệ.

Ghi nhớ

⚠ Cấu trúc một câu lệnh trong chính sách IAM/S3 — bảng phải thuộc: | Trường | Giá trị hợp lệ | |---|---| | Effect | CHỈ "Allow" hoặc "Deny" — phân biệt chữ hoa thường | | Principal | "*", hoặc ARN, hoặc {"Service": "..."} — chỉ có ở resource-based policy | | Action | "s3:GetObject", hoặc mảng, hoặc "s3:*" | | Resource | ARN, luôn bắt đầu bằng arn: | | Condition | tuỳ chọn — điều kiện bổ sung | | Sid | tuỳ chọn — nhãn cho câu lệnh |

Từ khoá nhận diện:

"cho phép đọc bucket" → s3:GetObject + s3:ListBucket, hai Resource khác nhau "s3:ReadObject", "s3:GetBucket" → KHÔNG TỒN TẠI "urn:aws:..." → SAI, phải là arn:aws:... "Effect: read-only" → SAI, chỉ có Allow và Deny "quyền chỉ đọc dựng sẵn" → managed policy AmazonS3ReadOnlyAccess

⚠ Hành động S3 và Resource tương ứng — bảng rất hay dùng: | Hành động | Resource phải là | |---|---| | s3:ListBucket | arn:aws:s3:::bucket | | s3:GetBucketLocation | arn:aws:s3:::bucket | | s3:GetObject | arn:aws:s3:::bucket/* | | s3:PutObject | arn:aws:s3:::bucket/* | | s3:DeleteObject | arn:aws:s3:::bucket/* | | Cách nhớ | thao tác trên BUCKET → ARN bucket; thao tác trên ĐỐI TƯỢNG → ARN có /* |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chính sách có hợp lệ không | put-bucket-policy sẽ báo lỗi cú pháp ngay | | Ai thật sự truy cập được | IAM Access Analyzer for S3 | | Quyền hiệu lực | IAM Policy Simulator |

Và một mẹo tránh gần hết các lỗi kiểu này: hãy dùng trình soạn chính sách trực quan của IAM Console hoặc iam policy validation thay vì gõ JSON bằng tay. Nó tự sinh đúng cấu trúc, gợi ý đúng tên hành động, và cảnh báo ngay khi Resource không khớp với loại hành động — ba lỗi mà cả ba phương án sai trong câu hỏi này đều mắc phải.

Đáp án

D — Cấu hình AWS WAF trên CloudFront để bảo vệ hạ tầng, và dùng AWS Firewall Manager để nhân bản, quản lý cấu hình WAF trên nhiều tài khoản AWS.

Vì sao đúng

Đề nêu hai yêu cầu, và mỗi dịch vụ giải quyết một yêu cầu:

⚠ Điểm mấu chốt thứ nhất — WAF phải gắn ở ĐIỂM VÀO, tức là CloudFront:

Lưu lượng độc hại → CloudFront → ALB → EC2 → RDS
        ↓
    Gắn WAF ở CLOUDFRONT (điểm vào ngoài cùng)
        ↓
    → chặn ngay tại EDGE, gần người gửi nhất
    → request độc hại KHÔNG BAO GIỜ tới hạ tầng của bạn
    → bảo vệ cả EC2 lẫn cơ sở dữ liệu phía sau
        ↓
    Gắn WAF ở EC2 (phương án C)
        ↓
    → không làm được: WAF chỉ gắn vào CloudFront, ALB,
      API Gateway, AppSync, Cognito, App Runner

⚠ Điểm mấu chốt thứ hai — Firewall Manager quản lý tập trung:

AWS Firewall Manager
        ↓
    Định nghĩa một CHÍNH SÁCH BẢO MẬT ở tài khoản quản trị
        ↓
    Tự động áp cho MỌI tài khoản trong Organizations
        ↓
    → tài nguyên MỚI tạo cũng tự động được bảo vệ
    → tài khoản MỚI thêm vào tổ chức cũng vậy
    → không phải sao chép tay, không phải nhớ làm lại

⚠ Và Firewall Manager quản lý được nhiều hơn WAF:

AWS WAF rules
AWS Shield Advanced
Security Group (kiểm tra và sửa)
AWS Network Firewall
Route 53 Resolver DNS Firewall

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

• B (dùng Firewall Manager để tạo rào chắn trên CloudFront, nhân bản bằng cách xuất cấu hình thủ công) — đây là phương án gần nhất và vế đầu gần đúng. Nhưng nó hiểu sai vai trò: Firewall Manager không tự tạo rào chắn — nó quản lý và phân phối chính sách WAF/Shield. Và vế "xuất cấu hình thủ công" trái hẳn mục đích của dịch vụ, vốn là tự động áp dụng.

• C (cấu hình WAF trên EC2, vì WAF trên CloudFront làm tăng độ trễ) — sai hai chỗ: WAF KHÔNG gắn được vào EC2, và WAF ở CloudFront không làm tăng độ trễ đáng kể — ngược lại, chặn ở edge còn giảm tải cho hạ tầng phía sau.

• A (dùng Security Group trên CloudFront) — CloudFront không nằm trong VPC, nên không gắn Security Group được. Ngoài ra Security Group không có luật Deny để chặn IP cụ thể.

Ghi nhớ

⚠ WAF gắn được vào đâu — bảng phải thuộc: | Gắn được | KHÔNG gắn được | |---|---| | CloudFront | EC2 instance | | Application Load Balancer | Network Load Balancer | | API Gateway | S3 (trực tiếp) | | AppSync | RDS | | Cognito User Pool | | | App Runner, Verified Access | |

Từ khoá nhận diện:

"chặn tấn công tầng ứng dụng" → AWS WAF "quản lý WAF trên nhiều tài khoản" → AWS Firewall Manager "chống DDoS nâng cao" → AWS Shield Advanced "WAF trên EC2 hoặc NLB" → KHÔNG GẮN ĐƯỢC "Security Group cho CloudFront" → KHÔNG CÓ "phát hiện hành vi bất thường" → GuardDuty

Ba việc kiểm chứng: | Việc | Cách | |---|---| | WAF có đang chặn gì không | WAF sampled requests và CloudWatch metrics | | Có tài nguyên nào chưa được bảo vệ | Firewall Manager compliance dashboard | | Rule có chặn nhầm không | chạy ở chế độ Count trước khi chuyển sang Block |

Và một lời khuyên bắt buộc khi triển khai WAF lần đầu: luôn bật rule ở chế độ Count trong vài ngày trước khi chuyển sang Block. Managed rule group rất mạnh nhưng cũng rất dễ chặn nhầm lưu lượng hợp lệ — một biểu mẫu có ký tự đặc biệt, một API nhận JSON dài, một ứng dụng di động có user agent lạ. Chế độ Count cho bạn thấy chính xác những gì sẽ bị chặn mà không làm phiền một khách hàng nào.

Đáp án

D — Dùng bản ghi Alias.

Vì sao đúng

Có hai lý do độc lập khiến Alias là lựa chọn duy nhất đúng ở đây.

⚠ Lý do thứ nhất — johntrucks.com là ZONE APEX:

https://johntrucks.com/     ← tên miền GỐC, không có "www"
        ↓
    Chuẩn DNS CẤM tạo CNAME ở zone apex
        ↓
    (vì zone apex đã bắt buộc có bản ghi SOA và NS,
     mà CNAME không đứng cùng bản ghi nào khác được)
        ↓
    → CNAME BỊ LOẠI ngay lập tức

⚠ Lý do thứ hai — đích là CloudFront, một tài nguyên AWS:

Alias record chỉ trỏ tới TÀI NGUYÊN AWS:
        CloudFront distribution        ← trường hợp này
        ALB / NLB
        S3 static website endpoint
        API Gateway, Elastic Beanstalk
        Global Accelerator, VPC endpoint
        hoặc record khác trong CÙNG hosted zone
        ↓
    → CloudFront nằm trong danh sách
    → Alias hoạt động hoàn hảo

⚠ Và Alias còn có hai lợi thế thực tế:

MIỄN PHÍ truy vấn
        ↓
    → Route 53 không tính tiền truy vấn cho Alias
      trỏ tới tài nguyên AWS (CNAME thì có tính)

Tự động theo IP của tài nguyên
        ↓
    → CloudFront đổi IP lúc nào cũng được
    → không cần cấu hình lại, không phụ thuộc TTL

Xem thêm câu #11677: cùng lựa chọn CNAME hay Alias nhưng đáp án là CNAME, vì đích ở đó là tên miền của bên thứ ba (ngoài AWS) và tên miền nguồn là www. chứ không phải zone apex. Hai câu không mâu thuẫn: đích ở đâu và tên miền có phải zone apex hay không quyết định câu trả lời.

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

• A (CNAME) — đây là phương án gần nhất và sẽ đúng nếu tên miền là www.johntrucks.com. Nhưng với zone apex thì chuẩn DNS cấm dùng CNAME. Đây chính là ranh giới mà câu hỏi kiểm tra.

• C (bản ghi A) — A record trỏ tới một địa chỉ IPv4 cố định. CloudFront dùng hàng trăm IP thay đổi liên tục ở các edge location — ghi cứng một IP là chắc chắn hỏng.

• B (bản ghi AAAA) — cùng lý do, chỉ khác là IPv6. (Lưu ý: Alias record có thể có type A hoặc AAAA ở tầng bên dưới, nhưng thứ bạn tạo trong Route 53 vẫn được gọi là Alias.)

Ghi nhớ

⚠ CNAME và Alias — bảng phải thuộc, đây là câu hỏi Route 53 kinh điển: | | CNAME | Alias | |---|---|---| | Chuẩn | DNS tiêu chuẩn | riêng của Route 53 | | Trỏ tới | bất kỳ tên miền nào | chỉ tài nguyên AWS hoặc record cùng zone | | Zone apex | KHÔNG ĐƯỢC | ĐƯỢC | | Chi phí truy vấn | có tính phí | MIỄN PHÍ | | Health check tự động | không | có với một số tài nguyên | | TTL | bạn đặt | theo tài nguyên AWS |

Từ khoá nhận diện:

"trỏ tên miền GỐC (zone apex)" → Alias "trỏ tới CloudFront, ALB, S3 website" → Alias "trỏ tới tên miền NGOÀI AWS" → CNAME "trỏ tới một địa chỉ IP" → A (IPv4) hoặc AAAA (IPv6) "tiết kiệm phí truy vấn DNS" → Alias

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bản ghi đã lan chưa | dig johntrucks.com — phải trỏ về IP của CloudFront | | Distribution đã sẵn sàng chưa | trạng thái phải là Deployed | | Bucket có bị chặn đúng không | curl URL S3 trực tiếp — phải nhận 403 |

Và một mẹo nhớ không bao giờ nhầm giữa hai loại bản ghi này: Alias là "CNAME dành riêng cho AWS, và dùng được cả ở tên miền gốc". Mỗi khi đích đến là một tài nguyên AWS, hãy dùng Alias — bạn được thêm khả năng dùng ở zone apex, được miễn phí truy vấn, và không phải lo tài nguyên đổi địa chỉ.