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

Đáp án

A, D — hai việc cần làm:

• D — Cài Systems Manager Agent (SSM Agent) lên các instance.
• A — Thêm quyền cho Session Manager vào instance profile.

Vì sao đúng

Chi tiết quyết định nằm ở hai chữ trong đề: AMI TUỲ CHỈNH.

⚠ Điểm mấu chốt — AMI tuỳ chỉnh thường KHÔNG có sẵn SSM Agent:

AMI của AWS (Amazon Linux, Ubuntu bản của AWS, Windows Server)
        ↓
    → SSM Agent đã CÀI SẴN

AMI TUỲ CHỈNH do công ty tự dựng
        ↓
    → có thể dựng từ ảnh gốc không có agent
    → hoặc agent bị gỡ trong quá trình làm sạch ảnh
        ↓
    → phải TỰ CÀI      ← điều D

⚠ Và điều A — agent cần chứng chỉ để nói chuyện với Systems Manager:

Agent chạy nhưng không có quyền
        ↓
    → không đăng ký được với dịch vụ SSM
    → máy KHÔNG xuất hiện trong Session Manager console
        ↓
    Gắn instance profile với chính sách
        AmazonSSMManagedInstanceCore
        ↓
    → agent nhận chứng chỉ tạm từ metadata service
    → đăng ký thành công

⚠ Và điểm rất đáng nhớ về Session Manager — E sai vì lý do này:

Session Manager KHÔNG dùng cổng 22
        ↓
    Agent tự khởi tạo kết nối RA NGOÀI (outbound HTTPS 443)
    tới endpoint của SSM
        ↓
    → KHÔNG cần mở cổng vào nào
    → KHÔNG cần IP công cộng
    → KHÔNG cần bastion host
        ↓
    → đây chính là lý do Session Manager an toàn hơn SSH

Xem thêm câu #11813: cùng bộ điều kiện này ở một tình huống khác — ở đó agent đã cài sẵn nên chỉ thiếu instance profile. Hai câu bổ sung nhau thành danh sách kiểm tra đầy đủ.

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

• E (sửa security group để cho phép lưu lượng vào cổng SSH 22) — đây là phương án gần nhất vì đề nhắc tới "SSH session", nên rất dễ chọn. Nhưng Session Manager hoàn toàn không dùng cổng 22; mở cổng đó chỉ làm tăng bề mặt tấn công mà không giải quyết gì.

• B (thêm access key vào instance để cấp quyền cho Session Manager) — trái thực hành tốt nghiêm trọng: EC2 phải dùng IAM role qua instance profile, không bao giờ nhúng access key. Khoá dài hạn nằm trên máy là khoá có thể bị đánh cắp.

• C (chạy Systems Manager Inventory để làm mới dữ liệu instance) — Inventory kiểm kê phần mềm trên các máy ĐÃ được quản lý. Máy chưa đăng ký được thì Inventory không thấy nó, nên chạy Inventory không giúp gì.

Ghi nhớ

⚠ Ba điều kiện để SSM quản lý được một máy — bảng phải thuộc: | Điều kiện | Chi tiết | |---|---| | SSM Agent | cài sẵn trên AMI của AWS; AMI tuỳ chỉnh phải TỰ CÀI | | IAM instance profile | chính sách AmazonSSMManagedInstanceCore | | Đường mạng ra tới endpoint SSM | NAT Gateway hoặc 3 interface VPC endpoint |

Từ khoá nhận diện:

"AMI tuỳ chỉnh, máy không hiện trong SSM" → thiếu agent VÀ/HOẶC instance profile "Session Manager cần mở cổng 22" → LUÔN SAI "nhúng access key vào EC2" → LUÔN SAI, dùng instance profile "máy tại chỗ" → hybrid activation, id bắt đầu bằng mi- "private subnet không có NAT" → 3 VPC endpoint cho SSM

⚠ Vì sao Session Manager tốt hơn SSH truyền thống: | Ưu điểm | Nội dung | |---|---| | Không mở cổng vào nào | agent tự kết nối ra, giảm hẳn bề mặt tấn công | | Không quản lý khoá | không có tệp .pem để mất hay để lộ | | Phân quyền bằng IAM | thu hồi tức thì | | Ghi log toàn bộ phiên | ra S3 hoặc CloudWatch Logs — rất quan trọng cho kiểm toán | | Không cần bastion | và không cần IP công cộng | | Hoạt động với | EC2, máy tại chỗ, container |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Máy nào đang được quản lý | describe-instance-information | | Agent có kết nối được không | đọc log của chính agent | | Phiên làm việc có được ghi lại không | cấu hình Session Manager logging ra S3/CloudWatch |

Và một tính năng nên bật ngay khi triển khai Session Manager cho hệ thống sản xuất: ghi log toàn bộ phiên làm việc ra S3 hoặc CloudWatch Logs. Nó ghi lại mọi lệnh mà mọi người đã gõ trên máy chủ — thứ mà SSH truyền thống gần như không bao giờ có, và là thứ đầu tiên kiểm toán viên hỏi tới khi cần biết ai đã làm gì trên hệ thống.

Đáp án

B — Tạo một cache cluster MỚI với node type mới bằng API CreateCacheCluster.

Vì sao đúng

Memcached trên ElastiCache có một ràng buộc quan trọng: không đổi được node type của cụm đang chạy.

⚠ Điểm mấu chốt — Memcached không hỗ trợ mở rộng DỌC tại chỗ:

ModifyCacheCluster với Memcached
        ↓
    Sửa được: SỐ NODE (thêm/bớt), parameter group,
               security group, maintenance window
        ↓
    KHÔNG sửa được: NODE TYPE (loại instance)
        ↓
    → muốn node to hơn: TẠO CỤM MỚI

⚠ Và vì sao ràng buộc này ít gây đau đớn với Memcached:

Memcached KHÔNG bền vững — dữ liệu là CACHE thuần
        ↓
    Tạo cụm mới, trỏ ứng dụng sang
        ↓
    → cache trống, ứng dụng nạp lại dần từ nguồn gốc
    → dữ liệu KHÔNG mất gì (vì nó vốn tái tạo được)
        ↓
    Chỉ có một khoảng ngắn tỷ lệ trúng cache thấp
      và tải xuống cơ sở dữ liệu tăng

⚠ Quy trình chuyển đổi ít gián đoạn:

1. Tạo cụm MỚI với node type lớn hơn
2. (tuỳ chọn) Cho ứng dụng ghi vào CẢ HAI cụm một thời gian
   để làm ấm cache mới
3. Đổi CONFIGURATION ENDPOINT trong cấu hình ứng dụng
4. Theo dõi CacheHitRate của cụm mới
5. Xoá cụm cũ khi tỷ lệ trúng cache đã ổn định

Xem thêm câu #11782: cùng chủ đề chọn Memcached hay Redis — ở đó chính khả năng thêm/bớt node đơn giản là lý do chọn Memcached. Câu này cho thấy mặt còn lại: mở rộng DỌC thì không làm tại chỗ được.

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

• C (sửa cụm hiện tại bằng ModifyCacheCluster) — đây là phương án gần nhất và API đó có thật, dùng cho cụm Memcached. Nhưng nó không đổi được CacheNodeType; nó chỉ đổi được số node và các cấu hình khác.

• A (dùng CreateReplicationGroup và khai CacheNodeType mới) — CreateReplicationGroup chỉ dành cho REDIS. Memcached không có khái niệm replication group — nó không sao chép gì cả.

• D (khai CacheNodeType mới qua ModifyCacheParameterGroup) — parameter group chỉ chứa THAM SỐ CẤU HÌNH của công cụ (kích thước item tối đa, số luồng…). Nó không quyết định loại phần cứng nào.

Ghi nhớ

⚠ Mở rộng ElastiCache — bảng phải thuộc: | | Memcached | Redis | |---|---|---| | Mở rộng NGANG (thêm node) | CÓ — đơn giản | có (thêm replica hoặc shard) | | Mở rộng DỌC (đổi node type) | KHÔNG — phải tạo cụm mới | CÓ (ModifyReplicationGroup) | | Dữ liệu khi thay đổi | mất (là cache thuần) | giữ được | | Auto Discovery | có | dùng cluster endpoint |

Từ khoá nhận diện:

"đổi node type của Memcached" → tạo cụm MỚI "thêm/bớt node Memcached" → ModifyCacheCluster, đơn giản "mở rộng dọc Redis" → ModifyReplicationGroup, giữ được dữ liệu "CreateReplicationGroup" → chỉ dành cho Redis "parameter group" → tham số công cụ, không phải loại phần cứng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cụm đang dùng node type gì | describe-cache-clusters, xem CacheNodeType | | Cache có đủ lớn không | chỉ số Evictions | | Cụm mới đã ấm chưa | CacheHitRate đã trở lại mức cũ chưa |

Và một điều cần chuẩn bị trước khi chuyển sang cụm mới: hãy sẵn sàng cho việc tải xuống cơ sở dữ liệu tăng vọt trong thời gian cache mới nạp lại. Một cache đang phục vụ 90% lưu lượng khi bị thay bằng cụm trống nghĩa là cơ sở dữ liệu phải gánh gấp mười lần trong vài phút — hãy làm việc này vào giờ thấp điểm, và theo dõi sát chỉ số của tầng dữ liệu.

Đáp án

B — AWS WAF.

Vì sao đúng

Đề mô tả một IP gửi rất nhiều request lỗi 404 liên tục — dấu hiệu điển hình của bot quét dữ liệu, và WAF có đúng công cụ cho việc này.

⚠ Điểm mấu chốt — rate-based rule chặn theo tần suất từ một IP:

WAF rate-based rule
        ↓
    Đếm số request từ MỖI IP trong cửa sổ 5 phút
        ↓
    Vượt ngưỡng → tự động CHẶN IP đó
        ↓
    Tự bỏ chặn khi tần suất giảm xuống dưới ngưỡng
        ↓
    → không cần ai can thiệp
    → phản ứng được với IP mới mà không phải cập nhật danh sách

⚠ Và WAF có nhiều cách chặn bot, không chỉ một:

Rate-based rule       → chặn theo TẦN SUẤT
IP set                → chặn danh sách IP cụ thể
Bot Control (managed) → phân biệt bot tốt và bot xấu
CAPTCHA / Challenge   → thử thách thay vì chặn thẳng
String match          → chặn theo User-Agent đáng ngờ
Scope-down statement  → chỉ áp rule cho một phần đường dẫn

⚠ Và vì sao WAF gắn được vào ALB — điều kiện tiên quyết:

WAF gắn được vào:
        CloudFront, ALB, API Gateway, AppSync,
        Cognito User Pool, App Runner
        ↓
    Đề nói ứng dụng chạy sau ALB
        ↓
    → gắn web ACL vào ALB là xong

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

• C (AWS Shield Standard) — đây là phương án gần nhất vì Shield cũng là dịch vụ bảo vệ. Nhưng Shield Standard chống DDoS ở tầng 3/4 (SYN flood, UDP reflection) — nó không đọc HTTP và không phân biệt được một bot quét dữ liệu với người dùng thật.

• A (Amazon Inspector) — quét lỗ hổng phần mềm trên EC2, container và Lambda. Nó không chặn lưu lượng nào.

• D (AWS CloudTrail) — ghi lại lời gọi API quản trị, không ghi lưu lượng HTTP của người dùng và không chặn được gì.

Ghi nhớ

⚠ Các dịch vụ bảo vệ theo tầng — bảng phải thuộc: | Dịch vụ | Tầng | Việc | |---|---|---| | Shield Standard | 3/4 | chống DDoS cơ bản, MIỄN PHÍ, tự động | | Shield Advanced | 3/4/7 | có phí — SRT hỗ trợ 24/7, hoàn tiền chi phí | | AWS WAF | 7 (HTTP) | chặn request độc hại, bot, rate limit | | Security Group / NACL | 3/4 | lọc theo IP và cổng | | Network Firewall | 3–7 | tường lửa có trạng thái cho cả VPC |

Từ khoá nhận diện:

"bot quét dữ liệu, nhiều request từ một IP" → WAF rate-based rule "SQL injection, XSS" → WAF managed rule group "chống DDoS tầng mạng" → Shield "hỗ trợ 24/7 khi bị DDoS + hoàn tiền" → Shield Advanced "chặn một IP ở tầng mạng" → NACL "quản lý WAF trên nhiều tài khoản" → Firewall Manager

Ba việc kiểm chứng: | Việc | Cách | |---|---| | WAF có chặn gì không | WAF sampled requests và chỉ số BlockedRequests | | 404 có giảm không | chỉ số HTTPCode_Target_4XX_Count của ALB | | Có chặn nhầm không | chạy Count trước, đọc log WAF bằng Athena |

Và một lưu ý khi đặt ngưỡng cho rate-based rule: hãy đo tần suất request của người dùng THẬT trước khi chọn con số. Một trang web có nhiều tài nguyên tĩnh có thể khiến một người dùng bình thường gửi hàng trăm request trong vài giây — đặt ngưỡng quá thấp sẽ chặn chính khách hàng của bạn, và triệu chứng sẽ là những báo lỗi rời rạc rất khó tái hiện.

Đáp án

A — Đổi chính sách co giãn sang dựa trên SỐ TIN NHẮN trong hàng đợi Amazon SQS.

Vì sao đúng

Vấn đề nằm ở chỗ chính sách hiện tại đang đo sai thứ: CPU không phản ánh được lượng công việc đang chờ.

⚠ Điểm mấu chốt — CPU là chỉ số HẬU QUẢ, hàng đợi là chỉ số DẪN DẮT:

Tin nhắn dồn trong hàng đợi
        ↓
    Nhưng CPU của máy vẫn ở mức bình thường
        ↓
    Vì sao? Công việc có thể chờ I/O, chờ mạng,
            chờ cơ sở dữ liệu — không tốn CPU
        ↓
    → chính sách theo CPU KHÔNG kích hoạt
    → hàng đợi tiếp tục dài ra
        ↓
Đo THẲNG số tin nhắn đang chờ
        ↓
    → phản ánh đúng lượng công việc tồn đọng
    → co giãn đúng lúc cần

⚠ Chỉ số cần dùng và cách làm cho đúng:

ApproximateNumberOfMessagesVisible
        ↓
    Số tin nhắn ĐANG CHỜ được xử lý
        ↓
    Nhưng ĐỪNG dùng thẳng con số này làm ngưỡng
        ↓
    Vì "1000 tin nhắn" đúng với 5 máy
       nhưng vô nghĩa với 50 máy

⚠ Cách AWS khuyến nghị — BACKLOG PER INSTANCE:

backlog mỗi máy = ApproximateNumberOfMessagesVisible
                  ÷ GroupInServiceInstances
        ↓
    Dựng chỉ số này bằng METRIC MATH
        ↓
    Target Tracking giữ nó ở một giá trị mục tiêu
        ↓
    Tính giá trị mục tiêu:
        mỗi máy xử lý 10 tin/phút
        chấp nhận trễ tối đa 5 phút
        → mục tiêu = 50 tin mỗi máy

Xem thêm câu #11718: cùng chủ đề co giãn theo hàng đợi SQS — ở đó hỏi dimension nào để lấy chỉ số (QueueName, duy nhất).

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

• C (đổi chính sách sang dựa trên mức dùng BỘ NHỚ của EC2) — đây là phương án gần nhất và bộ nhớ đôi khi là chỉ số tốt hơn CPU. Nhưng nó vẫn là chỉ số hậu quả, không phản ánh lượng công việc tồn đọng. (Và nhớ rằng RAM cần CloudWatch agent mới có.)

• B (tăng thời gian giữ tin nhắn để không bị mất) — chữa triệu chứng, không chữa bệnh: tin nhắn sẽ ở lại lâu hơn, nhưng vẫn không được xử lý, và độ trễ tiếp tục tăng. (Thời gian giữ tối đa là 14 ngày.)

• D (dựng ELB để phân phối tải đều hơn giữa các EC2) — hiểu sai kiến trúc: trong mô hình này các instance TỰ KÉO (poll) tin nhắn từ hàng đợi, không ai đẩy request tới chúng. Không có gì để load balancer phân phối cả.

Ghi nhớ

⚠ Chỉ số SQS quan trọng — bảng phải thuộc: | Chỉ số | Ý nghĩa | |---|---| | ApproximateNumberOfMessagesVisible | tin nhắn đang CHỜ — dùng để co giãn | | ApproximateNumberOfMessagesNotVisible | đang được xử lý (trong visibility timeout) | | ApproximateAgeOfOldestMessage | tin nhắn cũ nhất chờ bao lâu — dấu hiệu tụt hậu | | NumberOfMessagesSent / Received / Deleted | thông lượng | | NumberOfEmptyReceives | poll rỗng — bật long polling để giảm |

Từ khoá nhận diện:

"hàng đợi dồn nhưng ASG không co giãn" → đổi sang chỉ số hàng đợi "co giãn theo hàng đợi cho đúng" → backlog per instance (Metric Math) "tin nhắn chờ quá lâu" → ApproximateAgeOfOldestMessage "dimension của SQS" → QueueName, duy nhất "consumer tự kéo tin nhắn" → KHÔNG cần load balancer

⚠ Chỉ số dẫn dắt và chỉ số hậu quả — nguyên lý quan trọng nhất: | Dẫn dắt (nên dùng để co giãn) | Hậu quả (đã muộn) | |---|---| | Độ dài hàng đợi SQS | tin nhắn hết hạn, mất dữ liệu | | RequestCountPerTarget của ALB | CPU cao, độ trễ tăng | | SurgeQueueLength | SpilloverCount | | Số kết nối | người dùng phàn nàn |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hàng đợi có đang tụt hậu không | ApproximateAgeOfOldestMessage tăng dần | | ASG có co giãn không | Activity history của ASG | | Có tin nhắn nào hỏng không | kiểm tra Dead Letter Queue |

Và một chỉ số nên đặt cảnh báo bên cạnh số lượng tin nhắn: ApproximateAgeOfOldestMessage. Số tin nhắn chờ có thể lớn mà vẫn bình thường nếu hệ thống xử lý nhanh; nhưng một tin nhắn đã nằm chờ hai tiếng đồng hồ luôn nghĩa là có gì đó đang hỏng — và với thời gian giữ tối đa 14 ngày, đó cũng là đồng hồ đếm ngược tới lúc dữ liệu biến mất vĩnh viễn.

Đáp án

C, D — hai bước cần thực hiện:

• C — Thêm alternate domain name (CNAME) www.sample.com vào CloudFront distribution và chọn chứng chỉ SSL tuỳ chỉnh.
• D — Đặt Viewer Protocol Policy ở MỌI cache behavior thành chuyển hướng HTTP sang HTTPS.

Vì sao đúng

Hai bước này giải quyết hai vế của cùng một yêu cầu: có chứng chỉ hợp lệ và ép người dùng dùng HTTPS.

⚠ Bước C — không khai alternate domain name thì chứng chỉ vô dụng:

Chứng chỉ ACM đã tạo cho www.sample.com
        ↓
    Nhưng CloudFront chưa biết gì về tên miền đó
        ↓
    → distribution vẫn chỉ phục vụ d111111abcdef8.cloudfront.net
    → truy cập bằng www.sample.com → CloudFront trả 403
        ↓
    Thêm vào "Alternate domain names (CNAMEs)"
    và chọn custom SSL certificate
        ↓
    → CloudFront chấp nhận tên miền đó và trình đúng chứng chỉ

⚠ Bước D — có chứng chỉ chưa đủ, phải ÉP dùng HTTPS:

Viewer Protocol Policy có ba lựa chọn:
        HTTP and HTTPS       → cho phép cả hai — KHÔNG ép
        Redirect HTTP to HTTPS → chuyển hướng 301 sang HTTPS  ← đáp án
        HTTPS Only           → từ chối HTTP thẳng (403)
        ↓
    Đề yêu cầu "bảo đảm lưu lượng được mã hoá"
        ↓
    → Redirect là lựa chọn thân thiện nhất:
      người gõ http:// vẫn tới được, và được chuyển sang https://

⚠ Và phải làm cho MỌI cache behavior:

Một distribution có thể có nhiều cache behavior
      (theo path pattern: /api/*, /static/*, default)
        ↓
    Mỗi behavior có Viewer Protocol Policy RIÊNG
        ↓
    → bỏ sót một cái là còn một đường đi qua HTTP

Xem thêm câu #11738: cùng chủ đề nhưng hỏi điều kiện tiên quyết — phải đăng ký tên miền và có chứng chỉ PUBLIC (và với CloudFront thì chứng chỉ BẮT BUỘC ở us-east-1).

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

• E (đặt Viewer Protocol Policy cho phép CẢ HTTP LẪN HTTPS) — đây là phương án gần nhất và đảo ngược đúng mục đích: nó cho phép người dùng tiếp tục dùng HTTP không mã hoá, trái thẳng yêu cầu của đề.

• A (dựng WAF web ACL gắn vào distribution) — WAF lọc request độc hại (SQL injection, XSS, bot). Nó là biện pháp bảo mật thật, nhưng không liên quan tới mã hoá đường truyền.

• B (dựng CloudFront Origin Shield) — một lớp cache trung gian giúp giảm tải cho origin và tăng tỷ lệ trúng cache. Không liên quan tới TLS.

Ghi nhớ

⚠ Hai chính sách giao thức của CloudFront — bảng phải thuộc: | Chính sách | Điều khiển chặng | |---|---| | Viewer Protocol Policy | người xem ↔ CloudFront | | Origin Protocol Policy | CloudFront ↔ origin | | Quan trọng | hai cái này ĐỘC LẬP — đây là chỗ hay nhầm nhất |

Từ khoá nhận diện:

"ép người dùng dùng HTTPS" → Viewer Protocol Policy = Redirect hoặc HTTPS Only "dùng tên miền riêng cho CloudFront" → alternate domain name + custom SSL certificate "chứng chỉ cho CloudFront" → ACM ở us-east-1, BẮT BUỘC "mã hoá cả chặng tới origin" → Origin Protocol Policy = HTTPS Only "S3 website endpoint + HTTPS" → KHÔNG CÓ — phải dùng REST endpoint + OAC

Ba việc kiểm chứng: | Việc | Cách | |---|---| | HTTP có bị chuyển hướng không | curl -I http://www.sample.com — phải nhận 301 | | Chứng chỉ có đúng không | openssl s_client -connect www.sample.com:443 -servername www.sample.com | | Distribution đã triển khai chưa | trạng thái phải là Deployed |

Và một bước nên làm ngay sau khi ép HTTPS: thêm header Strict-Transport-Security (HSTS) qua Response Headers Policy của CloudFront. Chuyển hướng 301 vẫn để lại một lần kết nối HTTP đầu tiên trước khi trình duyệt được chuyển hướng — HSTS bảo trình duyệt nhớ rằng tên miền này chỉ dùng HTTPS, nên từ lần thứ hai trở đi ngay cả lần gọi đầu tiên cũng đã được mã hoá.

Đáp án

A — Route table của subnet KHÔNG có VPC endpoint làm đích đến.

Vì sao đúng

Gateway endpoint cho S3 hoạt động hoàn toàn bằng cơ chế định tuyến — thiếu tuyến là nó không có tác dụng gì.

⚠ Điểm mấu chốt — gateway endpoint chỉ là một dòng trong route table:

Tạo gateway endpoint cho S3
        ↓
    Nó KHÔNG tự động chuyển hướng lưu lượng nào
        ↓
    Phải thêm một TUYẾN vào route table của subnet:
        Destination : pl-xxxxxxxx (prefix list của S3)
        Target      : vpce-xxxxxxxx
        ↓
    → từ đó, lưu lượng tới S3 mới đi qua endpoint
        ↓
    Thiếu tuyến → lưu lượng vẫn đi theo đường cũ
                  (ra internet qua IGW/NAT, hoặc không đi đâu cả)

⚠ Và đây là bẫy vận hành phổ biến nhất:

Khi tạo endpoint, console CHO CHỌN route table nào áp dụng
        ↓
    Rất dễ chọn thiếu một bảng
        ↓
    → subnet dùng bảng đó KHÔNG hoạt động
    → trong khi subnet khác thì bình thường
        ↓
    → triệu chứng "chỗ được chỗ không" rất khó hiểu

⚠ Kiểm chứng nhanh:

aws ec2 describe-route-tables \
  --filters "Name=association.subnet-id,Values=subnet-xxxx" \
  --query 'RouteTables[].Routes[?GatewayId!=null]'
        ↓
    → phải thấy một dòng với GatewayId bắt đầu bằng "vpce-"

Xem thêm câu #11803 và #11763: cùng chủ đề VPC endpoint cho S3 — ở đó nhấn mạnh gateway endpoint MIỄN PHÍ và là mẹo tiết kiệm chi phí NAT lớn nhất.

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

• B (bucket policy phải cấu hình cho mọi địa chỉ IP riêng) — đây là phương án gần nhất và bucket policy đúng là một lớp cần kiểm tra. Nhưng bạn không khai IP riêng trong bucket policy; điều kiện đúng để giới hạn theo endpoint là aws:SourceVpce. Và đề đã nói endpoint policy đã đúng.

• D (EC2 cần được gán Elastic IP) — ngược hẳn mục đích: cả điểm của VPC endpoint là không cần IP công cộng. Gán Elastic IP là quay lại đường ra internet.

• C (phải bật Storage Class Analytics mới dùng được IP riêng) — bịa hoàn toàn: Storage Class Analytics gợi ý chuyển lớp lưu trữ, không liên quan gì tới mạng.

Ghi nhớ

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

Từ khoá nhận diện:

"tạo gateway endpoint rồi mà không dùng được" → thiếu tuyến trong route table "tạo interface endpoint rồi mà không dùng được" → Security Group hoặc private DNS "chỉ cho phép truy cập bucket qua endpoint" → bucket policy với aws:SourceVpce "chặn đẩy dữ liệu ra bucket lạ" → endpoint policy "máy tại chỗ tới S3 riêng tư" → interface endpoint hoặc DX public VIF

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Endpoint đã tạo chưa | describe-vpc-endpoints | | Route table đã có tuyến chưa | describe-route-tables cho đúng subnet | | Lưu lượng đi đường nào | VPC Flow Logs — đích là IP nội bộ của endpoint |

Và một lỗi rất hay gặp khi VPC có nhiều route table: khi tạo gateway endpoint, hãy chọn TẤT CẢ các route table cần dùng, không chỉ một. Console để bạn tick chọn, và bỏ sót một bảng nghĩa là những subnet gắn với bảng đó vẫn đi ra internet như cũ — bạn tưởng đã bật endpoint cho cả VPC, trong khi thực tế chỉ một phần được hưởng.

Đáp án

C — Sửa cache behavior của CloudFront để CHUYỂN TIẾP header User-Agent tới origin.

Vì sao đúng

Nguyên nhân nằm ở hành vi mặc định của CloudFront: nó KHÔNG chuyển tiếp header nào tới origin.

⚠ Điểm mấu chốt — ứng dụng không nhận được thông tin để nhận diện thiết bị:

Điện thoại gửi request kèm
    User-Agent: Mozilla/5.0 (iPhone; ...)
        ↓
    CloudFront LOẠI BỎ header đó (mặc định)
        ↓
    Ứng dụng ở origin không biết đây là điện thoại
        ↓
    → trả về bản DESKTOP
        ↓
    Và tệ hơn: bản desktop đó được CACHE
    → mọi người sau đó cũng nhận bản desktop

⚠ Vì sao CloudFront mặc định làm vậy:

Càng ít thứ đi vào KHOÁ CACHE
        ↓
    → càng nhiều request dùng chung một bản cache
    → tỷ lệ trúng cache càng cao
        ↓
    → mặc định tối ưu cho HIỆU NĂNG, không cho tính đúng đắn

⚠ Và đây là chỗ phải cẩn thận — User-Agent có cardinality RẤT CAO:

Chuyển tiếp NGUYÊN VĂN User-Agent vào khoá cache
        ↓
    Có hàng CHỤC NGHÌN chuỗi User-Agent khác nhau
    (mỗi phiên bản trình duyệt, mỗi hệ điều hành, mỗi thiết bị)
        ↓
    → mỗi chuỗi tạo một mục cache riêng
    → TỶ LỆ TRÚNG CACHE tụt về gần 0
        ↓
CÁCH TỐT HƠN: dùng header CloudFront-Is-*-Viewer
        ↓
    CloudFront-Is-Mobile-Viewer   : true/false
    CloudFront-Is-Tablet-Viewer   : true/false
    CloudFront-Is-Desktop-Viewer  : true/false
    CloudFront-Is-SmartTV-Viewer  : true/false
        ↓
    → CHỈ CÓ HAI GIÁ TRỊ mỗi header
    → cache vẫn hiệu quả, ứng dụng vẫn nhận diện được thiết bị

Xem thêm câu #11759: cùng nguyên nhân gốc — CloudFront không chuyển tiếp thứ mà ứng dụng cần. Ở đó là cookie (mất sticky session), ở đây là header (nhận nhầm thiết bị).

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

• D (thêm một CUSTOM header User-Agent trong cấu hình ORIGIN) — đây là phương án gần nhất và rất dễ nhầm. Nhưng custom origin header là header CỐ ĐỊNH mà CloudFront TỰ THÊM VÀO mọi request — nó ghi đè giá trị thật của người dùng, nên mọi request sẽ mang cùng một User-Agent. Đó là cơ chế dùng để xác thực CloudFront với origin, không phải để truyền thông tin thiết bị.

• A (bật IPv6 trên distribution và dùng dualstack endpoint) — IPv6 là chuyện địa chỉ mạng, hoàn toàn không liên quan tới việc nhận diện loại thiết bị.

• B (bật IPv6 trên ALB và dùng dualstack cho origin) — cùng lý do.

Ghi nhớ

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

Từ khoá nhận diện:

"mobile nhận bản desktop" → chuyển tiếp CloudFront-Is-Mobile-Viewer "phải đăng nhập lại liên tục" → chuyển tiếp cookie "nội dung khác nhau theo ngôn ngữ" → CloudFront-Viewer-Country hoặc Accept-Language "custom origin header" → CloudFront TỰ THÊM, dùng để xác thực với origin "tỷ lệ trúng cache tụt về 0" → quá nhiều thứ trong khoá cache

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

⚠ Các header đặc biệt CloudFront tự sinh — rất đáng nhớ: | Header | Nội dung | |---|---| | CloudFront-Is-Mobile-Viewer | true/false | | CloudFront-Is-Tablet-Viewer | true/false | | CloudFront-Is-Desktop-Viewer | true/false | | CloudFront-Is-SmartTV-Viewer | true/false | | CloudFront-Viewer-Country | mã quốc gia hai ký tự | | CloudFront-Viewer-Address | IP của người xem | | CloudFront-Forwarded-Proto | http hay https | | Ưu điểm chung | ít giá trị → cache vẫn hiệu quả |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Header có tới origin không | ALB access log, hoặc ghi log header ở ứng dụng | | Tỷ lệ trúng cache | chỉ số CacheHitRate — sau khi sửa phải theo dõi | | Cache hit hay miss | header X-Cache trong phản hồi |

Và một khuyến nghị về hướng đi dài hạn cho đúng vấn đề này: hãy chuyển sang responsive design thay vì phục vụ hai bản HTML khác nhau. Một bản HTML duy nhất với CSS thích ứng cho tỷ lệ trúng cache cao nhất có thể, xoá bỏ hoàn toàn cả lớp vấn đề "nhận nhầm thiết bị", và giảm một nửa khối lượng bảo trì giao diện — trong khi việc chuyển tiếp header chỉ là cách chữa cho kiến trúc hiện tại.

Đáp án

C — Dùng AWS Config, bật quy tắc restricted-common-ports và thêm cổng 80 vào tham số.

Vì sao đúng

Đề nêu hai yêu cầu, và AWS Config đáp ứng cả hai bằng một quy tắc dựng sẵn:

⚠ Điểm mấu chốt — Config đánh giá NGAY khi security group thay đổi:

Ai đó thêm luật mở cổng 80 ra 0.0.0.0/0
        ↓
    Config nhận sự kiện thay đổi cấu hình
        ↓
    Đánh giá lại quy tắc trong VÀI PHÚT
        ↓
    → tài nguyên chuyển sang NON_COMPLIANT
    → hiện ngay trên dashboard
    → EventBridge bắt được → SNS báo cho đội bảo mật

⚠ Cấu hình quy tắc:

{
  "ConfigRuleName": "chan-cong-80",
  "Source": {
    "Owner": "AWS",
    "SourceIdentifier": "RESTRICTED_INCOMING_TRAFFIC"
  },
  "InputParameters": "{\"blockedPort1\": \"80\"}"
}

⚠ Và có thể đi thêm một bước — TỰ SỬA:

Remediation action gắn vào quy tắc
        ↓
    SSM Automation: AWS-DisablePublicAccessForSecurityGroup
        ↓
    → tự gỡ luật vi phạm ngay sau khi phát hiện
        ↓
    Nên chạy chế độ Manual trước để xem nó định sửa gì

Xem thêm câu #11621: cùng quy tắc restricted-common-ports ở một tình huống khác — chặn cổng 846 sau khi đội bảo mật phát hiện tấn công. Khoá đáp án thống nhất.

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

• D (bật Trusted Advisor và tạo CloudWatch alarm kích hoạt khi có cảnh báo đỏ ở check cổng mở) — đây là phương án gần nhất vì Trusted Advisor có check "Security Groups – Unrestricted Access". Nhưng Trusted Advisor làm mới khoảng mỗi 24 giờ, nên không phải "gần thời gian thực". Nó cũng không cho tuỳ chỉnh danh sách cổng như Config.

• A (lên lịch Lambda chạy mỗi giờ để quét và đánh giá mọi security group) — mỗi giờ vẫn không phải gần thời gian thực, và phải tự viết cùng bảo trì mã, tự dựng báo cáo, không có lịch sử cấu hình cho kiểm toán.

• B (dùng Amazon Inspector để đánh giá security group trong các lần quét) — Inspector quét lỗ hổng phần mềm trên EC2, container và Lambda. (Inspector v1 từng có network reachability, nhưng đó không phải báo cáo tuân thủ security group, và v2 tập trung vào CVE.)

Ghi nhớ

⚠ Bốn dịch vụ hay bị nhầm trong bối cảnh tuân thủ — bảng phải thuộc: | Dịch vụ | Trả lời câu hỏi | Tần suất | |---|---|---| | AWS Config | "cấu hình có đúng chuẩn không" | theo thay đổi (gần tức thì) | | Trusted Advisor | "có khuyến nghị gì" | ~24 giờ | | Inspector | "phần mềm có lỗ hổng nào" | liên tục (v2) | | Security Hub | "tổng hợp mọi phát hiện" | theo dòng phát hiện |

Từ khoá nhận diện:

"báo cáo tuân thủ gần thời gian thực" → AWS Config "khuyến nghị chung, cập nhật hằng ngày" → Trusted Advisor "tự sửa khi phát hiện vi phạm" → Config remediation "CHẶN HẲN không cho mở cổng" → SCP — Config chỉ phát hiện SAU "lỗ hổng CVE" → Inspector

⚠ Điểm yếu quan trọng nhất của AWS Config — phải hiểu để thiết kế đúng:

Config là cơ chế PHÁT HIỆN (detective), không phải NGĂN CHẶN
        ↓
    Cổng ĐÃ MỞ RỒI mới bị phát hiện
        ↓
    → có một khoảng thời gian phơi nhiễm
        ↓
Kiến trúc đúng:
    SCP chặn từ đầu
      + Config phát hiện những gì lọt qua
      + Remediation tự sửa

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai đang vi phạm | bảng compliance của quy tắc | | Ai đã mở cổng | CloudTrail sự kiện AuthorizeSecurityGroupIngress | | Trước đây cấu hình ra sao | Config timeline của chính security group đó |

Và một chi tiết đáng lưu ý khi áp dụng chính sách "chặn cổng 80" cho toàn bộ hệ thống: load balancer thường vẫn cần một listener ở cổng 80 để chuyển hướng sang HTTPS. Chặn cứng cổng 80 ở mọi security group sẽ khiến người dùng gõ http:// nhận được lỗi kết nối thay vì được chuyển hướng — hãy loại trừ security group của load balancer, hoặc dùng listener redirect kèm HSTS để vẫn giữ được trải nghiệm mà không có lưu lượng nào thật sự đi qua HTTP.

Đáp án

B — Tài khoản đã chạm HẠN MỨC MẶC ĐỊNH về số VPC được phép.

Vì sao đúng

Đề mô tả một mô hình dùng tài nguyên rất đặc thù, và nó dẫn thẳng tới việc cạn hạn mức.

⚠ Điểm mấu chốt — mỗi khách hàng một VPC, tất cả trong MỘT tài khoản và MỘT Region:

Template tạo một VPC MỚI cho MỖI ứng dụng
        ↓
    Nhiều khách hàng → nhiều ứng dụng → nhiều VPC
        ↓
    Tất cả nằm trong CÙNG một tài khoản và CÙNG một Region
        ↓
    Hạn mức mặc định: 5 VPC mỗi Region mỗi tài khoản
        ↓
    → khách hàng thứ sáu → CloudFormation THẤT BẠI

⚠ Và triệu chứng rất đặc trưng:

Stack chuyển sang CREATE_FAILED rồi ROLLBACK
        ↓
    Tab Events của stack nêu rõ:
        "The maximum number of VPCs has been reached"
        ↓
    → thông báo rất rõ ràng, chỉ cần biết chỗ để đọc

⚠ Hai cách xử lý — một ngắn hạn, một dài hạn:

NGẮN HẠN
        ↓
    Service Quotas → xin tăng hạn mức "VPCs per Region"
        ↓
    → thường được duyệt, nhưng có thể mất vài ngày

DÀI HẠN (kiến trúc tốt hơn)
        ↓
    Mỗi khách hàng một TÀI KHOẢN AWS RIÊNG
        ↓
    → hạn mức tách bạch, không ai ảnh hưởng ai
    → cô lập bảo mật thật sự
    → chi phí tách bạch tự nhiên
    → dùng Control Tower để tự động hoá việc tạo tài khoản

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

• C (AMI được dùng không có ở Region đó) — đây là phương án gần nhất vì AMI theo Region là một ràng buộc thật. Nhưng đề nói rõ cùng một tài khoản và cùng một Region cho mọi khách hàng — nếu AMI không có thì ứng dụng đầu tiên đã thất bại, không phải tới khách hàng mới.

• A (template CloudFormation cần cập nhật lên phiên bản mới nhất) — không có khái niệm "phiên bản template" nào cần cập nhật. AWSTemplateFormatVersion đã cố định ở 2010-09-09 từ đầu và không đổi.

• D (Region đang bảo trì theo lịch nên tạm thời không dùng được) — AWS không có "bảo trì theo lịch" làm cả Region ngừng hoạt động. Và nếu có sự cố Region thì mọi thao tác đều hỏng, không riêng việc tạo VPC.

Ghi nhớ

⚠ Các hạn mức mặc định hay chạm phải — bảng đáng thuộc: | Tài nguyên | Hạn mức mặc định | |---|---| | VPC mỗi Region | 5 | | Elastic IP mỗi Region | 5 | | Internet Gateway mỗi Region | 5 (bằng số VPC) | | Subnet mỗi VPC | 200 | | Security group mỗi VPC | 2.500 | | Luật mỗi security group | 60 vào, 60 ra | | Route mỗi route table | 50 | | vCPU theo họ instance | tính bằng vCPU, không phải số instance | | Xin tăng ở đâu | Service Quotas — một số tự động duyệt |

Từ khoá nhận diện:

"tạo VPC thất bại, đã có vài VPC rồi" → hạn mức 5 VPC mỗi Region "ASG không khởi chạy được máy" → hạn mức vCPU "sắp chạm hạn mức" → Trusted Advisor hoặc Service Quotas "stack thất bại" → đọc tab Events, dòng CREATE_FAILED đầu tiên "mỗi khách hàng một môi trường riêng" → tài khoản riêng, không phải VPC riêng

⚠ Vì sao "mỗi khách hàng một tài khoản" tốt hơn "mỗi khách hàng một VPC":

Cùng một tài khoản, nhiều VPC
        ↓
    → hạn mức DÙNG CHUNG: một khách dùng nhiều là cả nhóm bị ảnh hưởng
    → cô lập chỉ ở tầng MẠNG, không ở tầng quyền
    → chi phí khó tách bạch, phải dựa hoàn toàn vào tag
    → một sự cố IAM có thể ảnh hưởng mọi khách hàng

Mỗi khách hàng một tài khoản
        ↓
    → hạn mức TÁCH BẠCH
    → cô lập MẠNH NHẤT trên AWS
    → chi phí tách bạch tự nhiên theo tài khoản
    → SCP áp trần quyền cho từng nhóm
        ↓
    Công cụ: AWS Control Tower + Account Factory

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đang dùng bao nhiêu VPC | describe-vpcs --query 'length(Vpcs)' | | Hạn mức hiện tại | Service Quotas console, tìm "VPCs per Region" | | Vì sao stack thất bại | tab Events, dòng CREATE_FAILED đầu tiên |

Và một lời khuyên về kiến trúc rút ra từ chính sự cố này: mô hình "nhiều khách hàng trong một tài khoản" sẽ liên tục va vào hạn mức khi số khách hàng tăng lên, và VPC chỉ là hạn mức đầu tiên bạn chạm phải — sau đó sẽ tới Elastic IP, Internet Gateway, rồi vCPU. Đây là lúc nên chuyển sang mô hình một khách hàng một tài khoản với Control Tower, thay vì lần lượt xin tăng từng hạn mức một.

Đáp án

C — Thêm một Aurora Replica vào DB cluster.

Vì sao đúng

Đề nêu ba ràng buộc, và thêm replica là cách duy nhất thoả cả ba:

⚠ Điểm mấu chốt — Aurora dùng tầng lưu trữ CHIA SẺ, nên thêm replica rất nhanh và rất nhẹ:

Aurora không sao chép dữ liệu sang từng replica
        ↓
    Mọi node dùng CHUNG một tầng lưu trữ phân tán
      (6 bản sao trên 3 AZ)
        ↓
    Thêm replica = thêm một node TÍNH TOÁN đọc từ tầng đó
        ↓
    → không cần copy dữ liệu
    → thêm xong trong vài phút
    → KHÔNG gián đoạn cluster đang chạy
        ↓
    Replica mới tự động vào READER ENDPOINT
    → ứng dụng không phải đổi gì

⚠ Và vì sao nó giải quyết đúng triệu chứng RAM cao:

Cluster hiện có: 1 writer + 1 reader
        ↓
    Lưu lượng đọc dồn hết vào MỘT reader
        ↓
    → buffer pool của nó phải chứa quá nhiều dữ liệu nóng
    → RAM cạn, phải đọc từ tầng lưu trữ nhiều hơn
    → độ trễ truy vấn tăng
        ↓
Thêm reader thứ hai
        ↓
    → tải đọc chia đôi qua reader endpoint
    → mỗi node giữ được phần dữ liệu nóng của mình trong RAM

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

• D (chụp snapshot rồi dựng cluster MỚI với instance nhiều bộ nhớ hơn) — đây là phương án gần nhất và cũng giải quyết được vấn đề RAM. Nhưng nó gián đoạn nhiều: phải chuyển ứng dụng sang cluster mới, và dữ liệu ghi sau thời điểm snapshot sẽ mất nếu không dùng thêm cơ chế đồng bộ. Trái cả hai ràng buộc còn lại. (Nếu thật sự cần node lớn hơn, cách đúng là đổi loại instance của replica rồi failover — vẫn không mất dữ liệu.)

• B (tăng gấp đôi dung lượng đĩa của cluster) — Aurora TỰ MỞ RỘNG lưu trữ tới 128 TB; bạn không cấp phát dung lượng thủ công. Và vấn đề của đề là RAM, không phải dung lượng đĩa.

• A (chuyển thành multi-master cluster) — Aurora multi-master giải quyết bài toán mở rộng khả năng GHI, còn đề mô tả tải ĐỌC. Nó cũng phức tạp hơn nhiều và đòi dựng lại cluster — gián đoạn lớn.

Ghi nhớ

⚠ Kiến trúc Aurora — bảng phải thuộc: | Đặc điểm | Nội dung | |---|---| | Tầng lưu trữ chia sẻ | 6 bản sao trên 3 AZ, tự mở rộng tới 128 TB | | Replica | tối đa 15, độ trễ mili giây | | Failover | thường dưới 30 giây | | Thêm/bớt replica | không gián đoạn, vài phút | | Endpoint | cluster (writer), reader, custom, instance |

Từ khoá nhận diện:

"tải ĐỌC cao, cần cải thiện, không gián đoạn" → thêm Aurora Replica "tải GHI cao" → instance writer lớn hơn, hoặc phân mảnh ở tầng ứng dụng "tải không đoán được, muốn tự co giãn" → Aurora Serverless v2 "chịu được mất cả một Region" → Aurora Global Database "số replica thay đổi liên tục" → reader endpoint (đừng ghi cứng instance endpoint)

⚠ Bốn cách mở rộng Aurora — chọn theo đúng triệu chứng: | Triệu chứng | Cách | |---|---| | Tải ĐỌC cao | thêm replica — không gián đoạn | | Tải GHI cao | đổi loại instance của writer (cần failover ngắn) | | Tải biến động khó đoán | Aurora Serverless v2 — co giãn theo ACU | | Cần đọc ở Region khác | Aurora Global Database |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tải đọc phân bố ra sao | DatabaseConnections theo từng instance | | Bộ nhớ còn bao nhiêu | FreeableMemory | | Truy vấn nào nặng nhất | Performance Insights — thấy ngay câu lệnh tốn tài nguyên |

Và một việc nên làm trước khi thêm phần cứng: mở Performance Insights để xem truy vấn nào đang chiếm tài nguyên. Rất thường xuyên, một đợt tăng RAM và độ trễ đột ngột không đến từ việc thiếu máy mà từ một truy vấn thiếu chỉ mục được gọi nhiều hơn trong giờ cao điểm — và thêm replica sẽ che giấu triệu chứng đó thay vì chữa nó, để rồi vấn đề quay lại khi lưu lượng tăng thêm một bậc nữa.