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

Đáp án

C — Dựng đường hầm VPN và cấu hình AD CONNECTOR.

Vì sao đúng

Yêu cầu là đăng nhập console AWS bằng tài khoản Active Directory tại chỗ, tức là liên kết danh tính (federation) — và AD Connector là cầu nối đúng nghĩa.

⚠ Điểm mấu chốt — AD Connector là một proxy, không phải bản sao:

AD Connector
        ↓
    KHÔNG lưu bất kỳ dữ liệu thư mục nào trên AWS
        ↓
    Nó CHUYỂN TIẾP yêu cầu xác thực
    về chính domain controller tại chỗ
        ↓
    → mật khẩu vẫn nằm ở AD của công ty
    → chính sách mật khẩu, khoá tài khoản
      vẫn do AD quyết định
    → nhân viên nghỉ việc: khoá ở AD là mất
      quyền vào AWS ngay

⚠ Vì sao phải có VPN (hoặc Direct Connect) trước:

AD Connector nằm trong VPC của bạn
        ↓
    Phải nói chuyện được với domain controller
    ở trung tâm dữ liệu tại chỗ
        ↓
    Cần đường mạng RIÊNG:
      Site-to-Site VPN, hoặc Direct Connect
        ↓
    → đó là lý do đề nhắc tới đường hầm VPN
        ↓
    Cổng cần mở: LDAP 389, Kerberos 88,
    DNS 53, và vài cổng khác

⚠ Đăng nhập console diễn ra thế nào:

Người dùng vào URL đăng nhập của thư mục
        ↓
    Nhập tài khoản AD
        ↓
    AD Connector chuyển tiếp về AD tại chỗ
        ↓
    Xác thực xong → ánh xạ nhóm AD sang IAM ROLE
        ↓
    → nhận quyền tạm thời qua STS
    → vào console, KHÔNG cần IAM user nào

Xem thêm câu #11829: cũng về đăng nhập tập trung. IAM Identity Center là cách hiện đại hơn cho cùng bài toán, và AD Connector có thể làm nguồn danh tính cho chính Identity Center.

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

• A (dùng "IAM connector" để đồng bộ Active Directory tại chỗ) — không có dịch vụ nào tên là IAM connector. Nếu muốn đồng bộ danh tính thì cách đúng là SCIM với IAM Identity Center, hoặc AD Connector để uỷ quyền xác thực.

• D (thiết lập quan hệ tin cậy hai chiều giữa AWS IAM và Active Directory) — IAM không tham gia quan hệ tin cậy kiểu AD. Trust hai chiều là khái niệm giữa AWS Managed Microsoft AD và AD tại chỗ, không phải giữa IAM và AD.

• B (bật "Active Directory federation" trong một private zone của Route 53) — Route 53 là dịch vụ DNS, hoàn toàn không có chức năng xác thực nào.

Ghi nhớ

⚠ Ba lựa chọn Directory Service — bảng phải thuộc: | Dịch vụ | Nội dung | |---|---| | AD Connector | PROXY về AD tại chỗ — không lưu dữ liệu trên AWS | | AWS Managed Microsoft AD | AD THẬT chạy trên AWS, lập được trust với AD tại chỗ | | Simple AD | tương thích Samba, không lập trust được, cho nhu cầu nhỏ | | Cần gì chung | đường mạng riêng tới tại chỗ (VPN / Direct Connect) |

Từ khoá nhận diện:

"dùng tài khoản AD tại chỗ để vào AWS" → AD Connector, hoặc Identity Center với AD "cần AD chạy trên AWS cho ứng dụng Windows" → AWS Managed Microsoft AD "đã có Okta / Entra ID / Ping" → SAML 2.0 federation, IAM Identity Center "đăng nhập một lần cho nhiều tài khoản AWS" → IAM Identity Center "người dùng ứng dụng, không phải nhân viên" → Cognito

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Connector có khoẻ không | Directory Service console — trạng thái Active | | Đăng nhập được không | thử URL đăng nhập của thư mục bằng một tài khoản AD | | Vì sao hỏng | thường là VPN đứt hoặc thiếu cổng tới domain controller |

Và một lưu ý về hướng đi lâu dài: với triển khai mới hôm nay, AWS khuyến nghị IAM Identity Center thay vì nối AD Connector thẳng vào IAM. Identity Center vẫn dùng được chính AD tại chỗ làm nguồn danh tính, nhưng bổ sung thêm permission set áp cho nhiều tài khoản, một cổng truy cập duy nhất, và hỗ trợ đăng nhập cho cả CLI — những thứ mà cách nối trực tiếp không có.

Đáp án

C — Dùng AWS Organizations tạo TÀI KHOẢN RIÊNG cho mỗi phòng ban và áp SERVICE CONTROL POLICY để giới hạn dịch vụ được duyệt.

Vì sao đúng

Đề đòi hai thứ: môi trường cô lập cho từng phòng ban, và chỉ dùng được dịch vụ đã duyệt trước. Cặp tài khoản riêng + SCP thoả cả hai một cách mạnh nhất.

⚠ Vế thứ nhất — tài khoản là ranh giới cô lập MẠNH NHẤT trên AWS:

Ranh giới cô lập, từ yếu tới mạnh:
        ↓
    IAM policy  → cùng tài khoản, dễ cấu hình sai
    VPC         → cô lập MẠNG, không cô lập quyền
    TÀI KHOẢN   → cô lập TOÀN DIỆN  ← mạnh nhất
        ↓
    Tài khoản riêng cho mỗi phòng ban:
      - hạn mức TÁCH BẠCH
      - chi phí tách bạch tự nhiên
      - một tài khoản bị xâm nhập không lan sang cái khác
      - không có cách nào "vô tình" chạm tài nguyên phòng khác

⚠ Vế thứ hai — SCP là TRẦN quyền, không ai vượt qua được:

{
  "Effect": "Deny",
  "NotAction": [
    "ec2:*", "s3:*", "rds:*", "lambda:*",
    "cloudwatch:*", "logs:*", "iam:*"
  ],
  "Resource": "*"
}

    → mọi dịch vụ NGOÀI danh sách đều bị chặn
        ↓
    Kể cả người dùng có quyền quản trị đầy đủ
    trong tài khoản đó cũng KHÔNG dùng được
        ↓
    → đúng nghĩa "chỉ dịch vụ được duyệt trước"

⚠ Cách tổ chức OU cho gọn:

Root
 ├── OU Security      → tài khoản log, audit
 ├── OU Infrastructure → mạng dùng chung
 └── OU Workloads
      ├── OU Ky-thuat     → tài khoản phòng kỹ thuật
      ├── OU Marketing    → tài khoản phòng marketing
      └── OU Tai-chinh    → tài khoản phòng tài chính
        ↓
    SCP áp lên OU → mọi tài khoản trong đó thừa hưởng
        ↓
    Dựng bằng AWS Control Tower cho nhanh và đúng chuẩn

Xem thêm câu #11828 và #11829 (cùng lô): cùng chủ đề Organizations — đưa tài khoản vào tổ chức, và phân quyền đăng nhập tập trung.

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

• B (dùng AWS Service Catalog tạo danh mục dịch vụ được duyệt cho mỗi phòng ban) — đây là phương án gần nhất và là một công cụ bổ trợ rất tốt: nó cho phép phát hành các sản phẩm hạ tầng chuẩn hoá. Nhưng nó không NGĂN được ai đó tự tạo tài nguyên ngoài danh mục, và không tạo ra sự cô lập giữa các phòng ban.

• A (tạo IAM policy cho mỗi phòng ban và gắn vào tài khoản người dùng) — không có cô lập thật: mọi người vẫn ở chung một tài khoản, chung hạn mức, và một chính sách viết sai là chạm sang tài nguyên phòng khác. IAM policy cũng dễ bị vượt qua hơn SCP.

• D (tạo VPC riêng cho mỗi phòng ban và giới hạn bằng IAM role) — VPC chỉ cô lập MẠNG, không cô lập quyền, hạn mức hay chi phí. Người dùng vẫn tạo được tài nguyên ngoài VPC (S3, DynamoDB, Lambda).

Ghi nhớ

⚠ Bốn mức cô lập — bảng phải thuộc: | Mức | Cô lập được gì | Đánh giá | |---|---|---| | Tài khoản AWS | quyền, hạn mức, chi phí, mạng — TẤT CẢ | mạnh nhất | | VPC | chỉ MẠNG | không đủ cho yêu cầu quản trị | | IAM policy | quyền, trong cùng một tài khoản | dễ cấu hình sai | | Tag | chỉ là nhãn | không phải cơ chế bảo mật |

Từ khoá nhận diện:

"mỗi phòng ban một môi trường cô lập" → tài khoản riêng + Organizations "chỉ được dùng dịch vụ đã duyệt" → SCP "phát hành hạ tầng chuẩn cho các đội tự dùng" → Service Catalog "dựng nhiều tài khoản theo chuẩn, tự động" → Control Tower + Account Factory "chặn hẳn một Region" → SCP với aws:RequestedRegion

Ba việc kiểm chứng: | Việc | Cách | |---|---| | SCP đang áp cho tài khoản nào | list-policies-for-target, và describe-effective-policy | | SCP có chặn đúng không | đăng nhập tài khoản thành viên rồi thử gọi một dịch vụ bị cấm | | Cấu trúc OU hiện tại | list-organizational-units-for-parent |

Và một nguyên tắc nên tuân thủ nghiêm khi bắt đầu dùng SCP: luôn thử trên một OU thử nghiệm trước, và không bao giờ áp một SCP mới thẳng lên root. SCP có hiệu lực ngay lập tức với mọi tài khoản bên dưới, kể cả các luồng tự động đang chạy — và một chính sách quên mất một action nào đó có thể làm đứt CI/CD, đứt sao lưu, hoặc chặn luôn chính công cụ mà bạn cần để gỡ nó ra.

Đáp án

A — XOÁ các luật security group và network ACL không cần thiết.

Vì sao đúng

Đề đã nói rõ vấn đề: có những luật thừa gây rủi ro. Cách xử lý một luật thừa là gỡ nó đi — không có công cụ nào làm hộ việc quyết định luật nào cần giữ.

⚠ Điểm mấu chốt — mỗi luật thừa là một cánh cửa đang mở:

Luật cho phép 0.0.0.0/0 cổng 22
        ↓
    → cả internet dò được SSH
Luật cho một dải IP của nhà thầu đã hết hợp đồng
        ↓
    → đường vào không còn ai theo dõi
Luật mở cổng cho một dịch vụ đã ngừng chạy
        ↓
    → bề mặt tấn công không có lý do tồn tại
        ↓
    → cách khắc phục DUY NHẤT là XOÁ chúng

⚠ Nhưng phải làm có quy trình, không xoá bừa:

1. Xác định luật nào THẬT SỰ đang được dùng
        ↓
    VPC Flow Logs → có lưu lượng nào khớp luật đó không
    → luật không khớp gói tin nào trong 30 ngày
      thường là luật chết
        ↓
2. Ghi lại và thông báo trước cho các đội liên quan
        ↓
3. Xoá ở môi trường DEV/STAGING trước
        ↓
4. Xoá ở production trong cửa sổ thay đổi
        ↓
5. Theo dõi 24-48 giờ, sẵn sàng khôi phục

⚠ Và ngăn để chuyện không lặp lại:

AWS Config
        ↓
    restricted-ssh
    restricted-common-ports
    vpc-default-security-group-closed
        ↓
SCP
        ↓
    Chặn tạo luật 0.0.0.0/0 cho cổng nhạy cảm
        ↓
Hạ tầng dạng mã
        ↓
    Mọi luật đi qua review, có lịch sử,
    có người chịu trách nhiệm

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

• B (dùng Amazon Inspector để tìm và khắc phục theo thực hành tốt) — đây là phương án gần nhất vì Inspector có một chức năng đánh giá khả năng truy cập mạng, nhưng nó chỉ PHÁT HIỆN, không tự sửa — và ở đây vấn đề đã được xác định rồi. Việc còn lại là hành động. (Muốn tự động sửa thì là Config + SSM Automation, không phải Inspector.)

• C (báo cho AWS Support về các lỗ hổng) — security group và NACL là phần trách nhiệm của KHÁCH HÀNG theo mô hình trách nhiệm chia sẻ. AWS không sửa cấu hình mạng của bạn.

• D (tạo AWS WAF web ACL để chống tấn công web) — WAF lọc lưu lượng HTTP tầng 7 trước CloudFront, ALB hay API Gateway. Nó không thay thế việc dọn luật ở tầng mạng, và cũng không giải quyết một cổng SSH đang mở.

Ghi nhớ

⚠ Bốn dịch vụ hay bị lẫn — bảng phải thuộc: | Dịch vụ | Việc | |---|---| | Security Group / NACL | kiểm soát truy cập MẠNG — bạn tự cấu hình | | Inspector | quét lỗ hổng phần mềm và khả năng truy cập mạng | | Config | kiểm tra cấu hình tuân thủ, có KHẮC PHỤC tự động | | WAF | lọc HTTP tầng 7: SQL injection, XSS, bot | | GuardDuty | phát hiện hành vi đe doạ |

Từ khoá nhận diện:

"đã tìm ra luật thừa" → XOÁ chúng "tự động phát hiện và sửa cấu hình sai" → Config + SSM Automation "quét lỗ hổng trên máy" → Inspector "chống SQL injection, XSS" → WAF "chống DDoS lớn" → Shield Advanced

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Còn luật mở toang nào không | describe-security-groups, lọc 0.0.0.0/0 | | Luật có ai dùng không | VPC Flow Logs trong 30 ngày | | Xoá xong có gãy gì không | theo dõi lỗi ứng dụng và REJECT trong flow log 48 giờ |

Và một cách làm giúp việc dọn dẹp lần sau dễ hơn rất nhiều: bắt buộc mỗi luật security group phải có trường mô tả nói rõ vì sao nó tồn tại và ai yêu cầu. Phần lớn thời gian của một đợt dọn dẹp không nằm ở việc xoá, mà ở việc đi hỏi khắp nơi xem một dải IP lạ trong luật số 7 là của ai — và câu trả lời thường là không còn ai nhớ nữa.

Đáp án

A — Tạo SNAPSHOT THỦ CÔNG bằng create-db-snapshot, chia sẻ nó với tài khoản development, rồi tạo một bản sao trong tài khoản đó.

Vì sao đúng

Có một quy tắc rất cứng của RDS quyết định toàn bộ câu này: snapshot TỰ ĐỘNG không chia sẻ được.

⚠ Điểm mấu chốt — automated snapshot ↔ manual snapshot:

AUTOMATED SNAPSHOT
        ↓
    - RDS tự tạo theo cửa sổ sao lưu
    - Xoá theo thời gian giữ (1-35 ngày)
    - XOÁ INSTANCE là MẤT LUÔN
    - KHÔNG chia sẻ được sang tài khoản khác
    - KHÔNG copy trực tiếp sang tài khoản khác được
        ↓
MANUAL SNAPSHOT                    ← đề này
        ↓
    - Bạn chủ động tạo
    - GIỮ MÃI tới khi bạn xoá
    - CHIA SẺ ĐƯỢC với tài khoản khác
    - Copy được sang Region khác

⚠ Quy trình đúng, ba bước:

1. Tài khoản production:
     aws rds create-db-snapshot \
       --db-instance-identifier prod-db \
       --db-snapshot-identifier tuan-2026-09-02
        ↓
2. Chia sẻ với tài khoản dev:
     aws rds modify-db-snapshot-attribute \
       --db-snapshot-identifier tuan-2026-09-02 \
       --attribute-name restore \
       --values-to-add 111122223333
        ↓
3. Tài khoản dev TẠO BẢN SAO:
     aws rds copy-db-snapshot ...
        ↓
    → sau đó khôi phục thành instance để kiểm thử

⚠ Vì sao bước 3 (copy) lại cần thiết:

Snapshot được chia sẻ vẫn THUỘC SỞ HỮU
tài khoản production
        ↓
    → production xoá snapshot là dev mất luôn
    → dev không kiểm soát vòng đời của nó
        ↓
    Copy sang tài khoản dev
        ↓
    → dev có bản của riêng mình
    → độc lập hoàn toàn

⚠ Một chi tiết về mã hoá rất hay ra thi:

Snapshot mã hoá bằng KMS
        ↓
    KHÔNG dùng được khoá MẶC ĐỊNH của AWS
      (aws/rds) khi chia sẻ liên tài khoản
        ↓
    → phải mã hoá bằng CUSTOMER MANAGED KEY
    → và chia sẻ CẢ KHOÁ đó với tài khoản dev
      (qua key policy)
        ↓
    Thiếu bước chia sẻ khoá:
      dev thấy snapshot nhưng KHÔNG copy được

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

• D (copy một snapshot TỰ ĐỘNG sang tài khoản dev bằng copy-db-snapshot) — đây là phương án gần nhất và chỉ sai đúng một chữ: snapshot tự động không chia sẻ và không copy liên tài khoản được. Cách thường dùng khi buộc phải bắt đầu từ snapshot tự động là copy nó thành snapshot thủ công trong chính tài khoản production trước, rồi mới chia sẻ.

• C (tạo standby Multi-AZ trong tài khoản dev rồi chụp snapshot) — Multi-AZ standby nằm trong CÙNG một tài khoản và cùng Region với instance chính; không có cách nào đặt nó ở tài khoản khác. Và cách này cũng rất đắt.

• B (dùng S3 Cross-Region Replication để sao chép bản sao lưu tự động) — bạn không truy cập được vào bucket S3 chứa sao lưu của RDS; nó do AWS quản lý và không hiện ra trong tài khoản bạn.

Ghi nhớ

⚠ Automated ↔ Manual snapshot — bảng phải thuộc: | | Automated | Manual | |---|---|---| | Ai tạo | RDS, theo cửa sổ sao lưu | bạn | | Thời gian giữ | 1-35 ngày | tới khi bạn xoá | | Xoá instance | MẤT (trừ khi giữ bản cuối) | còn | | Chia sẻ liên tài khoản | KHÔNG | ĐƯỢC | | Copy sang Region khác | không trực tiếp | được | | PITR | CÓ — khôi phục tới từng giây | không |

Từ khoá nhận diện:

"chia sẻ sao lưu sang tài khoản khác" → MANUAL snapshot "khôi phục về đúng thời điểm trước sự cố" → PITR từ automated backup "sao lưu tự động nhiều dịch vụ, nhiều tài khoản" → AWS Backup "giữ sao lưu lâu hơn 35 ngày" → manual snapshot hoặc AWS Backup "snapshot mã hoá không copy được" → phải dùng CMK và chia sẻ khoá

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Snapshot đã chia sẻ chưa | describe-db-snapshot-attributes | | Dev thấy snapshot không | ở tài khoản dev: describe-db-snapshots --include-shared | | Vì sao copy hỏng | thường là chưa chia sẻ khoá KMS |

Và một lời khuyên nên cân nhắc thay cho việc chạy tay mỗi tuần: dùng AWS Backup với backup plan có cross-account copy. Nó làm đúng việc mà đề mô tả — chụp, sao chép sang tài khoản development theo lịch, và tự dọn bản cũ theo thời gian giữ — nhưng không cần ai nhớ chạy lệnh vào thứ Hai hằng tuần, và cũng không âm thầm dừng lại khi người phụ trách nghỉ phép.

Đáp án

B — Tạo một CloudFront distribution cho website với origin là bucket S3.

Vì sao đúng

Triệu chứng rất đặc trưng: chậm với người dùng ở XA, bình thường khi kiểm thử tại chỗ, và nội dung là ảnh và video tĩnh. Đó là bài toán CloudFront giải.

⚠ Điểm mấu chốt — vấn đề là KHOẢNG CÁCH, không phải năng lực:

Kiểm thử tại Singapore → nhanh
        ↓
    → bucket khoẻ, ứng dụng khoẻ
        ↓
Người dùng ở xa → chậm
        ↓
    → mỗi tệp phải đi vòng nửa vòng trái đất
    → độ trễ vòng lặp lớn, TCP chậm khởi động
    → ảnh và video càng lớn càng lộ rõ
        ↓
CLOUDFRONT
        ↓
    Cache tại hơn 400 điểm hiện diện toàn cầu
        ↓
    Lần đầu: lấy từ S3 ở Singapore
    Từ lần sau: phục vụ NGAY TẠI EDGE gần người dùng
        ↓
    → độ trễ giảm từ hàng trăm ms xuống vài chục ms

⚠ Và với video thì lợi ích còn lớn hơn:

Video được tải theo từng đoạn (range request)
        ↓
    Mỗi đoạn là một vòng đi-về tới origin
        ↓
    Origin ở xa → mỗi đoạn chậm → video giật
        ↓
    CloudFront hỗ trợ range request và cache từng đoạn
        ↓
    → phát mượt, ít đệm lại

⚠ Cấu hình nên có:

Origin Access Control (OAC)
        ↓
    → bucket để HOÀN TOÀN RIÊNG TƯ
    → chỉ CloudFront đọc được
        ↓
Cache policy:
    ảnh, video, CSS, JS → TTL dài
    HTML → TTL ngắn hoặc 0
        ↓
Bật nén (Gzip/Brotli) cho tệp văn bản
Chứng chỉ ACM ở us-east-1 cho tên miền riêng

Xem thêm câu #11830, #11876 và #11877 (cùng lô): cùng chùm bài toán nội dung tĩnh và độ trễ, khoá đều là CloudFront.

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

• C (bật S3 Transfer Acceleration và dùng endpoint s3-accelerate) — đây là phương án gần nhất và cũng dùng mạng edge của CloudFront, nhưng nó tối ưu cho TẢI LÊN và KHÔNG CACHE gì cả. Mỗi lượt tải xuống vẫn phải đi tới bucket ở Singapore, chỉ là qua đường tốt hơn. Với nội dung tĩnh đọc lặp lại thì cache mới là thứ tạo khác biệt.

• A (tạo API Gateway ở mỗi Region và bật cache) — API Gateway dành cho API, không phải để phục vụ ảnh và video. Nó cũng có giới hạn kích thước phản hồi và đắt hơn nhiều cho loại lưu lượng này.

• D (dùng AWS Direct Connect cho S3) — Direct Connect là đường riêng từ trung tâm dữ liệu của CÔNG TY tới AWS. Người dùng cuối trên internet không đi qua nó.

Ghi nhớ

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

Đề có một mâu thuẫn nội tại: phần mô tả nói người dùng ở châu Âu báo chậm, nhưng câu hỏi lại yêu cầu cải thiện trải nghiệm cho người dùng ở Canada và châu Á. Đây là lỗi biên tập của bộ đề — hai vế nhắc tới các khu vực khác nhau.

Điều này không làm đổi khoá đáp án: dù người dùng ở châu Âu, Canada hay bất kỳ đâu xa Singapore, giải pháp vẫn là CloudFront, vì nó phục vụ nội dung từ điểm hiện diện gần người dùng bất kể họ ở đâu. Khi gặp đề có mâu thuẫn kiểu này, hãy bám vào bản chất vấn đề — ở đây là "người dùng ở xa, nội dung tĩnh, độ trễ cao" — thay vì cố dung hoà các chi tiết địa lý.

⚠ Bốn công cụ tăng tốc — bảng phải thuộc: | Vấn đề | Giải pháp | |---|---| | Tải XUỐNG chậm ở xa, nội dung lặp lại | CloudFront | | Tải LÊN chậm ở xa, tệp lớn | S3 Transfer Acceleration | | TCP/UDP không phải HTTP, cần IP tĩnh | Global Accelerator | | Từ trung tâm dữ liệu công ty tới AWS | Direct Connect |

Từ khoá nhận diện:

"người dùng toàn cầu, nội dung tĩnh chậm" → CloudFront "nhanh khi test tại chỗ, chậm ở xa" → vấn đề ĐỘ TRỄ, không phải năng lực "tải lên chậm" → Transfer Acceleration "game, VoIP, cần failover đa Region nhanh" → Global Accelerator "kết nối riêng ổn định từ văn phòng" → Direct Connect

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cache có hiệu quả không | chỉ số CacheHitRate | | Người dùng ở xa thấy gì | kiểm tra từ nhiều khu vực, xem header X-Cache: Hit from cloudfront | | Bucket đã đóng chưa | thử gọi thẳng URL của S3 — phải nhận 403 |

Và một chỉ số nên nhìn ngay sau khi triển khai: CacheHitRate. Nếu nó thấp bất thường thì gần như luôn do cache policy đang chuyển tiếp quá nhiều header, cookie hoặc query string xuống origin — mỗi biến thể tạo ra một mục cache riêng, và bạn sẽ có một CDN chỉ làm nhiệm vụ chuyển tiếp request thay vì phục vụ chúng.

Đáp án

B — Chuyển CSDL sang một instance Amazon Aurora và tạo Aurora Replica ở Availability Zone khác.

Vì sao đúng

Đề đòi tăng cả tính SẴN SÀNG lẫn ĐỘ BỀN của tầng dữ liệu, ít thay đổi ứng dụng nhất. Aurora MySQL thoả cả ba.

⚠ Điểm mấu chốt — vấn đề hiện tại là MySQL tự cài trên MỘT máy EC2:

MySQL trên một EC2
        ↓
    - Máy hỏng → CSDL chết
    - AZ hỏng → CSDL chết
    - EBS chỉ có bản sao trong MỘT AZ
    - Bạn tự lo: vá lỗi, sao lưu, failover
        ↓
    → không có sẵn sàng, không có độ bền cao

⚠ Aurora giải cả hai vế cùng lúc:

ĐỘ BỀN
        ↓
    Tầng lưu trữ ghi 6 BẢN SAO trên 3 AZ
    Tự phát hiện và sửa lỗi khối dữ liệu
    Sao lưu liên tục về S3, PITR tới từng giây
        ↓
SẴN SÀNG
        ↓
    Aurora Replica ở AZ khác
    Failover TỰ ĐỘNG, thường DƯỚI 30 GIÂY
    Endpoint không đổi → ứng dụng chỉ cần kết nối lại

⚠ Và vì sao "ít thay đổi ứng dụng nhất":

Aurora MySQL TƯƠNG THÍCH GIAO THỨC với MySQL
        ↓
    Cùng driver, cùng cú pháp SQL,
    cùng công cụ quản trị
        ↓
    → ứng dụng chỉ cần đổi CHUỖI KẾT NỐI
    → không phải viết lại truy vấn
        ↓
    Chuyển dữ liệu: mysqldump, hoặc AWS DMS
    (DMS chuyển được gần như không gián đoạn)

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

• A (bật Multi-AZ cho chính instance CSDL hiện tại) — đây là phương án gần nhất về ý định, nhưng Multi-AZ là tính năng của RDS, không phải của MySQL tự cài trên EC2. Không có nút nào để bật; muốn có thì phải chuyển sang dịch vụ được quản lý trước đã.

• C (tạo RDS Microsoft SQL Server Multi-AZ rồi nhập dữ liệu vào) — đổi hẳn động cơ CSDL từ MySQL sang SQL Server, kéo theo viết lại truy vấn, đổi driver, đổi kiểu dữ liệu — rất nhiều thay đổi ứng dụng, trái thẳng yêu cầu.

• D (tạo read replica và đặt một ALB để phân phối kết nối) — sai hai chỗ: read replica không tự failover, và ALB là load balancer HTTP tầng 7, không cân bằng kết nối MySQL được. (Muốn cân bằng kết nối CSDL thì dùng RDS Proxy hoặc reader endpoint của Aurora.)

Ghi nhớ

⚠ Ba mức quản lý CSDL trên AWS — bảng phải thuộc: | Mức | Bạn lo gì | |---|---| | CSDL tự cài trên EC2 | TẤT CẢ: vá, sao lưu, failover, mở rộng | | RDS | lược đồ, người dùng, tối ưu truy vấn | | Aurora | như RDS, nhưng lưu trữ và failover tốt hơn nhiều | | Aurora Serverless v2 | thêm: không phải chọn cỡ instance |

Từ khoá nhận diện:

"tăng sẵn sàng và độ bền, ít đổi ứng dụng" → chuyển sang Aurora hoặc RDS "MySQL/PostgreSQL trên EC2" → gần như luôn nên chuyển sang dịch vụ quản lý "cần failover NHANH nhất" → Aurora (dưới 30 giây) "cần đọc ở Region khác" → Aurora Global Database "tải khó đoán" → Aurora Serverless v2

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Failover mất bao lâu | chủ động failover-db-cluster ở staging, đo thời gian | | Replica có tụt hậu không | AuroraReplicaLagMaximum | | Ứng dụng chịu được đứt ngắn không | thử ngắt kết nối, xem có thử lại đúng không |

Và một việc phải kiểm tra ở phía ứng dụng trước khi coi là xong: cơ chế thử lại khi mất kết nối. Aurora failover trong khoảng 30 giây, nhưng nếu ứng dụng không bắt lỗi kết nối và thử lại thì người dùng vẫn thấy một trang lỗi — và toàn bộ khoản đầu tư vào tầng dữ liệu sẽ không thể hiện ra được ở trải nghiệm thật.

Đáp án

C — Dùng lệnh set-alarm-state của AWS CLI cho CloudWatch.

Vì sao đúng

Muốn kiểm thử đường thông báo, bạn cần ép alarm vào trạng thái ALARM mà không phải tạo tải thật.

⚠ Điểm mấu chốt — set-alarm-state ép trạng thái nhân tạo:

aws cloudwatch set-alarm-state \
  --alarm-name canh-bao-cpu-cao \
  --state-value ALARM \
  --state-reason "Kiem thu duong thong bao"
        ↓
    Alarm chuyển sang ALARM NGAY LẬP TỨC
        ↓
    → mọi hành động gắn với alarm được kích hoạt
    → SNS gửi thông báo thật
    → email/SMS/Lambda/webhook đều chạy
        ↓
    → xác nhận được TOÀN BỘ đường đi

⚠ Và trạng thái nhân tạo chỉ tồn tại tạm thời:

Sau khi ép trạng thái
        ↓
    Ở lần đánh giá chỉ số tiếp theo
        ↓
    Alarm tự quay về trạng thái THẬT theo dữ liệu
        ↓
    → không cần dọn dẹp gì
    → không ảnh hưởng cấu hình alarm

⚠ Nên kiểm thử cả ba trạng thái:

--state-value ALARM              → có gửi cảnh báo không
--state-value OK                 → có gửi thông báo "đã hết" không
--state-value INSUFFICIENT_DATA  → xử lý ra sao khi mất dữ liệu
        ↓
    Trạng thái thứ ba rất hay bị bỏ quên
    → nhưng "chỉ số biến mất" cũng là một sự cố thật

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

• B (dùng set-alarm-state trong AWS CloudTrail) — đây là phương án gần nhất và tên lệnh hoàn toàn đúng, chỉ sai dịch vụ: set-alarm-state là API của CloudWatch, không phải CloudTrail. CloudTrail chỉ ghi lại lời gọi API, không thực hiện thao tác nào.

• A (gửi chỉ số tuỳ chỉnh báo CPU 80% tới AWS CloudTrail) — cũng sai dịch vụ: chỉ số tuỳ chỉnh gửi tới CloudWatch. (Và cách này cũng không kiểm thử được alarm đang gắn với chỉ số CPU chuẩn của EC2.)

• D (chỉnh CPU lên 80% bằng EC2 Management Console) — không có cách nào đặt mức sử dụng CPU từ console. Muốn tạo tải thật thì phải chạy công cụ như stress bên trong máy, và cách đó chậm hơn nhiều.

Ghi nhớ

⚠ Ba trạng thái của CloudWatch alarm — bảng phải thuộc: | Trạng thái | Nghĩa | |---|---| | OK | chỉ số nằm trong ngưỡng | | ALARM | vượt ngưỡng đủ số chu kỳ yêu cầu | | INSUFFICIENT_DATA | không đủ dữ liệu để phán xét — máy tắt, agent chết | | Hành động | gắn được cho CẢ BA trạng thái |

Từ khoá nhận diện:

"kiểm thử alarm và thông báo" → set-alarm-state "alarm kẹt ở INSUFFICIENT_DATA" → chỉ số ngừng được gửi "muốn cảnh báo cả khi hết sự cố" → thêm hành động cho trạng thái OK "nhiều alarm liên quan nhau" → composite alarm "ngưỡng thay đổi theo thời gian" → anomaly detection alarm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Alarm đang ở trạng thái nào | describe-alarms --alarm-names ... | | Lịch sử chuyển trạng thái | describe-alarm-history | | Thông báo có tới không | set-alarm-state rồi kiểm tra hộp thư |

Và một thói quen nên đưa vào quy trình phát hành: chạy set-alarm-state cho mọi alarm quan trọng ngay sau khi tạo chúng. Một alarm được cấu hình đúng nhưng gắn vào SNS topic mà chưa ai xác nhận đăng ký là thứ trông hoàn toàn bình thường trên console — và bạn sẽ chỉ phát hiện ra vào đúng đêm nó lẽ ra phải đánh thức ai đó dậy.

Đáp án

D — DỪNG rồi KHỞI ĐỘNG LẠI instance trong cửa sổ bảo trì ngoài giờ làm việc.

Vì sao đúng

Bảo trì theo lịch của AWS là do máy chủ vật lý bên dưới cần được xử lý. Với instance dùng EBS, thao tác stop rồi start sẽ chuyển máy sang một phần cứng khác.

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

REBOOT (khởi động lại)
        ↓
    Máy khởi động lại TRÊN CÙNG máy chủ vật lý
        ↓
    → KHÔNG giải quyết được vấn đề phần cứng

STOP rồi START
        ↓
    Instance được đặt lên MỘT MÁY CHỦ VẬT LÝ KHÁC
        ↓
    → thoát khỏi phần cứng sắp bảo trì
    → sự kiện bảo trì được huỷ bỏ
        ↓
    Và bạn CHỌN ĐƯỢC THỜI ĐIỂM
    → làm ngoài giờ làm việc → không ảnh hưởng ai

⚠ Những gì THAY ĐỔI khi stop/start — phải biết trước:

IP CÔNG CỘNG      → ĐỔI  (trừ khi dùng Elastic IP)
IP riêng          → giữ nguyên
Instance store    → MẤT SẠCH DỮ LIỆU
EBS volume        → giữ nguyên
Instance ID       → giữ nguyên
Availability Zone → giữ nguyên
        ↓
    → gắn ELASTIC IP trước khi làm
    → kiểm tra không có dữ liệu quan trọng
      trên ổ instance store

⚠ Và cách tránh hẳn vấn đề này về lâu dài:

Máy đơn lẻ = điểm hỏng đơn lẻ
        ↓
    Đưa vào AUTO SCALING GROUP nhiều AZ
        ↓
    → AWS retire một máy → ASG tự thay
    → không ai phải thức đêm
        ↓
    Và bắt sự kiện Health bằng EventBridge
    → tự động stop/start trước hạn

Xem thêm câu #11788 (lô 127): cùng chủ đề — stop/start để chuyển instance sang phần cứng khác khi có lịch retire.

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

• A (tạo AMI rồi dựng máy mới từ AMI sau khi máy hiện tại đã TẮT) — đây là phương án gần nhất và cũng chuyển được sang phần cứng khác, nhưng nó phức tạp hơn hẳn: máy mới có instance ID mới, IP mới, phải cấu hình lại mọi thứ trỏ tới nó. Stop/start đạt cùng kết quả với ít việc hơn nhiều.

• B (dùng EC2 console để chuyển instance sang phần cứng khác) — không có nút nào như vậy. Cách duy nhất để đổi máy chủ vật lý là stop/start (hoặc dựng máy mới).

• C (đặt quy tắc CloudWatch Events khởi động lại instance nếu nó bị dừng) — phản ứng SAU khi đã mất dịch vụ, đúng thứ đề nói là không chấp nhận được. Và nếu AWS dừng máy trong quá trình bảo trì thì việc tự start lại chỉ diễn ra sau khi gián đoạn đã xảy ra.

Ghi nhớ

⚠ Các loại sự kiện bảo trì EC2 — bảng phải thuộc: | Sự kiện | Nghĩa | Cách xử lý | |---|---|---| | Instance retirement | phần cứng sắp ngừng | stop/start (EBS) — instance store thì phải dựng mới | | Instance reboot | AWS sẽ khởi động lại | tự reboot trước vào lúc thuận tiện | | System reboot | máy chủ vật lý reboot | stop/start để tránh | | System maintenance (network/power) | bảo trì hạ tầng | stop/start để tránh | | Instance stop | thường với instance store hỏng | dựng máy mới |

Từ khoá nhận diện:

"bảo trì theo lịch, không được gián đoạn" → stop/start ngoài giờ "máy sắp retire" → stop/start (EBS-backed) "instance store" → stop/start là MẤT DỮ LIỆU — phải sao lưu trước "tránh hẳn vấn đề này" → ASG nhiều AZ "biết trước sự kiện" → AWS Health Dashboard + EventBridge

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Máy nào bị lên lịch | EC2 → Events, hoặc describe-instance-status --include-all-instances | | Sự kiện đã huỷ chưa | kiểm tra lại sau khi stop/start — mục Events phải trống | | Ứng dụng lên lại chưa | health check của ALB, và log khởi động của ứng dụng |

Và một cách nhìn dài hơi hơn về chính tình huống này: việc một máy đơn lẻ "không được phép gián đoạn" là dấu hiệu của một điểm hỏng đơn lẻ, chứ không phải một yêu cầu vận hành. Phần cứng sẽ còn hỏng nữa, và AWS sẽ còn gửi thông báo bảo trì nữa — nên đầu tư đúng chỗ là đưa ứng dụng vào Auto Scaling group trải trên nhiều AZ, để lần thông báo sau không còn ai phải đọc nó nữa.

Đáp án

A — Phân tích VPC FLOW LOGS.

Vì sao đúng

Sự cố xảy ra ngay sau một thay đổi cấu hình MẠNG, và triệu chứng là không kết nối được. Chỉ có một nguồn dữ liệu cho biết gói tin bị chặn ở đâu.

⚠ Điểm mấu chốt — flow log ghi lại từng luồng, kèm phán quyết:

Mỗi bản ghi có trường ACTION
        ↓
      ACCEPT → gói được cho qua
      REJECT → gói bị CHẶN
        ↓
    Lọc luồng:
      srcaddr = IP của máy ứng dụng
      dstaddr = IP của RDS
      dstport = 3306
        ↓
    Thấy REJECT → biết ngay bị chặn
    Không thấy bản ghi nào → gói KHÔNG TỚI được
      (route table hoặc sai subnet)

⚠ Đọc kết quả để khoanh vùng thủ phạm:

REJECT ở chiều VÀO RDS
        ↓
    → security group của RDS chưa cho phép
      SG của máy ứng dụng ở cổng 3306
    → hoặc NACL của subnet CSDL chặn chiều vào

ACCEPT vào, REJECT ra
        ↓
    → NACL thiếu luật chiều ra
      (nhớ dải cổng tạm 1024-65535)

KHÔNG có bản ghi nào
        ↓
    → route table sai
    → hoặc máy đang gọi nhầm địa chỉ

⚠ Và một công cụ nhanh hơn nữa cho đúng tình huống này:

VPC REACHABILITY ANALYZER
        ↓
    Khai nguồn (ENI của EC2) và đích (ENI của RDS)
        ↓
    Phân tích cấu hình, KHÔNG gửi gói tin nào
        ↓
    → trả lời thẳng: "bị chặn tại security group
      sg-xxxx" hoặc "network ACL, luật số 110"
        ↓
    → nhanh hơn nhiều so với chờ log

Xem thêm câu #11848 và #11835 (cùng lô): cùng dùng VPC Flow Logs — một câu để đọc phán quyết ACCEPT/REJECT, một câu để tìm nguồn lưu lượng lớn.

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

• D (log lỗi của RDS MySQL) — đây là phương án gần nhất vì cũng liên quan tới CSDL, nhưng log lỗi của MySQL chỉ ghi những gì xảy ra sau khi kết nối đã tới được động cơ CSDL. Nếu gói tin bị chặn ở tầng mạng thì RDS không ghi gì cả — chính sự im lặng đó là manh mối, nhưng nó không chỉ ra nguyên nhân.

• B (log của Elastic Load Balancing) — không có load balancer nào trong đường đi này. ELB nằm giữa người dùng và tầng web, không nằm giữa tầng web và CSDL.

• C (log của Auto Scaling) — Auto Scaling ghi việc khởi chạy và kết thúc máy, không ghi gì về kết nối mạng.

Ghi nhớ

⚠ Chọn đúng nguồn log cho đúng câu hỏi — bảng phải thuộc: | Câu hỏi | Nguồn log | |---|---| | Gói tin bị chặn ở đâu | VPC Flow Logs | | Ai đã thay đổi cấu hình | CloudTrail | | Cấu hình đã đổi thế nào | AWS Config — có timeline và diff | | Ứng dụng báo lỗi gì | CloudWatch Logs | | Truy vấn CSDL chậm | RDS slow query log, Performance Insights | | Request HTTP nào lỗi | ALB access log |

Từ khoá nhận diện:

"không kết nối được sau khi đổi cấu hình mạng" → VPC Flow Logs, hoặc Reachability Analyzer "ai đã sửa security group" → CloudTrail "cấu hình trước khi đổi ra sao" → AWS Config timeline "timeout" → gói bị bỏ im lặng — SG, NACL, route table "connection refused" → tới được máy, dịch vụ không lắng nghe

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bị chặn ở đâu | Reachability Analyzer từ ENI của EC2 tới ENI của RDS | | Bằng chứng gói tin | Flow Logs, lọc dstPort = 3306, xem action | | Ai đã đổi gì | Config timeline của security group, đối chiếu CloudTrail |

Và một việc rất nên làm ngay khi bắt đầu điều tra loại sự cố này: mở AWS Config timeline của security group và network ACL liên quan. Config lưu lại ảnh chụp cấu hình theo thời gian, nên bạn sẽ thấy đúng luật nào vừa bị xoá hoặc thêm vào lúc mấy giờ — thường nhanh hơn cả việc đọc flow log, và nó trả lời luôn câu hỏi tiếp theo là phải khôi phục lại cái gì.

Đáp án

B — Dùng CUSTOMER-MANAGED CMK trong AWS KMS và bật xoay khoá tự động.

Vì sao đúng

Yêu cầu là xoay khoá ít nhất mỗi 365 ngày với ít công vận hành nhất. Customer managed key có sẵn nút bật xoay tự động — đúng một lần bấm.

⚠ Điểm mấu chốt — xoay tự động của KMS làm gì:

Bật automatic key rotation trên một CMK
        ↓
    KMS sinh VẬT LIỆU KHOÁ MỚI mỗi 365 ngày
    (đặt được từ 90 tới 2560 ngày)
        ↓
    Khoá cũ ĐƯỢC GIỮ LẠI
        ↓
    → dữ liệu mã hoá bằng khoá cũ vẫn giải mã được
    → dữ liệu mới dùng vật liệu khoá mới
        ↓
    KEY ID và ARN KHÔNG ĐỔI
        ↓
    → ứng dụng KHÔNG PHẢI SỬA GÌ
    → không phải mã hoá lại dữ liệu cũ

⚠ Vì sao đây là "ít công vận hành nhất":

Bật một lần
        ↓
    → KMS tự lo mãi mãi
    → không Lambda, không lịch, không theo dõi
    → chi phí thêm: một khoá tính tiền như một khoá
      (mỗi phiên bản KHÔNG tính riêng)

⚠ Một chi tiết rất hay ra thi — xoay không mã hoá lại dữ liệu cũ:

Đối tượng đã mã hoá trước khi xoay
        ↓
    Vẫn được giải mã bằng vật liệu khoá CŨ
        ↓
    KMS tự chọn đúng phiên bản
        ↓
    → nếu yêu cầu tuân thủ đòi dữ liệu cũ
      phải dùng khoá mới, thì phải MÃ HOÁ LẠI
      (S3 Batch Operations copy đè)

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

• A (dùng AWS-managed CMK và bật xoay tự động) — đây là phương án gần nhất, nhưng bạn KHÔNG BẬT/TẮT được xoay trên AWS managed key — không có nút đó. Chúng xoay theo lịch riêng của AWS mà bạn không kiểm soát, không chứng minh được với kiểm toán viên, và cũng không đổi được chính sách khoá.

• C (nhập vật liệu khoá vào CMK rồi viết Lambda để xoay) — CMK có vật liệu khoá nhập từ ngoài KHÔNG hỗ trợ xoay tự động; bạn phải tự nhập vật liệu mới. Đây là phương án nhiều công vận hành nhất, ngược hẳn yêu cầu.

• D (dùng customer-managed CMK và ép xoay bằng Trusted Advisor) — Trusted Advisor không xoay khoá. Nó chỉ đưa ra khuyến nghị, và cũng không có kiểm tra nào về xoay khoá KMS.

Ghi nhớ

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

Phương án A có một điểm cần nói rõ vì tài liệu AWS đã thay đổi: AWS managed key nay tự xoay mỗi năm một lần (trước đây là ba năm). Xét riêng con số thì chúng cũng đáp ứng ngưỡng "ít nhất mỗi 365 ngày" của đề.

Tuy vậy khoá đáp án vẫn là B, vì phương án A sai ở chỗ khác: bạn không thể "bật" xoay trên AWS managed key — việc đó do AWS quyết định và không có công tắc nào cho bạn. Với một cuộc kiểm toán, bạn cần chứng minh được cấu hình xoay đang bật và kiểm soát được chính sách khoá, và chỉ customer managed key cho phép cả hai. Khi gặp đề nói tới tuân thủ và kiểm toán, câu trả lời gần như luôn là customer managed key.

⚠ Ba loại khoá trong KMS — bảng phải thuộc: | Loại | Xoay | Bạn kiểm soát | |---|---|---| | AWS owned key | AWS lo hoàn toàn | không thấy, không kiểm soát | | AWS managed key (aws/s3, aws/rds) | AWS tự xoay, bạn KHÔNG bật/tắt được | không sửa được key policy | | Customer managed key | BẬT/TẮT được, chu kỳ 90-2560 ngày | toàn quyền: policy, grant, xoá, alias | | Chi phí | miễn phí | miễn phí | tính tiền theo khoá mỗi tháng + phí API |

Từ khoá nhận diện:

"xoay khoá tự động, tuân thủ" → customer managed CMK + automatic rotation "kiểm soát chính sách khoá" → customer managed "khoá phải do công ty sinh ra" → imported key material (không xoay tự động được) "khoá trong thiết bị phần cứng riêng" → CloudHSM, hoặc KMS custom key store "ai đã dùng khoá này" → CloudTrail

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xoay đã bật chưa | get-key-rotation-status --key-id ... | | Đã xoay bao nhiêu lần | list-key-rotations | | Ai đang dùng khoá | CloudTrail, lọc theo resources.ARN của khoá |

Và một cảnh báo nên đặt ngay cho mọi CMK quan trọng: alarm khi có lời gọi ScheduleKeyDeletion. Xoá một khoá KMS đồng nghĩa với việc mọi dữ liệu mã hoá bằng nó trở thành không đọc được vĩnh viễn — có thời gian chờ tối thiểu bảy ngày để huỷ lệnh, nhưng thời gian đó chỉ có ích nếu ai đó thực sự nhận được thông báo.