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

Đáp án

B — Sửa danh sách tài khoản được phép thấy AMI ngay trong giao diện AMI Console, và các tài khoản kia dùng được ngay.

Vì sao đúng

AMI có một cơ chế chia sẻ riêng biệt, không đi qua IAM role: thuộc tính launch permission.

⚠ Điểm mấu chốt — chia sẻ AMI là sửa một thuộc tính của chính AMI:

Thuộc tính launchPermission của AMI
        ↓
    Thêm số hiệu tài khoản vào danh sách
        ↓
    → tài khoản đó THẤY và KHỞI CHẠY được AMI ngay
        ↓
    → KHÔNG cần IAM role, KHÔNG cần STS, KHÔNG cần assume gì cả

# Chia sẻ cho từng tài khoản
aws ec2 modify-image-attribute --image-id ami-xxxxxxxx \
  --launch-permission "Add=[{UserId=111122223333},{UserId=444455556666}]"

⚠ Và vì đề nói "cùng một tổ chức", có cách gọn hơn nhiều:

# Chia sẻ cho CẢ tổ chức, hoặc một OU — không phải liệt kê từng tài khoản
aws ec2 modify-image-attribute --image-id ami-xxxxxxxx \
  --launch-permission \
  "Add=[{OrganizationArn=arn:aws:organizations::111122223333:organization/o-abc123}]"

⚠ Một điều bắt buộc phải nhớ nếu AMI được mã hoá:

AMI mã hoá bằng AWS managed key (aws/ebs)
        ↓
    → KHÔNG chia sẻ được, vì key policy không sửa được

AMI mã hoá bằng CUSTOMER-MANAGED CMK
        ↓
    → phải chia sẻ THÊM quyền dùng CMK trong key policy
        ↓
    Snapshot thì KHÔNG cần chia sẻ riêng — đi kèm AMI sẵn

Và một lời khuyên cho bên nhận: nên copy-image về tài khoản mình để không phụ thuộc vào việc bên chia sẻ có xoá AMI hay thu quyền hay không.

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

• D (sửa danh sách tài khoản VÀ tạo IAM role để assume qua STS) — đây là phương án gần nhất và vế đầu hoàn toàn đúng. Nhưng vế sau thừa: launch permission tự nó đã đủ, không cần thêm cơ chế đóng vai nào.

• A (chỉ tạo IAM role để tài khoản kia assume) — không hoạt động. IAM role cấp quyền trong phạm vi tài khoản sở hữu role, nhưng khả năng khởi chạy một AMI cụ thể được điều khiển bởi launch permission của chính AMI, không phải bởi chính sách IAM.

• C (không cần làm gì, chỉ đưa "AMI id bí mật" là dùng được) — sai và nguy hiểm về tư duy bảo mật: AMI id không phải bí mật, và AMI riêng tư thì tài khoản khác không thấy được dù biết id.

Ghi nhớ

⚠ Ba cách chia sẻ AMI — bảng phải thuộc: | Cách | Cú pháp | |---|---| | Cho tài khoản cụ thể | Add=[{UserId=111122223333}] | | Cho cả Organization / OU | Add=[{OrganizationArn=...}] hoặc OrganizationalUnitArn | | Công khai cho tất cả | Add=[{Group=all}] — cẩn thận |

Từ khoá nhận diện:

"chia sẻ AMI cho tài khoản khác" → modify-image-attribute launch permission "chia sẻ AMI cần IAM role" → SAI, không cần "chia sẻ cho toàn tổ chức" → OrganizationArn "AMI mã hoá bằng aws/ebs" → KHÔNG chia sẻ được "bên nhận muốn độc lập" → copy-image về tài khoản mình "dùng ở Region khác" → copy-image sang Region đó

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai đang được chia sẻ | describe-image-attribute --attribute launchPermission | | AMI có mã hoá không | describe-images, xem block device mapping | | Bên kia dùng được chưa | khởi chạy thử một instance ở tài khoản đó |

Và một lời khuyên về quản trị AMI trong tổ chức nhiều tài khoản: hãy dùng EC2 Image Builder cùng với một tài khoản chuyên trách chứa AMI chuẩn, thay vì để mỗi đội tự dựng và tự chia sẻ. Khi AMI được chia sẻ tay từ tài khoản cá nhân của một kỹ sư, chuỗi phụ thuộc trở nên vô hình — và ngày người đó dọn dẹp tài khoản của mình cũng là ngày các Auto Scaling group của những đội khác ngừng khởi chạy được máy mới.

Đáp án

D — Đặt OnFailure=DO_NOTHING.

Vì sao đúng

Vấn đề của đề rất rõ ràng: CloudFormation xoá mất chính cái máy chứa bằng chứng cần đọc.

⚠ Điểm mấu chốt — hành vi mặc định là rollback, và rollback xoá instance:

cfn-init thất bại
        ↓
    CloudFormation rollback (mặc định)
        ↓
    → chấm dứt instance
        ↓
    → EBS volume bị xoá theo
        ↓
    → log biến mất trước khi kịp đọc

⚠ OnFailure=DO_NOTHING giữ nguyên hiện trường:

aws cloudformation create-stack \
  --stack-name thu-nghiem \
  --template-body file://mau.yaml \
  --on-failure DO_NOTHING

Stack thất bại → dừng ở CREATE_FAILED
        ↓
    → instance VẪN CHẠY
        ↓
    → SSH hoặc Session Manager vào, đọc log thoải mái
    → không có giới hạn thời gian nào
        ↓
    → đúng yêu cầu "gỡ lỗi trong hơn 24 giờ" của đề

⚠ Ba giá trị của OnFailure — phải thuộc:

Đừng quên dọn dẹp: stack ở CREATE_FAILED vẫn tính tiền cho mọi tài nguyên nó đã tạo.

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

• C (cài CloudWatch Logs agent, tạo IAM role, đẩy log thẳng lên CloudWatch) — đây là phương án gần nhất và là một thực hành rất tốt trong sản xuất. Nhưng đề nêu một ràng buộc rõ: "không thay đổi cách EC2 instance hoạt động" — mà cài agent và gắn IAM role mới chính là thay đổi đó. Ngoài ra, nếu cfn-init hỏng trước khi agent kịp chạy thì cách này cũng không cứu được.

• A (tăng Wait Timeout lên 2 giờ) — chỉ khiến CloudFormation chờ lâu hơn rồi vẫn rollback và vẫn xoá máy. Và 2 giờ không đáp ứng yêu cầu "gỡ lỗi trong hơn 24 giờ".

• B (bật VPC Flow Logs để bắt tệp log của cfn-init) — hiểu sai hoàn toàn: VPC Flow Logs ghi siêu dữ liệu lưu lượng mạng (IP, cổng, chấp nhận/từ chối). Nó không đọc được nội dung của bất cứ tệp nào.

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

Đề ghi đường dẫn log là /var/cfn/cfn-init-output.log, nhưng đường dẫn thật trên Amazon Linux là /var/log/cfn-init-output.log (và /var/log/cfn-init.log). Đây là lỗi nhỏ trong đề bài, không ảnh hưởng tới đáp án — vấn đề vẫn là làm sao giữ instance lại để đọc được log, dù nó nằm ở đâu.

Ghi nhớ

⚠ Các tệp log cần đọc khi CloudFormation dựng EC2 thất bại — bảng phải thuộc: | Tệp | Nội dung | |---|---| | /var/log/cloud-init-output.log | toàn bộ user data chạy tới đâu — xem ĐẦU TIÊN | | /var/log/cfn-init.log | cfn-init làm gì, hỏng ở bước nào | | /var/log/cfn-init-cmd.log | đầu ra chi tiết của từng lệnh | | /var/log/cloud-init.log | quá trình khởi tạo của cloud-init |

Từ khoá nhận diện:

"stack rollback xoá mất máy hỏng" → OnFailure=DO_NOTHING (hoặc --disable-rollback) "stack xong quá sớm" → thiếu CreationPolicy / WaitCondition "không nhận được tín hiệu" → thiếu đường mạng, hoặc hết thời gian chờ "muốn giữ dữ liệu khi xoá stack" → DeletionPolicy: Retain "cập nhật hỏng, rollback cũng hỏng" → continue-update-rollback

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Stack hỏng ở tài nguyên nào | tab Events, tìm dòng CREATE_FAILED đầu tiên | | Vào máy bằng gì | Session Manager nếu chưa mở SSH | | Đã chạy tới bước nào | so mốc thời gian trong cfn-init.log với Events của stack |

Và một lời nhắc rất thực tế: DO_NOTHING để lại toàn bộ tài nguyên đã tạo, và tất cả chúng vẫn tính tiền. Trong lúc phát triển, việc thử đi thử lại một template hỏng có thể để lại một dãy stack CREATE_FAILED với instance, NAT Gateway và load balancer nằm im — hãy đặt lịch dọn chúng, hoặc ít nhất là một cảnh báo ngân sách, trước khi phát hiện ra sau vài tuần.

Đáp án

D — AMI ID gắn với từng Region, nên phải cấp một danh sách AMI hợp lệ KHÁC NHAU tuỳ Region mà script chạy.

Vì sao đúng

Đây là một trong những bài học nền tảng nhất về AWS, và nó lộ ra đúng lúc mã nguồn được đem sang Region khác.

⚠ Điểm mấu chốt — cùng một ảnh, khác Region là khác id:

Amazon Linux 2023 ở eu-west-1  → ami-0abcd1234ef567890
Amazon Linux 2023 ở us-east-1  → ami-09876fedc543210ab
        ↓
    CÙNG một hệ điều hành, CÙNG một bản dựng
    → nhưng HAI ID hoàn toàn khác nhau
        ↓
    Script so id của New York với danh sách của Ireland
        ↓
    → không khớp cái nào → báo tất cả không tuân thủ
    → trong khi kiểm toán viên kiểm tay thì thấy đúng chuẩn

⚠ Cách sửa đúng — tra id theo Region thay vì viết cứng:

# Cách 1: bảng ánh xạ Region → danh sách AMI hợp lệ
AMI_HOP_LE = {
    'eu-west-1': ['ami-0abcd1234ef567890', ...],
    'us-east-1': ['ami-09876fedc543210ab', ...],
}
region = boto3.session.Session().region_name
hop_le = AMI_HOP_LE[region]

# Cách 2 (tốt hơn): tra động qua SSM Public Parameter
aws ssm get-parameter --region us-east-1 \
  --name /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64 \
  --query 'Parameter.Value' --output text

# Cách 3 (tốt nhất cho việc kiểm tra tuân thủ):
#   đừng so theo AMI ID — hãy so theo TAG
#   gắn tag cho mọi AMI được duyệt, ví dụ TuanThu=true
#   → script chỉ cần kiểm tra tag, không phụ thuộc Region

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

• A (đã chạm hạn mức lời gọi API và script không xử lý lỗi đó) — đây là phương án gần nhất vì throttling API là vấn đề thật khi quét nhiều tài nguyên. Nhưng khi bị throttle, script sẽ ném ngoại lệ hoặc bỏ sót instance, chứ không đưa ra kết quả "tất cả đều không tuân thủ" một cách nhất quán như đề mô tả.

• C (script thiếu quyền IAM) — thiếu quyền thì lời gọi trả về AccessDenied, và script sẽ báo lỗi chứ không đọc được danh sách instance để đánh giá.

• B (đồng nghiệp chạy sai, hãy viết tài liệu hướng dẫn) — đổ lỗi cho người dùng trong khi lỗi nằm ở thiết kế của script. Kiểm toán viên đã kiểm tay và xác nhận các instance đúng chuẩn — bằng chứng rõ ràng rằng script sai.

Ghi nhớ

⚠ Tài nguyên nào theo Region, theo AZ, hay global — bảng phải thuộc: | Phạm vi | Tài nguyên | |---|---| | Global | IAM, Route 53, CloudFront, WAF (cho CloudFront), S3 (tên bucket) | | Region | AMI, EBS snapshot, VPC, Elastic IP, key pair, security group, RDS | | AZ | EBS volume, subnet, instance store |

Từ khoá nhận diện:

"AMI dùng được ở Region khác" → KHÔNG, phải copy-image "viết cứng AMI id trong mã" → LUÔN LÀ LỖI thiết kế "lấy AMI mới nhất tự động" → SSM Public Parameter "CloudFormation cần AMI theo Region" → mục Mappings, hoặc AWS::SSM::Parameter::Value<AWS::EC2::Image::Id> "IAM user dùng ở Region nào" → mọi Region, IAM là global

Ba việc kiểm chứng: | Việc | Cách | |---|---| | AMI id tương ứng ở Region khác | describe-images --filters Name=name,Values=<ten-anh> | | Script đang chạy ở Region nào | in ra Region ngay đầu script — nên là thói quen | | Có phiên bản đúng ở đó không | so ImageId với Name và CreationDate |

Và một lời khuyên về cách kiểm thử: hãy chạy thử mọi script trên ít nhất hai Region trước khi đưa cho người khác dùng. Lỗi kiểu này không bao giờ lộ ra ở Region gốc, không sinh ngoại lệ, không ghi dòng lỗi nào — nó chỉ âm thầm trả về một kết quả sai mà trông rất có thẩm quyền, và trong bối cảnh kiểm toán tài chính thì một báo cáo sai còn tệ hơn nhiều so với một script chạy lỗi.

Đáp án

D — AWS Organizations với Organizational Unit (OU).

Vì sao đúng

Vấn đề gốc của công ty nằm ở một câu trong đề: 200 nhân viên đang dùng CHUNG MỘT tài khoản AWS.

⚠ Điểm mấu chốt — trong cùng một tài khoản, không có ranh giới thật sự:

Cùng một tài khoản
        ↓
    Chỉ có IAM policy làm hàng rào
        ↓
    Một chính sách viết lỏng, một quyền gán nhầm
        ↓
    → đội này sửa được tài nguyên đội kia
    → đúng như việc tạo VPC peering lung tung mà đề mô tả
        ↓
    Và hoá đơn cũng chung một chỗ, không tách theo phòng ban được

⚠ Tài khoản riêng là ranh giới cô lập MẠNH NHẤT trên AWS:

Mỗi phòng ban → một (hoặc vài) tài khoản riêng
        ↓
    Gom vào các OU: Ke-toan, Van-hanh, Tai-chinh
        ↓
    → mặc định KHÔNG có đường nào chạm sang nhau
    → VPC peering giữa hai tài khoản phải được CẢ HAI chấp nhận
    → hạn mức dịch vụ tách riêng, sự cố không lan sang nhau
    → chi phí tách bạch tự nhiên theo tài khoản

⚠ Và SCP là thứ IAM policy không làm được:

Service Control Policy gắn vào OU
        ↓
    Đặt TRẦN quyền tối đa cho MỌI principal trong đó
        ↓
    → kể cả IAM user có AdministratorAccess cũng không vượt được
    → kể cả root của tài khoản thành viên
        ↓
    Ví dụ: chặn hẳn ec2:AcceptVpcPeeringConnection
           → hết chuyện đội này nối vào VPC đội kia

Bộ công cụ đi kèm: Control Tower dựng sẵn cấu trúc landing zone, IAM Identity Center cho đăng nhập một lần vào nhiều tài khoản, và thanh toán gộp vẫn cho hưởng chiết khấu theo tổng khối lượng.

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

• A (IAM Group với chính sách hạn chế) — đây là phương án gần nhất và là cách nhiều công ty thử đầu tiên. Nhưng nó chỉ là hàng rào trong cùng một tài khoản: chính sách phức tạp dần theo số đội, ai đó có quyền IAM vẫn tự nới được, và hạn mức dịch vụ vẫn dùng chung — một đội tạo quá nhiều VPC là cả công ty hết chỗ.

• B (IAM Role với chính sách hạn chế) — cùng hạn chế như A. Role tốt hơn user về mặt chứng chỉ tạm thời, nhưng vẫn không tạo ra ranh giới cô lập nào.

• C (AWS GuardDuty) — dịch vụ phát hiện mối đe doạ. Nó có thể báo cho bạn biết có chuyện lạ đang xảy ra, nhưng không tách môi trường của ai với ai.

Ghi nhớ

⚠ Các mức cô lập trên AWS, từ yếu tới mạnh — bảng phải thuộc: | Mức | Cô lập | |---|---| | IAM policy trong một tài khoản | yếu nhất — phụ thuộc cách viết chính sách | | VPC riêng trong một tài khoản | tách mạng, nhưng không tách quyền quản trị | | Tài khoản AWS riêng | mạnh nhất — ranh giới mặc định của mọi thứ | | OU + SCP | thêm trần quyền không ai vượt được |

Từ khoá nhận diện:

"tách môi trường theo phòng ban / theo đội" → Organizations + OU "đặt trần quyền, kể cả admin cũng không vượt" → SCP "dựng sẵn cấu trúc nhiều tài khoản theo chuẩn" → Control Tower "đăng nhập một lần vào nhiều tài khoản" → IAM Identity Center "chia sẻ subnet giữa các tài khoản" → AWS RAM "nối nhiều VPC cho gọn" → Transit Gateway, không phải peering từng cặp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cây tổ chức hiện tại | list-organizational-units-for-parent | | SCP đang áp cho ai | list-policies-for-target | | Quyền hiệu lực thật | IAM Policy Simulator, hoặc describe-effective-policy |

Và một lời khuyên về cách chuyển đổi: hãy bắt đầu bằng việc dựng cấu trúc tài khoản mới rồi di chuyển từng đội một, đừng cố tách hạ tầng trong tài khoản cũ. Tách một tài khoản đã có 200 người dùng chung là công việc khó nhất trong toàn bộ quá trình — nhưng nó cũng là công việc mà mỗi tháng trì hoãn lại khiến nó khó thêm một chút, vì lượng tài nguyên đan xen vào nhau chỉ có tăng chứ không bao giờ giảm.

Đáp án

A, D — hai cách rút ngắn thời gian nâng cấp:

• D — Tạo GOLDEN AMI đã cài sẵn ứng dụng và các phụ thuộc.
• A — Tạo môi trường Beanstalk mới cho mỗi phiên bản và áp dụng mẫu triển khai BLUE/GREEN.

Vì sao đúng

Đề nêu hai ràng buộc, và mỗi giải pháp giải quyết một ràng buộc:

⚠ Golden AMI — chuyển việc cài đặt sang lúc DỰNG ẢNH thay vì lúc TRIỂN KHAI:

Cách hiện tại:
    máy mới lên → cài runtime → cài phụ thuộc OS → cài ứng dụng
        ↓
    → mỗi lần triển khai đều làm lại từ đầu, mất hàng chục phút

Golden AMI:
    dựng sẵn một AMI đã có runtime + phụ thuộc + ứng dụng
        ↓
    → máy mới chỉ cần KHỞI ĐỘNG là chạy
    → thời gian triển khai xuống còn vài phút

⚠ Blue/Green — không có phút chết nào và quay lui tức thì:

Môi trường BLUE đang phục vụ (phiên bản cũ)
        ↓
    Dựng môi trường GREEN mới hoàn toàn, phiên bản mới
        ↓
    Kiểm thử GREEN kỹ càng khi nó CHƯA nhận lưu lượng
        ↓
    Swap CNAME giữa hai môi trường
        ↓
    → chuyển tức thì, không gián đoạn
    → có vấn đề thì SWAP NGƯỢC LẠI, cũng tức thì

Hai thứ này bổ sung cho nhau: Golden AMI làm môi trường GREEN dựng lên nhanh, còn blue/green đảm bảo không mất dịch vụ trong lúc chuyển.

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

• C (dùng "rolling with additional batch") — đây là phương án gần nhất vì nó thật sự giữ được tính sẵn sàng: Beanstalk thêm một lô máy mới trước rồi mới thay dần. Nhưng nó không rút ngắn thời gian nâng cấp — mỗi máy vẫn phải cài lại toàn bộ runtime và phụ thuộc, và vì làm theo lô nên tổng thời gian còn dài hơn. Đề hỏi cả hai mục tiêu.

• E (dùng "all at once") — đây là kiểu triển khai nhanh nhất nhưng có PHÚT CHẾT: toàn bộ fleet được cập nhật cùng lúc, dịch vụ gián đoạn. Trái thẳng yêu cầu của đề.

• B (nâng cấp loại instance EC2) — máy mạnh hơn có thể cài nhanh hơn đôi chút, nhưng không giải quyết được vấn đề gốc (vẫn cài lại từ đầu mỗi lần) và cũng không đảm bảo tính sẵn sàng.

Ghi nhớ

⚠ Các kiểu triển khai của Elastic Beanstalk — bảng phải thuộc: | Kiểu | Phút chết | Tốc độ | Quay lui | |---|---|---|---| | All at once | CÓ | nhanh nhất | phải triển khai lại | | Rolling | không | chậm | phải triển khai lại | | Rolling with additional batch | không | chậm nhất | phải triển khai lại | | Immutable | không | chậm | nhanh — chỉ bỏ ASG mới | | Traffic splitting | không | chậm | nhanh — dùng cho canary | | Blue/Green (swap URL) | không | tuỳ | TỨC THÌ — swap ngược |

Từ khoá nhận diện:

"không được gián đoạn + quay lui tức thì" → Blue/Green "triển khai chậm vì cài đặt lâu" → Golden AMI "giảm dung lượng phục vụ trong lúc triển khai" → Rolling (không có additional batch) "giữ nguyên dung lượng" → Rolling with additional batch, hoặc Immutable "thử nghiệm với một phần nhỏ người dùng" → Traffic splitting (canary) "nhanh nhất, chấp nhận gián đoạn" → All at once (chỉ hợp môi trường dev)

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Triển khai mất bao lâu | so mốc thời gian trong event log của môi trường | | Máy mới lên mất bao lâu | thời gian từ Launch tới khi qua health check | | Swap có thật sự tức thì không | TTL của DNS — CNAME swap vẫn phụ thuộc DNS cache của client |

Và một cảnh báo rất quan trọng khi làm blue/green trên Beanstalk: đừng để RDS nằm bên trong môi trường Beanstalk. Khi cơ sở dữ liệu được tạo như một phần của môi trường, việc xoá môi trường cũ sau khi swap sẽ xoá luôn cơ sở dữ liệu đó — hãy tạo RDS như một tài nguyên độc lập bên ngoài và chỉ truyền chuỗi kết nối vào qua biến môi trường.

Đáp án

C — ASG sẽ thay instance không khoẻ bằng một instance khoẻ.

Vì sao đúng

Đây là hành vi cốt lõi và cũng là lý do tồn tại của Auto Scaling Group: giữ đủ số máy KHOẺ, không phải giữ đủ số máy.

⚠ Điểm mấu chốt — quy trình thay máy hỏng:

Health check đánh dấu instance là unhealthy
        ↓
    ASG CHẤM DỨT instance đó
        ↓
    Số máy tụt xuống dưới DesiredCapacity
        ↓
    ASG KHỞI CHẠY một instance mới thay thế
        ↓
    → toàn bộ tự động, không cần ai can thiệp

⚠ Ba nguồn health check mà ASG chấp nhận — CHỈ CẦN MỘT nguồn báo hỏng:

Chỉ cần MỘT nguồn báo unhealthy
        ↓
    → ASG thay máy
        ↓
    → KHÔNG cần cả EC2 lẫn ELB cùng báo hỏng

Đây chính là chỗ phương án A hiểu sai.

⚠ Vì sao nên bật ELB health check chứ không chỉ dựa vào EC2:

EC2 status check chỉ biết "máy còn sống"
        ↓
    Ứng dụng treo, cổng 8080 không trả lời
        ↓
    → EC2 check vẫn PASS
    → máy vẫn nhận lưu lượng, người dùng vẫn nhận lỗi
        ↓
ELB health check gọi thẳng /health của ứng dụng
        ↓
    → phát hiện được ứng dụng chết dù máy còn sống

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

• B (instance tự hồi phục được trong grace period, nên ASG chờ hết grace period rồi mới thay) — đây là phương án gần nhất và hiểu sai ý nghĩa của grace period. Health check grace period là khoảng thời gian SAU KHI KHỞI CHẠY mà ASG chưa bắt đầu kiểm tra, để máy mới kịp khởi động và nạp ứng dụng. Nó không phải thời gian chờ một máy đang chạy tự khỏi bệnh — khi máy đã bị đánh dấu unhealthy thì ASG thay ngay.

• A (phải cả EC2 lẫn ELB cùng báo unhealthy) — sai; một nguồn là đủ. Yêu cầu cả hai cùng báo sẽ khiến những lỗi chỉ ở tầng ứng dụng không bao giờ được xử lý.

• D (custom health check thì ASG không tự thay) — sai; set-instance-health với giá trị Unhealthy khiến ASG thay máy y như mọi nguồn khác. Đó chính là mục đích của API này.

Ghi nhớ

⚠ Ba khoảng thời gian của ASG hay bị nhầm — bảng phải thuộc: | Tham số | Nghĩa | |---|---| | Health check grace period | sau khi khởi chạy, chờ bao lâu mới BẮT ĐẦU kiểm tra sức khoẻ | | Instance warm-up | máy mới cần bao lâu mới được tính vào chỉ số co giãn | | Cooldown | sau một hành động co giãn, chờ bao lâu mới làm tiếp |

Từ khoá nhận diện:

"instance bị đánh dấu unhealthy" → ASG chấm dứt và thay máy mới "máy mới vừa lên đã bị giết" → grace period quá ngắn "ứng dụng chết nhưng ASG không thay" → đang dùng EC2 health check, nên bật thêm ELB "muốn bảo trì mà ASG không đụng vào" → enter-standby "máy hỏng nằm lại mãi" → ReplaceUnhealthy hoặc HealthCheck bị tạm ngừng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Vì sao máy bị thay | Activity history của ASG — đọc Cause | | Health check kiểu gì | describe-auto-scaling-groups, xem HealthCheckType | | Ứng dụng có trả lời không | gọi thẳng đường dẫn health check bằng curl từ trong VPC |

Và một dấu hiệu cần nhận ra sớm: nếu ASG thay máy liên tục mà không rõ lý do, hãy nghi grace period trước tiên. Vòng lặp máy-lên-rồi-bị-giết trông rất giống một sự cố nghiêm trọng ở tầng ứng dụng, nhưng nguyên nhân thường chỉ là ứng dụng cần 90 giây để khởi động trong khi ASG bắt đầu chấm điểm nó từ giây thứ 30 — và mỗi vòng lặp lại tốn tiền cho một instance mới.

Đáp án

B — Tạo một RDS Read Replica dành riêng cho đội ETL.

Vì sao đúng

Vấn đề của đề là hai loại tải rất khác nhau đang tranh nhau một cơ sở dữ liệu:

⚠ Điểm mấu chốt — read replica tách hẳn hai loại tải ra hai máy:

ETL chạy trên instance CHÍNH
        ↓
    Quét toàn bảng → chiếm CPU, chiếm I/O, chiếm buffer pool
        ↓
    → truy vấn của người dùng phải xếp hàng
    → website chậm đúng lúc ETL chạy

Tạo read replica riêng cho ETL
        ↓
    ETL quét thoải mái trên replica
        ↓
    → instance chính chỉ phục vụ website
    → hai bên không còn giẫm chân nhau

⚠ Đây là lời giải cho CẢ ngắn hạn lẫn dài hạn như đề yêu cầu:

Ngắn hạn: tạo replica trong vài phút, trỏ ETL sang đó
        ↓
Dài hạn: replica mở rộng độc lập
        - chọn loại instance to hơn nếu ETL nặng thêm
        - thêm replica nữa nếu có thêm đội dùng dữ liệu
        - website hoàn toàn không bị ảnh hưởng

Một chi tiết hay: replica có thể đặt loại instance KHÁC với máy chính — ETL thường cần nhiều bộ nhớ và I/O nhưng không cần chạy 24/7, nên tối ưu riêng được.

Xem thêm câu #11616: cùng công cụ read replica nhưng cho bài toán khác — chia tải đọc của chính website, và ở đó ElastiCache là mảnh ghép thứ hai.

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

• D (nâng cấp loại instance của RDS) — đây là phương án gần nhất và sẽ giúp được một thời gian. Nhưng nó không tách hai loại tải ra: ETL vẫn tranh tài nguyên với website, chỉ là trên một cái máy to hơn. Khi dữ liệu tiếp tục lớn lên, vấn đề quay lại — và lần này bạn đã hết đường nâng cấp dọc.

• A (bật RDS Multi-AZ) — nhầm lẫn kinh điển: Multi-AZ là để SẴN SÀNG CAO, và bản standby KHÔNG phục vụ đọc. Bật nó không giảm được một chút tải nào cho instance chính.

• C (dùng Athena để truy vấn RDS) — Athena không truy vấn RDS được trực tiếp. Athena chạy SQL trên dữ liệu nằm trong S3. (Có thể dùng Athena Federated Query qua một connector Lambda, nhưng nó chậm hơn và không giải quyết vấn đề tải trên RDS.)

Ghi nhớ

⚠ Multi-AZ và Read Replica — bảng phải thuộc: | | Multi-AZ | Read Replica | |---|---|---| | Mục đích | sẵn sàng cao | chia tải đọc | | Sao chép | đồng bộ | bất đồng bộ | | Phục vụ đọc | KHÔNG | CÓ | | Failover | tự động | phải promote thủ công | | Loại instance | giống máy chính | khác được | | Số lượng | 1 standby | tối đa 5 (Aurora: 15) |

Từ khoá nhận diện:

"báo cáo/ETL làm chậm website" → Read Replica riêng "sẵn sàng cao" → Multi-AZ "Athena truy vấn RDS" → SAI, Athena chạy trên S3 "đưa dữ liệu RDS vào hồ dữ liệu" → DMS, hoặc Glue, hoặc RDS export to S3 "báo cáo phân tích quy mô lớn" → Redshift

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Replica trễ bao nhiêu | chỉ số ReplicaLag | | Máy chính đã nhẹ chưa | so CPUUtilization và ReadIOPS trước/sau | | Truy vấn nào nặng nhất | bật Performance Insights — thấy ngay truy vấn tốn tài nguyên |

Và một lời khuyên khi triển khai: hãy kiểm tra đúng chuỗi kết nối mà đội ETL đang dùng, đừng chỉ tạo replica rồi báo họ. Sự cố hay gặp nhất sau bước này là replica được tạo ra, tốn tiền hằng tháng, mà công việc ETL vẫn chạy nguyên trên máy chính vì không ai đổi cấu hình — và vì website vẫn chậm y như cũ, người ta kết luận rằng "read replica không giải quyết được vấn đề".

Đáp án

A, B, D — ba nguyên nhân có thể:

• B — Luật INBOUND của Security Group của cơ sở dữ liệu đã thay đổi.
• D — Luật INBOUND của Network ACL đã thay đổi.
• A — Luật OUTBOUND của Network ACL đã thay đổi.

Vì sao đúng

Câu này kiểm tra khác biệt quan trọng nhất giữa hai lớp lọc mạng của VPC: stateful và stateless.

⚠ Điểm mấu chốt — Security Group có TRẠNG THÁI, Network ACL thì KHÔNG:

SECURITY GROUP (stateful)
        ↓
    Cho phép chiều VÀO → chiều VỀ tự động được phép
        ↓
    → chỉ cần lo luật INBOUND của SG cơ sở dữ liệu
    → luật OUTBOUND của nó KHÔNG ảnh hưởng tới việc trả lời

NETWORK ACL (stateless)
        ↓
    Mỗi chiều xét RIÊNG, không nhớ gì cả
        ↓
    → phải mở CẢ inbound (request đi vào)
      VÀ outbound (trả lời đi ra, qua CỔNG TẠM 1024–65535)
    → thiếu một chiều là kết nối chết

⚠ Ba nguyên nhân của đề, giải thích từng cái:

Nguyên nhân A là thứ khó chẩn đoán nhất trong đời thực: ứng dụng gửi được, cơ sở dữ liệu nhận được và xử lý xong, nhưng gói trả lời bị NACL chặn — triệu chứng hiện ra là timeout, không phải "connection refused".

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

• E (luật OUTBOUND của Security Group đã thay đổi) — đây là phương án gần nhất và là bẫy trung tâm của câu hỏi. Vì Security Group có trạng thái, gói trả lời cho một kết nối đã được chấp nhận luôn được phép đi ra, bất kể luật outbound viết gì. (Luật outbound của SG phía ỨNG DỤNG thì có ảnh hưởng, nhưng mặc định nó cho phép mọi thứ, và phương án không nói rõ là SG nào.)

• F (IP riêng của cơ sở dữ liệu chính đã thay đổi) — ứng dụng nối tới endpoint DNS của RDS, không nối tới IP. Khi failover hay khi IP đổi, RDS tự cập nhật bản ghi DNS — đó chính là điểm mạnh của Multi-AZ.

• C (vừa tạo một read replica) — tạo replica không đụng gì tới khả năng kết nối tới instance chính.

Ghi nhớ

⚠ Security Group và Network ACL — bảng phải thuộc, đây là câu hỏi kinh điển: | | Security Group | Network ACL | |---|---|---| | Gắn vào | ENI (instance) | subnet | | Trạng thái | STATEFUL — nhớ kết nối | STATELESS — xét từng gói | | Luật | chỉ có Allow | có cả Allow và Deny | | Thứ tự | xét tất cả luật | theo số thứ tự, dừng ở luật khớp đầu tiên | | Mặc định | chặn hết vào, cho hết ra | cho hết cả hai chiều | | Chặn một IP cụ thể | KHÔNG làm được | làm được |

Từ khoá nhận diện:

"chặn một địa chỉ IP xấu" → NACL (SG không có luật Deny) "request vào được mà không có phản hồi" → NACL outbound thiếu cổng tạm "connection refused ngay lập tức" → thường là SG hoặc cổng ứng dụng "timeout" → thường là NACL, route table, hoặc SG chặn im lặng "IP của RDS đổi" → không quan trọng, dùng endpoint DNS

⚠ Dải cổng tạm (ephemeral ports) — phải mở ở NACL outbound: | Hệ thống | Dải | |---|---| | Linux | 32768–60999 | | Windows Server 2008+ | 49152–65535 | | NLB / Lambda | 1024–65535 | | Cách an toàn | mở 1024–65535 ở chiều trả lời |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai đã đổi luật | CloudTrail AuthorizeSecurityGroupIngress, ReplaceNetworkAclEntry | | Gói bị chặn ở đâu | VPC Flow Logs — tìm bản ghi REJECT | | Đường đi có thông không | VPC Reachability Analyzer |

Và một lời khuyên cho lần sự cố tiếp theo: hãy chạy VPC Reachability Analyzer trước khi đọc từng luật một bằng mắt. Nó mô phỏng đường đi từ ENI nguồn tới ENI đích và chỉ đích danh thành phần đang chặn — trong khi cách làm thủ công đòi bạn giữ trong đầu cùng lúc hai security group, hai network ACL với hai chiều mỗi cái, và một bảng định tuyến, đúng vào lúc website đang chết và mọi người đang hỏi bao giờ xong.

Đáp án

B — /26.

Vì sao đúng

Bài toán trông đơn giản nhưng có một cái bẫy: AWS lấy mất 5 địa chỉ trong mỗi subnet.

⚠ Điểm mấu chốt — năm địa chỉ AWS giữ lại, không dùng được:

Với subnet 10.0.0.0/24 chẳng hạn:
    10.0.0.0   → địa chỉ mạng
    10.0.0.1   → router của VPC
    10.0.0.2   → DNS của AWS
    10.0.0.3   → dành cho tương lai
    10.0.0.255 → địa chỉ broadcast (AWS không dùng nhưng vẫn giữ)
        ↓
    → LUÔN mất đúng 5 địa chỉ, ở mọi subnet, mọi kích thước

⚠ Tính toán cho đề bài:

/27 → 2^(32-27) = 32 địa chỉ → 32 - 5 = 27 dùng được
        ↓
    27 < 28  → KHÔNG ĐỦ (thiếu đúng một máy!)

/26 → 2^(32-26) = 64 địa chỉ → 64 - 5 = 59 dùng được
        ↓
    59 >= 28 → ĐỦ, và đây là kích thước NHỎ NHẤT thoả mãn

Chính con số 27 này là bẫy: nếu quên 5 địa chỉ dự trữ, người ta sẽ tính /27 cho 32 máy và chọn nhầm.

⚠ Bảng tra nhanh cần thuộc:

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

• D (/27) — đây là phương án gần nhất và là bẫy chính: 32 địa chỉ nghe như thừa cho 28 máy, nhưng sau khi trừ 5 thì chỉ còn 27 — thiếu đúng một địa chỉ.

• A (/28) — chỉ 11 địa chỉ dùng được. Đây cũng là subnet NHỎ NHẤT mà AWS cho phép.

• C (/25) — đủ dùng (123 địa chỉ) nhưng đề hỏi kích thước TỐI THIỂU, mà /26 đã đủ. Cấp quá rộng cũng là lãng phí không gian địa chỉ khi cần chia nhiều subnet.

Ghi nhớ

⚠ Giới hạn CIDR của VPC và subnet — bảng phải thuộc: | Đối tượng | Nhỏ nhất | Lớn nhất | |---|---|---| | VPC | /28 (16 địa chỉ) | /16 (65.536 địa chỉ) | | Subnet | /28 | bằng kích thước VPC | | Địa chỉ AWS giữ | 5 mỗi subnet | luôn luôn |

Từ khoá nhận diện:

"cần N máy trong subnet" → tính N + 5, rồi làm tròn lên luỹ thừa của 2 "subnet nhỏ nhất AWS cho phép" → /28 "VPC lớn nhất" → /16 "đổi kích thước subnet đã tạo" → KHÔNG ĐƯỢC, phải tạo subnet mới "VPC hết địa chỉ" → thêm CIDR phụ (secondary CIDR block)

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Còn bao nhiêu địa chỉ trống | describe-subnets, xem AvailableIpAddressCount | | Ai đang chiếm địa chỉ | describe-network-interfaces lọc theo subnet | | Sắp cạn chưa | đặt cảnh báo — cạn địa chỉ làm ASG không khởi chạy được máy |

Và một lời khuyên rút từ sự cố phổ biến nhất liên quan tới chuyện này: hãy theo dõi AvailableIpAddressCount như một chỉ số vận hành. Subnet cạn địa chỉ không gây lỗi ở đâu cả cho tới đúng lúc bạn cần scale out — khi ấy Auto Scaling group thất bại với một thông báo mơ hồ trong Activity history, thường vào giờ cao điểm, và cách sửa lại là tạo subnet mới rồi cấu hình lại ASG chứ không phải một cú bấm nút.

Đáp án

A — Luật thứ hai cho phép TOÀN BỘ EC2 instance thuộc một security group được SSH vào bastion host.

Vì sao đúng

Manh mối nằm ngay ở dải địa chỉ mà đề nêu: 172.x.x.x là dải IP RIÊNG, tức là các máy đó nằm bên trong VPC, không phải từ internet.

⚠ Điểm mấu chốt — Security Group cho phép tham chiếu một SG khác làm nguồn:

Luật inbound của bastion:
    Luật 1: SSH ← 109.190.217.138/32   (IP của bạn)
    Luật 2: SSH ← sg-0123456789abcdef   ← đây là thủ phạm
        ↓
    Luật 2 nghĩa là: MỌI instance mang SG đó
    đều SSH vào bastion được
        ↓
    Chúng có IP riêng dạng 172.x.x.x → khớp đúng
      những gì thấy trong VPC Flow Logs

⚠ Và điều quan trọng nhất về cách Security Group đánh giá luật:

Security Group xét TẤT CẢ các luật
        ↓
    Chỉ cần MỘT luật cho phép là được vào
        ↓
    → luật hẹp hơn KHÔNG "thắng" luật rộng hơn
    → SG chỉ có Allow, KHÔNG có Deny để phủ quyết

Đây là chỗ rất nhiều người hiểu sai: họ tưởng luật /32 của mình sẽ "giới hạn" quyền truy cập, trong khi thực tế nó chỉ cộng thêm một đường vào bên cạnh những đường đã có.

⚠ Cách sửa:

# Xem toàn bộ luật, đặc biệt là nguồn kiểu SG
aws ec2 describe-security-groups --group-ids sg-bastion \
  --query 'SecurityGroups[0].IpPermissions'

# Gỡ luật cho phép cả một SG
aws ec2 revoke-security-group-ingress --group-id sg-bastion \
  --protocol tcp --port 22 --source-group sg-0123456789abcdef

Và cách làm đúng hơn cả: bỏ hẳn bastion, dùng Session Manager.

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

• C (luật NACL quá mở) — đây là phương án gần nhất vì NACL đúng là lớp lọc thứ hai. Nhưng NACL và SG được xét CÙNG NHAU theo kiểu AND: kể cả NACL mở toang, gói tin vẫn phải qua được Security Group. Nếu SG chỉ có đúng luật /32 thì các máy 172.x.x.x đã bị chặn rồi.

• B (luật IP phải là 109.190.217.138/0) — sai về ký hiệu CIDR: /0 nghĩa là TOÀN BỘ INTERNET (0.0.0.0/0), tức là mở rộng ra chứ không thu hẹp lại. Ký hiệu đúng cho một địa chỉ duy nhất là /32.

• D (có người đang tấn công, dùng Inspector để kiểm tra) — sai cả chẩn đoán lẫn công cụ: lưu lượng đến từ bên trong VPC một cách hợp lệ theo đúng luật đã cấu hình. Và Inspector quét lỗ hổng phần mềm, nó không phân tích lưu lượng mạng.

Ghi nhớ

⚠ Các kiểu nguồn cho một luật Security Group — bảng phải thuộc: | Nguồn | Nghĩa | |---|---| | 0.0.0.0/0 | toàn bộ internet — nguy hiểm với cổng 22 | | 1.2.3.4/32 | đúng một địa chỉ IP | | sg-xxxxxxxx | MỌI instance mang security group đó | | Prefix list | một danh sách dải IP đặt tên, quản lý tập trung |

Từ khoá nhận diện:

"IP 172.x, 10.x, 192.168.x truy cập được" → nguồn là một SG, không phải internet "/0" → toàn bộ internet, LUÔN SAI khi ý định là một IP "luật hẹp giới hạn luật rộng" → SAI, SG chỉ cộng dồn Allow "cần luật Deny" → NACL, SG không có Deny "bỏ hẳn bastion" → Session Manager

⚠ Ba dải IP riêng (RFC 1918) — nhìn thấy là biết ngay lưu lượng nội bộ: | Dải | Kích thước | |---|---| | 10.0.0.0/8 | 16,7 triệu địa chỉ | | 172.16.0.0/12 | 172.16.x tới 172.31.x | | 192.168.0.0/16 | 65.536 địa chỉ |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Toàn bộ luật thật sự là gì | describe-security-groups — đọc JSON, đừng chỉ liếc console | | SG kia đang gắn cho bao nhiêu máy | describe-instances --filters Name=instance.group-id,Values=sg-xxx | | Ai đã thêm luật | CloudTrail AuthorizeSecurityGroupIngress |

Và một thói quen đáng xây dựng: hãy đọc luật security group bằng CLI dưới dạng JSON, đừng chỉ nhìn console. Giao diện hiển thị nguồn kiểu security group bằng một chuỗi ngắn trông rất giống một dòng ghi chú, nên mắt rất dễ lướt qua — và đó chính là cách một luật "mở cho cả một security group" nằm im nhiều tháng trong cấu hình của một bastion host mà mọi người vẫn tin là chỉ mình họ vào được.