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

Đáp án

B — Bật DynamoDB STREAMS và tạo GLOBAL TABLE ở một Region khác.

Vì sao đúng

Yêu cầu là nhân bản bảng sang Region khác phục vụ khôi phục thảm hoạ, và global table là cơ chế duy nhất làm điều đó.

⚠ Điểm mấu chốt — global table nhân bản đa Region, HAI CHIỀU:

DynamoDB Global Table
        ↓
    Bảng tồn tại ở NHIỀU Region cùng lúc
        ↓
    Ghi ở Region nào cũng được
    → tự nhân bản sang các Region còn lại
      (multi-active, active-active)
        ↓
    Độ trễ nhân bản: thường DƯỚI MỘT GIÂY
        ↓
    → mất cả một Region vẫn còn bản đầy đủ
    → và ứng dụng ở Region khác dùng được ngay

⚠ Vì sao phải bật DynamoDB Streams:

Global table dùng STREAMS làm cơ chế nhân bản
        ↓
    Streams ghi lại mọi thay đổi ở mức bản ghi
        ↓
    → phải bật với **`StreamViewType: NEW_AND_OLD_IMAGES`**
        ↓
    Với phiên bản 2019.11.21 (hiện hành)
      → bật streams là điều kiện tiên quyết
      → tạo replica chỉ là thêm một Region

⚠ Xử lý xung đột khi ghi ở nhiều nơi:

Hai Region cùng sửa một bản ghi
        ↓
    Global table dùng LAST WRITER WINS
        ↓
    → bản ghi có dấu thời gian mới hơn thắng
        ↓
    → phù hợp với phần lớn ứng dụng
    → nhưng KHÔNG phù hợp khi cần
      giao dịch nghiêm ngặt liên Region
        ↓
    Cách tránh: định tuyến người dùng
    về đúng một Region theo vùng địa lý

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

• A (bật point-in-time recovery — PITR) — đây là phương án gần nhất và là một biện pháp sao lưu rất tốt, nhưng PITR khôi phục TRONG CÙNG Region theo thời điểm (35 ngày gần nhất). Không nhân bản sang Region khác, nên không đáp ứng yêu cầu khôi phục thảm hoạ theo Region.

• D (bật Streams và tạo global secondary index — GSI) — GSI là một chỉ mục TRONG CÙNG bảng và cùng Region. Chữ "global" ở đây nghĩa là phủ toàn bộ bảng (khác local secondary index), không phải toàn cầu về địa lý — đây là bẫy đặt tên rất hay gặp.

• C (bật DynamoDB Accelerator — DAX) — DAX là lớp CACHE trong bộ nhớ đặt trước DynamoDB để giảm độ trễ đọc. Không nhân bản dữ liệu, và chỉ trong một Region.

Ghi nhớ

⚠ Các tính năng DynamoDB dễ nhầm — bảng phải thuộc: | Tính năng | Việc | |---|---| | Global Table | nhân bản ĐA REGION, ghi được ở mọi Region | | Global Secondary Index (GSI) | chỉ mục phụ TRONG CÙNG bảng — khoá phân vùng khác | | Local Secondary Index (LSI) | chỉ mục phụ, cùng khoá phân vùng, phải tạo lúc tạo bảng | | DAX | cache trong bộ nhớ, độ trễ micro giây | | Streams | luồng thay đổi — nền tảng của global table, và cho Lambda trigger | | PITR | khôi phục theo thời điểm, 35 ngày, CÙNG Region | | On-demand backup | sao lưu thủ công, giữ mãi |

Từ khoá nhận diện:

"nhân bản sang Region khác" → Global Table "khôi phục về thời điểm trước sự cố" → PITR "truy vấn theo thuộc tính khác khoá chính" → GSI "đọc quá chậm, cần micro giây" → DAX "phản ứng khi dữ liệu thay đổi" → Streams + Lambda

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã có replica chưa | describe-table → Replicas | | Nhân bản có trễ không | chỉ số ReplicationLatency | | PITR đã bật chưa | describe-continuous-backups |

Và một điều nên nói rõ khi trình bày phương án khôi phục thảm hoạ: global table không phải là bản sao lưu. Nó bảo vệ bạn khỏi việc mất một Region, nhưng nếu ai đó chạy nhầm một lệnh xoá, thao tác đó được nhân bản sang mọi Region trong chưa đầy một giây — nên PITR vẫn phải bật, và hai cơ chế này giải quyết hai loại rủi ro hoàn toàn khác nhau.

Đáp án

D — Cập nhật SECURITY GROUP của instance, thêm luật cho phép SSH ĐI VÀO từ địa chỉ IP của quản trị viên.

Vì sao đúng

Triệu chứng TIMEOUT kết hợp với máy ở public subnet và có IP công cộng chỉ thẳng tới một nghi phạm.

⚠ Điểm mấu chốt — security group mặc định CHẶN HẾT chiều vào:

Security group mới tạo
        ↓
    Inbound:  KHÔNG CÓ LUẬT NÀO → chặn tất cả
    Outbound: cho phép TẤT CẢ
        ↓
    Không thêm luật SSH inbound
        ↓
    → gói tin bị BỎ IM LẶNG
    → client chờ mãi → TIMEOUT
        ↓
    Luật cần thêm:
      Type: SSH,  Port: 22,
      Source: <IP-cua-quan-tri-vien>/32

⚠ Vì sao TIMEOUT là manh mối quyết định:

TIMEOUT (chờ mãi, không phản hồi)
        ↓
    → gói bị BỎ IM LẶNG ở tầng mạng
    → security group, NACL, route table,
      hoặc không có IP công cộng

CONNECTION REFUSED (từ chối ngay)
        ↓
    → gói ĐÃ TỚI máy
    → nhưng sshd không chạy, hoặc nghe cổng khác

PERMISSION DENIED (publickey)
        ↓
    → mạng HOÀN TOÀN THÔNG
    → vấn đề ở khoá hoặc tên người dùng

⚠ Và đề đã loại sẵn các nghi phạm khác:

"public subnet"          → route table có tuyến ra IGW ✓
"obtained a public IP"   → máy có IP công cộng ✓
        ↓
    → còn lại đúng hai lớp lọc:
      security group và NACL
        ↓
    NACL mặc định của VPC CHO PHÉP TẤT CẢ
        ↓
    → nghi phạm duy nhất còn lại là
      SECURITY GROUP, chiều VÀO

Xem thêm câu #11825 (lô 127): gần như cùng một câu hỏi, cùng đáp án — security group chưa cho phép SSH đi vào. Chỉ khác chữ cái vì bộ đề xáo thứ tự phương án (ở đó là B, ở đây là D). Khoá nhất quán.

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

• B (thêm luật cho phép SSH ĐI RA tới IP của quản trị viên) — đây là phương án gần nhất và cùng nói về security group, chỉ sai chiều: security group có trạng thái, gói trả lời của một kết nối đã được chấp nhận luôn được đi ra. Và outbound mặc định đã mở hết.

• A (sửa NACL cho phép cổng 22 ĐI RA tới IP của quản trị viên) — NACL mặc định của VPC cho phép tất cả cả hai chiều, nên nó không phải nguyên nhân. (Và nếu có sửa thì chiều ra cần dải cổng tạm 1024-65535, không phải cổng 22.)

• C (thêm một mục trong route table cho IP của quản trị viên) — route table không hoạt động theo IP của từng client. Subnet đã là public, tuyến 0.0.0.0/0 → IGW đã bao phủ mọi đích.

Ghi nhớ

⚠ Ba lỗi SSH và ý nghĩa — bảng phải thuộc: | Lỗi | Nghĩa | Nghi phạm | |---|---|---| | Connection timed out | gói bị bỏ im lặng | SG, NACL, route table, không có IP công cộng | | Connection refused | tới máy nhưng không ai nghe | sshd chưa chạy, sai cổng | | Permission denied (publickey) | mạng thông, sai chứng chỉ | sai khoá, sai user, sai quyền tệp | | Host key verification failed | khoá host đổi | máy đã được dựng lại |

Từ khoá nhận diện:

"SSH timeout" → security group inbound, trước tiên "connection refused" → dịch vụ chưa chạy trên máy "permission denied" → khoá hoặc tên user "IP nhà thay đổi liên tục" → Session Manager, đừng sửa SG mỗi lần "không muốn mở cổng 22 chút nào" → Session Manager

⚠ Security Group ↔ Network ACL — nhắc lại: | | Security Group | Network ACL | |---|---|---| | Trạng thái | CÓ (stateful) | KHÔNG (stateless) | | Mặc định | vào: chặn hết, ra: mở hết | mặc định của VPC: mở CẢ HAI chiều | | Luật | chỉ Allow | Allow và Deny | | Phạm vi | ENI / instance | cả subnet | | Chiều ra của gói trả lời | tự động cho qua | PHẢI CÓ LUẬT |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | IP hiện tại của bạn | curl https://checkip.amazonaws.com | | Security group cho phép gì | describe-security-groups — đọc JSON | | Gói bị chặn ở đâu | VPC Flow Logs, tìm bản ghi REJECT |

Và một công cụ nên dùng trước khi đọc log dòng nào: VPC Reachability Analyzer. Nó phân tích đường đi từ nguồn tới đích mà không gửi gói tin nào, rồi chỉ thẳng "bị chặn tại security group sg-xxxx" — nhanh hơn nhiều so với việc bật flow log rồi chờ dữ liệu, và nó cũng trả lời luôn câu hỏi tiếp theo là cần sửa chính xác thành phần nào.

Đáp án

C và D — Xin chứng chỉ SSL CÔNG KHAI qua AWS Certificate Manager (ACM), và GẮN chứng chỉ đó vào ALB.

Vì sao đúng

Đây là mô hình chuẩn của AWS cho HTTPS: kết thúc TLS tại load balancer, dùng chứng chỉ công khai miễn phí từ ACM.

⚠ Điểm mấu chốt — TLS termination tại ALB:

Người dùng ──HTTPS──▶ ALB ──HTTP──▶ EC2
                       │
                  chứng chỉ ACM
                  gắn ở listener 443
        ↓
    → chỉ QUẢN LÝ MỘT chứng chỉ, ở một chỗ
    → EC2 không phải cài, không phải gia hạn
    → thêm bao nhiêu máy cũng không phải làm gì
    → ALB lo cả việc bắt tay TLS (tốn CPU)

⚠ Vì sao phải là chứng chỉ CÔNG KHAI:

Website cho người dùng internet
        ↓
    Trình duyệt phải TIN chứng chỉ
        ↓
    → cần CA công cộng ký
        ↓
    Chứng chỉ RIÊNG (AWS Private CA)
        ↓
    → chỉ máy đã cài CA gốc của công ty mới tin
    → dùng cho nội bộ, mTLS, IoT

⚠ Và ACM có một giới hạn phải nhớ:

Chứng chỉ ACM CÔNG KHAI
        ↓
    MIỄN PHÍ, tự động gia hạn
        ↓
    Nhưng KHÔNG TẢI PRIVATE KEY VỀ ĐƯỢC
        ↓
    → KHÔNG cài lên EC2 được
    → chỉ dùng với các dịch vụ tích hợp:
      ALB / NLB / CloudFront / API Gateway
      Elastic Beanstalk / App Runner
        ↓
    → đây chính là lý do phương án B sai

Xem thêm câu #11929 (cùng lô): cùng chủ đề chứng chỉ ACM cho ALB, ở đó nhấn vào việc DNS validation để tự động gia hạn. Khoá nhất quán.

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

• B (cài chứng chỉ SSL trực tiếp lên từng instance EC2) — đây là phương án gần nhất về mặt "cũng ra được HTTPS", nhưng nó không dùng được với chứng chỉ ACM công khai (không tải private key về được), và tạo ra gánh nặng vận hành: mỗi máy một bản chứng chỉ, mỗi lần gia hạn phải triển khai lại toàn bộ.

• A (xin chứng chỉ RIÊNG qua ACM) — chứng chỉ riêng không được trình duyệt tin, sẽ hiện cảnh báo bảo mật với mọi người dùng.

• E (dùng chứng chỉ mua từ bên ngoài) — làm được (nhập vào ACM), nhưng phải tự gia hạn thủ công mỗi năm, và tốn tiền trong khi ACM công khai miễn phí. Không phải cách hiệu quả nhất.

Ghi nhớ

⚠ ACM — bảng phải thuộc: | Đặc điểm | Nội dung | |---|---| | Chứng chỉ công khai | MIỄN PHÍ, tự gia hạn (với DNS validation) | | Không tải private key | KHÔNG cài lên EC2 được | | Dùng được với | ALB, NLB, CloudFront, API Gateway, Beanstalk, App Runner | | CloudFront | BẮT BUỘC chứng chỉ ở us-east-1 | | ALB / NLB | cùng Region với load balancer | | Nhập chứng chỉ ngoài | được, nhưng KHÔNG tự gia hạn |

Từ khoá nhận diện:

"HTTPS cho website sau ALB" → ACM công khai + gắn vào ALB "cần cài chứng chỉ lên EC2" → ACM công khai KHÔNG làm được — dùng Private CA hoặc chứng chỉ ngoài "chứng chỉ nội bộ, mTLS, IoT" → AWS Private CA "tự động gia hạn" → ACM + DNS validation "chứng chỉ cho CloudFront" → us-east-1

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chứng chỉ đã gắn chưa | describe-listeners → Certificates | | Trình duyệt có tin không | mở website, kiểm tra ổ khoá | | Có tự gia hạn được không | describe-certificate → RenewalEligibility |

Và một cấu hình rất nên làm cùng lúc với việc bật HTTPS: redirect toàn bộ HTTP sang HTTPS ngay tại ALB. Đây là một quy tắc trên listener 80, không cần đụng tới mã ứng dụng — và nếu thiếu nó thì mọi người dùng gõ địa chỉ không kèm https:// vẫn đi vào bằng kết nối không mã hoá, khiến toàn bộ công sức cấu hình chứng chỉ mất tác dụng với đúng nhóm người dùng đông nhất.

Đáp án

A — Tạo một STACK SET RIÊNG để kiểm thử bản cập nhật.

Vì sao đúng

StackSets không có cơ chế "phiên bản thử nghiệm" cho một phần stack instance, nên cách an toàn là tách hẳn ra một stack set khác.

⚠ Điểm mấu chốt — một stack set chỉ có MỘT template:

Stack set giữ MỘT template duy nhất
        ↓
    Cập nhật stack set
        ↓
    → template mới trở thành template CỦA CẢ STACK SET
        ↓
    Dù chỉ triển khai cho vài tài khoản
        ↓
    → các stack instance còn lại thành LỖI THỜI
      (outdated), không khớp template hiện tại
    → trạng thái stack set trở nên lẫn lộn
        ↓
    → khó biết đâu là bản đang chạy ở đâu

⚠ Stack set riêng để kiểm thử — sạch sẽ và an toàn:

Tạo stack set thứ hai
        ↓
    Triển khai vào một OU / vài tài khoản thử nghiệm
    ở một vài Region
        ↓
    → hoàn toàn cô lập khỏi stack set production
    → chạy hỏng cũng không ảnh hưởng gì
        ↓
    Xác nhận ổn
        ↓
    → cập nhật stack set THẬT
    → và dùng RegionOrder + FailureTolerance
      để triển khai từ từ

⚠ Và khi cập nhật stack set thật, hãy triển khai có kiểm soát:

RegionOrder
        ↓
    Đặt Region ít rủi ro nhất lên ĐẦU

FailureToleranceCount = 0
        ↓
    Hỏng một tài khoản → DỪNG NGAY toàn bộ

MaxConcurrentCount thấp
        ↓
    Triển khai từng ít tài khoản một
        ↓
    → một template hỏng dừng lại sau
      một tài khoản, không lan ra sáu mươi

Xem thêm câu #11875 (lô 128): cùng chủ đề StackSets — một template triển khai ra nhiều tài khoản và Region bằng một thao tác. Khoá nhất quán.

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

• C (cập nhật stack set và chọn một tài khoản và Region duy nhất) — đây là phương án gần nhất và về mặt lệnh thì làm được (update-stack-set nhận danh sách accounts và regions), nhưng nó đã thay đổi template của cả stack set: mọi stack instance chưa cập nhật sẽ mang trạng thái outdated, và bạn đang thử nghiệm ngay trên chính stack set production.

• B (dùng change set cho stack set) — StackSets KHÔNG hỗ trợ change set. Change set là tính năng của stack thường.

• D (tạo nested stack để triển khai bản cập nhật) — nested stack dùng để chia nhỏ một template lớn, không phải cơ chế kiểm thử hay triển khai theo giai đoạn.

Ghi nhớ

⚠ StackSets — bảng phải thuộc: | Đặc điểm | Nội dung | |---|---| | Việc | một template → NHIỀU tài khoản và Region, một thao tác | | Hai chế độ quyền | self-managed (tự tạo 2 IAM role) ↔ service-managed (qua Organizations) | | Auto-deployment | tài khoản mới vào OU TỰ ĐỘNG được triển khai | | Không hỗ trợ | change set | | Kiểm soát rủi ro | MaxConcurrentCount, FailureToleranceCount, RegionOrder | | Phát hiện sửa tay | drift detection |

Từ khoá nhận diện:

"kiểm thử bản cập nhật stack set" → tạo stack set RIÊNG "nhiều tài khoản và Region, một thao tác" → StackSets "xem trước thay đổi" → change set — chỉ cho stack THƯỜNG "chia nhỏ template lớn" → nested stacks "tài khoản mới tự có cấu hình chuẩn" → service-managed + auto-deployment

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Trạng thái từng ô | list-stack-instances --stack-set-name ... | | Chỗ nào hỏng | describe-stack-instance cho tài khoản/Region đó | | Có ai sửa tay không | drift detection trên stack set |

Và một cách tổ chức đáng theo cho hạ tầng dùng StackSets: giữ hẳn một OU sandbox và một stack set thử nghiệm song song với stack set production. Chi phí thêm gần như bằng không nếu template chỉ tạo IAM role hay luật Config, nhưng nó cho bạn một nơi để phạm sai lầm — thứ luôn rẻ hơn nhiều so với việc phát hiện lỗi sau khi đã triển khai ra sáu mươi tài khoản.

Đáp án

A và B — Phân tích bằng AWS COST EXPLORER, và KÍCH HOẠT tag createdBy trong tài khoản.

Vì sao đúng

Đề cần biết chi phí theo TỪNG lập trình viên trong một tài khoản dùng chung, và tag do AWS sinh ra chính là thứ giải quyết được ngay.

⚠ Điểm mấu chốt — aws:createdBy là tag AWS TỰ GẮN:

Tài khoản dùng chung, hơn 60 người
        ↓
    Không ai gắn tag thủ công theo tên mình
        ↓
    AWS có sẵn một tag SINH TỰ ĐỘNG:
        aws:createdBy
        ↓
    Ghi lại DANH TÍNH đã tạo ra tài nguyên
      (IAM user hoặc role)
        ↓
    → không cần ai làm gì thêm
    → chỉ cần KÍCH HOẠT nó làm cost allocation tag

⚠ Và Cost Explorer là nơi nhìn kết quả:

Cost Explorer
        ↓
    Group by → Tag → aws:createdBy
        ↓
    → biểu đồ chi phí theo từng danh tính
    → lọc thêm theo dịch vụ, theo Region
    → so sánh giữa các tháng

⚠ Nhưng phải nói rõ hai giới hạn của createdBy:

1. KHÔNG ÁP NGƯỢC cho quá khứ
        ↓
    Chỉ gắn cho tài nguyên tạo SAU khi kích hoạt
    → chi phí tháng trước không chia được

2. Không phủ HẾT tài nguyên
        ↓
    Một số dịch vụ không hỗ trợ tag này
    Tài nguyên do tự động hoá tạo ra
      → mang danh tính của role, không phải của người
        ↓
    → là ước lượng tốt, không phải con số tuyệt đối

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

• E (phân tích API bằng AWS CloudTrail) — đây là phương án gần nhất và thực sự cho biết AI đã tạo tài nguyên nào, nhưng CloudTrail không có thông tin chi phí. Muốn ra được con số tiền thì vẫn phải tự đối chiếu thủ công với dữ liệu billing — rất nhiều việc so với việc bật một tag.

• C (dùng AWS Config để theo dõi việc sử dụng tài nguyên) — Config theo dõi CẤU HÌNH, không theo dõi chi phí.

• D (tạo billing alarm trong AWS Budgets) — Budgets cảnh báo khi vượt ngưỡng, không phân tích và chia nhỏ chi phí theo người.

Ghi nhớ

⚠ Hai loại cost allocation tag — bảng phải thuộc: | Loại | Tiền tố | Ai gắn | |---|---|---| | Do AWS sinh | aws: | AWS tự gắn | | Ví dụ | aws:createdBy, aws:cloudformation:stack-name, aws:cloudformation:logical-id | | | Do người dùng định nghĩa | user: trong CUR | bạn tự gắn | | Ví dụ | Project, Environment, Owner | | | Điểm chung | đều phải KÍCH HOẠT ở Billing → Cost Allocation Tags | | | Khác biệt | aws: không sửa, không xoá được | |

Từ khoá nhận diện:

"chi phí theo TỪNG NGƯỜI trong tài khoản chung" → aws:createdBy + Cost Explorer "chi phí theo dự án / phòng ban" → tag do người dùng định nghĩa "ai đã tạo tài nguyên này" → CloudTrail, hoặc aws:createdBy "cảnh báo khi vượt ngân sách" → Budgets "tách bạch chi phí tuyệt đối" → mỗi người/đội một TÀI KHOẢN riêng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tag đã kích hoạt chưa | Billing → Cost Allocation Tags — cột Status | | Ai tốn nhiều nhất | Cost Explorer → Group by → Tag → aws:createdBy | | Tài nguyên nào không có tag | Cost Explorer hiện nhóm "No tag key" |

Và một cách nhìn nên trao đổi với người quản lý cùng lúc với báo cáo: aws:createdBy cho biết ai TẠO ra tài nguyên, không cho biết ai đang DÙNG nó. Một lập trình viên dựng môi trường chung cho cả đội sẽ hiện lên như người tốn kém nhất, nên con số này rất hữu ích để tìm điểm nóng, nhưng không nên dùng trực tiếp để đánh giá từng cá nhân.

Đáp án

A — ELASTIC LOAD BALANCER ACCESS LOGS.

Vì sao đúng

ALB access log ghi lại địa chỉ IP của client cho từng request — đúng thông tin đề cần.

⚠ Điểm mấu chốt — trường client:port trong mỗi bản ghi:

Mỗi dòng access log của ALB chứa:
        ↓
    type          → http hay https
    time          → thời điểm
    elb           → id của load balancer
    client:port   → ĐỊA CHỈ IP CỦA CLIENT  ← cần
    target:port   → máy nào xử lý
    request       → phương thức + URL + phiên bản HTTP
    elb_status_code / target_status_code
    user_agent    → trình duyệt hoặc công cụ
    ssl_cipher, ssl_protocol
        ↓
    → đủ để tìm ra IP nào gửi bất thường nhiều

⚠ Phân tích bằng Athena — cách làm chuẩn:

SELECT client_ip, count(*) AS so_request
FROM alb_logs
WHERE time BETWEEN ... AND ...
GROUP BY client_ip
ORDER BY so_request DESC
LIMIT 20

    → bảng xếp hạng IP gửi nhiều request nhất
    → tài liệu AWS có sẵn câu lệnh tạo bảng

⚠ Một chi tiết bắt buộc phải nhớ:

ALB ACCESS LOG KHÔNG BẬT SẴN
        ↓
    Phải bật thủ công, ghi ra một bucket S3
        ↓
    Bucket cần bucket policy cho phép
    dịch vụ ELB ghi vào
        ↓
    → nếu chưa bật từ trước thì
      KHÔNG CÓ dữ liệu của quá khứ
        ↓
    → nên bật ngay từ ngày dựng ALB

Xem thêm câu #11933 (cùng lô) và #11887 (lô 129): cùng nguồn log này, ở đó trọng tâm là mã trạng thái HTTP tầng 7. Khoá nhất quán.

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

• B (Amazon CloudWatch Logs) — đây là phương án gần nhất vì cũng là nơi chứa log, nhưng ALB không tự ghi access log vào CloudWatch Logs — nó ghi ra S3. CloudWatch Logs chứa log do bạn tự đẩy lên (log ứng dụng qua agent).

• D (AWS CloudTrail logs) — ghi lời gọi API tới AWS (ai tạo, ai sửa ALB), không ghi request HTTP của người dùng cuối.

• C (EC2 Auto Scaling logs) — ASG ghi sự kiện khởi chạy và kết thúc máy, không ghi lưu lượng nào.

Ghi nhớ

⚠ Các trường quan trọng của ALB access log — bảng đáng thuộc: | Trường | Ý nghĩa | |---|---| | client:port | IP và cổng của CLIENT — trường của câu này | | target:port | máy backend xử lý | | elb_status_code | mã ALB trả cho client | | target_status_code | mã backend trả cho ALB | | request_processing_time, target_processing_time | tách được độ trễ do ALB hay do backend | | user_agent | nhận diện bot, công cụ tự động | | ssl_cipher, ssl_protocol | phiên bản TLS được dùng | | trace_id | nối với X-Ray |

Từ khoá nhận diện:

"IP của client truy cập ALB" → ALB access log "mã trạng thái HTTP" → ALB / CloudFront access log "gói tin bị chặn" → VPC Flow Logs "ai gọi API AWS" → CloudTrail "chặn IP gửi quá nhiều" → WAF rate-based rule

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Access log đã bật chưa | describe-load-balancer-attributes | | IP nào gửi nhiều nhất | Athena: GROUP BY client_ip ORDER BY count DESC | | Có phải bot không | xem cột user_agent trong cùng truy vấn |

Và một điều nên làm ngay hôm nay dù chưa có sự cố nào: bật access log cho mọi ALB đang chạy. Log chỉ tồn tại từ thời điểm bật trở đi, nên nếu để tới lúc có chuyện mới bật, bạn sẽ có đầy đủ dữ liệu về mọi thứ trừ khoảng thời gian mà bạn thực sự cần điều tra.

Đáp án

A và E — Cấu hình cache behavior để CHUYỂN TIẾP COOKIE, VÀ bật STICKY SESSIONS trên ALB target group.

Vì sao đúng

Kiến trúc có hai tầng, và phiên bị mất vì cả hai tầng đều chưa được cấu hình để giữ phiên.

⚠ Tầng thứ nhất — ALB phải gửi người dùng về đúng máy:

Ứng dụng CÓ TRẠNG THÁI (stateful)
        ↓
    Phiên lưu trong bộ nhớ của một máy EC2
        ↓
    ALB không dính phiên → request rơi vào máy khác
        ↓
    → máy đó không biết phiên → bắt đăng nhập lại
        ↓
    STICKY SESSIONS trên target group
        ↓
    → ALB gắn cookie AWSALB, gửi về đúng máy cũ

⚠ Tầng thứ hai — CloudFront phải CHUYỂN TIẾP cookie đó:

CloudFront mặc định KHÔNG chuyển tiếp cookie
        ↓
    → cookie AWSALB của ALB bị BỎ RƠI
    → và cookie phiên của ứng dụng cũng vậy
        ↓
    → ALB không nhận được cookie
    → sticky session VÔ TÁC DỤNG
        ↓
    Phải khai cookie trong CACHE BEHAVIOR
        ↓
    → chỉ khi đó chuỗi mới thông từ đầu tới cuối

⚠ Nhưng phải khai CHỌN LỌC, đừng chuyển tiếp tất cả:

Chuyển tiếp TẤT CẢ cookie
        ↓
    → mỗi người dùng một khoá cache riêng
    → tỉ lệ cache hit gần bằng 0
        ↓
Cách đúng:
        ↓
    Đường dẫn ĐỘNG (/app/*, /api/*)
      → cache behavior riêng, TTL 0,
        chuyển tiếp cookie cần thiết
        ↓
    Đường dẫn TĨNH (/static/*, /images/*)
      → cache behavior riêng, TTL dài,
        KHÔNG chuyển tiếp cookie
        ↓
    → vừa giữ được phiên, vừa giữ được cache

Xem thêm câu #11909 (lô 129) và #11858 (lô 128): cùng chùm sticky session. Ở hai câu đó không có CloudFront nên chỉ cần bật sticky ở ALB; ở đây có thêm một tầng nên phải làm cả hai việc. Khoá nhất quán.

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

• D (bật group-level stickiness trên listener rule của ALB) — đây là phương án gần nhất và là một tính năng có thật, nhưng nó dùng khi một listener rule chuyển tiếp tới NHIỀU target group theo trọng số — nó giữ người dùng ở cùng một target group, không phải cùng một máy. Không giải quyết vấn đề phiên trong bộ nhớ máy.

• B (chuyển tiếp header) — chuyển tiếp header không mang cookie phiên; và chuyển tiếp thừa header còn làm giảm tỉ lệ cache hit.

• C (bật slow start trên target group) — slow start tăng dần lưu lượng cho target mới thêm vào, giúp máy khởi động êm. Hoàn toàn không liên quan tới phiên.

Ghi nhớ

⚠ Chuỗi giữ phiên qua CloudFront + ALB — bảng phải thuộc: | Tầng | Việc cần làm | |---|---| | CloudFront | chuyển tiếp cookie trong cache behavior của đường dẫn động | | ALB target group | bật sticky sessions (stickiness.enabled) | | Ứng dụng | lý tưởng nhất là KHÔNG giữ trạng thái | | Thiếu một tầng | cả chuỗi hỏng — người dùng vẫn bị đăng xuất |

Từ khoá nhận diện:

"bị đăng xuất, có CloudFront + ALB" → chuyển tiếp cookie + sticky session "bị đăng xuất, chỉ có ALB" → sticky session "mất phiên khi máy bị thay" → đưa phiên ra ngoài: Redis / DynamoDB "cache hit thấp" → chuyển tiếp quá nhiều cookie / query string "máy mới nhận tải quá nhanh" → slow start

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cookie có tới ALB không | DevTools → xem cookie AWSALB có được gửi kèm request | | Sticky đã bật chưa | describe-target-group-attributes | | Cache hit có tụt không | chỉ số CacheHitRate sau khi bật chuyển tiếp cookie |

Và một hệ quả cần theo dõi ngay sau khi bật chuyển tiếp cookie: tỉ lệ cache hit sẽ giảm. Nếu bạn khai cookie ở cache behavior mặc định thay vì chỉ ở đường dẫn động, mỗi người dùng sẽ có một tập cache riêng và CloudFront gần như chỉ còn là lớp trung chuyển — nên việc tách đường dẫn tĩnh ra một behavior riêng không phải chuyện tuỳ chọn, mà là điều kiện để giữ được cả hai mục tiêu.

Đáp án

A — Xác nhận có luật OUTBOUND trong security group cho phép lưu lượng qua CỔNG 443 tới 0.0.0.0/0.

Vì sao đúng

Máy cần gọi RA một địa chỉ HTTPS bên ngoài, nên thứ cần kiểm tra là đường ĐI RA, ở đúng cổng 443.

⚠ Điểm mấu chốt — chiều và cổng phải khớp với hành vi:

Máy gọi https://example.com
        ↓
    → kết nối ĐI RA
    → tới cổng ĐÍCH 443
        ↓
    Security group phải cho phép:
      Outbound, TCP 443, tới 0.0.0.0/0
        ↓
    Mặc định outbound của SG là MỞ HẾT
        ↓
    → nhưng nhiều tổ chức SIẾT LẠI vì bảo mật
    → và siết nhầm là chặn luôn HTTPS
        ↓
    → đây là nguyên nhân hợp lý nhất

⚠ Vì sao chiều VÀO không liên quan:

Security group có TRẠNG THÁI (stateful)
        ↓
    Kết nối đi ra đã được cho phép
      → phản hồi TỰ ĐỘNG được đi vào
        ↓
    → KHÔNG cần luật inbound nào
    → phương án C sai vì lý do này

⚠ Nhưng với private subnet còn phải kiểm tra ĐƯỜNG RA:

Private subnet gọi ra internet
        ↓
    Cần một trong hai:
      - NAT Gateway (và tuyến 0.0.0.0/0 → nat-)
      - VPC endpoint (nếu đích là dịch vụ AWS)
        ↓
    Không có → kết nối TIMEOUT
        ↓
    → trong bốn phương án đề cho,
      chỉ A chạm tới nguyên nhân có thật

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

• B (luật NACL outbound cho phép dải cổng tạm 1024-65535 tới 0.0.0.0/0) — đây là phương án gần nhất và dải cổng tạm đúng là một khái niệm quan trọng của NACL, nhưng nó áp cho chiều VÀO của gói trả lời, không phải chiều ra của gói yêu cầu. Gói đi ra tới cổng 443, còn cổng tạm là ở chiều ngược lại. (Và NACL mặc định của VPC đã mở cả hai chiều.)

• C (luật security group INBOUND cho phép cổng 443 từ 0.0.0.0/0) — sai chiều: SG là stateful, phản hồi tự động được vào. Và mở 443 từ cả internet vào một máy private là rủi ro bảo mật không cần thiết.

• D (luật NACL outbound cho phép cổng 80) — sai cổng: https:// dùng 443, không phải 80.

Ghi nhớ

⚠ Chiều và cổng — bảng phải thuộc: | Tình huống | Cần luật gì | |---|---| | Máy GỌI RA một dịch vụ HTTPS | SG outbound, cổng đích 443 | | Máy NHẬN kết nối HTTPS vào | SG inbound, cổng 443 | | NACL cho kết nối ĐI RA | outbound cổng đích, inbound cổng tạm 1024-65535 | | NACL cho kết nối ĐI VÀO | inbound cổng dịch vụ, outbound cổng tạm | | Ghi nhớ | SG stateful → chỉ cần một chiều; NACL stateless → cần cả hai |

Từ khoá nhận diện:

"máy gọi ra một địa chỉ HTTPS" → SG outbound 443 "kết nối TCP hỏng một chiều với NACL" → thiếu DẢI CỔNG TẠM "private subnet không ra được internet" → NAT Gateway, hoặc VPC endpoint "gọi dịch vụ AWS mà không qua internet" → VPC endpoint "timeout" → gói bị bỏ im lặng: SG, NACL, route table

Ba việc kiểm chứng: | Việc | Cách | |---|---| | SG cho phép gì chiều ra | describe-security-groups — đọc IpPermissionsEgress | | Máy có ra được không | curl -v https://example.com trên chính máy đó | | Bị chặn ở đâu | Flow Logs, tìm REJECT với dstPort = 443 |

Và một bước nên làm trước khi soi từng luật: chạy curl -v ngay trên máy đó. Kết quả nói cho bạn biết vấn đề ở tầng nào — treo ở bước "Trying..." là lỗi mạng hoặc định tuyến, lỗi phân giải tên miền là vấn đề DNS, còn nếu bắt tay TLS thất bại thì mạng đã thông và nguyên nhân nằm ở nơi khác hoàn toàn.

Đáp án

C — Tạo AWS Config rule được kích hoạt khi cấu hình CloudTrail thay đổi, và áp hành động khắc phục tự động AWS-ConfigureCloudTrailLogging.

Vì sao đúng

Đề có một ràng buộc quyết định: KHÔNG viết mã tuỳ chỉnh nào. Config có sẵn cả luật lẫn document khắc phục cho đúng việc này.

⚠ Điểm mấu chốt — mô hình phát hiện + khắc phục, không cần code:

PHÁT HIỆN
        ↓
    Luật Config quản lý sẵn: cloudtrail-enabled
    (hoặc cloud-trail-enabled)
        ↓
    Đánh giá lại khi CẤU HÌNH THAY ĐỔI
        ↓
    CloudTrail bị tắt → NON_COMPLIANT
        ↓
KHẮC PHỤC
        ↓
    Gắn REMEDIATION ACTION vào chính luật đó
        ↓
    SSM Automation document có sẵn:
      AWS-ConfigureCloudTrailLogging
        ↓
    → BẬT LẠI CloudTrail, tự động
    → không một dòng mã nào

⚠ Hai chế độ khắc phục — chọn "tự động" cho yêu cầu này:

Manual remediation
        ↓
    Config phát hiện → người bấm nút để sửa

Automatic remediation  ← đề này
        ↓
    Config phát hiện → TỰ CHẠY document
        ↓
    Có tham số:
      MaximumAutomaticAttempts
      RetryAttemptSeconds
        ↓
    → đề nói "immediately and automatically"
      → chọn chế độ tự động

⚠ Nhưng cách NGĂN CHẶN còn tốt hơn:

Config + remediation là PHÁT HIỆN rồi SỬA
        ↓
    → vẫn có một khoảng thời gian CloudTrail bị tắt
    → log của khoảng đó MẤT VĨNH VIỄN
        ↓
NGĂN CHẶN — nên làm cùng lúc:
        ↓
    1. SCP chặn cloudtrail:StopLogging,
       DeleteTrail, UpdateTrail
    2. ORGANIZATION TRAIL
       → tài khoản thành viên KHÔNG tắt được
    3. Log ghi vào bucket ở TÀI KHOẢN KHÁC
       + S3 Object Lock

Xem thêm câu #11792 (lô 127) và #11845 (lô 128): cùng mô hình Config phát hiện + SSM Automation khắc phục, áp cho các loại tài nguyên khác. Khoá nhất quán.

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

• B (Config rule kích hoạt Lambda để bật lại CloudTrail) — đây là phương án gần nhất và chạy được, nhưng nó đòi viết mã Lambda — vi phạm thẳng ràng buộc "without writing any custom code". Trong khi document có sẵn làm đúng việc đó.

• A (EventBridge chạy theo lịch mỗi giờ để bật lại CloudTrail) — phản ứng chậm tới một giờ, không phải "ngay lập tức". Và nó chạy cả khi không có gì thay đổi.

• D (dùng Amazon Inspector phân tích cấu hình rồi gọi Lambda) — Inspector quét LỖ HỔNG phần mềm, không kiểm tra cấu hình dịch vụ. Và cũng đòi viết mã.

Ghi nhớ

⚠ Ngăn chặn ↔ Phát hiện ↔ Khắc phục — bảng phải thuộc: | Loại | Công cụ | Đặc điểm | |---|---|---| | Ngăn chặn | SCP, organization trail, Object Lock | chặn TRƯỚC khi việc xảy ra | | Phát hiện | AWS Config, Security Hub, GuardDuty | báo sau khi đã xảy ra | | Khắc phục | SSM Automation document | tự sửa cái đã phát hiện | | Tốt nhất | dùng cả ba tầng | |

Từ khoá nhận diện:

"tự động sửa, KHÔNG viết mã" → Config rule + SSM Automation document CÓ SẴN "không ai được tắt CloudTrail" → SCP + organization trail "phát hiện cấu hình sai" → AWS Config "phát hiện hành vi đe doạ" → GuardDuty "quét lỗ hổng phần mềm" → Inspector

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Luật có phát hiện được không | tắt thử trail ở môi trường test | | Khắc phục có chạy không | SSM → Automation → Executions | | Ai đã tắt | CloudTrail, tìm StopLogging — và nghịch lý là log đó cũng bị dừng |

Và một điểm hạn chế cố hữu của cách tiếp cận này đáng nói rõ: giữa lúc CloudTrail bị tắt và lúc Config sửa lại, mọi hoạt động trong khoảng đó không được ghi lại và không bao giờ khôi phục được. Đó chính là lý do organization trail cộng với SCP mới là biện pháp chính — Config remediation chỉ nên là lưới an toàn phía sau, không phải tuyến phòng thủ duy nhất.

Đáp án

C — Đặt CLOUDWATCH ALARM cho các service quota và cấu hình SNS gửi email khi mức dùng vượt 80%.

Vì sao đúng

Yêu cầu là cảnh báo tự động qua email khi mức dùng vượt một ngưỡng phần trăm — đó chính là mô hình alarm + SNS.

⚠ Điểm mấu chốt — Service Quotas phát chỉ số vào CloudWatch:

Namespace: AWS/Usage
        ↓
    Chỉ số: ResourceCount
    Dimensions:
      Service   → ví dụ "EC2"
      Class     → "Standard/OnDemand"
      Type      → "Resource"
      Resource  → "vCPU"
        ↓
    → tạo CloudWatch alarm trên chỉ số này
        ↓
    Alarm action: SNS topic
        ↓
    SNS subscription: email đã XÁC NHẬN

⚠ Cách hay nhất — dùng METRIC MATH để tính phần trăm:

m1 = mức dùng hiện tại (AWS/Usage)
        ↓
    Biểu thức:  (m1 / SERVICE_QUOTA(m1)) * 100
        ↓
    → ra thẳng PHẦN TRĂM so với hạn mức
    → đặt ngưỡng 80
        ↓
    Hàm SERVICE_QUOTA() lấy giá trị hạn mức
    hiện tại một cách tự động
        ↓
    → hạn mức được nâng thì ngưỡng tự điều chỉnh
    → không phải sửa alarm bằng tay

⚠ Và Service Quotas có nút tạo alarm sẵn:

Service Quotas console
        ↓
    Chọn một quota → "Create alarm"
        ↓
    Khai ngưỡng phần trăm (ví dụ 80)
        ↓
    → console tự dựng CloudWatch alarm
      với metric math đúng
        ↓
    Chỉ áp dụng cho các quota
    có hỗ trợ CloudWatch usage metrics

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

• D (dùng Trusted Advisor để theo dõi rồi cấu hình SNS gửi email) — đây là phương án gần nhất và Trusted Advisor thật sự có mục kiểm tra Service Limits, nhưng nó cập nhật theo chu kỳ (thường hằng tuần), không đặt ngưỡng tuỳ ý được, và không tự gửi tới SNS — chỉ có bản tóm tắt hằng tuần qua email. Không phải cơ chế cảnh báo theo ngưỡng.

• A (dùng AWS Config theo dõi mức dùng quota, gửi qua Amazon SES) — Config theo dõi CẤU HÌNH tài nguyên, không theo dõi mức dùng so với hạn mức. Và SES là dịch vụ gửi email cho ứng dụng, không phải kênh cảnh báo hệ thống.

• B (dùng Personal Health Dashboard theo dõi quota, cảnh báo qua AWS Chatbot) — Health Dashboard báo sự kiện của AWS ảnh hưởng tới tài nguyên của bạn, không theo dõi mức dùng hạn mức theo phần trăm.

Ghi nhớ

⚠ Theo dõi hạn mức — bảng phải thuộc: | Công cụ | Đặc điểm | |---|---| | CloudWatch alarm trên AWS/Usage | ngưỡng tuỳ ý, thời gian gần thực, gửi SNS | | Service Quotas console | xem, xin tăng, tạo alarm sẵn | | Trusted Advisor → Service Limits | kiểm tra định kỳ, cảnh báo ở ~80%, không tuỳ chỉnh | | AWS Health + EventBridge | thông báo khi AWS thay đổi hạn mức | | Quota Request Template | tự xin tăng cho tài khoản MỚI trong tổ chức |

Từ khoá nhận diện:

"cảnh báo khi vượt N% hạn mức" → CloudWatch alarm + SNS "xin tăng hạn mức" → Service Quotas "kiểm tra nhanh sắp chạm hạn mức nào" → Trusted Advisor "tài khoản mới tự có hạn mức cao" → Quota Request Template "stack thất bại vì hạn mức" → đọc tab Events, rồi Service Quotas

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đang dùng bao nhiêu | Service Quotas console, hoặc chỉ số AWS/Usage | | Alarm có gửi được không | set-alarm-state --state-value ALARM rồi xem hộp thư | | Đăng ký SNS xác nhận chưa | list-subscriptions-by-topic |

Và một việc rất đáng làm với tổ chức có nhiều tài khoản: dựng bộ alarm hạn mức bằng CloudFormation StackSets. Khi đó mọi tài khoản, kể cả tài khoản được tạo vào tháng sau, đều tự có cùng một bộ cảnh báo — thay vì phải nhớ cấu hình thủ công cho từng nơi, và phát hiện ra thiếu sót vào đúng lúc một tài khoản nào đó chạm trần.