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

Đáp án

C — Chuyển dữ liệu tại chỗ vào nhiều thiết bị Snowball Edge Storage Optimized, đưa dữ liệu từ Snowball vào Amazon S3, rồi tạo lifecycle policy để chuyển tiếp sang Glacier.

Vì sao đúng

Đề có hai ràng buộc: 5 PB dữ liệu và "tối ưu chi phí nhất". Phải giải quyết cả hai.

⚠ Ràng buộc thứ nhất — 5 PB không truyền qua đường mạng được:

Giả sử có đường truyền 1 Gbps DÀNH RIÊNG, chạy 100% công suất
        ↓
    5 PB ÷ (1 Gbps) ≈ hơn 460 NGÀY
        ↓
    → hơn một năm, và chiếm trọn đường truyền
        ↓
    → phải chuyển bằng THIẾT BỊ VẬT LÝ

Snowball Edge Storage Optimized chứa khoảng 80 TB dùng được mỗi thiết bị, nên 5 PB cần vài chục thiết bị chạy song song — vài tuần thay vì hơn một năm.

⚠ Ràng buộc thứ hai — Snowball CHỈ đổ được vào S3, không đổ thẳng vào Glacier:

Snowball Edge nhập dữ liệu
        ↓
    Đích duy nhất: một bucket Amazon S3
        ↓
    → muốn vào Glacier thì phải qua bước thứ hai
        ↓
    Lifecycle policy chuyển sang Glacier / Glacier Deep Archive
        ↓
    → tự động, không tốn phí yêu cầu như copy tay

Quy tắc lifecycle rất gọn:

{
  "Rules": [{
    "Status": "Enabled",
    "Filter": {"Prefix": ""},
    "Transitions": [{
      "Days": 0,
      "StorageClass": "DEEP_ARCHIVE"
    }]
  }]
}

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

• A (Snowball rồi copy dữ liệu từ Snowball vào Glacier) — đây là phương án gần nhất và chỉ sai một chi tiết: Snowball không nhập thẳng vào Glacier được, đích của nó luôn là S3. Chi tiết nhỏ này chính là thứ câu hỏi muốn kiểm tra.

• B (dựng Direct Connect rồi truyền qua đó) — Direct Connect là đường truyền tốt, nhưng với 5 PB thì vẫn quá chậm, và phải trả phí cổng cộng phí truyền trong suốt nhiều tháng. Đề hỏi cách tối ưu chi phí nhất — đây là phương án đắt hơn hẳn.

• D (VPN Site-to-Site) — tệ hơn nữa: VPN đi qua internet công cộng, giới hạn khoảng 1,25 Gbps mỗi tunnel, và độ ổn định kém hơn Direct Connect.

Xem thêm câu #11617: cũng 5 PB dữ liệu tại chỗ và cũng dùng Snowball, nhưng mục đích là phân tích sau khi làm sạch — khi đó điểm nhấn là Snowball Edge Compute Optimized chạy được EC2 ngay trên thiết bị.

Ghi nhớ

⚠ Chọn cách di chuyển dữ liệu theo khối lượng — bảng phải thuộc: | Khối lượng | Cách | |---|---| | Vài GB tới vài TB | internet + AWS CLI / S3 Transfer Acceleration | | Vài TB tới vài chục TB, đều đặn | DataSync qua Direct Connect hoặc VPN | | Vài chục TB tới hàng PB | Snowball Edge | | Trên 10 PB | Snowmobile (xe container) | | Lai, dùng lâu dài | Storage Gateway |

Từ khoá nhận diện:

"hàng PB, một lần" → Snowball Edge "Snowball đổ thẳng vào Glacier" → LUÔN SAI, chỉ vào S3 "đồng bộ định kỳ tại chỗ ↔ AWS" → DataSync "lưu trữ dài hạn rẻ nhất" → Glacier Deep Archive "cần đường truyền ổn định lâu dài" → Direct Connect

⚠ Các lớp lưu trữ archive của S3 — bảng phải thuộc: | Lớp | Thời gian lấy lại | Giá | |---|---|---| | Glacier Instant Retrieval | mili giây | rẻ hơn Standard-IA | | Glacier Flexible Retrieval | phút tới 5–12 giờ | rẻ hơn nữa | | Glacier Deep Archive | 12–48 giờ | rẻ nhất |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu đã sang lớp mới chưa | head-object, xem StorageClass | | Lifecycle có chạy không | S3 đánh giá mỗi ngày một lần | | Chi phí thực tế | Cost Explorer, tách theo usage type |

Và một lời khuyên quan trọng trước khi archive: hãy tính trước cả chi phí LẤY LẠI, không chỉ chi phí lưu trữ. Deep Archive rẻ tới mức khó tin khi cất, nhưng lấy 5 PB ra khỏi nó là một khoản tiền lớn cộng với nhiều ngày chờ đợi. Nếu có khả năng dữ liệu sẽ được truy vấn — dù chỉ một phần nhỏ — thì hãy giữ phần đó ở lớp truy cập nhanh hơn, thay vì phải giải thích với ban giám đốc vì sao "kho lưu trữ giá rẻ" lại sinh ra một hoá đơn khôi phục sáu chữ số.

Đáp án

A — Bật Amazon S3 Server Access Logging cho các bucket quan trọng và lưu log sang một bucket khác để phân tích.

Vì sao đúng

Đề nhấn mạnh "tiết kiệm chi phí, không phát sinh thêm tiền" — và đó chính là điểm phân biệt.

⚠ Điểm mấu chốt: Server Access Logging MIỄN PHÍ, chỉ trả tiền lưu trữ log:

S3 Server Access Logging
        ↓
    Không tính phí cho tính năng
    Chỉ trả tiền cho dung lượng log lưu trong S3
        ↓
    → đúng yêu cầu "không phát sinh thêm chi phí"

Cấu hình rất đơn giản, và có một quy tắc bắt buộc:

Bucket nguồn: bucket-tai-lieu-quan-trong
Bucket đích:  bucket-luu-log          ← PHẢI là bucket KHÁC
        ↓
    Nếu ghi log vào chính bucket nguồn
        ↓
    → mỗi bản ghi log lại tạo ra một bản ghi log mới
    → VÒNG LẶP VÔ TẬN, hoá đơn tăng không giới hạn

⚠ Log ghi lại gì:

Đánh đổi cần biết: log giao "best effort" và có thể trễ vài giờ. Đủ cho kiểm toán và điều tra sau sự cố — không đủ cho cảnh báo tức thì.

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

• D (dùng CloudTrail để nhận diện các request tới bucket) — đây là phương án gần nhất và về chức năng thì tốt hơn: CloudTrail data event ghi chi tiết hơn, gần thời gian thực, tích hợp với EventBridge. Nhưng CloudTrail data event có phí riêng theo số sự kiện, và với một bucket bận rộn thì đó là khoản tiền đáng kể. Đề nói rõ startup nhỏ cần cách không tốn thêm — nên đáp án là Server Access Logging.

• B (dùng X-Ray để truy vết request tới S3) — X-Ray truy vết hành trình request bên trong ứng dụng của bạn; nó không phải công cụ kiểm toán truy cập S3, và chỉ thấy những lời gọi đi qua ứng dụng có gắn SDK.

• C (dùng Amazon Inspector để theo dõi lời gọi tới dịch vụ) — mô tả sai công dụng: Inspector quét lỗ hổng bảo mật của EC2, container và Lambda. Nó không ghi lại lời gọi API nào.

Xem thêm câu #11602: cùng công cụ này nhưng hỏi ở góc điều tra — dùng access log để phát hiện nhân viên thử truy cập tệp không có quyền, mà họ không nhận ra.

Ghi nhớ

⚠ Hai cách ghi nhật ký truy cập S3 — bảng phải thuộc: | | Server Access Logging | CloudTrail Data Events | |---|---|---| | Chi phí | miễn phí (trả tiền lưu trữ log) | có phí theo sự kiện | | Độ trễ | vài giờ, best effort | gần thời gian thực | | Đích | bucket S3 khác | CloudTrail, CloudWatch Logs, S3 | | Tích hợp cảnh báo | không sẵn | EventBridge, CloudWatch Alarm | | Trường dữ liệu | chi tiết về HTTP và hiệu năng | chi tiết về identity và IAM |

Từ khoá nhận diện:

"theo dõi truy cập S3, rẻ nhất" → Server Access Logging "cần gần thời gian thực, cần cảnh báo" → CloudTrail data event "ai gọi API quản trị (tạo/xoá bucket)" → CloudTrail management event — MIỄN PHÍ "quét lỗ hổng" → Inspector "phân tích log S3 bằng SQL" → Amazon Athena

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã bật chưa | get-bucket-logging --bucket <ten> | | Log có tới không | xem bucket đích — có thể chờ vài giờ mới thấy tệp đầu tiên | | Log có đầy đủ không | best effort — không đảm bảo 100% mọi request |

Và một cảnh báo cho cả hai lựa chọn: hãy đặt lifecycle policy cho bucket chứa log ngay từ ngày bật. Log truy cập của một bucket bận rộn lớn nhanh một cách đáng ngạc nhiên, và vì không ai nhìn vào bucket log trong lúc mọi thứ đang chạy tốt, chuyện thường thấy là vài năm sau có người phát hiện ra rằng bản thân đống log đang tốn nhiều tiền hơn cả dữ liệu mà nó ghi lại.

Đáp án

C — Bạn có thể đưa một tài nguyên đang có vào cho AWS CloudFormation quản lý bằng RESOURCE IMPORT.

Vì sao đúng

Resource import sinh ra đúng cho tình huống của đề: tài nguyên đã tồn tại và đang chạy, giờ muốn CloudFormation quản lý mà không được đụng gì tới nó.

⚠ Điểm mấu chốt — import KHÔNG tạo mới và KHÔNG gián đoạn tài nguyên đang chạy:

Tài nguyên đang chạy (tạo bằng tay)
        ↓
    Thêm nó vào template với đầy đủ thuộc tính hiện tại
        ↓
    Tạo change set kiểu IMPORT, khai định danh tài nguyên
        ↓
    CloudFormation chỉ GHI NHẬN quyền quản lý
        ↓
    → tài nguyên KHÔNG bị tạo lại, KHÔNG gián đoạn
    → từ nay cập nhật qua template

⚠ Ba việc phải chuẩn bị trước khi import:

1. Template phải mô tả tài nguyên KHỚP với thực tế
        → sai một thuộc tính là import thất bại hoặc lệch trạng thái
2. Mỗi tài nguyên cần một ĐỊNH DANH duy nhất
        → tên bucket, instance id, tên bảng DynamoDB...
3. Nên đặt DeletionPolicy: Retain trước khi import
        → lỡ có sự cố thì tài nguyên thật không bị xoá

⚠ Sau khi import, việc bắt buộc tiếp theo là DRIFT DETECTION:

Chạy drift detection ngay sau khi import
        ↓
    → xác nhận template khớp với tài nguyên thật
        ↓
    Nếu lệch → sửa template cho khớp
        ↓
    → nếu bỏ qua bước này, lần update stack sau
      CloudFormation có thể "sửa lại" tài nguyên theo template SAI

Import làm được với hai tình huống: thêm tài nguyên vào stack đang có, hoặc tạo một stack mới hoàn toàn từ tài nguyên có sẵn.

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

• A (drift detection là cơ chế thêm tài nguyên vào stack) — đây là phương án gần nhất vì drift detection có thật và có liên quan tới quy trình này. Nhưng nó chỉ PHÁT HIỆN chênh lệch giữa template và tài nguyên thật, nó không thêm được tài nguyên nào vào stack.

• B (mục Mappings) — Mappings là bảng tra cứu giá trị theo khoá, ví dụ chọn AMI id theo Region. Nó không đưa tài nguyên nào vào quản lý.

• D (mục Parameters) — Parameters nhận giá trị đầu vào khi tạo hoặc cập nhật stack. Cũng không phải cơ chế import.

Ghi nhớ

⚠ Các mục chính của template CloudFormation — bảng phải thuộc: | Mục | Việc | |---|---| | Resources | BẮT BUỘC — khai tài nguyên | | Parameters | giá trị đầu vào khi chạy | | Mappings | bảng tra cứu tĩnh (ví dụ AMI theo Region) | | Conditions | tạo tài nguyên có điều kiện | | Outputs | giá trị xuất ra, export được cho stack khác | | Transform | dùng macro, ví dụ SAM | | Metadata | dữ liệu bổ sung, cấu hình cfn-init |

Từ khoá nhận diện:

"đưa tài nguyên có sẵn vào CloudFormation" → resource import "template và thực tế có khớp không" → drift detection "xem trước thay đổi" → change set "triển khai nhiều tài khoản/Region" → StackSets "giữ tài nguyên khi xoá stack" → DeletionPolicy: Retain

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Loại tài nguyên có import được không | tra bảng "Resources that support import" | | Import có thành công không | trạng thái stack IMPORT_COMPLETE | | Template có khớp thực tế không | detect-stack-drift rồi đọc kết quả |

Và một lời khuyên: hãy đặt DeletionPolicy: Retain cho mọi tài nguyên trước khi import chúng. Import là thao tác nhận quyền quản lý một tài nguyên đang phục vụ sản xuất, và kể từ giây phút đó, một lệnh delete-stack gõ nhầm hay một Replacement: True không ai để ý đều có thể xoá thật. Retain biến sai lầm tệ nhất thành một tài nguyên mồ côi cần dọn dẹp — thay vì một cơ sở dữ liệu đã biến mất.

Đáp án

B, D — hai điều đúng khi chia sẻ AMI:

• B — Chỉ chia sẻ được AMI có volume KHÔNG mã hoá, hoặc volume mã hoá bằng CUSTOMER-MANAGED CMK.
• D — KHÔNG cần chia sẻ riêng các EBS snapshot mà AMI tham chiếu để chia sẻ được AMI.

Vì sao đúng

⚠ Điều B — vì sao khoá do AWS quản lý không chia sẻ được:

Volume mã hoá bằng AWS managed key (aws/ebs)
        ↓
    Key policy của khoá này KHÔNG SỬA ĐƯỢC
        ↓
    → không có cách nào cấp quyền cho tài khoản khác
        ↓
    → AMI đó KHÔNG chia sẻ được, chấm hết

Volume mã hoá bằng CUSTOMER-MANAGED CMK
        ↓
    Key policy SỬA ĐƯỢC
        ↓
    → cấp quyền dùng khoá cho tài khoản kia
    → chia sẻ được

⚠ Điều D — snapshot đi kèm AMI, không phải chia sẻ riêng:

Chia sẻ AMI cho tài khoản khác
        ↓
    Quyền trên các snapshot mà AMI tham chiếu
    được cấp KÈM THEO, tự động
        ↓
    → KHÔNG phải chạy modify-snapshot-attribute riêng
        ↓
    Nhưng nếu snapshot MÃ HOÁ
        ↓
    → vẫn phải chia sẻ quyền dùng CMK, đó là việc RIÊNG

Đây chính là chỗ hai phương án B và E dễ làm người ta rối: snapshot thì không cần chia sẻ riêng, nhưng CMK thì có.

# Chia sẻ AMI cho một tài khoản
aws ec2 modify-image-attribute --image-id ami-xxxx \
  --launch-permission "Add=[{UserId=111122223333}]"

# Nếu mã hoá: cấp thêm quyền dùng CMK trong key policy

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

• E (phải chia sẻ cả CMK VÀ các EBS snapshot mà AMI tham chiếu) — đây là phương án gần nhất và vế CMK hoàn toàn đúng. Nhưng vế snapshot thì sai: snapshot đi kèm sẵn khi chia sẻ AMI. Đúng một nửa vẫn là sai.

• A (chỉ chia sẻ được AMI không mã hoá hoặc mã hoá bằng AWS-managed CMK) — ngược hẳn: AWS managed key là loại KHÔNG chia sẻ được, vì key policy của nó không sửa được.

• C (AMI là tài nguyên theo Region và chia sẻ được giữa các Region) — vế đầu đúng, vế sau sai. AMI gắn với đúng một Region; muốn dùng ở Region khác thì phải copy-image sang đó, tạo ra một AMI mới với id mới.

Ghi nhớ

⚠ Phạm vi của các tài nguyên EC2 — bảng phải thuộc: | Tài nguyên | Phạm vi | |---|---| | AMI | Region — dùng Region khác phải copy-image | | EBS snapshot | Region — copy sang Region khác được | | EBS volume | Availability Zone | | Security Group | VPC | | Elastic IP | Region | | Key pair | Region |

Từ khoá nhận diện:

"chia sẻ AMI mã hoá" → phải dùng CUSTOMER-MANAGED CMK "AWS managed key chia sẻ được" → LUÔN SAI "chia sẻ AMI có phải chia sẻ snapshot không" → KHÔNG, đi kèm sẵn "dùng AMI ở Region khác" → copy-image "chia sẻ cho toàn bộ tổ chức" → launch permission theo OrganizationArn "chia sẻ công khai" → --launch-permission "Add=[{Group=all}]"

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai đang được chia sẻ | describe-image-attribute --attribute launchPermission | | AMI mã hoá bằng khoá nào | describe-images, xem block device mapping | | Bên nhận có dùng được không | khởi chạy thử một instance ở tài khoản đó |

Và một cảnh báo về bảo mật: hãy kiểm tra AMI trước khi chia sẻ công khai, và kiểm tra kỹ hơn nữa là bạn nghĩ cần. Một AMI chia sẻ ra ngoài mang theo toàn bộ nội dung ổ đĩa — khoá SSH trong ~/.ssh, lịch sử lệnh trong .bash_history, tệp cấu hình còn nguyên chuỗi kết nối cơ sở dữ liệu. Đã có không ít lần dữ liệu doanh nghiệp rò rỉ theo đúng con đường này, và AMI công khai thì không thu hồi được: người ta đã kịp sao chép nó về tài khoản của mình từ lâu.

Đáp án

D, E — hai cách dựng lại AMI đã lỡ xoá:

• D — TẠO MỘT AMI MỚI từ các EC2 instance đã được khởi chạy trước khi AMI bị xoá.
• E — TẠO MỘT AMI MỚI từ các EBS snapshot đã lưu làm bản sao lưu.

Vì sao đúng

Mấu chốt của câu này nằm ở một chữ: "tạo mới" (create) chứ không phải "khôi phục" (recover).

⚠ Điểm mấu chốt: AMI đã deregister thì KHÔNG khôi phục được — nhưng dựng lại được:

Deregister AMI
        ↓
    → id AMI đó BIẾN MẤT VĨNH VIỄN, không lấy lại
        ↓
Nhưng dữ liệu thật vẫn còn ở hai nơi:
        ↓
    1. Các EC2 instance đã khởi chạy từ AMI đó (vẫn đang chạy)
    2. Các EBS snapshot đã tạo làm sao lưu
        ↓
    → từ mỗi nguồn đều dựng lại được một AMI MỚI

⚠ Cách D — dựng từ instance đang chạy (đơn giản nhất):

aws ec2 create-image --instance-id i-xxxxxxxx \
    --name "ami-moi-tu-instance"
# Không truyền --no-reboot → máy khởi động lại
#   → được AMI nhất quán ở mức ứng dụng

⚠ Cách E — dựng từ snapshot (dùng khi instance cũng đã mất):

aws ec2 register-image \
  --name "ami-moi-tu-snapshot" \
  --root-device-name /dev/xvda \
  --block-device-mappings \
    '[{"DeviceName":"/dev/xvda",
       "Ebs":{"SnapshotId":"snap-xxxxxxxx"}}]' \
  --architecture x86_64 \
  --virtualization-type hvm \
  --ena-support

Điểm cần chú ý ở cách E: bạn phải tự khai lại siêu dữ liệu — kiến trúc, tên ổ gốc, loại ảo hoá, hỗ trợ ENA. Chính những thông tin này là thứ mất theo AMI khi deregister.

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

• B (khôi phục AMI từ EBS snapshot) — đây là phương án gần nhất và rất dễ chọn nhầm, vì nó chỉ khác đáp án E ở một động từ. Nhưng đó là khác biệt thật: không có thao tác "khôi phục AMI" nào trong AWS. Bạn đăng ký một AMI mới từ snapshot, và nó mang id mới.

• A (khôi phục AMI từ các instance đang chạy) — cùng lỗi như B: động từ sai. Đúng phải là tạo AMI mới từ instance.

• C (AWS Support giữ bản sao lưu AMI, viết thư nhờ khôi phục) — sai; AWS không giữ bản sao lưu AMI của khách hàng. Trách nhiệm sao lưu thuộc về bạn — đây chính là mô hình trách nhiệm chia sẻ.

Ghi nhớ

⚠ Cái gì khôi phục được, cái gì không — bảng phải thuộc: | Thao tác | Đảo ngược được | |---|---| | Deregister AMI | KHÔNG — nhưng dựng lại AMI mới được nếu còn snapshot | | Xoá EBS snapshot | KHÔNG — mất hẳn | | Terminate instance | không, nhưng volume có DeleteOnTermination: false thì còn | | Xoá đối tượng S3 (có versioning) | CÓ — xoá delete marker | | Xoá KMS CMK | CÓ trong thời gian chờ 7–30 ngày | | Xoá RDS instance | có nếu đã tạo final snapshot |

Từ khoá nhận diện:

"khôi phục AMI đã xoá" → KHÔNG có, phải TẠO MỚI "AWS Support giữ backup hộ" → LUÔN SAI "tạo AMI từ snapshot" → register-image "tạo AMI từ instance" → create-image "chống xoá nhầm" → AWS Backup + Recycle Bin

⚠ Recycle Bin — tính năng phải biết để tránh đúng sự cố của đề: | Nội dung | Chi tiết | |---|---| | Bảo vệ được | EBS snapshot và AMI (EBS-backed) | | Cách hoạt động | xoá xong vào thùng rác, giữ theo thời hạn quy định | | Thời hạn giữ | 1 ngày tới 1 năm | | Quy tắc | áp cho toàn bộ hoặc theo tag | | Trong thời hạn | khôi phục lại nguyên vẹn, giữ nguyên id |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Snapshot còn không | describe-snapshots --owner-ids self | | Ai đã xoá AMI | CloudTrail sự kiện DeregisterImage | | ASG nào đang trỏ vào AMI đã mất | rà launch template và launch configuration |

Và một lời khuyên rút ra từ chính sự cố của đề: hãy bật Recycle Bin cho snapshot và AMI ngay hôm nay — nó gần như miễn phí (chỉ trả tiền lưu trữ trong thời gian giữ) và biến một sự cố kiểu này thành một cú bấm chuột. Đáng lo hơn nữa: nếu Auto Scaling group đang trỏ vào AMI vừa bị xoá thì hệ thống vẫn chạy bình thường cho tới lần scale-out tiếp theo — rồi mọi instance mới đều thất bại, thường là đúng lúc lưu lượng đang tăng cao.

Đáp án

C — Triển khai NAT Gateway ở public subnet và thêm tuyến vào route table của các private subnet.

Vì sao đúng

Đề đã tự loại trừ gần hết nguyên nhân, chỉ cần đọc kỹ: "Load Balancer truy cập được ứng dụng, và ứng dụng truy cập được cơ sở dữ liệu".

⚠ Điểm mấu chốt — những gì hoạt động tốt đã loại bỏ hầu hết nghi phạm:

ALB → EC2 chạy được
        ↓
    → Security Group vào đúng, NACL đúng, subnet đúng

EC2 → RDS chạy được
        ↓
    → mạng nội bộ VPC hoàn toàn bình thường

Chỉ EC2 → internet là hỏng
        ↓
    → thiếu ĐƯỜNG RA khỏi private subnet
        ↓
    → NAT Gateway

⚠ Vì sao là NAT Gateway chứ không phải Internet Gateway:

NAT Gateway đặt ở PUBLIC subnet
        ↓
    Private subnet route: 0.0.0.0/0 → nat-xxxxx
        ↓
    NAT chuyển tiếp ra IGW bằng IP công cộng của chính nó
        ↓
    → instance RA được internet để tải bản vá
    → nhưng KHÔNG AI từ internet vào được instance
        ↓
    → giữ nguyên tính chất "private" của subnet

⚠ Có một cách khác, và với SSM thì nó còn tốt hơn:

Thay vì NAT Gateway, tạo VPC ENDPOINT cho SSM
        ↓
    Cần BA endpoint kiểu Interface:
        com.amazonaws.<region>.ssm
        com.amazonaws.<region>.ssmmessages
        com.amazonaws.<region>.ec2messages
        ↓
    → lưu lượng SSM đi trong mạng AWS, KHÔNG ra internet
    → rẻ hơn NAT nếu chỉ cần SSM
        ↓
    Nhưng nếu còn cần tải gói phần mềm từ repo bên ngoài
        ↓
    → vẫn phải có NAT Gateway

Đề nói mục đích là vá máy, tức là phải tải gói từ repo ngoài — nên NAT Gateway là câu trả lời đầy đủ.

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

• D (đặt Internet Gateway ở public subnet rồi thêm tuyến) — đây là phương án gần nhất và hai chỗ sai rất đáng nhớ. Thứ nhất, IGW gắn vào VPC chứ không đặt vào subnet nào — chính cách diễn đạt đã sai. Thứ hai, nếu trỏ private subnet thẳng vào IGW thì subnet đó thành public, phá vỡ toàn bộ thiết kế bảo mật của hệ thống (và instance không có IP công cộng thì vẫn không ra được).

• A (chuyển instance sang public subnet) — "được việc" nhưng phá kiến trúc: đưa cả fleet ứng dụng ra phơi mặt trên internet chỉ để tải bản vá là cái giá quá đắt. Vế "private subnet không ra internet được" cũng sai — chúng ra được, qua NAT.

• B (mở Security Group của EC2) — Security Group cho phép sẵn toàn bộ lưu lượng ĐI RA theo mặc định, và đề đã chứng minh mạng nội bộ thông suốt. Đây không phải nguyên nhân.

Ghi nhớ

⚠ Public subnet và private subnet — bảng phải thuộc: | | Public subnet | Private subnet | |---|---|---| | Route 0.0.0.0/0 trỏ tới | Internet Gateway | NAT Gateway | | Từ internet vào được | có (nếu có IP công cộng) | không | | Ra internet được | có | có, qua NAT | | Đặt gì ở đây | ALB, NAT Gateway, bastion | EC2 ứng dụng, RDS |

Từ khoá nhận diện:

"private subnet cần ra internet" → NAT Gateway "chỉ cần gọi dịch vụ AWS, không ra internet" → VPC endpoint "IGW đặt trong subnet" → LUÔN SAI, IGW gắn vào VPC "NAT Gateway đặt ở private subnet" → SAI, phải ở PUBLIC subnet "SSM không kết nối được" → thiếu NAT, thiếu VPC endpoint, hoặc thiếu IAM role

⚠ Ba điều kiện để SSM quản lý được một instance — thiếu một là máy biến mất khỏi Fleet Manager: | Điều kiện | Chi tiết | |---|---| | SSM Agent | đã cài và đang chạy | | IAM instance profile | AmazonSSMManagedInstanceCore | | Đường mạng tới endpoint SSM | NAT Gateway hoặc 3 VPC endpoint |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Route table đúng chưa | private subnet phải có 0.0.0.0/0 → nat-xxxxx | | NAT có ở public subnet không | subnet của NAT phải có tuyến tới IGW | | Instance có ra được không | curl -I https://s3.amazonaws.com từ trong máy |

Và một lưu ý về chi phí thường bị bỏ qua: NAT Gateway tính tiền theo giờ VÀ theo mỗi GB đi qua nó, kể cả lưu lượng tới chính các dịch vụ AWS. Một fleet tải hàng trăm GB từ S3 mỗi ngày qua NAT sẽ sinh ra khoản phí xử lý dữ liệu hoàn toàn tránh được — chỉ cần thêm một gateway endpoint cho S3, thứ vốn miễn phí hoàn toàn.

Đáp án

A — Định nghĩa Cost Allocation Tags và tạo báo cáo bằng Cost Explorer.

Vì sao đúng

Đề hỏi đúng một thứ: báo cáo phân bổ chi phí Elastic IP THEO PHÒNG BAN — và đó chính là bài toán mà cost allocation tag sinh ra để giải.

⚠ Điểm mấu chốt — quy trình ba bước, và bước 2 là chỗ hay bị quên nhất:

1. Gắn tag lên tài nguyên
       Department = KinhDoanh / KyThuat / Marketing
        ↓
2. KÍCH HOẠT tag đó làm cost allocation tag
       Billing console → Cost allocation tags → Activate
        ↓
   ⚠ Không kích hoạt thì tag KHÔNG bao giờ hiện trong báo cáo chi phí
        ↓
3. Cost Explorer → Group by → Tag: Department
        ↓
   → biểu đồ chi phí Elastic IP tách theo từng phòng ban

⚠ Cảnh báo lớn nhất: dữ liệu chi phí KHÔNG hồi tố:

Kích hoạt cost allocation tag hôm nay
        ↓
    → chỉ áp cho dữ liệu chi phí TỪ NAY TRỞ ĐI
        ↓
    → chi phí tháng trước KHÔNG được gắn tag lại
        ↓
    → phải chờ tới chu kỳ thanh toán sau mới có báo cáo đầy đủ

Và về chính vấn đề Elastic IP mà đề nêu, đây là điều đáng nhớ:

Nghĩa là Elastic IP luôn tốn tiền, và những địa chỉ nằm không chính là khoản lãng phí thuần tuý mà công ty trong đề đang trả.

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

• D (tạo một AWS Config rule cho mỗi phòng ban để theo dõi chi phí) — đây là phương án gần nhất vì Config đúng là có thể phát hiện tài nguyên thiếu tag (quy tắc required-tags). Nhưng AWS Config không theo dõi chi phí — nó là dịch vụ tuân thủ cấu hình, không có dữ liệu tiền bạc nào.

• C (Lambda kiểm tra mỗi giờ và dùng CloudTrail tìm người truy cập cuối) — trả lời câu hỏi "ai đụng vào", không phải "phòng nào tốn bao nhiêu". Vừa phức tạp vừa không ra được báo cáo chi phí.

• B (dùng AWS Artifact để cấm để EIP rảnh quá 20 phút) — mô tả sai hoàn toàn: AWS Artifact là cổng tải tài liệu tuân thủ (báo cáo SOC, ISO, PCI). Nó không thực thi chính sách nào cả.

Xem thêm câu #11636: cùng đáp án cost allocation tag nhưng đặt vấn đề từ góc phân bổ chi phí theo phòng ban trong một tài khoản — ở đó bẫy là phương án "Tags" chung chung, thiếu bước kích hoạt.

Ghi nhớ

⚠ Bộ công cụ chi phí của AWS — bảng phải thuộc: | Công cụ | Việc | |---|---| | Cost Explorer | xem và phân tích chi phí, nhóm theo tag/dịch vụ/tài khoản | | AWS Budgets | đặt ngân sách và cảnh báo khi sắp vượt | | 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 bằng học máy | | Compute Optimizer | gợi ý giảm cỡ tài nguyên | | Trusted Advisor | khuyến nghị tối ưu, có check EIP không dùng |

Từ khoá nhận diện:

"chi phí theo phòng ban / dự án" → cost allocation tag + Cost Explorer "cảnh báo khi vượt ngân sách" → AWS Budgets "tài nguyên thiếu tag" → AWS Config required-tags "tài liệu tuân thủ, báo cáo SOC" → AWS Artifact "chi phí tự nhiên tăng vọt" → Cost Anomaly Detection

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tag đã kích hoạt chưa | Billing console → Cost allocation tags | | Tài nguyên nào thiếu tag | Tag Editor hoặc required-tags | | EIP nào đang rảnh | describe-addresses — tìm mục không có InstanceId |

Và một lời khuyên thực dụng cho chính vấn đề của công ty trong đề: hãy đặt một quy tắc AWS Config phát hiện Elastic IP không gắn vào đâu, kèm remediation tự thu hồi sau một khoảng thời gian. Elastic IP rảnh là loại lãng phí ngấm ngầm nhất trên AWS — mỗi địa chỉ chỉ tốn vài đô mỗi tháng nên không ai để ý, nhưng chúng tích tụ theo năm tháng, không bao giờ tự biến mất, và không có sự cố nào xảy ra để nhắc ai đó dọn dẹp.

Đáp án

B — Xem lại DB parameter group.

Vì sao đúng

Với RDS, cách ép mọi kết nối phải mã hoá nằm trong tham số của chính công cụ cơ sở dữ liệu, không nằm ở tầng mạng hay ở một công tắc trên console.

⚠ Điểm mấu chốt — mỗi công cụ có một tham số riêng, phải nhớ đúng tên:

PostgreSQL  → rds.force_ssl = 1
MySQL       → require_secure_transport = ON
SQL Server  → dùng option group, tham số "Force Encryption"
        ↓
    Đặt tham số trong một CUSTOM parameter group
        ↓
    Gắn parameter group đó vào DB instance
        ↓
    → mọi kết nối không dùng SSL/TLS bị TỪ CHỐI

⚠ Hai chi tiết vận hành bắt buộc phải biết:

1. KHÔNG sửa được default parameter group
        ↓
    → phải TẠO một custom parameter group rồi gắn vào

2. rds.force_ssl là tham số kiểu STATIC
        ↓
    → phải KHỞI ĐỘNG LẠI DB instance mới có hiệu lực
    → (tham số kiểu dynamic thì áp ngay)

Phía ứng dụng cũng phải kết nối đúng cách:

psql "host=db.xxxx.rds.amazonaws.com dbname=app user=app \
      sslmode=verify-full \
      sslrootcert=global-bundle.pem"

sslmode=require chỉ bảo đảm đường truyền được mã hoá; verify-full mới kiểm tra chứng chỉ máy chủ, tức là chống được cả tấn công người-đứng-giữa.

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

• C (bật kết nối SSL từ RDS Console) — đây là phương án gần nhất và nghe rất hợp lý, nhưng không có công tắc "Enable SSL" nào trên console RDS. SSL/TLS đã sẵn sàng từ đầu ở mọi RDS instance; thứ bạn cần là BẮT BUỘC dùng nó, và điều đó chỉ làm được qua parameter group.

• A (sửa luật Security Group) — Security Group lọc theo IP và cổng, nó không nhìn thấy nội dung kết nối nên không phân biệt được kết nối mã hoá hay không. Ngoài ra PostgreSQL dùng cùng một cổng 5432 cho cả hai kiểu.

• D (vá cơ sở dữ liệu bằng "SSL/TLS Postgres Addon") — không tồn tại. PostgreSQL hỗ trợ SSL sẵn có, và RDS là dịch vụ được quản lý nên bạn không tự vá công cụ cơ sở dữ liệu.

Ghi nhớ

⚠ Mã hoá khi truyền và khi lưu — bảng phải thuộc: | | In transit (khi truyền) | At rest (khi lưu) | |---|---|---| | Bật thế nào | parameter group (rds.force_ssl) | chỉ bật được LÚC TẠO instance | | Bật sau được không | được, bất cứ lúc nào | KHÔNG — phải khôi phục snapshot đã mã hoá sang instance mới | | Cơ chế | SSL/TLS + chứng chỉ RDS CA | KMS |

Từ khoá nhận diện:

"ép mọi kết nối phải mã hoá" → parameter group (rds.force_ssl / require_secure_transport) "bật mã hoá cho RDS đang chạy" → KHÔNG được — snapshot, copy có mã hoá, restore "đổi tham số mà không thấy tác dụng" → tham số static, cần khởi động lại "chứng chỉ RDS sắp hết hạn" → rds-ca-rsa2048-g1 và bạn bè, phải xoay định kỳ "Security Group ép mã hoá" → LUÔN SAI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tham số đã áp chưa | describe-db-parameters, và trạng thái instance phải là in-sync | | Kết nối hiện tại có mã hoá không | PostgreSQL: truy vấn view pg_stat_ssl | | Còn ai kết nối không mã hoá | cùng view đó, cột ssl = false — tìm ra trước khi bật ép buộc |

Và một lời khuyên về trình tự triển khai: hãy kiểm tra pg_stat_ssl để biết còn client nào đang kết nối không mã hoá TRƯỚC khi bật rds.force_ssl. Bật tham số này rồi khởi động lại là một thay đổi có hiệu lực tức thì và không khoan nhượng — mọi ứng dụng chưa cấu hình SSL sẽ mất kết nối ngay lập tức, thường là những công việc nền hay báo cáo định kỳ mà không ai nhớ ra cho tới khi chúng bắt đầu báo lỗi.

Đáp án

D — Liên kết danh tính người dùng bằng Amazon Cognito để họ đóng vai (assume role) truy cập S3.

Vì sao đúng

Bài toán này có một ràng buộc mà mọi ứng dụng di động đều gặp: mã ứng dụng nằm trên máy của người dùng, nên KHÔNG có bí mật nào an toàn ở đó.

⚠ Điểm mấu chốt — Cognito phát chứng chỉ TẠM THỜI cho từng người dùng:

Người dùng đăng nhập (Cognito User Pool, Google, Facebook, Apple...)
        ↓
    Cognito Identity Pool đổi token đăng nhập
        ↓
    STS cấp chứng chỉ TẠM (thường hết hạn sau 1 giờ)
        ↓
    Ứng dụng dùng chứng chỉ đó ghi thẳng lên S3
        ↓
    → KHÔNG có access key dài hạn nào nằm trong ứng dụng

⚠ Và đây là phần đắt giá nhất: giới hạn mỗi người chỉ ghi được vào thư mục của chính họ:

{
  "Effect": "Allow",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::anh-dai-dien/${cognito-identity.amazonaws.com:sub}/*"
}

Biến ${cognito-identity.amazonaws.com:sub} được thay bằng định danh của chính người dùng đang gọi, nên một chính sách duy nhất phục vụ hàng triệu người mà mỗi người vẫn bị nhốt trong thư mục riêng — không ai ghi đè ảnh của ai.

⚠ Cognito có hai thành phần, đừng nhầm:

User Pool     → thư mục người dùng: đăng ký, đăng nhập, MFA, quên mật khẩu
                → trả về TOKEN
Identity Pool → đổi token lấy CHỨNG CHỈ AWS TẠM THỜI
                → đây mới là phần cho phép gọi thẳng dịch vụ AWS

Đề cần ghi thẳng vào S3, nên Identity Pool là mảnh ghép quyết định.

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

• B (liên kết bằng SAML để dùng SSO truy cập S3) — đây là phương án gần nhất vì liên kết danh tính đúng là hướng đi đúng. Nhưng SAML dành cho danh tính doanh nghiệp (Active Directory, Okta) với số lượng hữu hạn nhân viên. Người chơi game trên di động thì đăng nhập bằng Google, Facebook, Apple — tức là OIDC/social, đúng địa hạt của Cognito.

• C (tạo một IAM user rồi nhúng access key vào ứng dụng) — sai lầm bảo mật nghiêm trọng nhất trong danh sách. Mã ứng dụng di động dịch ngược được, và khoá đó là khoá dài hạn: ai lấy được thì ghi vào bucket của bạn bao lâu tuỳ thích. Ngoài ra mọi người dùng chung một danh tính nên không kiểm toán được ai làm gì.

• A (Lambda tạo một IAM user cho mỗi người dùng) — không mở rộng được: IAM có hạn mức mặc định 5.000 user mỗi tài khoản, trong khi một game di động có thể có hàng triệu người. Và bản chất vẫn là phát khoá dài hạn.

Ghi nhớ

⚠ Chọn cách xác thực theo đối tượng — bảng phải thuộc: | Đối tượng | Cách | |---|---| | Người dùng ứng dụng di động / web công cộng | Cognito Identity Pool | | Nhân viên doanh nghiệp | IAM Identity Center hoặc SAML federation | | Ứng dụng chạy trên EC2/Lambda/ECS | IAM role, không bao giờ dùng khoá | | Hệ thống bên ngoài AWS | IAM role + sts:ExternalId, hoặc IAM Roles Anywhere |

Từ khoá nhận diện:

"hàng triệu người dùng ứng dụng di động" → Cognito "nhúng access key vào ứng dụng" → LUÔN SAI "tạo IAM user cho mỗi người dùng" → LUÔN SAI, không mở rộng được "nhân viên đăng nhập bằng AD" → SAML / IAM Identity Center "tải tệp lên mà không lộ quyền bucket" → presigned URL hoặc presigned POST

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chính sách có chặn đúng không | thử ghi vào thư mục của người khác — phải bị từ chối | | Chứng chỉ hết hạn khi nào | mặc định 1 giờ, chỉnh được | | Ai đã tải gì lên | CloudTrail data event hoặc S3 access log |

Và một lưu ý về kiến trúc: cho phép người dùng ghi thẳng lên S3 nghĩa là họ ghi được BẤT KỲ nội dung gì, không chỉ ảnh. Chính sách IAM không kiểm tra được nội dung tệp, nên hãy chặn kích thước bằng presigned POST hoặc kiểm tra sau khi tải lên bằng một Lambda gắn vào S3 Event Notification — và đừng bao giờ phục vụ trực tiếp những tệp đó dưới Content-Type do client tự khai, vì đó là cách bucket ảnh đại diện của bạn biến thành nơi lưu trữ mã độc.

Đáp án

C — Bạn quên WaitCondition.

Vì sao đúng

Đề mô tả một triệu chứng rất rõ: CloudFormation báo hoàn tất trong khi cfn-init còn đang chạy dở. Nghĩa là stack không hề chờ tín hiệu nào.

⚠ Điểm mấu chốt: gửi tín hiệu là một chuyện, có ai CHỜ tín hiệu đó hay không lại là chuyện khác:

cfn-signal gửi tín hiệu "tôi xong rồi"
        ↓
    Nhưng KHÔNG có ai đang chờ nghe
        ↓
    → CloudFormation đánh dấu tài nguyên xong ngay khi
      EC2 API trả về "instance đã khởi chạy"
        ↓
    → stack CREATE_COMPLETE trong khi máy còn đang cài đặt

⚠ Hai cách khai "hãy chờ tín hiệu" — cả hai đều được chấp nhận:

Cách 1 — CreationPolicy (gọn hơn, dùng cho chính tài nguyên đó):

MayChu:
  Type: AWS::EC2::Instance
  CreationPolicy:
    ResourceSignal:
      Count: 1
      Timeout: PT15M

Cách 2 — WaitCondition + WaitConditionHandle (linh hoạt hơn):

ChoTinHieu:
  Type: AWS::CloudFormation::WaitCondition
  DependsOn: MayChu
  Properties:
    Handle: !Ref TayCamTinHieu
    Timeout: "900"
    Count: 1

Và trong user data, script phải báo về:

/opt/aws/bin/cfn-init -v --stack ${AWS::StackName} \
    --resource MayChu --region ${AWS::Region}

/opt/aws/bin/cfn-signal -e $? --stack ${AWS::StackName} \
    --resource MayChu --region ${AWS::Region}

⚠ Chú ý -e $? — nó truyền mã thoát của cfn-init vào tín hiệu:

cfn-init thành công → $? = 0 → tín hiệu SUCCESS → stack tiếp tục
cfn-init thất bại   → $? khác 0 → tín hiệu FAILURE → stack rollback NGAY
        ↓
    Viết cfn-signal --success true cứng
        ↓
    → luôn báo thành công dù cài đặt hỏng
    → mất toàn bộ giá trị của cơ chế này

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

• A (quên đặt lệnh cfn-signal trong user data) — đây là phương án gần nhất, nhưng đề đã nói rõ là đang dùng cfn-signal. Vấn đề không nằm ở việc gửi tín hiệu mà ở việc không có ai chờ nó.

• B (quên DeletionPolicy) — DeletionPolicy quyết định số phận tài nguyên khi stack bị xoá, không liên quan gì tới thời điểm stack báo hoàn tất.

• D (không tắt rollback) — rollback quyết định điều xảy ra khi tạo stack thất bại. Ở đây stack thành công (quá sớm), nên rollback không phải nguyên nhân.

Xem thêm câu #11594: cùng bộ công cụ này nhưng hỏi triệu chứng ngược — stack không nhận được tín hiệu vì thiếu đường mạng hoặc hết thời gian chờ. Hai câu là hai mặt của một cơ chế.

Ghi nhớ

⚠ Hai cơ chế chờ tín hiệu — bảng phải thuộc: | | CreationPolicy | WaitCondition | |---|---|---| | Khai ở đâu | thuộc tính của chính tài nguyên | một tài nguyên riêng | | Dùng với | EC2, Auto Scaling group, ASG replace | bất kỳ, kể cả nguồn ngoài | | Cú pháp | gọn hơn | cần thêm WaitConditionHandle | | AWS khuyên | ưu tiên CreationPolicy | dùng khi tín hiệu đến từ nơi khác |

Từ khoá nhận diện:

"stack xong quá sớm" → thiếu CreationPolicy hoặc WaitCondition "cài đặt hỏng mà stack vẫn xanh" → cfn-signal không truyền -e $? "chờ mãi rồi rollback" → cfn-signal chưa từng chạy (kiểm tra cfn-init.log) "cập nhật ASG theo lô" → UpdatePolicy "giữ tài nguyên khi xoá stack" → DeletionPolicy

⚠ Bốn kịch bản trợ giúp của CloudFormation trên EC2 — bảng phải thuộc: | Kịch bản | Việc | |---|---| | cfn-init | đọc mục Metadata.AWS::CloudFormation::Init — cài gói, ghi tệp, chạy dịch vụ | | cfn-signal | báo thành công hoặc thất bại về cho stack | | cfn-hup | theo dõi metadata đổi và chạy lại cfn-init — cập nhật không cần thay máy | | cfn-get-metadata | đọc metadata để gỡ lỗi |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Stack có chờ không | tìm CreationPolicy hoặc WaitCondition trong template | | Tín hiệu có tới không | tab Events của stack | | cfn-init hỏng ở đâu | SSH vào máy đọc /var/log/cfn-init.log |

Và một lời khuyên khi gỡ lỗi loại này: hãy tạo stack với --disable-rollback khi đang phát triển. Hành vi mặc định là rollback và xoá sạch instance hỏng, tức là xoá luôn đúng những tệp log duy nhất có thể cho bạn biết vì sao nó hỏng — và bạn rơi vào vòng lặp thử lại nhiều lần mà chẳng lần nào nhìn được vào bên trong.