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

Đáp án

A, E — hai điểm đúng về retention period của S3 Object Lock:

• E — Khi áp retention TƯỜNG MINH cho một phiên bản đối tượng, bạn khai một "Retain Until Date" cho phiên bản đó.
• A — Các PHIÊN BẢN KHÁC NHAU của cùng một đối tượng có thể có chế độ và thời hạn retention KHÁC NHAU.

Vì sao đúng

Cả hai điểm đều xoay quanh một sự thật nền tảng: Object Lock áp ở mức PHIÊN BẢN, không phải mức đối tượng.

⚠ Điểm mấu chốt — mỗi phiên bản là một đơn vị bảo vệ độc lập:

tai-lieu.pdf
   ├── phiên bản v1 → Compliance, giữ tới 2031
   ├── phiên bản v2 → Governance, giữ tới 2027
   └── phiên bản v3 → không có retention
        ↓
    → ba phiên bản, ba chế độ khác nhau  ← điều A
    → hoàn toàn hợp lệ và đúng thiết kế

Đây cũng là lý do Object Lock bắt buộc phải bật versioning: không có phiên bản thì không có đơn vị để gắn thời hạn.

⚠ Điều E — hai cách khai thời hạn, và chúng khai bằng hai đại lượng khác nhau:

Áp TƯỜNG MINH cho một phiên bản
        ↓
    Khai "Retain Until Date" — một MỐC NGÀY cụ thể
        aws s3api put-object-retention \
          --bucket kho --key tai-lieu.pdf --version-id xxx \
          --retention '{"Mode":"COMPLIANCE",
                        "RetainUntilDate":"2031-09-02T00:00:00Z"}'

Áp qua BUCKET DEFAULT SETTINGS
        ↓
    Khai một KHOẢNG THỜI GIAN — số ngày hoặc số năm
        ↓
    S3 tự tính mốc ngày = thời điểm ghi + khoảng đó

Chính khác biệt này khiến phương án B sai.

⚠ Và thứ tự ưu tiên — nguồn gốc của việc "quy tắc không chạy như mong đợi" trong đề:

Retention TƯỜNG MINH trên một phiên bản
        ↓
    LUÔN THẮNG cấu hình mặc định của bucket
        ↓
    → bucket default chỉ áp cho đối tượng ghi mới
      mà KHÔNG khai retention riêng

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

• C (cấu hình mặc định của bucket sẽ GHI ĐÈ mọi retention tường minh) — đây là phương án gần nhất và ngược hẳn thực tế: retention tường minh luôn thắng cấu hình mặc định. Nếu đúng như phương án này thì sẽ không ai đặt được thời hạn riêng cho một tài liệu cụ thể.

• B (dùng bucket default settings thì bạn khai một "Retain Until Date") — sai ở đại lượng: bucket default khai bằng số ngày hoặc số năm, không phải một mốc ngày cố định. Một mốc ngày cố định cho mọi đối tượng tương lai cũng vô nghĩa.

• D (không đặt retention cho một phiên bản qua bucket default được) — sai; đó chính là công dụng của bucket default: mọi phiên bản ghi mới tự động nhận thời hạn.

Ghi nhớ

⚠ Hai chế độ của S3 Object Lock — bảng phải thuộc: | Chế độ | Ai gỡ được trước hạn | |---|---| | Governance | principal có s3:BypassGovernanceRetention | | Compliance | KHÔNG AI — kể cả tài khoản gốc |

Từ khoá nhận diện:

"giữ đủ N năm, không ai xoá được" → Object Lock chế độ Compliance "cho phép quản trị viên gỡ khi cần" → chế độ Governance "tranh chấp pháp lý, chưa biết bao lâu" → Legal Hold (không có thời hạn) "Object Lock mà tắt versioning" → LUÔN SAI "bucket default ghi đè retention riêng" → LUÔN SAI, tường minh thắng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Vì sao xoá được / không xoá được | so retention tường minh với bucket default | | Có bao nhiêu phiên bản đang bị khoá | S3 Inventory | | Ai đã đặt retention | CloudTrail PutObjectRetention |

Và một cảnh báo tương xứng với sức mạnh của tính năng này: chế độ Compliance là không thể đảo ngược, và mọi phiên bản bị khoá đều tiếp tục tính tiền lưu trữ cho tới ngày hết hạn. Đặt nhầm 50 năm thay vì 5 năm nghĩa là bạn vừa cam kết trả tiền cho khối dữ liệu đó tới tận nửa thế kỷ sau, và cách duy nhất để ngừng trả là đóng cả tài khoản AWS — hãy luôn thử ở Governance trước, và chỉ chuyển sang Compliance khi con số đã được duyệt bằng văn bản.

Đáp án

D — Multi-AZ dùng sao chép ĐỒNG BỘ và trải trên ÍT NHẤT HAI Availability Zone trong cùng một Region. Read replica dùng sao chép BẤT ĐỒNG BỘ và có thể nằm cùng AZ, khác AZ, hoặc khác Region.

Vì sao đúng

Câu này kiểm tra đúng hai trục phân biệt hai tính năng dễ nhầm nhất của RDS.

⚠ Trục thứ nhất — kiểu sao chép:

Multi-AZ: ĐỒNG BỘ (synchronous)
        ↓
    Ứng dụng gửi COMMIT
        ↓
    Ghi vào máy chính VÀ standby
        ↓
    Chỉ khi CẢ HAI xong mới báo thành công
        ↓
    → KHÔNG mất giao dịch nào khi failover
    → nhưng độ trễ ghi cao hơn một chút

Read replica: BẤT ĐỒNG BỘ (asynchronous)
        ↓
    Máy chính báo commit NGAY, không chờ replica
        ↓
    → độ trễ ghi không đổi
    → nhưng replica có thể TRỄ, và có thể mất giao dịch
      nếu máy chính chết đột ngột

⚠ Trục thứ hai — phạm vi địa lý:

Multi-AZ: ÍT NHẤT hai AZ, TRONG CÙNG một Region
        ↓
    → chống được sự cố cấp AZ
    → KHÔNG chống được sự cố cấp Region

Read replica: linh hoạt hơn nhiều
        ↓
    - cùng AZ         → chia tải đọc, độ trễ thấp nhất
    - khác AZ         → thêm khả năng chịu lỗi
    - KHÁC REGION     → khôi phục thảm hoạ cấp Region,
                        và phục vụ người dùng ở gần hơn

Ba phương án còn lại đều sai vì đảo ngược một trong hai trục này.

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

• A (Multi-AZ bất đồng bộ, read replica bất đồng bộ) — đây là phương án gần nhất và vế read replica hoàn toàn đúng, nhưng vế Multi-AZ sai: Multi-AZ là ĐỒNG BỘ — đó chính là điều làm nên cam kết "không mất giao dịch đã commit".

• B (Multi-AZ bất đồng bộ, read replica đồng bộ) — đảo ngược cả hai vế.

• C (Multi-AZ bất đồng bộ và chỉ trải MỘT AZ) — sai nặng nhất: nếu chỉ nằm trong một AZ thì cái tên "Multi-AZ" đã vô nghĩa, và nó không chống được sự cố AZ nào.

Ghi nhớ

⚠ Multi-AZ và Read Replica — bảng phải thuộc, đây là câu hỏi RDS kinh điển nhất: | | Multi-AZ | Read Replica | |---|---|---| | Sao chép | ĐỒNG BỘ | BẤT ĐỒNG BỘ | | Mục đích | sẵn sàng cao | chia tải đọc | | Phục vụ đọc | KHÔNG (standby chờ) | CÓ | | Failover | tự động | phải promote thủ công | | Phạm vi | ≥2 AZ, cùng Region | cùng AZ / khác AZ / KHÁC REGION | | Số lượng | 1 standby | tối đa 5 (Aurora: 15) | | Mất dữ liệu khi chuyển | không | có thể | | Loại instance | giống máy chính | khác được |

Từ khoá nhận diện:

"không mất giao dịch đã commit" → Multi-AZ (đồng bộ) "chia tải đọc, báo cáo nặng" → Read Replica "chịu được mất cả một Region" → cross-Region read replica hoặc Aurora Global Database "Multi-AZ chia tải đọc" → LUÔN SAI "read replica tự failover" → SAI, phải promote thủ công "cả hai" → dùng đồng thời được, và thường nên vậy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Multi-AZ đã bật chưa | describe-db-instances, xem MultiAZ | | Replica trễ bao nhiêu | chỉ số ReplicaLag | | Failover thật mất bao lâu | reboot-db-instance --force-failover rồi bấm giờ |

Và một cách nhớ đơn giản không bao giờ nhầm: Multi-AZ là bản sao để CHỊU LỖI, Read Replica là bản sao để CHỊU TẢI. Bản sao chịu lỗi phải giống hệt bản gốc từng giao dịch nên nó phải đồng bộ và nằm gần; bản sao chịu tải chỉ cần "đủ mới" nên nó được phép bất đồng bộ và nằm xa — hai mục đích khác nhau dẫn tới hai thiết kế khác nhau, và mọi đặc tính trong bảng đều suy ra từ đó.

Đáp án

D — Security Group của instance ở VPC1 phải được cấu hình cho phép lưu lượng VÀO từ tài nguyên ở VPC2. Network ACL mặc định cho phép mọi lưu lượng vào và ra, nên NACL mặc định của VPC1 không cần sửa gì.

Vì sao đúng

Phương án này mô tả đúng cả hai lớp lọc và hành vi mặc định của mỗi lớp.

⚠ Điểm mấu chốt — hai lớp lọc, hai hành vi mặc định trái ngược nhau:

Security Group (mặc định)
        ↓
    Chặn HẾT chiều VÀO
    Cho HẾT chiều RA
        ↓
    → muốn VPC2 vào được thì PHẢI thêm luật inbound

Network ACL mặc định
        ↓
    Cho HẾT cả hai chiều
        ↓
    → không cần sửa gì

Nhớ cách này: Security Group mặc định là "đóng", Network ACL mặc định là "mở".

⚠ Và cách viết luật inbound cho đúng chuẩn:

Nếu hai VPC CÙNG REGION và đã peering
        ↓
    → tham chiếu THẲNG security group của VPC2
        (Source = sg-xxxxxxxx)
        ↓
    → máy mới ở VPC2 tự động được phép, không phải sửa luật

Nếu khác Region
        ↓
    → tham chiếu SG chéo VPC KHÔNG dùng được
    → phải khai theo dải CIDR của VPC2

⚠ Nhưng đừng quên: SG và NACL chỉ là hai trong ba điều kiện:

1. Route table — hai VPC phải có ĐƯỜNG ĐI tới nhau
       (peering, Transit Gateway, hoặc VPN)
2. Network ACL — cả hai chiều, ở cả hai subnet
3. Security Group — luật inbound ở phía đích
        ↓
    Thiếu bất kỳ điều nào → không thông
    Đề chỉ hỏi về hai lớp lọc, nhưng thực tế phải đủ ba

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

• C (SG mặc định cho hết chiều ra nên chỉ cần sửa inbound; nếu subnet không gắn NACL nào thì không cần sửa gì) — đây là phương án gần nhất và vế đầu hoàn toàn đúng. Nhưng vế sau sai về kỹ thuật: mọi subnet LUÔN gắn với một NACL — nếu bạn không khai thì nó dùng NACL mặc định của VPC. Không có subnet nào "không có NACL".

• A (NACL và Security Group có quan hệ cha–con, cấp quyền ở NACL thì SG tự có theo) — bịa hoàn toàn. Hai lớp này độc lập và được xét theo kiểu AND: gói tin phải qua được cả hai.

• B (tạo luật DENY trên Security Group) — Security Group KHÔNG CÓ luật Deny. Nó chỉ có Allow; những gì không được cho phép thì mặc nhiên bị chặn. Muốn Deny tường minh thì phải dùng NACL.

Ghi nhớ

⚠ Security Group và Network ACL — bảng phải thuộc: | | Security Group | Network ACL | |---|---|---| | Gắn vào | ENI (instance) | subnet | | Trạng thái | STATEFUL — nhớ kết nối | STATELESS — xét từng gói | | Luật | CHỈ có Allow | có cả Allow và Deny | | Mặc định | chặn vào, cho ra | cho cả hai chiều | | Thứ tự xét | xét tất cả luật | theo số thứ tự, dừng ở luật khớp đầu tiên | | Chặn một IP cụ thể | KHÔNG làm được | làm được | | Tham chiếu SG khác | CÓ | không |

Từ khoá nhận diện:

"chặn một địa chỉ IP xấu" → NACL (SG không có Deny) "SG có luật Deny" → LUÔN SAI "subnet không có NACL" → SAI, luôn có NACL mặc định "NACL và SG là quan hệ cha–con" → LUÔN SAI, độc lập và xét AND "request vào được mà không có phản hồi" → NACL outbound thiếu cổng tạm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Luật SG thật sự là gì | describe-security-groups — đọc JSON, đừng chỉ liếc console | | NACL có bị sửa không | describe-network-acls, xem có luật Deny nào | | Gói bị bỏ ở đâu | VPC Flow Logs, tìm bản ghi REJECT |

Và một lời khuyên khi viết luật: hãy tham chiếu security group thay vì dải CIDR bất cứ khi nào có thể. Luật viết theo CIDR trở nên sai ngay khi ai đó thêm subnet mới hoặc đổi dải địa chỉ, và nó không nói lên ý định — trong khi một luật ghi "cho phép SG của tầng ứng dụng" vừa tự đúng khi fleet co giãn, vừa tự giải thích cho người đọc nó sáu tháng sau.

Đáp án

A, D — hai cách giới hạn nội dung cho người đăng ký:

• D — Dùng CloudFront signed URL.
• A — Dùng CloudFront signed cookie.

Vì sao đúng

Đề hỏi cách chỉ phát nội dung cho người đã đăng ký dịch vụ — tức là kiểm soát TRUY CẬP, không phải mã hoá đường truyền.

⚠ Điểm mấu chốt — signed URL và signed cookie là hai mặt của cùng một cơ chế:

Ứng dụng của bạn xác thực người đăng ký
        ↓
    Ký bằng khoá riêng (private key) của một key pair đã đăng ký
        ↓
    Tạo ra một "policy" nhúng trong URL hoặc cookie:
        - hết hạn lúc nào
        - (tuỳ chọn) chỉ cho phép từ dải IP nào
        - (tuỳ chọn) chỉ có hiệu lực sau thời điểm nào
        ↓
    CloudFront kiểm chứng chữ ký ở EDGE
        ↓
    → không hợp lệ hoặc hết hạn → 403

⚠ Chọn cái nào — đây là câu hỏi rất hay gặp:

Với một dịch vụ phát video như đề, signed cookie thường là lựa chọn thực tế: một video HLS gồm hàng nghìn tệp .ts, ký từng cái một là không khả thi.

⚠ Và đừng quên khoá cửa sau — nếu không thì mọi thứ vô nghĩa:

Signed URL/cookie bảo vệ đường qua CloudFront
        ↓
    Nhưng nếu bucket S3 vẫn công khai
        ↓
    → người ta gọi thẳng URL S3, bỏ qua CloudFront hoàn toàn
        ↓
    → phải dùng OAC + Block Public Access

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

(Ba phương án còn lại đều nói về mã hoá đường truyền, không phải kiểm soát truy cập.)

• C (bắt buộc HTTPS giữa CloudFront và custom origin) — đây là phương án gần nhất vì HTTPS đúng là một biện pháp bảo mật thật và nên bật. Nhưng nó bảo vệ dữ liệu trên đường truyền, hoàn toàn không giới hạn ai được xem.

• E (bắt buộc HTTPS giữa CloudFront và S3 origin) — cùng lý do.

• B (chuyển tiếp request HTTPS tới origin bằng bộ mã ECDSA hoặc RSA) — nói về thuật toán mã hoá TLS, còn xa hơn nữa khỏi câu hỏi.

Ghi nhớ

⚠ Bốn lớp kiểm soát truy cập của CloudFront — bảng phải thuộc: | Lớp | Việc | |---|---| | Signed URL / signed cookie | chỉ người có chữ ký hợp lệ mới xem được | | OAC (hoặc OAI) | chỉ CloudFront được vào origin S3 | | Geo restriction | chặn hoặc cho phép theo quốc gia | | AWS WAF | chặn request độc hại, giới hạn tần suất |

Từ khoá nhận diện:

"chỉ người đăng ký mới xem được" → signed URL / signed cookie "nhiều tệp, một phiên (video streaming)" → signed COOKIE "một tệp, một link tải" → signed URL "chỉ CloudFront được vào S3" → OAC "chặn theo quốc gia" → geo restriction "HTTPS" → mã hoá đường truyền, KHÔNG phải kiểm soát truy cập

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chữ ký có hợp lệ không | gọi thử URL — sai thì nhận 403 | | Vào thẳng origin có bị chặn không | curl URL S3 — phải 403 | | Vì sao bị từ chối | CloudFront access log, cột x-edge-detailed-result-type |

Và một lời khuyên về vận hành khoá ký: hãy giữ private key trong Secrets Manager hoặc Parameter Store SecureString, đừng nhúng nó vào mã nguồn hay vào image. Khoá đó chính là thứ cấp quyền xem toàn bộ thư viện nội dung của bạn — ai lấy được nó thì tự ký được URL cho chính mình, vô thời hạn, và bạn sẽ không thấy điều đó trong bất kỳ log nào cho tới khi nội dung xuất hiện ở nơi không nên có.

Đáp án

B — Triển khai phiên bản mới sang một môi trường RIÊNG theo mô hình Blue/Green, rồi hoán đổi bản ghi Route 53 của hai môi trường để chuyển lưu lượng sang phiên bản mới.

Vì sao đúng

Đề nêu hai yêu cầu, và chỉ Blue/Green thoả cả hai ở mức tốt nhất:

⚠ Điểm mấu chốt — môi trường cũ vẫn còn nguyên vẹn:

Môi trường BLUE đang phục vụ (bản cũ)
        ↓
    Dựng môi trường GREEN hoàn toàn mới, bản mới
        ↓
    Kiểm thử GREEN kỹ càng trên URL RIÊNG của nó
    (chưa có người dùng thật nào)
        ↓
    Hoán đổi URL / bản ghi Route 53
        ↓
    → lưu lượng chuyển sang GREEN
    → BLUE VẪN CHẠY, vẫn nguyên vẹn
        ↓
    Phát hiện lỗi → hoán đổi NGƯỢC LẠI
        ↓
    → quay lui trong vài giây, không phải triển khai lại

⚠ Vì sao các kiểu triển khai tại chỗ không quay lui nhanh được:

Rolling / Immutable / All at once
        ↓
    Đều cập nhật hoặc thay thế fleet HIỆN TẠI
        ↓
    Muốn quay lui = TRIỂN KHAI LẠI bản cũ
        ↓
    → mất từng ấy thời gian một lần nữa
    → trong khi người dùng vẫn đang gặp lỗi

Xem thêm câu #11678 và #11628: cùng chủ đề triển khai Beanstalk nhưng ràng buộc khác nhau — #11678 cấm phát sinh chi phí nên đáp án là Rolling; #11628 cần rút ngắn thời gian nâng cấp nên ghép Golden AMI + Blue/Green.

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

• C (Rolling with additional batch) — đây là phương án gần nhất vì nó giữ nguyên dung lượng phục vụ và không có phút chết. Nhưng quay lui thì chậm: phải triển khai lại bản cũ theo từng lô, mất đúng bằng thời gian đã bỏ ra để triển khai bản mới.

• A (Rolling) — không có phút chết, nhưng giảm dung lượng phục vụ trong lúc triển khai và quay lui cũng chậm như C.

• D (All at once) — có phút chết rõ ràng (toàn bộ fleet cập nhật cùng lúc) và quay lui cũng phải triển khai lại. Trượt cả hai yêu cầu.

Ghi nhớ

⚠ Sáu kiểu triển khai của Elastic Beanstalk — bảng phải thuộc: | Kiểu | Phút chết | Thêm máy | Quay lui | |---|---|---|---| | All at once | CÓ | không | triển khai lại | | Rolling | không | không | triển khai lại | | Rolling with additional batch | không | có (một lô) | triển khai lại | | Immutable | không | gấp đôi | nhanh — bỏ ASG mới | | Traffic splitting | không | có | nhanh | | Blue/Green | không | gấp đôi | TỨC THÌ — hoán đổi ngược |

Từ khoá nhận diện:

"phút chết tối thiểu + quay lui nhanh" → Blue/Green "hai phiên bản cùng chạy, không thêm chi phí" → Rolling "an toàn nhất trong các kiểu tại chỗ" → Immutable "thử với một phần nhỏ người dùng" → Traffic splitting (canary) "nhanh nhất, chấp nhận gián đoạn" → All at once (chỉ môi trường dev)

⚠ Cảnh báo quan trọng nhất khi làm Blue/Green trên Beanstalk:

ĐỪNG để RDS nằm bên trong môi trường Beanstalk
        ↓
    Cơ sở dữ liệu tạo như một phần của môi trường
        ↓
    → xoá môi trường cũ sau khi hoán đổi
      = XOÁ LUÔN cơ sở dữ liệu
        ↓
    Cách đúng: tạo RDS ĐỘC LẬP,
    truyền chuỗi kết nối qua biến môi trường

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Môi trường mới có khoẻ không | trang Health, kiểm thử trên URL riêng trước khi hoán đổi | | Hoán đổi đã lan chưa | dig tên miền, so với TTL đã đặt | | Quay lui có sẵn sàng không | môi trường cũ vẫn phải đang chạy |

Và một chi tiết quyết định thành bại của mọi phương án Blue/Green dựa trên DNS: hãy hạ TTL xuống 60 giây vài giờ TRƯỚC khi hoán đổi. "Chuyển đổi tức thì" chỉ đúng ở phía AWS — với TTL 3600 giây, sẽ có người dùng còn được resolver trả về địa chỉ cũ suốt một giờ sau khi bạn bấm nút, và trong lúc quay lui khẩn cấp thì mỗi phút chờ DNS đều là phút người dùng vẫn đang gặp lỗi.

Đáp án

A, B — hai điều đúng khi cấu hình Application Load Balancer:

• A — Trước khi dùng ALB, bạn phải thêm ÍT NHẤT MỘT listener.
• B — Bạn cấu hình target group bằng cách GẮN chúng vào listener.

Vì sao đúng

Hai điều này mô tả đúng kiến trúc ba tầng của ALB.

⚠ Điểm mấu chốt — ba thành phần và quan hệ giữa chúng:

LISTENER — lắng nghe một CỔNG và một GIAO THỨC
        ↓
    (ví dụ: HTTPS trên cổng 443)
        ↓
    RULE — điều kiện định tuyến, xét theo thứ tự ưu tiên
        ↓
    (ví dụ: đường dẫn /api/* → target group A)
        ↓
    TARGET GROUP — tập hợp các đích và health check của chúng
        ↓
    TARGET — EC2 instance, IP, Lambda, hoặc ALB khác

⚠ Điều A — không có listener thì ALB không nhận gì cả:

ALB không có listener
        ↓
    → không lắng nghe cổng nào
    → mọi kết nối tới đều bị từ chối
        ↓
    → listener là thành phần BẮT BUỘC đầu tiên

⚠ Điều B — target group được nối vào listener qua rule:

Target group tồn tại ĐỘC LẬP
        ↓
    Nó chỉ nhận lưu lượng khi được một RULE của listener trỏ tới
        ↓
    → tạo target group xong mà quên gắn vào listener
      thì nó chẳng bao giờ nhận request nào

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

• D (khi tạo listener, bạn định nghĩa cả ACTION và CONDITION cho default rule) — đây là phương án gần nhất và là bẫy tinh vi nhất: default rule CHỈ có ACTION, KHÔNG có CONDITION. Nó là quy tắc "bắt tất cả những gì còn lại", nên theo định nghĩa nó không có điều kiện nào để khớp. Chỉ những rule bạn thêm sau mới có condition.

• E (một target chỉ đăng ký được với ĐÚNG MỘT target group tại một thời điểm) — sai: một instance đăng ký được vào NHIỀU target group. Đây là cách thông thường để phục vụ nhiều cổng hoặc nhiều đường dẫn từ cùng một fleet.

• C (mọi target trong một target group phải thuộc CÙNG một Availability Zone) — ngược hẳn thực hành tốt: ALB đòi ít nhất hai AZ, và target group nên trải trên nhiều AZ để chịu lỗi.

Ghi nhớ

⚠ Kiến trúc ALB — bảng phải thuộc: | Thành phần | Vai trò | |---|---| | Load balancer | điểm vào, trải trên ≥ 2 AZ | | Listener | BẮT BUỘC — một cổng + một giao thức | | Rule | điều kiện định tuyến, có priority | | Default rule | chỉ có action, KHÔNG có condition | | Target group | nhóm đích + health check riêng | | Target | EC2, IP, Lambda, hoặc ALB khác |

Từ khoá nhận diện:

"default rule có condition" → LUÔN SAI "một target chỉ thuộc một target group" → SAI, thuộc nhiều được "target group phải cùng một AZ" → SAI, nên trải nhiều AZ "ALB cần mấy AZ" → ít nhất HAI "health check ở đâu" → cấp TARGET GROUP, không phải cấp load balancer

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Listener và rule hiện tại | describe-listeners, describe-rules | | Target có khoẻ không | describe-target-health — đọc trường Reason | | Rule nào đang khớp | ALB access log, hoặc thử với curl và các host header khác nhau |

Và một mẹo cấu hình nên áp dụng cho mọi ALB: hãy đặt listener cổng 80 với action redirect sang HTTPS, thay vì cho nó forward tới target group. Cách này không tốn một target nào, không tiêu tài nguyên backend, và đảm bảo mọi khách truy cập bằng HTTP đều được đưa sang kết nối mã hoá — một dòng cấu hình thay cho cả một tầng chuyển hướng viết trong ứng dụng.

Đáp án

A — Lỗi cho thấy IAM role cấu hình chưa đúng. Sau khi đã tạo flow log thì KHÔNG SỬA ĐƯỢC cấu hình của nó; phải XOÁ flow log cũ và tạo lại một cái mới với cấu hình đúng.

Vì sao đúng

Đây là một đặc điểm ít người biết cho tới khi vấp phải: flow log là tài nguyên BẤT BIẾN.

⚠ Điểm mấu chốt — không có API nào sửa được flow log đã tạo:

API của VPC Flow Logs chỉ có:
        create-flow-logs
        describe-flow-logs
        delete-flow-logs
        ↓
    KHÔNG có modify-flow-logs hay update-flow-logs
        ↓
    → mọi thay đổi (IAM role, đích, định dạng, khoảng thời gian)
      đều phải: XOÁ rồi TẠO LẠI

⚠ Trạng thái Access error nghĩa là gì:

Flow log service không ghi được vào đích đã khai
        ↓
    Thường do IAM role:
        - thiếu quyền logs:CreateLogStream, logs:PutLogEvents
        - trust policy không tin vps-flow-logs.amazonaws.com
        - role đã bị xoá
        ↓
    Hoặc do đích:
        - log group không tồn tại
        - bucket policy của S3 không cho phép ghi

⚠ IAM role đúng phải có hai phần:

// Trust policy — AI được đóng vai này
{
  "Effect": "Allow",
  "Principal": { "Service": "vpc-flow-logs.amazonaws.com" },
  "Action": "sts:AssumeRole"
}

// Permissions policy — đóng vai rồi làm được gì
{
  "Effect": "Allow",
  "Action": ["logs:CreateLogGroup", "logs:CreateLogStream",
             "logs:PutLogEvents", "logs:DescribeLogGroups",
             "logs:DescribeLogStreams"],
  "Resource": "*"
}

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

• C (role thiếu quan hệ tin cậy với dịch vụ flow logs, hãy đổi trust relationship từ cấu hình flow log) — đây là phương án gần nhất và chẩn đoán có thể đúng, nhưng cách sửa thì sai: trust relationship sửa ở IAM, không sửa "từ cấu hình flow log". Và nếu muốn đổi sang một role khác thì vẫn phải xoá flow log rồi tạo lại.

• D (flow log đang trong quá trình tạo, có khi mất tới 10 phút) — flow log đúng là mất vài phút mới có dữ liệu đầu tiên, nhưng khi đó trạng thái là ACTIVE, không phải Access error. Trạng thái lỗi là kết luận rõ ràng, không phải sự chậm trễ.

• B (lỗi nội bộ của dịch vụ, hãy mở ticket với AWS) — Access error là lỗi cấu hình phía khách hàng, có thông báo rất rõ ràng; không cần AWS can thiệp.

Ghi nhớ

⚠ VPC Flow Logs — bảng phải thuộc: | Đặc điểm | Nội dung | |---|---| | Bất biến | không sửa được, phải xoá và tạo lại | | Cấp áp dụng | VPC, subnet, hoặc ENI | | Đích | CloudWatch Logs, S3, hoặc Kinesis Data Firehose | | Loại lưu lượng | ACCEPT, REJECT, hoặc ALL | | Khoảng gom | 1 phút hoặc 10 phút | | Ghi lại | siêu dữ liệu gói tin, KHÔNG ghi nội dung |

Từ khoá nhận diện:

"sửa cấu hình flow log" → KHÔNG ĐƯỢC, xoá và tạo lại "Access error" → IAM role hoặc quyền ghi vào đích "gói tin bị chặn ở đâu" → Flow Logs, lọc REJECT "muốn xem NỘI DUNG gói tin" → Traffic Mirroring, không phải Flow Logs "chẩn đoán đường đi nhanh" → VPC Reachability Analyzer

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Trạng thái flow log | describe-flow-logs, xem FlowLogStatus | | Thông báo lỗi cụ thể | trường DeliverLogsErrorMessage | | Role có đúng không | get-role, đọc AssumeRolePolicyDocument |

Và một lời khuyên khi triển khai ở quy mô tổ chức: hãy bật flow log ở cấp VPC ngay từ lúc tạo VPC, và đưa nó vào template hạ tầng dạng mã. Flow log không ghi lại được quá khứ — nên vào ngày bạn cần điều tra một sự cố bảo mật, thứ quyết định bạn có câu trả lời hay không là việc ai đó đã bật nó từ nhiều tháng trước, chứ không phải việc bạn bật nó nhanh đến đâu lúc ấy.

Đáp án

A — Chạy runbook AWSSupport-TroubleshootS3PublicRead của AWS Systems Manager Automation để chẩn đoán vấn đề truy cập đối tượng từ một bucket S3 công khai.

Vì sao đúng

AWS có sẵn một runbook chuyên trách cho đúng tình huống này, và nó kiểm tra tất cả các lớp cùng lúc.

⚠ Điểm mấu chốt — quyền truy cập S3 có RẤT NHIỀU lớp, kiểm tra tay dễ bỏ sót:

Runbook AWSSupport-TroubleshootS3PublicRead rà:
        ↓
    1. S3 Block Public Access — ở cấp TÀI KHOẢN
    2. S3 Block Public Access — ở cấp BUCKET
    3. Bucket policy — có Deny nào không
    4. Bucket ACL và object ACL
    5. Object Ownership (BucketOwnerEnforced?)
    6. Đối tượng có mã hoá bằng KMS không
    7. Bucket có bật Requester Pays không
        ↓
    → xuất ra báo cáo chỉ rõ LỚP NÀO đang chặn

⚠ Và nghi phạm số một trong tình huống của đề:

S3 Block Public Access
        ↓
    Từ tháng 4/2023, AWS BẬT SẴN cho mọi bucket mới
        ↓
    Nó GHI ĐÈ mọi bucket policy và ACL cho phép công khai
        ↓
    → bạn thấy bucket policy ghi "Principal: *"
    → nhưng vẫn nhận 403
        ↓
    → đây là lý do phổ biến nhất của đúng triệu chứng này

⚠ Nghi phạm số hai — Object Ownership:

BucketOwnerEnforced (mặc định cho bucket mới)
        ↓
    → ACL bị VÔ HIỆU HOÁ hoàn toàn
        ↓
    → mọi cấu hình "public read" dựa trên ACL không có tác dụng
    → phải chuyển sang dùng bucket policy

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

• B (câu lệnh Deny tường minh trong bucket policy, hãy kiểm tra bucket policy) — đây là phương án gần nhất và là một trong những nguyên nhân thật. Nhưng nó chỉ kiểm tra MỘT lớp trong số nhiều lớp; nếu thủ phạm là Block Public Access hay Object Ownership thì bucket policy trông hoàn toàn bình thường và bạn sẽ đi sai hướng.

• D (SCP của AWS Organizations chặn truy cập S3) — có thể xảy ra, nhưng khi đó mọi thao tác S3 của tài khoản đều bị chặn, không riêng bucket này. Và triệu chứng thường xuất hiện đồng loạt chứ không lẻ tẻ.

• C (lỗi khi tạo bucket, hãy xoá rồi tạo lại) — không có "lỗi khi tạo bucket" nào gây ra chuyện này, và xoá bucket là hành động phá huỷ dữ liệu cho một vấn đề chỉ là cấu hình quyền.

Ghi nhớ

⚠ Thứ tự các lớp quyết định một request tới S3 — bảng phải thuộc: | Thứ tự | Lớp | |---|---| | 1 | Block Public Access (tài khoản) — ghi đè tất cả | | 2 | Block Public Access (bucket) | | 3 | SCP của Organizations | | 4 | Bucket policy (Deny thắng Allow) | | 5 | Chính sách IAM của người gọi | | 6 | ACL — chỉ khi Object Ownership cho phép | | 7 | KMS key policy nếu đối tượng mã hoá |

Từ khoá nhận diện:

"bucket public mà vẫn 403" → Block Public Access hoặc Object Ownership "403 dù bucket policy cho phép" → kiểm tra Deny và BPA "403 với đối tượng mã hoá" → thiếu kms:Decrypt "muốn chẩn đoán tự động" → AWSSupport-TroubleshootS3PublicRead "tìm bucket đang mở ra ngoài" → IAM Access Analyzer for S3

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Block Public Access | get-public-access-block ở cả cấp tài khoản lẫn cấp bucket | | Object Ownership | get-bucket-ownership-controls | | Ai thật sự vào được | IAM Access Analyzer for S3 |

Và một lời nhắc quan trọng về hướng đi: trước khi bỏ công gỡ Block Public Access để "làm cho bucket công khai", hãy hỏi lại xem có thật sự cần công khai hay không. Đề nói đây là ảnh cho một ứng dụng web — mà tình huống đó có một câu trả lời tốt hơn hẳn: đặt CloudFront phía trước với OAC, giữ bucket riêng tư hoàn toàn, vừa nhanh hơn nhờ cache, vừa rẻ hơn về chi phí truyền dữ liệu, vừa không bao giờ phải lo ai đó liệt bucket của bạn vào danh sách "S3 mở công khai".

Đáp án

B — ALB access logs.

Vì sao đúng

Đề cần hai loại thông tin ở mức TỪNG REQUEST: độ trễ và địa chỉ IP của client. Chỉ access log có cả hai ở mức đó.

⚠ Điểm mấu chốt — access log ghi một dòng cho MỖI request:

Mỗi dòng chứa đầy đủ:
        time                        → thời điểm
        client:port                 → IP CỦA CLIENT      ← đề cần
        request_processing_time     → ALB nhận request
        target_processing_time      → ỨNG DỤNG xử lý     ← đề cần
        response_processing_time    → ALB trả về
        elb_status_code / target_status_code
        user_agent, ssl_cipher, target_group_arn

⚠ Ba trường thời gian tách riêng — đây là chỗ giá trị nhất:

request_processing_time  → ALB nhận và chuyển tiếp
target_processing_time   → ỨNG DỤNG của bạn xử lý
response_processing_time → ALB gửi trả client
        ↓
    → biết ngay độ trễ đến từ ĐÂU
    → target cao   → ứng dụng chậm
    → request/response cao → vấn đề mạng hoặc client chậm

⚠ Và phân tích bằng Athena:

SELECT client_ip,
       count(*) AS so_request,
       avg(target_processing_time) AS do_tre_tb,
       approx_percentile(target_processing_time, 0.99) AS p99
FROM alb_logs
WHERE day = '2026/09/02'
GROUP BY client_ip
ORDER BY so_request DESC
LIMIT 50;

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

• D (CloudWatch metrics) — đây là phương án gần nhất và có chỉ số TargetResponseTime rất hữu ích. Nhưng chỉ số là giá trị TỔNG HỢP theo chu kỳ: bạn biết độ trễ trung bình hay p99 của cả fleet, nhưng không biết IP nào gây ra request nào. Đề cần mẫu hình theo địa chỉ IP client, tức là dữ liệu ở mức từng request.

• C (ALB request tracing) — request tracing gắn một id duy nhất (header X-Amzn-Trace-Id) vào mỗi request để lần theo nó qua các dịch vụ. Rất hữu ích để nối các log lại, nhưng bản thân nó không phải một nguồn dữ liệu về độ trễ hay IP.

• A (CloudTrail logs) — CloudTrail ghi lời gọi API quản trị (CreateLoadBalancer, ModifyListener…), không ghi lưu lượng HTTP đi qua load balancer.

Ghi nhớ

⚠ Bốn nguồn dữ liệu quanh một ALB — bảng phải thuộc: | Nguồn | Cho gì | Mức chi tiết | |---|---|---| | Access log | từng request — IP, độ trễ, mã lỗi | cao nhất | | CloudWatch metrics | số liệu tổng hợp theo chu kỳ | trung bình | | Request tracing | id để lần theo một request | liên kết | | CloudTrail | ai thay đổi cấu hình load balancer | quản trị |

Từ khoá nhận diện:

"phân tích theo IP client, theo từng request" → access log + Athena "cảnh báo khi độ trễ tăng" → CloudWatch metric TargetResponseTime "lần theo một request qua nhiều dịch vụ" → X-Ray / request tracing "ai đổi cấu hình ALB" → CloudTrail "IP client mà ứng dụng nhìn thấy" → header X-Forwarded-For

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Access log đã bật chưa | thuộc tính access_logs.s3.enabled | | Log có tới S3 không | xem bucket — chờ ít nhất 5 phút | | Truy vấn có tốn không | Athena báo "data scanned" sau mỗi lần chạy |

Và một lời khuyên khi đọc số liệu độ trễ: hãy dùng phân vị p95 hoặc p99, đừng dùng giá trị trung bình. Trung bình che giấu đúng những gì bạn cần tìm — một hệ thống có 99% request trả về trong 50 mili giây và 1% mất 10 giây vẫn cho trung bình rất đẹp, trong khi cái 1% đó chính là những người dùng đang phàn nàn và là dấu vết của vấn đề thật.

Đáp án

C — Geolocation routing policy.

Vì sao đúng

Đề có hai yêu cầu, và yêu cầu thứ hai mới là chỗ loại bỏ các phương án khác: người dùng ngoài Úc KHÔNG được truy cập máy chủ đó qua truy vấn DNS.

⚠ Điểm mấu chốt — geolocation định tuyến theo VỊ TRÍ, và có thể TỪ CHỐI:

Geolocation routing
        ↓
    Route 53 xác định vị trí người hỏi (theo IP của resolver)
        ↓
    Trả về bản ghi khớp với vị trí đó
        ↓
    KHÔNG có bản ghi nào khớp và KHÔNG có bản ghi mặc định
        ↓
    → Route 53 trả về "no answer"
    → người dùng KHÔNG phân giải được tên miền
        ↓
    → đúng yêu cầu "không truy cập được qua DNS" của đề

⚠ Đây là điểm phân biệt quan trọng nhất với latency-based routing:

Latency-based
        ↓
    Luôn trả về MỘT đáp án — Region nhanh nhất cho người đó
        ↓
    → người ở châu Âu vẫn nhận được địa chỉ nào đó
    → KHÔNG chặn được ai

Geolocation
        ↓
    Có thể KHÔNG trả về gì cả nếu vị trí không khớp
        ↓
    → chặn được thật

⚠ Ba mức chi tiết của geolocation:

Continent  → châu Á, châu Âu, Bắc Mỹ...
Country    → Australia, Vietnam...       ← đề dùng mức này
Subdivision→ bang/tỉnh (hiện hỗ trợ Mỹ, và một số nước)
        ↓
    Ưu tiên: mức CỤ THỂ NHẤT thắng
    (subdivision > country > continent > default)

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

• B (Latency) — đây là phương án gần nhất vì nó cũng "phục vụ người dùng theo vị trí". Nhưng nó chọn theo độ trễ mạng đo được, không theo biên giới quốc gia, và luôn trả về một đáp án cho mọi người — nên không đáp ứng được yêu cầu chặn.

• A (Failover) — dùng cho mô hình chính/dự phòng: khi máy chính trượt health check thì chuyển sang máy dự phòng. Không liên quan tới vị trí địa lý.

• D (Weighted) — chia lưu lượng theo tỷ lệ giữa nhiều đích, dùng cho canary và A/B test. Không nhìn tới vị trí người dùng.

Ghi nhớ

⚠ Bảy chính sách định tuyến của Route 53 — bảng phải thuộc: | Chính sách | Chọn theo | |---|---| | Simple | một đích duy nhất | | Weighted | tỷ lệ phần trăm — canary, A/B test | | Latency-based | Region phản hồi nhanh nhất | | Failover | chính / dự phòng, cần health check | | Geolocation | vị trí địa lý của người dùng | | Geoproximity | khoảng cách, điều chỉnh được bằng bias | | Multivalue answer | trả nhiều IP, có health check |

Từ khoá nhận diện:

"chỉ người ở nước X được truy cập" → Geolocation "phục vụ từ Region nhanh nhất" → Latency-based "chuyển sang dự phòng khi hỏng" → Failover "chuyển dần 10% lưu lượng" → Weighted "kéo lưu lượng về một Region nhiều hơn bình thường" → Geoproximity + bias "chặn theo quốc gia ở tầng CDN" → CloudFront geo restriction

⚠ Geolocation và Geoproximity — hai cái tên rất dễ nhầm: | | Geolocation | Geoproximity | |---|---|---| | Dựa trên | biên giới hành chính (châu lục, nước, bang) | khoảng cách địa lý thực tế | | Chặn được người ngoài | CÓ (nếu không có default record) | không | | Điều chỉnh | không | bias — nới rộng hoặc thu hẹp vùng phục vụ | | Cần | — | phải dùng Route 53 Traffic Flow |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Người ở nước khác nhận được gì | Route 53 Traffic Policy có công cụ test, hoặc dùng resolver ở nước đó | | Bản ghi đã lan chưa | dig @<resolver> ten-mien.com | | Có ai bị chặn nhầm không | log của ứng dụng — tìm sụt giảm lưu lượng bất thường theo vùng |

Và một cảnh báo cần nói rõ với đội sản phẩm: định tuyến theo địa lý dựa vào IP của DNS resolver, không phải IP của người dùng. Một người ở Sydney dùng DNS công cộng của Google hay Cloudflare có thể bị nhìn nhận là ở nơi khác, và ngược lại — nên nếu yêu cầu "chỉ người Úc được xem" xuất phát từ ràng buộc pháp lý về bản quyền, hãy thực thi nó ở tầng ứng dụng hoặc bằng WAF, và coi geolocation chỉ là lớp tối ưu trải nghiệm.