Ngân hàng đề — AWS Certified Solutions Architect Associate

Đáp án

A — Dùng AWS Lambda với thư viện Python để xử lý.

Vì sao đúng

Đề cho ba con số rất cụ thể, và cả ba đều nằm gọn trong khả năng của Lambda: | Con số | Giới hạn Lambda | Kết luận | |---|---|---| | 1 MB dữ liệu mỗi ngày | tối đa 10 GB /tmp | rất nhỏ | | 512 MB bộ nhớ | 128 MB – 10.240 MB | cấu hình được chính xác | | Hoàn thành trong 10 giây | tối đa 15 phút | thoải mái |

Và mô hình chi phí là điều quyết định:

Chạy MỘT LẦN mỗi ngày, 10 giây, 512 MB:
    10 giây × 512 MB = 5,12 GB-giây mỗi ngày
    × 30 ngày = ~154 GB-giây mỗi tháng
        ↓
    Mức miễn phí của Lambda: 400.000 GB-giây/tháng
        ↓
    CHI PHÍ = 0 ĐỒNG

So với việc chạy một EC2 instance:

EC2 t3.micro chạy 24/7:  ~7,5 USD/tháng
    → để làm việc chỉ mất 10 giây mỗi ngày
    → 99,99% thời gian máy ngồi không mà vẫn tính tiền

Đây là mẫu sử dụng lý tưởng của serverless:

Công việc NGẮN, THƯA, có thể dự đoán
    → không có gì chạy khi không cần
    → không có máy chủ để vá lỗi hay giám sát

Kích hoạt bằng EventBridge theo lịch:

aws events put-rule --name xu-ly-du-lieu-suc-khoe-hang-ngay   --schedule-expression "cron(0 2 * * ? *)"

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

• **B. Tạo AWS Glue PySpark job để xử lý — đây là phương án gần nhất về mặt cũng là dịch vụ không máy chủ, nhưng nó quá nặng cho 1 MB dữ liệu: Glue Spark job dùng tối thiểu 2 DPU và tính phí tối thiểu 1 phút mỗi lần chạy, cộng thời gian khởi động Spark. Dùng cụm Spark cho 1 MB dữ liệu là dùng sai công cụ. (Glue Python shell job với 0,0625 DPU thì hợp lý hơn nhiều, nhưng đề ghi rõ là PySpark.)
• **C. Dùng Data Firehose đưa dữ liệu vào S3 rồi xử lý trên EC2 instance — đắt và thừa: phải trả tiền cho EC2 chạy liên tục, cộng phí Firehose, cho một công việc 10 giây mỗi ngày.
• **D. Lưu vào Amazon Redshift rồi xử lý bằng Lambda — cực kỳ lãng phí: Redshift là kho dữ liệu cho phân tích hàng terabyte. Một cụm nhỏ nhất cũng tốn hàng trăm USD mỗi tháng — cho 1 MB dữ liệu mỗi ngày.

Ghi nhớ

Giới hạn của AWS Lambda — bảng cần thuộc: | Giới hạn | Giá trị | |---|---| | Bộ nhớ | 128 MB – 10.240 MB | | Thời gian chạy tối đa | 15 phút | | Lưu trữ tạm /tmp | 512 MB – 10.240 MB | | Kích thước gói (zip) | 50 MB nén, 250 MB giải nén | | Kích thước container image | 10 GB | | Payload đồng bộ | 6 MB | | Mức đồng thời mặc định | 1.000 (tăng được) |

Mức miễn phí của Lambda — luôn có, không hết hạn:

1.000.000 request mỗi tháng
400.000 GB-giây tính toán mỗi tháng

Rất nhiều workload nhỏ như trong đề chạy hoàn toàn miễn phí.

Và có một chi tiết quan trọng về cách Lambda tính phí:

CPU được cấp TỶ LỆ THUẬN với bộ nhớ
    → tăng bộ nhớ cũng tăng tốc độ xử lý
    → đôi khi CHIA ĐÔI bộ nhớ làm hàm chạy LÂU GẤP BA
       → tổng chi phí CAO HƠN

Công cụ AWS Lambda Power Tuning giúp tìm cấu hình bộ nhớ tối ưu về chi phí bằng cách chạy thử ở nhiều mức.

Chọn dịch vụ tính toán theo đặc điểm công việc: | Đặc điểm | Dịch vụ | |---|---| | Ngắn (dưới 15 phút), thưa, theo sự kiện | Lambda ← câu này | | Chạy lâu, tải liên tục | Fargate hoặc EC2 | | Xử lý lô lớn, hàng nghìn công việc | AWS Batch | | ETL trên khối lượng lớn | Glue | | Cần GPU hoặc phần cứng đặc biệt | EC2 |

Ba loại Glue job — để thấy vì sao PySpark không hợp: | Loại | Tài nguyên tối thiểu | Phù hợp | |---|---|---| | Spark | 2 DPU | dữ liệu lớn, xử lý phân tán | | Python shell | 0,0625 DPU | script đơn giản, dữ liệu nhỏ | | Streaming ETL | 2 DPU | luồng liên tục |

Với 1 MB dữ liệu, ngay cả Python shell job cũng đắt hơn Lambda — vì Glue tính phí tối thiểu 1 phút.

Ba cách kích hoạt Lambda cho công việc theo lịch: | Cách | Chi tiết | |---|---| | EventBridge Scheduler | hiện đại nhất, hỗ trợ múi giờ, one-time schedule | | EventBridge rule với cron | phổ biến | | S3 event notification | khi có dữ liệu mới |

EventBridge Scheduler đáng dùng cho lịch mới: nó hỗ trợ múi giờ (cron thường chạy theo UTC), có cơ chế thử lại, và quản lý được hàng triệu lịch.

Ba lưu ý khi viết Lambda xử lý dữ liệu: | Lưu ý | Chi tiết | |---|---| | Đặt timeout hợp lý | 10 giây cho công việc này, không để mặc định 3 giây | | Xử lý được việc chạy hai lần | Lambda có thể gọi lại khi lỗi | | Ghi log đủ để chẩn đoán | CloudWatch Logs là nơi duy nhất thấy được |

Và với dữ liệu sức khoẻ như đề mô tả, đừng quên phần tuân thủ: | Yêu cầu | Cấu hình | |---|---| | Mã hoá dữ liệu trong S3 | SSE-KMS để có audit trail | | Ký BAA với AWS nếu là PHI | bắt buộc về pháp lý cho HIPAA | | Quyền IAM tối thiểu cho Lambda | chỉ đọc đúng prefix cần thiết |

Và một lời khuyên về thiết kế: với 1 MB mỗi ngày, dữ liệu tích luỹ khoảng 365 MB mỗi năm — hoàn toàn nhỏ. Nhưng nếu số thiết bị tăng lên hàng nghìn, kiến trúc sẽ khác hẳn: khi đó Kinesis Data Firehose gom dữ liệu thành tệp lớn rồi xử lý theo lô sẽ hiệu quả hơn nhiều so với Lambda chạy cho từng thiết bị.

Đáp án

B — Step scaling.

Vì sao đúng

Đề mô tả chính xác cơ chế của step scaling qua ba cụm từ: | Cụm từ trong đề | Đặc trưng của step scaling | |---|---| | "a set of scaling ADJUSTMENTS" | nhiều bậc điều chỉnh khác nhau | | "specifying the scaling metrics and THRESHOLD VALUES" | bạn tự khai ngưỡng | | "for the CloudWatch ALARMS that trigger the scaling" | step scaling gắn với CloudWatch alarm |

Cách step scaling hoạt động:

Bạn định nghĩa các BẬC theo mức vượt ngưỡng:
    CPU 60–70%  → thêm 1 instance
    CPU 70–85%  → thêm 2 instance
    CPU trên 85% → thêm 4 instance
        ↓
    Vượt càng nhiều thì phản ứng càng mạnh

aws autoscaling put-scaling-policy   --auto-scaling-group-name asg-ung-dung   --policy-name mo-rong-theo-bac   --policy-type StepScaling   --adjustment-type ChangeInCapacity   --step-adjustments     MetricIntervalLowerBound=0,MetricIntervalUpperBound=10,ScalingAdjustment=1     MetricIntervalLowerBound=10,MetricIntervalUpperBound=25,ScalingAdjustment=2     MetricIntervalLowerBound=25,ScalingAdjustment=4

MetricIntervalLowerBound tính TƯƠNG ĐỐI so với ngưỡng của alarm — nếu alarm đặt ở 60%, thì bậc 0–10 nghĩa là CPU từ 60% tới 70%.

Và điểm mạnh so với simple scaling:

Simple scaling:
    một hành động duy nhất
    + PHẢI CHỜ HẾT cooldown mới phản ứng tiếp
    → tải tăng vọt thì phản ứng rất chậm

Step scaling:
    nhiều bậc, chọn bậc phù hợp với mức vượt
    + KHÔNG chờ cooldown giữa các lần đánh giá
    → phản ứng nhanh và tương xứng

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

• **C. Simple scaling — đây là phương án gần nhất và cũng dựa trên CloudWatch alarm, nhưng nó chỉ có MỘT hành động duy nhất, không phải "a SET of scaling adjustments". Và nó phải chờ hết cooldown trước khi phản ứng tiếp, nên chậm hơn hẳn. Đây là loại policy thế hệ cũ.
• **A. Target tracking scaling — bạn KHÔNG khai ngưỡng và bậc: bạn chỉ đặt một giá trị mục tiêu (ví dụ CPU 50%), và AWS tự tạo alarm, tự tính toán cần thêm bớt bao nhiêu. Đề nói rõ là tự khai ngưỡng và các mức điều chỉnh.
• **D. Scheduled scaling — không dựa trên metric nào: nó thay đổi dung lượng theo thời gian định trước (ví dụ 8 giờ sáng tăng lên 10 máy). Không có CloudWatch alarm nào tham gia.

Ghi nhớ

Năm loại scaling policy của Auto Scaling — bảng cần thuộc: | Loại | Bạn khai gì | Đặc điểm | |---|---|---| | Target tracking | một GIÁ TRỊ MỤC TIÊU | AWS tự lo phần còn lại — đơn giản nhất | | Step scaling | ngưỡng + nhiều BẬC điều chỉnh | kiểm soát chi tiết ← câu này | | Simple scaling | ngưỡng + một hành động | cũ, chậm vì cooldown | | Scheduled scaling | thời điểm và dung lượng | cho mẫu tải biết trước theo giờ | | Predictive scaling | metric để dự báo | mở rộng TRƯỚC dựa trên học máy |

Từ khoá nhận diện trong đề thi:

"set of scaling adjustments", "step", "threshold values" → step scaling "maintain metric at a target value", "keep CPU at 50%" → target tracking "at a specific time", "every Monday 8AM" → scheduled scaling "forecast", "recurring pattern", "in advance" → predictive scaling

Ba loại adjustment-type: | Loại | Ý nghĩa | |---|---| | ChangeInCapacity | thêm hoặc bớt SỐ LƯỢNG cụ thể | | PercentChangeInCapacity | thêm bớt theo phần trăm | | ExactCapacity | đặt về một con số cố định |

PercentChangeInCapacity hữu ích khi đội máy lớn — thêm 20% của 50 máy hợp lý hơn là luôn thêm đúng 2 máy.

Và AWS khuyến nghị target tracking cho hầu hết trường hợp:

Target tracking:
    ✓ đơn giản — chỉ một con số
    ✓ tự tạo và quản lý alarm
    ✓ tự động cân bằng, tránh dao động
        ↓
Step scaling chỉ nên dùng khi:
    → cần phản ứng khác nhau tuỳ mức độ vượt ngưỡng
    → hoặc dùng metric tuỳ chỉnh phức tạp

Ba tham số quan trọng của step scaling: | Tham số | Việc | |---|---| | MetricIntervalLowerBound / UpperBound | định nghĩa từng bậc, TƯƠNG ĐỐI so với ngưỡng alarm | | EstimatedInstanceWarmup | thời gian chờ instance mới sẵn sàng trước khi tính vào metric | | MinAdjustmentMagnitude | mức thay đổi tối thiểu (dùng với PercentChangeInCapacity) |

EstimatedInstanceWarmup rất quan trọng:

Không đặt (hoặc đặt quá ngắn):
    → instance mới chưa khởi động xong đã bị tính vào metric trung bình
    → metric vẫn cao → ASG thêm tiếp
    → mở rộng QUÁ MỨC

Ba cấu hình khác ảnh hưởng tới hành vi co giãn: | Cấu hình | Ảnh hưởng | |---|---| | Cooldown period | thời gian chờ giữa hai hoạt động co giãn (simple scaling) | | Health check grace period | thời gian bỏ qua health check cho instance mới | | MinSize / MaxSize | biên trên và dưới tuyệt đối |

Và một lời khuyên về việc chọn metric để co giãn: | Metric | Phù hợp | |---|---| | CPUUtilization | ứng dụng nặng tính toán | | ALBRequestCountPerTarget | thường phản ánh tải thật tốt hơn CPU | | Độ sâu hàng đợi SQS | ứng dụng xử lý theo hàng đợi | | Bộ nhớ (metric tuỳ chỉnh) | cần CloudWatch agent mới có |

ALBRequestCountPerTarget đáng cân nhắc cho ứng dụng web: số request là chỉ báo trực tiếp của nhu cầu, còn CPU là hệ quả gián tiếp và có độ trễ.

Và một lời khuyên vận hành: hãy đặt cả policy mở rộng lẫn thu hẹp, và làm cho việc thu hẹp thận trọng hơn việc mở rộng (ngưỡng thấp hơn, bậc nhỏ hơn). Mở rộng quá tay chỉ tốn tiền tạm thời; thu hẹp quá tay gây gián đoạn dịch vụ.

Đáp án

A và B.

• A — Dùng AWS WAF tạo web ACL với rule cho phép tường minh các IP đã duyệt khai trong IP Set
• B — Thêm rule nữa vào web ACL với geo match condition CHẶN request từ quốc gia cụ thể

Vì sao đúng

Đề nêu hai yêu cầu đối lập nhau, và WAF xử lý được nhờ thứ tự ưu tiên của rule: | Yêu cầu | Rule | |---|---| | Chặn request từ một quốc gia | B — geo match rule với action Block | | NHƯNG vẫn cho phép một số IP cụ thể từ chính quốc gia đó | A — IP set rule với action Allow, ĐỘ ƯU TIÊN CAO HƠN |

Và thứ tự là chi tiết quyết định:

Priority 1: Allow IP set (các IP được duyệt)   ← xét TRƯỚC
Priority 2: Block geo match (quốc gia X)       ← xét SAU
    ↓
Request từ IP được duyệt (ở quốc gia X):
    → khớp rule 1 → ALLOW → DỪNG, không xét rule 2
Request khác từ quốc gia X:
    → không khớp rule 1
    → khớp rule 2 → BLOCK

WAF đánh giá rule theo THỨ TỰ ƯU TIÊN và dừng ở rule khớp đầu tiên có action kết thúc (Allow hoặc Block) — nên đảo ngược thứ tự sẽ khiến rule Allow không bao giờ được xét tới.

aws wafv2 create-ip-set --name ip-duoc-duyet --scope REGIONAL   --ip-address-version IPV4 --addresses 203.0.113.10/32 198.51.100.25/32

{"Rules": [
  {"Name": "cho-phep-ip-duyet", "Priority": 1,
   "Statement": {"IPSetReferenceStatement": {"ARN": "<arn-ip-set>"}},
   "Action": {"Allow": {}}},
  {"Name": "chan-quoc-gia", "Priority": 2,
   "Statement": {"GeoMatchStatement": {"CountryCodes": ["XX"]}},
   "Action": {"Block": {}}}
]}

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

• **C. Tạo listener rule trên Application Load Balancer cho phép các IP đã duyệt — đây là phương án gần nhất về mặt cũng lọc lưu lượng, nhưng ALB listener rule KHÔNG lọc theo IP nguồn được: điều kiện hợp lệ của nó là host header, đường dẫn, HTTP header, phương thức, query string. (ALB có điều kiện source-ip nhưng nó dành cho việc định tuyến, không thay thế được WAF cho bài toán kết hợp geo và IP.)
• **D. Đặt geo match condition trên Application Load Balancer — ALB KHÔNG có tính năng chặn theo địa lý. Đó là chức năng của WAF hoặc CloudFront.
• **E. Đặt Transit Gateway trước VPC và dùng NACL chặn request theo quốc gia — NACL chỉ lọc theo CIDR, nó không biết quốc gia nào. Và Transit Gateway là trung tâm định tuyến, không phải thiết bị lọc.

Ghi nhớ

Nguyên tắc đánh giá rule của AWS WAF:

① Rule được xét theo THỨ TỰ ƯU TIÊN (số nhỏ trước)
② Gặp action Allow hoặc Block → DỪNG
③ Action Count → tiếp tục xét rule sau
④ Không rule nào khớp → dùng DEFAULT ACTION của web ACL

Hệ quả thực tế quan trọng:

Rule ngoại lệ (Allow) phải có ĐỘ ƯU TIÊN CAO HƠN rule chặn. Đặt ngược lại là rule Allow không bao giờ được xét.

Bốn action của WAF rule: | Action | Việc | |---|---| | Allow | cho qua, dừng đánh giá | | Block | chặn, dừng đánh giá | | Count | chỉ đếm, KHÔNG chặn — dùng để thử nghiệm | | CAPTCHA / Challenge | yêu cầu xác minh |

Count là công cụ triển khai an toàn: bật rule mới ở chế độ Count trước, xem nó khớp với những request nào, rồi mới chuyển sang Block. Tránh được việc chặn nhầm khách hàng thật.

Các loại statement của WAF rule: | Statement | Lọc theo | |---|---| | IPSetReferenceStatement | danh sách IP hoặc CIDR | | GeoMatchStatement | quốc gia (mã ISO hai chữ) | | RateBasedStatement | số request mỗi 5 phút từ một IP | | ByteMatchStatement | chuỗi trong request | | SqliMatchStatement / XssMatchStatement | tấn công SQL injection, XSS | | SizeConstraintStatement | kích thước phần request | | LabelMatchStatement | nhãn do rule khác gắn |

Và các statement kết hợp được:

AndStatement, OrStatement, NotStatement

Ví dụ: chặn quốc gia X TRỪ KHI IP nằm trong danh sách:

{"AndStatement": {"Statements": [
   {"GeoMatchStatement": {"CountryCodes": ["XX"]}},
   {"NotStatement": {"Statement":
     {"IPSetReferenceStatement": {"ARN": "<arn-ip-set>"}}}}]}}

Cách này gộp thành MỘT rule — cũng đúng, và dễ đọc hơn khi logic phức tạp.

Ba nơi gắn được AWS WAF: | Nơi | Scope | |---|---| | Application Load Balancer | REGIONAL ← đề này | | API Gateway, AppSync, Cognito | REGIONAL | | CloudFront | CLOUDFRONT — phải tạo web ACL ở us-east-1 |

Chặn ở CloudFront hiệu quả hơn chặn ở ALB — request bị chặn ngay tại điểm biên, không tới hạ tầng của bạn. Với tấn công quy mô lớn, khác biệt này rất đáng kể.

Ba nhóm managed rule nên cân nhắc: | Nhóm | Chống | |---|---| | AWSManagedRulesCommonRuleSet | các tấn công web phổ biến (OWASP) | | AWSManagedRulesAmazonIpReputationList | IP có tiếng xấu, botnet | | AWSManagedRulesKnownBadInputsRuleSet | payload khai thác đã biết | | AWSManagedRulesBotControlRuleSet | bot (có phí thêm) |

Rate-based rule là biện pháp nên có cho mọi ứng dụng công khai:

{"RateBasedStatement": {"Limit": 2000, "AggregateKeyType": "IP"}}

Nó chặn IP gửi quá 2.000 request trong 5 phút — biện pháp đơn giản mà hiệu quả chống lạm dụng.

Ba lưu ý về geo match: | Lưu ý | Chi tiết | |---|---| | Dựa trên cơ sở dữ liệu GeoIP | không chính xác 100% | | VPN và proxy vượt qua được dễ dàng | không phải biện pháp bảo mật mạnh | | Cần header X-Forwarded-For đúng nếu có proxy phía trước | nếu không sẽ nhận nhầm quốc gia |

Dòng giữa đáng nhớ: chặn theo quốc gia phù hợp cho tuân thủ pháp lý hoặc giảm nhiễu, không phải để chống kẻ tấn công có chủ đích.

Và một lời khuyên vận hành: bật WAF logging vào Kinesis Firehose → S3, rồi phân tích bằng Athena. Khi có khiếu nại "tôi không truy cập được", log là cách duy nhất biết request đó bị rule nào chặn.

Đáp án

A và B.

• A — Mọi dữ liệu di chuyển giữa volume và instance đều được mã hoá
• B — Snapshot được mã hoá TỰ ĐỘNG

Vì sao đúng

Mã hoá EBS hoạt động ở tầng hạ tầng và bao trùm toàn bộ vòng đời dữ liệu.

A — mã hoá không chỉ ở trạng thái nghỉ:

Khi bật mã hoá EBS, những thứ sau ĐỀU được mã hoá:
    ✓ Dữ liệu NẰM TRÊN volume (at rest)
    ✓ Dữ liệu DI CHUYỂN giữa volume và instance (in transit)
    ✓ Mọi SNAPSHOT tạo từ volume đó
    ✓ Mọi VOLUME tạo từ snapshot đó

Vế thứ hai là điều nhiều người không biết — mã hoá EBS bao gồm cả đường truyền giữa máy chủ và tầng lưu trữ.

B — và tính mã hoá lan truyền tự động:

Volume mã hoá
    → snapshot TỰ ĐỘNG mã hoá
        → volume tạo từ snapshot đó TỰ ĐỘNG mã hoá
            → AMI tạo từ đó cũng mã hoá

Không có cách nào "vô tình" tạo ra bản sao không mã hoá từ nguồn đã mã hoá.

Và toàn bộ quá trình trong suốt với ứng dụng:

Không cần sửa mã ứng dụng
Không ảnh hưởng đáng kể tới hiệu năng (IOPS, độ trễ gần như không đổi)
Hệ điều hành không biết có mã hoá

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

• **D. Chỉ dữ liệu trên volume được mã hoá, KHÔNG phải dữ liệu di chuyển giữa volume và instance — đây là phương án gần nhất và là hiểu nhầm phổ biến nhất, nhưng nó mâu thuẫn trực tiếp với A: mã hoá EBS bao gồm cả dữ liệu in transit giữa instance và volume.
• **C. Snapshot KHÔNG được mã hoá tự động — sai, mâu thuẫn với B.
• **E. Volume tạo từ snapshot đã mã hoá thì KHÔNG được mã hoá — sai: tính mã hoá luôn được kế thừa. Đây là bảo đảm quan trọng của cơ chế.

Ghi nhớ

Những gì được mã hoá khi bật mã hoá EBS: | Đối tượng | Mã hoá | |---|---| | Dữ liệu nằm trên volume | ✅ | | Dữ liệu giữa volume và instance | ✅ | | Snapshot tạo từ volume | ✅ tự động | | Volume tạo từ snapshot mã hoá | ✅ tự động | | AMI tạo từ volume mã hoá | ✅ |

Ba đặc điểm khác của mã hoá EBS: | Đặc điểm | Chi tiết | |---|---| | Dùng AWS KMS | khoá mặc định aws/ebs hoặc khoá của bạn | | Trong suốt với ứng dụng | không cần sửa mã | | Ảnh hưởng hiệu năng không đáng kể | IOPS và độ trễ gần như không đổi |

Và một cạm bẫy quan trọng: KHÔNG mã hoá được volume ĐANG TỒN TẠI trực tiếp.

Volume chưa mã hoá:
    → không có nút "bật mã hoá"
    ↓
Quy trình chuyển đổi:
    ① Chụp snapshot của volume
    ② Sao chép snapshot với tuỳ chọn Encrypted = true
    ③ Tạo volume mới từ snapshot đã mã hoá
    ④ Tháo volume cũ, gắn volume mới

aws ec2 copy-snapshot --source-snapshot-id snap-0abc123   --source-region ap-southeast-1 --encrypted --kms-key-id alias/khoa-cua-toi

Và có một cách tránh vấn đề này hoàn toàn: bật mã hoá MẶC ĐỊNH cho toàn Region.

aws ec2 enable-ebs-encryption-by-default --region ap-southeast-1

Sau đó mọi volume mới đều tự động mã hoá — không ai quên được nữa. Đây là cấu hình nên bật cho mọi tài khoản sản xuất.

Hai loại khoá KMS cho EBS: | Loại | Đặc điểm | |---|---| | AWS managed key (aws/ebs) | miễn phí lưu, KHÔNG đổi được policy | | Customer managed key | ~1 USD/tháng, KIỂM SOÁT đầy đủ, chia sẻ được |

Với yêu cầu HIPAA như đề mô tả, customer managed key thường là lựa chọn đúng — nó cho phép đặt key policy riêng, xoay vòng theo lịch, và có audit trail chi tiết trong CloudTrail về ai đã dùng khoá.

Ba lưu ý về chia sẻ snapshot đã mã hoá: | Lưu ý | Chi tiết | |---|---| | Snapshot mã hoá bằng khoá aws/ebs KHÔNG chia sẻ được | phải dùng customer managed key | | Phải chia sẻ CẢ khoá KMS | không thì tài khoản kia không giải mã được | | Không công khai snapshot mã hoá được | chỉ chia sẻ với tài khoản cụ thể |

Bốn tầng mã hoá nên có cho ứng dụng hồ sơ y tế: | Tầng | Cơ chế | |---|---| | EBS | mã hoá volume ← câu này | | S3 | SSE-KMS | | RDS / Neptune | bật mã hoá lúc tạo | | In transit | TLS cho mọi kết nối |

Lưu ý về Amazon Neptune mà đề nhắc tới: giống RDS, mã hoá phải bật LÚC TẠO cluster — không bật được cho cluster đang chạy. Muốn mã hoá cluster chưa mã hoá thì phải chụp snapshot, sao chép có mã hoá, rồi khôi phục.

Và tuân thủ HIPAA cần nhiều hơn mã hoá: | Yêu cầu | Chi tiết | |---|---| | Ký BAA với AWS | bắt buộc về pháp lý | | Chỉ dùng dịch vụ đủ điều kiện HIPAA | EC2, EBS, S3, RDS, Neptune đều nằm trong danh sách | | Audit trail đầy đủ | CloudTrail, và data event nếu cần | | Kiểm soát truy cập tối thiểu | IAM chặt chẽ |

Và một lưu ý về Dedicated Instance mà đề nhắc tới: nó đảm bảo phần cứng không chia sẻ với khách hàng khác, phục vụ yêu cầu tuân thủ. Nhưng nó không liên quan tới mã hoá — hai biện pháp bổ sung nhau, không thay thế nhau.

Đáp án

D — Đặt thẻ (tag) trên các máy chủ UAT và production, rồi thêm điều kiện vào IAM policy cho phép truy cập theo thẻ cụ thể.

Vì sao đúng

Đề cần ngăn nhân viên phụ trách UAT chạm vào máy production, và kiểm soát truy cập theo thuộc tính là cách gọn nhất.

Cơ chế gọi là ABAC (Attribute-Based Access Control):

Gắn thẻ cho tài nguyên:
    Instance UAT        → MoiTruong = uat
    Instance production → MoiTruong = production
        ↓
IAM policy dùng điều kiện theo thẻ:
    chỉ thao tác được với instance có thẻ khớp

{"Effect": "Allow",
 "Action": ["ec2:StartInstances", "ec2:StopInstances", "ec2:RebootInstances"],
 "Resource": "arn:aws:ec2:*:*:instance/*",
 "Condition": {"StringEquals": {"ec2:ResourceTag/MoiTruong": "uat"}}}

Và ưu điểm lớn nhất là khả năng mở rộng:

Thêm instance UAT mới → gắn thẻ MoiTruong = uat → tự động được phép
Thêm instance production → gắn thẻ tương ứng → tự động bị chặn
    → KHÔNG phải sửa policy

Với một policy duy nhất dùng biến, còn gọn hơn nữa:

{"Condition": {"StringEquals":
   {"ec2:ResourceTag/MoiTruong": "${aws:PrincipalTag/MoiTruong}"}}}

Người dùng có thẻ MoiTruong = uat chỉ thao tác được với tài nguyên có thẻ tương ứng — một policy phục vụ mọi môi trường.

Và cần chặn việc tự đổi thẻ:

{"Effect": "Deny",
 "Action": ["ec2:CreateTags", "ec2:DeleteTags"],
 "Resource": "*",
 "Condition": {"StringNotEquals": {"aws:ResourceTag/MoiTruong": "uat"}}}

Thiếu bước này thì người dùng đổi thẻ của máy production thành uat rồi thao tác thoải mái.

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

• **A. Khởi chạy UAT và production trong VPC riêng nối bằng VPC peering — đây là phương án gần nhất về mặt cũng tách biệt hai môi trường, nhưng nó giải quyết vấn đề MẠNG, không phải vấn đề QUYỀN: tách VPC ngăn lưu lượng đi lại, nhưng người dùng có quyền IAM vẫn gọi API để dừng, khởi động, chấm dứt máy production từ Console. Và peering còn nối chúng lại với nhau.
• **B. Cấp quyền qua AWS Resource Access Manager (RAM) — sai vai trò dịch vụ: RAM dùng để chia sẻ tài nguyên giữa các TÀI KHOẢN AWS (subnet, Transit Gateway, Route 53 rule). Nó không phân quyền cho người dùng trong cùng một tài khoản, và EC2 instance không phải loại tài nguyên chia sẻ được qua RAM.
• **C. Đặt UAT và production ở Availability Zone khác nhau và dùng MFA — không liên quan tới phân quyền: AZ là vị trí vật lý, không phải ranh giới bảo mật. Và MFA xác thực danh tính, nó không giới hạn người dùng được thao tác với tài nguyên nào.

Ghi nhớ

Hai mô hình kiểm soát truy cập: | Mô hình | Cách hoạt động | |---|---| | RBAC (theo vai trò) | policy liệt kê tài nguyên cụ thể — phải sửa khi thêm tài nguyên | | ABAC (theo thuộc tính) | policy so khớp THẺ — tự áp cho tài nguyên mới |

ABAC là lựa chọn tốt hơn khi tài nguyên thay đổi thường xuyên — đúng tình huống của môi trường UAT.

Ba khoá điều kiện liên quan tới thẻ: | Khoá | Áp cho | |---|---| | aws:ResourceTag/<key> | thẻ của TÀI NGUYÊN đang thao tác | | aws:RequestTag/<key> | thẻ được gửi kèm khi TẠO tài nguyên | | aws:PrincipalTag/<key> | thẻ của NGƯỜI GỌI | | aws:TagKeys | danh sách khoá thẻ trong request |

aws:RequestTag dùng để BẮT BUỘC gắn thẻ khi tạo:

{"Effect": "Deny", "Action": "ec2:RunInstances", "Resource": "*",
 "Condition": {"Null": {"aws:RequestTag/MoiTruong": "true"}}}

Không có thẻ thì không tạo được instance — đảm bảo mọi tài nguyên đều nằm trong phạm vi kiểm soát.

Ba lưu ý quan trọng khi dùng ABAC với EC2: | Lưu ý | Chi tiết | |---|---| | Không phải mọi API EC2 đều hỗ trợ điều kiện theo thẻ | kiểm tra tài liệu từng action | | Phải chặn quyền sửa thẻ | nếu không người dùng tự nâng quyền | | ec2:DescribeInstances KHÔNG lọc theo thẻ được | người dùng vẫn XEM được mọi instance |

Dòng cuối hay gây bất ngờ: các API Describe* của EC2 không hỗ trợ điều kiện theo thẻ ở mức tài nguyên. Người dùng UAT vẫn nhìn thấy máy production trong danh sách, chỉ là không thao tác được. Nếu cần che luôn thì phải tách tài khoản.

Và đó dẫn tới lựa chọn mạnh hơn: tách TÀI KHOẢN AWS. | | Tách bằng thẻ + IAM | Tách bằng tài khoản | |---|---|---| | Mức cách ly | logic | tuyệt đối | | Che tài nguyên khỏi tầm nhìn | ❌ | ✅ | | Ranh giới hạn mức và chi phí | không rõ ràng | rõ ràng | | Độ phức tạp | thấp | cao hơn |

AWS khuyến nghị tách tài khoản cho ranh giới prod và non-prod — với AWS Organizations và Control Tower, việc này không còn quá phức tạp. Nhưng cho câu hỏi này, ABAC là đáp án đúng và là giải pháp hợp lý trong phạm vi một tài khoản.

Ba lợi ích khác của việc gắn thẻ nhất quán: | Lợi ích | Chi tiết | |---|---| | Phân bổ chi phí | Cost Explorer nhóm theo thẻ — biết môi trường nào tốn bao nhiêu | | Tự động hoá | dừng máy UAT ngoài giờ theo thẻ | | Kiểm kê và tuân thủ | AWS Config rule required-tags |

Lưu ý: để dùng thẻ trong Cost Explorer, phải KÍCH HOẠT khoá thẻ đó trong Billing console mục "Cost allocation tags" — và dữ liệu chỉ có từ thời điểm kích hoạt trở đi.

Và một lời khuyên: dùng AWS Config rule required-tags để phát hiện instance chưa gắn thẻ. Với ABAC, một instance thiếu thẻ nghĩa là không ai thao tác được với nó — hoặc tệ hơn, nếu policy viết lỏng thì ai cũng thao tác được.

Đáp án

C — Chặn các địa chỉ IP đó trong Network Access Control List (NACL).

Vì sao đúng

Đề cần biện pháp NHANH NHẤT để chặn tấn công từ các IP đã biết, trong khi giải pháp lâu dài đang được chuẩn bị.

Và NACL là công cụ duy nhất trong bốn phương án làm được điều đó:

NACL có rule DENY
    → thêm rule chặn IP cụ thể
    → có hiệu lực NGAY LẬP TỨC
    → không đụng gì tới cấu hình instance

aws ec2 create-network-acl-entry --network-acl-id acl-0abc123   --rule-number 10 --protocol -1 --rule-action deny   --cidr-block 198.51.100.42/32 --ingress

Vì sao phải là NACL chứ không phải security group:

Security group:
    ✗ CHỈ có rule ALLOW
    → không có cách nào "chặn một IP cụ thể"
    → muốn chặn thì phải liệt kê TẤT CẢ IP được phép, bất khả thi

NACL:
    ✓ có CẢ Allow lẫn Deny
    → thêm rule Deny cho các IP tấn công là xong

Và có một lợi thế nữa: NACL là stateless nên nó CẮT được kết nối đang mở.

Security group stateful:
    → đổi rule KHÔNG ngắt kết nối đã thiết lập
NACL stateless:
    → mọi gói tin đều bị đánh giá lại
    → kết nối SSH đang mở của kẻ tấn công bị cắt NGAY

Nhớ đặt rule Deny ở SỐ NHỎ HƠN mọi rule Allow bao quát:

Rule 10:  DENY  198.51.100.42/32   ← xét trước
Rule 100: ALLOW 0.0.0.0/0

NACL dừng ở rule khớp đầu tiên — đặt Deny ở số lớn hơn là nó không bao giờ được xét tới.

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

• **A. Đưa các EC2 instance vào private subnet — đây là phương án gần nhất và thực sự chấm dứt tấn công, nhưng nó KHÔNG NHANH và gây gián đoạn: không "chuyển" instance sang subnet khác được — phải chụp AMI, khởi chạy lại ở subnet mới, cập nhật DNS. Và làm vậy cũng cắt luôn truy cập hợp lệ của người dùng.
• **B. Gỡ Internet Gateway khỏi VPC — biện pháp quá mạnh tay: nó chặn tấn công nhưng làm sập toàn bộ kết nối Internet của mọi tài nguyên trong VPC. Chữa bệnh bằng cách giết bệnh nhân.
• **D. Gán địa chỉ AnyCast tĩnh cho mỗi instance — không liên quan tới việc chặn: địa chỉ AnyCast là tính năng của Global Accelerator, dùng để tối ưu định tuyến. Nó không lọc lưu lượng độc hại nào.

Ghi nhớ

Security group và NACL — bảng phân biệt cốt lõi: | | Security group | Network ACL | |---|---|---| | Rule | CHỈ Allow | Allow VÀ DENY | | Trạng thái | stateful | stateless | | Áp ở mức | ENI / instance | subnet | | Đánh giá | mọi rule | theo thứ tự số, dừng ở rule đầu khớp | | Cắt kết nối đang mở | ❌ | ✅ | | Nguồn chấp nhận | IP, CIDR, security group, prefix list | chỉ CIDR |

Hai dòng in đậm giải thích trọn vẹn vì sao NACL là đáp án:

Chỉ NACL có rule Deny. Chỉ NACL cắt được kết nối đang mở.

Nguyên tắc đánh giá NACL — thuộc lòng:

① Xét theo THỨ TỰ SỐ TĂNG DẦN
② DỪNG ngay ở rule khớp ĐẦU TIÊN
③ Không rule nào khớp → rule mặc định (*) → DENY

Hệ quả: đặt rule DENY cụ thể ở số NHỎ HƠN rule ALLOW bao quát.

Ba lưu ý về việc dùng NACL để chặn IP: | Lưu ý | Chi tiết | |---|---| | Giới hạn số rule | mặc định 20 rule mỗi NACL, tăng được tới 40 | | Chỉ chấp nhận CIDR | không dùng được tên miền hay danh sách động | | Áp cho CẢ subnet | mọi tài nguyên trong đó đều bị ảnh hưởng |

Dòng đầu là hạn chế thực tế: nếu tấn công đến từ hàng trăm IP, NACL không đủ chỗ. Khi đó cần AWS WAF với IP set (chứa tới 10.000 CIDR) hoặc Network Firewall.

Và giải pháp căn bản cho vấn đề của đề: KHÔNG mở cổng 22 ra Internet. | Biện pháp | Lợi ích | |---|---| | AWS Systems Manager Session Manager | không cần cổng 22, không cần IP công khai, có audit log | | Chỉ mở cổng 22 cho IP công ty (/32) | thu hẹp bề mặt tấn công | | Bastion host trong public subnet, instance ở private | tập trung điểm vào |

Session Manager là cách được AWS khuyến nghị hiện nay:

aws ssm start-session --target i-0abc123def456

Yêu cầu: SSM Agent (đã cài sẵn trong AMI Amazon Linux và Ubuntu gần đây), IAM role AmazonSSMManagedInstanceCore, và VPC endpoint nếu ở private subnet không có NAT.

Ba biện pháp khác chống dò mật khẩu SSH: | Biện pháp | Chi tiết | |---|---| | Tắt xác thực bằng mật khẩu | chỉ dùng khoá SSH | | Đổi cổng SSH | giảm nhiễu từ bot quét tự động | | fail2ban | tự chặn IP sau vài lần đăng nhập sai |

Và về ba dịch vụ mà đội bảo mật đang dựng: | Dịch vụ | Chống | |---|---| | AWS WAF | tấn công tầng 7 — chỉ áp cho HTTP/HTTPS, KHÔNG cho SSH | | GuardDuty | phát hiện hành vi bất thường, có phát hiện riêng cho brute force SSH | | Shield Advanced | DDoS quy mô lớn |

Lưu ý quan trọng: WAF KHÔNG bảo vệ được SSH — nó chỉ lọc lưu lượng HTTP qua CloudFront, ALB, API Gateway. Với tấn công vào cổng 22, các công cụ đúng là NACL, security group, hoặc AWS Network Firewall.

GuardDuty có phát hiện riêng cho tình huống này:

UnauthorizedAccess:EC2/SSHBruteForce

Kết hợp với EventBridge và Lambda, nó tự động thêm IP tấn công vào NACL — biến biện pháp thủ công của đề thành phản ứng tự động.

Và một lưu ý về Elastic IP: sau khi xử lý xong sự cố, cân nhắc cấp lại Elastic IP mới cho các instance. Địa chỉ cũ đã nằm trong danh sách mục tiêu của các bot quét và sẽ tiếp tục bị dò trong thời gian dài.

Đáp án

B — Cấu hình health check chưa được định nghĩa đúng.

Vì sao đúng

Đề cho một manh mối loại trừ quan trọng: security group đã cho phép cổng 80 — nghĩa là đường mạng thông.

Suy luận từ đó:

Security group mở cổng 80  ✅ đã kiểm tra
Instance nằm trong target group ✅ đã thêm
    ↓
Vẫn "out of service"
    → Load balancer đang gọi health check và KHÔNG nhận được phản hồi đúng
    → vấn đề nằm ở CẤU HÌNH HEALTH CHECK

Bốn thông số health check hay bị sai: | Thông số | Lỗi thường gặp | |---|---| | Đường dẫn (path) | trỏ tới URL không tồn tại → nhận 404 | | Cổng | khai cổng khác cổng ứng dụng đang nghe | | Mã thành công | ứng dụng trả 301 hoặc 302 nhưng chỉ chấp nhận 200 | | Ngưỡng và khoảng thời gian | quá gắt so với thời gian khởi động của ứng dụng |

Lỗi phổ biến nhất: đường dẫn health check.

Mặc định: "/"
    → nếu ứng dụng chuyển hướng "/" sang "/dang-nhap" → trả 302
    → ALB coi là THẤT BẠI (mặc định chỉ chấp nhận 200)

Cách sửa — tạo một endpoint riêng cho health check:

aws elbv2 modify-target-group --target-group-arn <arn>   --health-check-path /health   --health-check-port traffic-port   --matcher HttpCode=200   --health-check-interval-seconds 30   --healthy-threshold-count 2   --unhealthy-threshold-count 3

Và xem lý do thất bại cụ thể:

aws elbv2 describe-target-health --target-group-arn <arn>

Trường Reason cho biết chính xác vấn đề: Target.ResponseCodeMismatch, Target.Timeout, Target.FailedHealthChecks.

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

• **D. Dùng sai subnet trong VPC — đây là phương án gần nhất và thực sự có thể gây lỗi tương tự, nhưng nó ít khớp với dữ kiện: nếu instance ở subnet mà ALB không vươn tới được, thường không thêm được vào target group ngay từ đầu, hoặc lỗi sẽ biểu hiện ở cả hai target group một cách khác. Health check sai là nguyên nhân phổ biến hơn nhiều khi security group đã đúng.
• **A. Dùng sai AMI — không phải nguyên nhân trực tiếp: AMI quyết định hệ điều hành và phần mềm cài sẵn. Nếu ứng dụng không chạy thì vấn đề là ứng dụng, và triệu chứng vẫn quy về health check thất bại.
• **C. Dùng sai loại instance — không liên quan: loại instance quyết định CPU, bộ nhớ, mạng. Máy nhỏ có thể chậm nhưng vẫn phản hồi health check.

Ghi nhớ

Danh sách kiểm tra khi target ở trạng thái unhealthy — theo thứ tự: | Bước | Kiểm tra | |---|---| | ① Ứng dụng có đang chạy không | curl http://localhost:80/health trên chính instance | | ② Đường dẫn health check đúng chưa | và nó trả về mã gì | | ③ Mã thành công (Matcher) | mặc định chỉ 200 | | ④ Security group của INSTANCE | cho phép cổng từ security group của ALB | | ⑤ Security group của ALB | cho phép outbound tới instance | | ⑥ NACL của subnet | cần cả inbound VÀ outbound (stateless) | | ⑦ Grace period | ứng dụng khởi động lâu hơn thời gian cho phép |

Bước ① là bước nên làm đầu tiên — nó phân biệt ngay giữa "ứng dụng hỏng" và "cấu hình mạng hỏng".

Các tham số health check của ALB: | Tham số | Mặc định | Ghi chú | |---|---|---| | HealthCheckPath | / | nên tạo endpoint riêng /health | | HealthCheckIntervalSeconds | 30 | 5–300 | | HealthCheckTimeoutSeconds | 5 | phải nhỏ hơn interval | | HealthyThresholdCount | 5 | số lần thành công liên tiếp để khoẻ lại | | UnhealthyThresholdCount | 2 | số lần thất bại để bị loại | | Matcher | 200 | khai 200-299 nếu ứng dụng trả mã khác |

Thiết kế endpoint health check tốt:

✅ Trả về 200 nhanh, không phụ thuộc dịch vụ bên ngoài
✅ Kiểm tra được các phụ thuộc THIẾT YẾU (kết nối database)
✅ Không yêu cầu xác thực
❌ Đừng gọi API bên thứ ba trong health check
❌ Đừng trả về nội dung nặng

Cạm bẫy quan trọng: health check phụ thuộc quá nhiều thứ.

Health check kiểm tra cả database, cache, và ba dịch vụ khác
    → một dịch vụ phụ chậm → mọi instance bị đánh dấu hỏng
    → ALB loại HẾT instance → dịch vụ sập hoàn toàn

Nguyên tắc: health check chỉ nên kiểm tra thứ mà instance đó thực sự cần để phục vụ request.

Các loại health check theo dịch vụ: | Dịch vụ | Giao thức hỗ trợ | |---|---| | ALB | CHỈ HTTP và HTTPS | | NLB | TCP, HTTP, HTTPS | | Route 53 | HTTP, HTTPS, TCP | | Auto Scaling | EC2 status check hoặc ELB |

Và một cấu hình ASG quan trọng liên quan:

aws autoscaling update-auto-scaling-group   --auto-scaling-group-name asg-ung-dung   --health-check-type ELB --health-check-grace-period 300

Mặc định ASG chỉ dùng EC2 status check — instance treo ở tầng ứng dụng nhưng máy vẫn sống sẽ không bị thay. Bật ELB mới bắt được.

Nhưng cẩn thận với grace-period quá ngắn:

Ứng dụng khởi động mất 4 phút, grace period đặt 60 giây
    → ASG coi instance mới là hỏng → chấm dứt
    → khởi chạy máy khác → lại chấm dứt
    → VÒNG LẶP vô tận, tốn tiền và không bao giờ có máy phục vụ

Và một công cụ chẩn đoán hữu ích: VPC Reachability Analyzer kiểm tra đường mạng giữa ALB và instance mà không cần gửi lưu lượng thật — nó chỉ ra chính xác security group hay NACL nào đang chặn.

Đáp án

C — Thêm lifecycle hook đưa instance sang trạng thái Terminating:Wait; cấu hình CloudWatch Events rule cho sự kiện EC2 Instance-terminate Lifecycle Action kèm Lambda function; kích hoạt CloudWatch agent đẩy log rồi tiếp tục việc chấm dứt.

Vì sao đúng

Đề nêu vấn đề rõ: instance bị chấm dứt tự động và log tạm thời biến mất theo — nên phải có cách giữ instance lại đủ lâu để lấy log.

Lifecycle hook làm đúng việc đó:

ASG quyết định chấm dứt instance
    ↓
Lifecycle hook TẠM DỪNG quá trình
    → instance chuyển sang trạng thái Terminating:Wait
    → giữ tới 1 giờ (mặc định), tối đa 48 giờ
    ↓
Trong lúc chờ: thu thập và đẩy log đi
    ↓
Gọi CompleteLifecycleAction → việc chấm dứt tiếp tục

Ba thành phần khớp chính xác với cơ chế của AWS: | Thành phần | Vì sao đúng | |---|---| | Terminating:Wait | đúng tên trạng thái khi hook chặn việc chấm dứt | | Sự kiện EC2 Instance-terminate Lifecycle Action | đúng tên sự kiện mà ASG phát ra | | CloudWatch agent đẩy log | agent đã cài sẵn, chỉ cần kích hoạt |

aws autoscaling put-lifecycle-hook   --lifecycle-hook-name thu-thap-log-truoc-khi-tat   --auto-scaling-group-name asg-ung-dung   --lifecycle-transition autoscaling:EC2_INSTANCE_TERMINATING   --heartbeat-timeout 300   --default-result CONTINUE

EventBridge rule bắt sự kiện:

{"source": ["aws.autoscaling"],
 "detail-type": ["EC2 Instance-terminate Lifecycle Action"]}

Và Lambda hoàn tất hook sau khi log đã được gửi:

autoscaling.complete_lifecycle_action(
    LifecycleHookName=hook, AutoScalingGroupName=asg,
    LifecycleActionToken=token, LifecycleActionResult='CONTINUE')

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

• **D. Lifecycle hook Terminating:Wait + sự kiện EC2 Instance Terminate SUCCESSFUL + SSM Run Command — đây là phương án gần nhất và có lifecycle hook đúng, nhưng nó sai loại sự kiện: EC2 Instance Terminate Successful phát ra SAU KHI instance đã bị chấm dứt xong — lúc đó máy không còn tồn tại để mà lấy log. Sự kiện đúng phải là Instance-terminate Lifecycle Action.
• **A. Lifecycle hook đưa sang trạng thái Pending:Wait — sai tên trạng thái: Pending:Wait là trạng thái khi instance đang được KHỞI CHẠY và bị hook chặn lại. Với việc chấm dứt, trạng thái đúng là Terminating:Wait.
• **B. Lifecycle hook Terminating:Wait + AWS Step Functions thu thập log — phần hook đúng nhưng thừa một tầng: Step Functions là công cụ điều phối; ở đây chỉ có một bước đơn giản (đẩy log rồi hoàn tất hook). Dùng Lambda trực tiếp gọn hơn, và đề hỏi cách "EASIEST".

Ghi nhớ

Hai loại lifecycle hook của Auto Scaling: | Loại | Trạng thái | Khi nào | |---|---|---| | EC2_INSTANCE_LAUNCHING | Pending:Wait | trước khi instance vào phục vụ | | EC2_INSTANCE_TERMINATING | Terminating:Wait | trước khi instance bị chấm dứt ← câu này |

Cặp trạng thái này là điểm phân biệt của câu hỏi.

Ba việc thường làm trong lifecycle hook lúc chấm dứt: | Việc | Lý do | |---|---| | Thu thập log để chẩn đoán | ← câu này | | Rút instance khỏi cụm một cách sạch sẽ | deregister khỏi service discovery | | Sao lưu dữ liệu cục bộ | trước khi máy biến mất |

Và lúc khởi chạy:

Tải cấu hình, làm nóng cache, đăng ký vào hệ thống giám sát
    → rồi mới cho instance nhận lưu lượng

Ba tham số của lifecycle hook: | Tham số | Ý nghĩa | |---|---| | HeartbeatTimeout | thời gian chờ trước khi tự động tiếp tục (30 giây – 7.200 giây) | | DefaultResult | CONTINUE hoặc ABANDON khi hết thời gian | | NotificationTargetARN | SNS hoặc SQS nhận thông báo (tuỳ chọn) |

DefaultResult là lựa chọn an toàn quan trọng:

CONTINUE:  hết giờ → tiếp tục chấm dứt bình thường
ABANDON:   hết giờ → chấm dứt ngay và không chạy hook còn lại

Với việc thu thập log, CONTINUE là đúng — mất log còn hơn giữ instance hỏng mãi.

Và có thể gia hạn nếu cần thêm thời gian:

autoscaling.record_lifecycle_action_heartbeat(
    LifecycleHookName=hook, AutoScalingGroupName=asg,
    LifecycleActionToken=token)

Ba tên sự kiện của Auto Scaling trong EventBridge — đừng nhầm: | Sự kiện | Khi nào phát | |---|---| | EC2 Instance-launch Lifecycle Action | hook lúc khởi chạy kích hoạt | | EC2 Instance-terminate Lifecycle Action | hook lúc chấm dứt kích hoạt ← đúng | | EC2 Instance Launch Successful | đã khởi chạy XONG | | EC2 Instance Terminate Successful | đã chấm dứt XONG — quá muộn để lấy log |

Và giải pháp căn bản hơn: đừng để log chỉ nằm trên instance. | Biện pháp | Chi tiết | |---|---| | CloudWatch agent đẩy log LIÊN TỤC | log có mặt ở CloudWatch ngay khi được ghi | | Ghi log ra stdout, dùng driver log của container | với ứng dụng container hoá | | Firehose → S3 | lưu trữ dài hạn, rẻ |

Nếu agent đã đẩy log liên tục thì lifecycle hook gần như không cần — log mới nhất chỉ chậm vài giây so với thời điểm instance bị chấm dứt. Lifecycle hook trở thành lưới an toàn cho phần log chưa kịp gửi.

Cấu hình CloudWatch agent đẩy log liên tục:

{"logs": {"logs_collected": {"files": {"collect_list": [{
  "file_path": "/var/log/ung-dung/*.log",
  "log_group_name": "/ung-dung/san-xuat",
  "log_stream_name": "{instance_id}"}]}}}}

Và một điều đáng làm hơn cả việc thu thập log: tìm hiểu vì sao health check HTTPS thất bại. | Nguyên nhân thường gặp | Cách kiểm tra | |---|---| | Chứng chỉ hết hạn hoặc không khớp tên miền | kiểm tra chứng chỉ trên instance | | Ứng dụng khởi động lâu hơn grace period | tăng HealthCheckGracePeriod | | Health check phụ thuộc dịch vụ bên ngoài đang chậm | đơn giản hoá endpoint health check | | Rò rỉ bộ nhớ khiến ứng dụng treo dần | theo dõi metric bộ nhớ |

Và một lưu ý về chẩn đoán: hãy bật EC2 Instance Metadata ghi vào log để biết instance nào, ở AZ nào, khởi chạy lúc nào. Khi phân tích nguyên nhân gốc trên hàng chục instance đã bị chấm dứt, thông tin đó là thứ giúp nhận ra mẫu — ví dụ chỉ instance ở một AZ cụ thể mới hỏng.

Đáp án

B — Dùng AWS Schema Conversion Tool (SCT) chuyển đổi lược đồ và mã ứng dụng cho khớp với database đích, rồi dùng AWS Database Migration Service (DMS) để di chuyển dữ liệu.

Vì sao đúng

Đề mô tả chính xác một cuộc di chuyển database KHÁC ENGINE (heterogeneous): Oracle tại chỗ → PostgreSQL trên AWS.

Và di chuyển khác engine luôn có hai giai đoạn riêng biệt: | Giai đoạn | Công cụ | Việc | |---|---|---| | ① Chuyển đổi LƯỢC ĐỒ và MÃ | AWS SCT | bảng, index, view, stored procedure, trigger, hàm | | ② Chuyển DỮ LIỆU | AWS DMS | dữ liệu thật, kèm CDC để ít gián đoạn |

Vì sao cần cả hai:

DMS chuyển được DỮ LIỆU
    → nhưng KHÔNG chuyển được đối tượng lược đồ phức tạp
    → không dịch được PL/SQL của Oracle sang PL/pgSQL

SCT chuyển được LƯỢC ĐỒ và MÃ
    → nhưng không chuyển dữ liệu

Và SCT có báo cáo đánh giá rất hữu ích trước khi bắt đầu:

SCT quét database nguồn → báo cáo:
    - bao nhiêu % đối tượng chuyển ĐƯỢC TỰ ĐỘNG
    - đối tượng nào cần SỬA TAY và vì sao
    - ước lượng công sức tính bằng giờ

Đây là thông tin quyết định để lập kế hoạch dự án — di chuyển Oracle sang PostgreSQL thường có 10–30% đối tượng cần can thiệp thủ công.

Đề còn nói rõ "entails a schema and CODE transformation before the proper data migration starts" — mô tả đúng trình tự SCT trước, DMS sau.

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

• **A. Cấu hình Launch Template tự chuyển đổi lược đồ và mã, rồi dùng DMS — đây là phương án gần nhất vì có DMS đúng, nhưng nó nhầm hoàn toàn về Launch Template: đó là mẫu cấu hình để khởi chạy EC2 instance (AMI, loại instance, security group). Nó không liên quan gì tới việc chuyển đổi lược đồ database.
• **C. Dùng Amazon Neptune chuyển đổi lược đồ và AWS Batch di chuyển dữ liệu — sai cả hai: Neptune là cơ sở dữ liệu ĐỒ THỊ, không phải công cụ chuyển đổi. Và AWS Batch là dịch vụ chạy công việc theo lô — dùng nó nghĩa là tự viết toàn bộ logic di chuyển.
• **D. Di chuyển khác engine không được hỗ trợ trên AWS — sai về mặt sự thật: AWS hỗ trợ rất tốt, và bộ đôi SCT + DMS được thiết kế đúng cho việc này. Đây là một trong những trường hợp sử dụng phổ biến nhất của DMS.

Ghi nhớ

Hai loại di chuyển database: | Loại | Nghĩa | Công cụ | |---|---|---| | Homogeneous (cùng engine) | Oracle → Oracle, MySQL → MySQL | chỉ DMS | | Heterogeneous (khác engine) | Oracle → PostgreSQL | SCT + DMS ← câu này |

Quy tắc nhận diện: đổi engine thì cần SCT.

Ba thành phần của AWS DMS: | Thành phần | Việc | |---|---| | Replication instance | máy chạy tiến trình sao chép | | Endpoint | thông tin kết nối nguồn và đích | | Task | định nghĩa di chuyển gì, theo cách nào |

Ba chế độ của DMS task: | Chế độ | Dùng khi | |---|---| | Full load | chấp nhận thời gian ngừng | | Full load + CDC | giảm thiểu thời gian ngừng — chuẩn cho sản xuất | | CDC only | dữ liệu đã có sẵn ở đích |

Yêu cầu cho CDC từ Oracle: bật supplemental logging và cấp quyền đọc redo log cho tài khoản DMS.

Những gì SCT chuyển đổi được: | Đối tượng | Mức tự động | |---|---| | Bảng, cột, kiểu dữ liệu | cao | | Index, ràng buộc | cao | | View | khá cao | | Stored procedure, function, trigger (PL/SQL → PL/pgSQL) | trung bình — thường cần sửa tay | | Package của Oracle | thấp — PostgreSQL không có khái niệm này |

Ba khác biệt Oracle và PostgreSQL hay gây vướng: | Khác biệt | Xử lý | |---|---| | Oracle coi chuỗi rỗng là NULL | PostgreSQL phân biệt — logic ứng dụng có thể đổi | | ROWNUM không tồn tại trong PostgreSQL | dùng LIMIT | | Sequence và NEXTVAL cú pháp khác | SCT chuyển được phần lớn | | Package, DBMS_* | phải viết lại bằng extension hoặc mã ứng dụng |

Và SCT còn chuyển đổi được MÃ ỨNG DỤNG:

SCT quét mã Java, C#, C++ tìm câu SQL nhúng
    → chuyển sang cú pháp PostgreSQL
    → đây là phần "code transformation" mà đề nhắc tới

Quy trình di chuyển đầy đủ:

① SCT đánh giá → biết mức độ phức tạp và công sức
② SCT chuyển lược đồ → sửa tay phần không tự động được
③ Áp lược đồ lên PostgreSQL đích
④ DMS full load → chuyển dữ liệu hiện có
⑤ DMS CDC → đồng bộ liên tục
⑥ Kiểm thử ứng dụng trên đích
⑦ Cắt chuyển: dừng ghi, chờ CDC bắt kịp, đổi chuỗi kết nối
⑧ Giữ Oracle chạy vài ngày phòng khi cần quay lui

Bước ⑥ là phần tốn thời gian nhất trong thực tế — sự khác biệt về kế hoạch thực thi truy vấn và ngữ nghĩa NULL thường chỉ lộ ra khi chạy thật.

Ba tính năng đáng dùng của DMS: | Tính năng | Việc | |---|---| | Data validation | so sánh từng dòng giữa nguồn và đích | | Table mapping và transformation rule | đổi tên bảng, lọc dữ liệu, đổi tên cột | | Premigration assessment | phát hiện vấn đề trước khi chạy |

Bật validation là bước không nên bỏ qua:

{"ValidationSettings": {"EnableValidation": true,
                        "ValidationMode": "ROW_LEVEL"}}

Metric quyết định thời điểm cắt chuyển: CDCLatencyTarget — nó cho biết đích còn tụt hậu bao nhiêu giây so với nguồn. Cắt chuyển khi con số này gần bằng 0.

Và một lời khuyên về lợi ích kinh tế: chuyển từ Oracle sang PostgreSQL thường tiết kiệm rất lớn về phí giấy phép — đó là động lực chính của phần lớn dự án loại này. Nhưng hãy tính cả công sức chuyển đổi và kiểm thử vào bài toán; với hệ thống có nhiều stored procedure phức tạp, chi phí nhân lực có thể vượt phần tiết kiệm trong năm đầu.

Đáp án

C — Run Command (thuộc AWS Systems Manager).

Vì sao đúng

Đề cần cấu hình EC2 instance mà KHÔNG cần kết nối RDP hay SSH — và Run Command là tính năng dành riêng cho việc đó.

Cách nó hoạt động:

SSM Agent chạy trên instance
    → định kỳ HỎI dịch vụ Systems Manager xem có lệnh nào không
    → nhận lệnh → thực thi → gửi kết quả về
        ↓
Không cần mở cổng 22 hay 3389
Không cần IP công khai
Không cần quản lý khoá SSH

Chú ý chiều kết nối: instance GỌI RA, AWS không gọi vào — đó là lý do không cần mở cổng inbound nào.

Chạy lệnh trên toàn đội máy bằng một lời gọi:

aws ssm send-command   --document-name "AWS-RunShellScript"   --targets "Key=tag:Ung Dung,Values=mmorpg"   --parameters 'commands=["systemctl restart may-chu-game"]'   --comment "Khoi dong lai dich vu game"

Và nhắm mục tiêu bằng THẺ là điểm mạnh với Auto Scaling:

Instance được ASG tạo và xoá liên tục
    → nhắm theo instance ID thì phải cập nhật liên tục
    → nhắm theo THẺ thì máy mới tự động nằm trong phạm vi

Ba lợi ích quan trọng so với SSH: | Lợi ích | Chi tiết | |---|---| | Phân quyền bằng IAM | ai chạy được lệnh gì, trên máy nào | | Ghi log mọi lệnh | CloudTrail + output vào S3 hoặc CloudWatch Logs | | Chạy hàng loạt | một lệnh cho hàng trăm máy, có kiểm soát tốc độ |

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

• **D. EC2Config — đây là phương án gần nhất vì cũng là agent chạy trên instance, nhưng nó là thành phần cũ và chỉ dành cho Windows: EC2Config lo các tác vụ khởi tạo (đặt tên máy, cấu hình mạng, xử lý user data). Nó đã được thay thế bằng EC2Launch và SSM Agent, và không phải cơ chế chạy lệnh từ xa.
• **A. AWS Config — sai vai trò dịch vụ: AWS Config ghi lại và đánh giá cấu hình tài nguyên so với quy tắc. Nó không chạy lệnh trên instance.
• **B. AWS CodePipeline — là dịch vụ CI/CD: nó điều phối quy trình build và deploy mã nguồn. Không phải công cụ quản trị hệ thống.

Ghi nhớ

Các tính năng chính của AWS Systems Manager: | Tính năng | Việc | |---|---| | Run Command | chạy lệnh hoặc script trên nhiều instance ← câu này | | Session Manager | phiên shell tương tác, thay thế SSH và RDP | | Patch Manager | tự động vá lỗi hệ điều hành theo lịch | | State Manager | giữ instance ở trạng thái cấu hình mong muốn | | Parameter Store | lưu cấu hình và bí mật | | Inventory | kiểm kê phần mềm đã cài | | Automation | quy trình vận hành nhiều bước | | Fleet Manager | giao diện quản lý máy chủ từ xa |

Run Command và Session Manager — phân biệt: | | Run Command | Session Manager | |---|---|---| | Kiểu tương tác | chạy lệnh rồi trả kết quả | phiên shell TƯƠNG TÁC | | Nhiều máy cùng lúc | ✅ hàng trăm | ❌ một máy mỗi phiên | | Phù hợp | tự động hoá, thao tác hàng loạt | chẩn đoán, khám phá |

Ba yêu cầu để Systems Manager hoạt động: | Yêu cầu | Chi tiết | |---|---| | SSM Agent đã cài | có sẵn trong AMI Amazon Linux, Ubuntu, Windows gần đây | | IAM role gắn vào instance | policy AmazonSSMManagedInstanceCore | | Đường mạng tới endpoint SSM | NAT gateway hoặc VPC endpoint |

Với instance trong private subnet không có NAT, cần ba VPC endpoint:

com.amazonaws.<region>.ssm
com.amazonaws.<region>.ssmmessages
com.amazonaws.<region>.ec2messages

Thiếu một trong ba là instance không hiện trong danh sách managed instance — và đây là nguyên nhân phổ biến nhất của lỗi "instance không xuất hiện".

Các document dựng sẵn hay dùng: | Document | Việc | |---|---| | AWS-RunShellScript | chạy lệnh shell trên Linux | | AWS-RunPowerShellScript | chạy PowerShell trên Windows | | AWS-ConfigureAWSPackage | cài hoặc gỡ gói AWS (ví dụ CloudWatch agent) | | AWS-UpdateSSMAgent | cập nhật chính SSM Agent | | AWS-InstallApplication | cài phần mềm trên Windows |

Ba tuỳ chọn kiểm soát khi chạy trên nhiều máy: | Tuỳ chọn | Việc | |---|---| | --max-concurrency | bao nhiêu máy chạy cùng lúc (số hoặc phần trăm) | | --max-errors | dừng lại nếu quá số lỗi cho phép | | --output-s3-bucket-name | lưu output vào S3 |

Hai tuỳ chọn đầu rất quan trọng cho đội máy lớn:

aws ssm send-command --document-name "AWS-RunShellScript"   --targets "Key=tag:Ung Dung,Values=mmorpg"   --max-concurrency "10%" --max-errors "5"   --parameters 'commands=["./cap-nhat.sh"]'

Chạy 10% số máy mỗi lần, dừng nếu quá 5 máy lỗi — tránh việc một script hỏng làm sập cả đội game cùng lúc.

Ba cách nhắm mục tiêu: | Cách | Cú pháp | |---|---| | Theo thẻ | Key=tag:MoiTruong,Values=san-xuat ← tốt nhất với ASG | | Theo instance ID | Key=InstanceIds,Values=i-0abc,i-0def | | Theo resource group | Key=resource-groups:Name,Values=nhom-game |

Và State Manager đáng biết cho việc giữ cấu hình nhất quán:

Thay vì chạy lệnh thủ công mỗi lần:
    → State Manager áp cấu hình theo lịch
    → instance mới do ASG tạo cũng tự được áp
    → cấu hình không bị trôi dạt theo thời gian

Với đội máy do Auto Scaling quản lý như đề mô tả, State Manager thường phù hợp hơn Run Command cho các cấu hình cần duy trì lâu dài.

Và một lời khuyên về bảo mật: sau khi có Systems Manager, hãy đóng hẳn cổng 22 và 3389 trong security group. Nhiều tổ chức cài SSM nhưng vẫn để cổng SSH mở "phòng khi cần" — và đó vẫn là bề mặt tấn công lớn nhất còn lại.