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

Đáp án

D — Khởi tạo (initialize) hoặc "pre-warm" EBS volume trước khi đưa vào sản xuất.

Vì sao đúng

Triệu chứng đề mô tả là hành vi đã được AWS ghi trong tài liệu, không phải lỗi.

⚠ Điểm mấu chốt — volume tạo từ snapshot được nạp LƯỜI từ S3:

Tạo volume từ snapshot
        ↓
    Volume "sẵn sàng" ngay và mount được
        ↓
    NHƯNG dữ liệu vẫn nằm trên S3
        ↓
    Mỗi khối chỉ được KÉO VỀ khi LẦN ĐẦU được đọc
        ↓
    → lần đọc đầu tiên của mỗi khối CHẬM HƠN ĐÁNG KỂ
    → những lần sau thì nhanh bình thường
        ↓
    → đúng triệu chứng "độ trễ tăng ở lần truy cập đầu tiên"

⚠ Hai cách khắc phục — một miễn phí, một có phí:

Cách 1 — Pre-warm thủ công (MIỄN PHÍ)
        ↓
    Đọc toàn bộ volume một lượt để ép kéo hết dữ liệu về:

    # Volume có dữ liệu — đọc toàn bộ, không ghi gì
    sudo dd if=/dev/nvme1n1 of=/dev/null bs=1M
    # hoặc dùng fio để nhanh hơn
    sudo fio --filename=/dev/nvme1n1 --rw=read --bs=1M \
             --iodepth=32 --ioengine=libaio --direct=1 \
             --name=khoi-tao

Cách 2 — Fast Snapshot Restore (CÓ PHÍ)
        ↓
    Bật FSR cho snapshot ở một AZ cụ thể
        ↓
    → mọi volume tạo từ snapshot đó đạt hiệu năng
      TỐI ĐA NGAY LẬP TỨC, không cần pre-warm
        ↓
    → tính phí theo GIỜ cho mỗi cặp snapshot + AZ

⚠ Một cảnh báo quan trọng về lệnh dùng để pre-warm:

Volume TRỐNG (mới tạo, chưa có dữ liệu)
        ↓
    → KHÔNG cần pre-warm gì cả, đã đạt hiệu năng tối đa

Volume có DỮ LIỆU (tạo từ snapshot)
        ↓
    → CHỈ ĐỌC, dùng "if=" và "of=/dev/null"
    → TUYỆT ĐỐI không ghi đè bằng dd — sẽ MẤT DỮ LIỆU

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

• C (tăng read-ahead cho tải đọc nhiều trên st1 và sc1) — đây là phương án gần nhất và là một khuyến nghị THẬT của AWS, nhưng nó dành riêng cho volume HDD với tải đọc TUẦN TỰ, và nó cải thiện thông lượng nói chung — không giải quyết vấn đề độ trễ ở lần đọc đầu tiên do lazy loading.

• A (dùng instance EBS-optimized) — cấp băng thông riêng giữa instance và EBS, tốt cho hiệu năng chung. Nhưng vấn đề ở đây là dữ liệu chưa được kéo về từ S3, không phải nghẽn băng thông. (Ngoài ra mọi instance thế hệ mới đã EBS-optimized mặc định.)

• B (dùng RAID 0 để tận dụng tối đa tài nguyên instance) — RAID 0 cộng IOPS và throughput của nhiều volume, nhưng mỗi volume vẫn phải nạp lười riêng — vấn đề không hề mất đi.

Ghi nhớ

⚠ Hiệu năng volume tạo từ snapshot — bảng phải thuộc: | Tình huống | Hiệu năng ban đầu | |---|---| | Volume mới, TRỐNG | tối đa ngay — không cần làm gì | | Volume tạo từ SNAPSHOT | chậm ở lần đọc đầu của mỗi khối | | Sau khi pre-warm | tối đa | | Bật Fast Snapshot Restore | tối đa ngay, có phí |

Từ khoá nhận diện:

"volume từ snapshot chậm lần đầu" → lazy loading — pre-warm hoặc FSR "cần hiệu năng tối đa ngay khi khôi phục" → Fast Snapshot Restore "volume mới trống có cần pre-warm không" → KHÔNG "tăng read-ahead" → chỉ cho st1/sc1 với tải tuần tự "vượt trần IOPS của một volume" → RAID 0 hoặc io2 Block Express

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Pre-warm đã xong chưa | theo dõi VolumeReadOps — giảm hẳn khi đã đọc hết | | Volume có chạm trần không | VolumeQueueLength và BurstBalance | | FSR đã bật chưa | describe-fast-snapshot-restores |

Và một lời khuyên khi lập kế hoạch khôi phục thảm hoạ: hãy đo thời gian pre-warm cho volume kích thước thật của bạn, và tính nó vào RTO. Một volume 2 TB tạo từ snapshot cần đọc hết 2 TB dữ liệu từ S3 trước khi đạt hiệu năng bình thường — đó có thể là hàng chục phút mà nhiều đội không tính tới, rồi ngạc nhiên vì sao hệ thống "đã khôi phục xong" mà vẫn chạy chậm chạp suốt buổi sáng đầu tiên.

Đáp án

D — Đối tượng được yêu cầu KHÔNG có trên ORIGIN SERVER; origin sinh ra lỗi 404 và CloudFront chỉ chuyển tiếp lỗi đó về cho người dùng.

Vì sao đúng

Cần phân biệt rõ CloudFront TẠO RA lỗi và CloudFront CHUYỂN TIẾP lỗi của origin.

⚠ Điểm mấu chốt — CloudFront là bên trung gian, nó không tự biết tệp nào tồn tại:

Người dùng yêu cầu /anh/khong-ton-tai.jpg
        ↓
    CloudFront kiểm tra cache → không có (cache miss)
        ↓
    CloudFront hỏi ORIGIN
        ↓
    Origin (S3 hoặc web server) trả về 404
        ↓
    CloudFront CHUYỂN TIẾP 404 đó về cho người dùng
        ↓
    → lỗi do ORIGIN sinh ra, CloudFront chỉ truyền lại

⚠ Vì sao "cache miss" không phải nguyên nhân:

Cache miss
        ↓
    → chỉ nghĩa là CloudFront chưa có bản sao ở edge đó
        ↓
    → CloudFront sẽ đi hỏi origin
        ↓
    → nếu origin có tệp → trả về 200, và cache lại
    → nếu origin KHÔNG có → trả về 404
        ↓
    → cache miss là chuyện BÌNH THƯỜNG, không phải lỗi

⚠ Và một hành vi cần biết: CloudFront CÓ CACHE cả lỗi 404:

CloudFront cache phản hồi lỗi trong 10 GIÂY (mặc định)
        ↓
    → gọi là "negative caching"
    → tránh dồn request lỗi xuống origin
        ↓
    Hệ quả: sau khi bạn ĐÃ tải tệp lên origin
        ↓
    → vẫn có thể nhận 404 trong tối đa 10 giây
    → chỉnh được bằng Custom Error Response

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

• B (đối tượng không được CloudFront tìm thấy và CHÍNH CLOUDFRONT sinh ra lỗi 404) — đây là phương án gần nhất và rất tinh vi: kết quả người dùng thấy thì giống hệt, nhưng cơ chế thì khác. CloudFront không có danh mục nội dung để biết tệp nào tồn tại; nó luôn phải hỏi origin. Phân biệt được điều này quyết định bạn đi tìm nguyên nhân ở đâu.

• A (404 sinh ra do cache miss) — hiểu sai bản chất của cache miss: đó là trạng thái bình thường, dẫn tới việc đi hỏi origin, không phải một lỗi.

• C (CloudFront không kết nối được tới origin) — khi đó lỗi sẽ là 502 Bad Gateway hoặc 504 Gateway Timeout, không phải 404.

Ghi nhớ

⚠ Mã lỗi của CloudFront và ai sinh ra chúng — bảng phải thuộc: | Mã | Ai sinh ra | Nguyên nhân | |---|---|---| | 404 | ORIGIN | không có tệp đó | | 403 | CloudFront hoặc origin | WAF, geo restriction, thiếu OAC, signed URL sai | | 502 | CloudFront | origin trả phản hồi hỏng, lỗi bắt tay SSL | | 503 | CloudFront | origin quá tải, hoặc CloudFront đang giới hạn | | 504 | CloudFront | origin không trả lời kịp (mặc định 30 giây) |

Từ khoá nhận diện:

"404 qua CloudFront" → tệp không có ở ORIGIN "403 với S3 origin" → thiếu OAC, hoặc bucket policy chặn "502" → origin trả phản hồi không hợp lệ, hoặc lỗi TLS "504" → origin quá chậm — tăng origin response timeout "cache miss" → bình thường, không phải lỗi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Origin có tệp không | curl -I <origin-url>/duong-dan | | CloudFront ghi nhận gì | access log, cột sc-status và x-edge-result-type | | Lỗi có bị cache không | gọi lại sau 10 giây xem còn 404 không |

Và một mẹo chẩn đoán tiết kiệm rất nhiều thời gian với mọi lỗi qua CloudFront: luôn gọi thẳng vào origin trước tiên. Nếu origin cũng trả 404 thì vấn đề nằm ở nội dung hoặc đường dẫn, và bạn không cần đụng tới cấu hình CloudFront chút nào — còn nếu origin trả 200 mà CloudFront trả 404, thì mới đến lượt cache behavior, path pattern và các quy tắc viết lại URI.

Đáp án

C — Chứng chỉ ACM không được yêu cầu (hoặc nhập) ở CÙNG Region với load balancer.

Vì sao đúng

ACM là dịch vụ theo Region, và chứng chỉ chỉ hiện ra ở đúng Region nơi nó được tạo.

⚠ Điểm mấu chốt — quy tắc Region của chứng chỉ ACM:

Dùng cho ALB, NLB, API Gateway
        ↓
    Chứng chỉ phải ở CÙNG REGION với tài nguyên đó
        ↓
    ALB ở ap-southeast-1 → chứng chỉ phải ở ap-southeast-1

Dùng cho CLOUDFRONT
        ↓
    Chứng chỉ BẮT BUỘC ở us-east-1 (N. Virginia)
        ↓
    → vì CloudFront là dịch vụ TOÀN CẦU, và AWS
      chọn us-east-1 làm nơi lưu chứng chỉ cho nó

⚠ Triệu chứng rất đặc trưng và dễ gây hoang mang:

Bạn nhập chứng chỉ thành công, thấy trạng thái "Issued"
        ↓
    Nhưng mở cấu hình ALB, ô chọn chứng chỉ TRỐNG TRƠN
        ↓
    → không có thông báo lỗi nào
    → không có gợi ý nào về nguyên nhân
        ↓
    → vì bạn đang xem ACM ở MỘT Region,
      còn ALB thì tìm chứng chỉ ở Region CỦA NÓ

⚠ Cách sửa:

# Kiểm tra chứng chỉ đang ở Region nào
aws acm list-certificates --region ap-southeast-1
aws acm list-certificates --region us-east-1

# Nhập lại vào ĐÚNG Region của ALB
aws acm import-certificate --region ap-southeast-1 \
  --certificate fileb://chung-chi.pem \
  --private-key fileb://khoa-rieng.pem \
  --certificate-chain fileb://chuoi-ca.pem

Xem thêm câu #11738: cùng ràng buộc Region nhưng cho CloudFront, nơi chứng chỉ bắt buộc ở us-east-1. Và #11725, #11749 về việc chứng chỉ ACM công khai không cài lên EC2 được.

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

• D (chứng chỉ dùng với ALB phải nhập ở Region US East N. Virginia) — đây là phương án gần nhất và là sự nhầm lẫn phổ biến nhất: quy tắc us-east-1 chỉ áp cho CLOUDFRONT, không áp cho ALB. ALB cần chứng chỉ cùng Region với chính nó.

• A (ALB không hỗ trợ chứng chỉ ACM, phải cài lên EC2) — sai; ALB tích hợp rất tốt với ACM, đó là cách dùng phổ biến nhất. (Việc "cài lên EC2" lại là chuyện khác — và chứng chỉ ACM công khai thì không cài lên EC2 được.)

• B (ACM không tích hợp trực tiếp với ALB, phải qua CloudFront) — sai hoàn toàn; ALB là một trong những dịch vụ tích hợp ACM đầu tiên và sâu nhất.

Ghi nhớ

⚠ Chứng chỉ ACM phải ở Region nào — bảng phải thuộc: | Dịch vụ | Region của chứng chỉ | |---|---| | CloudFront | BẮT BUỘC us-east-1 | | ALB / NLB | cùng Region với load balancer | | API Gateway (regional) | cùng Region | | API Gateway (edge-optimized) | us-east-1 | | App Runner, AppSync | cùng Region | | Elastic Beanstalk | cùng Region (qua ELB) |

Từ khoá nhận diện:

"chứng chỉ không hiện trong danh sách chọn" → sai Region "chứng chỉ cho CloudFront" → us-east-1, BẮT BUỘC "chứng chỉ cho ALB" → cùng Region với ALB "cài chứng chỉ ACM lên EC2" → KHÔNG ĐƯỢC (dùng AWS Private CA) "chứng chỉ mua ngoài" → import-certificate — nhưng ACM không tự gia hạn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chứng chỉ ở Region nào | list-certificates với --region từng Region | | Đang được dùng ở đâu | describe-certificate, xem InUseBy | | Còn hạn bao lâu | describe-certificate, xem NotAfter |

Và một mẹo giúp không bao giờ mất thời gian vì lỗi này nữa: khi ô chọn chứng chỉ trống trơn, việc đầu tiên cần làm là kiểm tra bộ chọn Region ở góc trên bên phải console. Đây là một trong những lỗi tốn thời gian nhất trên AWS chính vì nó hoàn toàn im lặng — không có cảnh báo, không có gợi ý, chỉ là một danh sách rỗng trông y hệt như khi bạn chưa tạo chứng chỉ nào.

Đáp án

B — AuroraReplicaLagMaximum.

Vì sao đúng

Đề hỏi độ trễ TỐI ĐA giữa instance chính và các replica — và tên chỉ số nói rõ điều đó.

⚠ Điểm mấu chốt — ba chỉ số độ trễ replica của Aurora:

AuroraReplicaLag
        ↓
    Độ trễ của MỘT replica cụ thể
    (đo trên chính instance đó)

AuroraReplicaLagMaximum        ← đề hỏi cái này
        ↓
    Độ trễ LỚN NHẤT trong TOÀN BỘ cluster
    → replica tụt hậu nhất đang trễ bao nhiêu

AuroraReplicaLagMinimum
        ↓
    Độ trễ NHỎ NHẤT trong cluster
    → replica nhanh nhất

⚠ Vì sao Maximum mới là con số cần cho báo cáo:

Cluster có 5 replica:
        replica 1: trễ 5 ms
        replica 2: trễ 8 ms
        replica 3: trễ 6 ms
        replica 4: trễ 12 ms
        replica 5: trễ 850 ms   ← có vấn đề
        ↓
    Nhìn trung bình: khoảng 176 ms — che mất vấn đề
    Nhìn Maximum:    850 ms — thấy ngay có replica tụt hậu
        ↓
    → với độ trễ, luôn nhìn giá trị XẤU NHẤT

⚠ Và vì sao độ trễ replica quan trọng đến vậy:

Ứng dụng ghi vào writer endpoint
        ↓
    Rồi đọc ngay qua reader endpoint
        ↓
    Nếu replica đang trễ 850 ms
        ↓
    → người dùng KHÔNG THẤY dữ liệu vừa ghi
    → biểu hiện: "tôi vừa lưu mà nó biến mất"
        ↓
    → chỗ này thường bị đổ nhầm cho lỗi ứng dụng

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

• D (AuroraReplicaLag) — đây là phương án gần nhất và là chỉ số có thật, nhưng nó đo độ trễ của MỘT replica, không phải giá trị lớn nhất toàn cluster. Đề hỏi "maximum amount of lag", nên phải là AuroraReplicaLagMaximum.

• A (AuroraBinlogReplicaLag) — cũng là chỉ số có thật, nhưng nó đo độ trễ của replica dùng BINLOG — tức là replica ngoài cluster Aurora (ví dụ một MySQL bên ngoài sao chép từ Aurora). Không phải replica trong chính cluster.

• C (InsertLatency) — đo độ trễ của thao tác INSERT, hoàn toàn khác với độ trễ sao chép.

Ghi nhớ

⚠ Các chỉ số độ trễ của Aurora — bảng phải thuộc: | Chỉ số | Đo gì | |---|---| | AuroraReplicaLag | độ trễ của một replica (mili giây) | | AuroraReplicaLagMaximum | độ trễ LỚN NHẤT trong cluster | | AuroraReplicaLagMinimum | độ trễ nhỏ nhất trong cluster | | AuroraBinlogReplicaLag | độ trễ của replica ngoài cluster, qua binlog | | AuroraGlobalDBReplicationLag | độ trễ của Aurora Global Database giữa các Region |

Từ khoá nhận diện:

"độ trễ tối đa giữa primary và các replica" → AuroraReplicaLagMaximum "độ trễ của một replica cụ thể" → AuroraReplicaLag "replica ngoài cluster (MySQL bên ngoài)" → AuroraBinlogReplicaLag "độ trễ giữa các Region" → AuroraGlobalDBReplicationLag "RDS thường (không phải Aurora)" → ReplicaLag (đơn vị GIÂY) |

⚠ Aurora và RDS thường — cơ chế sao chép khác nhau hoàn toàn: | | Aurora | RDS thường | |---|---|---| | Cơ chế | tầng lưu trữ chia sẻ | sao chép log tới từng replica | | Độ trễ điển hình | mili giây | giây | | Đơn vị chỉ số | mili giây | giây | | Số replica | tối đa 15 | tối đa 5 | | Failover | dưới 30 giây | 60–120 giây |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Replica nào đang tụt hậu | vẽ AuroraReplicaLag theo từng DBInstanceIdentifier | | Toàn cluster có ổn không | AuroraReplicaLagMaximum | | Vì sao tụt hậu | Performance Insights trên chính replica đó |

Và một lời khuyên khi thiết kế ứng dụng dùng reader endpoint: hãy đặt cảnh báo trên AuroraReplicaLagMaximum và cho ứng dụng đọc từ writer endpoint trong những luồng nhạy cảm với độ trễ. Aurora thường chỉ trễ vài mili giây và phần lớn ứng dụng không bận tâm — nhưng những luồng kiểu "lưu xong rồi hiển thị lại ngay" sẽ hiện ra dưới dạng lỗi khó hiểu và không tái hiện được, đúng vào những lúc hệ thống đang bận nhất.

Đáp án

C — AWS Shield Advanced.

Vì sao đúng

Đề nêu hai thứ mà chỉ Shield Advanced mới có, và cả hai đều không có ở bản miễn phí.

⚠ Điểm mấu chốt — Shield Standard và Shield Advanced khác nhau rất xa:

AWS Shield Standard
        ↓
    MIỄN PHÍ, TỰ ĐỘNG cho mọi khách hàng
    Chống DDoS tầng 3/4 phổ biến (SYN flood, UDP reflection)
        ↓
    → KHÔNG có đội hỗ trợ riêng
    → KHÔNG hoàn tiền
    → KHÔNG có báo cáo chi tiết về đợt tấn công

AWS Shield Advanced
        ↓
    CÓ PHÍ — cam kết 1 năm, tính theo tháng + phí truyền dữ liệu
        ↓
    → Shield Response Team hỗ trợ 24/7
    → COST PROTECTION: hoàn tiền phần chi phí tăng thêm
      do DDoS gây ra (EC2, ELB, CloudFront, Route 53, Global Accelerator)
    → bảo vệ cả tầng 7 khi kết hợp WAF
    → WAF ĐƯỢC MIỄN PHÍ khi có Shield Advanced

⚠ Cost protection hoạt động thế nào — đây là điểm đề nhấn mạnh:

Bị DDoS → tài nguyên tự co giãn để chịu tải
        ↓
    → hoá đơn tăng vọt (thêm instance, thêm truyền dữ liệu)
        ↓
    Mở yêu cầu hoàn tiền với AWS
        ↓
    → AWS hoàn lại phần chi phí TĂNG THÊM do đợt tấn công

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

• D (AWS Shield — bản Standard) — đây là phương án gần nhất và đã bảo vệ bạn ở mức cơ bản, miễn phí. Nhưng nó không có đội hỗ trợ 24/7 và không hoàn tiền — đúng hai thứ mà đề yêu cầu.

• A (AWS WAF) — lọc request độc hại ở tầng 7 (SQL injection, XSS, bot). Nó là một phần của giải pháp chống DDoS tầng ứng dụng, nhưng không có SRT, không có cost protection.

• B ("AWS DDoS OpsTeam") — không tồn tại. Tên đúng là AWS Shield Response Team (SRT), và nó là một phần của Shield Advanced.

Ghi nhớ

⚠ Shield Standard và Shield Advanced — bảng phải thuộc: | | Shield Standard | Shield Advanced | |---|---|---| | Chi phí | MIỄN PHÍ, tự động | có phí, cam kết 1 năm | | Bảo vệ tầng 3/4 | có | có, nâng cao hơn | | Bảo vệ tầng 7 | không | có (qua WAF) | | Đội hỗ trợ 24/7 (SRT) | KHÔNG | CÓ | | Hoàn tiền chi phí do DDoS | KHÔNG | CÓ | | WAF | tính phí riêng | MIỄN PHÍ kèm theo | | Báo cáo và chỉ số chi tiết | không | có |

Từ khoá nhận diện:

"hỗ trợ 24/7 khi bị DDoS", "hoàn tiền" → Shield Advanced "chống DDoS cơ bản, miễn phí" → Shield Standard "SQL injection, XSS, bot" → WAF "quản lý WAF trên nhiều tài khoản" → Firewall Manager "AWS DDoS OpsTeam" → KHÔNG TỒN TẠI (đúng là Shield Response Team)

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có đang bị tấn công không | Shield console → mục Events; chỉ số DDoSDetected | | Tài nguyên nào được bảo vệ | list-protections của Shield | | Cost protection có áp không | mở yêu cầu qua AWS Support kèm thời điểm tấn công |

Và một lời khuyên khi cân nhắc Shield Advanced: hãy uỷ quyền trước cho Shield Response Team ngay khi đăng ký, đừng chờ tới lúc bị tấn công. Nếu chưa có sẵn uỷ quyền, SRT phải chờ bạn phê duyệt trong lúc sự cố đang diễn ra — và đó chính là những phút mà bạn cần họ hành động ngay chứ không phải chờ ai đó tìm thấy email lúc hai giờ sáng.

Đáp án

B, D — hai đặc điểm của Redis Multi-AZ:

• D — Khi chọn replica để thăng cấp thành primary, ElastiCache for Redis chọn replica có ĐỘ TRỄ SAO CHÉP THẤP NHẤT.
• B — Bạn chỉ thăng cấp read replica thành primary THỦ CÔNG được (khi cluster mode tắt) nếu Multi-AZ và automatic failover đang TẮT.

Vì sao đúng

⚠ Điều D — chọn replica ít tụt hậu nhất để giảm mất dữ liệu:

Primary hỏng
        ↓
    ElastiCache so độ trễ sao chép của mọi replica
        ↓
    Chọn replica TRỄ ÍT NHẤT
        ↓
    → thăng cấp nó thành primary mới
        ↓
    → giảm tối đa lượng dữ liệu bị mất
      (vì Redis sao chép BẤT ĐỒNG BỘ)

⚠ Điều B — hai cơ chế loại trừ nhau:

Multi-AZ + automatic failover BẬT
        ↓
    ElastiCache TỰ quản việc thăng cấp
        ↓
    → bạn KHÔNG can thiệp thủ công được
    → nếu cho phép, hai bên sẽ tranh nhau quyết định

Muốn tự thăng cấp bằng tay
        ↓
    → phải TẮT Multi-AZ và automatic failover trước

⚠ Và điểm quan trọng nhất phải nhớ về Redis — sao chép BẤT ĐỒNG BỘ:

Primary ghi dữ liệu, trả về ngay cho client
        ↓
    Sau đó mới đẩy sang replica
        ↓
    → primary chết đột ngột
    → những ghi chưa kịp sao chép BỊ MẤT
        ↓
    → đây là lý do điều E sai, và cũng là lý do
      điều D quan trọng (chọn replica ít mất nhất)

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

• A (primary khởi động lại thì bị xoá sạch dữ liệu, rồi nạp lại từ replica mới nhất) — đây là phương án gần nhất và mô tả hành vi của Memcached, không phải Redis. Redis giữ dữ liệu qua lần khởi động lại nhờ cơ chế bền vững; và nếu có nạp lại thì cũng không phải "từ replica mới nhất".

• C (khởi động lại primary do khách hàng khởi xướng sẽ kích hoạt automatic failover, nên phải tắt failover trước) — sai: reboot do bạn chủ động KHÔNG kích hoạt failover. ElastiCache phân biệt được reboot có kế hoạch với sự cố thật.

• E (sao chép của Redis là ĐỒNG BỘ trong cấu hình Multi-AZ) — sai và là hiểu nhầm quan trọng nhất: Redis luôn sao chép BẤT ĐỒNG BỘ, kể cả với Multi-AZ. (Khác hẳn RDS Multi-AZ — nơi sao chép là đồng bộ.)

Ghi nhớ

⚠ Redis và Memcached — bảng phải thuộc: | | Redis | Memcached | |---|---|---| | Kiểu dữ liệu | phong phú (list, set, sorted set, stream, hash) | chỉ chuỗi | | Bền vững | có (snapshot, AOF) | không | | Sao chép | có, BẤT ĐỒNG BỘ | không | | Multi-AZ và failover | có | không | | Đa luồng | ít hơn | có — mở rộng theo lõi tốt | | Chọn khi | cần bền vững, bảng xếp hạng, pub/sub, phiên làm việc | cache đơn giản, nhiều lõi |

Từ khoá nhận diện:

"Redis sao chép đồng bộ" → LUÔN SAI — luôn bất đồng bộ "chọn replica nào để thăng cấp" → replica trễ ít nhất "thăng cấp thủ công" → phải TẮT Multi-AZ và automatic failover "cache mất dữ liệu khi reboot" → Memcached, không phải Redis "cần chia tải đọc" → read replica của Redis

⚠ Ba khái niệm của Redis trên ElastiCache — dễ lẫn: | Khái niệm | Nội dung | |---|---| | Cluster mode DISABLED | một shard, một primary + tối đa 5 replica | | Cluster mode ENABLED | nhiều shard, dữ liệu phân mảnh — mở rộng ghi được | | Multi-AZ + automatic failover | replica ở AZ khác, tự thăng cấp khi primary hỏng |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Multi-AZ đã bật chưa | describe-replication-groups, xem AutomaticFailover | | Failover mất bao lâu | test-failover rồi bấm giờ | | Replica trễ bao nhiêu | chỉ số ReplicationLag |

Và một điều cần nói rõ với đội phát triển khi thiết kế trên Redis: sao chép bất đồng bộ nghĩa là một lần failover CÓ THỂ làm mất vài ghi gần nhất. Với dữ liệu cache thì điều đó vô hại — cache trượt rồi nạp lại là xong. Nhưng nếu Redis đang giữ thứ gì đó không tái tạo được — phiên làm việc, hàng đợi công việc, bộ đếm — thì hãy chấp nhận rằng một số bản ghi sẽ biến mất, và thiết kế ứng dụng để chịu được điều đó.

Đáp án

C — Cấu hình Amazon RDS Proxy để gộp và dùng chung các kết nối cơ sở dữ liệu.

Vì sao đúng

Đề mô tả chính xác vấn đề mà RDS Proxy sinh ra để giải: ứng dụng serverless tạo bùng nổ kết nối mới.

⚠ Điểm mấu chốt — vì sao serverless và cơ sở dữ liệu quan hệ xung khắc:

Lưu lượng tăng vọt
        ↓
    Lambda khởi chạy hàng trăm phiên bản đồng thời
        ↓
    MỖI phiên bản mở một kết nối MỚI tới RDS
        ↓
    → mỗi kết nối tốn BỘ NHỚ và CPU của cơ sở dữ liệu
    → chạm max_connections → từ chối kết nối
    → cơ sở dữ liệu kiệt sức đúng lúc cần nó nhất

⚠ RDS Proxy đứng giữa và gộp kết nối lại:

Lambda ×500 → RDS Proxy → RDS (chỉ ~20 kết nối thật)
        ↓
    Proxy duy trì một POOL kết nối tới cơ sở dữ liệu
        ↓
    Nhiều client dùng chung một kết nối thật
      (connection multiplexing)
        ↓
    → cơ sở dữ liệu chỉ thấy vài chục kết nối ổn định
    → không còn bùng nổ, không còn kiệt bộ nhớ

⚠ Và RDS Proxy còn cho hai thứ nữa rất đáng giá:

Failover nhanh hơn tới 66%
        ↓
    Proxy giữ kết nối của client, tự nối lại sang
    instance mới sau failover
        ↓
    → ứng dụng không thấy đứt kết nối

Xác thực bằng IAM và Secrets Manager
        ↓
    → ứng dụng KHÔNG cần biết mật khẩu cơ sở dữ liệu
    → proxy lấy chứng chỉ từ Secrets Manager

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

• B (chạy DB instance ở chế độ Multi-AZ để cải thiện hiệu năng) — đây là phương án gần nhất vì Multi-AZ đúng là một cải tiến thật. Nhưng nó dành cho SẴN SÀNG CAO, và bản standby KHÔNG phục vụ đọc — nó không giảm được một kết nối nào. Thậm chí sao chép đồng bộ còn làm độ trễ ghi tăng nhẹ.

• A (dùng Lambda để quản lý kết nối RDS theo tải) — tự dựng lại thứ RDS Proxy đã làm sẵn, và rất khó làm đúng: Lambda không chia sẻ trạng thái giữa các phiên bản, nên không có "pool" thật sự nào để quản.

• D (dùng Enhanced Monitoring để quản lý connection pool) — hiểu sai công dụng: Enhanced Monitoring chỉ QUAN SÁT chỉ số cấp hệ điều hành. Nó không quản lý gì cả.

Ghi nhớ

⚠ RDS Proxy — bảng phải thuộc: | Đặc điểm | Nội dung | |---|---| | Gộp kết nối (pooling) | nhiều client dùng chung ít kết nối thật | | Failover nhanh hơn tới 66% | proxy giữ kết nối client, tự nối lại | | Xác thực qua IAM và Secrets Manager | ứng dụng không cần biết mật khẩu | | Hỗ trợ | MySQL, PostgreSQL, MariaDB, SQL Server (RDS và Aurora) | | Chi phí | theo vCPU của DB instance, tính theo giờ | | Vị trí | trong VPC, dùng endpoint riêng |

Từ khoá nhận diện:

"Lambda tạo quá nhiều kết nối tới RDS" → RDS Proxy "chạm max_connections" → RDS Proxy, hoặc tăng cỡ instance "failover nhanh hơn" → RDS Proxy (hoặc Aurora) "sẵn sàng cao" → Multi-AZ "chia tải đọc" → Read Replica "ứng dụng không nên biết mật khẩu DB" → RDS Proxy + Secrets Manager

⚠ Vì sao kết nối lại tốn kém đến vậy với cơ sở dữ liệu quan hệ:

PostgreSQL: mỗi kết nối là một TIẾN TRÌNH riêng
MySQL:      mỗi kết nối là một LUỒNG riêng
        ↓
    Mỗi kết nối tốn vài MB bộ nhớ
        ↓
    500 kết nối → hàng GB bộ nhớ chỉ để duy trì kết nối
        ↓
    → bộ nhớ dành cho buffer cache bị thu hẹp
    → truy vấn chậm đi, rồi swap, rồi sập

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bao nhiêu kết nối tới DB | chỉ số DatabaseConnections — so trước và sau | | Pool có hiệu quả không | DatabaseConnectionsCurrentlySessionPinned — cao là đang bị ghim | | Còn chạm trần không | so DatabaseConnections với max_connections |

Và một chi tiết cần kiểm tra sau khi bật RDS Proxy: chỉ số DatabaseConnectionsCurrentlySessionPinned. Nếu con số này cao, nghĩa là ứng dụng đang dùng những tính năng khiến proxy phải "ghim" một kết nối thật cho riêng một client — biến số phiên, bảng tạm, PREPARE — và khi đó việc gộp kết nối gần như mất tác dụng, dù bạn vẫn trả tiền đầy đủ cho proxy.

Đáp án

B — Dùng AWS Artifact.

Vì sao đúng

AWS Artifact là cổng tự phục vụ để tải tài liệu tuân thủ của AWS — và đó chính xác là thứ kiểm toán viên nội bộ đang cần.

⚠ Điểm mấu chốt — Artifact cung cấp bằng chứng về phần AWS chịu trách nhiệm:

Kiểm toán hỏi: "AWS có chứng nhận ISO không?"
        ↓
    Mở AWS Artifact → Reports
        ↓
    Tải về ngay:
        ISO 27001, 27017, 27018, 27701, 9001
        SOC 1, SOC 2, SOC 3
        PCI DSS Attestation of Compliance
        FedRAMP, HIPAA, IRAP, C5, và nhiều chuẩn khác
        ↓
    → miễn phí, tải ngay, không cần mở ticket

⚠ Artifact có HAI phần — đừng nhầm:

Artifact REPORTS
        ↓
    Tài liệu AWS cung cấp CHO BẠN
    → báo cáo kiểm toán, chứng nhận của AWS

Artifact AGREEMENTS
        ↓
    Thoả thuận BẠN KÝ VỚI AWS
    → BAA (Business Associate Addendum) cho HIPAA
    → NDA, thoả thuận GDPR

⚠ Và điều quan trọng nhất phải hiểu về ranh giới:

Artifact chứng minh phần AWS đạt chuẩn
        ↓
    → trung tâm dữ liệu, phần cứng, tầng ảo hoá
        ↓
    NHƯNG KHÔNG chứng minh HỆ THỐNG CỦA BẠN đạt chuẩn
        ↓
    → cấu hình, phân quyền, mã hoá, quy trình của bạn
      vẫn phải tự chứng minh
        ↓
    → dùng AWS Config, Security Hub, Audit Manager

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

• D (liên hệ AWS Support) — đây là phương án gần nhất và từng là cách làm trước khi có Artifact. Nhưng nay tài liệu đã tự phục vụ hoàn toàn: mở ticket chỉ khiến bạn chờ trong khi bản tải về nằm sẵn cách vài cú bấm chuột.

• A (AWS GuardDuty) — dịch vụ phát hiện mối đe doạ, phân tích CloudTrail, VPC Flow Logs và DNS log để tìm hành vi độc hại. Không liên quan tới tài liệu chứng nhận.

• C (điền form kiểm thử xâm nhập ISO) — không tồn tại. Kiểm thử xâm nhập là chuyện khác hẳn, và từ 2019 AWS đã cho phép sẵn trên hầu hết dịch vụ mà không cần xin phép.

Ghi nhớ

⚠ Các dịch vụ liên quan tới tuân thủ — bảng phải thuộc: | Dịch vụ | Việc | |---|---| | AWS Artifact | TẢI tài liệu tuân thủ CỦA AWS | | AWS Config | cấu hình TÀI NGUYÊN CỦA BẠN có đúng chuẩn không | | Security Hub | tổng hợp theo chuẩn CIS, PCI DSS, AWS Foundational | | AWS Audit Manager | thu thập bằng chứng tự động cho một khung kiểm toán | | Inspector | lỗ hổng phần mềm | | Macie | tìm dữ liệu nhạy cảm trong S3 |

Từ khoá nhận diện:

"chứng chỉ ISO, SOC, PCI CỦA AWS" → AWS Artifact "ký BAA cho HIPAA" → AWS Artifact Agreements "hệ thống CỦA TÔI có đúng chuẩn không" → AWS Config + Security Hub "thu thập bằng chứng cho kỳ kiểm toán" → AWS Audit Manager "phát hiện hành vi độc hại" → GuardDuty

⚠ Mô hình trách nhiệm chia sẻ trong bối cảnh tuân thủ: | AWS chứng minh (qua Artifact) | Bạn phải tự chứng minh | |---|---| | An ninh vật lý trung tâm dữ liệu | Cấu hình dịch vụ (bucket có công khai không) | | Quy trình vận hành hạ tầng | Phân quyền IAM | | Kiểm soát nhân sự của AWS | Mã hoá dữ liệu | | Tầng ảo hoá, phần cứng | Vá hệ điều hành khách (với EC2) | | Chứng nhận của hạ tầng | Quy trình và kiểm soát của tổ chức bạn |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có tài liệu cần không | AWS Artifact console → Reports | | Ai được tải | chính sách IAM cho action artifact:Get | | Bằng chứng cho phần của bạn | Audit Manager hoặc Security Hub báo cáo |

Và một điều rất đáng nói rõ với kiểm toán viên ngay từ đầu: chứng nhận ISO của AWS chứng minh HẠ TẦNG đạt chuẩn, không chứng minh HỆ THỐNG CỦA BẠN đạt chuẩn. Rất nhiều tổ chức nộp báo cáo từ Artifact rồi tưởng đã xong phần tuân thủ — trong khi phần khó thật sự nằm ở việc chứng minh cấu hình, phân quyền và quy trình của chính họ, và đó là lúc AWS Config, Security Hub cùng Audit Manager mới là công cụ cần tới.

Đáp án

B — Amazon ElastiCache for Memcached.

Vì sao đúng

Đề nêu hai từ khoá quyết định: "ĐƠN GIẢN" và "co giãn ra/vào bằng cách THÊM hoặc BỚT NODE".

⚠ Điểm mấu chốt — Memcached co giãn ngang bằng cách thêm bớt node, rất đơn giản:

Memcached
        ↓
    Một cụm gồm nhiều node ĐỘC LẬP, ngang hàng
        ↓
    Thêm node  → thêm dung lượng và thông lượng
    Bớt node   → giảm ngay
        ↓
    Client dùng CONSISTENT HASHING để chọn node
        ↓
    → không có primary, không có replica
    → không có khái niệm failover
        ↓
    → đúng nghĩa "đơn giản" mà đề mô tả

⚠ Và vì sao Redis phức tạp hơn cho cùng nhu cầu:

Redis (cluster mode disabled)
        ↓
    Một primary + nhiều replica
        ↓
    → thêm replica chỉ tăng khả năng ĐỌC
    → KHÔNG tăng dung lượng lưu trữ

Redis (cluster mode enabled)
        ↓
    Nhiều shard, mỗi shard có primary và replica
        ↓
    → mở rộng được, nhưng phải quản lý shard,
      resharding, slot migration
        ↓
    → phức tạp hơn hẳn việc chỉ thêm một node

⚠ Và một ưu thế nữa của Memcached mà đề ngầm nhắc tới:

Memcached ĐA LUỒNG
        ↓
    → tận dụng được mọi lõi CPU của node
    → mở rộng dọc tốt (chọn instance nhiều lõi)
        ↓
    Redis chủ yếu đơn luồng cho việc xử lý lệnh
        ↓
    → một node Redis không dùng hết CPU nhiều lõi

Xem thêm câu #11779: cùng lựa chọn Redis hay Memcached nhưng đáp án là Redis, vì ở đó yêu cầu là Multi-AZ và automatic failover — những thứ Memcached hoàn toàn không có. Hai câu không mâu thuẫn: yêu cầu quyết định lựa chọn.

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

• A (ElastiCache for Redis) — đây là phương án gần nhất và là lựa chọn phổ biến hơn trong thực tế. Nhưng Redis có nhiều tính năng hơn mức cần thiết ở đây, và việc mở rộng của nó (qua shard) phức tạp hơn việc chỉ thêm một node như Memcached. Đề nhấn mạnh "đơn giản".

• C (DynamoDB Accelerator — DAX) — là bộ nhớ đệm CHỈ dành cho DynamoDB, không phải cache đa dụng cho ứng dụng web.

• D (Amazon CloudFront) — là CDN cache nội dung HTTP ở edge, không phải in-memory cache cho dữ liệu ứng dụng.

Ghi nhớ

⚠ Redis và Memcached — bảng phải thuộc: | | Redis | Memcached | |---|---|---| | Kiểu dữ liệu | phong phú (list, set, sorted set, hash, stream) | chỉ chuỗi | | Bền vững | có (snapshot, AOF) | KHÔNG | | Sao chép, replica | có | KHÔNG | | Multi-AZ, failover | có | KHÔNG | | Đa luồng | chủ yếu đơn luồng | CÓ | | Mở rộng | shard (phức tạp hơn) | thêm/bớt node (đơn giản) | | Pub/Sub, transaction, Lua | có | không | | Chọn khi | cần tính năng, bền vững, sẵn sàng cao | cache đơn giản, nhiều lõi, mở rộng ngang |

Từ khoá nhận diện:

"đơn giản, thêm bớt node để co giãn" → Memcached "cần Multi-AZ, failover, bền vững" → Redis "bảng xếp hạng, pub/sub, phiên làm việc" → Redis "cache cho DynamoDB" → DAX "cache nội dung web ở edge" → CloudFront "tận dụng nhiều lõi CPU" → Memcached

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cache có đủ lớn không | chỉ số Evictions — khác 0 là đang thiếu | | Cache có hiệu quả không | CacheHitRate | | Client có tự phát hiện node không | dùng configuration endpoint, không phải endpoint từng node |

Và một lời khuyên khi chọn giữa hai công cụ này: hãy chọn Memcached chỉ khi bạn thật sự chỉ cần một cache khoá–giá trị đơn thuần. Redis phức tạp hơn một chút nhưng cho bạn bền vững, sao chép, failover và một tập kiểu dữ liệu phong phú — và trong thực tế, phần lớn ứng dụng sớm muộn cũng cần ít nhất một trong số đó, lúc ấy việc chuyển đổi sẽ tốn hơn nhiều so với việc chọn đúng ngay từ đầu.

Đáp án

C, D — hai cách bảo vệ log CloudTrail với công sức ÍT NHẤT:

• D — Bật CloudTrail log file integrity validation.
• C — Dùng S3 MFA Delete trên bucket chứa log và digest file.

Vì sao đúng

Cả hai đều là công tắc có sẵn, không cần dựng thêm hạ tầng nào.

⚠ Điều D — log file validation chứng minh log chưa bị sửa:

Bật một tuỳ chọn khi tạo trail
        ↓
    CloudTrail tạo DIGEST FILE mỗi giờ:
        - mã băm SHA-256 của từng tệp log
        - mã băm của digest giờ TRƯỚC
        - CHỮ KÝ SỐ bằng khoá riêng của AWS
        ↓
    Kiểm chứng bằng MỘT LỆNH:
        aws cloudtrail validate-logs --trail-arn ... --start-time ...
        ↓
    → phát hiện được mọi kiểu sửa, xoá, làm giả

⚠ Điều C — MFA Delete chặn việc xoá vĩnh viễn:

MFA Delete trên bucket chứa log
        ↓
    Xoá vĩnh viễn một phiên bản → PHẢI có mã MFA
    Tắt versioning → PHẢI có mã MFA
        ↓
    → kẻ tấn công chiếm được quyền quản trị
      vẫn KHÔNG xoá được log nếu không có thiết bị MFA
        ↓
    Bật bằng MỘT lệnh CLI (root + MFA)

⚠ Và hai cơ chế này bổ sung cho nhau:

Validation → chứng minh TOÀN VẸN (không bị SỬA)
MFA Delete → bảo vệ SẴN CÓ (không bị XOÁ)
        ↓
    → phủ đủ hai mối đe doạ chính với nhật ký kiểm toán

Xem thêm câu #11736: cùng chủ đề bảo vệ log CloudTrail, ở đó nhấn mạnh rằng chỉ log file validation mới CHỨNG MINH được tính toàn vẹn — versioning và mã hoá giải quyết vấn đề khác.

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

• E (bật Versioning trên bucket chứa log và digest file) — đây là phương án gần nhất và là một biện pháp bảo vệ thật (khôi phục được nếu tệp bị ghi đè). Nhưng nó không CHỨNG MINH được điều gì với kiểm toán viên, và MFA Delete đã bao hàm versioning (MFA Delete bắt buộc phải bật versioning trước). Chọn C là đủ và mạnh hơn.

• A (tích hợp CloudWatch alarm để báo khi log file bị thay đổi) — nghe hợp lý nhưng rất tốn công: phải dựng CloudTrail data event cho bucket log, viết metric filter, tạo alarm — nhiều bước hơn hẳn hai công tắc kia. Và nó chỉ báo sau khi đã xảy ra, không ngăn chặn.

• B (dùng tài khoản root để quản lý log CloudTrail) — trái thẳng thực hành tốt về bảo mật: root chỉ nên dùng cho vài thao tác đặc biệt, và dùng nó hằng ngày làm tăng rủi ro thay vì giảm.

Ghi nhớ

⚠ Ba tính chất bảo mật và công cụ tương ứng cho log — bảng phải thuộc: | Tính chất | Bảo vệ khỏi | Công cụ | |---|---|---| | Integrity (toàn vẹn) | ai đó SỬA log | log file validation | | Availability (sẵn có) | ai đó XOÁ log | MFA Delete, Object Lock, versioning | | Confidentiality (bí mật) | người không phận sự ĐỌC | SSE-KMS |

Từ khoá nhận diện:

"chứng minh log chưa bị sửa" → log file validation "không ai xoá được log, kể cả root" → S3 Object Lock chế độ Compliance "chặn xoá, ít công sức" → MFA Delete "ai đọc được log" → SSE-KMS "tài khoản thành viên không tắt được trail" → organization trail

⚠ MFA Delete và Object Lock — chọn cái nào: | | MFA Delete | Object Lock (Compliance) | |---|---|---| | Bật bằng | root + CLI | lúc tạo bucket | | Chặn ai | người không có thiết bị MFA | TẤT CẢ, kể cả root | | Gỡ được không | được, bởi root | KHÔNG trong thời hạn giữ | | Lifecycle | KHÔNG dùng chung được | dùng chung được | | Công sức | ít nhất | trung bình | | Chọn khi | chống xoá nhầm, làm nhanh | yêu cầu tuân thủ nghiêm ngặt |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Validation đã bật chưa | describe-trails, xem LogFileValidationEnabled | | Log có toàn vẹn không | validate-logs cho khoảng thời gian cần kiểm | | MFA Delete đã bật chưa | get-bucket-versioning, xem trường MFADelete |

Và một hệ quả vận hành của MFA Delete cần cân nhắc trước khi bật: nó không dùng chung được với lifecycle expiration. Nghĩa là bucket log sẽ lớn dần mãi vì không có cơ chế tự động dọn — với một tổ chức lớn, đó là khoản chi phí tăng đều đặn mà không ai nhìn thấy, nên hãy cân nhắc S3 Object Lock cùng với lifecycle như một phương án thay thế.