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

Đáp án

D — Đưa toàn bộ instance ra sau một NAT GATEWAY và cung cấp địa chỉ IP của gateway đó cho dịch vụ bên thứ ba.

Vì sao đúng

Yêu cầu là mọi kết nối phải đến từ MỘT địa chỉ IP duy nhất, và NAT Gateway làm đúng việc đó.

⚠ Điểm mấu chốt — NAT dịch mọi IP nguồn về một địa chỉ:

Nhiều instance trong private subnet
    10.0.1.15, 10.0.1.22, 10.0.2.31, …
        ↓
    Tất cả đi ra qua NAT Gateway
        ↓
    NAT thay IP nguồn bằng ELASTIC IP của chính nó
        ↓
    Dịch vụ bên thứ ba chỉ thấy MỘT địa chỉ
        ↓
    → khai đúng một IP vào danh sách cho phép
    → thêm hay bớt instance KHÔNG cần báo lại

⚠ Và đây chính là lý do NAT hợp với whitelist:

Không có NAT: mỗi máy một IP công cộng
        ↓
    → mỗi lần Auto Scaling thêm máy là một IP MỚI
    → phải xin bên thứ ba cập nhật danh sách
    → không khả thi

Có NAT: IP ổn định vì gắn Elastic IP
        ↓
    → danh sách cho phép khai MỘT LẦN

⚠ Nhiều AZ thì làm sao:

Thực hành tốt: MỖI AZ MỘT NAT GATEWAY
        ↓
    → tránh phí dữ liệu qua AZ
    → AZ hỏng không kéo theo AZ khác
        ↓
    Nhưng khi đó có NHIỀU Elastic IP
        ↓
    Cách xử lý:
      - khai CẢ HAI/BA IP vào danh sách cho phép, hoặc
      - dùng ELASTIC IP từ một pool IP của chính công ty
        (BYOIP) để dải địa chỉ nằm gọn

Xem thêm câu #11835: cũng về NAT Gateway, nhưng ở góc chi phí — làm sao biết máy nào đang tạo nhiều lưu lượng nhất qua nó.

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

• A (tạo một Elastic Network Interface duy nhất cho các instance và đưa Elastic IP của ENI đó) — đây là phương án gần nhất về ý tưởng "một IP chung", nhưng một ENI chỉ gắn được vào MỘT instance tại một thời điểm. Không có cách nào để nhiều máy dùng chung một ENI.

• B (đưa mọi instance ra sau một internet gateway và đưa IP của gateway) — Internet Gateway KHÔNG CÓ địa chỉ IP. Nó là một thành phần định tuyến ảo, mở rộng theo chiều ngang, và không thực hiện NAT nhiều-thành-một: máy sau IGW ra internet bằng chính IP công cộng của nó.

• C (dồn mọi instance vào một subnet rồi đưa dải CIDR của subnet) — dải CIDR của subnet là địa chỉ riêng (ví dụ 10.0.1.0/24), bên ngoài không nhìn thấy. Bên thứ ba sẽ thấy IP công cộng, không thấy dải này.

Ghi nhớ

⚠ Bốn thành phần ra internet — bảng phải thuộc: | Thành phần | IP nguồn bên ngoài thấy | Có NAT không | |---|---|---| | Internet Gateway | IP công cộng của TỪNG máy | không NAT nhiều-thành-một | | NAT Gateway | Elastic IP của NAT — MỘT địa chỉ | có | | NAT Instance | Elastic IP của instance đó | có, nhưng tự quản lý | | Egress-only IGW | chỉ cho IPv6 | không |

Từ khoá nhận diện:

"bên kia chỉ cho phép một IP" → NAT Gateway + Elastic IP "máy private cần ra internet" → NAT Gateway "IPv6, ra được nhưng không vào được" → Egress-only Internet Gateway "NAT đắt quá" → VPC endpoint cho dịch vụ AWS "IP phải thuộc dải của công ty" → BYOIP

Ba việc kiểm chứng: | Việc | Cách | |---|---| | IP mà bên ngoài nhìn thấy | từ instance chạy curl https://checkip.amazonaws.com | | NAT đang dùng Elastic IP nào | describe-nat-gateways | | Lưu lượng có thật đi qua NAT không | VPC Flow Logs trên ENI của NAT |

Và một đánh đổi cần nói rõ với đội vận hành trước khi chốt thiết kế: yêu cầu "chỉ một IP duy nhất" và yêu cầu "chịu được mất một AZ" kéo về hai hướng ngược nhau. Cách dung hoà thường dùng là giữ một NAT mỗi AZ và thuyết phục bên thứ ba nhận danh sách hai đến ba IP — gần như bên nào cũng chấp nhận, và nó rẻ hơn nhiều so với việc đánh đổi khả năng chịu lỗi của cả hệ thống.

Đáp án

D — Bật FLOW LOG trên elastic network interface của NAT Gateway rồi dùng CloudWatch Logs Insights lọc theo địa chỉ IP nguồn.

Vì sao đúng

Câu hỏi là máy nào tạo ra nhiều lưu lượng nhất, và chỉ có một nguồn dữ liệu trả lời được: bản ghi từng luồng mạng đi qua NAT.

⚠ Điểm mấu chốt — vì sao phải là flow log:

Hoá đơn NAT chỉ cho biết TỔNG số GB
        ↓
    Không cho biết GB đó của máy nào
        ↓
VPC Flow Logs trên ENI của NAT
        ↓
    Mỗi bản ghi có:
      srcaddr, dstaddr, srcport, dstport,
      protocol, packets, BYTES, action
        ↓
    → cộng bytes theo srcaddr
    → ra ngay bảng xếp hạng máy tốn băng thông

⚠ Truy vấn Logs Insights làm sẵn:

stats sum(bytes) as tongByte by srcAddr
| sort tongByte desc
| limit 20

Kết quả:  10.0.1.47   842 GB
          10.0.2.13    91 GB
          10.0.1.22    12 GB
        ↓
    → thủ phạm lộ ra ngay dòng đầu tiên

⚠ Chú ý về hướng của bản ghi — dễ đọc nhầm:

Trên ENI của NAT có HAI chiều bản ghi:
        ↓
  Chiều từ máy nội bộ vào NAT
      srcaddr = IP RIÊNG của instance  ← cái cần
        ↓
  Chiều từ NAT ra internet
      srcaddr = ELASTIC IP của NAT     ← không hữu ích
        ↓
    → lọc theo dải riêng (10.x, 172.16-31.x, 192.168.x)
      để chỉ lấy chiều đầu

Xem thêm câu #11834: cùng về NAT Gateway, ở đó là góc mạng — dùng NAT để có một IP nguồn duy nhất cho danh sách cho phép.

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

• C (xem CloudTrail và tìm các lời gọi API dùng NAT gateway) — đây là phương án gần nhất về hình thức "xem log", nhưng CloudTrail ghi lời gọi API tới mặt phẳng điều khiển của AWS, không ghi lưu lượng dữ liệu. Không có "lời gọi API để dùng NAT" nào tồn tại — máy chỉ gửi gói tin đi.

• A (chạy Cost and Usage Report rồi nhóm theo instance ID) — chi phí NAT quy về chính NAT Gateway, không quy về từng instance gửi lưu lượng. CUR sẽ cho biết NAT tốn bao nhiêu, nhưng không tách được theo máy.

• B (gắn Elastic IP cho từng máy rồi xem chỉ số CloudWatch lọc theo instance ID) — thay đổi cả kiến trúc chỉ để chẩn đoán, và làm vậy là bỏ luôn NAT, khiến mọi máy lộ ra internet. NetworkOut của EC2 cũng đã có sẵn mà không cần Elastic IP nào.

Ghi nhớ

⚠ Ba loại log của AWS — bảng phải thuộc: | Log | Ghi gì | Trả lời câu hỏi | |---|---|---| | VPC Flow Logs | luồng mạng: IP, cổng, BYTES, accept/reject | ai gửi bao nhiêu dữ liệu đi đâu | | CloudTrail | lời gọi API tới AWS | ai đã làm gì trên tài khoản | | CloudWatch Logs | log ứng dụng và hệ điều hành | ứng dụng đã in ra gì | | Bẫy hay gặp | dùng CloudTrail để tìm lưu lượng mạng | không bao giờ đúng |

Từ khoá nhận diện:

"máy nào tốn băng thông" → VPC Flow Logs + Logs Insights "ai đã xoá cái này" → CloudTrail "gói tin bị chặn ở đâu" → Flow Logs, tìm REJECT "phí NAT tăng" → Flow Logs trước, rồi VPC endpoint để giảm "phân tích khối lượng log rất lớn" → đổ ra S3 rồi dùng Athena

Ba việc kiểm chứng: | Việc | Cách | |---|---| | ENI của NAT là cái nào | describe-nat-gateways → NetworkInterfaceId | | Máy nào tốn nhất | Logs Insights: stats sum(bytes) by srcAddr | | Đã giảm được chưa | BytesOutToDestination của NAT trong CloudWatch |

Và một việc nên làm ngay khi đã tìm ra máy tốn nhất: xem dstport và dstaddr của chính luồng đó trước khi kết luận. Rất thường xuyên, một hoá đơn NAT tăng vọt không đến từ lưu lượng nghiệp vụ mà từ một tác vụ sao lưu hoặc đẩy log đang đi vòng ra internet để tới S3 — và trường hợp đó chỉ cần thêm một gateway endpoint miễn phí là chi phí biến mất hoàn toàn.

Đáp án

D — Chạy lại template để tạo một STACK MỚI.

Vì sao đúng

Trạng thái ROLLBACK_COMPLETE là một ngõ cụt trong vòng đời của CloudFormation.

⚠ Điểm mấu chốt — ROLLBACK_COMPLETE chỉ đi được tới một chỗ:

Tạo stack LẦN ĐẦU thất bại
        ↓
    CREATE_FAILED → ROLLBACK_IN_PROGRESS → ROLLBACK_COMPLETE
        ↓
    Ở trạng thái này, stack KHÔNG CÓ tài nguyên nào
    và KHÔNG bao giờ tạo thành công được
        ↓
    Thao tác DUY NHẤT được phép:  DELETE
        ↓
    → xoá stack rồi tạo lại
    → hoặc tạo stack với TÊN KHÁC

⚠ Vì sao update-stack không dùng được:

UpdateStack đòi stack đang ở trạng thái
    CREATE_COMPLETE hoặc UPDATE_COMPLETE
        ↓
    ROLLBACK_COMPLETE không nằm trong danh sách đó
        ↓
    → API trả lỗi thẳng

⚠ Phân biệt với trường hợp DỄ NHẦM — UPDATE_ROLLBACK_FAILED:

Stack ĐÃ TỪNG tạo thành công, rồi cập nhật hỏng
        ↓
    UPDATE_ROLLBACK_FAILED
        ↓
    → chỗ này CÓ cách cứu:
        ContinueUpdateRollback
        (bỏ qua các tài nguyên gây kẹt bằng
         --resources-to-skip)
        ↓
    → khác hẳn ROLLBACK_COMPLETE của lần tạo đầu

⚠ Có một lựa chọn khác khi ĐANG PHÁT TRIỂN:

Tạo stack với --disable-rollback
  (hoặc --on-failure DO_NOTHING)
        ↓
    Thất bại → dừng lại ở CREATE_FAILED,
    GIỮ NGUYÊN tài nguyên đã tạo được
        ↓
    → xem được hiện trường để gỡ lỗi
    → và từ CREATE_FAILED thì CHẠY TIẾP được
       bằng ContinueUpdateRollback / cập nhật lại

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

• A (chạy update-stack trên stack đã hỏng) — đây là phương án gần nhất về mặt trực giác, nhưng CloudFormation từ chối cập nhật một stack ở ROLLBACK_COMPLETE. Chỉ có DeleteStack được chấp nhận.

• B (chạy execute-change-set) — change set là công cụ xem trước rồi áp dụng một thay đổi lên stack ĐANG TỒN TẠI và khoẻ mạnh. Không tạo được change set cho một stack ở trạng thái này.

• C (chạy validate-template) — chỉ kiểm tra cú pháp JSON/YAML và cấu trúc template, không tạo hay sửa gì cả. Đề đã nói lỗi được sửa xong rồi, nên bước này cũng không giải quyết việc triển khai.

Ghi nhớ

⚠ Các trạng thái stack và lối thoát — bảng phải thuộc: | Trạng thái | Ý nghĩa | Làm gì tiếp | |---|---|---| | ROLLBACK_COMPLETE | tạo lần đầu hỏng, đã dọn sạch | CHỈ XOÁ được → rồi tạo lại | | CREATE_FAILED | hỏng, chưa rollback (do --disable-rollback) | xem hiện trường, xoá hoặc thử tiếp | | UPDATE_ROLLBACK_FAILED | cập nhật hỏng, rollback cũng hỏng | ContinueUpdateRollback | | UPDATE_ROLLBACK_COMPLETE | cập nhật hỏng, đã lùi về bản cũ | stack vẫn dùng được | | DELETE_FAILED | xoá hỏng | xoá lại kèm --retain-resources |

Từ khoá nhận diện:

"ROLLBACK_COMPLETE, tạo lần đầu" → xoá rồi tạo lại "UPDATE_ROLLBACK_FAILED" → continue-update-rollback "muốn xem lỗi trước khi nó dọn sạch" → --disable-rollback "muốn biết thay đổi sẽ ảnh hưởng gì" → change set "giữ lại tài nguyên khi xoá stack" → DeletionPolicy: Retain

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Stack đang ở trạng thái nào | describe-stacks --query 'Stacks[0].StackStatus' | | Vì sao hỏng | describe-stack-events — đọc từ dưới lên, tìm CREATE_FAILED đầu tiên | | Template có hợp lệ không | validate-template (chỉ cú pháp), và cfn-lint cho kiểm tra sâu hơn |

Và một thói quen đáng có khi phát triển template: luôn triển khai lần đầu với --disable-rollback. Hành vi rollback mặc định rất hợp lý ở môi trường thật, nhưng lúc đang viết template thì nó xoá sạch đúng thứ bạn cần nhìn — và bạn sẽ phải đoán nguyên nhân từ vài dòng sự kiện thay vì mở thẳng tài nguyên hỏng ra xem.

Đáp án

A và D — Vá lớp HYPERVISOR, và duy trì HẠ TẦNG MẠNG.

Vì sao đúng

Mô hình trách nhiệm chia sẻ có một đường ranh rất rõ với EC2: AWS lo tới lớp ảo hoá, khách hàng lo từ hệ điều hành khách trở lên.

⚠ Điểm mấu chốt — đường ranh nằm ở đâu với EC2:

     KHÁCH HÀNG chịu trách nhiệm
        ↓
    Dữ liệu của bạn
    Ứng dụng, thư viện, runtime
    HỆ ĐIỀU HÀNH KHÁCH — cài đặt, VÁ LỖI
    Cấu hình mạng: SECURITY GROUP, NACL
    IAM: người dùng, vai, chính sách
    Mã hoá dữ liệu (khi lưu và khi truyền)
════════════ ĐƯỜNG RANH ════════════
        ↓
     AWS chịu trách nhiệm
    HYPERVISOR — vá lỗi, bảo mật
    Máy chủ vật lý, ổ đĩa, nguồn điện
    HẠ TẦNG MẠNG — thiết bị, cáp, đường trục
    Trung tâm dữ liệu: an ninh vật lý, làm mát
    Ảo hoá lưu trữ nền

⚠ Cách nhớ nhanh — "OF the cloud" ↔ "IN the cloud":

AWS lo BẢO MẬT CỦA đám mây (security OF the cloud)
        ↓
    → những thứ bạn KHÔNG CHẠM TỚI ĐƯỢC
      hypervisor, phần cứng, mạng vật lý, toà nhà

Bạn lo BẢO MẬT TRONG đám mây (security IN the cloud)
        ↓
    → những thứ bạn CẤU HÌNH ĐƯỢC trong console/CLI
      hệ điều hành khách, security group, IAM, dữ liệu
        ↓
Phép thử đơn giản:
    "Tôi có bấm được nút đó không?"
      → có  ⇒ trách nhiệm của TÔI
      → không ⇒ trách nhiệm của AWS

⚠ Và ranh giới DỊCH CHUYỂN theo loại dịch vụ:

EC2 (IaaS)      → bạn lo NHIỀU NHẤT: cả hệ điều hành
RDS (PaaS)      → AWS vá hệ điều hành và động cơ CSDL;
                  bạn lo lược đồ, người dùng CSDL, khoá
Lambda (FaaS)   → AWS lo cả runtime;
                  bạn chỉ lo MÃ và IAM
S3              → AWS lo hạ tầng lưu trữ;
                  bạn lo CHÍNH SÁCH và mã hoá

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

• E (vá hệ điều hành khách) — đây là phương án gần nhất và là bẫy kinh điển của mô hình này: với EC2 thì vá hệ điều hành khách là việc của KHÁCH HÀNG. (Với RDS hay Lambda thì AWS lo — nhưng đề hỏi rõ về EC2.)

• B (cấu hình security group) — hoàn toàn là việc của khách hàng. AWS cung cấp cơ chế; bạn quyết định luật nào được mở.

• C (theo dõi mức sử dụng volume EBS) — việc của khách hàng. AWS bảo đảm EBS hoạt động và bền bỉ; dung lượng còn bao nhiêu là chuyện của bạn, và cũng chính vì thế mà chỉ số này cần CloudWatch agent mới lấy được.

Ghi nhớ

⚠ Trách nhiệm với EC2 — bảng phải thuộc: | AWS | Khách hàng | |---|---| | Vá hypervisor | Vá hệ điều hành khách | | Hạ tầng mạng vật lý | Security group, NACL, route table | | An ninh vật lý trung tâm dữ liệu | IAM: người dùng, vai, chính sách | | Phần cứng máy chủ, ổ đĩa | Mã hoá dữ liệu | | Độ bền của EBS và S3 | Sao lưu và snapshot | | Sẵn sàng của hạ tầng AZ | Thiết kế đa AZ cho ứng dụng |

Từ khoá nhận diện:

"hypervisor", "phần cứng", "trung tâm dữ liệu", "hạ tầng mạng" → AWS "hệ điều hành khách", "security group", "IAM", "dữ liệu", "mã hoá" → KHÁCH HÀNG "vá hệ điều hành trên EC2" → khách hàng "vá hệ điều hành trên RDS" → AWS "ai chịu trách nhiệm về 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 | |---|---| | 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 — SOC, ISO, PCI | | Cấu hình của tôi có lệch chuẩn không | Security Hub, chuẩn AWS Foundational Security Best Practices |

Và một hệ quả đáng nhớ của mô hình này khi có sự cố: AWS không bao giờ vá hệ điều hành trên EC2 của bạn, kể cả khi lỗ hổng là loại nghiêm trọng nhất. Bạn sẽ nhận được thông báo qua AWS Health, nhưng việc triển khai bản vá là của bạn — và đó chính là lý do Patch Manager với một baseline có lịch tự động nên được dựng ngay từ ngày đầu, chứ không phải sau lần đầu tiên có CVE khẩn cấp.

Đáp án

A — Đổi instance RDS MySQL sang loại LỚN HƠN (mở rộng theo chiều dọc).

Vì sao đúng

Triệu chứng rất cụ thể: CPU chạm gần 100%. Khi CPU là điểm nghẽn, chỉ có một cách trực tiếp — cho nó nhiều CPU hơn.

⚠ Điểm mấu chốt — chẩn đoán theo đúng chỉ số bị cạn:

CPUUtilization ~100%
        ↓
    Không phải thiếu bộ nhớ (FreeableMemory)
    Không phải nghẽn đĩa (ReadIOPS/WriteIOPS)
    Không phải hết kết nối (DatabaseConnections)
        ↓
    → CPU chính là tài nguyên đang cạn
        ↓
    Đổi sang loại instance nhiều vCPU hơn
      db.t3.large → db.m5.2xlarge chẳng hạn

⚠ Vì sao MySQL trên RDS chỉ mở rộng dọc được ở phần GHI:

RDS MySQL có read replica
        ↓
    → chia được tải ĐỌC
        ↓
    Nhưng chỉ có MỘT node GHI (primary)
        ↓
    → không có cách nào chia tải ghi
    → muốn node ghi mạnh hơn thì phải ĐỔI CỠ nó

⚠ Việc đổi cỡ diễn ra thế nào:

Single-AZ
        ↓
    Gián đoạn vài phút khi đổi
        ↓
Multi-AZ  ← ít gián đoạn hơn nhiều
        ↓
    1. AWS đổi cỡ node DỰ PHÒNG trước
    2. Failover sang node đó
    3. Đổi cỡ node còn lại
        ↓
    → chỉ gián đoạn đúng lúc failover (~60-120 giây)
        ↓
    Đặt trong cửa sổ bảo trì, hoặc apply-immediately

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

• D (mở rộng ngang bằng cách thêm node RDS MySQL để san tải GHI) — đây là phương án gần nhất nhưng sai ở một từ: read replica chỉ nhận ĐỌC, không nhận GHI. RDS MySQL không có chế độ nhiều node ghi. (Muốn nhiều node ghi thì phải là Aurora Multi-Master, một sản phẩm khác.)

• C (bật Multi-AZ để có thêm năng lực) — hiểu sai mục đích của Multi-AZ: node dự phòng ở chế độ standby, không phục vụ truy vấn nào. Multi-AZ là khả năng chịu lỗi, không phải năng lực xử lý.

• B (dùng CloudFront để cache truy vấn CSDL) — CloudFront cache nội dung HTTP, không cache truy vấn SQL. Muốn cache kết quả truy vấn thì dùng ElastiCache.

Ghi nhớ

⚠ Chỉ số RDS ↔ cách chữa — bảng phải thuộc: | Chỉ số cạn | Nguyên nhân | Cách chữa | |---|---|---| | CPUUtilization cao | truy vấn nặng, thiếu chỉ mục, thiếu CPU | đổi cỡ instance, tối ưu truy vấn | | FreeableMemory thấp | buffer pool không đủ | đổi sang họ nhiều RAM (R-family) | | ReadIOPS/WriteIOPS chạm trần | nghẽn lưu trữ | gp3 với IOPS cấp phát, hoặc io2 | | DatabaseConnections chạm trần | quá nhiều kết nối | RDS Proxy, connection pooling | | ReplicaLag cao | replica yếu hơn primary | đổi cỡ replica |

Từ khoá nhận diện:

"CPU 100% trên RDS" → đổi cỡ instance (và xem lại truy vấn) "tải ĐỌC cao" → read replica "quá nhiều kết nối, Lambda" → RDS Proxy "chịu được mất một AZ" → Multi-AZ (không phải để tăng năng lực) "cần nhiều node GHI" → Aurora, không phải RDS MySQL

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Truy vấn nào nặng nhất | Performance Insights → Top SQL | | Đổi cỡ mất bao lâu | describe-events, và trạng thái modifying | | Có thật sự đỡ không | so CPUUtilization và ReadLatency trước/sau |

Và một điều đáng nói thẳng về phương án đúng này: đổi cỡ instance là câu trả lời đúng cho đề, nhưng thường không phải câu trả lời tốt nhất cho hệ thống thật. CPU 100% trên một CSDL quan hệ hầu như luôn bắt nguồn từ một vài truy vấn thiếu chỉ mục, và Performance Insights sẽ chỉ ra chúng trong vài phút — sửa được thì bạn vừa giữ nguyên chi phí, vừa tránh việc vấn đề quay lại ở quy mô lớn hơn.

Đáp án

D — Gọi lệnh cfn-signal ở CUỐI script user data.

Vì sao đúng

Đề nói rõ: wait condition không nhận đủ số tín hiệu. Wait condition chỉ chờ đúng một thứ — tín hiệu do chính máy gửi về.

⚠ Điểm mấu chốt — cơ chế wait condition / CreationPolicy:

CloudFormation tạo Auto Scaling group
        ↓
    Nếu có CreationPolicy hoặc WaitCondition
        ↓
    CloudFormation KHÔNG coi là xong khi máy khởi chạy
        ↓
    Nó CHỜ đủ N tín hiệu thành công
        ↓
    Tín hiệu do ai gửi?
        ↓
    → CHÍNH MÁY EC2 gửi, bằng lệnh cfn-signal
      ở cuối script user data
        ↓
    Không gọi cfn-signal → không có tín hiệu nào
        ↓
    → hết Timeout → CREATE_FAILED → rollback

⚠ Cách viết đúng trong template:

NhomMay:
  Type: AWS::AutoScaling::AutoScalingGroup
  CreationPolicy:
    ResourceSignal:
      Count: 2
      Timeout: PT15M

Và trong user data:

#!/bin/bash
yum install -y aws-cfn-bootstrap
# ... cài đặt ứng dụng ...
/opt/aws/bin/cfn-signal -e $? \
  --stack ${AWS::StackName} \
  --resource NhomMay \
  --region ${AWS::Region}

⚠ Chi tiết quan trọng — -e $? truyền mã thoát:

cfn-signal -e 0    → báo THÀNH CÔNG
cfn-signal -e 1    → báo THẤT BẠI (CloudFormation dừng ngay)
cfn-signal -e $?   → truyền mã thoát của lệnh TRƯỚC ĐÓ
        ↓
    → nếu việc cài đặt hỏng thì stack biết ngay
    → không phải chờ hết 15 phút timeout

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

• C (sửa security group để cho phép lưu lượng RA qua cổng 8080) — đây là phương án gần nhất vì đường mạng đúng là một nguyên nhân có thật khi tín hiệu không về được. Nhưng cfn-signal gọi tới endpoint CloudFormation qua HTTPS cổng 443, không phải 8080. (Và security group mặc định đã cho phép mọi lưu lượng ra.)

• A (giảm số instance mong muốn trong Auto Scaling group) — chỉ giảm số tín hiệu cần chờ, không làm cho tín hiệu nào được gửi. Nếu Count cũng giảm theo thì stack vẫn treo; nếu không thì vẫn không có tín hiệu nào.

• B (đặt AssignPublicIp = True) — có thể là một nguyên nhân đúng ở trường hợp khác (máy ở public subnet mà không có IP công cộng thì không gọi được endpoint), nhưng đề nói user data đã cấu hình instance, và nguyên nhân gốc mà đề nhắm tới là thiếu hẳn lệnh gửi tín hiệu.

Ghi nhớ

⚠ CreationPolicy ↔ WaitCondition — bảng phải thuộc: | | CreationPolicy | WaitCondition | |---|---|---| | Cách dùng | thuộc tính gắn thẳng vào tài nguyên | tài nguyên riêng + handle | | Khuyến nghị | CÁCH HIỆN ĐẠI, nên dùng | cách cũ | | Dùng được với | EC2, ASG, WaitCondition | mọi loại | | Đều cần | cfn-signal từ trong máy | |

Từ khoá nhận diện:

"wait condition không nhận đủ tín hiệu" → thiếu cfn-signal "stack treo rồi timeout" → tín hiệu không về được "muốn stack biết ứng dụng đã sẵn sàng" → CreationPolicy + cfn-signal "cập nhật ASG mà không đứt dịch vụ" → UpdatePolicy "cài đặt phức tạp trong user data" → cfn-init + metadata

Ba việc kiểm chứng: | Việc | Cách | |---|---| | User data có chạy tới cuối không | /var/log/cloud-init-output.log trên máy | | Tín hiệu đã gửi chưa | tab Events của stack, tìm dòng Received SUCCESS signal | | Máy có ra được endpoint không | trên máy chạy curl -I https://cloudformation.<region>.amazonaws.com |

Và một thói quen gỡ lỗi rất hiệu quả cho loại lỗi này: tạo stack với --disable-rollback. Mặc định CloudFormation sẽ xoá sạch máy ngay khi hết timeout, nghĩa là bạn mất luôn /var/log/cloud-init-output.log — đúng tệp duy nhất nói cho bạn biết script dừng ở dòng nào.

Đáp án

B — Cấu hình maintenance window để vá 10% số máy trong patch group tại mỗi thời điểm.

Vì sao đúng

Nguyên nhân gốc là quá nhiều máy bị vá cùng lúc, và maintenance window có sẵn đúng nút chỉnh cho việc đó.

⚠ Điểm mấu chốt — hai tham số quyết định mức ảnh hưởng:

Maintenance window → Task
        ↓
    Concurrency  (số máy chạy CÙNG LÚC)
        ↓
      đặt "10%"  → chỉ 10% số máy bị vá đồng thời
      → 90% còn lại vẫn phục vụ bình thường
        ↓
    Error threshold  (ngưỡng lỗi)
        ↓
      đặt "10%"  → hỏng quá 10% thì DỪNG toàn bộ
      → một bản vá xấu không lan ra cả đội máy

⚠ Vì sao đây là câu trả lời "tự động và ít ảnh hưởng nhất":

Không cần dựng AMI mới
Không cần chia lại patch group
Không cần làm tay từng máy
        ↓
    → chỉ đổi MỘT tham số trên task đã có
    → giữ nguyên lịch tự động

⚠ Ghép thêm với load balancer thì gần như không ai thấy gì:

Máy sắp được vá
        ↓
    Rút khỏi target group của ALB (deregister)
        ↓
    Chờ hết deregistration delay (kết nối đang chạy xong)
        ↓
    Vá + khởi động lại nếu cần
        ↓
    Đăng ký lại, chờ qua health check
        ↓
    → sang máy tiếp theo
        ↓
    Làm được bằng SSM Automation document tuỳ chỉnh

Xem thêm câu #11572, #11610, #11648 và #11791: cùng chùm Systems Manager Patch Manager, mỗi câu nhìn từ một góc — baseline, patch group, tuân thủ, và ở đây là mức đồng thời.

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

• C (dùng nhiều patch group riêng và cập nhật chúng vào các thời điểm khác nhau) — đây là phương án gần nhất và cũng giãn được tải thật, nhưng nó là cách thủ công và thô hơn: phải tự chia nhóm, tự đặt nhiều lịch, và mức song song bên trong mỗi nhóm vẫn không kiểm soát được. Tham số concurrency làm đúng việc đó mà không cần chia lại gì.

• A (dựng AMI đã vá rồi dùng maintenance window triển khai AMI đó cho 10% đội máy mỗi lần) — maintenance window không triển khai AMI. Thay AMI là việc của Auto Scaling group với instance refresh, một quy trình hoàn toàn khác.

• D (cập nhật từng máy một bằng snapshot của AMI đã vá) — thủ công, rất chậm, và trái với yêu cầu "tự động" của đề.

Ghi nhớ

⚠ Các thành phần của Patch Manager — bảng phải thuộc: | Thành phần | Việc | |---|---| | Patch baseline | bản vá nào được duyệt, phân loại, mức nghiêm trọng, danh sách chặn | | Patch group | gắn bằng TAG Patch Group — chia máy theo môi trường | | Maintenance window | khi nào vá, và bao nhiêu máy cùng lúc | | Concurrency | số hoặc phần trăm máy chạy đồng thời | | Error threshold | dừng lại khi hỏng quá ngưỡng | | Patch compliance | báo cáo máy nào còn thiếu bản vá |

Từ khoá nhận diện:

"vá làm chậm dịch vụ" → giảm CONCURRENCY của maintenance window "vá theo môi trường khác nhau" → patch group bằng tag "chỉ duyệt bản vá đã kiểm thử" → patch baseline tuỳ chỉnh + ApprovalDelay "máy nào chưa vá" → Patch compliance "đổi AMI cho cả đội máy" → ASG instance refresh, không phải Patch Manager

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cửa sổ chạy thế nào | describe-maintenance-window-executions | | Máy nào chưa tuân thủ | Systems Manager → Patch Manager → Compliance | | Có thật sự ít ảnh hưởng hơn không | so TargetResponseTime của ALB trong khung giờ vá |

Và một cách tiếp cận đáng cân nhắc nếu đội máy nằm sau Auto Scaling group: thay vì vá tại chỗ, hãy dựng AMI đã vá rồi dùng instance refresh. Cách đó biến việc vá thành việc thay máy, nên máy chạy trong production luôn là máy mới nguyên — và nếu bản vá có vấn đề thì bạn quay lại launch template cũ trong vài phút, thay vì phải gỡ bản vá trên từng máy.

Đáp án

C — Bật S3 TRANSFER ACCELERATION cho bucket và dùng tên miền endpoint s3-accelerate.

Vì sao đúng

Đề có đủ ba dấu hiệu đặc trưng của Transfer Acceleration: khoảng cách địa lý xa, tệp lớn, và truyền theo cả hai chiều.

⚠ Điểm mấu chốt — nó tăng tốc bằng cách nào:

Không có Transfer Acceleration
        ↓
    Người dùng ở ap-south-1 → internet công cộng →
    bucket ở us-east-1
        ↓
    Đi qua nhiều nhà mạng, nhiều chặng, mất gói,
    TCP window nhỏ lại
        ↓
Có Transfer Acceleration
        ↓
    Người dùng → EDGE LOCATION CloudFront gần nhất
      (chỉ vài chục mili giây)
        ↓
    Từ edge → bucket qua ĐƯỜNG TRỤC RIÊNG của AWS
        ↓
    → đường tối ưu, ít mất gói, băng thông lớn
    → nhanh hơn 50-500% với tệp lớn đi xa

⚠ Cách dùng — phải đổi endpoint:

Endpoint thường:
    ten-bucket.s3.us-east-1.amazonaws.com

Endpoint tăng tốc:
    ten-bucket.s3-accelerate.amazonaws.com
        ↓
    Bật tính năng chưa đủ — ứng dụng PHẢI GỌI
    endpoint mới thì mới có tác dụng
        ↓
    Yêu cầu: tên bucket KHÔNG ĐƯỢC CÓ DẤU CHẤM

⚠ Và một công cụ để biết có đáng tiền không:

AWS có trang so sánh tốc độ công khai
  (Speed Comparison tool)
        ↓
    Đo thử từ chính vị trí của bạn
        ↓
    → chỉ trả tiền khi thực sự nhanh hơn
      (AWS không tính phí nếu không cải thiện)

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

• B (tạo bucket mới cùng tên ở ap-south-1 rồi dùng endpoint của bucket đó) — sai ngay ở tiền đề: tên bucket S3 là DUY NHẤT TOÀN CẦU, không thể có hai bucket cùng tên ở hai Region. (Ý tưởng nhân bản dữ liệu sang Region gần hơn thì đúng — nhưng cách làm là Cross-Region Replication với một bucket tên khác.)

• A (đổi mã hoá phía máy chủ từ AES sang RSA) — S3 không hỗ trợ RSA cho mã hoá lưu trữ (chỉ có SSE-S3/AES-256, SSE-KMS, SSE-C), và mã hoá không liên quan gì tới tốc độ truyền.

• D (giảm số tiền tố — prefix — trong bucket) — đi ngược lại: nhiều prefix hơn thì thông lượng cao hơn, vì S3 mở rộng theo prefix (mỗi prefix 3.500 PUT và 5.500 GET mỗi giây).

Ghi nhớ

⚠ Bốn cách tăng tốc S3 — chọn theo đúng bài toán: | Vấn đề | Giải pháp | |---|---| | Tải LÊN từ xa, tệp lớn | Transfer Acceleration | | Tải XUỐNG nhiều, nội dung lặp lại | CloudFront (có cache) | | Tệp rất lớn (>100 MB) | Multipart Upload — song song, thử lại từng phần | | Người đọc ở Region khác thường xuyên | Cross-Region Replication | | Dữ liệu hàng chục TB trở lên | Snowball / DataSync |

Từ khoá nhận diện:

"tải LÊN chậm từ xa" → Transfer Acceleration "tải XUỐNG chậm, nhiều người đọc cùng nội dung" → CloudFront "tệp vài GB" → Multipart Upload (bắt buộc trên 5 GB) "cần bản sao ở Region khác" → CRR "chuyển 100 TB lên cloud" → Snowball

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có nhanh hơn thật không | công cụ Speed Comparison của AWS | | Đã bật chưa | get-bucket-accelerate-configuration | | Ứng dụng có dùng endpoint mới không | bắt log request, tìm s3-accelerate |

Và một chi tiết dễ làm mất công vô ích: bật Transfer Acceleration mà không sửa endpoint trong ứng dụng thì không có gì thay đổi cả — bucket vẫn nhận request qua endpoint thường, tốc độ y như cũ, và bạn cũng không bị tính thêm phí. Vậy nên khi kiểm chứng, hãy nhìn vào chính chuỗi endpoint mà SDK đang gọi, đừng chỉ nhìn công tắc trên console.

Đáp án

D — Tạo IAM ROLE có quyền truy cập S3 rồi gắn role đó vào instance EC2.

Vì sao đúng

Đây là nguyên tắc nền tảng nhất của IAM trên EC2: máy dùng role, không dùng khoá.

⚠ Điểm mấu chốt — role cung cấp thông tin xác thực TẠM THỜI, tự xoay:

Gắn IAM role vào instance
  (qua instance profile)
        ↓
    Instance Metadata Service (IMDS) cấp
      access key + secret + session token
        ↓
    Thông tin này TỰ HẾT HẠN sau vài giờ
    và TỰ ĐƯỢC LÀM MỚI
        ↓
    SDK và CLI tự tìm thấy, không cần cấu hình gì
        ↓
    → KHÔNG có khoá dài hạn nào nằm trên đĩa
    → không có gì để lộ, không phải xoay tay

⚠ Vì sao "không có khoá trên máy" quan trọng đến thế:

Access key dài hạn nằm trên máy
        ↓
    → lộ khi ai đó đọc được tệp cấu hình
    → lộ khi vô tình commit vào git
    → lộ khi AMI được chia sẻ
    → lộ trong bản sao lưu, trong snapshot
        ↓
    Và khoá dài hạn KHÔNG TỰ HẾT HẠN
        ↓
    → kẻ lấy được dùng mãi tới khi có người phát hiện

⚠ Vẫn phải áp quyền tối thiểu:

{
  "Effect": "Allow",
  "Action": ["s3:PutObject"],
  "Resource": "arn:aws:s3:::bucket-log-ung-dung/*"
}

Chỉ hành động thật sự cần (ghi log → PutObject)
Chỉ bucket thật sự cần
Nhớ /* cho thao tác trên ĐỐI TƯỢNG
        ↓
    → role bị lạm dụng cũng chỉ tới được đúng chỗ đó

Xem thêm câu #11813 và #11814: cùng về instance profile — ở đó là điều kiện để Systems Manager quản lý được máy.

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

• C (tạo IAM user rồi uỷ quyền cho instance) — đây là phương án gần nhất và là cách làm cũ, nhưng IAM user đi kèm access key dài hạn phải nằm đâu đó trên máy. Đúng thứ mà role sinh ra để loại bỏ.

• B (lưu access key trong AMI) — tệ nhất trong bốn phương án: khoá được nhân bản vào mọi máy dựng từ AMI đó, tồn tại mãi, và lộ ngay nếu AMI được chia sẻ.

• A (đặt bucket policy cho phép mọi instance EC2 truy cập) — quá rộng một cách nguy hiểm: mọi máy trong tài khoản, kể cả máy của môi trường khác hay máy vừa bị xâm nhập, đều ghi được vào bucket.

Ghi nhớ

⚠ Bốn cách cấp quyền cho tải công việc — bảng phải thuộc: | Cách | Đánh giá | |---|---| | IAM role gắn vào EC2 | ĐÚNG — khoá tạm thời, tự xoay | | IAM role cho Lambda / ECS task / EKS service account | cùng nguyên tắc, đúng cho từng dịch vụ | | IAM user + access key | chỉ cho người hoặc hệ thống NGOÀI AWS | | Khoá nhúng trong mã hoặc AMI | KHÔNG BAO GIỜ |

Từ khoá nhận diện:

"EC2 cần gọi dịch vụ AWS" → IAM role, luôn luôn "cần bảo mật cao nhất" → role + quyền tối thiểu "máy TẠI CHỖ cần gọi AWS" → IAM Roles Anywhere hoặc SSM Hybrid Activation "CI/CD ngoài AWS" → OIDC federation, không phải access key "khoá đã lộ" → vô hiệu hoá NGAY, rồi mới điều tra

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Máy đang dùng role nào | trên máy: aws sts get-caller-identity | | Role có đủ/thừa quyền không | IAM Access Analyzer, tab Access Advisor | | Còn khoá dài hạn nào không | IAM Credential Report toàn tài khoản |

Và một việc nên làm ngay sau khi chuyển sang role: rà lại xem còn tệp ~/.aws/credentials nào sót trên máy không. Khi có cả role lẫn tệp khoá, SDK ưu tiên tệp khoá — nên hệ thống vẫn chạy bình thường, bạn tưởng đã chuyển xong, còn khoá cũ thì vẫn đang được dùng và vẫn tiếp tục là rủi ro.

Đáp án

A và B — Đảm nhận một role có quyền s3:BypassGovernanceRetention, VÀ thêm header x-amz-bypass-governance-retention: true vào request xoá.

Vì sao đúng

Object Lock ở chế độ governance được thiết kế để chặn xoá nhầm nhưng vẫn cho phép người có thẩm quyền vượt qua — và việc vượt qua đòi cả hai điều kiện cùng lúc.

⚠ Điểm mấu chốt — hai điều kiện, thiếu một là hỏng:

ĐIỀU KIỆN 1 — QUYỀN
        ↓
    Danh tính gọi phải có s3:BypassGovernanceRetention
        ↓
    Không có → 403 AccessDenied

ĐIỀU KIỆN 2 — Ý ĐỊNH RÕ RÀNG
        ↓
    Request phải mang header
      x-amz-bypass-governance-retention: true
        ↓
    Thiếu header → S3 từ chối, dù có quyền
        ↓
    (CLI: cờ --bypass-governance-retention)

⚠ Vì sao AWS bắt phải có CẢ HAI:

Chỉ cần quyền thôi thì
        ↓
    một lệnh xoá gõ vội cũng đi qua được
    → mất luôn ý nghĩa "chống xoá nhầm"
        ↓
Bắt khai header riêng
        ↓
    → người gọi phải CỐ Ý nói "tôi biết đang vượt rào"
    → không ai vượt rào một cách vô tình

⚠ Governance ↔ Compliance — khác biệt cốt lõi:

GOVERNANCE MODE
        ↓
    Vượt qua ĐƯỢC, nếu có quyền + header
    → phù hợp khi cần đường lùi

COMPLIANCE MODE
        ↓
    KHÔNG AI vượt qua được — kể cả TÀI KHOẢN GỐC
    → không rút ngắn được thời hạn giữ
    → không xoá được cho tới khi hết hạn
    → dùng cho yêu cầu pháp lý như SEC 17a-4

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

• D (đảm nhận role có quyền s3:PutObjectRetention) — đây là phương án gần nhất và cũng là một quyền có thật liên quan tới Object Lock, nhưng nó dùng để đặt hoặc sửa thời hạn giữ, không phải để xoá vượt rào. Đúng quyền cần là s3:BypassGovernanceRetention.

• C (đổi bucket từ governance sang compliance mode) — đi ngược lại hoàn toàn: compliance là chế độ chặt hơn, và sau khi đặt thì dữ liệu càng không xoá được.

• E (gia hạn Retain Until Date cho dữ liệu đó) — kéo dài thời gian không xoá được, đúng ngược với mục tiêu. (Và với Object Lock, ngày giữ chỉ kéo DÀI ra được, không rút ngắn.)

Ghi nhớ

⚠ Hai chế độ Object Lock — bảng phải thuộc: | | Governance | Compliance | |---|---|---| | Vượt qua được | CÓ — quyền + header | KHÔNG, kể cả root | | Rút ngắn thời hạn | được (khi vượt rào) | không bao giờ | | Xoá sớm | được (khi vượt rào) | không bao giờ | | Dùng khi | bảo vệ khỏi xoá nhầm | yêu cầu pháp lý bắt buộc | | Rủi ro | thấp | đặt sai là ôm chi phí lưu trữ tới hết hạn |

Từ khoá nhận diện:

"xoá dữ liệu trong governance mode" → s3:BypassGovernanceRetention + HEADER "không ai được xoá, kể cả admin" → compliance mode "WORM", "SEC 17a-4", "bất biến" → Object Lock "giữ vô thời hạn cho một vụ kiện" → Legal Hold "lỡ bật compliance sai" → không sửa được — chỉ chờ hết hạn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bucket đang ở chế độ nào | get-object-lock-configuration | | Một đối tượng bị khoá tới bao giờ | get-object-retention --version-id ... | | Ai đã vượt rào | CloudTrail, tìm request có header bypass |

Và một quy tắc vận hành nên đặt ra ngay: quyền s3:BypassGovernanceRetention chỉ nên nằm trong một role riêng, cần đảm nhận có chủ đích và bắt buộc MFA, chứ không gắn vào role vận hành hằng ngày. Chính sự bất tiện đó là thứ giữ cho governance mode còn nguyên tác dụng — nếu ai cũng vượt rào được bằng một lệnh, thì bucket của bạn thực chất chưa được bảo vệ gì cả.