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

Đáp án

D — Trạng thái error cho biết phần cứng bên dưới của EBS volume đã hỏng. Volume đó KHÔNG khôi phục được, nhưng dữ liệu khôi phục được từ bản sao lưu sang một volume MỚI.

Vì sao đúng

Trạng thái error của EBS có một ý nghĩa rất cụ thể và rất dứt khoát.

⚠ Điểm mấu chốt — error nghĩa là hỏng phần cứng, không phải hỏng kết nối:

EBS volume ở trạng thái "error"
        ↓
    Hạ tầng lưu trữ bên dưới đã hỏng
    và AWS KHÔNG khôi phục được volume đó
        ↓
    → khởi động lại instance KHÔNG giúp gì
    → tháo ra gắn lại KHÔNG giúp gì
        ↓
    → cách duy nhất: TẠO VOLUME MỚI từ snapshot

⚠ Quy trình khôi phục:

# 1. Tìm snapshot gần nhất của volume hỏng
aws ec2 describe-snapshots --owner-ids self \
  --filters Name=volume-id,Values=vol-xxxxxxxx \
  --query 'sort_by(Snapshots,&StartTime)[-1]'

# 2. Tạo volume mới từ snapshot đó, CÙNG AZ với instance
aws ec2 create-volume --snapshot-id snap-xxxx \
  --availability-zone ap-southeast-1a --volume-type gp3

# 3. Tháo volume hỏng, gắn volume mới vào cùng device name
aws ec2 detach-volume --volume-id vol-hong --force
aws ec2 attach-volume --volume-id vol-moi \
  --instance-id i-xxxx --device /dev/xvdf

⚠ Và điều quan trọng nhất phải chấp nhận:

Bạn MẤT toàn bộ dữ liệu phát sinh SAU snapshot gần nhất
        ↓
    → khoảng cách giữa hai snapshot chính là RPO của bạn
        ↓
    → đây là lý do lịch snapshot phải khớp với
      mức mất mát mà nghiệp vụ chấp nhận được

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

• C (khởi động lại instance, nếu dữ liệu không hiện thì khôi phục từ backup) — đây là phương án gần nhất và vế thứ hai đúng. Nhưng vế đầu là lãng phí thời gian: trạng thái error là kết luận dứt khoát về hỏng phần cứng, khởi động lại không bao giờ sửa được nó.

• A (kênh liên lạc giữa volume và instance bị gián đoạn, khởi động lại là hết) — chẩn đoán sai: nếu chỉ là vấn đề kết nối thì volume vẫn ở trạng thái in-use, không phải error.

• B (khôi phục volume từ Data Lifecycle Manager bằng cách chuyển volume sang instance khác) — hiểu sai công dụng: DLM chỉ TẠO và XOÁ snapshot theo lịch, nó không có chức năng khôi phục nào. Khôi phục là thao tác EC2 thông thường từ snapshot.

Ghi nhớ

⚠ Các trạng thái của EBS volume — bảng phải thuộc: | Trạng thái | Nghĩa | |---|---| | creating | đang tạo | | available | sẵn sàng, chưa gắn vào máy nào | | in-use | đang gắn vào instance | | deleting / deleted | đang xoá / đã xoá | | error | PHẦN CỨNG HỎNG — không khôi phục được |

Từ khoá nhận diện:

"volume ở trạng thái error" → tạo volume mới từ snapshot "volume vẫn in-use nhưng không đọc được" → kiểm tra hệ thống tệp, fsck "tăng dung lượng mà df không đổi" → chưa resize2fs / xfs_growfs "snapshot tự động theo lịch" → DLM hoặc AWS Backup "khôi phục snapshot" → create-volume --snapshot-id

⚠ Một chi tiết hiệu năng rất hay bị bỏ qua khi khôi phục:

Volume tạo từ snapshot được nạp LƯỜI (lazy loading)
        ↓
    Khối dữ liệu chỉ được kéo từ S3 khi lần đầu được đọc
        ↓
    → những lần đọc đầu tiên CHẬM HƠN đáng kể
        ↓
    Cách khắc phục:
        - bật Fast Snapshot Restore (có phí), hoặc
        - đọc trước toàn bộ volume:
          sudo dd if=/dev/xvdf of=/dev/null bs=1M

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Trạng thái volume | describe-volumes, xem State | | Snapshot gần nhất khi nào | describe-snapshots lọc theo volume-id | | Volume mới đã gắn đúng chưa | lsblk trong máy, rồi mount lại |

Và một lời khuyên rút ra từ chính sự cố này: hãy tính xem lịch snapshot hiện tại tương ứng với RPO bao nhiêu giờ, và xác nhận con số đó với bộ phận nghiệp vụ. Khi một volume chuyển sang error, lượng dữ liệu bạn mất chính xác bằng khoảng thời gian từ snapshot gần nhất tới lúc sự cố — và đó là con số nên được thống nhất từ trước, chứ không phải thứ được phát hiện ra trong lúc đang khôi phục.

Đáp án

B, D — hai tính năng của EFS mount helper:

• D — Mount với IAM authorization.
• B — Tự động mount lại khi EC2 instance khởi động lại.

Vì sao đúng

EFS mount helper (amazon-efs-utils) là một công cụ bọc quanh lệnh mount chuẩn, và nó thêm vào những thứ mà NFS thuần không có.

⚠ Điểm mấu chốt — mount helper thêm bốn khả năng:

1. Mã hoá khi truyền (TLS)
       mount -t efs -o tls fs-xxxx:/ /mnt/efs
       → dựng đường hầm stunnel, mã hoá toàn bộ lưu lượng NFS

2. IAM authorization                          ← điều D
       mount -t efs -o tls,iam fs-xxxx:/ /mnt/efs
       → dùng IAM role của instance để xác thực

3. Access point
       mount -t efs -o tls,accesspoint=fsap-xxxx fs-xxxx:/ /mnt/efs

4. Tự mount lại khi khởi động                 ← điều B
       thêm dòng vào /etc/fstab với tuỳ chọn _netdev

⚠ Điều D — IAM authorization giải quyết vấn đề gì:

NFS thuần xác thực bằng UID/GID của tiến trình
        ↓
    → ai giả được UID thì truy cập được
    → không kiểm toán được ai đã mount
        ↓
IAM authorization
        ↓
    → dùng IAM role của instance
    → file system policy quyết định ai được mount
    → CloudTrail ghi lại việc mount
        ↓
    → phân quyền và kiểm toán theo mô hình AWS

⚠ Điều B — dòng /etc/fstab để tự mount lại:

fs-xxxxxxxx:/ /mnt/efs efs _netdev,tls,iam 0 0
        ↓
    Tuỳ chọn _netdev rất quan trọng
        ↓
    → báo cho hệ thống chờ MẠNG SẴN SÀNG rồi mới mount
        ↓
    → thiếu nó thì máy có thể treo lúc khởi động,
      hoặc mount thất bại vì mạng chưa lên

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

• A (mount từ EC2 chạy Windows) — đây là phương án gần nhất vì nghe như một khả năng hợp lý. Nhưng EFS chỉ dùng NFS, và mount helper chỉ có cho Linux. Windows cần SMB, tức là FSx for Windows File Server.

• E (mount từ máy Windows tại chỗ) — cùng lý do; và máy tại chỗ dù chạy Linux thì cũng cần Direct Connect hoặc VPN để tới được mount target.

• C (mount với xác thực bằng Amazon Cognito) — không tồn tại. Cognito dành cho danh tính người dùng ứng dụng, không dùng để mount hệ thống tệp.

Ghi nhớ

⚠ Tính năng của EFS mount helper — bảng phải thuộc: | Tuỳ chọn | Việc | |---|---| | tls | mã hoá khi truyền (qua stunnel) | | iam | xác thực bằng IAM role của instance | | accesspoint=fsap-xxxx | mount qua access point | | _netdev (trong fstab) | chờ mạng sẵn sàng — tự mount khi khởi động | | awscredsuri | dùng chứng chỉ từ một URI (cho container) |

Từ khoá nhận diện:

"mã hoá khi truyền cho EFS" → -o tls "xác thực bằng IAM" → -o iam (cần cả tls) "tự mount khi reboot" → /etc/fstab với _netdev "mount từ Windows" → KHÔNG ĐƯỢC với EFS, dùng FSx for Windows "mỗi ứng dụng một thư mục riêng" → access point

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã mount chưa | df -hT — thấy kiểu nfs4 | | Có mã hoá khi truyền không | kiểm tra tiến trình stunnel đang chạy | | Vì sao mount thất bại | log tại /var/log/amazon/efs/mount.log |

Và một lời khuyên khi đưa EFS vào tự động hoá: luôn thêm _netdev vào dòng /etc/fstab, và cân nhắc thêm nofail. Thiếu _netdev thì máy có thể cố mount trước khi mạng sẵn sàng và treo hẳn lúc khởi động — một tình huống đặc biệt khó chịu với instance trong Auto Scaling group, vì máy không bao giờ qua được health check, ASG giết nó đi, rồi khởi chạy một máy mới lặp lại đúng chu trình đó.

Đáp án

B — Dùng DynamoDB Streams kết hợp với AWS Lambda để tích hợp DynamoDB với hệ thống quan hệ.

Vì sao đúng

Đề mô tả một kiến trúc rất phổ biến: hai cơ sở dữ liệu phục vụ hai loại tải khác nhau, và cần một cầu nối giữa chúng.

⚠ Điểm mấu chốt — DynamoDB Streams là dòng sự kiện của mọi thay đổi:

Mỗi lần một mục trong bảng DynamoDB được
        thêm, sửa, hoặc xoá
        ↓
    Một bản ghi được đẩy vào DynamoDB Stream
        ↓
    Lambda được kích hoạt tự động
        ↓
    → Lambda ghi thay đổi đó sang cơ sở dữ liệu quan hệ
        ↓
    → DynamoDB phục vụ ứng dụng (mili giây)
    → hệ thống quan hệ vẫn có đủ dữ liệu để làm báo cáo

⚠ Bốn chế độ StreamViewType — chọn đúng là quan trọng:

KEYS_ONLY            → chỉ khoá của mục bị thay đổi
NEW_IMAGE            → trạng thái SAU khi thay đổi
OLD_IMAGE            → trạng thái TRƯỚC khi thay đổi
NEW_AND_OLD_IMAGES   → cả hai            ← thường dùng cho đồng bộ
        ↓
    Có cả hai ảnh thì mới dựng được câu UPDATE chính xác
    và biết được trường nào đã đổi

⚠ Và vì sao đây là mẫu kiến trúc chuẩn:

Không cần polling
        ↓
    Lambda được đẩy sự kiện, không phải hỏi liên tục
        ↓
Thứ tự được đảm bảo trong mỗi partition
        ↓
Tự động thử lại khi Lambda lỗi
        ↓
Có Dead Letter Queue cho bản ghi xử lý hỏng mãi
        ↓
    → gần như không phải viết hạ tầng nào

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

• C (dùng Kinesis Data Streams để mang cập nhật thời gian thực từ hệ thống quan hệ sang DynamoDB) — đây là phương án gần nhất vì Kinesis đúng là công cụ cho dòng dữ liệu. Nhưng nó đi sai chiều (từ quan hệ sang DynamoDB, trong khi đề cần chiều ngược lại), và nó là giải pháp tự dựng trong khi DynamoDB đã có Streams sẵn. (Có Kinesis Data Streams for DynamoDB cho tình huống cần fan-out nhiều consumer, nhưng vẫn là chiều từ DynamoDB đi ra.)

• D (DynamoDB Accelerator — DAX) — là bộ nhớ đệm trong bộ nhớ cho chính DynamoDB, giúp đọc nhanh hơn nữa. Nó không tích hợp với hệ thống nào bên ngoài.

• A (dùng ElastiCache làm bộ nhớ đệm để tích hợp) — ElastiCache là cache, không phải cơ chế đồng bộ dữ liệu giữa hai cơ sở dữ liệu.

Ghi nhớ

⚠ DynamoDB Streams — bảng phải thuộc: | Đặc điểm | Nội dung | |---|---| | Ghi lại | mọi thay đổi ở mức ITEM (insert, update, delete) | | Giữ dữ liệu | 24 giờ | | Thứ tự | đảm bảo trong mỗi partition key | | Tiêu thụ bởi | Lambda (phổ biến nhất), hoặc Kinesis Client Library | | Không tính phí riêng cho stream | chỉ trả tiền cho lời gọi đọc |

Từ khoá nhận diện:

"phản ứng khi dữ liệu DynamoDB thay đổi" → DynamoDB Streams + Lambda "tăng tốc ĐỌC DynamoDB" → DAX "sao chép DynamoDB sang Region khác" → Global Tables (dùng Streams bên dưới) "xuất DynamoDB sang S3 để phân tích" → export to S3 (không tốn RCU) "di chuyển từ cơ sở dữ liệu quan hệ sang DynamoDB" → DMS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Stream đã bật chưa | describe-table, xem StreamSpecification | | Lambda có xử lý kịp không | chỉ số IteratorAge — cao là đang tụt hậu | | Có bản ghi nào hỏng không | kiểm tra Dead Letter Queue |

Và một chỉ số cần theo dõi sát khi vận hành mẫu kiến trúc này: IteratorAge của Lambda. Nó cho biết bản ghi cũ nhất đang chờ xử lý đã nằm trong stream bao lâu — và vì DynamoDB Streams chỉ giữ dữ liệu 24 giờ, một IteratorAge đang leo đều đặn nghĩa là đồng hồ đếm ngược tới lúc dữ liệu bị mất vĩnh viễn mà không có cách nào lấy lại.

Đáp án

D — Dùng AWS CloudFormation template để quản lý và duy trì hạ tầng mạng.

Vì sao đúng

Đề nêu đúng bài toán mà hạ tầng dạng mã (Infrastructure as Code) sinh ra để giải: nhân bản hạ tầng mạng theo yêu cầu.

⚠ Điểm mấu chốt — template là bản mô tả nhân bản được vô hạn:

Một template mô tả toàn bộ mạng:
        VPC, subnet, route table, IGW, NAT Gateway,
        security group, NACL, VPC endpoint
        ↓
    Tạo stack với tham số MoiTruong = "dev"
        ↓
    Tạo stack với tham số MoiTruong = "staging"
        ↓
    → hai môi trường GIỐNG HỆT NHAU về cấu trúc
    → khác nhau ở CIDR, tên, kích thước — do tham số quyết định
        ↓
    → xoá stack là dọn sạch, không sót tài nguyên nào

⚠ Và những thứ khiến CloudFormation hợp với hạ tầng mạng hơn cả:

Tự tính THỨ TỰ PHỤ THUỘC
        ↓
    → IGW phải có trước route table trỏ tới nó
    → NAT Gateway phải có subnet và Elastic IP trước
    → bạn không phải sắp xếp gì cả

Xoá stack = dọn theo THỨ TỰ NGƯỢC LẠI
        ↓
    → không còn ENI mồ côi, không còn Elastic IP bị bỏ quên

Template nằm trong Git
        ↓
    → có lịch sử thay đổi, có code review, có rollback

⚠ Kết hợp với cross-stack reference cho kiến trúc sạch:

Stack MẠNG      → export VpcId, SubnetIds
Stack BẢO MẬT   → export SecurityGroupIds
Stack ỨNG DỤNG  → ImportValue từ hai stack trên
        ↓
    → triển khai lại ứng dụng KHÔNG đụng tới mạng

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

• B (AWS Service Catalog) — đây là phương án gần nhất và thường được dùng CÙNG với CloudFormation. Nhưng Service Catalog là lớp phía trên: nó quản lý danh mục các template đã được duyệt để người dùng tự cấp phát. Bản thân nó không định nghĩa hạ tầng — nội dung của mỗi product vẫn là một CloudFormation template.

• A (Elastic Beanstalk) — nền tảng triển khai ỨNG DỤNG: bạn đưa mã lên, nó lo EC2, ELB, ASG. Nó không dùng để mô tả hạ tầng mạng tuỳ ý.

• C (AWS Config) — dịch vụ theo dõi và đánh giá cấu hình, cho biết tài nguyên có đúng chuẩn hay không. Nó không tạo ra hạ tầng nào.

Ghi nhớ

⚠ Các công cụ hạ tầng dạng mã trên AWS — bảng phải thuộc: | Công cụ | Nội dung | |---|---| | CloudFormation | template JSON/YAML — chuẩn của AWS | | AWS CDK | viết bằng TypeScript, Python, Java… → sinh ra CloudFormation | | AWS SAM | mở rộng CloudFormation cho serverless | | Terraform | công cụ của HashiCorp, đa nhà cung cấp | | Service Catalog | lớp quản trị phía trên template đã duyệt |

Từ khoá nhận diện:

"nhân bản hạ tầng, môi trường theo yêu cầu" → CloudFormation "người dùng tự cấp phát theo danh mục đã duyệt" → Service Catalog "triển khai ứng dụng, không quan tâm hạ tầng" → Elastic Beanstalk "kiểm tra cấu hình có đúng chuẩn không" → AWS Config "triển khai ra nhiều tài khoản và Region" → StackSets

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Template có hợp lệ không | validate-template, và cfn-lint | | Update sẽ động vào gì | tạo change set, đọc cột Replacement | | Có ai sửa tay không | detect-stack-drift |

Và một thói quen đáng xây dựng ngay từ template đầu tiên: chạy detect-stack-drift định kỳ cho mọi stack hạ tầng mạng. Toàn bộ giá trị của hạ tầng dạng mã nằm ở giả định "template chính là thực tế" — và chỉ cần một người sửa tay một luật security group trong lúc xử lý sự cố là giả định đó đã sai, một cách âm thầm, cho tới lần triển khai tiếp theo khi CloudFormation lặng lẽ khôi phục lại trạng thái cũ và làm hỏng thứ mà người kia đã sửa.

Đáp án

B, D — hai điều đúng khi tạo và cấu hình StackSets:

• D — Phải thiết lập QUAN HỆ TIN CẬY giữa tài khoản quản trị và tài khoản đích TRƯỚC khi tạo stack ở tài khoản đích.
• B — Với stack set dùng service-managed permissions, bạn KHÔNG phải tự tạo các IAM role.

Vì sao đúng

StackSets có hai mô hình quyền, và sự khác biệt giữa chúng là toàn bộ nội dung câu hỏi.

⚠ Hai mô hình quyền — bảng quyết định:

SELF-MANAGED permissions
        ↓
    BẠN tự tạo hai IAM role:
        - AWSCloudFormationStackSetAdministrationRole  (ở tài khoản quản trị)
        - AWSCloudFormationStackSetExecutionRole       (ở MỖI tài khoản đích)
        ↓
    Và phải thiết lập TRUST giữa chúng      ← điều D
        ↓
    → dùng khi các tài khoản KHÔNG thuộc cùng một Organization

SERVICE-MANAGED permissions
        ↓
    AWS TỰ TẠO và TỰ QUẢN các role cần thiết   ← điều B
        ↓
    → chỉ dùng được khi có AWS Organizations
    → triển khai theo OU, tài khoản MỚI thêm vào OU
      được TỰ ĐỘNG triển khai (automatic deployment)

⚠ Điều D đúng với cả hai mô hình:

Dù tự tạo role hay để AWS tạo
        ↓
    Vẫn phải có QUAN HỆ TIN CẬY giữa
    tài khoản quản trị và tài khoản đích
        ↓
    → self-managed: bạn tự viết trust policy
    → service-managed: AWS thiết lập qua Organizations
        ↓
    → thiếu trust là không triển khai được stack nào

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

• E (với self-managed permissions, bạn KHÔNG phải tạo IAM role) — đây là phương án gần nhất và đảo ngược đúng ý nghĩa của hai mô hình. Chính self-managed mới là mô hình bạn PHẢI tự tạo role; service-managed mới là mô hình AWS lo hộ.

• A (stack set tạo được bằng self-managed, service-managed hoặc resource-managed permissions) — "resource-managed" KHÔNG TỒN TẠI. Chỉ có hai mô hình quyền.

• C (khi xoá stack khỏi stack set nhưng giữ lại để chạy độc lập, chúng phải quản ở mức từng tài nguyên và không còn trong CloudFormation) — sai: khi bạn giữ lại stack (--retain-stacks), chúng vẫn là stack CloudFormation bình thường ở tài khoản đích, chỉ là không còn thuộc stack set nữa. Bạn quản lý chúng như mọi stack khác.

Ghi nhớ

⚠ Hai mô hình quyền của StackSets — bảng phải thuộc: | | Self-managed | Service-managed | |---|---|---| | Ai tạo IAM role | BẠN | AWS | | Cần Organizations | không | CÓ | | Triển khai theo | danh sách tài khoản | OU | | Tài khoản mới trong OU | phải thêm tay | TỰ ĐỘNG triển khai | | Dùng khi | tài khoản ngoài tổ chức | đã có Organizations |

Từ khoá nhận diện:

"AWS tự tạo role" → service-managed "tự tạo AdministrationRole và ExecutionRole" → self-managed "tài khoản mới tự động được triển khai" → service-managed + automatic deployment "resource-managed permissions" → KHÔNG TỒN TẠI "triển khai một stack ra nhiều tài khoản và Region" → StackSets

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Stack set dùng mô hình nào | describe-stack-set, xem PermissionModel | | Tài khoản nào triển khai thành công | list-stack-instances, xem Status | | Vì sao một tài khoản thất bại | describe-stack-instance — đọc StatusReason |

Và một lời khuyên khi triển khai StackSets ra quy mô lớn: luôn đặt FailureTolerancePercentage thấp và triển khai Region tuần tự cho lần đầu tiên. Một template có lỗi được đẩy đồng thời xuống năm mươi tài khoản ở mười Region sẽ tạo ra năm trăm stack thất bại cần dọn dẹp — trong khi cùng template đó với ngưỡng lỗi bằng 0 sẽ dừng lại sau tài khoản đầu tiên và để bạn sửa trong yên bình.

Đáp án

C — Cần cấu hình cache behavior của CloudFront để CHUYỂN TIẾP TẤT CẢ COOKIE tới origin.

Vì sao đúng

Nguyên nhân nằm ở chỗ CloudFront mặc định KHÔNG chuyển tiếp cookie — và sticky session của ALB thì hoạt động bằng cookie.

⚠ Điểm mấu chốt — chuỗi phụ thuộc bị đứt ở giữa:

ALB sticky session hoạt động bằng cookie AWSALB
        ↓
    ALB gắn cookie vào phản hồi
        ↓
    CloudFront nhận phản hồi, chuyển về client
        ↓
    Client gửi request tiếp theo KÈM cookie
        ↓
    CloudFront LOẠI BỎ cookie (mặc định)   ← chỗ đứt
        ↓
    ALB không thấy cookie → chọn target NGẪU NHIÊN
        ↓
    → phiên làm việc nằm ở máy khác → BẮT ĐĂNG NHẬP LẠI

⚠ Cách sửa — dùng cache policy và origin request policy:

Cách hiện đại (khuyến nghị):
    Origin Request Policy → CookiesConfig: all
        ↓
    → chuyển tiếp mọi cookie tới origin
      MÀ KHÔNG đưa chúng vào khoá cache

    Cache Policy → CookiesConfig: none (hoặc chỉ cookie cần thiết)
        ↓
    → cache vẫn hiệu quả

Cách cũ (legacy cache settings):
    Forward Cookies = All
        ↓
    → cookie đi vào KHOÁ CACHE
    → mỗi người dùng một bản cache riêng
    → TỶ LỆ TRÚNG CACHE gần như bằng 0

⚠ Đây chính là chỗ đánh đổi quan trọng nhất:

Đưa cookie vào KHOÁ CACHE
        ↓
    → mỗi tổ hợp cookie là một mục cache riêng
    → cookie phiên là duy nhất cho mỗi người
        ↓
    → CloudFront gần như không cache được gì
        ↓
    Vì vậy: tách "cái gì gửi tới origin" khỏi
            "cái gì tạo nên khoá cache"

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

• B (bật sticky session trên chính CloudFront distribution) — đây là phương án gần nhất vì nó nhắm đúng vào khái niệm sticky session. Nhưng CloudFront KHÔNG có tính năng sticky session: nó là CDN, không phải load balancer. Việc gắn phiên với target là chuyện của ALB.

• D (cấu hình CloudFront cache ở edge để giảm nhu cầu xác thực lại) — cache làm vấn đề tệ hơn: nếu CloudFront trả nội dung đã cache thì request thậm chí không tới ALB, và trang cá nhân hoá của người này có thể bị phục vụ cho người khác.

• A (dùng Origin Shield để chuyển tiếp thông tin xác thực tới ALB) — Origin Shield là một lớp cache trung gian giúp giảm tải cho origin. Nó không liên quan tới việc chuyển tiếp cookie.

Ghi nhớ

⚠ CloudFront chuyển tiếp gì tới origin — mặc định là gần như không gì cả: | Thành phần | Mặc định | |---|---| | Cookie | KHÔNG chuyển tiếp | | Query string | KHÔNG chuyển tiếp | | Header | chỉ một số header tối thiểu | | Lý do | để tối đa hoá tỷ lệ trúng cache |

Từ khoá nhận diện:

"đăng nhập lại liên tục sau CloudFront" → cookie không được chuyển tiếp "nội dung cá nhân hoá bị lẫn giữa người dùng" → cache sai khoá — kiểm tra cache policy "sticky session trên CloudFront" → KHÔNG TỒN TẠI "giảm tải cho origin" → Origin Shield "nội dung khác nhau theo thiết bị" → header CloudFront-Is-Mobile-Viewer

⚠ Hai loại policy của CloudFront — hiểu đúng là giải quyết được hầu hết vấn đề: | Policy | Quyết định | |---|---| | Cache Policy | cái gì tạo nên KHOÁ CACHE (và TTL) | | Origin Request Policy | cái gì được GỬI TỚI ORIGIN | | Mẹo quan trọng | thứ trong origin request policy mà không có trong cache policy thì được gửi đi mà không phá cache | | Response Headers Policy | header thêm vào phản hồi (CORS, bảo mật) |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cookie có tới origin không | ALB access log — xem có cookie trong request không | | Tỷ lệ trúng cache | chỉ số CacheHitRate của CloudFront | | Cache hit hay miss | header X-Cache trong phản hồi |

Và một cảnh báo về cách sửa vội vàng cho loại sự cố này: đừng bật "Forward all cookies" trong cache settings kiểu cũ rồi coi là xong. Nó sửa được lỗi đăng nhập, nhưng đồng thời đưa cookie phiên vào khoá cache — nghĩa là mỗi người dùng có một bản cache riêng, tỷ lệ trúng cache tụt về gần 0, và bạn vừa trả tiền cho một CDN không còn cache gì cả. Hãy dùng origin request policy để tách hai chuyện đó ra.

Đáp án

A, E, F — ba điều đúng về template này:

• A — Template tạo một bucket S3 được cấu hình làm WEBSITE.
• F — CloudFormation sẽ KHÔNG xoá bucket này khi xoá stack.
• E — Khi chạy từ AWS CLI, URL của website trên S3 sẽ được hiển thị ở phần output.

Vì sao đúng

⚠ Điều A — WebsiteConfiguration là dấu hiệu rõ ràng:

WebsiteConfiguration:
  IndexDocument: index.html
  ErrorDocument: error.html

    → bật static website hosting cho bucket
    → tạo ra WEBSITE ENDPOINT (bucket.s3-website-<region>.amazonaws.com)
        ↓
    Kèm bucket policy cho phép "s3:GetObject" với Principal "*"
        ↓
    → ai cũng đọc được nội dung → đúng nghĩa một website công khai

⚠ Điều F — DeletionPolicy: Retain là câu trả lời:

DeletionPolicy: Retain

    → khi xoá stack, CloudFormation GIỮ LẠI bucket
        ↓
    → bucket trở thành TÀI NGUYÊN MỒ CÔI
    → không còn stack nào quản, phải tự dọn tay
        ↓
    Đây chính là chỗ phân biệt điều F (đúng) với điều D (sai)

⚠ Điều E — mục Outputs in ra sau khi stack tạo xong:

Outputs:
  WebsiteURL:
    Value: !GetAtt [S3Bucket, WebsiteURL]

    aws cloudformation describe-stacks --stack-name <ten>
        ↓
    → phần Outputs hiển thị URL của website
        ↓
    (Console cũng hiện ở tab "Outputs" của stack)

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

• D (CloudFormation sẽ XOÁ bucket khi xoá stack) — đây là phương án gần nhất và trực tiếp mâu thuẫn với điều F. Nó sẽ đúng nếu template không có DeletionPolicy, vì mặc định là Delete. Nhưng template này khai rõ Retain.

• C (mục Outputs truyền URL cho stack khác trong cấu hình nested stack) — mục Outputs ở đây không có trường Export, nên không stack nào import được. Nó chỉ hiển thị giá trị cho người đọc.

• B (bucket được cấu hình để lưu đối tượng từ "PublicRead API của Amazon RDS") — vô nghĩa về mặt kỹ thuật: PublicRead là một giá trị ACL của S3, không phải API, và RDS hoàn toàn không liên quan.

Ghi nhớ

⚠ Ba DeletionPolicy — bảng phải thuộc: | Giá trị | Khi xoá stack | |---|---| | Delete (mặc định) | xoá tài nguyên | | Retain | GIỮ LẠI — trở thành tài nguyên mồ côi | | Snapshot | chụp snapshot rồi mới xoá — RDS, EBS, ElastiCache, Redshift |

Từ khoá nhận diện:

"DeletionPolicy: Retain" → tài nguyên KHÔNG bị xoá theo stack "WebsiteConfiguration" → static website hosting, WEBSITE endpoint "Outputs không có Export" → chỉ để hiển thị, stack khác KHÔNG import được "!GetAtt" → lấy thuộc tính của tài nguyên "!Ref cho S3 bucket" → trả về TÊN bucket

⚠ Một lưu ý về template này trong bối cảnh hiện nay:

Template dùng "AccessControl: PublicRead" (ACL)
        ↓
    Từ tháng 4/2023, AWS BẬT SẴN Block Public Access
    và đặt Object Ownership = BucketOwnerEnforced
        ↓
    → ACL bị VÔ HIỆU HOÁ
    → template này có thể THẤT BẠI khi chạy trên tài khoản mới
        ↓
    Cách làm hiện đại:
        - bỏ AccessControl, chỉ dùng bucket policy
        - hoặc tốt hơn: đặt CloudFront + OAC phía trước
          và giữ bucket HOÀN TOÀN riêng tư

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem output của stack | describe-stacks --stack-name <ten> --query 'Stacks[0].Outputs' | | Tài nguyên nào sẽ được giữ | rà template tìm DeletionPolicy | | Bucket còn sau khi xoá stack không | list-buckets sau khi delete-stack |

Và một lưu ý về hệ quả của Retain mà nhiều người không nghĩ tới: tài nguyên được giữ lại sẽ trở thành mồ côi và VẪN TÍNH TIỀN. Với một bucket website thì khoản đó nhỏ, nhưng cùng chính sách ấy áp cho RDS hay NAT Gateway thì bạn có một tài nguyên không ai quản, không ai nhớ, và tiếp tục xuất hiện trong hoá đơn mỗi tháng cho tới khi có người tình cờ tìm ra nó.

Đáp án

D — Bạn phải đặt TÊN BUCKET S3 GIỐNG HỆT tên bản ghi DNS mà bạn muốn dùng để định tuyến lưu lượng tới bucket đó.

Vì sao đúng

Đây là một ràng buộc cứng của S3 static website hosting, và nó là nguyên nhân phổ biến nhất của lỗi này.

⚠ Điểm mấu chốt — tên bucket phải khớp CHÍNH XÁC tên miền:

Muốn phục vụ website tại: www.congty.com
        ↓
    Bucket PHẢI có tên: www.congty.com
        ↓
    Muốn phục vụ tại tên miền gốc: congty.com
        ↓
    Bucket PHẢI có tên: congty.com

⚠ Vì sao lại có ràng buộc kỳ lạ này:

S3 website endpoint dùng HEADER "Host" của request
        ↓
    để xác định phục vụ bucket nào
        ↓
    Client gửi: Host: www.congty.com
        ↓
    S3 tìm bucket có TÊN đúng bằng "www.congty.com"
        ↓
    Không có → trả về lỗi "NoSuchBucket" hoặc 404
        ↓
    → đây chính là triệu chứng của đề

⚠ Cấu hình đầy đủ cho một website tĩnh trên S3:

1. Tạo bucket TÊN ĐÚNG BẰNG tên miền
2. Bật Static website hosting, khai index và error document
3. Bucket policy cho phép s3:GetObject với Principal "*"
   (và tắt Block Public Access — hoặc dùng CloudFront + OAC)
4. Route 53: tạo ALIAS record trỏ tới
   S3 WEBSITE ENDPOINT (không phải REST endpoint)

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

• B (kiểm tra bản ghi HOSTNAME có trỏ đúng website endpoint không) — đây là phương án gần nhất và trỏ đúng endpoint đúng là điều cần kiểm tra. Nhưng không có loại bản ghi DNS nào tên "HOSTNAME" — các loại thật là A, AAAA, CNAME, ALIAS, MX, TXT… Cách diễn đạt sai khiến phương án này không thể là đáp án.

• A (website endpoint cần chứng chỉ SSL cho HTTPS) — S3 website endpoint KHÔNG hỗ trợ HTTPS, nên không có chứng chỉ nào để kiểm tra. Muốn HTTPS thì phải đặt CloudFront phía trước.

• C (tên miền phải phân giải ra cùng một IP mỗi lần) — sai về nguyên lý: S3 và CloudFront cố ý trả về nhiều IP khác nhau để cân bằng tải và chịu lỗi. Đó là hành vi bình thường.

Ghi nhớ

⚠ Hai endpoint của S3 — bảng phải thuộc: | | REST endpoint | Website endpoint | |---|---|---| | Dạng | bucket.s3.<region>.amazonaws.com | bucket.s3-website-<region>.amazonaws.com | | HTTPS | CÓ | KHÔNG | | Tài liệu chỉ mục (index.html mỗi thư mục) | không | CÓ | | Trang lỗi tuỳ chỉnh | không | CÓ | | Quy tắc chuyển hướng | không | CÓ | | OAC / OAI | dùng được | KHÔNG | | Tên bucket phải khớp tên miền | không bắt buộc | BẮT BUỘC |

Từ khoá nhận diện:

"tên miền không phân giải tới website S3" → tên bucket phải bằng tên miền "cần HTTPS cho website S3" → phải dùng CloudFront "tài liệu chỉ mục cho mỗi thư mục" → website endpoint "trỏ tên miền GỐC về S3" → Route 53 ALIAS (CNAME không dùng được ở zone apex) "website S3 mà giữ bucket riêng tư" → CloudFront + OAC, và bỏ website endpoint

⚠ Kiến trúc hiện đại hơn — và nên dùng cho website thật:

CloudFront + OAC + bucket RIÊNG TƯ (REST endpoint)
        ↓
    → có HTTPS với chứng chỉ ACM (us-east-1)
    → có cache ở edge, nhanh hơn và rẻ hơn
    → bucket KHÔNG công khai — an toàn hơn hẳn
    → có WAF, geo restriction, signed URL
        ↓
    Đánh đổi: mất tài liệu chỉ mục cho thư mục con
        ↓
    → thay bằng CloudFront Function viết lại URI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Website endpoint có hoạt động không | curl http://bucket.s3-website-<region>.amazonaws.com | | DNS trỏ đi đâu | dig www.congty.com | | Bucket có công khai không | get-public-access-block và get-bucket-policy |

Và một lời khuyên về hướng đi cho website tĩnh: hãy dùng CloudFront với OAC thay vì phơi bucket ra công khai, kể cả khi nội dung vốn đã công khai. Bạn được HTTPS miễn phí, được cache ở edge, chi phí truyền dữ liệu thấp hơn, và quan trọng nhất là bucket của bạn không bao giờ xuất hiện trong danh sách "S3 bucket mở công khai" mà các công cụ quét bảo mật vẫn rà internet để tìm.

Đáp án

C — Cấu hình Amazon S3 Access Points cho các bucket.

Vì sao đúng

Đề mô tả chính xác vấn đề mà S3 Access Points sinh ra để giải: một bucket policy khổng lồ phục vụ hàng trăm ứng dụng.

⚠ Điểm mấu chốt — access point tách một chính sách lớn thành nhiều chính sách nhỏ độc lập:

Không có access point
        ↓
    MỘT bucket policy chứa quyền cho hàng trăm ứng dụng
        ↓
    → chạm giới hạn 20 KB của bucket policy
    → sửa cho ứng dụng A có thể phá ứng dụng B
    → không ai dám đụng vào

Có access point
        ↓
    Mỗi ứng dụng có MỘT access point riêng
    Mỗi access point có CHÍNH SÁCH RIÊNG của nó
        ↓
    → sửa chính sách của ứng dụng A KHÔNG ảnh hưởng ứng dụng B
    → đúng yêu cầu của đề

⚠ Mỗi access point có một tên miền riêng, ứng dụng dùng nó thay cho tên bucket:

Bucket:        s3://du-lieu-chung/
Access point:  arn:aws:s3:ap-southeast-1:111122223333:accesspoint/ung-dung-a
        ↓
    Ứng dụng gọi qua ARN của access point
        ↓
    → S3 áp CẢ bucket policy LẪN access point policy
    → quyền hiệu lực là GIAO của hai bên

⚠ Và ba khả năng nữa của access point:

Giới hạn theo TIỀN TỐ
        ↓
    access point chỉ cho phép truy cập s3://bucket/doi-tac-a/*

Giới hạn theo MẠNG
        ↓
    NetworkOrigin = VPC → chỉ gọi được từ trong VPC đó

Block Public Access riêng cho từng access point

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

• D (cấu hình VPC Endpoint cho bucket) — đây là phương án gần nhất vì nó cũng liên quan tới kiểm soát truy cập. Nhưng VPC endpoint kiểm soát truy cập theo ĐƯỜNG MẠNG (từ trong VPC, không qua internet), không tách bạch được quyền giữa hàng trăm ứng dụng. Vấn đề của đề là quản lý chính sách, không phải đường mạng.

• A (S3 Batch Operations) — dùng để thực hiện thao tác hàng loạt trên hàng triệu đối tượng (copy, đổi lớp lưu trữ, gọi Lambda). Không liên quan tới phân quyền.

• B (S3 Transfer Acceleration) — tăng tốc tải lên từ xa qua edge location. Không liên quan tới quyền.

Ghi nhớ

⚠ S3 Access Points — bảng phải thuộc: | Đặc điểm | Nội dung | |---|---| | Mục đích | tách chính sách truy cập theo từng ứng dụng | | Mỗi access point có | tên miền riêng + chính sách riêng | | Quyền hiệu lực | GIAO của bucket policy và access point policy | | NetworkOrigin | Internet hoặc VPC (chỉ gọi được từ VPC đó) | | Giới hạn tiền tố | khai trong chính sách của access point | | Số lượng | hàng nghìn access point mỗi bucket |

Từ khoá nhận diện:

"một bucket policy quá lớn, nhiều ứng dụng" → S3 Access Points "chỉ truy cập S3 từ trong VPC" → VPC endpoint, hoặc access point với NetworkOrigin=VPC "thao tác hàng loạt trên hàng triệu đối tượng" → S3 Batch Operations "tải lên từ xa chậm" → Transfer Acceleration "truy cập bucket ở nhiều Region qua một endpoint" → Multi-Region Access Points

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có những access point nào | list-access-points --bucket <ten> | | Chính sách của một access point | get-access-point-policy | | Ứng dụng có gọi qua access point không | rà mã nguồn xem dùng ARN access point hay tên bucket |

Và một lời khuyên khi chuyển đổi sang mô hình access point: hãy chuyển từng ứng dụng một, và giữ bucket policy hiện tại cho tới khi mọi ứng dụng đã đổi xong. Vì quyền hiệu lực là giao của bucket policy và access point policy, bạn có thể để hai cơ chế cùng tồn tại trong giai đoạn chuyển đổi — rồi mới thu gọn bucket policy lại thành một chính sách tối thiểu khi không còn ai gọi thẳng vào bucket nữa.

Đáp án

C — Thiết lập kết nối riêng bên trong Amazon VPC bằng cách dùng VPC endpoint.

Vì sao đúng

Đề nêu hai ràng buộc: kết nối riêng tới S3 và TIẾT KIỆM CHI PHÍ. VPC endpoint thoả cả hai.

⚠ Điểm mấu chốt — File Gateway nói chuyện với S3 qua VPC endpoint:

File Gateway (tại chỗ hoặc trên EC2)
        ↓
    Kết nối vào VPC (qua Direct Connect, VPN, hoặc chạy trong VPC)
        ↓
    Trong VPC có:
        - Interface endpoint cho Storage Gateway
        - Gateway endpoint cho S3               ← MIỄN PHÍ
        ↓
    → lưu lượng KHÔNG ra internet công cộng
    → đi trong mạng riêng của AWS

⚠ Hai loại VPC endpoint — và vì sao chọn đúng loại là tiết kiệm được nhiều tiền:

Gateway endpoint (S3, DynamoDB)
        ↓
    Thêm một TUYẾN vào route table
        ↓
    → HOÀN TOÀN MIỄN PHÍ
    → không tính phí giờ, không tính phí GB

Interface endpoint (PrivateLink, hầu hết dịch vụ khác)
        ↓
    Tạo một ENI có IP riêng trong subnet
        ↓
    → tính phí THEO GIỜ và THEO GB

⚠ Cấu hình đầy đủ cho File Gateway dùng VPC endpoint:

1. Interface endpoint cho storagegateway
       com.amazonaws.<region>.storagegateway
       → để gateway liên lạc với mặt phẳng điều khiển

2. Gateway endpoint cho S3 (MIỄN PHÍ)
       com.amazonaws.<region>.s3
       → để dữ liệu đi thẳng vào S3 không qua internet

3. Security Group cho phép gateway tới các endpoint

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

• D (dùng Direct Connect để truy cập S3 riêng tư) — đây là phương án gần nhất và về kỹ thuật thì đúng: public VIF của Direct Connect truy cập S3 qua cáp riêng. Nhưng nó đắt hơn rất nhiều — phí cổng theo giờ cộng phí đối tác viễn thông — và mất hàng tuần tới hàng tháng để triển khai. Đề hỏi cách tiết kiệm chi phí.

• B (dùng Transit Gateway để truy cập S3 riêng tư) — Transit Gateway nối nhiều VPC và mạng tại chỗ với nhau. Nó không phải cơ chế truy cập S3, và tự nó cũng tốn phí gắn kết cộng phí xử lý dữ liệu.

• A (dùng VPC Peering giữa tại chỗ và AWS) — hiểu sai khái niệm: VPC peering nối hai VPC, không nối trung tâm dữ liệu tại chỗ với AWS.

Ghi nhớ

⚠ Hai loại VPC endpoint — bảng phải thuộc: | | Gateway endpoint | Interface endpoint (PrivateLink) | |---|---|---| | Dịch vụ | CHỈ S3 và DynamoDB | hầu hết dịch vụ AWS | | Chi phí | MIỄN PHÍ | theo giờ + theo GB | | Cơ chế | thêm tuyến vào route table | ENI có IP riêng trong subnet | | Máy tại chỗ dùng được | KHÔNG | CÓ (qua DX/VPN) | | DNS | dùng tên công khai | có private DNS | | Bảo mật | endpoint policy | endpoint policy + Security Group |

Từ khoá nhận diện:

"truy cập S3 riêng tư từ TRONG VPC, rẻ nhất" → gateway endpoint (miễn phí) "truy cập S3 riêng tư từ TẠI CHỖ" → interface endpoint, hoặc Direct Connect public VIF "gọi dịch vụ AWS khác không ra internet" → interface endpoint "lộ dịch vụ của mình cho tài khoản khác" → PrivateLink endpoint service "nối nhiều VPC" → Transit Gateway hoặc peering

⚠ Mẹo tiết kiệm chi phí lớn nhất liên quan tới endpoint:

VPC có NAT Gateway và fleet đọc ghi S3 nhiều
        ↓
    Không có gateway endpoint
        ↓
    → mọi lưu lượng tới S3 đi qua NAT Gateway
    → tính phí XỬ LÝ DỮ LIỆU theo từng GB
        ↓
    Thêm gateway endpoint cho S3 (MIỄN PHÍ)
        ↓
    → lưu lượng S3 đi thẳng, KHÔNG qua NAT
    → cắt được một khoản đáng kể mỗi tháng
        ↓
    → nên làm cho MỌI VPC có NAT Gateway

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Endpoint đã tạo chưa | describe-vpc-endpoints | | Route table đã có tuyến chưa | gateway endpoint thêm tuyến vào route table — kiểm tra đúng bảng | | Lưu lượng có đi qua endpoint không | VPC Flow Logs — thấy đích là IP nội bộ của endpoint |

Và một việc nên làm ngay hôm nay trong mọi VPC đang có NAT Gateway: thêm gateway endpoint cho S3 và DynamoDB. Chúng hoàn toàn miễn phí, cấu hình mất vài phút, và với một fleet thường xuyên đọc ghi S3 thì chúng cắt đi phần lớn khoản phí xử lý dữ liệu của NAT — một khoản mà rất nhiều đội trả đều đặn hằng tháng suốt nhiều năm mà không biết rằng nó hoàn toàn tránh được.