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

Đáp án

B — Elastic Load Balancing Access Logs.

Vì sao đúng

Đề liệt kê đúng bốn thứ mà access log ghi lại: IP client, độ trễ, đường dẫn request, phản hồi của máy chủ.

⚠ Điểm mấu chốt — access log ghi MỘT DÒNG cho MỖI request đi qua ELB:

Mỗi dòng chứa:
    client:port                  → IP CỦA CLIENT
    request_processing_time      → ELB nhận request
    target_processing_time       → ỨNG DỤNG xử lý       ← độ trễ
    response_processing_time     → ELB trả về
    request                      → "GET /san-pham/123"  ← đường dẫn
    elb_status_code / target_status_code → PHẢN HỒI
    user_agent, ssl_cipher, target_group_arn
        ↓
    → đủ cả bốn thứ đề yêu cầu, trong một nguồn duy nhất

⚠ Vì sao ba trường thời gian được tách riêng — đây là phần giá trị nhất:

target_processing_time cao
        ↓
    → ỨNG DỤNG chậm, không phải load balancer

request/response_processing_time cao
        ↓
    → vấn đề ở mạng hoặc client chậm
        ↓
    → biết ngay nên đi tìm nguyên nhân ở đâu

⚠ Ba đặc điểm phải nhớ về access log:

Mặc định TẮT — phải bật, và bucket S3 cần bucket policy đúng
Ghi theo lô MỖI 5 PHÚT — không phải thời gian thực
Tính năng MIỄN PHÍ — chỉ trả tiền lưu trữ S3

Phân tích bằng Athena (nhớ phân vùng theo ngày):

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

Xem thêm câu #11692 và #11716: cùng bộ nguồn dữ liệu quanh load balancer — #11692 cũng chọn access log (phân tích độ trễ và IP), còn #11716 chọn CloudTrail vì ở đó câu hỏi là về lời gọi API quản trị, không phải lưu lượng.

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

• C (VPC Flow Logs) — đây là phương án gần nhất vì nó cũng ghi lưu lượng mạng và cũng có IP nguồn. Nhưng Flow Logs làm việc ở tầng 3/4: chỉ có IP, cổng, giao thức, số byte, ACCEPT/REJECT. Nó không biết gì về HTTP — không có đường dẫn, không có mã trạng thái, không có độ trễ ứng dụng.

• A (CloudTrail Logs) — ghi lời gọi API quản trị (CreateLoadBalancer, ModifyListener), không ghi lưu lượng HTTP của người dùng.

• D ("VPC Network Logs") — không tồn tại. Tên đúng là VPC Flow Logs.

Ghi nhớ

⚠ Bốn nguồn log và tầng chúng làm việc — bảng phải thuộc: | Nguồn | Tầng | Ghi gì | |---|---|---| | ELB access log | 7 (HTTP) | đường dẫn, mã trạng thái, độ trễ, IP client | | VPC Flow Logs | 3/4 (IP/TCP) | IP, cổng, byte, ACCEPT/REJECT | | CloudTrail | API | ai gọi API nào | | CloudWatch Logs | ứng dụng | log do ứng dụng đẩy lên |

Từ khoá nhận diện:

"đường dẫn HTTP, mã trạng thái, độ trễ" → ELB access log "gói tin bị chặn ở đâu" → VPC Flow Logs "ai đổi cấu hình" → CloudTrail "VPC Network Logs" → KHÔNG TỒN TẠI "lần theo request qua nhiều dịch vụ" → X-Ray

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 tốn bao nhiêu | Athena báo "data scanned" sau mỗi lần chạy |

Và một lời khuyên nên áp dụng cho mọi load balancer sản xuất: hãy bật access log ngay từ ngày dựng, cùng với một lifecycle policy cho bucket chứa log. Access 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ố hiệu năng hay một đợt lưu lượng bất thường, thứ quyết định bạn có câu trả lời hay không là việc ai đó đã bật nó từ trước, chứ không phải việc bạn bật nó nhanh đến đâu lúc ấy.

Đáp án

A — Chứng chỉ do Amazon cấp KHÔNG cài được lên EC2 instance. Muốn mã hoá toàn tuyến thì phải dùng chứng chỉ SSL của bên thứ ba.

Vì sao đúng

ACM có một giới hạn thiết kế rất quan trọng: bạn không bao giờ lấy được private key.

⚠ Điểm mấu chốt — ACM giữ private key và không cho xuất ra:

Chứng chỉ ACM công khai (miễn phí)
        ↓
    AWS sinh và GIỮ private key trong hạ tầng của mình
        ↓
    → KHÔNG có API nào xuất private key
    → KHÔNG tải về được bằng Console hay CLI
        ↓
    → mà cài chứng chỉ lên EC2 thì BẮT BUỘC phải có private key
        ↓
    → nên chứng chỉ ACM công khai KHÔNG cài lên EC2 được

⚠ ACM chỉ tích hợp được với các dịch vụ mà AWS tự kết thúc TLS:

Dùng được:
    Application/Network Load Balancer
    CloudFront (chứng chỉ phải ở us-east-1)
    API Gateway
    Elastic Beanstalk (qua ELB)
    App Runner, AppSync
        ↓
KHÔNG dùng được:
    EC2 instance          ← câu này
    Máy chủ tại chỗ
    Container tự chạy TLS

⚠ Vậy làm mã hoá toàn tuyến thế nào:

Chặng 1: Người xem → ALB
        ↓
    Dùng chứng chỉ ACM MIỄN PHÍ  ✓

Chặng 2: ALB → EC2
        ↓
    EC2 cần chứng chỉ CỦA RIÊNG NÓ:
        - chứng chỉ của bên thứ ba (đáp án của đề), HOẶC
        - chứng chỉ TỰ KÝ, HOẶC
        - chứng chỉ từ ACM PRIVATE CA
        ↓
    ALB KHÔNG kiểm tra chứng chỉ của target
        ↓
    → chỉ cần backend nói được HTTPS là đủ

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

Đáp án nói phải dùng chứng chỉ của bên thứ ba, nhưng thực tế còn hai lựa chọn khác tốt hơn mà đề không nêu:

1. Chứng chỉ TỰ KÝ (self-signed)
        ↓
    → hoàn toàn hợp lệ cho chặng ALB → EC2
    → vì ALB KHÔNG kiểm tra chứng chỉ của target
    → chính là phương án B, bị đánh dấu sai

2. AWS Private CA (ACM Private CA)
        ↓
    → dịch vụ của AWS, XUẤT ĐƯỢC private key
    → cài lên EC2 được, tự động xoay chứng chỉ
    → đây là cách làm CHUẨN NHẤT hiện nay

Khoá đáp án giữ nguyên vì trong bốn phương án đã cho, A là phương án duy nhất phát biểu đúng về mặt kỹ thuật (chứng chỉ ACM công khai thật sự không cài lên EC2 được). Nhưng khi thiết kế hệ thống thật, AWS Private CA mới là lựa chọn nên dùng.

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

• B (dùng chứng chỉ tự ký trên EC2) — đây là phương án gần nhất và trong thực tế nó hoạt động tốt cho chặng ALB → EC2. Nhưng nó không trả lời câu hỏi mà đề đặt ra ("cách đúng để cài chứng chỉ do Amazon cấp lên EC2"), và với một chính sách bảo mật nghiêm ngặt thì chứng chỉ tự ký thường không được chấp nhận.

• D (nhập chứng chỉ ACM của load balancer vào EC2 qua CLI) — không thể: không có lệnh nào xuất được private key từ ACM.

• C (dùng ACM để "phơi bày" chứng chỉ của load balancer cho EC2) — không có cơ chế nào như vậy; chứng chỉ không "chia sẻ" sang instance được.

Ghi nhớ

⚠ Hai loại chứng chỉ của ACM — bảng phải thuộc: | | ACM public certificate | AWS Private CA | |---|---|---| | Chi phí | MIỄN PHÍ | có phí (theo CA và theo chứng chỉ) | | Xuất private key | KHÔNG | CÓ | | Cài lên EC2 | KHÔNG | CÓ | | Trình duyệt tin cậy | có | không — chỉ nội bộ | | Tự xoay | có, nếu dùng với dịch vụ AWS tích hợp | có |

Từ khoá nhận diện:

"cài chứng chỉ ACM công khai lên EC2" → KHÔNG ĐƯỢC "mã hoá toàn tuyến tới EC2" → AWS Private CA, hoặc chứng chỉ bên thứ ba, hoặc tự ký "chứng chỉ cho CloudFront" → ACM ở us-east-1, BẮT BUỘC "đã có chứng chỉ mua sẵn" → import-certificate vào ACM (nhưng không tự xoay được) "chứng chỉ sắp hết hạn" → ACM tự gia hạn nếu đang gắn với dịch vụ tích hợp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chứng chỉ đang gắn ở đâu | describe-certificate, xem InUseBy | | Chặng ALB → EC2 có mã hoá không | target group protocol phải là HTTPS | | Chứng chỉ backend còn hạn không | openssl s_client -connect <ip>:443 |

Và một lời khuyên cho hệ thống cần mã hoá toàn tuyến lâu dài: hãy dùng AWS Private CA thay vì chứng chỉ tự ký hay chứng chỉ mua ngoài. Chứng chỉ tự ký phải quản lý bằng tay trên từng máy và hết hạn vào những lúc không ai nhớ; chứng chỉ mua ngoài thì tốn tiền và cũng phải xoay thủ công — trong khi Private CA tích hợp thẳng với cơ chế cấp phát tự động, và đó là khác biệt giữa một hệ thống chạy được và một hệ thống chạy được suốt nhiều năm.

Đáp án

B — Tạo MỘT quy tắc với CẢ HAI kiểu kích hoạt: configuration change VÀ periodic.

Vì sao đúng

Đề nêu hai yêu cầu về thời điểm đánh giá, và AWS Config cho phép một quy tắc mang cả hai loại trigger.

⚠ Điểm mấu chốt — một quy tắc, hai kiểu kích hoạt, không cần tạo hai quy tắc:

Yêu cầu 1: đánh giá MỖI KHI có trail được tạo
        ↓
    → Configuration change trigger

Yêu cầu 2: đánh giá MỖI 8 GIỜ
        ↓
    → Periodic trigger

    ↓ AWS Config cho phép khai CẢ HAI trong CÙNG một quy tắc

{
  "ConfigRuleName": "cloudtrail-bat-moi-region",
  "Source": {
    "Owner": "CUSTOM_LAMBDA",
    "SourceIdentifier": "arn:aws:lambda:...:function:KiemTraCloudTrail",
    "SourceDetails": [
      { "EventSource": "aws.config",
        "MessageType": "ConfigurationItemChangeNotification" },
      { "EventSource": "aws.config",
        "MessageType": "ScheduledNotification",
        "MaximumExecutionFrequency": "Eight_Hours" }
    ]
  }
}

⚠ Vì sao cần cả hai — mỗi loại bù đắp cho điểm mù của loại kia:

Configuration change
        ↓
    Phản ứng TỨC THÌ khi tài nguyên thay đổi
        ↓
    Nhưng: nếu ai đó TẮT trail bằng cách nào đó mà
    Config không nhận được sự kiện, thì không đánh giá lại

Periodic
        ↓
    Quét lại toàn bộ theo lịch, KHÔNG phụ thuộc sự kiện
        ↓
    → lưới an toàn, bắt được cả những gì trigger kia bỏ sót

⚠ Năm giá trị hợp lệ của MaximumExecutionFrequency:

One_Hour, Three_Hours, Six_Hours, Twelve_Hours, TwentyFour_Hours
        ↓
    ⚠ KHÔNG có "Eight_Hours" trong danh sách chuẩn!

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

Đề yêu cầu chạy mỗi 8 giờ, nhưng AWS Config chỉ chấp nhận năm giá trị: 1, 3, 6, 12 và 24 giờ. Không có tuỳ chọn 8 giờ.

Trong thực tế, muốn chu kỳ 8 giờ thì phải:
        ↓
    - chọn Six_Hours (chạy dày hơn yêu cầu), hoặc
    - dùng EventBridge Scheduler gọi
      start-config-rules-evaluation mỗi 8 giờ

Khoá đáp án giữ nguyên vì điều mà câu hỏi thật sự kiểm tra là: một quy tắc Config có thể mang cả hai kiểu trigger cùng lúc — và điều đó hoàn toàn đúng. Con số 8 giờ chỉ là chi tiết minh hoạ chọn chưa chuẩn.

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

• C (tạo HAI quy tắc, một cho mỗi kiểu trigger) — đây là phương án gần nhất và về mặt kỹ thuật thì chạy được. Nhưng nó không tối ưu: bạn phải bảo trì hai quy tắc trùng logic, kết quả compliance bị tách làm hai chỗ, và chi phí Config nhân đôi (tính theo số lần đánh giá).

• A (chỉ dùng configuration change) — thoả yêu cầu thứ nhất, trượt yêu cầu thứ hai.

• D (chỉ dùng periodic) — thoả yêu cầu thứ hai, trượt yêu cầu thứ nhất, và phản ứng chậm hơn nhiều.

Ghi nhớ

⚠ Hai kiểu trigger của AWS Config rule — bảng phải thuộc: | Kiểu | Khi nào chạy | Dùng cho | |---|---|---| | Configuration change | ngay khi tài nguyên thay đổi | phát hiện nhanh | | Periodic | theo chu kỳ cố định | lưới an toàn, kiểm tra tổng thể | | Cả hai | kết hợp | an toàn nhất — đáp án của câu này |

Từ khoá nhận diện:

"vừa tức thì vừa định kỳ" → một quy tắc với CẢ HAI trigger "chu kỳ đánh giá" → 1, 3, 6, 12, 24 giờ (không có giá trị khác) "quy tắc dựng sẵn của AWS" → managed rule "logic riêng của công ty" → custom rule bằng Lambda hoặc Guard "tự sửa khi phát hiện vi phạm" → remediation action (SSM Automation)

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Quy tắc dùng trigger gì | describe-config-rules, xem SourceDetails | | Lần đánh giá gần nhất | describe-config-rule-evaluation-status | | Ép đánh giá lại ngay | start-config-rules-evaluation |

Và một lời khuyên trước khi viết bất kỳ custom rule nào: hãy tra danh sách managed rule của AWS trước. Có hàng trăm quy tắc dựng sẵn cho những chuẩn phổ biến nhất — bao gồm cả multi-region-cloud-trail-enabled đúng cho yêu cầu của đề này — và mỗi custom rule bạn viết là một hàm Lambda phải bảo trì, phải vá, và phải sửa mỗi khi AWS đổi cấu trúc dữ liệu cấu hình.

Đáp án

B — Network ACL là STATELESS, nên bạn phải cho phép cả lưu lượng vào lẫn lưu lượng ra. Mở chiều ra là kết nối hoạt động.

Vì sao đúng

Đề đã tự loại trừ gần hết nghi phạm: inbound đã mở ở CẢ Security Group LẪN Network ACL. Chỉ còn đúng một chỗ chưa được kiểm tra.

⚠ Điểm mấu chốt — NACL xét từng gói tin một cách độc lập:

Client → EC2 (request)
        ↓
    NACL inbound cho phép cổng dịch vụ  ✓ vào được
        ↓
    Ứng dụng xử lý, gửi phản hồi
        ↓
    Phản hồi đi RA: từ cổng dịch vụ → CỔNG TẠM của client
        ↓
    NACL outbound không mở dải cổng tạm  ✗ CHẶN
        ↓
    → client thấy TIMEOUT
    → không có thông báo lỗi nào từ phía máy chủ

⚠ Security Group không có vấn đề này vì nó có TRẠNG THÁI:

Security Group ghi nhớ mỗi kết nối đã cho phép
        ↓
    → gói phản hồi TỰ ĐỘNG được đi ra
    → không cần luật outbound nào

⚠ Luật NACL outbound phải mở dải cổng tạm, không phải cổng dịch vụ:

Linux           : 32768–60999
Windows 2008+   : 49152–65535
NLB / Lambda    : 1024–65535
        ↓
    → cách an toàn: mở 1024–65535 cho chiều ra

Xem thêm câu #11721: cùng tình huống và cùng đáp án với câu này — hai câu chỉ khác cách diễn đạt đề bài. Cùng chủ đề còn có #11631 (mất kết nối tới RDS) và #11686 (cho phép hai VPC nói chuyện).

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

• D (Security Group là stateless, phải mở cả hai chiều) — đây là phương án gần nhất và đảo ngược hai khái niệm. Đây chính là bẫy: hai phương án B và D chỉ khác nhau ở việc đổi chỗ tên hai dịch vụ.

• A (phải cấu hình Internet Gateway để truy cập EC2 từ internet) — có thể đúng trong một tình huống khác (nếu instance nằm ở private subnet). Nhưng đề nói đội kiểm thử đang cố kết nối tới dịch vụ, và vấn đề đã được khoanh vào hai lớp lọc — IGW không phải nghi phạm ở đây.

• C (triển khai nhiều Availability Zone để có tính sẵn sàng cao) — nói về kiến trúc chịu lỗi, hoàn toàn không liên quan tới việc một kết nối bị chặn.

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 | STATELESS | | Luật | chỉ Allow | 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ả | theo số thứ tự, dừng ở luật khớp đầu | | Chặn một IP | không được | được |

Từ khoá nhận diện:

"đã mở inbound cả hai lớp mà vẫn timeout" → NACL outbound thiếu cổng tạm "SG là stateless" → LUÔN SAI "NACL là stateful" → LUÔN SAI "chặn một IP cụ thể" → NACL "connection refused ngay" → thường là dịch vụ chưa chạy, không phải mạng "timeout" → NACL, SG, hoặc route table

Ba việc kiểm chứng: | Việc | Cách | |---|---| | NACL có mở chiều ra không | describe-network-acls — xem cả Egress: true | | Gói bị bỏ ở đâu | VPC Flow Logs, lọc action = REJECT | | Đường đi có thông không | VPC Reachability Analyzer |

Và một lời khuyên rút ra từ việc chủ đề này xuất hiện đi xuất hiện lại: hãy để NACL ở cấu hình mặc định và dồn toàn bộ luật lọc vào Security Group, trừ khi thật sự cần chặn một IP cụ thể. NACL stateless là nguồn gốc của một tỷ lệ rất lớn các sự cố mạng khó chẩn đoán nhất trên AWS — chúng gây timeout thay vì lỗi rõ ràng, và ai cũng quên mất chiều còn lại, vì trong đầu con người thì một kết nối vốn dĩ là thứ hai chiều.

Đáp án

A, B, C — ba điều đúng về địa chỉ IP của EC2 trong VPC:

• A — Mặc định EC2 và VPC dùng giao thức IPv4, và bạn KHÔNG tắt được hành vi này.
• C — Bạn KHÔNG thể gắn hay gỡ IP công cộng (auto-assigned) khỏi instance bằng tay.
• B — Nếu IP công cộng của instance đã bị thu hồi, nó sẽ KHÔNG được cấp IP mới nếu instance có nhiều hơn một network interface.

Vì sao đúng

⚠ Điều A — IPv4 là bắt buộc, IPv6 là tuỳ chọn thêm:

Mọi VPC bắt buộc có một CIDR block IPv4
        ↓
    Mọi instance đều nhận một IP RIÊNG IPv4
        ↓
    → không tắt được
        ↓
    IPv6 là CIDR block PHỤ, thêm vào nếu muốn
    → chạy song song, không thay thế IPv4

⚠ Điều C — IP công cộng tự động là thuộc tính CỦA instance, không phải tài nguyên riêng:

IP công cộng (auto-assigned)
        ↓
    AWS cấp lúc khởi chạy, gắn cứng vào instance
        ↓
    → KHÔNG có API associate-public-ip
    → KHÔNG có API disassociate-public-ip
    → mất khi stop, đổi địa chỉ khác khi start lại
        ↓
Elastic IP thì ngược lại
        ↓
    → là TÀI NGUYÊN ĐỘC LẬP của tài khoản
    → gắn và gỡ tuỳ ý bằng associate-address

⚠ Điều B — nhiều ENI thì không được cấp lại IP công cộng:

Instance có NHIỀU network interface
        ↓
    AWS không biết nên gắn IP công cộng vào ENI nào
        ↓
    → không tự cấp lại
        ↓
    → muốn có địa chỉ công cộng thì phải dùng ELASTIC IP
      và khai rõ gắn vào ENI nào

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

• D (instance có thể có CẢ IP công cộng LẪN Elastic IP) — đây là phương án gần nhất và là hiểu nhầm phổ biến. Khi bạn gắn Elastic IP vào một instance đang có IP công cộng tự động, AWS THU HỒI địa chỉ tự động đó. Một ENI chỉ có một địa chỉ công cộng cho mỗi IP riêng.

• E (mặc định AWS cấp IP công cộng cho instance ở CẢ default VPC lẫn non-default VPC) — sai một nửa: default VPC thì có, còn subnet trong VPC tự tạo thì mặc định MapPublicIpOnLaunch = false.

• F (IP công cộng bị thu hồi khi stop/terminate, nhưng giữ lại khi hibernate) — sai: hibernate cũng làm mất IP công cộng tự động, y như stop. Chỉ Elastic IP mới được giữ.

Ghi nhớ

⚠ Ba loại địa chỉ IP của EC2 — bảng phải thuộc: | Loại | Giữ khi stop/start | Gắn/gỡ thủ công | Tính tiền | |---|---|---|---| | Private IPv4 | CÓ | không (cố định trong ENI) | không | | Public IPv4 (auto) | KHÔNG | KHÔNG | có (từ 2024) | | Elastic IP | CÓ | CÓ | có, kể cả khi không dùng | | IPv6 | CÓ | có | không |

Từ khoá nhận diện:

"giữ nguyên địa chỉ khi thay máy" → Elastic IP "gỡ IP công cộng ra khỏi instance" → KHÔNG LÀM ĐƯỢC với địa chỉ tự động "gắn Elastic IP thì IP tự động thế nào" → bị THU HỒI "instance nhiều ENI" → không tự cấp IP công cộng "tắt IPv4 dùng IPv6 thôi" → KHÔNG được ở VPC thường

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Instance có những IP nào | describe-instances, xem NetworkInterfaces[] | | Elastic IP nào đang rảnh | describe-addresses — mục không có InstanceId là đang lãng phí tiền | | Subnet có tự cấp IP công cộng không | describe-subnets, xem MapPublicIpOnLaunch |

Và một lời nhắc về chi phí đã thay đổi gần đây: từ tháng 2/2024, AWS tính phí cho MỌI địa chỉ IPv4 công cộng, không chỉ Elastic IP nằm không. Với một fleet lớn dùng IP công cộng tự động, đây là một khoản phát sinh hoàn toàn mới — và cách xử lý thường là chuyển instance vào private subnet sau NAT Gateway hoặc sau load balancer, thứ mà lẽ ra đã nên làm vì lý do bảo mật.

Đáp án

C, D — hai điều đúng về IAM Group:

• C — Group được cấp quyền bằng chính sách kiểm soát truy cập (access control policy).
• D — Một IAM user có thể thuộc NHIỀU group, nhưng group KHÔNG thể thuộc group khác.

Vì sao đúng

⚠ Điều C — group tồn tại đúng để gắn chính sách:

Gắn chính sách vào GROUP
        ↓
    Mọi user trong group tự động có quyền đó
        ↓
    Thêm người mới → cho vào group → có quyền ngay
    Người nghỉ việc  → gỡ khỏi group → mất quyền ngay
        ↓
    → đây là cách quản lý quyền theo VAI TRÒ CÔNG VIỆC

⚠ Điều D — IAM group KHÔNG LỒNG NHAU được:

User "an" thuộc: LapTrinhVien, TrucCa, DocS3   ✓ hợp lệ
        ↓
    Quyền của an = HỢP của mọi chính sách từ ba group đó
                   + chính sách gắn trực tiếp cho an

Group "TruongNhom" chứa group "LapTrinhVien"   ✗ KHÔNG ĐƯỢC
        ↓
    → IAM không có phân cấp group
    → muốn "kế thừa" thì phải cho user vào cả hai group

⚠ Và điều quan trọng nhất, giải thích vì sao A và B đều sai:

GROUP KHÔNG PHẢI LÀ MỘT DANH TÍNH (identity)
        ↓
    → không có access key
    → không có mật khẩu
    → KHÔNG XUẤT HIỆN trong trường "Principal" của chính sách
    → KHÔNG đóng vai (assume role) được
        ↓
    → group chỉ là một CÁI TÚI ĐỰNG USER để gắn chính sách

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

• B (group không có chứng chỉ trực tiếp, nhưng có thể đóng vai IAM Role để truy cập dịch vụ) — đây là phương án gần nhất và vế đầu hoàn toàn đúng. Nhưng vế sau sai: group không đóng vai được, vì nó không phải principal. Chính USER trong group mới là bên gọi sts:AssumeRole — và họ làm được điều đó nhờ chính sách mà group cấp cho họ.

• A (group có thể được cấp chứng chỉ bảo mật để truy cập dịch vụ) — sai; group không có chứng chỉ nào.

• E (user thuộc nhiều group được, và group cũng thuộc group khác được) — vế đầu đúng, vế sau sai — chính là chỗ phân biệt với đáp án D.

Ghi nhớ

⚠ Ba loại danh tính IAM và group — bảng phải thuộc: | Đối tượng | Là principal | Có chứng chỉ | Đóng vai được | |---|---|---|---| | IAM User | CÓ | mật khẩu, access key | CÓ | | IAM Role | CÓ | chứng chỉ tạm thời | — | | IAM Group | KHÔNG | KHÔNG | KHÔNG |

Từ khoá nhận diện:

"group có access key" → LUÔN SAI "group lồng trong group" → LUÔN SAI "group đóng vai role" → LUÔN SAI "user thuộc nhiều group" → ĐÚNG "quản lý quyền cho nhiều người" → group + managed policy

⚠ Với môi trường NHIỀU TÀI KHOẢN như đề mô tả — group là cách làm đã lỗi thời:

IAM Group chỉ tồn tại TRONG MỘT tài khoản
        ↓
    Nhiều tài khoản → phải tạo lại user và group ở TỪNG tài khoản
        ↓
    → nhân bản cấu hình, khó kiểm toán, dễ lệch nhau
        ↓
IAM Identity Center (trước là AWS SSO)
        ↓
    → MỘT nơi quản lý danh tính cho CẢ TỔ CHỨC
    → permission set gán cho nhóm ở nhiều tài khoản
    → chứng chỉ TẠM THỜI, không có access key dài hạn
        ↓
    → đây mới là câu trả lời đúng cho bài toán của đề trong thực tế

Ba việc kiểm chứng: | Việc | Cách | |---|---| | User thuộc group nào | list-groups-for-user | | Group có chính sách gì | list-attached-group-policies | | Quyền hiệu lực thật | IAM Policy Simulator |

Và một lời khuyên cho đúng bối cảnh của đề — một đội lớn trải trên nhiều tài khoản AWS: hãy cân nhắc IAM Identity Center thay vì tiếp tục nhân bản user và group ở từng tài khoản. Cách làm bằng group chạy tốt trong một tài khoản, nhưng với nhiều tài khoản thì mỗi lần một người vào hay rời khỏi công ty là một loạt thao tác lặp lại ở nhiều nơi — và chính những thao tác lặp lại ấy là chỗ mà một tài khoản bị bỏ quên sẽ nằm lại nhiều tháng sau khi chủ nhân của nó đã nghỉ việc.

Đáp án

D — Thêm luật vào Network ACL cho phép lưu lượng ĐI RA trên dải cổng 1024–65535.

Vì sao đúng

Câu này kiểm tra hai thứ cùng lúc: hiểu NACL là stateless, và nhớ đúng dải cổng tạm.

⚠ Điểm mấu chốt — phản hồi đi ra qua CỔNG TẠM của client, không phải cổng 80:

Client (cổng tạm 54321) → Máy chủ (cổng 80)
        ↓
    NACL inbound cho phép cổng 80  ✓ request vào được
        ↓
    Máy chủ trả lời: từ cổng 80 → cổng 54321 của client
        ↓
    NACL outbound phải cho phép dải cổng TẠM
        ↓
    → không mở là phản hồi bị chặn
    → client thấy TIMEOUT

⚠ Vì sao dải 1024–65535 là câu trả lời an toàn nhất:

Client có thể là bất cứ thứ gì:
        Linux           → 32768–60999
        Windows 2008+   → 49152–65535
        Windows đời cũ  → 1025–5000
        NLB, Lambda     → 1024–65535
        ↓
    Máy chủ web phục vụ CẢ THẾ GIỚI
        ↓
    → không đoán được client dùng hệ điều hành gì
        ↓
    → mở 1024–65535 phủ được TẤT CẢ

Đây chính là dải mà tài liệu AWS khuyến nghị cho NACL của một subnet công khai.

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

• B (mở 32768–61000) — đây là phương án gần nhất và là dải cổng tạm của Linux, nên rất dễ chọn. Nhưng nó bỏ sót client Windows (49152–65535 nằm ngoài một phần, và Windows đời cũ dùng 1025–5000). Website công khai thì phải phục vụ mọi loại client.

• C (mở 1025–5000) — dải cổng tạm của Windows đời cũ, bỏ sót gần hết client hiện đại.

• A (thêm luật cho Security Group cho phép outbound cổng 80) — sai vì hai lẽ: Security Group là stateful nên phản hồi tự động được đi ra; và kể cả có thêm luật thì cũng phải là cổng tạm, không phải cổng 80.

Ghi nhớ

⚠ Dải cổng tạm theo hệ điều hành — bảng phải thuộc: | Hệ thống | Dải | |---|---| | Linux (kernel hiện đại) | 32768–60999 | | Windows Server 2008 trở lên | 49152–65535 | | Windows đời cũ | 1025–5000 | | NLB và Lambda | 1024–65535 | | Khuyến nghị cho NACL | 1024–65535 — phủ tất cả |

Từ khoá nhận diện:

"NACL outbound cho website công khai" → 1024–65535 "mở inbound rồi mà vẫn timeout" → NACL thiếu chiều ra "Security Group cần luật outbound cho phản hồi" → KHÔNG CẦN, SG stateful "chặn một IP cụ thể" → NACL (SG không có Deny) "connection refused ngay" → thường là dịch vụ chưa chạy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | NACL có mở chiều ra không | describe-network-acls — xem cả Egress: true | | Gói bị bỏ ở đâu | VPC Flow Logs, lọc action = REJECT | | Đường đi có thông không | VPC Reachability Analyzer |

Và một mẹo nhớ giúp không bao giờ chọn nhầm dải cổng: khi không chắc client là ai, hãy mở 1024–65535. Mọi dải cổng tạm của mọi hệ điều hành đều nằm trọn trong khoảng đó, và với chiều trả lời của một kết nối đã được chấp nhận ở chiều vào thì việc mở rộng này không tạo ra rủi ro mới — kẻ tấn công không thể chủ động khởi tạo kết nối chỉ bằng luật outbound.

Đáp án

D — S3 Server Side Encryption (mã hoá phía máy chủ) là thứ bạn KHÔNG phải chịu trách nhiệm.

Vì sao đúng

Trong bốn thứ được liệt kê, ba cái đầu là cấu hình bạn tự khai và tự vận hành, còn cái cuối là việc AWS thực hiện.

⚠ Điểm mấu chốt — SSE nghĩa là AWS làm việc mã hoá, không phải bạn:

S3 Server-Side Encryption
        ↓
    Bạn BẬT một công tắc
        ↓
    AWS thực hiện:
        - sinh và quản lý khoá (với SSE-S3)
        - mã hoá dữ liệu khi ghi
        - giải mã khi đọc
        - xoay khoá
        ↓
    → phần THỰC THI thuộc về AWS
    → bạn không viết mã, không quản khoá, không lo thuật toán

Đối lập với ba phương án còn lại:

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

Cần nói rõ để tránh hiểu sai: bạn VẪN chịu trách nhiệm QUYẾT ĐỊNH có bật mã hoá hay không.

Ranh giới thật sự nằm ở đây:
        ↓
    QUYẾT ĐỊNH bật mã hoá, chọn loại khoá
        → TRÁCH NHIỆM CỦA BẠN
        ↓
    THỰC HIỆN mã hoá, quản lý khoá, xoay khoá
        → TRÁCH NHIỆM CỦA AWS (với SSE-S3 và SSE-KMS)

Câu hỏi đang nói về vế thứ hai — phần cơ chế mã hoá — và theo nghĩa đó thì đáp án D đúng. Nhưng đừng rút ra kết luận rằng "mã hoá S3 là việc của AWS": nếu bạn không bật mã hoá thì dữ liệu không được mã hoá, và trách nhiệm cho lựa chọn đó hoàn toàn thuộc về bạn. (Từ tháng 1/2023, AWS bật SSE-S3 mặc định cho mọi bucket mới — nhưng bạn vẫn phải chọn nếu cần SSE-KMS cho yêu cầu kiểm toán.)

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

(Ba thứ này đều là trách nhiệm của khách hàng, nên chúng không phải đáp án cho câu hỏi "bạn KHÔNG chịu trách nhiệm cái gì".)

• C (bucket policy) — đây là phương án gần nhất về mức độ "nghe như AWS lo hộ", nhưng bucket policy hoàn toàn do bạn viết. Đây cũng là nguồn gốc của gần như mọi vụ rò rỉ dữ liệu S3 từng được công bố — và trách nhiệm luôn thuộc về khách hàng.

• B (S3 ACL) — cũng do bạn cấu hình. (AWS nay khuyến nghị tắt ACL bằng BucketOwnerEnforced và chỉ dùng bucket policy.)

• A (S3 versioning) — bạn bật, bạn quản lý phiên bản cũ, bạn đặt lifecycle để dọn.

Ghi nhớ

⚠ Mô hình trách nhiệm chia sẻ với S3 — bảng phải thuộc: | AWS lo | Khách hàng lo | |---|---| | Hạ tầng lưu trữ, độ bền 11 số 9 | Ai được truy cập (IAM, bucket policy, ACL) | | Thực hiện mã hoá (SSE) | QUYẾT ĐỊNH bật mã hoá và chọn loại khoá | | Sao chép dữ liệu qua nhiều AZ | Versioning, lifecycle, replication | | Vá và vận hành dịch vụ | Phân loại dữ liệu, tuân thủ | | An ninh vật lý trung tâm dữ liệu | Block Public Access, Object Lock |

Từ khoá nhận diện:

"AWS thực hiện mã hoá" → SSE-S3, SSE-KMS "ai được vào bucket" → KHÁCH HÀNG, luôn luôn "AWS tự sao lưu dữ liệu hộ tôi" → SAI — versioning và replication là của bạn "dùng AWS là tự động tuân thủ" → SAI "độ bền 11 số 9" → AWS đảm bảo — nhưng nó không chống được việc bạn tự xoá

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bucket có mã hoá không | get-bucket-encryption | | Ai vào được | IAM Access Analyzer for S3 | | Có bucket nào mở công khai không | Block Public Access ở cấp tài khoản và cấp bucket |

Và một điều đáng nhấn mạnh khi nói về trách nhiệm với S3: mã hoá và kiểm soát truy cập giải quyết hai vấn đề hoàn toàn khác nhau, và mã hoá là vấn đề dễ hơn nhiều. AWS đã lo phần khó của mã hoá cho bạn, thậm chí bật sẵn nó từ 2023 — nhưng chưa từng có vụ rò rỉ dữ liệu S3 nào xảy ra vì thiếu mã hoá; tất cả đều xảy ra vì một chính sách truy cập viết sai, và đó chính xác là phần mà không ai làm hộ bạn được.

Đáp án

A — EBS HDD volume loại st1 (Throughput Optimized HDD).

Vì sao đúng

Đề nêu hai ràng buộc: tải nặng về THÔNG LƯỢNG và CHI PHÍ THẤP. Chỉ st1 thoả cả hai.

⚠ Điểm mấu chốt — phân biệt THÔNG LƯỢNG với IOPS:

Throughput (thông lượng) — đo bằng MB/s
        ↓
    Đọc ghi TUẦN TỰ, khối dữ liệu LỚN
        ↓
    → log, big data, ETL, kho dữ liệu, xử lý video
    → HDD làm rất tốt và rẻ

IOPS — đo bằng số thao tác/giây
        ↓
    Đọc ghi NGẪU NHIÊN, khối dữ liệu NHỎ
        ↓
    → cơ sở dữ liệu giao dịch, ổ khởi động
    → cần SSD

⚠ Và st1 so với sc1 — cả hai đều là HDD, khác nhau ở mức truy cập:

st1 (Throughput Optimized HDD)
        ↓
    Throughput tới 500 MB/s
    Cho tải TRUY CẬP THƯỜNG XUYÊN, thiên thông lượng
        ↓
    → đúng mô tả "throughput intensive" của đề

sc1 (Cold HDD)
        ↓
    Throughput tới 250 MB/s — chỉ bằng một nửa
    Cho dữ liệu ÍT TRUY CẬP
        ↓
    → RẺ NHẤT, nhưng không đủ cho tải nặng

⚠ Và một hạn chế chung của cả hai loại HDD:

st1 và sc1 KHÔNG làm ổ khởi động được
        ↓
    Vì khởi động hệ điều hành là I/O NGẪU NHIÊN
        ↓
    → phải dùng gp3 (hoặc gp2, io1, io2) cho ổ gốc
    → HDD chỉ làm ổ DỮ LIỆU gắn thêm

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

• B (sc1 — Cold HDD) — đây là phương án gần nhất vì nó RẺ HƠN st1. Nhưng nó được thiết kế cho dữ liệu ít truy cập, throughput chỉ bằng một nửa, và cơ chế burst credit của nó cạn nhanh dưới tải liên tục. Đề nói "throughput intensive", nghĩa là truy cập thường xuyên.

• C (io1 — Provisioned IOPS SSD) — cho IOPS cao nhất, nhưng đắt nhất trong bốn lựa chọn và tối ưu cho I/O ngẫu nhiên. Dùng nó cho tải tuần tự là trả rất nhiều tiền cho thứ mình không cần.

• D (gp2 — General Purpose SSD) — đắt hơn HDD và cũng tối ưu cho I/O ngẫu nhiên. (Nếu chọn SSD thì gp3 luôn tốt hơn gp2 — rẻ hơn khoảng 20% và tách IOPS khỏi dung lượng.)

Ghi nhớ

⚠ Bốn nhóm EBS volume — bảng phải thuộc: | Loại | Kiểu | Tối ưu cho | Ổ boot | |---|---|---|---| | gp3 / gp2 | SSD | đa dụng, IOPS vừa phải | được | | io1 / io2 | SSD | IOPS cao, cơ sở dữ liệu | được | | st1 | HDD | THÔNG LƯỢNG, tuần tự | KHÔNG | | sc1 | HDD | lạnh, rẻ nhất | KHÔNG |

Từ khoá nhận diện:

"throughput intensive", "tuần tự", "big data", "log" → st1 "ít truy cập, rẻ nhất" → sc1 "IOPS cao, cơ sở dữ liệu" → io2 (hoặc gp3 nếu dưới 16.000 IOPS) "đa dụng, mặc định" → gp3 "ổ khởi động" → KHÔNG dùng st1 hay sc1 "độ trễ thấp nhất" → io2 Block Express

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tải là tuần tự hay ngẫu nhiên | chỉ số VolumeReadOps so với VolumeReadBytes — chia ra được kích thước I/O trung bình | | Có chạm trần throughput không | VolumeThroughputPercentage | | Burst credit còn không | BurstBalance — tụt về 0 là hiệu năng sập |

Và một lời khuyên khi chọn loại volume: hãy đo kích thước I/O trung bình của tải thật trước khi quyết định. Chia VolumeReadBytes cho VolumeReadOps sẽ cho biết mỗi thao tác đọc lấy bao nhiêu byte — con số vài trăm KB nghĩa là tải tuần tự và HDD sẽ tiết kiệm được rất nhiều tiền, còn con số vài KB nghĩa là tải ngẫu nhiên và chuyển sang HDD sẽ khiến hệ thống chậm đi thấy rõ.

Đáp án

B — Amazon RDS databases và Amazon Redshift clusters.

Vì sao đúng

Secrets Manager có Lambda xoay khoá DỰNG SẴN cho một số dịch vụ cơ sở dữ liệu của AWS — bạn không phải viết mã.

⚠ Điểm mấu chốt — danh sách dịch vụ có hỗ trợ xoay khoá dựng sẵn:

Amazon RDS         (MySQL, PostgreSQL, Oracle, SQL Server, MariaDB)
Amazon Aurora
Amazon Redshift
Amazon DocumentDB
        ↓
    → AWS cung cấp sẵn Lambda xoay khoá
    → chỉ cần bật và chọn lịch, không viết dòng nào

Trong bốn phương án, chỉ B liệt kê toàn dịch vụ nằm trong danh sách này.

⚠ Cơ chế xoay khoá — bốn bước mà Lambda phải thực hiện:

1. createSecret  → sinh giá trị bí mật MỚI, gắn nhãn AWSPENDING
2. setSecret     → cập nhật mật khẩu đó vào chính cơ sở dữ liệu
3. testSecret    → THỬ KẾT NỐI bằng giá trị mới
4. finishSecret  → đổi nhãn AWSPENDING thành AWSCURRENT
        ↓
    Bước 3 là lý do cơ chế này an toàn:
    nếu giá trị mới không dùng được thì KHÔNG chuyển sang

⚠ Hai chiến lược xoay khoá — biết cả hai:

Single user
        ↓
    Đổi mật khẩu của CHÍNH tài khoản đang dùng
        ↓
    → đơn giản, nhưng có KHOẢNG NGẮN mà kết nối cũ bị từ chối

Alternating users
        ↓
    Luân phiên giữa HAI tài khoản (ví dụ app_user và app_user_clone)
        ↓
    → KHÔNG có phút chết
    → cần một "superuser secret" để tạo và sửa tài khoản
    → an toàn hơn cho hệ thống không được gián đoạn

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

• D (Amazon EMR và Amazon Redshift) — đây là phương án gần nhất vì Redshift đúng là có hỗ trợ. Nhưng EMR không nằm trong danh sách dịch vụ có Lambda xoay khoá dựng sẵn.

• C (Amazon ECS và Amazon DocumentDB) — cũng đúng một nửa: DocumentDB có hỗ trợ, nhưng ECS thì không — ECS chỉ đọc secret từ Secrets Manager để truyền vào container, chứ không có gì để xoay.

• A (AWS CloudFormation và Amazon RDS) — RDS có hỗ trợ, nhưng CloudFormation không phải cơ sở dữ liệu và không có mật khẩu nào để xoay.

Ghi nhớ

⚠ Xoay khoá của Secrets Manager — bảng phải thuộc: | Dịch vụ | Lambda dựng sẵn | |---|---| | Amazon RDS (mọi công cụ) | CÓ | | Amazon Aurora | CÓ | | Amazon Redshift | CÓ | | Amazon DocumentDB | CÓ | | Dịch vụ khác / hệ thống ngoài | tự viết Lambda theo khuôn mẫu |

Từ khoá nhận diện:

"tự xoay mật khẩu cơ sở dữ liệu" → Secrets Manager "lưu cấu hình miễn phí" → Parameter Store "xoay khoá cho hệ thống ngoài AWS" → Secrets Manager + Lambda tự viết "xoay khoá mã hoá" → KMS key rotation (khác hoàn toàn) "ECS đọc secret" → được, nhưng không xoay

⚠ Secrets Manager và Parameter Store — bảng phải thuộc: | | Secrets Manager | Parameter Store | |---|---|---| | Chi phí | có phí theo secret + lời gọi | MIỄN PHÍ (Standard) | | Tự xoay khoá | CÓ, dựng sẵn cho RDS/Redshift/DocumentDB | KHÔNG | | Kích thước | 64 KB | 4 KB (8 KB Advanced) | | Sao chép chéo Region | CÓ | không | | Thời gian chờ khi xoá | 7–30 ngày | không có | | Chọn khi | bí mật cần xoay tự động | cấu hình đơn giản |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xoay khoá đã bật chưa | describe-secret, xem RotationEnabled và RotationRules | | Lần xoay gần nhất | LastRotatedDate | | Xoay có thành công không | log của Lambda xoay khoá — bước testSecret là nơi hay hỏng |

Và một lời khuyên trước khi bật xoay khoá tự động trên hệ thống sản xuất: hãy thử trước ở môi trường staging và đọc kỹ log của Lambda ở bước testSecret. Cơ chế này rất đáng tin khi hoạt động, nhưng nó thay đổi mật khẩu cơ sở dữ liệu thật — và nếu ứng dụng của bạn cache chuỗi kết nối vĩnh viễn thay vì lấy lại từ Secrets Manager, thì lần xoay đầu tiên sẽ là lần ứng dụng mất kết nối, vào đúng giờ mà lịch xoay đã đặt.