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

Đáp án

B — Dùng Amazon S3 Inventory report để liệt kê các đối tượng sao chép thất bại.

Vì sao đúng

Đề yêu cầu một danh sách đối tượng cụ thể, được tạo hằng ngày, tự động — và đó chính xác là mô tả của S3 Inventory.

⚠ Điểm mấu chốt — Inventory là báo cáo LIỆT KÊ TỪNG ĐỐI TƯỢNG:

S3 Inventory
        ↓
    Xuất một tệp CSV / ORC / Parquet vào bucket đích
        ↓
    Mỗi DÒNG là MỘT ĐỐI TƯỢNG, với các cột bạn chọn:
        - Replication status  ← cột cần cho đề này
        - Storage class, size, last modified
        - Encryption status, Object Lock, multipart
        ↓
    Lịch chạy: HẰNG NGÀY hoặc hằng tuần

⚠ Cột ReplicationStatus có bốn giá trị, phải nhớ:

PENDING   → đang chờ sao chép
COMPLETED → đã sao chép xong
FAILED    → THẤT BẠI  ← thứ đề cần
REPLICA   → chính là bản sao ở bucket đích

⚠ Lọc ra danh sách bằng Athena:

SELECT key, replication_status, last_modified_date
FROM s3_inventory
WHERE replication_status = 'FAILED'
  AND dt = '2026-09-02-00-00';

⚠ Và nên bổ sung một cơ chế cảnh báo tức thì bên cạnh báo cáo ngày:

S3 Event Notification: s3:Replication:OperationFailedReplication
        ↓
    → EventBridge → SNS
        ↓
    → biết NGAY khi có đối tượng lỗi,
      thay vì chờ báo cáo ngày hôm sau

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

• A (dùng S3 Storage Lens) — đây là phương án gần nhất vì Storage Lens cũng là công cụ phân tích S3. Nhưng nó cho số liệu TỔNG HỢP (dung lượng, số đối tượng, phân bố theo lớp lưu trữ), không liệt kê từng đối tượng. Đề cần một danh sách tên tệp cụ thể.

• C (dùng S3 Select) — dùng để truy vấn nội dung BÊN TRONG một đối tượng (CSV, JSON, Parquet) bằng SQL. Nó không truy vấn siêu dữ liệu của bucket. (Nó lại rất hữu ích để đọc chính tệp inventory.)

• D (đẩy chỉ số sao chép qua SQS rồi tự viết mã tổng hợp) — vòng vo và tự chế lại thứ đã có sẵn; chỉ số CloudWatch cũng chỉ cho số đếm, không cho danh sách tệp.

Ghi nhớ

⚠ Ba công cụ phân tích S3 hay bị nhầm — bảng phải thuộc: | Công cụ | Cho ra | |---|---| | S3 Inventory | danh sách TỪNG ĐỐI TƯỢNG + siêu dữ liệu, theo lịch | | S3 Storage Lens | số liệu tổng hợp theo bucket/tài khoản/tổ chức | | S3 Select | truy vấn nội dung bên trong một tệp | | (kèm) Athena | truy vấn SQL trên tệp inventory hoặc log |

Từ khoá nhận diện:

"danh sách các đối tượng thoả điều kiện" → S3 Inventory "tổng quan dung lượng, xu hướng chi phí" → Storage Lens "đọc vài dòng trong một tệp CSV lớn" → S3 Select "biết NGAY khi sao chép lỗi" → S3 Event Notification / EventBridge "đếm số lần lỗi" → chỉ số CloudWatch OperationsFailedReplication

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Inventory đã cấu hình chưa | list-bucket-inventory-configurations | | Báo cáo đầu tiên khi nào có | có thể mất tới 48 giờ, sau đó mới theo lịch | | Vì sao lỗi | CloudTrail và quyền của IAM role dùng cho replication |

Và một lưu ý về kỳ vọng khi mới bật tính năng này: báo cáo Inventory đầu tiên có thể mất tới 48 giờ mới xuất hiện. Đó là điều nên nói trước với Team Lead trong đề — nếu không, sáng hôm sau khi bucket đích vẫn trống rỗng, mọi người sẽ tưởng cấu hình bị sai và đi sửa một thứ vốn đang hoạt động hoàn toàn bình thường.

Đáp án

C — Dùng AWS Direct Connect KẾT HỢP với VPN.

Vì sao đúng

Đề liệt kê bốn tính chất, và một trong số đó loại bỏ Direct Connect đơn thuần:

⚠ Điểm mấu chốt — Direct Connect KHÔNG mã hoá dữ liệu:

Direct Connect là một sợi cáp riêng
        ↓
    Riêng tư về mặt VẬT LÝ (không đi qua internet công cộng)
        ↓
    Nhưng dữ liệu trên đó ở dạng THÔ, KHÔNG mã hoá
        ↓
    → yêu cầu tuân thủ đòi mã hoá thì chưa đạt
        ↓
Chạy IPsec VPN ĐÈ LÊN Direct Connect
        ↓
    → vừa riêng tư, vừa ổn định, vừa MÃ HOÁ

⚠ Kiến trúc cụ thể:

Trung tâm dữ liệu
        ↓  cáp riêng qua Direct Connect location
    Public VIF (Virtual Interface)
        ↓  chạy IPsec VPN qua đó
    Virtual Private Gateway hoặc Transit Gateway
        ↓
    VPC

Điểm cần nhớ: VPN phải chạy qua Public VIF, vì nó cần tới các endpoint công khai của AWS.

⚠ Một lựa chọn hiện đại hơn cũng nên biết:

MACsec (802.1AE)
        ↓
    Mã hoá ở TẦNG 2, ngay trên cổng Direct Connect
        ↓
    → không tốn chi phí đóng gói như IPsec
    → nhưng chỉ có ở một số cổng chuyên dụng 10/100 Gbps

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

• B (chỉ dùng Direct Connect) — đây là phương án gần nhất và thoả ba trên bốn yêu cầu. Nhưng nó không mã hoá, mà đề nói rõ cần "encrypted". Đây chính là bẫy trung tâm của câu hỏi.

• D (chỉ dùng Site-to-Site VPN) — có mã hoá nhưng chạy qua internet công cộng, nên không phải kết nối riêng, độ trễ dao động, và băng thông chỉ khoảng 1,25 Gbps mỗi đường hầm. Không thoả "low latency, high throughput".

• A (dùng Transit Gateway) — Transit Gateway là bộ định tuyến trung tâm để nối nhiều VPC và nhiều mạng với nhau. Nó không phải một kết nối vật lý tới trung tâm dữ liệu; bản thân nó vẫn cần Direct Connect hoặc VPN để nối ra ngoài.

Ghi nhớ

⚠ Ba lựa chọn kết nối lai — bảng phải thuộc: | | VPN | Direct Connect | DX + VPN | |---|---|---|---| | Riêng tư | không (qua internet) | có | có | | Mã hoá | có | KHÔNG | CÓ | | Băng thông | ~1,25 Gbps/tunnel | 50 Mbps – 100 Gbps | như DX | | Độ trễ | dao động | ổn định | ổn định | | Thời gian triển khai | vài phút | vài tuần – vài tháng | vài tuần | | Chi phí | thấp | cao | cao nhất |

Từ khoá nhận diện:

"riêng VÀ mã hoá" → Direct Connect + VPN "riêng, độ trễ ổn định" → Direct Connect "nhanh, rẻ, ngay lập tức" → Site-to-Site VPN "Direct Connect có mã hoá sẵn" → LUÔN SAI "nối nhiều VPC và nhiều chi nhánh" → Transit Gateway "dự phòng cho Direct Connect" → VPN làm đường backup

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kết nối DX có lên không | describe-connections, trạng thái available | | VPN có mã hoá thật không | describe-vpn-connections, xem cả hai tunnel | | Định tuyến đúng chưa | route table VPC, và BGP session phía bạn |

Và một điểm hay bị bỏ sót khi lập kế hoạch ngân sách: Direct Connect tính phí cổng theo giờ CỘNG phí truyền dữ liệu ra, và bạn còn phải trả riêng cho đối tác viễn thông cung cấp đoạn cáp từ trung tâm dữ liệu tới Direct Connect location. Đề đã nói công ty chấp nhận chi phí vận hành lớn — nhưng con số đó thường lớn hơn nhiều so với ước tính ban đầu, vì phần đắt nhất lại nằm ở hoá đơn của bên thứ ba chứ không phải của AWS.

Đáp án

B — Tạo DB snapshot của instance hiện có, khôi phục snapshot thành một instance MỚI, rồi nâng cấp phiên bản trên instance mới đó và thử nghiệm an toàn.

Vì sao đúng

Đề nêu hai yêu cầu: thử với dữ liệu và cấu hình THẬT của production, và KHÔNG được ảnh hưởng tới production.

⚠ Điểm mấu chốt — snapshot mang theo cả dữ liệu lẫn cấu hình:

Snapshot của RDS chứa:
        - toàn bộ dữ liệu tại thời điểm chụp
        - lược đồ, chỉ mục, thống kê
        ↓
    Khôi phục thành instance MỚI, TÁCH BIỆT HOÀN TOÀN
        ↓
    Gắn cùng parameter group và option group
        ↓
    → môi trường thử giống production nhất có thể
    → mà production không hề bị đụng tới

⚠ Quy trình đầy đủ:

# 1. Chụp snapshot
aws rds create-db-snapshot \
  --db-instance-identifier prod-db \
  --db-snapshot-identifier prod-db-truoc-nang-cap

# 2. Khôi phục thành instance thử nghiệm
aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier thu-nang-cap \
  --db-snapshot-identifier prod-db-truoc-nang-cap \
  --db-parameter-group-name prod-parameter-group

# 3. Nâng cấp phiên bản trên instance THỬ
aws rds modify-db-instance \
  --db-instance-identifier thu-nang-cap \
  --engine-version 15.4 --allow-major-version-upgrade \
  --apply-immediately

⚠ Ba thứ phải kiểm tra trên instance thử — đây mới là mục đích thật:

1. Nâng cấp có chạy trót lọt không, mất bao lâu
        → con số này quyết định thời gian ngừng dịch vụ thật
2. Ứng dụng có chạy đúng trên phiên bản mới không
        → cú pháp SQL đổi, hàm bị bỏ, hành vi khác đi
3. Hiệu năng có tụt không
        → trình tối ưu truy vấn đổi giữa các phiên bản lớn,
          một truy vấn đang nhanh có thể đột nhiên chậm

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

• C (tạo read replica rồi nâng cấp replica lên phiên bản mới) — đây là phương án gần nhất và có vẻ rất hợp lý, nhưng vướng một ràng buộc kỹ thuật: replica không được ở phiên bản CAO HƠN máy chính ở nâng cấp phiên bản lớn. Ngoài ra replica vẫn sao chép liên tục từ production, nên thử nghiệm trên đó có thể ảnh hưởng ngược lại.

• A (mua một instance đã có phiên bản mới rồi khôi phục snapshot vào đó) — sai về mặt kỹ thuật: không khôi phục snapshot vào một instance đang tồn tại được. restore-db-instance-from-db-snapshot luôn tạo instance mới.

• D (dùng CloudFormation dựng một cấu hình giống production) — cho ra hạ tầng giống nhau nhưng CƠ SỞ DỮ LIỆU TRỐNG. Đề nói rõ phải thử với dữ liệu production — mà lỗi nâng cấp thường lộ ra chính ở dữ liệu thật và khối lượng thật.

Ghi nhớ

⚠ Hai loại nâng cấp phiên bản RDS — bảng phải thuộc: | Loại | Ví dụ | Đặc điểm | |---|---|---| | Minor version | 14.7 → 14.9 | tự động được (AutoMinorVersionUpgrade), ít rủi ro | | Major version | 14.x → 15.x | phải làm tay, cần --allow-major-version-upgrade, rủi ro cao |

Từ khoá nhận diện:

"thử nâng cấp với dữ liệu thật" → snapshot → restore → nâng cấp bản sao "nâng cấp production ít gián đoạn nhất" → blue/green deployment của RDS "replica cao phiên bản hơn máy chính" → KHÔNG được với major version "khôi phục vào instance đang có" → KHÔNG TỒN TẠI, luôn tạo mới "quay về nếu nâng cấp hỏng" → snapshot trước khi nâng cấp

⚠ RDS Blue/Green Deployment — cách nâng cấp production tốt nhất hiện nay: | Nội dung | Chi tiết | |---|---| | AWS dựng | một môi trường green là bản sao của production | | Green được | nâng cấp phiên bản, sửa lược đồ, đổi parameter group | | Đồng bộ liên tục | green nhận dữ liệu mới từ blue theo thời gian thực | | Switchover | thường dưới một phút, đổi tên endpoint | | Quay lui | blue vẫn còn nguyên |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có nâng cấp thẳng lên phiên bản đích được không | describe-db-engine-versions --engine-version <hiện tại>, xem ValidUpgradeTarget | | Nâng cấp mất bao lâu | đo trên instance thử | | Ứng dụng có chạy được không | trỏ môi trường staging vào instance thử |

Và một lời khuyên đắt giá về nâng cấp phiên bản lớn: hãy đo và so sánh hiệu năng, đừng chỉ kiểm tra "chạy được hay không". Nâng cấp phiên bản lớn thường thay đổi trình tối ưu truy vấn, và hậu quả điển hình không phải là lỗi — mà là một vài truy vấn quan trọng đột nhiên chọn kế hoạch thực thi khác và chậm đi hàng chục lần. Chuyện đó sẽ không lộ ra trong một bài kiểm tra chức năng; nó lộ ra vào giờ cao điểm đầu tiên sau khi nâng cấp.

Đáp án

A — Network Load Balancer.

Vì sao đúng

Con số trong đề là chìa khoá: hàng triệu request mỗi giây.

⚠ Điểm mấu chốt — NLB được thiết kế cho quy mô này:

Network Load Balancer (tầng 4 — TCP/UDP/TLS)
        ↓
    Xử lý HÀNG TRIỆU request mỗi giây
    Độ trễ rất thấp (~100 micro giây)
    Chịu được cú tăng đột ngột mà KHÔNG cần pre-warm
        ↓
    → đúng yêu cầu của đề

Application Load Balancer (tầng 7 — HTTP/HTTPS)
        ↓
    Phải phân tích header, định tuyến theo đường dẫn,
    theo host, theo cookie...
        ↓
    → nhiều tính năng hơn, nhưng độ trễ cao hơn (~400 micro giây)
    → và co giãn CHẬM hơn khi lưu lượng tăng đột ngột

⚠ Vì sao NLB nhanh hơn — nó làm ít việc hơn:

NLB hoạt động ở tầng 4
        ↓
    Không đọc nội dung HTTP
    Không kết thúc kết nối (khi không dùng TLS)
        ↓
    → giữ nguyên IP nguồn của client tới thẳng target
    → gần như chỉ chuyển tiếp gói tin

⚠ Và NLB còn hai đặc tính rất hợp với dịch vụ phát video:

IP TĨNH cho mỗi Availability Zone
        ↓
    → gán được Elastic IP
    → khách hàng doanh nghiệp mở firewall theo IP được
    → thân thiện với DNS và với thiết bị đầu cuối

Hỗ trợ UDP
        ↓
    → cần cho các giao thức streaming thời gian thực
    → ALB KHÔNG hỗ trợ UDP

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

• C (Application Load Balancer) — đây là phương án gần nhất và là lựa chọn mặc định cho hầu hết ứng dụng web. Nhưng ở quy mô hàng triệu request mỗi giây thì độ trễ tầng 7 và thời gian co giãn của nó trở thành vấn đề; đề nhấn mạnh quy mô, không nhấn mạnh định tuyến thông minh.

• D (Classic Load Balancer) — thế hệ cũ, AWS khuyến nghị chuyển sang ALB hoặc NLB. Kém hơn cả hai về mọi mặt.

• B ("Infrastructure Load Balancer") — không tồn tại. Bốn loại thật là ALB, NLB, GWLB (Gateway Load Balancer) và CLB.

Ghi nhớ

⚠ Bốn loại Elastic Load Balancer — bảng phải thuộc: | Loại | Tầng | Giao thức | Dùng cho | |---|---|---|---| | ALB | 7 | HTTP, HTTPS, gRPC, WebSocket | web, microservice, định tuyến thông minh | | NLB | 4 | TCP, UDP, TLS | cực cao tải, độ trễ thấp, IP tĩnh | | GWLB | 3 | IP (GENEVE) | thiết bị bảo mật của bên thứ ba | | CLB | 4 và 7 | HTTP, HTTPS, TCP, SSL | thế hệ cũ, không dùng cho hệ thống mới |

Từ khoá nhận diện:

"hàng triệu request mỗi giây" → NLB "độ trễ cực thấp" → NLB "IP tĩnh / Elastic IP cho load balancer" → NLB "UDP" → NLB (ALB không hỗ trợ) "định tuyến theo đường dẫn, theo host" → ALB "WAF, xác thực Cognito" → ALB hoặc CloudFront "tường lửa của hãng thứ ba" → GWLB

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đang chịu tải bao nhiêu | chỉ số ActiveFlowCount, NewFlowCount (NLB) | | Target có khoẻ không | describe-target-health | | Chi phí bao nhiêu | LCU — tính theo kết nối, băng thông, và số quy tắc |

Và một lời khuyên khi cân nhắc giữa hai loại: hãy chọn NLB vì bạn cần đặc tính của nó (quy mô, IP tĩnh, UDP), chứ đừng chọn chỉ vì nó "nhanh hơn". Với phần lớn ứng dụng web, khác biệt vài trăm micro giây là vô hình so với thời gian ứng dụng xử lý — trong khi những thứ bạn đánh mất khi bỏ ALB (WAF, định tuyến theo đường dẫn, xác thực tích hợp) thì phải tự dựng lại bằng tay ở nơi khác.

Đáp án

A — Tạo cross-stack reference: dùng trường Export trong Outputs của network stack, rồi dùng hàm Fn::ImportValue để nhận giá trị vào web application stack.

Vì sao đúng

Cơ chế này là một cặp hai bước, mỗi bước ở một stack — và cả hai vế của phương án A đều đúng.

⚠ Điểm mấu chốt — Outputs là MỤC, Export là TRƯỜNG bên trong nó:

Outputs:                       ← MỤC của template
  IdVpc:
    Value: !Ref VpcChinh
    Export:                    ← TRƯỜNG khiến giá trị dùng được từ ngoài
      Name: !Sub "${AWS::StackName}-IdVpc"
        ↓
    Chỉ khai Outputs mà KHÔNG khai Export
        ↓
    → giá trị chỉ hiện trên console để người đọc
    → stack khác KHÔNG import được

Đây chính là chỗ phân biệt phương án A với B và D.

⚠ Và bên nhận phải dùng Fn::ImportValue, không phải Ref:

!Ref          → tham chiếu tài nguyên hoặc tham số TRONG CÙNG stack
!ImportValue  → nhận giá trị export từ stack KHÁC
        ↓
    Dùng !Ref cho một tên export → CloudFormation không hiểu

Đây là chỗ phân biệt phương án A với C và D.

# Trong web application stack
May:
  Type: AWS::EC2::Instance
  Properties:
    SubnetId: !ImportValue "mang-chinh-IdSubnet"

Xem thêm câu #11657: cùng cơ chế nhưng chỉ hỏi vế cung cấp giá trị, với bẫy là trường giả Expose.

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

• B (dùng trường Outputs để export, rồi Fn::ImportValue để nhận) — đây là phương án gần nhất và vế thứ hai hoàn toàn đúng. Nhưng vế thứ nhất thiếu chính xác: Outputs là mục chứa, còn thứ khiến giá trị chia sẻ được là trường Export bên trong. Không có Export thì ImportValue không tìm thấy gì.

• C (Export rồi dùng Ref để nhận) — vế đầu đúng, vế sau sai: Ref không đọc được giá trị export từ stack khác.

• D (Outputs rồi Ref) — sai cả hai vế.

Ghi nhớ

⚠ Cặp export/import — bảng phải thuộc: | Stack | Khai gì | |---|---| | Nguồn | mục Outputs + trường Export.Name | | Đích | hàm Fn::ImportValue (dạng rút gọn: !ImportValue) |

Từ khoá nhận diện:

"chia sẻ giá trị giữa hai stack" → Export + Fn::ImportValue "Ref cho giá trị của stack khác" → LUÔN SAI "chỉ khai Outputs là đủ" → SAI, phải có Export "chéo Region hoặc chéo tài khoản" → SSM Parameter Store, export/import không làm được "stack cha truyền cho stack con" → nested stack + Parameters

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có những export nào | list-exports | | Ai đang dùng một export | list-imports --export-name <ten> | | Vì sao không xoá được stack | thông báo lỗi nêu đích danh export đang bị dùng |

Và một quy ước đặt tên nên áp dụng ngay: luôn đặt tiền tố tên stack cho mọi export — !Sub "${AWS::StackName}-IdVpc". Tên export dùng chung không gian tên trong cả tài khoản và Region, nên một export tên "VpcId" trần trụi sẽ khiến mọi môi trường thứ hai (staging, dev) không dựng được vì trùng tên — và bạn chỉ phát hiện ra điều đó khi mọi thứ ở môi trường đầu tiên đã hoạt động trơn tru.

Đáp án

A — Tạo chỉ số tuỳ chỉnh độ phân giải cao (high-resolution custom metric) và đẩy dữ liệu bằng một script chạy mỗi 10 giây.

Vì sao đúng

Con số 10 giây trong đề là chìa khoá: nó vượt qua khả năng của mọi chỉ số dựng sẵn.

⚠ Điểm mấu chốt — ba mức độ phân giải, và trần của mỗi mức:

Basic monitoring    → 5 PHÚT  (miễn phí, mặc định)
Detailed monitoring → 1 PHÚT  (có phí, một công tắc)
        ↓
    Cả hai đều KHÔNG xuống được 10 giây
        ↓
High-resolution custom metric → tới 1 GIÂY
        ↓
    → đây là cách duy nhất đạt được 10 giây

⚠ Cách đẩy chỉ số độ phân giải cao:

aws cloudwatch put-metric-data \
  --namespace "UngDungCuaToi" \
  --metric-name CpuChiTiet \
  --dimensions InstanceId=i-xxxxxxxx \
  --value 87.5 \
  --storage-resolution 1        # 1 = high-resolution

Tham số --storage-resolution 1 là thứ quyết định: mặc định là 60 (chuẩn), đặt 1 mới cho phép lưu ở độ phân giải giây.

⚠ Và alarm cũng có hai mức tương ứng:

Alarm thường            → chu kỳ tối thiểu 60 giây
High-resolution alarm   → chu kỳ 10 hoặc 30 giây
        ↓
    → chỉ dùng được với chỉ số high-resolution
    → tính phí cao hơn alarm thường

Xem thêm câu #11615: cùng chủ đề độ phân giải chỉ số, nhưng ở đó yêu cầu chỉ là 1 phút nên detailed monitoring là đáp án đúng và tối ưu. Hai câu không mâu thuẫn — ngưỡng yêu cầu quyết định công cụ.

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

• C (bật EC2 detailed monitoring) — đây là phương án gần nhất và là câu trả lời đúng nếu đề hỏi 1 phút. Nhưng detailed monitoring chỉ xuống tới 60 giây, không tới 10 giây. Đây chính là ranh giới mà câu hỏi muốn kiểm tra.

• B (lấy thẳng từ CloudWatch Metrics) — chỉ số dựng sẵn có sẵn thật, nhưng ở 5 phút (basic) — quá thô so với yêu cầu.

• D (mở ticket với AWS) — độ phân giải chỉ số không phải hạn mức có thể xin tăng; đó là giới hạn kiến trúc của dịch vụ.

Ghi nhớ

⚠ Ba mức độ phân giải chỉ số — bảng phải thuộc: | Mức | Chu kỳ | Cách bật | |---|---|---| | Basic monitoring | 5 phút | mặc định, miễn phí | | Detailed monitoring | 1 phút | một công tắc, có phí theo instance | | High-resolution custom metric | tới 1 giây | PutMetricData với --storage-resolution 1 |

Từ khoá nhận diện:

"nhanh hơn 1 phút" → high-resolution custom metric "đúng 1 phút" → detailed monitoring "RAM, dung lượng đĩa" → CloudWatch agent "alarm phản ứng trong 10 giây" → high-resolution alarm "xin AWS tăng độ phân giải" → KHÔNG được

⚠ Thời gian lưu trữ theo độ phân giải — đây là cái giá của chỉ số dày: | Độ phân giải | Giữ được | |---|---| | Dưới 60 giây | CHỈ 3 GIỜ | | 60 giây | 15 ngày | | 5 phút | 63 ngày | | 1 giờ | 15 tháng | | Lưu ý | dữ liệu tự gộp lên mức thô hơn, không mất hẳn |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chỉ số có ở độ phân giải cao không | truy vấn với --period 10, xem có điểm liên tục không | | Chi phí bao nhiêu | Cost Explorer, lọc dịch vụ CloudWatch | | Dữ liệu cũ còn không | quá 3 giờ là dữ liệu giây đã bị gộp lên |

Và một cảnh báo về giới hạn dễ gây thất vọng: chỉ số độ phân giải dưới 60 giây chỉ được giữ đúng 3 giờ. Nghĩa là dữ liệu 10 giây rất tuyệt để quan sát thời gian thực và để gỡ lỗi ngay lúc sự cố đang diễn ra, nhưng hoàn toàn vô dụng cho việc phân tích một sự cố xảy ra từ hôm qua — lúc đó bạn chỉ còn bản đã gộp lên mức 1 phút hoặc 5 phút.

Đáp án

B — Bật Enhanced Monitoring cho RDS DB instance.

Vì sao đúng

CTO hỏi chỉ số ở MỨC HỆ ĐIỀU HÀNH, và đó chính xác là ranh giới phân biệt hai công cụ giám sát của RDS.

⚠ Điểm mấu chốt — chỉ số CloudWatch thường lấy từ HYPERVISOR, Enhanced Monitoring lấy từ BÊN TRONG máy:

Chỉ số CloudWatch chuẩn của RDS
        ↓
    Đo từ TẦNG HYPERVISOR, chu kỳ tối thiểu 60 giây
        ↓
    → CPUUtilization, FreeableMemory, ReadIOPS...
    → nhưng KHÔNG thấy vào trong hệ điều hành

Enhanced Monitoring
        ↓
    Một AGENT chạy TRÊN CHÍNH instance
        ↓
    → chỉ số cấp hệ điều hành, chu kỳ xuống tới 1 GIÂY
    → thấy được TỪNG TIẾN TRÌNH đang chạy

⚠ Enhanced Monitoring cho những gì mà CloudWatch thường không có:

Chỉ số wait của CPU là ví dụ điển hình: CloudWatch thường chỉ báo "CPU 40%", còn Enhanced Monitoring cho biết trong đó có bao nhiêu phần trăm là chờ đĩa — thông tin quyết định khi đo chuẩn hiệu năng như CTO yêu cầu.

⚠ Ba điều cần biết khi bật:

Chu kỳ: 1, 5, 10, 15, 30 hoặc 60 giây
        ↓
Dữ liệu KHÔNG đi vào CloudWatch Metrics
        ↓
    Nó đi vào CloudWatch LOGS, log group RDSOSMetrics
        ↓
    → muốn cảnh báo thì phải dùng metric filter
        ↓
Cần một IAM role cho RDS ghi vào CloudWatch Logs

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

• D (bật Performance Insights) — đây là phương án gần nhất và là công cụ tuyệt vời, nhưng nó nhìn ở tầng CƠ SỞ DỮ LIỆU: truy vấn nào tốn nhiều nhất, đang chờ loại tài nguyên nào (DB Load theo wait event). CTO hỏi chỉ số hệ điều hành, đó là địa hạt của Enhanced Monitoring. (Trong thực tế, đo chuẩn hiệu năng nên bật cả hai.)

• A (đăng ký chỉ số CloudWatch theo dõi CPU của máy chủ chạy RDS) — chỉ số CloudWatch chuẩn không đủ chi tiết: chỉ có một con số CPU tổng, không tách theo tiến trình, không có I/O wait, và tối thiểu 60 giây.

• C (đăng ký RDS event notification) — RDS events báo về sự kiện vòng đời: failover, khởi động lại, snapshot xong, bảo trì. Chúng không phải chỉ số hiệu năng.

Ghi nhớ

⚠ Bốn công cụ giám sát RDS — bảng phải thuộc: | Công cụ | Nhìn vào | |---|---| | CloudWatch metrics | hypervisor — CPU, bộ nhớ, IOPS, kết nối (tối thiểu 60 giây) | | Enhanced Monitoring | hệ điều hành — tiến trình, I/O wait (tới 1 giây) | | Performance Insights | cơ sở dữ liệu — truy vấn, wait event, DB Load | | RDS Events | vòng đời — failover, snapshot, bảo trì |

Từ khoá nhận diện:

"chỉ số cấp hệ điều hành", "từng tiến trình" → Enhanced Monitoring "truy vấn nào chậm", "nghẽn ở đâu trong DB" → Performance Insights "báo khi failover xảy ra" → RDS Events + SNS "CPU, kết nối, IOPS ở mức tổng" → CloudWatch metrics "log truy vấn chậm" → bật slow query log, đẩy sang CloudWatch Logs

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã bật chưa | describe-db-instances, xem MonitoringInterval khác 0 | | Dữ liệu ở đâu | CloudWatch Logs, log group RDSOSMetrics | | Chi phí bao nhiêu | tính theo lượng log — chu kỳ 1 giây tạo rất nhiều dữ liệu |

Và một lời khuyên khi làm việc đo chuẩn hiệu năng như CTO yêu cầu: hãy bật Enhanced Monitoring ở chu kỳ 1 giây trong lúc đo, rồi hạ xuống 60 giây hoặc tắt hẳn khi xong. Chu kỳ một giây cho bức tranh cực kỳ chi tiết đúng lúc bạn cần, nhưng nếu để nguyên như vậy trên một fleet cơ sở dữ liệu sản xuất thì lượng log ghi vào CloudWatch Logs sẽ trở thành một khoản chi phí đều đặn cho dữ liệu mà sau đó không ai còn mở ra xem nữa.

Đáp án

D, E — hai việc cần làm:

• D — Lưu bí mật dưới dạng SecureString trong SSM Parameter Store.
• E — Kiểm toán bằng CloudTrail.

Vì sao đúng

Đề nêu ba yêu cầu, và cặp SecureString + CloudTrail thoả cả ba:

⚠ Điểm mấu chốt — SecureString gộp việc mã hoá vào chính API của Parameter Store:

Ghi:
    aws ssm put-parameter --name /ung-dung/mat-khau-db \
      --value "bi-mat" --type SecureString --key-id alias/khoa-cua-toi

Đọc:
    aws ssm get-parameter --name /ung-dung/mat-khau-db \
      --with-decryption
        ↓
    → MỘT lời gọi, Parameter Store tự gọi KMS giải mã
    → ứng dụng nhận về giá trị đã sẵn sàng dùng

⚠ Vì sao "mã hoá bằng KMS trước rồi mới lưu" là cách dở hơn:

Tự mã hoá trước khi lưu
        ↓
    Ghi: gọi kms:Encrypt → rồi gọi ssm:PutParameter
    Đọc: gọi ssm:GetParameter → rồi gọi kms:Decrypt
        ↓
    → HAI lời gọi mỗi chiều
    → phải tự viết mã mã hoá/giải mã
    → phải tự xử lý mã hoá base64, tự lo lỗi
        ↓
    → vi phạm yêu cầu "API calls to be simple"

⚠ Và CloudTrail ghi lại đúng thứ đề cần:

{
  "eventSource": "kms.amazonaws.com",
  "eventName": "Decrypt",
  "userIdentity": { "arn": "arn:aws:sts::...:assumed-role/VaiTroUngDung/i-xxxx" },
  "requestParameters": {
    "encryptionContext": { "PARAMETER_ARN": "arn:aws:ssm:...:parameter/ung-dung/mat-khau-db" }
  }
}

encryptionContext cho biết tham số nào đã được giải mã — chính xác là "audit trail" mà yêu cầu tuân thủ đòi hỏi.

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

• C (mã hoá bằng KMS trước rồi mới lưu vào Parameter Store) — đây là phương án gần nhất và về mặt bảo mật thì hoạt động, nhưng nó vi phạm yêu cầu "API đơn giản": hai lời gọi mỗi chiều, cộng thêm mã tự viết. SecureString làm đúng việc đó mà chỉ cần một lời gọi.

• A (kiểm toán bằng "SSM Audit Trail") — không tồn tại dịch vụ nào tên như vậy. Việc kiểm toán trên AWS luôn là CloudTrail.

• B (lưu bí mật dạng PlainText) — trái thẳng yêu cầu tuân thủ: String thường KHÔNG được mã hoá, ai đọc được tham số là đọc được bí mật.

Ghi nhớ

⚠ Ba kiểu tham số của Parameter Store — bảng phải thuộc: | Kiểu | Nội dung | |---|---| | String | văn bản thuần, KHÔNG mã hoá | | StringList | danh sách phân tách bằng dấu phẩy, không mã hoá | | SecureString | mã hoá bằng KMS, giải mã bằng --with-decryption |

Từ khoá nhận diện:

"lưu bí mật đơn giản, miễn phí" → Parameter Store SecureString "tự động xoay khoá bí mật" → Secrets Manager "kiểm toán ai đã giải mã" → CloudTrail (sự kiện kms:Decrypt) "SSM Audit Trail" → KHÔNG TỒN TẠI "mã hoá thủ công rồi mới lưu" → thường SAI, đã có SecureString

⚠ Parameter Store và Secrets Manager — bảng phải thuộc: | | Parameter Store | Secrets Manager | |---|---|---| | Chi phí | MIỄN PHÍ (Standard tier) | có phí theo bí mật + theo lời gọi | | Tự xoay khoá | không (tự viết Lambda) | CÓ, dựng sẵn | | Tích hợp RDS/Redshift/DocumentDB | không | có, xoay mật khẩu tự động | | Kích thước | 4 KB (Standard), 8 KB (Advanced) | 64 KB | | Sao chép chéo Region | không (Advanced có tính năng riêng) | có | | Lưu trữ phiên bản | có | có | | Chọn khi | cấu hình và bí mật đơn giản | bí mật cần xoay tự động |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tham số đã mã hoá chưa | describe-parameters, xem Type: SecureString | | Ai đã giải mã | CloudTrail, lọc eventName = Decrypt | | Khoá nào được dùng | get-parameter, xem KeyId |

Và một lời khuyên về kiểm toán: hãy dùng CMK riêng thay cho khoá mặc định aws/ssm, ngay cả khi chỉ để kiểm toán tốt hơn. Với khoá mặc định, bạn không sửa được key policy, nghĩa là không kiểm soát được ở tầng khoá ai có quyền giải mã. Với CMK riêng, key policy trở thành một lớp phòng thủ thứ hai độc lập với chính sách IAM — và trong một cuộc kiểm toán tuân thủ, "hai lớp kiểm soát độc lập" là câu trả lời khác hẳn với "một lớp".

Đáp án

A — Dedicated Instances.

Vì sao đúng

Đề nêu hai ràng buộc: phần cứng riêng cho một khách hàng (single-tenant) và TIẾT KIỆM CHI PHÍ NHẤT. Hai lựa chọn thoả điều kiện đầu, và giá là thứ phân định.

⚠ Điểm mấu chốt — cả hai đều cô lập phần cứng, nhưng bán theo hai cách khác nhau:

Dedicated Instance
        ↓
    Chạy trên phần cứng KHÔNG chia sẻ với tài khoản khác
    Tính tiền THEO INSTANCE
        ↓
    → chỉ trả cho những máy đang chạy

Dedicated Host
        ↓
    Thuê nguyên một MÁY CHỦ VẬT LÝ
    Tính tiền THEO HOST
        ↓
    → trả tiền cho cả máy chủ, dù chỉ dùng một phần
    → đắt hơn nếu không lấp đầy host

⚠ Vậy khi nào mới cần Dedicated Host — điều làm nên khác biệt:

Dedicated Host cho bạn NHÌN THẤY phần cứng bên dưới:
        - biết số socket, số lõi vật lý
        - chọn được instance nằm trên host nào
        - host giữ nguyên qua các lần stop/start
        ↓
    → cần cho GIẤY PHÉP PHẦN MỀM tính theo socket/lõi
      (Oracle, Windows Server, SQL Server BYOL)
    → cần cho quy định đòi kiểm soát vị trí vật lý

Đề chỉ nói "phần cứng một khách hàng theo hướng dẫn bảo mật", không nhắc tới giấy phép hay yêu cầu về vị trí vật lý — nên Dedicated Instance là đủ và rẻ hơn.

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

• B (Dedicated Hosts) — đây là phương án gần nhất và cũng cho phần cứng riêng, nhưng đắt hơn: bạn trả tiền cho cả máy chủ vật lý, kể cả phần dung lượng không dùng tới. Đề hỏi cách tiết kiệm nhất.

• C (On-Demand Instances) — On-Demand là mô hình GIÁ, không phải mô hình thuê phần cứng. Mặc định nó chạy trên phần cứng dùng chung với khách hàng khác.

• D (Spot Instances) — cũng là mô hình giá, cũng chạy trên phần cứng dùng chung, và còn có thể bị thu hồi bất cứ lúc nào — hoàn toàn không hợp với hệ thống của một công ty dịch vụ tài chính.

Ghi nhớ

⚠ Ba mô hình thuê phần cứng (tenancy) của EC2 — bảng phải thuộc: | Tenancy | Phần cứng | Tính tiền | |---|---|---| | default (shared) | dùng chung với khách khác | theo instance, rẻ nhất | | dedicated | riêng cho tài khoản bạn | theo instance | | host | riêng, và bạn thấy được host | theo HOST |

Từ khoá nhận diện:

"phần cứng riêng, rẻ nhất" → Dedicated Instance "giấy phép tính theo socket/lõi (BYOL)" → Dedicated Host "cần biết instance nằm trên host nào" → Dedicated Host "độ trễ mạng thấp giữa các máy" → cluster placement group (không phải tenancy) "On-Demand / Spot / RI" → mô hình GIÁ, không phải tenancy

⚠ Đừng nhầm tenancy với mô hình giá — hai trục hoàn toàn khác nhau: | Trục | Các lựa chọn | |---|---| | Tenancy (phần cứng) | shared / dedicated / host | | Mô hình giá | On-Demand / Savings Plans / RI / Spot | | Kết hợp | Dedicated Instance vẫn mua Reserved được |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Instance đang chạy tenancy nào | describe-instances, xem Placement.Tenancy | | VPC đặt tenancy gì | describe-vpcs, xem InstanceTenancy | | Chi phí chênh bao nhiêu | Cost Explorer, lọc theo tenancy |

Và một lời khuyên trước khi quyết định: hãy hỏi rõ bộ phận tuân thủ xem yêu cầu thật sự là "phần cứng không chia sẻ" hay "kiểm soát được vị trí vật lý". Hai câu trả lời dẫn tới hai dịch vụ khác nhau và chênh nhau rất nhiều tiền — và trong phần lớn trường hợp, hướng dẫn bảo mật chỉ đòi vế thứ nhất, tức là Dedicated Instance đã đủ.

Đáp án

B — Bật chỉ số CloudWatch có bao gồm chỉ số lỗi 5xx của S3. Thử lại request thường là cách khắc phục.

Vì sao đúng

Chi tiết quyết định nằm ở mã lỗi và tính chất của nó: 500 Internal Error, xuất hiện KHÔNG THƯỜNG XUYÊN.

⚠ Điểm mấu chốt — 5xx là lỗi phía MÁY CHỦ, không phải lỗi của bạn:

4xx → lỗi phía CLIENT
    403 AccessDenied, 404 NoSuchKey, 400 BadRequest
        ↓
    → do quyền, do đường dẫn sai, do request sai

5xx → lỗi phía MÁY CHỦ (S3)
    500 Internal Error, 503 SlowDown, 503 Service Unavailable
        ↓
    → S3 là hệ thống phân tán khổng lồ
    → một tỷ lệ lỗi tạm thời rất nhỏ là ĐIỀU BÌNH THƯỜNG
    → AWS thiết kế sẵn với giả định client sẽ THỬ LẠI

⚠ Cách xử lý đúng — thử lại với exponential backoff:

Lần 1 thất bại → chờ 100 ms → thử lại
Lần 2 thất bại → chờ 200 ms → thử lại
Lần 3 thất bại → chờ 400 ms → thử lại
        ↓
    Cộng thêm "jitter" (độ lệch ngẫu nhiên)
        ↓
    → tránh mọi client cùng thử lại một lúc
        ↓
    Tin tốt: MỌI AWS SDK đã làm sẵn việc này
        ↓
    → nếu ứng dụng dùng SDK thay vì gọi HTTP thô,
      phần lớn lỗi 500 sẽ tự biến mất

⚠ Theo dõi bằng chỉ số CloudWatch:

Bật S3 Request Metrics (có phí, theo bucket hoặc theo prefix)
        ↓
    5xxErrors      → số lỗi phía máy chủ
    4xxErrors      → số lỗi phía client
    AllRequests    → tổng số request
        ↓
    Đặt cảnh báo theo TỶ LỆ, không theo số tuyệt đối:
        5xxErrors / AllRequests > 0,1%

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

• C (người dùng thiếu quyền, kiểm tra IAM role) — đây là phương án gần nhất vì lỗi quyền là nguyên nhân rất phổ biến khi truy cập S3. Nhưng thiếu quyền cho 403 AccessDenied, không phải 500. Và lỗi quyền xảy ra nhất quán, không "thỉnh thoảng" như đề mô tả.

• D (đối tượng mã hoá bằng KMS nên cần thêm quyền dùng khoá) — cũng cho 403, không phải 500. (Đây là một chẩn đoán rất hữu ích cho tình huống khác — xem thêm cách phân biệt lỗi từ s3 và từ kms trong CloudTrail.)

• A (kiểm tra xem bucket có đủ đối tượng người dùng cần không) — tệp không tồn tại cho 404 NoSuchKey, không phải 500.

Ghi nhớ

⚠ Mã lỗi của S3 và ý nghĩa — bảng phải thuộc: | Mã | Nghĩa | Cách xử lý | |---|---|---| | 400 BadRequest | request sai định dạng | sửa mã | | 403 AccessDenied | thiếu quyền (IAM, bucket policy, hoặc KMS) | sửa chính sách | | 404 NoSuchKey | không có đối tượng đó | kiểm tra đường dẫn | | 500 InternalError | lỗi phía S3 | THỬ LẠI với backoff | | 503 SlowDown | đang bị throttle | thử lại + giãn prefix | | 503 ServiceUnavailable | S3 tạm quá tải | thử lại |

Từ khoá nhận diện:

"500 Internal Error, không thường xuyên" → thử lại với exponential backoff "503 SlowDown" → vượt tần suất request, phân tán prefix "403 AccessDenied" → quyền IAM, bucket policy, hoặc KMS "tự viết logic thử lại" → thường thừa, SDK đã có sẵn "theo dõi tỷ lệ lỗi" → S3 Request Metrics

⚠ Hạn mức tần suất request của S3 — nguồn gốc của 503 SlowDown: | Thao tác | Giới hạn mỗi prefix | |---|---| | GET / HEAD | 5.500 request/giây | | PUT / COPY / POST / DELETE | 3.500 request/giây | | Cách tăng | dùng nhiều prefix — S3 tự co giãn theo prefix | | Lưu ý | không còn cần "băm ngẫu nhiên tên tệp" như hướng dẫn cũ |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tỷ lệ lỗi là bao nhiêu | bật Request Metrics, so 5xxErrors với AllRequests | | Lỗi tập trung ở đâu | bật metrics theo prefix để khoanh vùng | | SDK có thử lại không | bật log debug của SDK, xem số lần thử |

Và một điều đáng nói với đội phát triển trong đề: một tỷ lệ lỗi 500 rất nhỏ là hành vi đã được AWS ghi trong tài liệu, không phải sự cố. Điều cần sửa không nằm ở S3 mà nằm ở ứng dụng — nếu nó gọi API thô hoặc đã tắt cơ chế retry của SDK, thì mỗi lỗi tạm thời sẽ trở thành một lỗi mà người dùng nhìn thấy, trong khi lẽ ra nó phải biến mất trong im lặng sau một lần thử lại chỉ mất vài trăm mili giây.