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

Đáp án

B, E — hai loại volume KHÔNG dùng làm ổ khởi động được:

• E — Throughput Optimized HDD (st1)
• B — Cold HDD (sc1)

Vì sao đúng

⚠ Điểm mấu chốt — hai loại HDD của EBS không làm ổ boot được:

st1 và sc1 là ổ ĐĨA TỪ (HDD)
        ↓
    Tối ưu cho ĐỌC GHI TUẦN TỰ, throughput lớn
        ↓
    Nhưng khởi động hệ điều hành là NGẪU NHIÊN,
    rất nhiều thao tác I/O nhỏ rải rác
        ↓
    → HDD làm việc đó cực tệ
        ↓
    → AWS chặn thẳng: KHÔNG cho dùng làm ổ gốc

⚠ Bảng đầy đủ — loại nào làm boot volume được:

⚠ Vậy st1 và sc1 dùng vào việc gì:

st1 — Throughput Optimized HDD
        ↓
    Big data, log xử lý theo lô, kho dữ liệu, ETL
    → đọc ghi TUẦN TỰ khối lượng lớn

sc1 — Cold HDD
        ↓
    Dữ liệu ÍT TRUY CẬP, cần dung lượng lớn giá rẻ
    → RẺ NHẤT trong các loại EBS

Cả hai đều dùng làm ổ dữ liệu gắn thêm, chỉ không làm ổ gốc.

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

(Ba phương án còn lại đều LÀM ổ boot được, nên không phải đáp án.)

• D (Instance Store) — đây là phương án gần nhất và rất dễ chọn nhầm vì instance store là ổ tạm, mất dữ liệu khi máy dừng. Nhưng instance store-backed AMI có thật và khởi động được — đó là kiểu AMI đời đầu của EC2. Đúng là ngày nay hầu như không ai dùng (không stop được, không đổi loại instance được), nhưng câu hỏi hỏi có làm được không, chứ không hỏi có nên không.

• A (gp2) — SSD đa dụng, loại ổ boot phổ biến nhất.

• C (io1) — SSD hiệu năng cao, làm ổ boot được (dù thường phí tiền cho một ổ gốc).

Ghi nhớ

⚠ Sáu loại EBS volume — bảng phải thuộc: | Loại | Kiểu | IOPS tối đa | Dùng cho | |---|---|---|---| | gp3 | SSD | 16.000 | mặc định nên chọn — IOPS tách khỏi dung lượng | | gp2 | SSD | 16.000 | 3 IOPS/GB, loại cũ hơn | | io1 | SSD | 64.000 | PIOPS, tỷ lệ 50:1 | | io2 / Block Express | SSD | 64.000 / 256.000 | bền hơn, độ trễ thấp nhất | | st1 | HDD | throughput 500 MB/s | tuần tự, big data — KHÔNG boot | | sc1 | HDD | throughput 250 MB/s | lạnh, rẻ nhất — KHÔNG boot |

Từ khoá nhận diện:

"st1, sc1 làm ổ boot" → KHÔNG ĐƯỢC "cần IOPS cao mà không cần dung lượng" → gp3 "độ trễ thấp nhất, IOPS cực cao" → io2 Block Express "đọc tuần tự khối lượng lớn, rẻ" → st1 "lưu trữ lạnh, rẻ nhất" → sc1 "một volume nhiều instance" → io1/io2 Multi-Attach (tối đa 16, cùng AZ)

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Volume loại gì | describe-volumes, xem VolumeType | | Ổ nào là ổ gốc | describe-instances, xem RootDeviceName | | Có đang chạm trần hiệu năng không | chỉ số VolumeQueueLength |

Và một lời khuyên áp dụng được ngay: hãy rà lại toàn bộ volume gp2 đang có và chuyển chúng sang gp3. Việc chuyển đổi diễn ra tại chỗ, không cần dừng máy, cho hiệu năng nền tốt hơn, và thường rẻ hơn khoảng 20% — đây là một trong số rất ít thay đổi trên AWS mà bạn vừa tiết kiệm tiền vừa chạy nhanh hơn, nên gần như không có lý do gì để trì hoãn.

Đáp án

A — Dùng SSE-KMS để mã hoá dữ liệu người dùng trên S3.

Vì sao đúng

Đề nêu hai yêu cầu mâu thuẫn nhau ở vẻ ngoài, và chỉ SSE-KMS thoả cả hai:

⚠ Điểm mấu chốt — chỉ SSE-KMS cho bạn nhật ký sử dụng khoá:

SSE-KMS
        ↓
    Mỗi lần đọc/ghi đối tượng, S3 gọi KMS
        Decrypt / GenerateDataKey
        ↓
    Mỗi lời gọi là một sự kiện CloudTrail chứa:
        - AI gọi (userIdentity)
        - LÚC NÀO
        - cho ĐỐI TƯỢNG NÀO (encryptionContext)
        ↓
    → đúng "audit trail" mà đề yêu cầu

⚠ Vì sao SSE-S3 không đủ dù cũng do AWS quản lý khoá:

SSE-S3 (AES256)
        ↓
    AWS quản lý khoá HOÀN TOÀN, ẩn khỏi bạn
        ↓
    → KHÔNG có khoá nào trong tài khoản của bạn
    → KHÔNG có key policy để xem
    → KHÔNG có sự kiện CloudTrail nào về việc dùng khoá
        ↓
    → mã hoá thì có, nhưng KHÔNG KIỂM TOÁN ĐƯỢC

⚠ Và SSE-KMS còn cho thêm những thứ mà startup tài chính cần:

Key policy → kiểm soát AI được dùng khoá
Xoay khoá tự động → mỗi năm một lần
Vô hiệu hoá khoá → "công tắc ngắt" cho toàn bộ dữ liệu
Tách quyền → người quản trị S3 ≠ người quản trị khoá

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

• D (dùng SSE-S3) — đây là phương án gần nhất và thoả yêu cầu thứ nhất (không phải tự cung cấp khoá), nhưng trượt hoàn toàn yêu cầu thứ hai: không có nhật ký sử dụng khoá nào. Đây chính là ranh giới mà câu hỏi muốn kiểm tra.

• B (dùng SSE-C) — khách hàng phải gửi khoá theo TỪNG REQUEST, tức là bạn phải tự quản lý và tự lưu trữ khoá — trái thẳng yêu cầu "không muốn tự cung cấp khoá". S3 dùng xong là quên khoá ngay.

• C (mã hoá phía client bằng khoá tự cung cấp) — cũng buộc bạn tự quản lý khoá, và còn nhiều việc hơn: tự mã hoá, tự lưu khoá, tự lo xoay khoá.

Xem thêm câu #11662: cùng bài toán chọn kiểu mã hoá S3 nhưng đáp án là SSE-S3, vì đề ở đó không đòi nhật ký kiểm toán mà chỉ cần AES-256 và không phải quản khoá. Hai câu không mâu thuẫn: yêu cầu khác nhau thì đáp án khác nhau.

Ghi nhớ

⚠ Bốn kiểu mã hoá của S3 — bảng phải thuộc: | Kiểu | Ai giữ khoá | Nhật ký dùng khoá | |---|---|---| | SSE-S3 | AWS hoàn toàn | KHÔNG | | SSE-KMS | KMS, trong tài khoản bạn | CÓ (CloudTrail) | | DSSE-KMS | KMS, mã hoá hai lớp | CÓ | | SSE-C | bạn, gửi theo mỗi request | không (S3 không lưu khoá) | | Client-side | bạn hoàn toàn | tuỳ bạn tự làm |

Từ khoá nhận diện:

"cần biết ai dùng khoá, khi nào" → SSE-KMS "mã hoá đơn giản, không cần kiểm toán" → SSE-S3 "tự giữ khoá hoàn toàn" → SSE-C hoặc client-side "tuân thủ khắt khe, mã hoá hai lớp" → DSSE-KMS "khoá phải nằm trong HSM của riêng tôi" → CloudHSM hoặc External Key Store (XKS)

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đối tượng mã hoá kiểu gì | head-object, xem ServerSideEncryption và SSEKMSKeyId | | Ai đã dùng khoá | CloudTrail, lọc eventSource = kms.amazonaws.com | | Có bị throttle KMS không | chỉ số của KMS, và lỗi ThrottlingException |

Và một lời khuyên hai mặt cho startup trong đề: hãy bật S3 Bucket Keys ngay khi chọn SSE-KMS. Nhật ký kiểm toán là thứ họ cần, nhưng ở quy mô một ứng dụng tài chính có nhiều người dùng thì mỗi lượt đọc tệp là một lời gọi KMS được tính tiền — Bucket Keys giữ lại khả năng kiểm toán ở mức bucket trong khi cắt gần hết chi phí đó, và đó là đánh đổi mà hầu như mọi hệ thống thật đều nên chọn.

Đáp án

B — Xem header X-Forwarded-For.

Vì sao đúng

Triệu chứng đề mô tả là hoàn toàn bình thường và có thể dự đoán trước: ứng dụng đứng sau proxy thì chỉ thấy IP của proxy.

⚠ Điểm mấu chốt — ALB kết thúc kết nối của client và mở kết nối mới tới target:

Client (203.0.113.45)
        ↓  kết nối TCP thứ nhất
    Application Load Balancer
        ↓  kết nối TCP THỨ HAI, hoàn toàn mới
    EC2 instance
        ↓
    → instance thấy IP nguồn là IP RIÊNG của ALB
    → mọi request đều cùng một IP, đúng như đề mô tả
        ↓
    Nhưng ALB có gắn thêm header:
        X-Forwarded-For: 203.0.113.45

⚠ Cách đọc trong ứng dụng:

X-Forwarded-For: 203.0.113.45, 70.41.3.18, 150.172.238.178
                 ↑ client thật    ↑ proxy 1    ↑ proxy 2
        ↓
    Nếu chỉ có ALB → chỉ có MỘT địa chỉ
    Nếu có CloudFront/proxy phía trước → nhiều địa chỉ
        ↓
    Địa chỉ ĐẦU TIÊN là client gốc

⚠ Nhưng có một cảnh báo bảo mật rất quan trọng:

Client CÓ THỂ TỰ ĐẶT header X-Forwarded-For
        ↓
    → giá trị đầu tiên có thể là GIẢ MẠO
        ↓
    ALB NỐI THÊM vào cuối, không xoá cái client gửi
        ↓
    → nếu dùng cho GIỚI HẠN TẦN SUẤT hay CHẶN IP,
      đừng tin mù quáng địa chỉ đầu tiên
        ↓
    Cách an toàn: đếm ngược từ cuối, bỏ qua đúng số
    proxy tin cậy mà bạn biết là có

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

• D (xem header X-Forwarded-Proto) — đây là phương án gần nhất và là một header có thật do ALB gắn, nhưng nó mang giao thức (http hay https), không mang IP. (Nó rất quan trọng cho việc khác: ứng dụng sau ALB thường tưởng mình đang chạy HTTP và sinh ra URL chuyển hướng sai giao thức.)

• A (xem cookie của client) — cookie chứa dữ liệu phiên do ứng dụng hoặc ALB tự đặt, không chứa địa chỉ IP.

• C (sửa giao diện để người dùng gửi IP của họ trong request) — vừa không tin cậy được (client tự khai thì tự bịa được), vừa thừa vì header đã có sẵn.

Ghi nhớ

⚠ Ba header X-Forwarded-* của ALB — bảng phải thuộc: | Header | Nội dung | |---|---| | X-Forwarded-For | IP gốc của client | | X-Forwarded-Proto | http hay https — cần khi ứng dụng sinh URL | | X-Forwarded-Port | cổng client đã gọi |

Từ khoá nhận diện:

"mọi request đều cùng một IP" → X-Forwarded-For "ứng dụng chuyển hướng về HTTP dù client dùng HTTPS" → X-Forwarded-Proto "NLB mà vẫn muốn thấy IP thật" → preserve client IP hoặc Proxy Protocol v2 "CloudFront muốn biết IP client" → CloudFront-Viewer-Address "chặn IP xấu" → AWS WAF, đừng tự làm trong ứng dụng

⚠ Mỗi loại load balancer giữ IP client thế nào: | Loại | Cách | |---|---| | ALB | X-Forwarded-For (tầng 7) | | NLB | giữ NGUYÊN IP nguồn khi target theo instance id; hoặc Proxy Protocol v2 | | CloudFront | X-Forwarded-For và CloudFront-Viewer-Address | | Classic LB | X-Forwarded-For (HTTP/HTTPS) hoặc Proxy Protocol (TCP) |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Header có tới không | ghi log toàn bộ header của một request thử | | ALB có gắn đúng không | bật ELB access log, cột client:port | | Có bị giả mạo không | đếm số phần tử trong X-Forwarded-For, so với số proxy thật |

Và một lời khuyên cho lớp bảo mật: nếu bạn cần chặn theo IP hay giới hạn tần suất, hãy làm ở AWS WAF chứ đừng làm trong mã ứng dụng dựa vào X-Forwarded-For. WAF nhìn thấy IP kết nối thật ở tầng edge, trước khi bất kỳ header nào do client kiểm soát có thể đánh lừa logic của bạn — còn ứng dụng thì luôn nhận header sau khi nó đã đi qua tay người gửi.

Đáp án

A — Dùng trường Export trong mục Outputs của template.

Vì sao đúng

Chia sẻ giá trị giữa các stack là một cặp thao tác hai bước, mỗi bước ở một stack.

⚠ Điểm mấu chốt — Export ở stack NGUỒN, ImportValue ở stack ĐÍCH:

Stack A (nguồn) — khai Export
    Outputs:
      IdSubnet:
        Value: !Ref SubnetUngDung
        Export:
          Name: !Sub "${AWS::StackName}-IdSubnet"
        ↓
Stack B (đích) — dùng ImportValue
    SubnetId: !ImportValue "mang-chinh-IdSubnet"

⚠ Ba ràng buộc của cơ chế export/import, phải thuộc:

1. Tên export phải DUY NHẤT trong một tài khoản + một Region
        ↓
    → nên đặt tiền tố tên stack: ${AWS::StackName}-...

2. KHÔNG dùng chéo Region, KHÔNG dùng chéo tài khoản
        ↓
    → muốn chéo thì dùng SSM Parameter Store

3. KHÔNG XOÁ hay SỬA được export đang có stack khác dùng
        ↓
    → đây là ràng buộc gây đau đầu nhất

⚠ Ràng buộc thứ ba đáng nói kỹ vì nó tạo ra ràng buộc cứng giữa các stack:

Stack B đang ImportValue của Stack A
        ↓
    → KHÔNG xoá được Stack A
    → KHÔNG sửa được giá trị export đó
        ↓
    Muốn đổi: phải sửa Stack B bỏ import trước,
              rồi mới sửa hoặc xoá Stack A
        ↓
    → với nhiều stack lồng nhau, việc này rất phiền

Vì vậy nhiều đội chọn SSM Parameter Store thay thế: stack A ghi giá trị vào tham số, stack B đọc ra — không tạo ràng buộc cứng, và dùng được chéo Region.

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

• D (dùng Fn::ImportValue) — đây là phương án gần nhất và là nửa còn lại của đúng cơ chế này. Nhưng nó dùng ở stack ĐÍCH để nhận giá trị; đề hỏi cách cung cấp thông tin từ stack nguồn, tức là Export.

• B (dùng trường Expose trong Outputs) — không tồn tại. Từ khoá đúng là Export.

• C (dùng Fn::Transform) — dùng để gọi macro hoặc AWS::Include (chèn đoạn template từ S3). Không liên quan tới chia sẻ giá trị giữa các stack.

Xem thêm câu #11668: cùng cơ chế nhưng hỏi cả cặp hai bước (Export ở stack nguồn, Fn::ImportValue ở stack đích), với bẫy là dùng Ref thay cho ImportValue.

Ghi nhớ

⚠ Ba cách chia sẻ giá trị giữa các stack — bảng phải thuộc: | Cách | Đặc điểm | |---|---| | Export + Fn::ImportValue | gốc của CloudFormation — tạo ràng buộc cứng, cùng tài khoản và Region | | SSM Parameter Store | linh hoạt nhất — chéo Region được, không ràng buộc cứng | | Nested stack | stack cha truyền tham số cho stack con qua Parameters |

Từ khoá nhận diện:

"cung cấp giá trị cho stack khác" → Export trong Outputs "nhận giá trị từ stack khác" → Fn::ImportValue "chia sẻ chéo Region hoặc chéo tài khoản" → SSM Parameter Store "không xoá được stack" → đang có export bị stack khác dùng "chèn đoạn template dùng chung" → Fn::Transform với AWS::Include

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có những export nào | list-exports | | Ai đang dùng một export | list-imports --export-name <ten> | | Vì sao không xoá được stack | thông báo lỗi sẽ nêu đích danh export đang bị dùng |

Và một quy ước đặt tên đáng áp dụng ngay từ template đầu tiên: luôn đặt tiền tố tên stack cho mọi export (!Sub "${AWS::StackName}-IdSubnet"). Tên export phải duy nhất trong cả tài khoản và Region, nên một export tên "SubnetId" trần trụi sẽ chặn mọi stack khác dùng cái tên hiển nhiên đó — và bạn chỉ phát hiện ra điều này vào lúc triển khai môi trường thứ hai, khi mọi thứ đã xong xuôi.

Đáp án

C — Reboot (khởi động lại) Spot Instance KHÔNG cấu hình được làm hành vi khi bị thu hồi.

Vì sao đúng

Hiểu bản chất của việc thu hồi Spot là hiểu ngay vì sao reboot vô nghĩa ở đây.

⚠ Điểm mấu chốt — AWS thu hồi Spot vì AWS CẦN LẠI PHẦN CỨNG:

AWS cần máy vật lý đó cho khách hàng On-Demand
        ↓
    → instance của bạn phải RỜI KHỎI máy vật lý đó
        ↓
    Reboot = máy khởi động lại rồi CHẠY TIẾP TRÊN CÙNG HOST
        ↓
    → không giải phóng được phần cứng
    → hoàn toàn trái mục đích của việc thu hồi
        ↓
    → AWS không cung cấp lựa chọn này

⚠ Ba hành vi thu hồi hợp lệ:

⚠ Điều kiện của stop và hibernate — không phải lúc nào cũng dùng được:

Cả hai đòi:
    - ổ gốc phải là EBS (không phải instance store)
    - dùng persistent Spot request, không phải one-time
    - hibernate còn cần: loại instance và AMI hỗ trợ,
      RAM dưới 150 GB, ổ gốc phải MÃ HOÁ và đủ chỗ chứa RAM

⚠ Và điều quan trọng nhất về mặt vận hành — cảnh báo hai phút:

Trước khi thu hồi, AWS gửi cảnh báo trước 2 PHÚT
        ↓
    Đọc qua metadata:
      http://169.254.169.254/latest/meta-data/spot/instance-action
    Hoặc bắt qua EventBridge:
      "EC2 Spot Instance Interruption Warning"
        ↓
    → 2 phút để lưu tiến độ, rút khỏi load balancer,
      hoàn tất công việc đang dở

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

(Ba phương án còn lại đều là hành vi hợp lệ, nên không phải đáp án.)

• A (hibernate) — đây là phương án gần nhất vì nó nghe "lạ" nhất, nhưng hoàn toàn có thật: RAM được lưu xuống ổ gốc đã mã hoá, và khi có dung lượng trở lại thì máy khôi phục đúng trạng thái cũ.

• B (terminate) — hành vi mặc định.

• D (stop) — hợp lệ với persistent Spot request và ổ gốc EBS.

Ghi nhớ

⚠ Ba hành vi thu hồi Spot — bảng phải thuộc: | Hành vi | Dữ liệu EBS | RAM | Điều kiện | |---|---|---|---| | terminate | mất (nếu DeleteOnTermination) | mất | mặc định, luôn dùng được | | stop | còn | mất | ổ gốc EBS + persistent request | | hibernate | còn | CÒN | thêm: AMI/loại máy hỗ trợ, ổ gốc mã hoá, RAM < 150 GB | | reboot | — | — | KHÔNG TỒN TẠI |

Từ khoá nhận diện:

"reboot khi thu hồi Spot" → KHÔNG TỒN TẠI "giữ trạng thái RAM khi bị thu hồi" → hibernate "giữ dữ liệu đĩa, chạy lại sau" → stop "cảnh báo trước khi bị thu hồi" → 2 phút, qua metadata hoặc EventBridge "giảm xác suất bị thu hồi" → nhiều loại instance + capacity-optimized

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hành vi hiện tại là gì | describe-spot-instance-requests, xem InstanceInterruptionBehavior | | Loại nào ít bị thu hồi | Spot Instance Advisor — xem tần suất thu hồi | | Đã bị thu hồi bao nhiêu lần | EventBridge sự kiện EC2 Spot Instance Interruption Warning |

Và một lời khuyên khi thiết kế cho Spot: hãy giả định máy có thể biến mất bất cứ lúc nào, và đừng trông cậy vào hai phút cảnh báo như một đảm bảo. Cảnh báo đó là nỗ lực tốt nhất của AWS chứ không phải một hợp đồng — trong một số tình huống hiếm, instance có thể bị thu hồi mà không kịp gửi thông báo. Kiến trúc đúng cho Spot là kiến trúc mà mất một máy giữa chừng không cần ai phải làm gì cả.

Đáp án

D — 'x-amz-server-side-encryption': 'aws:kms'

Vì sao đúng

Đây là câu hỏi về giá trị chính xác của header, và S3 rất khắt khe: chỉ chấp nhận đúng hai giá trị.

⚠ Điểm mấu chốt — hai giá trị hợp lệ duy nhất:

x-amz-server-side-encryption: AES256    → SSE-S3
x-amz-server-side-encryption: aws:kms   → SSE-KMS  ← đáp án
        ↓
    Mọi giá trị khác ("SSE-KMS", "SSE-S3", "kms"...)
        ↓
    → S3 TỪ CHỐI request

Điểm dễ nhầm nhất: "SSE-KMS" là TÊN GỌI của cơ chế, còn "aws:kms" là GIÁ TRỊ trong header — chúng không giống nhau.

⚠ Ví dụ đầy đủ:

aws s3api put-object \
  --bucket bucket-cua-toi --key du-lieu.json --body du-lieu.json \
  --server-side-encryption aws:kms \
  --ssekms-key-id arn:aws:kms:ap-southeast-1:111122223333:key/xxxx

Trong HTTP thuần:

PUT /du-lieu.json HTTP/1.1
Host: bucket-cua-toi.s3.ap-southeast-1.amazonaws.com
x-amz-server-side-encryption: aws:kms
x-amz-server-side-encryption-aws-kms-key-id: arn:aws:kms:...:key/xxxx

⚠ Đề nói lỗi là "permission error" — và đó là manh mối thứ hai:

Header sai → S3 trả lỗi về tham số
Header đúng nhưng thiếu quyền KMS → AccessDenied
        ↓
    Ghi bằng SSE-KMS cần CẢ HAI quyền:
        s3:PutObject                  (trên bucket)
        kms:GenerateDataKey           (trên khoá)  ← rất hay thiếu
        kms:Decrypt                   (để đọc lại)
        ↓
    → sửa header xong mà vẫn AccessDenied
      thì phải xem KEY POLICY

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

• C ('SSE-KMS') — đây là phương án gần nhất và là bẫy chính: nó dùng tên gọi của cơ chế làm giá trị header. S3 không chấp nhận.

• A ('SSE-S3') — sai cả hai mặt: đó không phải giá trị hợp lệ, và nó cũng chỉ về cơ chế khác với yêu cầu của đề.

• B ('AES256') — giá trị hợp lệ, nhưng nó chỉ định SSE-S3, không phải SSE-KMS mà đội phát triển cần.

Ghi nhớ

⚠ Các header mã hoá của S3 — bảng phải thuộc: | Header | Giá trị | |---|---| | x-amz-server-side-encryption | AES256 (SSE-S3) hoặc aws:kms (SSE-KMS) | | x-amz-server-side-encryption-aws-kms-key-id | ARN hoặc id của CMK — thiếu thì dùng khoá aws/s3 | | x-amz-server-side-encryption-context | encryption context bổ sung | | x-amz-server-side-encryption-bucket-key-enabled | bật S3 Bucket Key cho request đó | | x-amz-server-side-encryption-customer-* | dành cho SSE-C (thuật toán, khoá, MD5 của khoá) |

Từ khoá nhận diện:

"SSE-KMS trong header" → aws:kms "SSE-S3 trong header" → AES256 "giá trị header là SSE-KMS" → LUÔN SAI "AccessDenied dù header đúng" → thiếu quyền KMS "ép mọi tệp phải mã hoá" → bucket policy với s3:x-amz-server-side-encryption

⚠ Quyền cần có khi dùng SSE-KMS — nguồn gốc của phần lớn lỗi AccessDenied: | Thao tác | Quyền cần | |---|---| | Ghi (PutObject) | s3:PutObject + kms:GenerateDataKey | | Đọc (GetObject) | s3:GetObject + kms:Decrypt | | Cả hai | thêm kms:DescribeKey | | Quyền phải có ở | CẢ chính sách IAM LẪN key policy |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đối tượng mã hoá kiểu gì | head-object, xem ServerSideEncryption và SSEKMSKeyId | | Vì sao AccessDenied | CloudTrail — xem lời gọi thất bại là s3 hay kms | | Key policy có đủ không | get-key-policy, tìm principal của ứng dụng |

Và một mẹo chẩn đoán tiết kiệm rất nhiều thời gian: khi gặp AccessDenied với SSE-KMS, hãy xem CloudTrail để biết dịch vụ nào từ chối — s3.amazonaws.com hay kms.amazonaws.com. Thông báo lỗi trả về cho client giống hệt nhau trong cả hai trường hợp, nên rất nhiều giờ bị tiêu vào việc sửa đi sửa lại bucket policy trong khi thứ thiếu thật ra là một dòng kms:GenerateDataKey trong key policy.

Đáp án

C — Tạo CloudWatch Alarm cho CPU của instance với DETAILED MONITORING bật, và cấu hình hành động restart khi alarm kích hoạt.

Vì sao đúng

Đề có một cụm từ quyết định: "khởi động lại NGAY KHI CÓ DẤU HIỆU ĐẦU TIÊN". Đó là yêu cầu về tốc độ phát hiện, và nó loại bỏ basic monitoring.

⚠ Điểm mấu chốt — basic monitoring quá chậm cho yêu cầu này:

Basic monitoring: 5 PHÚT một điểm dữ liệu
        ↓
    Alarm cần vài chu kỳ để chắc chắn
        ↓
    → 10–15 phút mới phát hiện
    → máy đã treo suốt thời gian đó

Detailed monitoring: 1 PHÚT một điểm
        ↓
    → 2–3 phút đã kích hoạt
    → đúng tinh thần "dấu hiệu đầu tiên"

⚠ Và EC2 action là cơ chế dựng sẵn, không cần viết mã:

CloudWatch Alarm → EC2 action:
        arn:aws:automate:<region>:ec2:reboot
        ↓
    → không cần Lambda
    → không cần IAM role riêng
    → không cần bảo trì mã nguồn

aws cloudwatch put-metric-alarm \
  --alarm-name ung-dung-treo \
  --namespace AWS/EC2 --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-xxxxxxxx \
  --statistic Average --period 60 --evaluation-periods 3 \
  --threshold 95 --comparison-operator GreaterThanThreshold \
  --alarm-actions arn:aws:automate:ap-southeast-1:ec2:reboot

Xem thêm câu #11609: cùng cơ chế alarm + EC2 reboot action, nhưng ở đó bẫy nằm ở chỗ khác — phân biệt CloudWatch Alarm (theo ngưỡng chỉ số) với CloudWatch Events (theo sự kiện).

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

• A (CPU là chỉ số dựng sẵn có trong basic monitoring, cấu hình restart action trên đó) — đây là phương án gần nhất và hai vế đầu hoàn toàn đúng: CPU đúng là chỉ số dựng sẵn, và basic monitoring đúng là có nó. Nhưng độ phân giải 5 phút quá chậm cho yêu cầu "dấu hiệu đầu tiên", và câu này còn thiếu bước tạo alarm — restart action phải gắn vào một alarm, không gắn thẳng vào chỉ số.

• B (alarm với basic monitoring + Lambda để restart) — vừa chậm (basic monitoring), vừa thừa: EC2 action đã làm được việc đó mà không cần Lambda nào.

• D (viết mã tuỳ chỉnh để gửi CPU lên CloudWatch) — hoàn toàn thừa: CPU là chỉ số AWS đã cấp sẵn. Tự đẩy lại nghĩa là tự viết mã, tự trả phí PutMetricData, và tự tạo thêm một chỗ có thể hỏng.

Ghi nhớ

⚠ Hai mức giám sát của EC2 — bảng phải thuộc: | Mức | Chu kỳ | Chi phí | |---|---|---| | Basic monitoring | 5 phút | miễn phí | | Detailed monitoring | 1 phút | có phí, tính theo instance |

Từ khoá nhận diện:

"phản ứng nhanh, dấu hiệu đầu tiên" → detailed monitoring "chỉ số EC2 mỗi 1 phút" → detailed monitoring "tự khởi động lại máy treo" → alarm + EC2 reboot action "tự viết mã đẩy CPU lên CloudWatch" → thừa, CPU có sẵn "RAM, dung lượng đĩa" → CloudWatch agent (detailed monitoring không cho hai thứ này)

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã bật detailed monitoring chưa | describe-instances, xem Monitoring.State | | Alarm có kích hoạt đúng lúc không | describe-alarm-history | | Reboot có thật sự chạy không | CloudTrail sự kiện RebootInstances |

Và một lời nhắc về bản chất của giải pháp tạm này: hãy đảm bảo mỗi lần máy tự khởi động lại đều có một thông báo gửi tới đội trực. Đề nói bản vá thật sẽ mất vài tuần, và trong vài tuần đó bạn cần biết lỗi xảy ra bao nhiêu lần mỗi ngày — nếu không, cơ chế tự phục hồi này sẽ lặng lẽ che giấu mức độ nghiêm trọng của vấn đề, và "vài tuần" rất dễ trở thành vài tháng.

Đáp án

A — Đặt máy chủ ứng dụng ở public subnet và cơ sở dữ liệu ở private subnet. Public subnet ra internet qua Internet Gateway; cơ sở dữ liệu ở private subnet ra internet qua NAT Gateway đặt trong public subnet.

Vì sao đúng

Đề nêu ba yêu cầu, và phương án A giải quyết đúng cả ba bằng đúng công cụ:

⚠ Điểm mấu chốt — NAT Gateway cho ra mà không cho vào:

NAT Gateway đặt ở PUBLIC subnet (có tuyến tới IGW)
        ↓
    Route table của PRIVATE subnet:
        0.0.0.0/0 → nat-xxxxxxxx
        ↓
    → RDS RA được internet (tải bản vá)
    → nhưng KHÔNG AI từ internet vào được RDS
        ↓
    → thoả cả hai yêu cầu tưởng như mâu thuẫn

⚠ Và ứng dụng nối tới cơ sở dữ liệu bằng gì:

Cả hai subnet cùng một VPC
        ↓
    Tuyến "local" tự có, KHÔNG XOÁ ĐƯỢC
        ↓
    → không cần peering, không cần gateway nào
    → chỉ cần Security Group của RDS cho phép
      SG của ứng dụng ở cổng 3306/5432

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

Đề nói "RDS cần truy cập internet để tải bản vá hằng tháng" — điều này không đúng với cách RDS hoạt động thực tế:

RDS là dịch vụ ĐƯỢC QUẢN LÝ
        ↓
    AWS tự vá công cụ cơ sở dữ liệu và hệ điều hành bên dưới
    trong maintenance window
        ↓
    → việc vá diễn ra ở HẠ TẦNG CỦA AWS
    → KHÔNG cần RDS instance của bạn có đường ra internet
        ↓
    → RDS ở private subnet không có NAT vẫn được vá bình thường

Khoá đáp án vẫn giữ nguyên vì trong bốn phương án, A là phương án duy nhất mô tả đúng kiến trúc mạng (private subnet + NAT Gateway cho lưu lượng đi ra). Nguyên lý mà câu hỏi kiểm tra — đặt tài nguyên nhạy cảm ở private subnet và cho nó ra ngoài qua NAT — hoàn toàn đúng; chỉ có ví dụ minh hoạ (RDS tải bản vá) là chọn nhầm dịch vụ. Với EC2 thì lý do đó chính xác tuyệt đối.

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

• B (cấu hình NAT Gateway cho CẢ HAI subnet, route table của cả hai đều trỏ tới NAT) — đây là phương án gần nhất và sai ở một chỗ chí mạng: nếu public subnet cũng trỏ 0.0.0.0/0 vào NAT, nó không còn là public subnet — máy chủ ứng dụng mất đường vào từ internet, và chính NAT Gateway cũng mất đường ra vì nó nằm trong subnet đó.

• C (dùng VPC peering giữa private subnet và public subnet) — hiểu sai khái niệm: VPC peering nối hai VPC, không nối hai subnet. Các subnet trong cùng một VPC đã thông với nhau sẵn.

• D (private subnet ra internet được nếu cấu hình IPv6) — sai: với IPv6, thứ cho ra internet mà chặn chiều vào là Egress-Only Internet Gateway, và bản thân IPv6 không tự cho phép hay tự chặn gì cả.

Ghi nhớ

⚠ Kiến trúc ba tầng chuẩn trên AWS — bảng phải thuộc: | Tầng | Vị trí | Ra internet bằng | |---|---|---| | Load balancer | public subnet, nhiều AZ | Internet Gateway | | Ứng dụng (EC2/ASG) | private subnet | NAT Gateway | | Cơ sở dữ liệu (RDS) | private subnet | thường KHÔNG cần ra internet |

Từ khoá nhận diện:

"private subnet ra internet, IPv4" → NAT Gateway "private subnet ra internet, IPv6" → Egress-Only IGW "public subnet trỏ vào NAT" → LUÔN SAI, phải trỏ vào IGW "peering giữa hai subnet" → KHÔNG TỒN TẠI, peering là giữa hai VPC "RDS không được lộ ra internet" → PubliclyAccessible: false + private subnet

Ba việc kiểm chứng: | Việc | Cách | |---|---| | RDS có lộ ra ngoài không | describe-db-instances, xem PubliclyAccessible | | Route table đúng chưa | private → NAT, public → IGW | | Ứng dụng nối được chưa | telnet <endpoint> 3306 từ máy ứng dụng |

Và một lời khuyên rút từ chính chỗ chưa chuẩn của đề bài: đừng cấp NAT Gateway cho subnet chỉ chứa RDS. RDS được AWS vá hộ và không cần đường ra internet, nên một NAT Gateway đặt ở đó là một khoản phí theo giờ trả suốt đời cho một nhu cầu không tồn tại — hãy dành NAT cho subnet chứa EC2, nơi việc tải gói phần mềm là chuyện có thật.

Đáp án

C — SSE-S3.

Vì sao đúng

Đề nêu hai yêu cầu, và cả hai đều chỉ thẳng về SSE-S3:

⚠ Điểm mấu chốt — SSE-S3 là mã hoá "không cần làm gì cả":

Bật Default Encryption với SSE-S3
        ↓
    S3 tự sinh khoá, tự xoay khoá, tự quản lý hoàn toàn
        ↓
    → không có khoá nào trong tài khoản bạn để quản
    → không có chi phí nào thêm
    → không có hạn mức lời gọi nào phải lo
        ↓
    Header: x-amz-server-side-encryption: AES256

⚠ Vì sao KHÔNG chọn SSE-KMS ở đây — đây là chỗ dễ chọn sai:

SSE-KMS cũng dùng AES-256 để mã hoá dữ liệu
        ↓
    Nhưng nó đưa vào MỘT KHOÁ trong tài khoản bạn
        ↓
    → có key policy phải viết
    → có quyết định xoay khoá phải ra
    → có chi phí và hạn mức lời gọi phải theo dõi
        ↓
    → tức là CÓ việc quản lý khoá
        ↓
    Đề nói rõ: KHÔNG muốn quản lý khoá → SSE-S3

Xem thêm câu #11655: cùng bài toán chọn kiểu mã hoá S3 nhưng đáp án là SSE-KMS, vì đề ở đó yêu cầu thêm nhật ký kiểm toán ai đã dùng khoá và khi nào — thứ mà SSE-S3 không có. Hai câu không mâu thuẫn: yêu cầu khác nhau thì đáp án khác nhau.

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

• D (SSE-KMS) — đây là phương án gần nhất và cũng cho mã hoá AES-256. Nhưng nó đòi bạn có và quản lý một khoá KMS, trái với yêu cầu rõ ràng của đề. (Nếu đề có thêm chữ "cần kiểm toán" thì đáp án lại đảo ngược.)

• A (SSE-C) — khách hàng phải gửi khoá theo từng request, tức là bạn tự quản lý và tự lưu trữ khoá — trái thẳng yêu cầu.

• B (Client Side Encryption) — nhiều việc nhất: tự mã hoá trước khi gửi, tự lưu khoá, tự lo xoay khoá.

Ghi nhớ

⚠ Chọn kiểu mã hoá S3 theo yêu cầu — bảng phải thuộc: | Yêu cầu của đề | Đáp án | |---|---| | "đơn giản, không quản khoá" | SSE-S3 | | "cần nhật ký ai dùng khoá" | SSE-KMS | | "cần kiểm soát ai được dùng khoá" | SSE-KMS (key policy) | | "tự giữ khoá hoàn toàn" | SSE-C hoặc client-side | | "mã hoá hai lớp, tuân thủ khắt khe" | DSSE-KMS | | "khoá phải trong HSM riêng" | CloudHSM / External Key Store |

Từ khoá nhận diện:

"AES-256, không quản khoá" → SSE-S3 "audit trail cho khoá" → SSE-KMS "gửi khoá theo mỗi request" → SSE-C "header AES256" → SSE-S3 "header aws:kms" → SSE-KMS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bucket dùng loại nào | get-bucket-encryption | | Một tệp cụ thể ra sao | head-object, xem ServerSideEncryption | | Còn tệp cũ chưa mã hoá không | S3 Inventory báo cáo trạng thái mã hoá của mọi đối tượng |

Và một lời khuyên khi lập kế hoạch tuân thủ: hãy dùng S3 Inventory để biết chính xác bao nhiêu đối tượng đang chưa mã hoá trước khi hứa hẹn gì với bộ phận kiểm toán. Bật Default Encryption chỉ mất một phút và giải quyết mọi tệp từ nay về sau; phần khó, tốn thời gian và tốn tiền luôn nằm ở khối dữ liệu cũ đã tích tụ từ trước — và con số đó thường lớn hơn nhiều so với ước lượng ban đầu.

Đáp án

A — Gắn một tag chung cho mỗi bucket, kích hoạt tag đó làm cost allocation tag, rồi dùng Cost Explorer tạo báo cáo chi phí theo tag.

Vì sao đúng

Đề hỏi chi phí của TỪNG BUCKET riêng lẻ, và mặc định thì AWS không cho bạn con số đó.

⚠ Điểm mấu chốt — hoá đơn S3 gộp chung cả tài khoản:

Mặc định, Cost Explorer chỉ cho biết:
    "S3 tốn 5.000 đô tháng này"
        ↓
    → KHÔNG biết bucket nào tốn bao nhiêu
        ↓
    Muốn tách ra thì phải GẮN TAG cho từng bucket
    rồi KÍCH HOẠT tag đó

⚠ Quy trình ba bước, và bước hai là chỗ hay bị bỏ sót:

1. Gắn tag cho mỗi bucket
       Bucket = kho-video, Bucket = kho-anh, Bucket = log
        ↓
2. KÍCH HOẠT tag làm cost allocation tag
       Billing console → Cost allocation tags → Activate
        ↓
   ⚠ Bỏ bước này thì tag KHÔNG BAO GIỜ hiện trong báo cáo chi phí
        ↓
3. Cost Explorer → Group by → Tag: Bucket
        ↓
    → thấy chi phí tách theo từng bucket

⚠ Và với bài toán cụ thể của đề — quyết định về lưu trữ và xoá dữ liệu — có một công cụ bổ trợ rất mạnh:

S3 Storage Lens (miễn phí ở mức dashboard mặc định)
        ↓
    Cho biết theo TỪNG BUCKET:
        - dung lượng, số đối tượng, kích thước trung bình
        - phân bố theo LỚP LƯU TRỮ
        - bao nhiêu dung lượng là PHIÊN BẢN CŨ
        - multipart upload dang dở chưa dọn
        ↓
    → đây mới là dữ liệu để quyết định lifecycle policy
    → Cost Explorer cho biết TỐN BAO NHIÊU,
      Storage Lens cho biết TỐN VÌ CÁI GÌ

Xem thêm câu #11590 và #11636: cùng cơ chế cost allocation tag, áp cho Elastic IP và cho phòng ban. Ba câu cùng một nguyên lý: muốn tách chi phí theo chiều nào thì gắn tag theo chiều đó rồi kích hoạt.

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

• B (dùng AWS Budgets để xem chi phí từng bucket) — đây là phương án gần nhất vì Budgets đúng là công cụ tài chính. Nhưng nó dùng để đặt ngưỡng ngân sách và gửi cảnh báo khi sắp vượt, không phải để phân tích và báo cáo. (Budgets cũng lọc theo tag được — nhưng vẫn cần bước kích hoạt tag, và công cụ để "tạo báo cáo" là Cost Explorer.)

• D (dùng Trusted Advisor) — đưa ra khuyến nghị tối ưu chung, ví dụ "bucket này chưa bật lifecycle policy". Nó không cho con số chi phí theo từng bucket.

• C (dùng AWS Simple Monthly Calculator) — công cụ ước tính chi phí TRƯỚC khi dùng (và nay đã được thay bằng AWS Pricing Calculator). Nó không biết gì về mức sử dụng thực tế của bạn.

Ghi nhớ

⚠ Bộ công cụ chi phí — bảng phải thuộc: | Công cụ | Việc | |---|---| | Cost Explorer | phân tích và báo cáo chi phí đã phát sinh | | AWS Budgets | đặt ngưỡng và cảnh báo | | Cost and Usage Report (CUR) | dữ liệu thô, chi tiết nhất, đổ vào S3 | | Cost Anomaly Detection | phát hiện chi phí tăng bất thường | | Pricing Calculator | ước tính TRƯỚC khi dùng | | S3 Storage Lens | phân tích mức dùng S3 theo bucket |

Từ khoá nhận diện:

"chi phí theo từng bucket / phòng ban / dự án" → cost allocation tag + Cost Explorer "cảnh báo khi vượt ngân sách" → Budgets "ước tính trước khi triển khai" → Pricing Calculator "bucket nào chứa gì, phiên bản cũ chiếm bao nhiêu" → S3 Storage Lens "danh sách chi tiết mọi đối tượng" → S3 Inventory

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tag đã kích hoạt chưa | Billing console → Cost allocation tags | | Bucket nào chưa gắn tag | get-bucket-tagging cho từng bucket, hoặc Tag Editor | | Dung lượng thật của bucket | Storage Lens, hoặc chỉ số BucketSizeBytes (nhớ chọn đúng storage type) |

Và một lời khuyên rất thực dụng cho công ty trong đề: hãy mở S3 Storage Lens trước khi làm bất cứ điều gì khác — nó miễn phí và thường trả lời được câu hỏi ngay trong buổi đầu tiên. Chi phí S3 tăng dần theo thời gian gần như luôn có cùng một thủ phạm: phiên bản cũ và multipart upload dang dở tích tụ trong im lặng, không hiện ra ở bất kỳ danh sách tệp nào, và không có sự cố nào xảy ra để nhắc ai đó đi tìm.