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

Đáp án

B — DỪNG gateway, khởi động lại máy ảo, rồi KHỞI ĐỘNG LẠI gateway.

Vì sao đúng

Thứ tự này bảo đảm gateway kết thúc mọi thao tác đang dở trước khi máy ảo tắt đi.

⚠ Điểm mấu chốt — dừng gateway là một thao tác có ý nghĩa, không phải chỉ tắt máy:

Dừng gateway (từ console hoặc API)
        ↓
    Gateway:
        - hoàn tất việc đẩy dữ liệu đang chờ lên AWS
        - ghi xong trạng thái nội bộ lên đĩa
        - đóng kết nối một cách sạch sẽ
        ↓
    → tới lúc này máy ảo mới an toàn để khởi động lại
        ↓
Khởi động lại máy ảo
        ↓
Khởi động lại gateway
        ↓
    → gateway kết nối lại với AWS, đồng bộ trạng thái

⚠ Vì sao KHÔNG được khởi động lại máy ảo trực tiếp:

Tắt máy ảo khi gateway đang chạy
        ↓
    Dữ liệu trong upload buffer chưa đẩy hết lên AWS
    Trạng thái nội bộ chưa ghi xong
        ↓
    → có thể MẤT dữ liệu chưa đồng bộ
    → có thể hỏng trạng thái nội bộ của gateway
        ↓
    → trong trường hợp xấu, gateway không khởi động lại được

⚠ Và đây là danh sách những việc AWS khuyến cáo KHÔNG làm với gateway VM:

KHÔNG khôi phục gateway từ snapshot của hypervisor
        ↓
    → trạng thái lệch với AWS → hỏng dữ liệu

KHÔNG gỡ đĩa cache hoặc upload buffer
        ↓
    → làm hỏng gateway vĩnh viễn

KHÔNG sao chép (clone) gateway VM
        ↓
    → hai gateway cùng danh tính → xung đột

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

• D (khởi động lại gateway, rồi khởi động lại máy ảo) — đây là phương án gần nhất và thứ tự gần đúng, nhưng "khởi động lại gateway" rồi lại khởi động lại máy ảo là thừa và sai trình tự: gateway vừa lên xong lại bị ngắt đột ngột khi máy ảo tắt.

• A (đồng bộ gateway rồi khởi động lại máy ảo) — không có thao tác "synchronize gateway" nào trong Storage Gateway, và bỏ qua bước dừng gateway.

• C (dừng máy ảo, khởi động lại gateway, rồi bật máy ảo) — thứ tự vô lý về mặt logic: máy ảo đã tắt thì gateway chạy ở đâu để mà khởi động lại.

Ghi nhớ

⚠ Quy trình bảo trì gateway — bảng phải thuộc: | Việc cần làm | Trình tự | |---|---| | Khởi động lại máy ảo | dừng gateway → reboot VM → khởi động gateway | | Nâng cấp phần mềm gateway | AWS tự cập nhật trong maintenance window | | Thêm đĩa cache | thêm đĩa vào VM → cấu hình trong console | | Bớt đĩa cache | KHÔNG ĐƯỢC — phải tạo gateway mới | | Di chuyển gateway | dựng gateway mới, chuyển client sang |

Từ khoá nhận diện:

"khởi động lại VM chạy gateway" → dừng gateway trước "khôi phục gateway từ snapshot hypervisor" → AWS KHUYẾN CÁO KHÔNG "giảm dung lượng cache" → tạo gateway mới "gateway hỏng" → dựng gateway mới, khôi phục volume từ snapshot "ghi thẳng vào bucket" → phải chạy RefreshCache

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Còn dữ liệu chưa đẩy lên không | UploadBufferPercentUsed trước khi dừng | | Gateway đã dừng hẳn chưa | trạng thái trong console Storage Gateway | | Sau khi khởi động lại | kiểm tra client mount lại được và dữ liệu đầy đủ |

Và một thói quen nên có trước mọi lần bảo trì gateway: chờ cho UploadBufferPercentUsed về gần 0 rồi mới dừng gateway. Dừng gateway sẽ hoàn tất các thao tác đang dở, nhưng nếu upload buffer đang đầy thì quá trình đó có thể kéo dài rất lâu — và biết trước điều này giúp bạn ước lượng đúng cửa sổ bảo trì thay vì ngồi chờ trong lo lắng.

Đáp án

C — Dùng các security check của AWS Trusted Advisor để rà soát cấu hình của tài khoản gốc.

Vì sao đúng

Trusted Advisor có sẵn những kiểm tra chuyên biệt cho tài khoản gốc, và chúng miễn phí.

⚠ Điểm mấu chốt — Trusted Advisor rà đúng những gì đề cần:

Nhóm kiểm tra Security của Trusted Advisor:
        ↓
    "Root Account MFA"
        → tài khoản gốc đã bật MFA chưa
    "IAM Access Key Rotation"
        → khoá nào quá cũ, kể cả khoá của root
    "IAM Use"
        → có đang dùng IAM user thay vì root không
        ↓
    → ba kiểm tra này NẰM TRONG NHÓM MIỄN PHÍ
    → có ở MỌI mức hỗ trợ, kể cả Basic

⚠ Và hai điều quan trọng nhất về root mà kiểm tra này soi:

Root PHẢI bật MFA
        ↓
    → ưu tiên FIDO security key (chống lừa đảo tốt nhất)
    → AWS cho đăng ký tối đa 8 thiết bị MFA cho một danh tính

Root KHÔNG NÊN có access key
        ↓
    → nếu có thì XOÁ NGAY
    → root không bao giờ cần gọi API

⚠ Ngoài Trusted Advisor còn hai công cụ nữa nên dùng cùng lúc:

IAM Credential Report
        ↓
    Tệp CSV liệt kê MỌI danh tính, gồm cả root:
        - có MFA chưa
        - access key tạo bao giờ, dùng lần cuối khi nào
        - mật khẩu đổi lần cuối khi nào
        ↓
    → miễn phí, tạo trong vài giây

Cảnh báo khi root ĐĂNG NHẬP
        ↓
    EventBridge bắt sự kiện CloudTrail ConsoleLogin
    với userIdentity.type = "Root"
        ↓
    → root chỉ nên dùng vài lần trong đời một tài khoản
    → mỗi lần xuất hiện đều đáng để có người xác nhận

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

• D (chạy báo cáo định kỳ bằng AWS Artifact để xác minh đạt chuẩn bảo mật) — đây là phương án gần nhất vì Artifact đúng là dịch vụ về tuân thủ. Nhưng nó chỉ cho tài liệu chứng nhận CỦA AWS (ISO, SOC, PCI); nó không rà soát cấu hình tài khoản của bạn chút nào.

• A (dùng CLI để xoay access key và secret key của root định kỳ) — trái thực hành tốt: root không nên có access key nào cả. Xoay chúng nghĩa là bạn đang duy trì một thứ lẽ ra phải xoá.

• B (đổi mật khẩu root bằng CLI thường xuyên) — không làm được: mật khẩu đăng nhập console không đổi được qua CLI. Và đổi mật khẩu định kỳ không còn là khuyến nghị bảo mật hiện đại — MFA quan trọng hơn nhiều.

Ghi nhớ

⚠ Thực hành tốt với tài khoản gốc — bảng phải thuộc: | Việc | Nội dung | |---|---| | Bật MFA | bắt buộc — ưu tiên FIDO security key | | XOÁ access key của root | root không bao giờ cần gọi API | | Không dùng root cho việc hằng ngày | dùng IAM Identity Center | | Bảo vệ email của root | đó là đường khôi phục mật khẩu | | Cảnh báo khi root đăng nhập | EventBridge + CloudTrail | | Lưu thông tin root an toàn | két sắt hoặc password manager của tổ chức |

Từ khoá nhận diện:

"kiểm tra cấu hình bảo mật tài khoản" → Trusted Advisor security checks "báo cáo chi tiết mọi danh tính" → IAM Credential Report "tài liệu chứng nhận CỦA AWS" → AWS Artifact "quyền nào đang thừa" → IAM Access Advisor / Access Analyzer "cấu hình tài nguyên có đúng chuẩn không" → AWS Config + Security Hub

⚠ Năm nhóm kiểm tra của Trusted Advisor — bảng phải thuộc: | Nhóm | Nội dung | |---|---| | Cost Optimization | tài nguyên nhàn rỗi, RI chưa dùng hết | | Performance | cấu hình hạn chế hiệu năng | | Security | root MFA, khoá cũ, cổng mở, bucket công khai | | Fault Tolerance | thiếu dư thừa, thiếu sao lưu | | Service Limits | sắp chạm hạn mức | | Mức hỗ trợ | vài check miễn phí ở mọi mức; đủ bộ cần Business trở lên |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Root đã bật MFA chưa | Trusted Advisor hoặc Credential Report | | Root có access key không | Credential Report, cột access_key_1_active — có thì xoá ngay | | Root có đăng nhập gần đây không | CloudTrail, lọc userIdentity.type = Root |

Và một biện pháp nên dựng ngay trong mọi tài khoản AWS: cảnh báo EventBridge cho mỗi lần tài khoản gốc đăng nhập. Root chỉ nên được dùng vài lần trong cả vòng đời một tài khoản — nên mỗi lần nó xuất hiện trong CloudTrail đều đáng để có người nhìn thấy và xác nhận rằng đó là việc có kế hoạch. Đây là một trong những tín hiệu cảnh báo sớm rẻ nhất và hiệu quả nhất mà bạn có thể có.

Đáp án

D — Sửa template CloudFormation để dùng AutoScalingReplacingUpdate policy, cập nhật stack, rồi thực hiện lần cập nhật thứ hai với bản phát hành mới.

Vì sao đúng

Đề nêu hai ràng buộc, và AutoScalingReplacingUpdate thoả cả hai:

⚠ Điểm mấu chốt — AutoScalingReplacingUpdate tạo ASG MỚI song song:

NhomMayChu:
  Type: AWS::AutoScaling::AutoScalingGroup
  UpdatePolicy:
    AutoScalingReplacingUpdate:
      WillReplace: true
  CreationPolicy:
    ResourceSignal:
      Count: 2
      Timeout: PT15M

Cập nhật stack
        ↓
    CloudFormation tạo một ASG HOÀN TOÀN MỚI
        ↓
    Chờ đủ số instance gửi tín hiệu thành công
        ↓
    THÀNH CÔNG → xoá ASG CŨ, giữ ASG mới
    THẤT BẠI  → XOÁ ASG MỚI, GIỮ NGUYÊN ASG CŨ  ← quay lui
        ↓
    → ALB không đổi → DNS không đổi
    → quay lui tự động và sạch sẽ

⚠ So sánh với AutoScalingRollingUpdate — khác biệt quyết định:

AutoScalingRollingUpdate
        ↓
    Cập nhật instance TRONG CHÍNH ASG hiện tại, theo từng lô
        ↓
    → hỏng giữa chừng thì ASG ở trạng thái HỖN HỢP
    → quay lui phải triển khai lại

AutoScalingReplacingUpdate
        ↓
    Tạo ASG MỚI hoàn toàn
        ↓
    → hỏng thì BỎ ASG mới đi, ASG cũ chưa hề bị đụng
    → quay lui TỨC THÌ và AN TOÀN

⚠ Và vì sao đề nói "cập nhật lần thứ hai":

Lần cập nhật thứ nhất
        ↓
    Chỉ THÊM UpdatePolicy vào template
    (bản thân nó không thay đổi ứng dụng)
        ↓
Lần cập nhật thứ hai
        ↓
    Đưa phiên bản ứng dụng mới vào
        ↓
    → lúc này UpdatePolicy mới phát huy tác dụng

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

• C (triển khai stack CloudFormation thứ hai, chờ ứng dụng sẵn sàng, rồi chuyển sang ALB mới) — đây là phương án gần nhất và là mô hình blue/green đúng nghĩa, có quay lui tốt. Nhưng nó tạo ra một ALB MỚI, nghĩa là phải đổi DNS để chuyển lưu lượng — trái thẳng ràng buộc "tránh thay đổi DNS".

• B (tạo AMI mới, tạo launch configuration mới, cập nhật ASG dùng launch configuration đó) — cập nhật tại chỗ, không có cơ chế quay lui tự động; hỏng thì phải tự sửa. (Ngoài ra launch configuration là công nghệ cũ — AWS đã ngừng cho tạo mới và khuyến nghị dùng launch template.)

• A (dùng lifecycle hook, triển khai instance mới, hoàn tất hook khi khoẻ) — lifecycle hook chỉ tạm dừng vòng đời instance để chạy việc gì đó (gom log, đăng ký dịch vụ). Nó không phải cơ chế triển khai phiên bản và không có quay lui.

Ghi nhớ

⚠ Ba UpdatePolicy cho Auto Scaling group — bảng phải thuộc: | Policy | Cách hoạt động | Quay lui | |---|---|---| | AutoScalingRollingUpdate | cập nhật từng lô trong ASG hiện tại | phải triển khai lại | | AutoScalingReplacingUpdate | tạo ASG MỚI, bỏ cái cũ khi thành công | tự động, an toàn | | AutoScalingScheduledAction | giữ nguyên desired capacity khi có scheduled action | — |

Từ khoá nhận diện:

"không đổi DNS + có quay lui" → AutoScalingReplacingUpdate "cập nhật từng lô, giữ dung lượng" → AutoScalingRollingUpdate với MinInstancesInService "blue/green với ALB mới" → đổi DNS — trái ràng buộc của đề này "chạy việc gì đó trước khi máy bị chấm dứt" → lifecycle hook "thay cả fleet, không dùng CloudFormation" → ASG Instance Refresh

⚠ Launch configuration đã lỗi thời — dùng launch template:

Launch configuration (cũ)
        ↓
    Không sửa được — mỗi lần đổi phải TẠO MỚI
    Không có phiên bản
    Không hỗ trợ nhiều tính năng mới (mixed instances, T2 unlimited,
    metadata v2 nâng cao, placement group…)
        ↓
Launch template (mới)
        ↓
    → CÓ PHIÊN BẢN — dễ quay lui
    → hỗ trợ mixed instances policy (nhiều loại máy, Spot + On-Demand)
    → AWS đã ngừng cho tạo launch configuration mới

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cập nhật đang ở đâu | tab Events của stack | | Instance mới có gửi tín hiệu không | cfn-signal — xem /var/log/cfn-init.log | | ASG cũ đã bị xoá chưa | describe-auto-scaling-groups sau khi cập nhật xong |

Và một chi tiết quyết định thành bại của AutoScalingReplacingUpdate: hãy kết hợp nó với CreationPolicy và cfn-signal. Không có tín hiệu, CloudFormation sẽ coi ASG mới là "thành công" ngay khi instance được khởi chạy — kể cả khi ứng dụng bên trong chưa lên hoặc đã lỗi — rồi xoá ASG cũ đi, và bạn mất luôn khả năng quay lui mà cơ chế này vốn sinh ra để cung cấp.

Đáp án

C — Dùng AWS Cost Explorer để sinh khuyến nghị tối ưu tài nguyên (resource optimization recommendations).

Vì sao đúng

Đề nhấn mạnh "CÔNG SỨC TỐI THIỂU", và Cost Explorer có sẵn một báo cáo làm đúng việc này.

⚠ Điểm mấu chốt — báo cáo dựng sẵn, không cần phân tích gì:

Cost Explorer → Rightsizing recommendations
        ↓
    AWS phân tích chỉ số CloudWatch của mọi instance
    trong 14 ngày gần nhất
        ↓
    Xuất ra danh sách:
        - instance nào đang NHÀN RỖI (idle)
        - instance nào nên GIẢM CỠ (downsize)
        - loại instance đề xuất thay thế
        - SỐ TIỀN TIẾT KIỆM ĐƯỢC mỗi tháng
        ↓
    → bật một công tắc, đọc kết quả
    → không viết mã, không dựng gì

⚠ Và AWS Compute Optimizer còn đi xa hơn — nên biết cả hai:

Cost Explorer rightsizing
        ↓
    Dựa trên CPU và mạng
    Tập trung vào TIẾT KIỆM CHI PHÍ

AWS Compute Optimizer
        ↓
    Dùng HỌC MÁY, phân tích sâu hơn
    Nếu cài CloudWatch agent thì xét cả BỘ NHỚ
        ↓
    → khuyến nghị cho EC2, ASG, EBS, Lambda, ECS on Fargate, RDS
    → phân loại: Over-provisioned, Under-provisioned, Optimized
    → MIỄN PHÍ

⚠ Một lưu ý quan trọng khi đọc khuyến nghị:

Khuyến nghị chỉ dựa trên chỉ số CÓ SẴN
        ↓
    Mặc định KHÔNG có dữ liệu BỘ NHỚ
        ↓
    → một instance CPU thấp nhưng RAM gần đầy
      vẫn bị đề xuất giảm cỡ
        ↓
    → cài CloudWatch agent để khuyến nghị chính xác hơn

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

• A (dùng chỉ số CloudWatch để tìm instance dùng ít tài nguyên) — đây là phương án gần nhất và là nền tảng mà chính Cost Explorer dùng bên dưới. Nhưng làm thủ công nghĩa là: tự truy vấn từng instance, tự đặt ngưỡng, tự tra bảng giá, tự tính tiết kiệm. Trái ràng buộc "công sức tối thiểu".

• B (dùng AWS Budgets để sinh cảnh báo cho instance dùng ít tài nguyên) — hiểu sai công dụng: Budgets đặt ngưỡng NGÂN SÁCH và cảnh báo khi sắp vượt. Nó không phân tích mức sử dụng tài nguyên.

• D (chạy Lambda kiểm tra mức sử dụng của instance) — tự viết lại thứ AWS đã cung cấp miễn phí, cộng thêm mã phải bảo trì.

Ghi nhớ

⚠ Bộ công cụ tối ưu chi phí — bảng phải thuộc: | Công cụ | Việc | |---|---| | Cost Explorer | phân tích chi phí + khuyến nghị rightsizing | | AWS Compute Optimizer | khuyến nghị bằng học máy — EC2, ASG, EBS, Lambda, RDS | | AWS Budgets | đặt ngân sách và cảnh báo | | Cost Anomaly Detection | phát hiện chi phí tăng bất thường | | Trusted Advisor | check "Low Utilization EC2 Instances" | | Cost and Usage Report | dữ liệu thô chi tiết nhất |

Từ khoá nhận diện:

"giảm cỡ instance, ít công sức nhất" → Cost Explorer rightsizing hoặc Compute Optimizer "cảnh báo khi vượt ngân sách" → Budgets "chi phí theo phòng ban" → cost allocation tag + Cost Explorer "chi phí tự nhiên tăng vọt" → Cost Anomaly Detection "khuyến nghị cho EBS, Lambda, RDS" → Compute Optimizer

⚠ Bảy cách giảm chi phí EC2 — bảng đáng thuộc: | Cách | Nội dung | |---|---| | Rightsizing | giảm cỡ instance dùng ít — câu này | | Savings Plans / RI | giảm tới 72% cho tải ổn định | | Spot | giảm tới 90% cho tải chịu được gián đoạn | | Graviton (arm64) | hiệu năng trên giá tốt hơn tới 40% | | Tắt máy ngoài giờ | dev/test không cần chạy 24/7 | | Xoá tài nguyên mồ côi | EBS chưa gắn, Elastic IP rảnh, snapshot cũ | | Thế hệ instance mới hơn | thường rẻ hơn và nhanh hơn cùng lúc |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có khuyến nghị nào không | Cost Explorer → Rightsizing recommendations (phải bật trong Preferences) | | Khuyến nghị chi tiết hơn | Compute Optimizer dashboard | | Đã tiết kiệm được bao nhiêu | so chi phí trước và sau trong Cost Explorer |

Và một lời khuyên trước khi làm theo khuyến nghị giảm cỡ: hãy cài CloudWatch agent để có dữ liệu bộ nhớ trước đã. Cả Cost Explorer lẫn Compute Optimizer mặc định chỉ nhìn thấy CPU và mạng — nên một cơ sở dữ liệu trong bộ nhớ hay một JVM cấu hình heap lớn sẽ hiện ra như "dùng ít tài nguyên" và bị đề xuất giảm cỡ, cho tới ngày nó hết RAM và bị OOM killer giết giữa giờ cao điểm.

Đáp án

D — Stop/start instance ngoài giờ làm việc để chuyển sang một host mới TRƯỚC thời điểm retirement đã lên lịch.

Vì sao đúng

Chìa khoá nằm ở một sự thật về EC2: stop rồi start làm instance chuyển sang một máy chủ vật lý KHÁC.

⚠ Điểm mấu chốt — stop/start khác hẳn reboot:

REBOOT
        ↓
    Instance khởi động lại trên CÙNG host vật lý
        ↓
    → vẫn nằm trên máy chủ đang xuống cấp
    → KHÔNG giải quyết được gì

STOP rồi START
        ↓
    Instance được đặt lên một HOST VẬT LÝ KHÁC
        ↓
    → thoát khỏi máy chủ sắp bị retire
    → và bạn CHỦ ĐỘNG chọn thời điểm, ngoài giờ làm việc

⚠ Cái gì giữ, cái gì mất khi stop/start — phải biết trước khi làm:

GIỮ:
    Instance ID
    IP riêng (private IPv4)
    Elastic IP (nếu đã gắn)
    IPv6
    Dữ liệu trên EBS
        ↓
MẤT:
    IP công cộng TỰ ĐỘNG (auto-assigned)  ← đổi địa chỉ mới
    Dữ liệu trên instance store
    RAM

⚠ Và điều quan trọng nhất về mặt vận hành:

Nếu KHÔNG làm gì
        ↓
    AWS sẽ tự stop hoặc terminate instance
    vào ĐÚNG thời điểm retirement đã báo
        ↓
    → giữa giờ làm việc, đúng lúc bận nhất
        ↓
Chủ động stop/start ngoài giờ
        ↓
    → bạn kiểm soát thời điểm gián đoạn
    → thông báo retirement được huỷ bỏ

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

• A (khởi động lại instance ngoài giờ để bảo trì hệ thống trước thời điểm retirement) — đây là phương án gần nhất và đúng ở vế "ngoài giờ". Nhưng reboot giữ nguyên host vật lý, nên instance vẫn nằm trên máy chủ sắp bị retire và thông báo vẫn còn hiệu lực.

• C (khởi động lại instance ngay lập tức) — sai cả hai vế: reboot không đổi host, và làm ngay lập tức nghĩa là gián đoạn trong giờ làm việc — trái yêu cầu "giảm thiểu gián đoạn".

• B (viết Lambda để di chuyển instance giữa các host) — không có API nào cho phép di chuyển instance giữa host. Cơ chế duy nhất chính là stop/start.

Ghi nhớ

⚠ Reboot, Stop/Start, Terminate — bảng phải thuộc: | Thao tác | Host vật lý | Instance store | IP công cộng tự động | Tính tiền | |---|---|---|---|---| | Reboot | GIỮ NGUYÊN | giữ | giữ | vẫn tính | | Stop/Start | ĐỔI host | MẤT | MẤT | chỉ trả tiền EBS khi dừng | | Hibernate | đổi host | mất | mất | lưu RAM xuống ổ gốc | | Terminate | — | mất | mất | ngừng hẳn |

Từ khoá nhận diện:

"instance trên host xuống cấp / sắp retire" → stop/start "reboot đổi host" → LUÔN SAI "giữ nguyên địa chỉ khi stop/start" → Elastic IP "lỗi phần cứng host (StatusCheckFailed_System)" → auto recovery hoặc stop/start "lỗi hệ điều hành (StatusCheckFailed_Instance)" → sửa trong máy, hoặc EC2Rescue

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Instance nào sắp bị retire | Personal Health Dashboard, hoặc describe-instance-status | | Đã chuyển host chưa | sau start, kiểm tra thông báo retirement đã biến mất | | Có mất IP công cộng không | dùng Elastic IP nếu địa chỉ quan trọng |

Và một lời khuyên về hướng đi dài hạn rút ra từ tình huống này: nếu một thông báo retirement khiến bạn phải lên lịch bảo trì ngoài giờ, thì đó là dấu hiệu instance ấy đang là điểm chết đơn. Trong một kiến trúc có Auto Scaling và không giữ trạng thái trên máy, việc AWS thu hồi một host chỉ là chuyện ASG tự thay một instance — không cần ai thức đêm, không cần thông báo cho ai cả.

Đáp án

B — Tạo một Alias record trong hosted zone trỏ tới Application Load Balancer.

Vì sao đúng

Điểm mà câu hỏi kiểm tra: Alias record hoạt động bình thường ngay cả khi ALB nằm ở TÀI KHOẢN KHÁC.

⚠ Điểm mấu chốt — Alias không quan tâm ALB thuộc tài khoản nào:

Hosted zone ở tài khoản A
ALB ở tài khoản B
        ↓
    Tạo Alias record trong hosted zone của A,
    trỏ tới DNS name của ALB ở B
        ↓
    → hoàn toàn hợp lệ
    → không cần chia sẻ tài nguyên, không cần role
    → không cần peering, không cần gì cả
        ↓
    Lý do: DNS name của ALB là thông tin CÔNG KHAI

⚠ Nhưng có một chi tiết vận hành cần biết:

Console Route 53 chỉ GỢI Ý các ALB trong CÙNG tài khoản
        ↓
    → ALB ở tài khoản khác KHÔNG hiện trong danh sách chọn
        ↓
    Cách làm: nhập thủ công bằng CLI hoặc API,
    khai DNS name và HOSTED ZONE ID của ALB
        ↓
    aws route53 change-resource-record-sets ... \
      AliasTarget={HostedZoneId=Z1H1FL5HABSF5,
                   DNSName=ten-alb-123.ap-southeast-1.elb.amazonaws.com,
                   EvaluateTargetHealth=true}

⚠ Và vì sao Alias là lựa chọn TIẾT KIỆM NHẤT như đề yêu cầu:

Alias record
        ↓
    → MIỄN PHÍ truy vấn khi trỏ tới tài nguyên AWS
    → không có hạ tầng phụ nào phải trả tiền

CNAME
        ↓
    → CÓ tính phí truy vấn
    → và không dùng được ở zone apex

Dựng ALB thứ hai để chuyển tiếp
        ↓
    → thêm một ALB phải trả tiền hằng giờ
    → thêm một chặng mạng, thêm độ trễ

Xem thêm câu #11773 và #11677: cùng lựa chọn Alias hay CNAME ở hai tình huống khác — #11773 đích là CloudFront ở zone apex (Alias), #11677 đích là tên miền bên thứ ba (CNAME).

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

• C (tạo CNAME trong hosted zone trỏ tới một alias record của ALB) — đây là phương án gần nhất và rất rối rắm: nó thêm một tầng phân giải thừa, tốn phí truy vấn, và bản thân "alias record của ALB" ở tài khoản kia là thứ bạn không cần tới. Alias trỏ thẳng là đủ.

• D (dựng một ALB trong cùng tài khoản với hosted zone rồi chuyển tiếp chéo tài khoản sang ALB kia) — hoạt động được nhưng đắt và thừa: thêm một ALB tính tiền theo giờ và theo LCU, thêm một chặng mạng, thêm một chỗ có thể hỏng.

• A (tạo bản sao bất đồng bộ của hosted zone ở tài khoản có ALB) — không có cơ chế "replica hosted zone" nào trong Route 53. Hosted zone không nhân bản được như vậy.

Ghi nhớ

⚠ Alias và CNAME — bảng phải thuộc: | | CNAME | Alias | |---|---|---| | Chuẩn | DNS tiêu chuẩn | riêng của Route 53 | | Trỏ tới | bất kỳ tên miền nào | tài nguyên AWS hoặc record cùng zone | | Zone apex | KHÔNG ĐƯỢC | ĐƯỢC | | Chi phí truy vấn | có tính phí | MIỄN PHÍ | | Tài nguyên ở tài khoản khác | được | ĐƯỢC | | Health check | không tự động | EvaluateTargetHealth |

Từ khoá nhận diện:

"trỏ tới ALB/CloudFront/S3 website" → Alias "tài nguyên ở tài khoản khác" → Alias vẫn dùng được "trỏ tên miền GỐC" → Alias (CNAME không được) "trỏ tới tên miền ngoài AWS" → CNAME "tiết kiệm phí truy vấn DNS" → Alias

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Record đã lan chưa | dig ten-mien.com — phải ra IP của ALB | | Hosted zone ID của ELB đúng chưa | tra bảng ELB hosted zone ID theo Region của AWS | | Health check có hoạt động không | tắt thử target của ALB, xem Route 53 phản ứng |

Và một chi tiết dễ khiến người mới bối rối khi làm việc này: ô chọn Alias target trên console chỉ liệt kê tài nguyên trong cùng tài khoản. Rất nhiều người kết luận rằng "Alias không dùng được chéo tài khoản" chỉ vì không thấy ALB của mình trong danh sách — trong khi thực tế nó hoàn toàn dùng được, chỉ là phải nhập DNS name và hosted zone ID bằng CLI thay vì chọn từ menu.

Đáp án

C — Tạo public subnet ở mỗi AZ cho ALB, private subnet ở mỗi AZ cho web server, và private subnet ở mỗi AZ cho database server.

Vì sao đúng

Đây là kiến trúc ba tầng chuẩn trên AWS, và đề nêu đúng hai ràng buộc dẫn tới nó: sẵn sàng cao trên nhiều AZ và hạn chế phơi ra internet tối đa.

⚠ Điểm mấu chốt — chỉ ALB cần ở public subnet:

Internet
        ↓
    ALB  → PUBLIC subnet (nhiều AZ)
        ↓  chỉ ALB có đường vào từ internet
    Web server → PRIVATE subnet
        ↓  không ai từ internet gọi thẳng được
    Database  → PRIVATE subnet
        ↓  chỉ web server gọi tới được

⚠ Vì sao web server KHÔNG cần ở public subnet:

Web server chỉ nhận request TỪ ALB
        ↓
    ALB nằm trong VPC, nói chuyện qua IP RIÊNG
        ↓
    → web server không cần IP công cộng
    → không cần đường vào từ internet
        ↓
    Cần tải bản vá, gọi API bên ngoài?
        ↓
    → NAT Gateway ở public subnet là đủ (chỉ ra, không cho vào)

⚠ Và cấu hình Security Group đi kèm — mẫu chuẩn:

SG của ALB      : inbound 80/443 từ 0.0.0.0/0
SG của web      : inbound cổng ứng dụng từ SG-CỦA-ALB
SG của database : inbound 3306/5432 từ SG-CỦA-WEB
        ↓
    → tham chiếu SG chứ không dùng dải CIDR
    → máy mới của ASG tự động được phép

⚠ Hai yêu cầu bắt buộc để có sẵn sàng cao:

ALB đòi subnet ở ÍT NHẤT HAI AZ
Database (nếu dùng RDS) đòi DB subnet group ở ÍT NHẤT HAI AZ
        ↓
    → mất một AZ, hệ thống vẫn phục vụ

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

• A (ALB public, web server PUBLIC, database private) — đây là phương án gần nhất và hoạt động được, nhưng nó phơi web server ra internet một cách không cần thiết. Đề nói rõ "hạn chế truy cập công khai tối đa", và web server hoàn toàn không cần đường vào từ internet.

• B (ALB public, web PRIVATE, database PUBLIC) — tệ nhất: đặt tầng nhạy cảm nhất ở nơi phơi ra ngoài, trong khi tầng ít nhạy cảm hơn lại được giấu đi. Hoàn toàn ngược với nguyên tắc phòng thủ nhiều lớp.

• D (mọi tầng đều public) — không có lớp bảo vệ nào; mỗi máy chủ đều là một cửa vào tiềm năng.

Ghi nhớ

⚠ Kiến trúc ba tầng chuẩn trên AWS — bảng phải thuộc: | Tầng | Loại subnet | Vì sao | |---|---|---| | Load balancer | public, ≥ 2 AZ | cần nhận lưu lượng từ internet | | Ứng dụng (web) | private | chỉ nhận từ ALB | | Cơ sở dữ liệu | private | chỉ nhận từ tầng ứng dụng | | NAT Gateway | public, mỗi AZ một cái | cho private subnet ra internet |

Từ khoá nhận diện:

"hạn chế truy cập công khai tối đa" → chỉ ALB ở public subnet "private subnet cần tải bản vá" → NAT Gateway "public subnet" → có route 0.0.0.0/0 → IGW "sẵn sàng cao" → ít nhất 2 AZ cho mọi tầng "chỉ ALB gọi được web server" → SG tham chiếu SG

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Subnet nào là public | route table có 0.0.0.0/0 → igw không | | Web server có IP công cộng không | describe-instances — không nên có | | RDS có lộ ra ngoài không | describe-db-instances, xem PubliclyAccessible |

Và một nguyên tắc đáng mang theo cho mọi thiết kế VPC: chỉ đặt vào public subnet những thứ BẮT BUỘC phải nhận kết nối từ internet. Trong thực tế, danh sách đó thường chỉ gồm load balancer, NAT Gateway và (nếu còn dùng) bastion host — mọi thứ khác đều thuộc về private subnet, và mỗi ngoại lệ bạn tạo ra là một cửa vào mà ai đó sẽ phải canh gác.

Đáp án

D — Dùng AWS Systems Manager để vá hệ điều hành Linux.

Vì sao đúng

Đề nhấn mạnh "GIÁN ĐOẠN ÍT NHẤT" — và vá tại chỗ luôn ít gián đoạn hơn thay máy.

⚠ Điểm mấu chốt — Systems Manager vá ngay trên máy đang chạy:

Run Command với AWS-RunPatchBaseline
        ↓
    aws ssm send-command \
      --document-name "AWS-RunPatchBaseline" \
      --parameters "Operation=Install" \
      --targets "Key=tag:Moi-truong,Values=production" \
      --max-concurrency "10%" --max-errors "2"
        ↓
    → vá tại chỗ, không thay instance
    → không cần dựng AMI mới
    → không cần triển khai lại stack
        ↓
    Nhiều bản vá Linux thậm chí KHÔNG cần khởi động lại

⚠ Và hai tham số kiểm soát rủi ro rất đáng dùng:

--max-concurrency "10%"
        ↓
    → vá 10% fleet mỗi đợt, không đụng cả fleet cùng lúc

--max-errors "2"
        ↓
    → quá 2 máy lỗi thì DỪNG HẲN
        ↓
    → một bản vá hỏng không kéo sập toàn bộ hệ thống

⚠ Sau khi vá xong, đừng quên bước xác nhận:

Cho Amazon Inspector quét lại
        ↓
    → xác nhận lỗ hổng CVE đã được xử lý
        ↓
    → Systems Manager SỬA, Inspector CHỨNG MINH đã sửa

Xem thêm câu #11572, #11610 và #11648: cùng chủ đề vá bằng Systems Manager ở các bối cảnh khác — kiểm toán tuân thủ, phân biệt các capability của SSM, và vá khẩn cấp khi đang bị tấn công.

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

• B (triển khai lại instance bằng AMI đã cập nhật qua CloudFormation) — đây là phương án gần nhất và là cách làm tốt về lâu dài (hạ tầng bất biến). Nhưng nó gián đoạn nhiều hơn hẳn: phải dựng AMI mới, thay toàn bộ instance, và mọi trạng thái trên máy cũ đều mất. Đề hỏi cách ít gián đoạn nhất.

• A (dùng Amazon Inspector để sinh báo cáo khuyến nghị) — Inspector PHÁT HIỆN lỗ hổng, nó không cài bản vá nào. Nó là bước xác nhận, không phải bước khắc phục.

• C (tắt rồi bật lại instance để đổi host bên dưới) — đổi host vật lý không thay đổi gì trong hệ điều hành khách. Lỗ hổng nằm ở phần mềm bên trong máy, vẫn còn nguyên sau khi chuyển host.

Ghi nhớ

⚠ Bốn dịch vụ 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 đúng chuẩn | | 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:

"vá lỗ hổng, ít gián đoạn nhất" → Systems Manager Run Command / 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 "stop/start đổi host để vá" → SAI, không đụng tới hệ điều hành khách

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 vá chạy tới đâu | list-command-invocations --details | | Đã hết lỗ hổng chưa | cho Inspector quét lại |

Và một lời khuyên cho tình huống khẩn cấp như đề mô tả: hãy vá một nhóm nhỏ trước rồi mới mở rộng, ngay cả khi lỗ hổng nghiêm trọ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á kernel lỗi có thể làm cả fleet không khởi động lại được — và khi ấy bạn có cả một lỗ hổng chưa vá lẫn một sự cố ngừng dịch vụ toàn diện, cùng một lúc.

Đáp án

D — Dùng AWS Config rule để phát hiện access key không tuân thủ, rồi tạo một Systems Manager Automation document tuỳ chỉnh để khắc phục.

Vì sao đúng

Cặp Config rule + remediation action là cơ chế dựng sẵn cho đúng mô hình "phát hiện rồi tự sửa".

⚠ Điểm mấu chốt — hai bước, cả hai đều có sẵn:

Bước 1 — PHÁT HIỆN
        ↓
    AWS Config managed rule: access-keys-rotated
        ↓
    Tham số maxAccessKeyAge = 60
        ↓
    → mọi access key quá 60 ngày → NON_COMPLIANT

Bước 2 — KHẮC PHỤC
        ↓
    Remediation action gắn vào quy tắc đó
        ↓
    Gọi một SSM Automation document
        ↓
    → tự động gọi iam:UpdateAccessKey với Status=Inactive

⚠ Vì sao cơ chế này tốt hơn tự viết:

Config tự đánh giá theo chu kỳ (24 giờ)
        ↓
    → không cần dựng lịch chạy
    → không cần máy chủ nào

Có bảng compliance sẵn
        ↓
    → thấy ngay ai đang vi phạm, đã sửa được bao nhiêu

Có LỊCH SỬ cấu hình
        ↓
    → chứng minh được với kiểm toán viên
        ↓
Remediation chạy chế độ MANUAL hoặc AUTOMATIC
        ↓
    → nên bắt đầu bằng Manual để xem nó định làm gì

⚠ Và với đúng bài toán này, có một cách còn nhẹ hơn nữa:

IAM Credential Report
        ↓
    Tệp CSV liệt kê MỌI danh tính:
        access_key_1_last_rotated
        access_key_1_last_used_date
        ↓
    → miễn phí, tạo trong vài giây
    → dùng để rà soát, đối chiếu với kết quả của Config

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

• B (viết script kiểm tra tuổi khoá, chạy bằng cron trên một EC2) — đây là phương án gần nhất và về kỹ thuật thì chạy được. Nhưng nó đòi một EC2 chạy 24/7 chỉ để chạy cron, cộng với mã phải bảo trì, IAM role phải quản, và không có bảng compliance hay lịch sử nào cho kiểm toán.

• C (CloudWatch alarm kích hoạt Lambda để vô hiệu hoá khoá cũ) — CloudWatch alarm phản ứng với NGƯỠNG CỦA MỘT CHỈ SỐ, mà "tuổi của access key" không phải một chỉ số CloudWatch. Không có gì để đặt alarm lên cả. (Dùng EventBridge Scheduler gọi Lambda thì được — nhưng vẫn là tự chế.)

• A (dùng Amazon Inspector để khuyến nghị và tự vô hiệu hoá khoá) — Inspector quét lỗ hổng phần mềm trên EC2, container và Lambda. Nó không đụng tới IAM và không tự sửa gì cả.

Ghi nhớ

⚠ Các quy tắc Config liên quan tới IAM — bảng đáng thuộc: | Quy tắc | Kiểm tra | |---|---| | access-keys-rotated | access key quá N ngày — câu này | | iam-user-mfa-enabled | user đã bật MFA chưa | | root-account-mfa-enabled | root đã bật MFA chưa | | iam-root-access-key-check | root có access key không | | iam-password-policy | chính sách mật khẩu | | iam-user-unused-credentials-check | chứng chỉ lâu không dùng | | iam-policy-no-statements-with-admin-access | chính sách quá rộng |

Từ khoá nhận diện:

"phát hiện cấu hình sai + tự sửa" → Config rule + remediation "báo cáo trạng thái mọi chứng chỉ IAM" → Credential Report "chặn từ đầu, không cho tạo" → SCP "quét lỗ hổng phần mềm" → Inspector "chạy theo lịch" → EventBridge Scheduler, không phải CloudWatch alarm

⚠ Config remediation — hai chế độ, phải hiểu rõ trước khi bật: | Chế độ | Nội dung | |---|---| | Manual | Config đánh dấu vi phạm, người xem rồi bấm Remediate | | Automatic | Config tự sửa ngay khi phát hiện | | Thực hành tốt | bắt đầu bằng Manual vài tuần, xem nó định sửa gì, rồi mới bật Automatic | | Cơ chế thực thi | SSM Automation document | | Có sẵn nhiều document dựng sẵn | ví dụ AWSConfigRemediation-RevokeUnusedIAMUserCredentials |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Khoá nào đang vi phạm | bảng compliance của quy tắc access-keys-rotated | | Khoá nào lâu không dùng | Credential Report, cột access_key_1_last_used_date | | Remediation đã chạy chưa | lịch sử Automation trong Systems Manager |

Và một lời khuyên về hướng đi dài hạn: thay vì hoàn thiện quy trình xoay access key, hãy tính tới việc bỏ hẳn chúng. Xoay khoá mỗi 60 ngày làm giảm cửa sổ rủi ro, nhưng nó không xoá bỏ rủi ro — một khoá bị lộ vào ngày thứ nhất vẫn có 60 ngày để bị khai thác. IAM Identity Center cho quản trị viên chứng chỉ tạm sống vài giờ, và khi đó cả bài toán xoay khoá lẫn quy tắc Config này đều không còn cần thiết.

Đáp án

B — Thêm một luật vào Network ACL cho tất cả subnet trong VPC.

Vì sao đúng

Đề nêu ba yêu cầu, và chỉ NACL đáp ứng được cả ba:

⚠ Điểm mấu chốt — Security Group KHÔNG CÓ luật Deny:

Security Group
        ↓
    CHỈ có luật Allow
    Những gì không được cho phép thì mặc nhiên bị chặn
        ↓
    → KHÔNG có cách nào nói "chặn riêng IP này"
    → muốn chặn một IP thì phải liệt kê MỌI IP KHÁC được phép
      — bất khả thi với dịch vụ công khai
        ↓
Network ACL
        ↓
    Có CẢ Allow LẪN Deny
        ↓
    → thêm một luật Deny cho IP đó là xong

⚠ Và cách viết luật cho đúng — số thứ tự rất quan trọng:

NACL xét luật theo SỐ THỨ TỰ, từ nhỏ tới lớn,
DỪNG ở luật khớp đầu tiên
        ↓
    → luật Deny phải có SỐ NHỎ HƠN các luật Allow
        ↓
Inbound  10 : DENY  ALL  from 203.0.113.45/32
Inbound 100 : ALLOW ...
        ↓
Outbound 10 : DENY  ALL  to   203.0.113.45/32
Outbound 100: ALLOW ...

⚠ Và phải áp cho MỌI subnet như đề yêu cầu:

NACL gắn với SUBNET, không gắn với VPC
        ↓
    → phải thêm luật vào NACL của TỪNG subnet
      (hoặc dùng chung một NACL cho nhiều subnet)
        ↓
    → bỏ sót một subnet là còn một đường vào

Xem thêm câu #11730, #11721, #11727: cùng bộ đôi Security Group và NACL nhưng khai thác đặc tính khác — stateless, phải mở cả chiều ra. Ở đây khai thác đặc tính có luật Deny.

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

• A (thêm luật vào Security Group của các instance ở subnet bị ảnh hưởng) — đây là phương án gần nhất và là phản xạ đầu tiên của nhiều người. Nhưng Security Group không có luật Deny, nên không thực hiện được yêu cầu. Ngoài ra nó chỉ áp cho instance, không phủ được mọi dịch vụ trong VPC.

• C (cài tường lửa trên từng EC2 instance rồi chặn IP) — làm được nhưng chậm và không đầy đủ: phải chạm vào từng máy, không phủ được RDS, ElastiCache, Lambda-trong-VPC, và máy mới lên sẽ không có luật đó.

• D (gỡ Internet Gateway và dùng NAT Gateway thay thế) — cắt đứt toàn bộ lưu lượng vào từ internet, tức là làm sập dịch vụ công khai để chặn một địa chỉ IP. Hoàn toàn không tương xứng.

Ghi nhớ

⚠ Security Group và Network ACL — bảng phải thuộc: | | Security Group | Network ACL | |---|---|---| | Gắn vào | ENI (instance) | subnet | | Trạng thái | stateful | stateless | | Luật | CHỈ Allow | Allow VÀ Deny | | Mặc định | chặn vào, cho ra | cho cả hai chiều | | Thứ tự xét | xét tất cả | theo số thứ tự, dừng ở luật khớp đầu | | Chặn một IP cụ thể | KHÔNG ĐƯỢC | ĐƯỢC | | Tham chiếu SG khác | có | không |

Từ khoá nhận diện:

"chặn tường minh một IP" → NACL (SG không có Deny) "cho toàn bộ subnet / mọi dịch vụ" → NACL "mở inbound rồi mà vẫn timeout" → NACL thiếu chiều ra "chặn IP ở tầng ứng dụng HTTP" → AWS WAF IP set "chặn ở nhiều tài khoản cùng lúc" → Firewall Manager hoặc Network Firewall

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Luật đã áp chưa | describe-network-acls — xem cả Egress: true | | IP có còn vào được không | VPC Flow Logs, tìm bản ghi REJECT từ IP đó | | Có subnet nào bị bỏ sót không | liệt kê mọi subnet và NACL tương ứng |

Và một lưu ý về giới hạn của cách làm này khi cần mở rộng: NACL chỉ chứa được khoảng 20 tới 40 luật, nên nó là công cụ phản ứng nhanh cho một vài địa chỉ, không phải nơi duy trì danh sách đen. Nếu đội bảo mật liên tục gửi thêm IP cần chặn, hãy chuyển sang WAF IP set (cho lưu lượng HTTP) hoặc AWS Network Firewall (cho toàn bộ VPC) — cả hai đều quản được hàng nghìn địa chỉ và cập nhật được bằng tự động hoá.