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

Đáp án

C — Gắn TAG cho EC2 instance và cho script Lambda bỏ qua việc tắt máy nếu thấy tag đó.

Vì sao đúng

Đây là mẫu thiết kế chuẩn cho mọi thao tác tự động trên hạ tầng: để chính tài nguyên tự mang thông tin về cách nó cần được đối xử.

⚠ Điểm mấu chốt — tag đi cùng tài nguyên, danh sách id thì không:

Gắn tag: KhongTatMay = true
        ↓
    Lambda lọc ngay ở tầng API
        ↓
    → tài nguyên mới tạo chỉ cần gắn tag là được bảo vệ
    → KHÔNG phải sửa mã, KHÔNG phải triển khai lại Lambda

ec2 = boto3.client('ec2')
may = ec2.describe_instances(Filters=[
    {'Name': 'instance-state-name', 'Values': ['running']},
    {'Name': 'tag:KhongTatMay', 'Values': ['true']}])
# ...lấy danh sách id này rồi LOẠI TRỪ khỏi lệnh stop_instances

⚠ Vì sao đây là cách "hiệu quả" như đề yêu cầu:

Việc bảo vệ một máy thuộc về NGƯỜI SỞ HỮU máy đó
        ↓
    Họ tự gắn tag khi tạo máy
        ↓
    → không phải mở ticket nhờ đội hạ tầng
    → không có danh sách trung tâm phải cập nhật
    → không có độ trễ giữa lúc tạo máy và lúc được bảo vệ

⚠ Và tag còn dùng lại được cho nhiều việc khác:

Cùng một tag KhongTatMay
        ↓
    → dùng cho AWS Config kiểm tra
    → dùng cho Patch Manager phân nhóm
    → dùng cho báo cáo chi phí
    → dùng cho SCP chặn thao tác nguy hiểm

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

• D (lưu danh sách id không được tắt vào SSM Parameter Store) — đây là phương án gần nhất và tốt hơn hẳn phương án A: sửa danh sách không cần triển khai lại Lambda. Nhưng nó vẫn là một danh sách trung tâm phải bảo trì bằng tay; máy mới tạo sẽ không được bảo vệ cho tới khi có người nhớ thêm id vào, và id của máy đã bị chấm dứt sẽ nằm lại đó mãi.

• A (dùng biến môi trường của Lambda chứa danh sách máy) — tệ nhất trong ba cách: mỗi lần đổi danh sách là phải cập nhật và triển khai lại hàm Lambda, và biến môi trường cũng có giới hạn kích thước (tổng 4 KB).

• B (đổi shutdown behavior và bật termination protection) — không chặn được: DisableApiTermination chỉ chặn terminate, không chặn stop. Mà Lambda ở đây gọi stop_instances. (Có DisableApiStop chặn được stop, nhưng nó cũng chặn luôn mọi thao tác dừng máy hợp lệ khác, và không nêu trong phương án.)

Ghi nhớ

⚠ Ba cách quản lý danh sách loại trừ — bảng phải thuộc: | Cách | Đánh giá | |---|---| | Tag trên tài nguyên | tốt nhất — thông tin đi cùng tài nguyên | | SSM Parameter Store | khá — sửa không cần triển khai lại, nhưng vẫn là danh sách trung tâm | | Biến môi trường Lambda | kém — mỗi lần đổi phải triển khai lại |

Từ khoá nhận diện:

"loại trừ một số tài nguyên khỏi thao tác tự động" → tag "cấu hình dùng chung cho nhiều hàm" → Parameter Store "bí mật, mật khẩu, tự xoay khoá" → Secrets Manager "chặn terminate" → DisableApiTermination "chặn stop" → DisableApiStop "ASG không được giết máy này" → instance protection hoặc standby

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Máy nào đang được bảo vệ | describe-instances --filters "Name=tag:KhongTatMay,Values=true" | | Lambda có bỏ sót không | ghi log danh sách máy sắp tắt TRƯỚC khi tắt | | Ai đã tắt máy | CloudTrail sự kiện StopInstances |

Và một lời khuyên rất đáng giá cho loại tự động hoá này: hãy cho Lambda chạy ở chế độ "dry run" vài ngày trước khi cho nó tắt máy thật. Chỉ cần ghi ra log danh sách máy mà nó định tắt, rồi gửi cho các đội xem — cách này phát hiện ra những máy thiếu tag khi hậu quả vẫn còn là một dòng log, chứ không phải một ứng dụng sản xuất bị tắt lúc nửa đêm.

Đáp án

A — Thêm tuyến 0.0.0.0/0 trỏ tới NAT Gateway.

Vì sao đúng

Đề cố tình liệt kê bốn loại gateway để xem bạn có phân biệt được chúng không. Chỉ một cái phù hợp với yêu cầu "private subnet ra internet bằng IPv4".

⚠ Điểm mấu chốt — bốn gateway, bốn việc khác nhau:

NAT Gateway              → IPv4, CHỈ RA  ← đáp án
Internet Gateway         → IPv4 + IPv6, HAI CHIỀU
Egress-Only IGW          → CHỈ IPv6, chỉ ra
Virtual Private Gateway  → nối tới mạng TẠI CHỖ, không ra internet

⚠ Vì sao NAT Gateway đúng và IGW sai:

Trỏ private subnet vào NAT Gateway
        ↓
    NAT có IP công cộng, nó thay mặt instance ra internet
        ↓
    → instance RA được, nhưng KHÔNG AI từ internet
      chủ động vào được instance
        ↓
    → subnet vẫn giữ đúng tính chất "private"

Trỏ private subnet thẳng vào Internet Gateway
        ↓
    → subnet đó TRỞ THÀNH public
    → và instance không có IP công cộng thì vẫn không ra được
        ↓
    → vừa phá thiết kế bảo mật, vừa không giải quyết vấn đề

⚠ Kiến trúc đầy đủ, và một chi tiết hay bị quên:

NAT Gateway phải nằm ở PUBLIC subnet
        ↓
    (public subnet của nó phải có tuyến tới IGW)
        ↓
Route table của private subnet:
    0.0.0.0/0 → nat-xxxxxxxx
        ↓
    Muốn sẵn sàng cao thật:
        → một NAT Gateway ở MỖI Availability Zone
        → NAT ở AZ khác chết là subnet đó mất mạng

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

• D (thêm tuyến 0.0.0.0/0 tới Internet Gateway) — đây là phương án gần nhất và là bẫy chính: nó biến private subnet thành public subnet, phá vỡ toàn bộ mục đích của thiết kế hai tầng, mà instance không có IP công cộng thì vẫn không ra được.

• B (tuyến 0.0.0.0/0 tới Egress-Only Internet Gateway) — Egress-Only IGW chỉ hoạt động với IPv6. Đề nói rõ là IPv4. (Với IPv6 thì đây lại chính là câu trả lời đúng — nên nhớ kỹ cặp đôi này.)

• C (tuyến 10.0.0.0/12 tới Virtual Private Gateway) — sai cả hai vế: VGW nối tới mạng tại chỗ qua VPN, không ra internet; và 10.0.0.0/12 là một dải IP riêng, không phải internet.

Ghi nhớ

⚠ Bốn gateway của VPC — bảng phải thuộc: | Gateway | Giao thức | Chiều | Dùng cho | |---|---|---|---| | Internet Gateway | IPv4 + IPv6 | hai chiều | public subnet | | NAT Gateway | IPv4 | chỉ ra | private subnet ra internet | | Egress-Only IGW | chỉ IPv6 | chỉ ra | private subnet dùng IPv6 | | Virtual Private Gateway | — | hai chiều | nối mạng tại chỗ (VPN) | | Carrier Gateway | — | hai chiều | Wavelength / 5G | | Transit Gateway | — | hai chiều | nối nhiều VPC và mạng tại chỗ |

Từ khoá nhận diện:

"private subnet ra internet, IPv4" → NAT Gateway "private subnet ra internet, IPv6" → Egress-Only Internet Gateway "IPv6 cần chặn chiều vào" → Egress-Only IGW (IPv6 không có NAT) "nối trung tâm dữ liệu" → Virtual Private Gateway hoặc Transit Gateway "gọi S3 mà không ra internet" → VPC endpoint (gateway, miễn phí)

⚠ Vì sao IPv6 không có NAT — một câu hỏi hay gặp:

IPv4 dùng NAT vì THIẾU địa chỉ
        ↓
    IPv6 có thừa địa chỉ, mọi thiết bị đều có địa chỉ công cộng
        ↓
    → không cần NAT để tiết kiệm địa chỉ
    → nhưng vẫn cần chặn chiều vào
        ↓
    → đó chính là lý do Egress-Only IGW tồn tại

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Route table đúng chưa | private subnet phải có 0.0.0.0/0 → nat-xxxxx | | NAT có ở public subnet không | subnet của NAT phải có tuyến tới IGW | | Instance ra được chưa | từ trong máy: curl -I https://checkip.amazonaws.com |

Và một lời khuyên tiết kiệm áp dụng được ngay hôm nay: hãy thêm gateway endpoint cho S3 và DynamoDB vào mọi VPC có NAT Gateway. Chúng hoàn toàn miễn phí, cấu hình mất vài phút, và với một fleet thường xuyên đọc ghi S3 thì chúng cắt đi phần lớn khoản phí xử lý dữ liệu của NAT — một khoản tiền mà nhiều đội trả hằng tháng suốt nhiều năm mà không biết rằng nó hoàn toàn tránh được.

Đáp án

C — AWS OpsWorks.

Vì sao đúng

Đề nêu hai ràng buộc rất cụ thể, và OpsWorks là dịch vụ AWS duy nhất trong danh sách thoả mãn cả hai:

⚠ Điểm mấu chốt — OpsWorks quản lý được node NGOÀI AWS:

OpsWorks for Puppet Enterprise
        ↓
    AWS vận hành máy chủ Puppet master
        ↓
    Node đăng ký vào:
        - EC2 instance trên AWS
        - MÁY VẬT LÝ trong trung tâm dữ liệu của bạn  ← điểm mấu chốt
        ↓
    → cùng một bộ module Puppet áp cho cả hai nơi
    → đúng yêu cầu HIPAA phải giữ một phần hạ tầng tại chỗ

⚠ Ba biến thể của OpsWorks — phải phân biệt:

OpsWorks Stacks            → phiên bản riêng của AWS, dùng Chef Solo
OpsWorks for Chef Automate → máy chủ Chef có quản lý
OpsWorks for Puppet Enterprise → máy chủ Puppet có quản lý  ← đề này

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

• A (Ansible) — đây là phương án gần nhất vì Ansible là công cụ quản lý cấu hình thật và rất phổ biến. Nhưng nó không phải một dịch vụ AWS, mà đề hỏi "dịch vụ AWS nào". Ngoài ra CTO đã chốt dùng Puppet, nên đổi sang Ansible là làm lại toàn bộ.

• B (AWS Artifact) — cổng để tải tài liệu tuân thủ của AWS (báo cáo SOC, ISO, PCI, và cả BAA cho HIPAA). Chữ "HIPAA" trong đề khiến nó nghe có lý, nhưng Artifact không quản lý cấu hình máy nào cả.

• D (Amazon GuardDuty) — dịch vụ phát hiện mối đe doạ. Không liên quan tới quản lý cấu hình.

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

AWS OpsWorks đã NGỪNG HOẠT ĐỘNG — AWS công bố kết thúc vòng đời ngày 26/5/2024 cho cả ba biến thể (Stacks, Chef Automate, Puppet Enterprise). Nghĩa là:

Câu hỏi này phản ánh danh mục dịch vụ TRƯỚC tháng 5/2024
        ↓
    Đáp án C vẫn ĐÚNG theo khoá của bộ đề, GIỮ NGUYÊN
        ↓
    Nhưng trong thực tế hiện nay KHÔNG dùng được nữa

Cách làm tương đương ngày nay cho đúng bài toán của đề:

Ghi nhớ

⚠ Các công cụ quản lý cấu hình và vị trí của chúng — bảng phải thuộc: | Công cụ | Là gì | |---|---| | Systems Manager | dịch vụ AWS — quản lý EC2 và máy tại chỗ (hybrid) | | OpsWorks | dịch vụ AWS, ĐÃ NGỪNG 5/2024 — Chef và Puppet có quản lý | | Chef, Puppet, Ansible, Salt | công cụ của bên thứ ba, tự vận hành | | Elastic Beanstalk | nền tảng triển khai ứng dụng, không phải quản lý cấu hình | | CloudFormation | hạ tầng dạng mã, không phải cấu hình bên trong máy |

Từ khoá nhận diện:

"quản lý cả máy tại chỗ lẫn máy AWS" → Systems Manager Hybrid Activations (ngày nay) "dùng lại module Chef/Puppet sẵn có" → OpsWorks (theo đề cũ) "tài liệu tuân thủ, BAA cho HIPAA" → AWS Artifact "hạ tầng dạng mã" → CloudFormation / CDK / Terraform "chỉ cần triển khai ứng dụng" → Elastic Beanstalk

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Máy tại chỗ đã đăng ký chưa | Fleet Manager — tìm node có id mi- | | Cấu hình có được áp không | State Manager association status | | Dịch vụ còn tồn tại không | luôn tra tài liệu AWS trước khi thiết kế theo đề thi cũ |

Và một lời nhắc chung khi ôn bằng ngân hàng đề: danh mục dịch vụ AWS thay đổi liên tục, và các bộ đề luôn chạy sau thực tế. Hãy học nguyên lý mà câu hỏi muốn kiểm tra — ở đây là "quản lý cấu hình thống nhất cho môi trường lai" — chứ đừng học thuộc tên dịch vụ, vì cái tên có thể đã biến mất trước cả ngày bạn đi thi.

Đáp án

C — Tape Gateway.

Vì sao đúng

Đề nêu ba ràng buộc, và Tape Gateway sinh ra để thoả đúng cả ba:

⚠ Điểm mấu chốt — Tape Gateway giả lập một thư viện băng từ thật:

Phần mềm sao lưu (Veeam, NetBackup, Backup Exec...)
        ↓
    Thấy một thư viện băng qua iSCSI:
        - ổ băng (tape drive)
        - băng từ ảo (virtual tape)
        - bộ nạp băng (media changer)
        ↓
    → phần mềm hoạt động Y HỆT như với thư viện băng vật lý
    → KHÔNG phải đổi quy trình, KHÔNG phải đổi phần mềm
        ↓
    Nhưng "băng" thật ra nằm trong S3

⚠ Vòng đời của một băng ảo:

Băng đang ghi / vừa ghi xong
        ↓
    Nằm trong Virtual Tape Library (VTL) — lưu ở S3
    → lấy lại NHANH
        ↓
Phần mềm "eject" (đẩy băng ra)
        ↓
    Băng chuyển sang Virtual Tape Shelf (VTS)
    → lưu ở GLACIER hoặc DEEP ARCHIVE
    → rẻ hơn nhiều, nhưng lấy lại mất hàng giờ
        ↓
Cần đọc lại → "retrieve" băng về VTL rồi mới đọc

Đây chính là mô hình mà các đội vận hành băng từ đã quen: băng trong tủ thì lấy nhanh, băng gửi kho thì lấy chậm — chỉ khác là không còn ai phải lái xe tới kho nữa.

Xem thêm câu #11596 và #11603: cùng họ Storage Gateway nhưng khác giao thức — Volume Gateway cho iSCSI mức khối, File Gateway cho NFS/SMB mức tệp.

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

• B (Volume Gateway) — đây là phương án gần nhất vì nó CŨNG dùng iSCSI, nên rất dễ chọn nhầm. Nhưng Volume Gateway trình ra các ổ đĩa khối, không phải thư viện băng. Phần mềm sao lưu ra băng sẽ không nhận ra nó là thiết bị nó cần.

• A (File Gateway) — trình ra NFS/SMB ở mức tệp. Phần mềm sao lưu ra băng không nói được giao thức đó.

• D (Snowball) — thiết bị di chuyển dữ liệu một lần, không phải cầu nối lâu dài cho một quy trình sao lưu chạy hằng ngày.

Ghi nhớ

⚠ Bốn loại Storage Gateway — bảng phải thuộc: | Loại | Giao thức | Phần mềm nhìn thấy gì | |---|---|---| | Tape Gateway | iSCSI VTL | thư viện băng từ | | Volume Gateway | iSCSI | ổ đĩa khối | | File Gateway (S3) | NFS, SMB | thư mục chia sẻ | | FSx File Gateway | SMB | chia sẻ Windows |

Từ khoá nhận diện:

"phần mềm sao lưu ra băng từ" → Tape Gateway "iSCSI, ổ đĩa" → Volume Gateway "NFS, SMB, chia sẻ tệp" → File Gateway "di chuyển dữ liệu một lần" → Snowball "đồng bộ định kỳ qua mạng" → DataSync "giữ nguyên phần mềm đang dùng" → Storage Gateway (đó là lý do nó tồn tại)

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Băng có được tạo không | console Storage Gateway, mục Tapes | | Băng đã archive chưa | trạng thái ARCHIVED | | Bộ đệm còn chỗ không | chỉ số CachePercentUsed |

Và một lời khuyên khi lập kế hoạch khôi phục: hãy đo thử thời gian lấy một băng từ Deep Archive về, trước khi cần tới nó thật. Deep Archive rẻ tới mức rất hấp dẫn cho băng lưu trữ dài hạn, nhưng 48 giờ chờ đợi có thể vượt xa mục tiêu RTO mà công ty đã cam kết — và đó là con số cần biết trong một buổi diễn tập, chứ không phải trong ngày mất dữ liệu thật.

Đáp án

A — Triển khai bản vá bằng AWS Systems Manager.

Vì sao đúng

Đề mô tả một tình huống khẩn cấp: lỗ hổng đã bị khai thác, bản vá vừa ra, phải áp cho toàn bộ máy càng nhanh càng tốt. Systems Manager có hai công cụ cho đúng việc này.

⚠ Điểm mấu chốt — hai cách vá, tuỳ mức khẩn cấp:

Run Command — vá NGAY LẬP TỨC
        ↓
    aws ssm send-command \
      --document-name "AWS-RunPatchBaseline" \
      --parameters "Operation=Install" \
      --targets "Key=tag:Moi-truong,Values=production"
        ↓
    → chạy đồng thời trên hàng trăm máy, xong trong vài phút

Patch Manager — vá theo LỊCH, có báo cáo tuân thủ
        ↓
    Patch Baseline + Patch Group + Maintenance Window
        ↓
    → cơ chế lâu dài, để lần sau không rơi vào cảnh này nữa

⚠ Vì sao Systems Manager là công cụ đúng cho tình huống khẩn cấp:

Không cần SSH vào từng máy
Không cần mở cổng nào
Không cần biết địa chỉ IP của máy nào
        ↓
    Chọn máy theo TAG, hoặc chọn tất cả
        ↓
    → có kiểm soát tốc độ triển khai (concurrency)
    → có ngưỡng dừng khi lỗi (error threshold)
    → mọi lệnh đều được ghi log

Với một bản vá khẩn cấp, tham số kiểm soát tốc độ rất đáng dùng:

--max-concurrency "10%"   → vá 10% fleet mỗi đợt
--max-errors "5"          → quá 5 máy lỗi thì DỪNG HẲN

Xem thêm câu #11572 và #11610: cùng chủ đề vá lỗi bằng Systems Manager, nhưng bẫy nằm ở chỗ khác — ở đó là phân biệt các capability của SSM và các tên gọi giả như "Patch Fleet".

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

• D (triển khai bằng Amazon Inspector) — đây là phương án gần nhất vì Inspector liên quan trực tiếp tới lỗ hổng. Nhưng nó chỉ PHÁT HIỆN và BÁO CÁO lỗ hổng — nó không cài bản vá nào. Hai dịch vụ bổ sung cho nhau: Inspector chỉ ra vấn đề, Systems Manager sửa.

• B (vá thẳng từ giao diện AWS Config) — AWS Config đánh giá cấu hình có đúng chuẩn không. Nó có cơ chế remediation, nhưng remediation đó gọi sang SSM Automation để thực thi — nghĩa là công cụ vá thật sự vẫn là Systems Manager.

• C (dùng AWS Artifact) — cổng tải tài liệu tuân thủ của AWS. Không thao tác gì lên máy của bạn.

Ghi nhớ

⚠ Bốn dịch vụ, bốn vai trò trong vòng đời một lỗ hổng — bảng phải thuộc: | Dịch vụ | Vai trò | |---|---| | Inspector | PHÁT HIỆN lỗ hổng (CVE) | | Systems Manager | SỬA — cài bản vá | | AWS Config | KIỂM TRA cấu hình có đúng chuẩn không | | Security Hub | TỔNG HỢP mọi phát hiện | | GuardDuty | phát hiện hành vi khai thác đang diễn ra |

Từ khoá nhận diện:

"cài bản vá" → Systems Manager "vá NGAY, khẩn cấp" → Run Command với AWS-RunPatchBaseline "vá theo lịch, có báo cáo tuân thủ" → Patch Manager "tìm lỗ hổng" → Inspector "chứng minh không còn lỗ hổng" → Inspector "Inspector cài bản vá" → LUÔN SAI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Máy nào chưa được quản lý | Fleet Manager — máy vắng mặt là rủi ro lớn nhất | | Lệnh chạy tới đâu | list-command-invocations --details | | Vá xong đã hết lỗ hổng chưa | cho Inspector quét lại để xác nhận |

Và một lời khuyên cho đúng tình huống khẩn cấp của đề: hãy vá một nhóm nhỏ trước rồi mới mở rộng, ngay cả khi đang bị tấn công. Áp lực khiến người ta muốn vá tất cả trong một lệnh, nhưng một bản vá Windows lỗi có thể làm cả fleet không khởi động lại được — và khi ấy bạn vừa có một lỗ hổng, vừa có một sự cố ngừng dịch vụ toàn diện, cùng một lúc.

Đáp án

A — Bật Stickiness trên Application Load Balancer.

Vì sao đúng

Đề dùng đúng thuật ngữ kỹ thuật: "session affinity" — và tên gọi của nó trên AWS là stickiness.

⚠ Điểm mấu chốt — mặc định ALB gửi mỗi request tới một máy bất kỳ:

Không có stickiness
        ↓
    Request 1 → máy A (tạo phiên, lưu trong RAM của A)
    Request 2 → máy B (không biết phiên đó)
        ↓
    → người dùng bị đăng xuất, giỏ hàng trống
    → đúng vấn đề đề nêu

Bật stickiness
        ↓
    ALB gắn một cookie vào phản hồi
        ↓
    Mọi request sau mang cookie đó → về ĐÚNG máy cũ
        ↓
    → trạng thái trong RAM của máy vẫn dùng được

⚠ Hai loại cookie của stickiness trên ALB:

⚠ Nhưng phải biết cái giá của stickiness:

Tải phân bố KHÔNG ĐỀU
        ↓
    Máy nhận nhiều phiên "nặng" sẽ quá tải
    trong khi máy khác nhàn rỗi

Máy chết = phiên MẤT
        ↓
    Người dùng bị đăng xuất dù hệ thống vẫn còn máy khoẻ

Scale in trở nên đau đớn
        ↓
    Gỡ một máy đi là gỡ luôn mọi phiên trên đó

Vì vậy stickiness là giải pháp cho hệ thống hiện có, còn kiến trúc đúng là làm ứng dụng KHÔNG có trạng thái — đẩy phiên ra ElastiCache, DynamoDB, hoặc dùng JWT.

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

• D (bật cookie trên tất cả các target của ALB) — đây là phương án gần nhất vì cookie đúng là cơ chế bên dưới. Nhưng ứng dụng tự đặt cookie không khiến ALB định tuyến theo cookie đó; ALB chỉ tôn trọng cookie khi bạn bật stickiness ở target group (và với application-based stickiness thì phải khai đúng tên cookie).

• C (bật Connection Draining) — tên trên ALB là deregistration delay: cho phép kết nối đang chạy hoàn tất trước khi gỡ một target. Nó giúp lúc triển khai, nhưng không gắn người dùng với một máy nào.

• B (bật header X-Forwarded-For để lưu cookie trên máy chủ) — hiểu sai công dụng: X-Forwarded-For mang địa chỉ IP gốc của client, để ứng dụng ghi log và giới hạn tần suất. Nó không liên quan gì tới cookie hay định tuyến.

Ghi nhớ

⚠ Ba tính năng của ALB hay bị nhầm — bảng phải thuộc: | Tính năng | Việc | |---|---| | Stickiness | gắn một người dùng với một target | | Deregistration delay | chờ kết nối đang chạy xong rồi mới gỡ target | | X-Forwarded-For | truyền IP gốc của client cho ứng dụng | | Slow start | cho target mới nhận tải tăng dần |

Từ khoá nhận diện:

"session affinity", "duy trì trạng thái" → stickiness "triển khai không làm đứt kết nối đang chạy" → deregistration delay "ứng dụng cần biết IP thật của khách" → X-Forwarded-For "kiến trúc đúng cho phiên làm việc" → ElastiCache / DynamoDB, ứng dụng không trạng thái "target mới bị dồn tải ngay" → slow start

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã bật chưa | thuộc tính target group stickiness.enabled | | Cookie có được gắn không | xem header phản hồi, tìm AWSALB | | Tải có bị lệch không | chỉ số RequestCount theo từng target |

Và một lời khuyên về hướng đi dài hạn: hãy coi stickiness là một giải pháp tạm, và ghi vào danh sách kỹ thuật nợ cần trả. Nó cứu được ứng dụng đang có ngay hôm nay, nhưng nó cũng khoá bạn vào một kiến trúc mà mỗi lần triển khai, mỗi lần scale in, và mỗi lần một máy chết đều làm phiền một nhóm người dùng thật — trong khi việc chuyển phiên sang ElastiCache thường chỉ là một thay đổi cấu hình ở tầng framework.

Đáp án

C — Theo dõi SurgeQueueLength và co giãn ASG dựa trên chỉ số đó.

Vì sao đúng

Hai chỉ số trong câu này là hai giai đoạn của cùng một sự cố, và thứ tự giữa chúng là toàn bộ nội dung câu hỏi.

⚠ Điểm mấu chốt — hàng đợi đầy TRƯỚC, mất request SAU:

Backend không kịp xử lý
        ↓
    Load balancer XẾP HÀNG các request chờ
        ↓
    → SurgeQueueLength tăng dần   ← DẤU HIỆU SỚM
        ↓
    Hàng đợi đầy (trần 1.024)
        ↓
    → request mới bị VỨT BỎ
    → SpilloverCount tăng          ← ĐÃ MẤT DỮ LIỆU RỒI

Vì vậy: co giãn theo SpilloverCount là phản ứng sau khi người dùng đã mất request; co giãn theo SurgeQueueLength là phản ứng khi còn kịp.

⚠ Hai con số phải nhớ:

SurgeQueueLength — trần cứng 1.024 request
SpilloverCount   — đếm số request bị vứt bỏ vì hàng đợi đầy
        ↓
    Đặt cảnh báo ở khoảng 100–200 (chứ không phải 1.000)
        ↓
    → có đủ thời gian để máy mới khởi chạy và sẵn sàng

⚠ Và đừng quên: co giãn không phải cách chữa duy nhất:

Hàng đợi dài có thể do:
        - thiếu máy           → co giãn
        - backend quá chậm    → tối ưu ứng dụng, truy vấn
        - cơ sở dữ liệu nghẽn → cache, read replica
        ↓
    Thêm máy vào một hệ thống nghẽn ở tầng dữ liệu
    chỉ làm cơ sở dữ liệu chết nhanh hơn

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

SurgeQueueLength và SpilloverCount là chỉ số của CLASSIC LOAD BALANCER, không tồn tại trên Application Load Balancer. Đề nói chung chung là "AWS load balancer" nhưng một phương án lại nhắc "ALB access logs" — hai vế không nhất quán.

Classic Load Balancer → SurgeQueueLength, SpilloverCount
Application Load Balancer → KHÔNG có hai chỉ số này
        ↓
    Chỉ số tương đương của ALB:
        RejectedConnectionCount  → kết nối bị từ chối
        TargetConnectionErrorCount → lỗi kết nối tới target
        TargetResponseTime         → độ trễ backend

Khoá đáp án vẫn đúng nếu hiểu đây là Classic Load Balancer, và nguyên lý — co giãn theo dấu hiệu sớm chứ không theo hậu quả — vẫn giữ nguyên giá trị với mọi loại load balancer.

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

• A (theo dõi BackendConnectionErrors rồi co giãn theo đó) — đây là phương án gần nhất và cũng là một chỉ số có thật. Nhưng nó đếm lỗi kết nối tới backend (backend từ chối, hết thời gian chờ), không phải hàng đợi đang dài dần — nên nó cũng là dấu hiệu muộn.

• B (pre-warm load balancer) — pre-warm giúp khi lưu lượng tăng đột ngột một lần (sự kiện biết trước). Đề nói vấn đề xảy ra hằng ngày, tức là thiếu dung lượng có hệ thống — pre-warm không giải quyết được.

• D (bật ALB access log rồi co giãn theo CloudWatch Logs) — không co giãn theo log được: Auto Scaling đọc chỉ số CloudWatch, không đọc log. (Có thể dùng metric filter để biến log thành chỉ số, nhưng vòng vo hơn hẳn và trễ hơn.)

Ghi nhớ

⚠ Chỉ số của load balancer theo loại — bảng phải thuộc: | Chỉ số | Loại LB | Ý nghĩa | |---|---|---| | SurgeQueueLength | CLB | request đang xếp hàng — trần 1.024 | | SpilloverCount | CLB | request bị VỨT vì hàng đợi đầy | | RejectedConnectionCount | ALB | kết nối bị từ chối | | TargetResponseTime | ALB | độ trễ backend — chỉ số tốt để co giãn | | RequestCountPerTarget | ALB | chỉ số co giãn được khuyến nghị | | HTTPCode_ELB_5XX_Count | ALB | lỗi phía load balancer |

Từ khoá nhận diện:

"SpilloverCount > 0" → đã mất request, phải co giãn theo SurgeQueueLength "co giãn theo dấu hiệu sớm" → hàng đợi, độ trễ, số request mỗi target "co giãn theo log" → KHÔNG, Auto Scaling dùng chỉ số "lưu lượng tăng đột ngột một lần" → pre-warm "thiếu dung lượng hằng ngày" → co giãn, hoặc scheduled scaling

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

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đang mất bao nhiêu request | tổng SpilloverCount theo ngày | | Hàng đợi dài lúc nào | vẽ SurgeQueueLength cùng biểu đồ lưu lượng | | Nghẽn ở đâu | TargetResponseTime — cao là backend chậm, không phải LB |

Và một nguyên tắc đáng mang theo ra ngoài câu hỏi này: hãy luôn đặt cảnh báo và chính sách co giãn trên chỉ số DẪN DẮT, còn chỉ số HẬU QUẢ thì để làm bằng chứng cho sự cố. SpilloverCount lớn hơn 0 không phải là tín hiệu để bắt đầu hành động — nó là biên lai ghi lại số người dùng bạn vừa làm thất vọng.

Đáp án

D — Đẩy RAMUtilization lên làm chỉ số tuỳ chỉnh bằng script trên EC2, rồi thiết lập chính sách co giãn dựa trên chỉ số đó.

Vì sao đúng

Điểm mấu chốt của câu này là một sự thật mà rất nhiều người mới ngạc nhiên: CloudWatch KHÔNG có chỉ số bộ nhớ cho EC2.

⚠ Vì sao AWS không cấp sẵn chỉ số RAM:

Chỉ số dựng sẵn được đo từ TẦNG HYPERVISOR
        ↓
    Hypervisor thấy: CPU, mạng, I/O đĩa
        ↓
    Hypervisor KHÔNG nhìn được vào BÊN TRONG hệ điều hành khách
        ↓
    → không biết RAM đang dùng bao nhiêu
    → không biết đĩa còn trống bao nhiêu
        ↓
    → muốn biết thì phải có thứ gì đó CHẠY BÊN TRONG máy

⚠ Cách làm chuẩn hiện nay — CloudWatch agent:

{
  "metrics": {
    "append_dimensions": {
      "AutoScalingGroupName": "${aws:AutoScalingGroupName}"
    },
    "metrics_collected": {
      "mem": {"measurement": ["mem_used_percent"]},
      "disk": {"measurement": ["disk_used_percent"]}
    }
  }
}

Chi tiết quan trọng nhất nằm ở append_dimensions: gắn chiều AutoScalingGroupName để CloudWatch tính trung bình trên toàn nhóm — đúng thứ mà chính sách co giãn cần.

Chỉ số CWAgent: mem_used_percent
        + dimension AutoScalingGroupName
        ↓
    Target Tracking Policy: giữ trung bình quanh 70%
        ↓
    → ASG tự thêm/bớt máy theo mức dùng RAM

(Đề nói "custom scripts", đó là cách cũ dùng bộ script Perl của AWS; ngày nay CloudWatch agent là cách được khuyến nghị — nhưng bản chất vẫn giống nhau: một thứ chạy bên trong máy đẩy chỉ số lên.)

Xem thêm câu #11614: cũng về co giãn theo RAM, nhưng ở đó bẫy là phương án "chỉ số RAM của Load Balancer" — thứ không tồn tại.

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

• A (bật detailed monitoring rồi dùng chỉ số RAMUtilization) — đây là phương án gần nhất và là hiểu nhầm phổ biến nhất. Detailed monitoring chỉ tăng độ phân giải từ 5 phút xuống 1 phút cho những chỉ số đã có sẵn; nó không thêm chỉ số mới nào. Và RAMUtilization không tồn tại trong namespace AWS/EC2.

• B (co giãn theo CPUUtilization) — với một cơ sở dữ liệu trong bộ nhớ, CPU và RAM không tương quan: máy có thể gần đầy RAM trong khi CPU vẫn thấp. Co giãn theo CPU sẽ không bao giờ kích hoạt cho tới lúc máy hết bộ nhớ và bị OOM killer giết tiến trình.

• C (đặt sau load balancer để nó theo dõi RAM bằng "smart balancing") — không có tính năng nào tên như vậy. Load balancer chỉ biết về kết nối và phản hồi HTTP, nó không nhìn được vào bên trong instance.

Ghi nhớ

⚠ Chỉ số EC2 có sẵn và phải cài agent — bảng phải thuộc: | Có sẵn (từ hypervisor) | Phải cài CloudWatch agent | |---|---| | CPUUtilization | mem_used_percent (RAM) | | NetworkIn / NetworkOut | disk_used_percent (đĩa còn trống) | | DiskReadBytes / DiskWriteBytes (instance store) | swap_used_percent | | EBSReadOps / EBSWriteOps (Nitro) | chỉ số theo tiến trình | | StatusCheckFailed* | log của ứng dụng |

Từ khoá nhận diện:

"co giãn theo RAM" → CloudWatch agent + chỉ số tuỳ chỉnh "RAMUtilization" trong AWS/EC2 → KHÔNG TỒN TẠI "detailed monitoring cho RAM" → SAI, chỉ tăng độ phân giải "đĩa sắp đầy" → CloudWatch agent "load balancer theo dõi RAM" → KHÔNG TỒN TẠI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chỉ số có lên không | tìm namespace CWAgent trong CloudWatch | | Có đúng dimension chưa | list-metrics --namespace CWAgent — phải thấy AutoScalingGroupName | | Chính sách có kích hoạt không | lịch sử hoạt động của ASG |

Và một lời cảnh báo về chi phí thường bị bỏ qua: hãy cẩn thận với số lượng dimension khi đẩy chỉ số tuỳ chỉnh. Mỗi tổ hợp giá trị dimension là một chỉ số riêng biệt được tính tiền hằng tháng, nên một cấu hình agent gắn thêm InstanceId cho một fleet vài trăm máy hay co giãn liên tục sẽ sinh ra hàng nghìn chỉ số — mỗi cái đều đúng, đều hữu ích, và cộng lại thành một khoản không nhỏ trong hoá đơn CloudWatch.

Đáp án

D — Thử khởi chạy instance ở một Availability Zone khác.

Vì sao đúng

Bẫy của câu này nằm ở việc phân biệt hai lỗi nghe rất giống nhau nhưng nguyên nhân hoàn toàn khác.

⚠ Điểm mấu chốt — hai lỗi, hai nguyên nhân, hai cách chữa:

InsufficientInstanceCapacity
        ↓
    AWS HẾT PHẦN CỨNG loại đó ở AZ đó, ngay lúc này
        ↓
    → vấn đề của AWS, không phải của tài khoản bạn
    → chữa: đổi AZ, đổi loại instance, hoặc chờ

VcpuLimitExceeded / InstanceLimitExceeded
        ↓
    TÀI KHOẢN của bạn đã chạm hạn mức
        ↓
    → chữa: xin tăng hạn mức qua Service Quotas

⚠ Bốn cách xử lý InsufficientInstanceCapacity, theo thứ tự nên thử:

1. Đổi Availability Zone          ← nhanh nhất, thường là đủ
2. Đổi loại instance (m5.large → m5a.large, m6i.large)
3. Chờ vài phút rồi thử lại — dung lượng được giải phóng liên tục
4. Khởi chạy số lượng ÍT HƠN — xin 20 máy thất bại
   nhưng xin 5 máy có thể thành công

⚠ Và cách phòng ngừa cho workload quan trọng:

On-Demand Capacity Reservation
        ↓
    Giữ trước phần cứng ở một AZ cụ thể
        ↓
    → đảm bảo có máy khi cần
    → nhưng KHÔNG có giảm giá, và trả tiền cả khi không dùng

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

• A (xin tăng hạn mức trong AWS Support Console) — đây là phương án gần nhất và là phản xạ đầu tiên của rất nhiều người. Nhưng hạn mức và dung lượng là hai chuyện khác nhau: hạn mức có tăng lên bao nhiêu cũng không tạo ra thêm máy chủ vật lý ở một AZ đang cạn. Lỗi cho vấn đề hạn mức là VcpuLimitExceeded, không phải lỗi này.

• C (dùng Trusted Advisor để tìm nguyên nhân gốc) — Trusted Advisor đưa ra khuyến nghị về chi phí, bảo mật, hiệu năng, hạn mức. Nó không có thông tin gì về dung lượng phần cứng còn trống của AWS — đó là dữ liệu nội bộ của AWS.

• B (chạy Amazon Inspector để xem cái gì đang chiếm dung lượng) — hiểu sai hoàn toàn: Inspector quét lỗ hổng bảo mật. Và "dung lượng" ở đây là phần cứng của AWS, không phải tài nguyên trong máy bạn.

Ghi nhớ

⚠ Các lỗi khởi chạy EC2 hay gặp — bảng phải thuộc: | Lỗi | Nguyên nhân | Cách chữa | |---|---|---| | InsufficientInstanceCapacity | AWS hết phần cứng ở AZ đó | đổi AZ / đổi loại / chờ | | VcpuLimitExceeded | tài khoản chạm hạn mức | Service Quotas | | InstanceLimitExceeded | chạm hạn mức số instance | Service Quotas | | Unsupported | loại instance không có ở AZ đó | đổi AZ hoặc đổi loại | | Client.InternalError | thường là quyền trên KMS key | sửa key policy | | InvalidParameterValue | AMI, subnet, hoặc tham số sai | kiểm tra lại cấu hình |

Từ khoá nhận diện:

"InsufficientInstanceCapacity" → đổi AZ, KHÔNG phải xin tăng hạn mức "VcpuLimitExceeded" → Service Quotas "đảm bảo có máy vào ngày cao điểm" → Capacity Reservation "muốn rẻ, chấp nhận gián đoạn" → Spot (và Spot hay gặp lỗi dung lượng hơn) "Client.InternalError khi khởi chạy" → KMS key policy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lỗi chính xác là gì | Activity history của ASG, đọc StatusMessage | | Loại instance có ở AZ nào | describe-instance-type-offerings --location-type availability-zone | | Hạn mức hiện tại | Service Quotas console |

Và một lời khuyên thiết kế rút ra từ lỗi này: hãy khai nhiều loại instance trong launch template của Auto Scaling group, đừng chỉ một loại. Một ASG bị khoá vào đúng m5.large sẽ đứng hình hoàn toàn khi AZ đó cạn loại máy ấy — trong khi một ASG khai m5.large, m5a.large, m6i.large, m5n.large gần như không bao giờ gặp cảnh không khởi chạy được máy nào.

Đáp án

D — AWS Systems Manager Inventory.

Vì sao đúng

Đề dùng đúng từ khoá của dịch vụ: "thu thập METADATA của instance" để "đối chiếu phần mềm và cấu hình với chính sách của công ty".

⚠ Điểm mấu chốt — Inventory là công cụ KIỂM KÊ:

SSM Inventory thu thập từ mỗi managed node:
        - phần mềm đã cài (tên, phiên bản)
        - bản vá đã áp
        - cấu hình mạng
        - dịch vụ Windows, Windows Role
        - file và thư mục theo mẫu bạn khai
        - registry key (Windows)
        - thông tin instance (AMI, loại máy, hệ điều hành)
        ↓
    → đúng thứ cần để đối chiếu với chính sách phần mềm

⚠ Và nó bao phủ được cả máy tại chỗ — chi tiết quan trọng của đề:

Đề nói: 90% trên AWS, 10% ở trung tâm dữ liệu riêng
        ↓
    SSM Hybrid Activation
        ↓
    Cài SSM Agent lên máy tại chỗ, đăng ký bằng mã kích hoạt
        ↓
    → máy nhận id dạng "mi-" (thay vì "i-")
    → Inventory thu thập từ chúng Y HỆT máy EC2
        ↓
    → MỘT bản kiểm kê cho toàn bộ hạ tầng

⚠ Truy vấn dữ liệu kiểm kê bằng SQL:

Resource Data Sync → đẩy dữ liệu Inventory vào S3
        ↓
    Glue crawler dựng catalog
        ↓
    Athena truy vấn:
        "máy nào còn cài phần mềm không được duyệt"
        "máy nào chạy phiên bản OpenSSL cũ"
        ↓
    → đúng bài toán tuân thủ chính sách phần mềm của đề

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

• C (Systems Manager Patch Manager) — đây là phương án gần nhất và cùng họ Systems Manager. Nhưng Patch Manager chỉ lo bản vá: cài bản vá và báo cáo tuân thủ vá. Đề hỏi về toàn bộ phần mềm và cấu hình, rộng hơn nhiều — đó là địa hạt của Inventory.

• B (Unified CloudWatch Agent) — thu thập chỉ số và log: CPU, RAM, đĩa, tệp log. Nó không kiểm kê danh sách phần mềm đã cài.

• A (AWS Batch) — dịch vụ chạy công việc tính toán theo lô. Không liên quan gì tới kiểm kê hay tuân thủ.

Ghi nhớ

⚠ Các capability của Systems Manager — bảng phải thuộc: | Capability | Việc | |---|---| | Inventory | kiểm kê phần mềm và cấu hình | | Patch Manager | vá và báo cáo tuân thủ bản vá | | State Manager | giữ máy ở đúng trạng thái mong muốn | | Compliance | tổng hợp tuân thủ của Patch + State Manager | | Run Command | chạy lệnh một lần | | Automation | runbook nhiều bước | | Session Manager | shell không cần SSH | | Fleet Manager | xem và quản lý máy qua giao diện | | Parameter Store | lưu cấu hình và bí mật |

Từ khoá nhận diện:

"kiểm kê phần mềm đã cài" → SSM Inventory "vá lỗi" → Patch Manager "giữ cấu hình luôn đúng" → State Manager "quản lý cả máy tại chỗ" → SSM Hybrid Activation "cấu hình TÀI NGUYÊN AWS có đúng chuẩn không" → AWS Config "lỗ hổng CVE" → Inspector

⚠ SSM Inventory và AWS Config — ranh giới hay bị nhầm: | | SSM Inventory | AWS Config | |---|---|---| | Nhìn vào | BÊN TRONG máy — phần mềm, registry, tệp | cấu hình TÀI NGUYÊN AWS — SG, bucket, volume | | Máy tại chỗ | có (hybrid) | không | | Lịch sử thay đổi | có (qua Resource Data Sync) | có, rất mạnh — Config timeline | | Tự sửa | qua State Manager / Automation | remediation action |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Máy nào đang được kiểm kê | Fleet Manager — đếm cả node mi- lẫn i- | | Dữ liệu thu thập lúc nào | Inventory chạy theo association của State Manager | | Máy tại chỗ đã đăng ký chưa | describe-instance-information, tìm id bắt đầu bằng mi- |

Và một lời nhắc quen thuộc nhưng luôn đúng: máy vắng mặt trong Inventory nguy hiểm hơn máy vi phạm chính sách. Báo cáo tuân thủ chỉ nói về những gì nó nhìn thấy được, nên một máy thiếu SSM Agent sẽ hiện ra dưới dạng… không hiện ra gì cả — hãy luôn đối chiếu số node được kiểm kê với số máy thật sự đang chạy, ở cả AWS lẫn trung tâm dữ liệu.