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

Đáp án

C — Load Balancer sẽ định tuyến request tới chính các target đang không khoẻ.

Vì sao đúng

Đây là một hành vi ít người biết nhưng rất logic khi hiểu ý đồ thiết kế: ELB thà thử một máy có thể hỏng còn hơn từ chối thẳng mọi khách.

⚠ Điểm mấu chốt — "fail open" khi TẤT CẢ target trong một AZ đều unhealthy:

Còn ít nhất một target khoẻ
        ↓
    → chỉ gửi request tới target khoẻ (bình thường)

TẤT CẢ target đều unhealthy
        ↓
    → ELB "fail open": gửi request tới TẤT CẢ target
        ↓
    → biết đâu health check sai mà ứng dụng vẫn phục vụ được

Lý do rất thực tế: health check có thể báo sai. Đường dẫn health check bị lỗi, ngưỡng đặt quá chặt, hay một lần triển khai làm /health trả 500 trong khi / vẫn chạy tốt — trong những trường hợp đó, từ chối toàn bộ lưu lượng là biến một sự cố nhỏ thành ngừng dịch vụ hoàn toàn.

⚠ Đề còn một chi tiết quan trọng: có hai AZ:

AZ-A: cả hai instance unhealthy
AZ-B: instance vẫn khoẻ
        ↓
Nếu BẬT cross-zone load balancing
        ↓
    → lưu lượng của AZ-A được chuyển sang instance khoẻ ở AZ-B
        ↓
    → đây mới là cách bảo vệ thật sự

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

• D (trả HTTP 503 Service Unavailable) — đây là phương án gần nhất và rất nhiều người chọn nó, vì 503 đúng là mã ALB trả khi không có target nào đăng ký trong target group. Nhưng ở đây target có đăng ký, chỉ là đang bị đánh dấu unhealthy — và trong tình huống đó ELB gửi request tới chúng chứ không trả 503.

• A (ELB hiện trạng thái "unhealthy" và ngừng nhận request) — bản thân Load Balancer không có trạng thái unhealthy; trạng thái đó thuộc về target. ELB vẫn active và vẫn nhận kết nối.

• B (trả HTTP 403 Forbidden) — 403 là mã của quyền truy cập, thường do WAF hoặc listener rule chặn, không liên quan gì tới sức khoẻ target.

Ghi nhớ

⚠ Ba tình huống và mã trả về của ALB — bảng phải thuộc: | Tình huống | Kết quả | |---|---| | Có target khoẻ | định tuyến tới target khoẻ | | Mọi target unhealthy | vẫn định tuyến tới chúng (fail open) | | Target group RỖNG | HTTP 503 | | Không khớp listener rule nào | HTTP 503 (hoặc mã của default action) | | Target từ chối kết nối | HTTP 502 | | Target không trả lời kịp | HTTP 504 |

Từ khoá nhận diện:

"tất cả target unhealthy" → vẫn nhận request, fail open "không có target nào đăng ký" → 503 "lỗi kết nối tới target" → 502 "target quá chậm" → 504 (tăng idle timeout hoặc sửa ứng dụng)

Ba việc kiểm chứng khi mọi target unhealthy: | Việc | Cách | |---|---| | Lý do cụ thể | describe-target-health — xem Reason (Target.Timeout, Target.ResponseCodeMismatch…) | | Security Group của target | có mở đúng cổng health check cho SG của ELB không | | Đường dẫn health check | gọi thẳng vào instance bằng curl xem trả gì |

Và một lời khuyên: hãy đặt cảnh báo trên chỉ số UnHealthyHostCount và HealthyHostCount của ELB. Chính vì ELB fail open, một sự cố kiểu này không hiện ra dưới dạng lỗi: khách vẫn nhận được trả lời, chỉ là từ những máy đã hỏng, nên có thể là dữ liệu cũ, phiên bản sai, hoặc trả lời chậm bất thường. Không có cảnh báo thì đội vận hành chỉ biết chuyện khi người dùng phàn nàn.

Đáp án

A — Để đạt thông lượng gần hoặc vượt 20.000 gói mỗi giây (PPS) trên trình điều khiển VIF.

Vì sao đúng

Enhanced networking sinh ra để vượt qua trần của lớp ảo hoá mạng cũ.

⚠ Điểm mấu chốt — enhanced networking dùng SR-IOV để đi thẳng vào phần cứng:

Không có enhanced networking
        ↓
    Gói tin → hypervisor xử lý → instance
        ↓
    → CPU của host tốn cho việc chuyển gói
    → độ trễ cao hơn, dao động nhiều hơn, trần PPS thấp

Có enhanced networking (SR-IOV)
        ↓
    Gói tin → card mạng ảo hoá ở PHẦN CỨNG → thẳng vào instance
        ↓
    → PPS cao hơn nhiều, độ trễ thấp và ổn định hơn
    → KHÔNG tính thêm tiền

⚠ Ba điều cần nhớ về chi phí và điều kiện:

Enhanced networking là MIỄN PHÍ
        ↓
Nhưng cần: loại instance hỗ trợ + AMI có driver + bật thuộc tính
        ↓
Mọi instance thế hệ hiện tại đã BẬT SẴN
        ↓
    → câu hỏi chỉ còn quan trọng với instance thế hệ cũ

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

• D (đạt tốc độ tới 2.500 Gbps giữa các EC2 instance) — đây là phương án gần nhất vì nó cũng nói về hiệu năng mạng, nhưng con số hoàn toàn bịa. Băng thông mạng EC2 tính bằng Gbps ở mức vài chục tới 400 Gbps với các loại lớn nhất, không có 2.500 Gbps. Và enhanced networking chủ yếu cải thiện PPS và độ trễ, không phải một con số băng thông tuyệt đối.

• B (cấu hình Direct Connect đạt 25 Gbps giữa các EC2 instance) — nhầm hoàn toàn: Direct Connect là đường truyền riêng từ trung tâm dữ liệu của bạn tới AWS, không liên quan gì tới lưu lượng giữa hai EC2 instance trong cùng VPC.

• C (cấu hình multi-attach cho EBS volume gắn vào tối đa 16 instance) — đây là tính năng EBS Multi-Attach, thuộc về lưu trữ chứ không phải mạng. (Con số cũng đáng nhớ: io1/io2 Multi-Attach gắn được tối đa 16 instance trong cùng một AZ.)

Ghi nhớ

⚠ Ba công nghệ mạng hiệu năng cao của EC2 — bảng phải thuộc: | Công nghệ | Dùng cho | Ghi chú | |---|---|---| | ENA (Elastic Network Adapter) | enhanced networking hiện tại, tới 100+ Gbps | mặc định thế hệ mới | | Intel 82599 VF | enhanced networking đời cũ, tới 10 Gbps | instance cũ | | EFA (Elastic Fabric Adapter) | HPC và huấn luyện ML — bỏ qua cả nhân hệ điều hành | dùng với MPI/NCCL |

Từ khoá nhận diện:

"PPS cao", "độ trễ thấp", "hiệu năng mạng" → enhanced networking (ENA) "HPC", "MPI", "huấn luyện phân tán" → EFA "độ trễ thấp nhất giữa các instance" → cluster placement group "nối trung tâm dữ liệu với AWS" → Direct Connect "một volume nhiều instance" → EBS Multi-Attach

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Instance đã bật chưa | describe-instances, xem EnaSupport: true | | Driver có nạp không | ethtool -i eth0 — thấy driver: ena | | Có đang chạm trần không | chỉ số bw_in_allowance_exceeded, pps_allowance_exceeded của ENA |

Và một lời khuyên: khi mạng chậm bất thường, hãy xem các chỉ số *_allowance_exceeded của ENA trước khi đổ lỗi cho ứng dụng. AWS không chặn thẳng lưu lượng vượt hạn mức mà âm thầm vứt gói, nên triệu chứng hiện ra là độ trễ tăng, kết nối thỉnh thoảng đứt, và TCP truyền lại — trông y hệt lỗi ứng dụng. Chỉ những bộ đếm này mới nói cho bạn biết instance đang chạm trần băng thông, PPS, hay số kết nối đồng thời.

Đáp án

D — Dùng một CMK nằm CÙNG tài khoản với Auto Scaling group: sao chép và mã hoá lại snapshot bằng CMK mới của tài khoản đó, rồi cho phép service-linked role dùng CMK mới.

Vì sao đúng

Chi tiết quyết định nằm ở dòng đầu đề bài: "một công ty vận hành NHIỀU tài khoản AWS" — nghĩa là CMK và ASG không cùng một tài khoản.

⚠ Điểm mấu chốt: service-linked role của ASG KHÔNG dùng được CMK ở tài khoản khác:

CMK nằm ở tài khoản A
ASG nằm ở tài khoản B
        ↓
    Service-linked role của ASG (tài khoản B)
        ↓
    → KHÔNG được cấp quyền dùng CMK liên tài khoản
        ↓
    → khởi chạy instance thất bại: "Client.InternalError"

Cách sửa đúng là đưa khoá về cùng nhà:

Ở tài khoản B (nơi có ASG):
    1. Tạo (hoặc chọn) một CMK của chính tài khoản B
    2. Sao chép snapshot của volume, mã hoá lại bằng CMK đó
       aws ec2 copy-snapshot --source-snapshot-id snap-xxx \
           --encrypted --kms-key-id <cmk-cua-tai-khoan-B>
    3. Tạo AMI mới từ snapshot đã mã hoá lại
    4. Sửa key policy của CMK mới: cho phép
       AWSServiceRoleForAutoScaling dùng khoá
    5. Trỏ launch template của ASG sang AMI mới

⚠ Bốn quyền mà service-linked role cần trên CMK — thiếu một là hỏng:

kms:Decrypt
kms:GenerateDataKeyWithoutPlaintext
kms:CreateGrant          ← hay bị quên nhất
kms:DescribeKey

Xem thêm câu #11558: cùng tình huống này nhưng hỏi nguyên nhân của thông báo lỗi Client.InternalError: Client error on launch. Hai câu bổ sung cho nhau — một câu chẩn đoán, một câu chữa.

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

• A (sửa key policy cho service-linked role rồi trỏ ASG dùng role đó) — đây là phương án gần nhất và nó đúng khi CMK cùng tài khoản với ASG. Nhưng đề nêu rõ bối cảnh nhiều tài khoản; với CMK ở tài khoản khác thì cách này không đủ. Ngoài ra vế "cập nhật ASG để dùng service-linked role" cũng lệch: service-linked role được AWS tạo và gắn tự động, không phải thứ bạn chọn cho ASG.

• B (xuất CMK từ tài khoản này sang tài khoản kia) — không tồn tại. Phần khoá bí mật của CMK không bao giờ rời khỏi KMS; đó là toàn bộ lý do KMS được các tiêu chuẩn tuân thủ chấp nhận. Thứ duy nhất "mang đi" được là bản sao dữ liệu đã mã hoá lại bằng khoá khác — chính là đáp án D.

• C (ASG không khởi chạy được instance có volume mã hoá) — sai hoàn toàn. ASG làm việc này hằng ngày; vấn đề của đề chỉ là quyền trên khoá, không phải giới hạn của dịch vụ.

Ghi nhớ

⚠ Hai loại khoá KMS — bảng phải thuộc: | Loại | Sửa key policy được | Chia sẻ liên tài khoản | |---|---|---| | AWS managed key (aws/ebs) | KHÔNG | KHÔNG | | Customer managed key (CMK) | CÓ | CÓ |

Từ khoá nhận diện:

"ASG + EBS mã hoá + lỗi khởi chạy" → quyền trên CMK cho service-linked role "CMK ở tài khoản khác" → sao chép và mã hoá lại snapshot bằng CMK cùng tài khoản "xuất/nhập CMK" → LUÔN SAI, khoá không rời KMS aws/ebs mà cần chia sẻ → SAI, phải dùng CMK "phải nhập khoá của riêng mình" → import key material, hoặc External Key Store

Ba việc kiểm chứng: | Việc | Cách | |---|---| | ASG hỏng vì gì | xem Activity history của ASG, không xem log EC2 | | Key policy có đủ không | get-key-policy, tìm AWSServiceRoleForAutoScaling | | Snapshot mã hoá bằng khoá nào | describe-snapshots, xem KmsKeyId |

Và một lời khuyên: hãy mã hoá AMI dùng chung bằng CMK của chính tài khoản chạy workload, ngay từ khi dựng pipeline. Lỗi này gần như luôn xuất hiện muộn và tệ nhất có thể: ASG đã chạy êm nhiều tháng, rồi một đêm scale-out lúc cao điểm thì mọi instance mới đều chết ngay khi khởi chạy, không có log ứng dụng nào để đọc, và thông báo duy nhất là Client.InternalError — một dòng chẳng nói gì về KMS.

Đáp án

D — Cảnh báo tiếp tục đánh giá chỉ số so với ngưỡng ngay cả sau khi đã kích hoạt. Nếu không muốn nó ở trạng thái ALARM thì phải điều chỉnh ngưỡng.

Vì sao đúng

Nhầm lẫn của bạn lập trình viên trong đề là tưởng cảnh báo hoạt động như một sự kiện — kêu một tiếng rồi thôi. Thực tế CloudWatch alarm là một máy trạng thái, phản ánh liên tục tình hình hiện tại của chỉ số.

⚠ Điểm mấu chốt: ALARM không phải "đã báo rồi", mà là "ngay lúc này vẫn đang vượt ngưỡng":

Chỉ số vượt ngưỡng
        ↓
    OK → ALARM, thực hiện action MỘT LẦN
        ↓
Chỉ số VẪN vượt ngưỡng
        ↓
    → vẫn ở ALARM, KHÔNG lặp lại action
        ↓
Chỉ số trở lại dưới ngưỡng
        ↓
    → ALARM → OK, tự động, không cần ai reset

Vậy cảnh báo kẹt mãi ở ALARM chỉ có nghĩa duy nhất: chỉ số thật sự vẫn đang vượt ngưỡng. Hai hướng xử lý:

⚠ Ba trạng thái của alarm và một cái bẫy:

OK                  → chỉ số trong ngưỡng
ALARM               → chỉ số vượt ngưỡng
INSUFFICIENT_DATA   → chưa đủ dữ liệu để kết luận
        ↓
    Cảnh báo trên chỉ số ít khi phát dữ liệu
        ↓
    → kẹt ở INSUFFICIENT_DATA, không bao giờ báo
        ↓
    → chữa bằng "Treat missing data as" cho phù hợp

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

• C (mã ứng dụng phải tự reset cảnh báo về trạng thái bình thường) — đây là phương án gần nhất và nghe rất hợp lý với ai quen hệ thống giám sát đời cũ, nơi cảnh báo phải "acknowledge" bằng tay. CloudWatch không hoạt động vậy: trạng thái do dữ liệu quyết định, chuyển về OK hoàn toàn tự động. (Có set-alarm-state để thử nghiệm, nhưng lần đánh giá kế tiếp sẽ ghi đè ngay.)

• B (cảnh báo tuỳ chỉnh ở ALARM tới khi tắt bằng tay) — sai; không có sự khác biệt nào về hành vi giữa cảnh báo trên chỉ số tuỳ chỉnh và chỉ số dựng sẵn.

• A (cấu hình sai, phải xoá rồi tạo lại) — vừa không đúng nguyên nhân vừa thừa: cảnh báo sửa tại chỗ được, không cần xoá. Và trong đa số trường hợp thì cảnh báo không hề sai — chính hệ thống mới đang có vấn đề.

Ghi nhớ

⚠ Ba trạng thái của CloudWatch alarm — bảng phải thuộc: | Trạng thái | Nghĩa | |---|---| | OK | chỉ số nằm trong ngưỡng | | ALARM | chỉ số vượt ngưỡng — cập nhật liên tục, không phải sự kiện | | INSUFFICIENT_DATA | thiếu dữ liệu để kết luận |

Từ khoá nhận diện:

"kẹt ở ALARM" → chỉ số vẫn đang vượt ngưỡng thật "phải reset bằng tay" → LUÔN SAI với CloudWatch "kẹt ở INSUFFICIENT_DATA" → chỉnh "treat missing data" "báo giả liên tục" → tăng EvaluationPeriods hoặc dùng M-out-of-N "chỉ số bất thường theo mùa" → anomaly detection thay ngưỡng cố định

Ba việc kiểm chứng khi alarm kẹt: | Việc | Cách | |---|---| | Lịch sử chuyển trạng thái | describe-alarm-history — thấy đúng lúc nó vào ALARM | | Chỉ số thật ra sao | vẽ đồ thị cùng khoảng thời gian, so với đường ngưỡng | | Action có chạy không | SNS topic có subscriber đã xác nhận chưa |

Và một lời khuyên: hãy coi một cảnh báo kẹt ở ALARM nhiều ngày là bằng chứng cảnh báo đó đã hỏng, dù chỉ số có đúng hay không. Đội vận hành học rất nhanh cách phớt lờ một dòng đỏ luôn đỏ, và khi ấy nó không còn là cảnh báo mà chỉ là đồ trang trí — tệ hơn nữa, nó dạy mọi người bỏ qua đúng cái bảng điều khiển mà một ngày kia sẽ hiện sự cố thật.

Đáp án

A — Tạo role Ở TÀI KHOẢN PRODUCTION, khai tài khoản Development là trusted entity, gắn permissions policy cho phép cập nhật bucket; RỒI sửa policy của IAM group ở tài khoản development để TỪ CHỐI nhóm Testers dùng role đó.

Vì sao đúng

Phương án đúng gồm hai nửa, và cả hai đều bắt buộc.

⚠ Nửa thứ nhất — role phải nằm ở nơi có tài nguyên:

Tài nguyên cần truy cập: bucket S3 ở PRODUCTION
        ↓
    → role phải tạo ở tài khoản PRODUCTION
        ↓
    Trust policy: "ai được phép đóng vai này"
        → tài khoản Development
    Permissions policy: "đóng vai rồi thì làm được gì"
        → s3:PutObject, s3:GetObject... trên bucket đó

⚠ Nửa thứ hai — trust policy tin cả TÀI KHOẢN, nên phải chặn lại ở phía bên kia:

Trust policy ghi: Principal = arn:aws:iam::<dev-account>:root
        ↓
    → nghĩa là MỌI user ở tài khoản dev đều có thể được phép
        ↓
    → cả Testers, không chỉ Developers
        ↓
Chữa: gắn Deny sts:AssumeRole trên role đó vào nhóm Testers

Chính sách Deny ở nhóm Testers:

{
  "Effect": "Deny",
  "Action": "sts:AssumeRole",
  "Resource": "arn:aws:iam::<prod-account>:role/CapNhatBucketProd"
}

⚠ Vì sao Deny tường minh là cách chắc chắn:

Trong IAM, Deny LUÔN thắng Allow
        ↓
    Dù sau này ai đó gắn nhầm quyền Allow cho Testers
        ↓
    → Deny vẫn chặn được

Đây là mẫu cross-account access bằng role, và nó tốt hơn hẳn việc tạo user IAM thứ hai ở tài khoản production: không có khoá dài hạn nào — mỗi lần đóng vai, STS cấp một bộ chứng chỉ tạm có thời hạn.

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

• D (tạo role ở production tin tài khoản development, không có phần Deny cho Testers) — đây là phương án gần nhất và nửa đầu hoàn toàn đúng. Nhưng thiếu nửa sau: trust policy tin cả tài khoản dev, nên Testers cũng đóng vai được nếu chính sách IAM của họ không cấm. Đề nêu rõ chỉ Developers mới được cập nhật bucket production, nên thiếu Deny là chưa đạt yêu cầu.

• C (tạo role ở tài khoản DEVELOPMENT, tin tài khoản production) — ngược chiều hoàn toàn. Role tạo ở dev thì chỉ cấp được quyền trên tài nguyên của dev; và trust ngược lại nghĩa là người ở production đóng vai vào dev — trái hẳn nhu cầu của đề.

• B (dùng inline policy cho chắc chắn không gán nhầm) — nói về cách tổ chức chính sách chứ không giải quyết bài toán liên tài khoản. Inline hay managed cũng không giúp một user ở tài khoản dev chạm được vào bucket ở tài khoản prod; chỉ role liên tài khoản mới làm được.

Ghi nhớ

⚠ Hai chính sách của một IAM role — bảng phải thuộc: | Chính sách | Trả lời câu hỏi | |---|---| | Trust policy | AI được đóng vai này | | Permissions policy | Đóng vai rồi thì làm được gì |

Từ khoá nhận diện:

"truy cập tài nguyên ở tài khoản khác" → role ở tài khoản CÓ TÀI NGUYÊN "chỉ một nhóm được, nhóm kia không" → thêm Deny sts:AssumeRole "tạo user IAM ở tài khoản kia" → thường SAI, khoá dài hạn "nhiều tài khoản, quản trị tập trung" → IAM Identity Center (SSO) "đối tác bên ngoài" → role + sts:ExternalId

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đóng vai được không | aws sts assume-role --role-arn ... --role-session-name thu | | Ai đã đóng vai | CloudTrail sự kiện AssumeRole, xem userIdentity | | Quyền hiệu lực thật | IAM Policy Simulator |

Và một cảnh báo về vận hành: Principal: {"AWS": "arn:aws:iam::123456789012:root"} trong trust policy không có nghĩa là "chỉ user root" — nó nghĩa là cả tài khoản đó, và đây là một trong những hiểu nhầm gây rò quyền phổ biến nhất. Muốn thắt chặt thật sự thì hãy khai đích danh ARN của role hoặc user được phép, thay vì tin cả tài khoản rồi bịt lại bằng Deny ở phía bên kia.

Đáp án

C — Một change set đã được thực thi thành công, và điều đó khiến CloudFormation xoá toàn bộ các change set còn lại.

Vì sao đúng

Đây là hành vi có chủ ý của CloudFormation mà rất ít người biết cho tới khi vấp phải.

⚠ Điểm mấu chốt: thực thi MỘT change set sẽ xoá TẤT CẢ change set còn lại của stack đó:

Stack có 5 change set đang chờ
        ↓
    Đội A thực thi change set của mình
        ↓
    → stack chuyển sang trạng thái mới
        ↓
    → 4 change set kia được tính trên trạng thái CŨ
        ↓
    → CloudFormation XOÁ hết chúng

Lý do rất hợp lý: change set là bản so sánh giữa template mới và trạng thái stack tại thời điểm tạo. Khi stack đã đổi, mọi so sánh cũ đều lỗi thời — giữ lại chỉ mời gọi người ta thực thi một thay đổi đã tính sai.

⚠ Cách sửa cho tình huống nhiều đội dùng chung template:

Vấn đề: nhiều đội tạo change set trên CÙNG MỘT stack
        ↓
Cách 1: mỗi đội một stack riêng từ cùng template  ← đúng nhất
Cách 2: quy trình tuần tự — thực thi xong thì
        các đội TẠO LẠI change set trên trạng thái mới
Cách 3: StackSets nếu cần triển khai ra nhiều tài khoản/Region

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

• A (vượt hạn mức tài nguyên của tài khoản khi kiểm tra change set) — đây là phương án gần nhất vì hạn mức đúng là gây lỗi thật khi cập nhật stack. Nhưng khi đó stack thất bại và rollback, còn change set thì không bị xoá hàng loạt; và lỗi hạn mức luôn hiện thông báo rõ ràng chứ không im lặng như đề mô tả.

• B (CloudFormation rollback và xoá các change set không hợp lệ) — change set không có khái niệm rollback: chúng chỉ là bản mô tả thay đổi, chưa đụng tới tài nguyên nào. Change set không tạo được thì mang trạng thái FAILED và vẫn nằm nguyên đó để đọc lý do.

• D (một change set không hợp lệ được thực thi khiến mọi stack và change set bị xoá) — sai nặng: stack không bị xoá. Thực thi hỏng thì stack rollback về trạng thái trước đó (UPDATE_ROLLBACK_COMPLETE), tài nguyên vẫn còn nguyên.

Ghi nhớ

⚠ Vòng đời của một change set — bảng phải thuộc: | Bước | Lệnh | |---|---| | Tạo | create-change-set | | Xem trước | describe-change-set — thấy Add / Modify / Remove | | Thực thi | execute-change-set — xoá mọi change set khác của stack | | Bỏ | delete-change-set |

Từ khoá nhận diện:

"change set biến mất" → có người đã thực thi một cái "nhiều đội dùng chung stack" → tách mỗi đội một stack "muốn biết thay đổi gì trước khi làm" → change set "triển khai nhiều tài khoản/Region" → StackSets "cấm sửa/xoá tài nguyên quan trọng" → stack policy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai đã thực thi change set | CloudTrail sự kiện ExecuteChangeSet | | Stack đổi gì và lúc nào | tab Events của stack | | Change set còn lại | list-change-sets --stack-name ... |

Và một lời khuyên: hãy luôn đọc cột Replacement trước khi thực thi change set. Change set trông rất hiền — nó chỉ là một bảng liệt kê — nên rất dễ liếc qua rồi bấm Execute. Nhưng một dòng Replacement: True trên RDS instance hay EBS volume nghĩa là CloudFormation sẽ xoá tài nguyên cũ và tạo cái mới, và với những tài nguyên có DeletionPolicy mặc định thì dữ liệu trong đó biến mất cùng nó.

Đáp án

B — Instance sẽ bị chấm dứt (terminated).

Vì sao đúng

Đề trộn hai thuộc tính nghe rất giống nhau nhưng canh hai cửa hoàn toàn khác nhau:

⚠ Điểm mấu chốt: lệnh shutdown gõ trong hệ điều hành KHÔNG đi qua API, nên DisableApiTermination không đụng tới nó:

Lập trình viên gõ shutdown trong Windows
        ↓
    Đây KHÔNG phải lời gọi API
        ↓
    → DisableApiTermination hoàn toàn không có tác dụng
        ↓
    Hành vi do InstanceInitiatedShutdownBehavior quyết định
        ↓
    Đề nói thuộc tính này "đã được đặt" → giá trị terminate
        ↓
    → instance bị CHẤM DỨT

⚠ Và còn một hệ quả nữa vì instance nằm trong ASG:

Instance bị chấm dứt
        ↓
    ASG thấy số instance thấp hơn desired capacity
        ↓
    → khởi chạy một instance MỚI thay thế
        ↓
    → mọi dữ liệu trên ổ tạm và mọi thứ chưa lưu đều mất

Đó chính là lý do đề nhấn mạnh "instance trọng yếu với hoạt động kinh doanh": nhóm kỹ thuật tưởng đã khoá chặt nó, nhưng cánh cửa họ khoá không phải cánh cửa mà lập trình viên đi qua.

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

• A (instance sẽ không tắt vì đã đặt DisableApiTermination) — đây là phương án gần nhất và là hiểu nhầm phổ biến nhất về thuộc tính này. Thuộc tính đó chỉ chặn lời gọi API; nó không hề can thiệp vào hệ điều hành bên trong.

• C (ASG không chấm dứt được instance có DisableApiTermination) — vế này có phần đúng trong ngữ cảnh khác (ASG thật sự vấp phải thuộc tính này khi tự scale-in), nhưng không đúng với tình huống của đề: ở đây chấm dứt là do chính hệ điều hành khởi xướng, ASG không ra lệnh gì cả.

• D (hệ điều hành gửi thông báo SNS rồi hoãn tắt máy vài phút) — bịa hoàn toàn. DisableApiTermination là một cờ boolean, không có tham số SNS, không có thời gian trì hoãn nào.

Ghi nhớ

⚠ Bốn thuộc tính bảo vệ EC2 — bảng phải thuộc: | Thuộc tính | Chặn | |---|---| | DisableApiTermination | terminate qua API | | DisableApiStop | stop qua API | | InstanceInitiatedShutdownBehavior | stop (mặc định) hoặc terminate khi tắt từ trong OS | | DeleteOnTermination (trên volume) | volume có bị xoá cùng instance không |

Từ khoá nhận diện:

"shutdown từ trong hệ điều hành" → InstanceInitiatedShutdownBehavior quyết định "terminate qua Console/CLI" → DisableApiTermination chặn được "DisableApiTermination chặn được lệnh trong OS" → LUÔN SAI "không muốn mất dữ liệu ổ gốc" → DeleteOnTermination: false "ASG không được thay instance này" → Standby hoặc bật instance protection

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thuộc tính hiện tại | describe-instance-attribute --attribute disableApiTermination | | Hành vi khi tắt trong OS | --attribute instanceInitiatedShutdownBehavior | | Ai/cái gì đã chấm dứt | CloudTrail TerminateInstances — hoặc không có bản ghi nào nếu do OS |

Và một lời khuyên cho kiến trúc: một instance "trọng yếu, không được mất" mà nằm trong Auto Scaling Group là một mâu thuẫn tự thân. ASG được sinh ra để coi máy chủ như thứ dùng rồi bỏ; nếu có thứ gì trên máy đó không thể mất, thì thứ đó phải nằm ở EBS volume tách rời, EFS, RDS hay S3 — chứ không phải ở ổ đĩa của một máy mà chính hệ thống được thiết kế để thay thế bất cứ lúc nào.

Đáp án

D — Tạo AMI bằng cách TẮT tuỳ chọn "No reboot" (tức là để instance khởi động lại).

Vì sao đúng

Câu này xoay quanh khác biệt giữa nhất quán ở mức tệp và nhất quán ở mức ứng dụng.

⚠ Điểm mấu chốt: khởi động lại là cách duy nhất để mọi thứ trong bộ nhớ được ghi xuống đĩa:

Bật "No reboot" (không khởi động lại)
        ↓
    Chụp ảnh ổ đĩa khi máy đang chạy
        ↓
    → dữ liệu đang nằm trong bộ đệm chưa ghi xuống đĩa
    → giao dịch cơ sở dữ liệu đang dở
        ↓
    → AMI có thể KHÔNG nhất quán ở mức ứng dụng

Tắt "No reboot" (mặc định — cho phép khởi động lại)
        ↓
    EC2 tắt máy sạch sẽ → mọi bộ đệm được ghi xuống đĩa
        ↓
    Chụp ảnh → khởi động lại instance
        ↓
    → AMI NHẤT QUÁN Ở MỨC ỨNG DỤNG

Đánh đổi rất rõ ràng và cũng chính là câu hỏi thực tế mà mọi đội vận hành phải trả lời:

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

• A (tạo AMI với "No reboot" BẬT) — đây là phương án gần nhất và ngược hẳn đáp án đúng. Chính tài liệu AWS ghi rõ: bật No reboot thì không đảm bảo được tính toàn vẹn của hệ thống tệp trong ảnh tạo ra.

• B (tạo AMI kiểu EBS-backed để có nhất quán ứng dụng) — nhầm hai khái niệm. EBS-backed hay instance store-backed nói về nơi lưu ổ gốc, không nói gì về việc dữ liệu trong bộ nhớ đã ghi xuống đĩa hay chưa. AMI EBS-backed vẫn không nhất quán nếu chụp lúc máy đang chạy với No reboot.

• C (tạo AMI với "Delete on termination" bật) — DeleteOnTermination quyết định volume có bị xoá khi instance bị chấm dứt hay không, hoàn toàn không liên quan tới tính nhất quán của ảnh.

Ghi nhớ

⚠ Ba mức nhất quán khi sao lưu — bảng phải thuộc: | Mức | Nghĩa | |---|---| | Crash-consistent | như rút phích điện — hệ thống tệp có thể phải kiểm tra lại | | File-system consistent | bộ đệm hệ thống tệp đã ghi xuống đĩa | | Application-consistent | ứng dụng đã đóng giao dịch dở, dữ liệu dùng ngay được |

Từ khoá nhận diện:

"application-consistent AMI" → cho phép khởi động lại (tắt No reboot) "không được gián đoạn dịch vụ" → No reboot, chấp nhận rủi ro "application-consistent mà KHÔNG khởi động lại" → dùng SSM Run Command chạy VSS hoặc fsfreeze trước khi chụp "nhất quán nhiều volume cùng lúc" → multi-volume snapshot của EBS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ảnh đã tạo xong chưa | describe-images, chờ State: available | | Có bỏ khởi động lại không | tham số --no-reboot trong lệnh create-image | | Ảnh có dùng được không | khởi chạy thử một instance từ nó trước khi tin |

Và một lời khuyên: hãy thực sự khởi chạy một instance từ AMI vừa tạo, ít nhất mỗi kỳ một lần. Bản sao lưu chưa từng được khôi phục thì chưa phải bản sao lưu — trạng thái available chỉ nói rằng AWS đã chép xong các khối dữ liệu, nó hoàn toàn không nói rằng hệ thống tệp bên trong lành lặn hay ứng dụng khởi động lên được.

Đáp án

B — Dùng AWS Systems Manager Patch Manager để tự động hoá việc vá các managed instance.

Vì sao đúng

Patch Manager là dịch vụ sinh ra đúng cho bài toán này, và chi tiết "các đội đã gắn tag đầy đủ theo hướng dẫn" trong đề chính là gợi ý dẫn tới nó.

⚠ Điểm mấu chốt: Patch Manager chọn máy theo TAG, nên hạ tầng đã gắn tag là gần như xong việc:

Patch Group (một tag đặc biệt tên "Patch Group")
        ↓
    Patch Baseline: luật chọn bản vá nào được duyệt
        ↓
    Maintenance Window: khung giờ được phép vá
        ↓
    → tự động quét và vá, có báo cáo tuân thủ

⚠ Hai chế độ của Patch Manager — biết cả hai là hiểu được cách triển khai an toàn:

Scan  → chỉ kiểm tra và BÁO CÁO, không cài gì
        → dùng để biết mình đang thiếu bao nhiêu bản vá
Install → cài bản vá thật, có thể tự khởi động lại
        → chạy trong maintenance window

Và thứ đề thật sự cần — "tuân thủ" — chính là đầu ra sẵn có của dịch vụ:

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

• A (dùng Systems Manager Automation) — đây là phương án gần nhất và Automation đúng là một phần của Systems Manager, có thể dựng runbook để vá. Nhưng nó là công cụ chung để tự động hoá quy trình vận hành; dùng nó cho việc vá nghĩa là tự viết lại thứ mà Patch Manager đã có sẵn — kèm baseline, kèm maintenance window, và quan trọng nhất là kèm báo cáo tuân thủ. Đề hỏi cách "nhanh và dễ nhất", nên câu trả lời là dịch vụ chuyên trách.

• C (Amazon Patch Manager) — không có dịch vụ nào tên như vậy. Tên đúng là AWS Systems Manager Patch Manager. Đây là bẫy tên gọi rất hay gặp trong đề thi.

• D (Amazon Inspector tự động vá) — Inspector chỉ quét và báo lỗ hổng, nó không cài bản vá nào. Hai dịch vụ này bổ sung cho nhau: Inspector chỉ ra vấn đề, Patch Manager sửa vấn đề.

Ghi nhớ

⚠ Các thành phần chính của Systems Manager — bảng phải thuộc: | Thành phần | Việc | |---|---| | Patch Manager | vá hệ điều hành, báo cáo tuân thủ | | Run Command | chạy lệnh một lần trên nhiều máy | | Automation | runbook nhiều bước cho quy trình vận hành | | Session Manager | shell không cần SSH, không cần cổng 22, không cần bastion | | Parameter Store | lưu cấu hình và bí mật | | State Manager | giữ máy ở đúng trạng thái mong muốn | | Inventory | kiểm kê phần mềm đã cài |

Từ khoá nhận diện:

"vá lỗi, tuân thủ bản vá" → Patch Manager "quét lỗ hổng bảo mật" → Amazon Inspector "Amazon Patch Manager" → LUÔN SAI, không có dịch vụ này "đánh giá cấu hình tài nguyên" → AWS Config "tổng hợp cảnh báo bảo mật" → Security Hub "chạy một lệnh trên hàng trăm máy" → Run Command

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Máy nào chưa quản lý được | Fleet Manager — máy thiếu sẽ không hiện ra, đó là dấu hiệu | | Tình trạng tuân thủ | describe-instance-patch-states | | Vá có chạy đúng giờ không | lịch sử của maintenance window |

Và một cảnh báo về cách đọc báo cáo: instance không xuất hiện trong Patch Manager là tình huống nguy hiểm hơn instance báo NON_COMPLIANT. Máy NON_COMPLIANT thì ai cũng thấy và sẽ có người xử lý; còn máy thiếu SSM Agent hay thiếu IAM role thì đơn giản là vắng mặt khỏi mọi báo cáo, và bảng tuân thủ vẫn hiện 100% xanh cho những máy còn lại. Hãy luôn đối chiếu số máy trong Patch Manager với số instance đang chạy thật.

Đáp án

B — Theo dõi kết quả các service check của Trusted Advisor bằng Amazon CloudWatch Events.

Vì sao đúng

Yêu cầu của đề là biết khi shard của Kinesis Data Streams sắp chạm hạn mức, và trong bốn phương án chỉ có một đường dẫn thật sự tồn tại.

⚠ Điểm mấu chốt: Trusted Advisor có nhóm check "Service Limits", và kết quả check phát ra sự kiện:

Trusted Advisor chạy check "Service Limits"
        ↓
    Phát hiện đã dùng >= 80% hạn mức shard
        ↓
    Phát sự kiện tới EventBridge (CloudWatch Events)
        ↓
    → SNS gửi email cho đội quản trị

Mẫu quy tắc EventBridge:

{
  "source": ["aws.trustedadvisor"],
  "detail-type": ["Trusted Advisor Check Item Refresh Notification"],
  "detail": {
    "status": ["WARN", "ERROR"],
    "check-name": ["Service Limits"]
  }
}

⚠ Hai điều kiện của cách làm này:

Check "Service Limits" của Trusted Advisor
        ↓
    Có ở MỌI mức hỗ trợ (là một trong các check miễn phí)
        ↓
Nhưng nó chỉ làm mới KHOẢNG MỖI 24 GIỜ
        ↓
    → hợp cho việc lên kế hoạch dung lượng
    → KHÔNG hợp để phản ứng tức thì

Ngưỡng cảnh báo là 80% hạn mức, tức là bạn được báo trước khi thật sự chạm trần — đúng điều đề cần.

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

• A (CloudTrail sinh log cho service limit rồi CloudWatch báo) — đây là phương án gần nhất vì CloudTrail và CloudWatch đúng là tích hợp với nhau. Nhưng CloudTrail ghi lời gọi API, nó không có khái niệm hạn mức dịch vụ. Nó chỉ ghi lại được lúc bạn đã bị từ chối vì vượt hạn mức (LimitExceededException) — tức là báo sau khi sự cố đã xảy ra, chứ không cảnh báo trước.

• C (CloudWatch ServiceLens theo dõi hạn mức dịch vụ) — hiểu sai công dụng. ServiceLens gắn kết chỉ số, log và X-Ray trace để nhìn sức khoẻ ứng dụng theo góc nhìn dịch vụ; nó không theo dõi hạn mức tài khoản.

• D (CloudWatch Events lấy dữ liệu từ Amazon Inspector) — Inspector là dịch vụ quét lỗ hổng bảo mật, không liên quan gì tới hạn mức của Kinesis.

Ghi nhớ

⚠ Ba cách theo dõi hạn mức dịch vụ — bảng phải thuộc: | Cách | Đặc điểm | |---|---| | Trusted Advisor + EventBridge | check Service Limits, làm mới ~24h, ngưỡng 80% | | Service Quotas + CloudWatch alarm | đẩy chỉ số mức sử dụng lên CloudWatch — theo dõi được sát hơn | | Chỉ số riêng của dịch vụ | ví dụ WriteProvisionedThroughputExceeded của Kinesis |

Từ khoá nhận diện:

"sắp chạm hạn mức dịch vụ" → Trusted Advisor hoặc Service Quotas "xin tăng hạn mức" → Service Quotas (có thể tự động qua API) "ai đã gọi API nào" → CloudTrail "quét lỗ hổng" → Inspector "bản đồ dịch vụ, trace" → ServiceLens / X-Ray

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đang dùng bao nhiêu hạn mức | Service Quotas console, hoặc list-service-quotas | | Có bị throttle không | chỉ số *ProvisionedThroughputExceeded | | Quy tắc EventBridge có khớp không | dùng Test event pattern trong console |

Và một lời khuyên: nếu việc lo đếm shard đang tốn thời gian của đội, hãy cân nhắc chuyển stream sang chế độ on-demand. Nó đắt hơn tính trên mỗi đơn vị dữ liệu, nhưng nó xoá sổ nguyên một loại sự cố — dữ liệu bị throttle rồi mất vì không ai kịp thêm shard trong đêm cao điểm — và với ứng dụng phát video có lưu lượng lên xuống thất thường thì đó thường là món hời.