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

Đáp án

B — TĂNG thời gian chờ (command timeout) của lệnh.

Vì sao đúng

Thông báo đã nói thẳng nguyên nhân: "but with command timeouts" — các lệnh trong tệp cấu hình chạy quá lâu so với hạn cho phép.

⚠ Điểm mấu chốt — Beanstalk có một hạn thời gian cho mỗi lệnh:

Tệp .ebextensions chạy commands / container_commands
        ↓
    Mỗi lệnh có một CHU KỲ CHỜ tối đa
        ↓
    Mặc định: 600 giây (10 phút)
        ↓
    Lệnh chạy lâu hơn — ví dụ:
      cài nhiều gói, biên dịch, tải dữ liệu lớn
        ↓
    → Beanstalk coi là timeout
    → môi trường vẫn tạo xong, nhưng
      "complete, but with command timeouts"
        ↓
    → tăng hạn: namespace
      aws:elasticbeanstalk:command → Timeout

⚠ Cách khai trong .ebextensions:

option_settings:
  aws:elasticbeanstalk:command:
    Timeout: 1800

    Timeout tính bằng GIÂY
    Tối đa 3600 (1 giờ)
        ↓
    Hoặc đặt trên console:
      Configuration → Rolling updates and deployments
      → Command timeout

⚠ Nhưng tăng timeout chỉ là chữa TRIỆU CHỨNG:

Nguyên nhân gốc: làm quá nhiều việc lúc TRIỂN KHAI
        ↓
CÁCH TỐT HƠN — chuyển việc sang lúc DỰNG ẢNH:
        ↓
    1. GOLDEN AMI hoặc CUSTOM PLATFORM
       → gói đã cài sẵn, không cài lúc triển khai
    2. Đóng gói phụ thuộc vào chính artifact
       → không tải từ internet lúc chạy
    3. Prebake bằng Docker image
       → Beanstalk chạy container đã dựng sẵn
        ↓
    → triển khai nhanh hơn nhiều
    → và không còn phụ thuộc vào mạng lúc triển khai

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

• C (dùng loại instance lớn hơn với nhiều CPU hơn) — đây là phương án gần nhất và có thể rút ngắn thời gian thật nếu lệnh bị nghẽn CPU. Nhưng nếu lệnh chậm vì tải gói từ internet hoặc chờ I/O thì máy mạnh hơn không giúp gì, mà vẫn tốn tiền suốt vòng đời môi trường.

• A (dùng preset high availability) — chỉ đổi kiến trúc môi trường (thêm load balancer, Auto Scaling). Không liên quan tới hạn thời gian của lệnh.

• D (cấu hình worker environment) — worker environment dùng để xử lý công việc nền qua SQS, hoàn toàn khác bài toán lệnh triển khai chạy quá lâu.

Ghi nhớ

⚠ Các tuỳ chọn triển khai của Beanstalk — bảng phải thuộc: | Kiểu | Gián đoạn | Chi phí thêm | Rollback | |---|---|---|---| | All at once | CÓ — toàn bộ cùng lúc | không | phải triển khai lại | | Rolling | giảm năng lực tạm thời | không | triển khai lại | | Rolling with additional batch | không giảm năng lực | có (máy tạm) | triển khai lại | | Immutable | không | có (ASG tạm) | nhanh — bỏ ASG mới | | Blue/Green (swap URL) | không | có (môi trường thứ hai) | nhanh nhất — swap lại |

Từ khoá nhận diện:

"command timeout" → tăng aws:elasticbeanstalk:command Timeout "triển khai không được gián đoạn" → Immutable hoặc Blue/Green "rollback nhanh nhất" → Blue/Green với swap URL "không muốn tốn thêm tiền khi triển khai" → Rolling "cài đặt phức tạp mỗi lần triển khai" → golden AMI / custom platform / Docker

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lệnh nào chạy lâu | /var/log/eb-engine.log — có mốc thời gian từng bước | | Timeout hiện tại là bao nhiêu | describe-configuration-settings, namespace aws:elasticbeanstalk:command | | Triển khai mất bao lâu | tab Events của môi trường |

Và một cách nhìn đáng nhớ về loại lỗi này: thời gian triển khai dài là một chi phí bạn trả ở MỌI lần phát hành. Tăng timeout khiến thông báo lỗi biến mất, nhưng mỗi lần đưa mã lên production vẫn mất chừng ấy phút, và những phút đó nhân với số lần phát hành trong một năm thường lớn hơn nhiều so với công sức bỏ ra để dựng sẵn một golden AMI.

Đáp án

C — Dùng CHỈ SỐ CLOUDWATCH để xem mức sử dụng tài nguyên của từng thành phần.

Vì sao đúng

Nghi ngờ là CPU cao ở một thành phần nào đó, và CloudWatch là nơi có sẵn chỉ số CPU của mọi dịch vụ.

⚠ Điểm mấu chốt — so chỉ số của từng tầng để khoanh vùng:

Tầng WEB (EC2)
        ↓
    CPUUtilization của instance hoặc của ASG
    NetworkIn/Out
        ↓
Tầng CSDL (RDS)
        ↓
    CPUUtilization, FreeableMemory,
    ReadLatency, DatabaseConnections
        ↓
Tầng cân bằng tải (ALB, nếu có)
        ↓
    TargetResponseTime, RequestCount,
    HTTPCode_Target_5XX
        ↓
    → thành phần nào có chỉ số vọt lên
      đúng vào khung giờ chậm
      → đó là điểm nghẽn

⚠ Kỹ thuật rất hiệu quả — vẽ chồng lên một dashboard:

Một biểu đồ, nhiều đường:
    CPU của EC2
    CPU của RDS
    TargetResponseTime của ALB
        ↓
    Cùng một trục thời gian
        ↓
    → nhìn thấy ngay đường nào vọt lên TRƯỚC
    → cái vọt lên trước thường là nguyên nhân,
      cái vọt sau là hậu quả

⚠ Sau khi biết TẦNG nào, mới đi tìm NGUYÊN NHÂN cụ thể:

CPU của RDS cao
        ↓
    → Performance Insights: truy vấn nào tốn nhất
    → slow query log

CPU của EC2 cao
        ↓
    → CloudWatch agent với procstat: tiến trình nào
    → X-Ray: hàm nào trong mã chậm

Cả hai bình thường mà vẫn chậm
        ↓
    → mạng, hoặc phụ thuộc bên ngoài
    → X-Ray sẽ chỉ ra

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

• A (dùng CloudWatch Logs và Athena để tìm dữ liệu sử dụng) — đây là phương án gần nhất vì cũng dùng CloudWatch, nhưng dữ liệu sử dụng tài nguyên là CHỈ SỐ, không phải log. Athena thì dùng để truy vấn dữ liệu trên S3, không phải để đọc chỉ số.

• B (dùng Amazon Inspector để xem chi tiết mức dùng tài nguyên) — Inspector quét LỖ HỔNG bảo mật, hoàn toàn không báo cáo hiệu năng.

• D (dùng CloudTrail để xem chỉ số sử dụng API của từng thành phần) — CloudTrail ghi lời gọi API tới AWS, không ghi mức dùng CPU hay bộ nhớ.

Ghi nhớ

⚠ Chỉ số cần xem theo từng tầng — bảng đáng thuộc: | Tầng | Chỉ số | |---|---| | EC2 / ASG | CPUUtilization, NetworkIn/Out, StatusCheckFailed, GroupInServiceInstances | | EC2 (cần agent) | mem_used_percent, disk_used_percent, procstat | | ALB | TargetResponseTime, RequestCount, HTTPCode_Target_5XX, HealthyHostCount | | RDS | CPUUtilization, FreeableMemory, ReadLatency, DatabaseConnections, ReadIOPS | | ElastiCache | CacheHitRate, Evictions, EngineCPUUtilization | | CloudFront | CacheHitRate, OriginLatency, 5xxErrorRate |

Từ khoá nhận diện:

"thành phần nào là điểm nghẽn" → so CHỈ SỐ CloudWatch của từng tầng "truy vấn nào tốn tài nguyên" → Performance Insights "hàm nào trong mã chậm" → X-Ray "bộ nhớ, dung lượng đĩa" → CloudWatch agent "người dùng thật cảm nhận thế nào" → CloudWatch RUM, Synthetics

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tầng nào nghẽn | dashboard chồng chỉ số các tầng, cùng khung giờ | | Truy vấn nào nặng | Performance Insights → Top SQL | | Có phải do một lần phát hành | đối chiếu mốc thời gian với CloudTrail |

Và một điều rất đáng nhớ khi đọc biểu đồ nhiều đường: cái vọt lên TRƯỚC thường là nguyên nhân, cái vọt lên SAU là hậu quả. CPU của CSDL tăng rồi mới tới thời gian phản hồi của ALB là một câu chuyện; thời gian phản hồi tăng trước rồi CPU của web tăng theo lại là một câu chuyện hoàn toàn khác — và trục thời gian chung là thứ duy nhất phân biệt được hai trường hợp đó.

Đáp án

A — Bảo đảm tính SẴN SÀNG CAO của NAT Gateway.

Vì sao đúng

NAT Gateway là một dịch vụ được AWS quản lý hoàn toàn, nên mọi thứ về hạ tầng bên dưới nó thuộc phần "bảo mật CỦA đám mây".

⚠ Điểm mấu chốt — AWS lo gì với NAT Gateway:

AWS chịu trách nhiệm:
        ↓
    - Phần cứng và phần mềm chạy NAT
    - TỰ CHỊU LỖI TRONG MỘT AZ
      (dự phòng sẵn bên trong, bạn không thấy)
    - Tự mở rộng băng thông tới 100 Gbps
    - Vá lỗi, bảo trì — trong suốt
        ↓
BẠN chịu trách nhiệm:
        ↓
    - Đặt NAT ở PUBLIC subnet
    - Gắn Elastic IP
    - Cấu hình ROUTE TABLE trỏ về nó
    - Quyết định đặt MẤY CÁI (một mỗi AZ)

⚠ Và đây là chỗ ranh giới rất tinh tế:

AWS bảo đảm NAT Gateway sẵn sàng TRONG MỘT AZ
        ↓
    Nhưng nếu CẢ AZ đó hỏng
        ↓
    → NAT ở đó cũng không dùng được
        ↓
    Việc thiết kế "một NAT mỗi AZ"
      là TRÁCH NHIỆM CỦA BẠN
        ↓
    → AWS lo độ sẵn sàng của TỪNG NAT
    → bạn lo kiến trúc chịu được mất một AZ

Xem thêm câu #11837 (lô 128): cùng chủ đề mô hình trách nhiệm chia sẻ, ở đó là với EC2 — AWS vá hypervisor, bạn vá hệ điều hành khách.

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

• B (cấu hình mã hoá cho dữ liệu trong RDS) — đây là phương án gần nhất vì RDS là dịch vụ được quản lý, nhưng quyết định BẬT mã hoá và chọn khoá là của KHÁCH HÀNG. AWS cung cấp cơ chế; bạn quyết định dùng hay không.

• C (quản lý sức khoẻ của hệ điều hành Linux) — hoàn toàn là việc của khách hàng với EC2: vá lỗi, theo dõi, khắc phục.

• D (cấu hình route table với ID của NAT gateway) — việc của khách hàng: bạn quyết định subnet nào định tuyến qua NAT nào.

Ghi nhớ

⚠ Ranh giới trách nhiệm trong đúng kiến trúc này — bảng phải thuộc: | Thành phần | AWS lo | Khách hàng lo | |---|---|---| | NAT Gateway | sẵn sàng, mở rộng, vá lỗi | đặt ở đâu, route table, mấy cái | | EC2 | hypervisor, phần cứng | hệ điều hành, ứng dụng, vá lỗi, SG | | RDS | vá hệ điều hành và động cơ, hạ tầng | BẬT mã hoá, lược đồ, người dùng, cửa sổ bảo trì | | VPC | hạ tầng mạng vật lý | CIDR, subnet, route table, SG, NACL |

Từ khoá nhận diện:

"AWS chịu trách nhiệm gì" → những thứ bạn KHÔNG CHẠM TỚI ĐƯỢC "khách hàng chịu trách nhiệm gì" → những thứ bạn CẤU HÌNH được "vá hệ điều hành EC2" → khách hàng "vá hệ điều hành RDS" → AWS "tính sẵn sàng của ỨNG DỤNG" → khách hàng, luôn luôn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiến trúc có chịu được mất một AZ không | thử xoá tuyến tới NAT của một AZ ở môi trường thử | | Máy của tôi đã vá chưa | Patch Manager → Compliance | | Phần AWS lo được chứng nhận thế nào | AWS Artifact |

Và một hệ quả rất cụ thể của mô hình này với chính NAT Gateway: AWS bảo đảm mỗi NAT Gateway hoạt động ổn định, nhưng không bảo đảm ứng dụng của bạn còn ra được internet khi một AZ gặp sự cố. Đó là lý do "một NAT mỗi AZ" là khuyến nghị mặc định — và cũng là ví dụ rõ nhất cho việc độ tin cậy của từng thành phần không tự động trở thành độ tin cậy của hệ thống.

Đáp án

B — Cấu hình UNIFIED CLOUDWATCH AGENT để đẩy log lên CloudWatch Logs.

Vì sao đúng

Vấn đề là log biến mất cùng với máy, và cách chữa gốc rễ là đưa log RA KHỎI máy ngay khi nó được ghi.

⚠ Điểm mấu chốt — đẩy liên tục, không chờ tới lúc huỷ:

Agent đọc tệp log và đẩy lên
LIÊN TỤC, gần như thời gian thực
        ↓
    Máy bị huỷ vì scale-in
        ↓
    → log ĐÃ NẰM Ở CloudWatch Logs từ trước
    → không mất gì
        ↓
    Và log stream đặt tên theo {instance_id}
    → vẫn tra được log của đúng máy đã biến mất

⚠ Vì sao cách này tốt hơn "cứu log lúc huỷ":

Cứu log lúc huỷ (lifecycle hook, script)
        ↓
    - Phải kịp trong khoảng thời gian chờ
    - Nếu máy hỏng đột ngột → mất sạch
    - Nếu Spot bị thu hồi → chỉ có 2 phút
    - Thêm một cơ chế phải bảo trì
        ↓
Đẩy liên tục
        ↓
    - Không có khoảng thời gian nào để mất
    - Máy chết bất ngờ cũng chỉ mất vài giây cuối
    - Là thực hành chuẩn cho hạ tầng
      "máy là thứ vứt đi được"

⚠ Cấu hình agent cho ASG:

"logs": {
  "logs_collected": {
    "files": {
      "collect_list": [{
        "file_path": "/var/log/ung-dung/*.log",
        "log_group_name": "/ung-dung/production",
        "log_stream_name": "{instance_id}",
        "timezone": "UTC"
      }]
    }
  }
}

{instance_id} → mỗi máy một stream riêng
        ↓
    → truy vết được về đúng máy
    → và Logs Insights truy vấn được
      xuyên suốt mọi stream

Xem thêm câu #11895 (cùng lô): cùng công cụ — unified CloudWatch agent để đẩy log. Và #11883 (cùng lô): lifecycle hook, dùng khi cần vào tận máy để phân tích trước lúc huỷ, chứ không phải để cứu log.

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

• C (dùng CloudWatch Events chuyển log sang S3 khi trạng thái EC2 chuyển sang terminated) — đây là phương án gần nhất về ý tưởng, nhưng quá muộn: khi sự kiện terminated được phát ra thì máy đã bị huỷ và đĩa đã biến mất. Không còn gì để chuyển.

• D (script chạy cron mỗi giờ để thu thập log) — mất tối đa một giờ log cuối cùng, và bản thân script cũng biến mất theo máy. Lại thêm một thứ phải bảo trì.

• A (bật VPC Flow Logs cho subnet và đẩy sang S3) — flow log ghi lưu lượng MẠNG, hoàn toàn không phải log của ứng dụng.

Ghi nhớ

⚠ Nguyên tắc "máy là thứ vứt đi được" — bảng đáng thuộc: | Thứ cần giữ | Đưa ra đâu | |---|---| | Log ứng dụng | CloudWatch Logs (qua agent) | | Chỉ số | CloudWatch Metrics | | Vết truy tìm | X-Ray | | Trạng thái phiên | ElastiCache Redis / DynamoDB | | Tệp người dùng tải lên | S3 / EFS | | Cấu hình | Parameter Store / Secrets Manager | | Kết quả | mất một máy không mất gì cả |

Từ khoá nhận diện:

"giữ log khi máy bị huỷ" → CloudWatch agent đẩy liên tục "phân tích máy TRƯỚC khi bị huỷ" → lifecycle hook "log của một máy đã biến mất" → log stream theo {instance_id} "log rất lớn, cần lưu lâu" → subscription filter → S3, hoặc export "tìm trong log của cả đội máy" → Logs Insights

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Log có lên không | CloudWatch → Log groups → tìm stream theo instance id | | Agent có chạy không | amazon-cloudwatch-agent-ctl -a status | | Log của máy đã huỷ còn không | tìm log stream mang id của máy cũ |

Và một việc nên làm ngay khi tạo log group: đặt hạn lưu trữ. Với một Auto Scaling group co giãn liên tục, số log stream sẽ tăng theo từng máy từng ngày — và mặc định giữ vĩnh viễn nghĩa là bạn đang trả tiền lưu trữ cho log của những máy đã ngừng tồn tại từ nhiều năm trước, mà không ai còn lý do gì để mở ra đọc.

Đáp án

A — Dựng Auto Scaling group gắn với Application Load Balancer, và cấu hình chính sách target tracking dựa trên mức dùng CPU trung bình của nhóm.

Vì sao đúng

Vấn đề là một máy đơn lẻ quá tải vào giờ cao điểm, và cách chữa đúng là mở rộng theo chiều ngang có tự động hoá.

⚠ Điểm mấu chốt — mở rộng NGANG thay vì mở rộng DỌC:

Một EC2, CPU vượt 90% giờ cao điểm
        ↓
    Mở rộng DỌC (máy to hơn)
        ↓
    → phải DỪNG máy để đổi cỡ
    → trả tiền máy to suốt 24 giờ
    → vẫn là ĐIỂM HỎNG ĐƠN LẺ
    → có một trần cứng không vượt qua được

    Mở rộng NGANG (ASG + ALB)
        ↓
    → thêm máy khi tải cao, bớt khi tải thấp
    → KHÔNG gián đoạn
    → chịu lỗi: một máy chết, ASG tự thay
    → trải nhiều AZ

⚠ Vì sao TARGET TRACKING là chính sách nên chọn:

Target tracking
        ↓
    Bạn chỉ khai MỘT con số:
      "giữ CPU trung bình ở 60%"
        ↓
    AWS tự tạo và quản lý alarm
    Tự tính cần thêm hay bớt bao nhiêu máy
        ↓
    → đơn giản nhất, ít phải chỉnh nhất
    → đúng nghĩa "hiệu quả vận hành nhất"
        ↓
So với step scaling:
    phải tự định nghĩa từng bậc ngưỡng
    → nhiều tham số hơn, dễ sai hơn

⚠ Cấu hình đầy đủ cho kiến trúc này:

1. Tạo AMI hoặc launch template từ máy hiện tại
2. ALB ở public subnet, nhiều AZ
3. ASG: Min 2, Desired 2, Max theo dự kiến
4. Health check type = ELB (không chỉ EC2)
5. Target tracking: ASGAverageCPUUtilization = 60
6. Trạng thái phiên ĐƯA RA NGOÀI (Redis/DynamoDB)
7. Nếu biết trước giờ cao điểm
   → thêm SCHEDULED SCALING làm lớp đệm

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

• D (alarm ở 80% CPU gọi Lambda để mở rộng DỌC) — đây là phương án gần nhất và có tự động hoá thật, nhưng đổi cỡ instance đòi DỪNG máy — tức là gián đoạn dịch vụ đúng vào giờ cao điểm. Lại còn phải viết và bảo trì một hàm Lambda cho việc mà ASG làm sẵn.

• C (bật CloudWatch Logs và đặt alarm cảnh báo khi CPU vượt 90%) — chỉ THÔNG BÁO, không giải quyết gì. Quản trị viên nhận email trong lúc người dùng vẫn đang chịu chậm.

• B (dựng VPN Site-to-Site để người dùng nối thẳng tới IP riêng của máy) — không liên quan tới CPU. Vấn đề là thiếu năng lực tính toán, không phải đường mạng. Và đây cũng là kiến trúc bất khả thi với người dùng web thông thường.

Ghi nhớ

⚠ Ba kiểu chính sách co giãn động — bảng phải thuộc: | Kiểu | Nội dung | |---|---| | Target tracking | khai MỘT giá trị mục tiêu, AWS lo phần còn lại — NÊN DÙNG MẶC ĐỊNH | | Step scaling | thêm/bớt theo BẬC tuỳ mức vượt ngưỡng | | Simple scaling | kiểu cũ, có cooldown, ít dùng | | Kết hợp | thêm scheduled scaling cho phần tải đoán được |

Từ khoá nhận diện:

"CPU cao giờ cao điểm, hiệu quả vận hành nhất" → ASG + ALB + target tracking "biết trước khung giờ" → thêm scheduled scaling "máy mới lên quá chậm" → warm pool, golden AMI, detailed monitoring "chỉ có một máy" → điểm hỏng đơn lẻ, luôn nên đưa vào ASG "đổi cỡ instance" → cần dừng máy, và trả tiền cả ngày

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chính sách có kích hoạt không | tab Activity của ASG | | Người dùng còn chậm không | TargetResponseTime của ALB | | Có bị co giãn dao động không | đồ thị GroupInServiceInstances — răng cưa liên tục là dấu hiệu xấu |

Và một bước rất hay bị bỏ qua khi chuyển từ một máy đơn lẻ sang Auto Scaling group: đưa trạng thái phiên ra khỏi máy trước. Nếu ứng dụng vẫn giữ phiên trong bộ nhớ, việc thêm máy thứ hai sẽ khiến người dùng bị đăng xuất ngẫu nhiên — và triệu chứng đó xuất hiện đúng vào lúc hệ thống đang mở rộng, tức là đúng lúc đông người dùng nhất.

Đáp án

D — Bật STICKY SESSIONS trên Target Group.

Vì sao đúng

Triệu chứng "phải đăng nhập lại nhiều lần mỗi giờ" là dấu hiệu kinh điển của phiên lưu trong bộ nhớ máy kết hợp với cân bằng tải không dính phiên.

⚠ Điểm mấu chốt — vì sao người dùng bị đăng xuất:

Đăng nhập → phiên được lưu trong RAM của máy A
        ↓
    Request tiếp theo → ALB gửi sang máy B
        ↓
    Máy B không biết phiên đó
        ↓
    → yêu cầu đăng nhập lại
        ↓
    Người dùng bị hỏi lại nhiều lần mỗi giờ
    → đúng triệu chứng đề mô tả

⚠ Sticky session giải quyết bằng cookie:

ALB gắn cookie AWSALB (duration-based)
        ↓
    Mọi request kèm cookie đó
      → gửi về ĐÚNG target cũ
        ↓
    Thời hạn: 1 giây tới 7 NGÀY
        ↓
    Hoặc application-based cookie:
      ứng dụng tự sinh, ALB bọc thêm AWSALBAPP
      → thời hạn theo chính phiên của ứng dụng

⚠ Nhưng đây là giải pháp TẠM, và phải nói rõ:

Nhược điểm:
    - Tải phân bố KHÔNG ĐỀU
    - Máy hỏng → NGƯỜI DÙNG MẤT PHIÊN
    - Auto Scaling thu nhỏ → mất phiên
    - Triển khai phiên bản mới khó êm
        ↓
CÁCH ĐÚNG VỀ LÂU DÀI:
        ↓
    Đưa phiên RA NGOÀI máy
      ElastiCache for Redis  (phổ biến nhất)
      DynamoDB với TTL
      JWT ký sẵn — không lưu phiên ở đâu cả
        ↓
    → mọi máy phục vụ được mọi người dùng
    → co giãn và triển khai tự do

Xem thêm câu #11858 (lô 128): gần như cùng một câu hỏi, cùng đáp án sticky sessions — chỉ khác chữ cái vì bộ đề xáo thứ tự phương án (ở đó là C, ở đây là D). Khoá đáp án nhất quán.

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

• C (thêm target ở nhiều Availability Zone) — đây là phương án gần nhất về mặt "cải thiện kiến trúc", nhưng nó làm vấn đề TỆ HƠN: càng nhiều máy thì request càng dễ rơi vào một máy không giữ phiên của người dùng đó.

• A (cấu hình health check trên ALB) — health check quyết định target nào còn khoẻ để nhận lưu lượng, hoàn toàn không liên quan tới việc giữ phiên.

• B (bật HTTP/2 trên ALB) — HTTP/2 cải thiện hiệu năng truyền tải (ghép nhiều luồng trên một kết nối), không ảnh hưởng tới việc định tuyến request về máy nào.

Ghi nhớ

⚠ Hai loại sticky session của ALB — bảng phải thuộc: | | Duration-based | Application-based | |---|---|---| | Cookie | AWSALB — ALB tự sinh | cookie của ứng dụng, ALB bọc AWSALBAPP | | Thời hạn | 1 giây tới 7 ngày, bạn đặt | theo phiên của ứng dụng | | Cần sửa ứng dụng | không | có | | Linh hoạt | thấp hơn | cao hơn |

Từ khoá nhận diện:

"phải đăng nhập lại nhiều lần" → sticky sessions, hoặc đưa phiên ra ngoài "mất phiên khi máy bị thay" → ElastiCache Redis / DynamoDB "chờ request đang dở xong rồi mới rút máy" → deregistration delay "cần IP tĩnh" → NLB "ALB tự lo cả việc đăng nhập" → authenticate với Cognito hoặc OIDC

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sticky đã bật chưa | describe-target-group-attributes | | Cookie có được gắn không | DevTools của trình duyệt, tìm AWSALB | | Tải có lệch không | chỉ số RequestCount theo từng target |

Và một lời khuyên nên nói rõ với đội phát triển khi bật tính năng này: sticky session làm người dùng hết bị đăng xuất, nhưng không làm ứng dụng hết phụ thuộc vào một máy cụ thể. Mỗi lần Auto Scaling thu nhỏ, mỗi lần một máy hỏng, mỗi lần phát hành phiên bản mới vẫn sẽ đá một nhóm người dùng ra ngoài — và cách duy nhất để hết hẳn là đưa phiên ra khỏi bộ nhớ máy.

Đáp án

A — SysOps Administrator (tức là KHÁCH HÀNG) chịu trách nhiệm sửa.

Vì sao đúng

Chính sách IAM gắn vào hàng đợi SQS là cấu hình do khách hàng tạo ra, nên nó nằm trọn trong phần "bảo mật TRONG đám mây".

⚠ Điểm mấu chốt — IAM luôn là việc của khách hàng:

AWS cung cấp:
        ↓
    Dịch vụ IAM, dịch vụ SQS
    Hạ tầng chạy chúng
    Cơ chế để bạn khai chính sách
        ↓
BẠN quyết định:
        ↓
    - Ai được truy cập hàng đợi
    - Được làm những hành động nào
    - Từ đâu, với điều kiện gì
        ↓
    → chính sách quá rộng là LỖI CẤU HÌNH
    → và cấu hình LUÔN là của khách hàng

⚠ Phép thử rất nhanh:

"Tôi có sửa được thứ này trong console
 hoặc bằng CLI không?"
        ↓
    CÓ  → trách nhiệm của TÔI
    KHÔNG → trách nhiệm của AWS
        ↓
    Chính sách của hàng đợi: sửa được ngay
        ↓
    → hoàn toàn là của tôi

⚠ Cách sửa cho đúng — siết về quyền tối thiểu:

1. Xem chính sách hiện tại
     get-queue-attributes --attribute-names Policy
2. Xác định ai THẬT SỰ cần dùng
     IAM Access Analyzer → last accessed
     CloudTrail → ai đã gọi gì
3. Viết lại chính sách:
     - Principal cụ thể (không dùng "*")
     - Action tối thiểu (SendMessage / ReceiveMessage)
     - Thêm Condition (aws:SourceArn, aws:PrincipalOrgID)
4. Kiểm chứng ở môi trường thử
5. Áp dụng và theo dõi lỗi AccessDenied

Xem thêm câu #11837 và #11906 (lô 128 và cùng lô): cùng chủ đề mô hình trách nhiệm chia sẻ, với EC2 và với NAT Gateway.

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

• B (đội Amazon SQS) — AWS vận hành dịch vụ SQS, nhưng không đọc và không sửa chính sách của khách hàng. Làm vậy sẽ là can thiệp vào cấu hình mà họ không có quyền quyết định.

• C (đội AWS IAM) — cùng lý do: AWS vận hành IAM như một dịch vụ, nội dung chính sách là của bạn.

• D (AWS Premium Support) — Support tư vấn và hỗ trợ, nhưng không tự sửa cấu hình tài nguyên của bạn.

Ghi nhớ

⚠ Ai chịu trách nhiệm gì — bảng phải thuộc: | AWS ("của đám mây") | Khách hàng ("trong đám mây") | |---|---| | Phần cứng, trung tâm dữ liệu | DỮ LIỆU | | Hypervisor, ảo hoá | IAM: user, role, CHÍNH SÁCH | | Hạ tầng mạng vật lý | Cấu hình mạng: SG, NACL, route table | | Vận hành các dịch vụ được quản lý | Mã hoá (quyết định bật và chọn khoá) | | Vá phần mềm của dịch vụ quản lý | Vá hệ điều hành khách trên EC2 | | Độ bền của S3, EBS | Sao lưu và thiết kế chịu lỗi |

Từ khoá nhận diện:

"chính sách quá rộng" → khách hàng sửa, luôn luôn "cấu hình sai" → khách hàng "phần cứng hỏng" → AWS "dịch vụ AWS gặp sự cố" → AWS — theo dõi qua Health Dashboard "ai chịu trách nhiệm về DỮ LIỆU" → khách hàng, không bao giờ khác

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chính sách hiện tại là gì | get-queue-attributes --attribute-names Policy | | Có chia sẻ ra ngoài không | IAM Access Analyzer | | Ai thực sự đang dùng | CloudTrail, nhóm theo userIdentity |

Và một cách tiếp cận giúp việc siết quyền không gây sự cố: quan sát trước khi siết. IAM Access Analyzer sinh được một chính sách tối thiểu từ chính lịch sử CloudTrail của tài nguyên đó — nên thay vì đoán xem ai còn cần quyền gì rồi làm đứt một luồng nào đó, bạn bắt đầu từ dữ liệu thật về những gì đã thực sự được gọi.

Đáp án

A — Sửa instance CSDL thành triển khai MULTI-AZ, thực hiện NGOÀI GIỜ LÀM VIỆC.

Vì sao đúng

Đề đòi hai thứ: giảm thời gian ngừng khi CSDL gặp sự cố, và không ảnh hưởng người dùng trong giờ làm việc. Multi-AZ đáp ứng vế đầu, và việc chọn thời điểm đáp ứng vế sau.

⚠ Điểm mấu chốt — Multi-AZ là cơ chế sẵn sàng cao của RDS:

Bật Multi-AZ
        ↓
    RDS tạo một node DỰ PHÒNG ở AZ khác
        ↓
    Sao chép ĐỒNG BỘ từ node chính sang
        ↓
    Node chính hoặc AZ hỏng
        ↓
    → FAILOVER TỰ ĐỘNG trong 60-120 giây
    → ENDPOINT KHÔNG ĐỔI
    → ứng dụng chỉ cần kết nối lại

⚠ Vì sao phải làm NGOÀI giờ làm việc:

Bật Multi-AZ trên instance đang chạy
        ↓
    RDS phải:
      - chụp snapshot
      - dựng node dự phòng ở AZ khác
      - đồng bộ dữ liệu
        ↓
    → tăng tải I/O đáng kể
    → có thể làm chậm CSDL trong lúc đó
        ↓
    Với instance lớn: mất hàng giờ
        ↓
    → làm ngoài giờ, hoặc đặt vào
      cửa sổ bảo trì

⚠ Và phải chuẩn bị ứng dụng để failover thật sự nhanh:

Multi-AZ rút ngắn thời gian phía CSDL
        ↓
    Nhưng phía ỨNG DỤNG mới quyết định
    người dùng cảm nhận bao lâu
        ↓
    - TTL DNS ngắn (JVM cache VĨNH VIỄN mặc định)
    - Thử lại có backoff
    - Hoặc dùng RDS PROXY
      → giảm thời gian failover tới 66%

Xem thêm câu #11850 (lô 128): các nguyên nhân gây failover Multi-AZ. Và #11901 (cùng lô): giảm thêm thời gian failover bằng RDS Proxy.

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

• C (tạo RDS DB cluster rồi chuyển toàn bộ dữ liệu sang) — đây là phương án gần nhất và Aurora thật sự failover nhanh hơn, nhưng nó là một cuộc di chuyển dữ liệu lớn: nhiều rủi ro, nhiều công, và gián đoạn khi chuyển đổi — trong khi bật Multi-AZ chỉ là một thao tác sửa cấu hình.

• D (tạo read replica ngoài giờ làm việc) — read replica dùng để mở rộng ĐỌC, sao chép bất đồng bộ, và KHÔNG tự failover: phải thăng cấp bằng tay, mất nhiều phút và có thể mất dữ liệu chưa kịp sao chép.

• B (đổi sang loại instance có nhiều ENI dự phòng) — không có khái niệm này với RDS; bạn không cấu hình ENI của instance RDS, và ENI cũng không giải quyết chuyện AZ hỏng.

Ghi nhớ

⚠ Multi-AZ ↔ Read Replica — bảng phải thuộc: | | Multi-AZ | Read Replica | |---|---|---| | Mục đích | SẴN SÀNG CAO | mở rộng ĐỌC | | Sao chép | ĐỒNG BỘ | bất đồng bộ | | Phục vụ truy vấn | KHÔNG | CÓ (chỉ đọc) | | Failover | TỰ ĐỘNG | phải tự thăng cấp | | Phạm vi | AZ khác, cùng Region | được cả Region khác | | Dùng chung | có, và nên | |

Từ khoá nhận diện:

"giảm thời gian ngừng khi CSDL hỏng" → Multi-AZ "tải ĐỌC cao" → read replica "failover nhanh hơn nữa" → RDS Proxy, hoặc Aurora "chịu được mất cả Region" → cross-Region replica, Aurora Global Database "không ảnh hưởng giờ làm việc" → làm ngoài giờ, hoặc đặt cửa sổ bảo trì

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Multi-AZ đã bật chưa | describe-db-instances --query '...MultiAZ' | | Failover mất bao lâu | chủ động failover ở staging, đo từ log ứng dụng | | Có ảnh hưởng giờ làm việc không | theo dõi ReadLatency và WriteLatency trong lúc bật |

Và một phép đo nên thực hiện ít nhất một lần trước khi coi hệ thống là "sẵn sàng cao": chủ động gây failover ở môi trường staging và đếm xem ứng dụng mất bao lâu để phục hồi. Rất nhiều đội phát hiện ra ở bước này rằng CSDL chỉ mất một phút, còn ứng dụng thì mất mười — và toàn bộ khoảng chênh đó nằm ở những thứ hoàn toàn nằm trong tầm sửa chữa của họ.

Đáp án

D — Tạo bản ghi ALIAS trong Route 53 trỏ tới tên miền của CloudFront distribution.

Vì sao đúng

Đề nhấn mạnh "tiết kiệm nhất", và đó chính là lợi thế đặc trưng của bản ghi Alias.

⚠ Điểm mấu chốt — Alias truy vấn MIỄN PHÍ:

Bản ghi ALIAS trỏ tới tài nguyên AWS
        ↓
    CloudFront, ALB, S3 website endpoint,
    API Gateway, Global Accelerator, ELB…
        ↓
    → Route 53 KHÔNG TÍNH TIỀN truy vấn
        ↓
Bản ghi CNAME
        ↓
    → TÍNH TIỀN theo số truy vấn
        ↓
    Với một cổng thông tin đông người dùng
      → khác biệt là đáng kể

⚠ Và Alias còn có ba ưu thế kỹ thuật:

1. Dùng được ở ZONE APEX
        ↓
    ourbusiness.com (không có "www")
    → CNAME KHÔNG dùng được ở đây
    → Alias thì được

2. Tự cập nhật khi IP đích thay đổi
        ↓
    CloudFront đổi IP → Alias tự theo

3. Route 53 trả thẳng địa chỉ IP
        ↓
    → client không phải phân giải hai lần
    → nhanh hơn CNAME một chặng

⚠ Cấu hình cụ thể cho đề:

Hosted zone: ourbusiness.com
        ↓
    Record name: www
    Type: A
    Alias: YES
    Route traffic to: Alias to CloudFront distribution
      → chọn d1234abcd.cloudfront.net
        ↓
    ĐỒNG THỜI, trong CloudFront distribution:
      thêm www.ourbusiness.com vào ALTERNATE
      DOMAIN NAMES (CNAME)
      và gắn chứng chỉ ACM ở us-east-1
        ↓
    Thiếu bước này → CloudFront trả lỗi

Xem thêm câu #11773 (lô 126) và #11789 (lô 127): cùng chùm Alias — ở đó là Alias cho CloudFront tại zone apex, và Alias cho ALB liên tài khoản. Và #11677 (lô 122): trường hợp phải dùng CNAME vì đích là tên miền của bên thứ ba, không phải tài nguyên AWS.

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

• C (tạo bản ghi A trỏ tới địa chỉ IP công cộng của cổng thông tin) — đây là phương án gần nhất vì cũng là bản ghi A, nhưng nó bỏ qua CloudFront hoàn toàn (trái yêu cầu của đề), và CloudFront không có IP tĩnh để mà trỏ tới.

• A (bản ghi MX) — MX dùng cho định tuyến EMAIL, hoàn toàn không liên quan tới lưu lượng web.

• B (bản ghi PTR) — PTR dùng cho phân giải NGƯỢC (từ IP ra tên miền), thường phục vụ kiểm tra email. Không định tuyến lưu lượng đi vào.

Ghi nhớ

⚠ Alias ↔ CNAME — bảng phải thuộc: | | Alias | CNAME | |---|---|---| | Chi phí truy vấn | MIỄN PHÍ | có phí | | Zone apex | DÙNG ĐƯỢC | KHÔNG | | Đích | chỉ tài nguyên AWS và bản ghi cùng zone | bất kỳ tên miền nào | | Loại bản ghi | A hoặc AAAA | CNAME | | Trả về | địa chỉ IP | một tên miền khác | | TTL | Route 53 quản lý | bạn đặt | | Health check | kết hợp được | có |

Từ khoá nhận diện:

"trỏ tới CloudFront / ALB / S3 website" → ALIAS "trỏ tới tên miền của BÊN THỨ BA" → CNAME (Alias không làm được) "tên miền gốc, không có www" → ALIAS, bắt buộc "tiết kiệm nhất" → ALIAS — truy vấn miễn phí "định tuyến email" → MX

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bản ghi trả về gì | dig www.ourbusiness.com | | CloudFront có nhận tên miền không | kiểm tra Alternate Domain Names của distribution | | Có đi qua CloudFront không | xem header X-Cache và Via trong phản hồi |

Và một lỗi rất hay gặp khi gắn tên miền riêng cho CloudFront: tạo bản ghi Alias xong mà quên thêm tên miền vào Alternate Domain Names. DNS sẽ trỏ đúng, request tới đúng CloudFront, và CloudFront từ chối với một thông báo về việc distribution không khớp tên miền — một lỗi trông giống lỗi DNS nhưng nằm hoàn toàn ở phía CloudFront.

Đáp án

C và E — Định tuyến theo VỊ TRÍ ĐỊA LÝ của Route 53, và GEO RESTRICTION của CloudFront.

Vì sao đúng

Đề cần chặn người dùng ở một số quốc gia, và chỉ hai dịch vụ này có khái niệm vị trí địa lý.

⚠ Điểm mấu chốt — hai tầng chặn khác nhau:

CLOUDFRONT GEO RESTRICTION  ← tầng nội dung
        ↓
    Xác định quốc gia bằng CSDL địa lý IP
        ↓
    Danh sách CHO PHÉP hoặc danh sách CHẶN
        ↓
    Người dùng bị chặn → nhận 403
        ↓
    → chặn NGAY tại edge, gần người dùng
    → nội dung không bao giờ được phục vụ

ROUTE 53 GEOLOCATION  ← tầng DNS
        ↓
    Trả lời DNS khác nhau theo vị trí người truy vấn
        ↓
    Quốc gia bị hạn chế → trỏ tới một trang
      thông báo, hoặc không trả lời
        ↓
    → chặn ngay từ bước phân giải tên miền

⚠ Vì sao nên dùng CẢ HAI:

Route 53 geolocation
        ↓
    Dựa trên vị trí của RESOLVER, không phải
    của người dùng
        ↓
    → người dùng cấu hình DNS công cộng
      (8.8.8.8) có thể bị nhận nhầm vị trí

CloudFront geo restriction
        ↓
    Dựa trên IP THẬT của người dùng
        ↓
    → chính xác hơn, là hàng rào thật
        ↓
    → hai tầng bổ sung cho nhau

⚠ Nhưng phải nói rõ giới hạn:

Cả hai đều dựa trên ĐỊA CHỈ IP
        ↓
    → VPN hoặc proxy VƯỢT QUA ĐƯỢC
        ↓
    Với ràng buộc bản quyền nghiêm ngặt:
      thêm một tầng nữa —
      xác thực người dùng + kiểm tra
      quốc gia trong hồ sơ tài khoản
        ↓
    Hoặc dùng WAF với luật geo match
    kết hợp thêm điều kiện khác

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

• A (AWS Shield geo-restriction) — đây là phương án gần nhất về hình thức vì Shield đúng là một dịch vụ bảo vệ, nhưng Shield chống DDoS, không có tính năng geo-restriction nào. Việc chặn theo quốc gia thuộc về CloudFront hoặc WAF.

• B (giới hạn bằng security group) — security group lọc theo dải CIDR, không có khái niệm quốc gia. Duy trì thủ công danh sách CIDR của cả một quốc gia là bất khả thi.

• D (giới hạn bằng network ACL) — cùng lý do: lọc theo IP/CIDR, không theo vị trí địa lý.

Ghi nhớ

⚠ Các cách chặn theo vị trí — bảng phải thuộc: | Cách | Tầng | Đặc điểm | |---|---|---| | CloudFront geo restriction | edge | allow list hoặc block list theo quốc gia, trả 403 | | WAF geo match rule | tầng 7 | linh hoạt hơn — kết hợp được với điều kiện khác | | Route 53 geolocation | DNS | theo vị trí resolver, ít chính xác hơn | | Security group / NACL | 3/4 | chỉ theo CIDR, không theo quốc gia | | Xác thực người dùng | ứng dụng | chính xác nhất, VPN không vượt được |

Từ khoá nhận diện:

"chặn theo quốc gia" → CloudFront geo restriction hoặc WAF geo match "hướng người dùng theo vùng" → Route 53 geolocation "tuân thủ vị trí dữ liệu" → geolocation + SCP khoá Region "chống DDoS" → Shield "chặn SQL injection, XSS" → WAF

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chặn có hiệu lực không | kiểm tra từ một IP ở quốc gia bị chặn — phải nhận 403 | | Cấu hình hiện tại | get-distribution-config → Restrictions | | Ai bị chặn | CloudFront access log, cột x-edge-result-type |

Và một điều nên nói rõ với bộ phận pháp lý khi triển khai loại ràng buộc này: chặn theo địa lý dựa trên IP là biện pháp hợp lý, không phải biện pháp tuyệt đối. Bất kỳ người dùng nào có VPN đều vượt qua được, nên nếu hợp đồng bản quyền đòi hỏi mức bảo đảm cao hơn, cần thêm một lớp xác thực người dùng thật — và điều đó nên được thống nhất trước khi hệ thống lên production.