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

Đáp án

D — Dựng event bus của EventBridge ở các tài khoản chi nhánh, tạo rule khớp sự kiện và chuyển tiếp chúng từ tài khoản chính.

Vì sao đúng

Ràng buộc quyết định nằm ở đề: không được thay đổi cấu hình của CMS. Nên mọi thay đổi phải nằm ở phía AWS, sau điểm mà CMS đã gửi sự kiện tới.

EventBridge hỗ trợ chuyển tiếp sự kiện chéo tài khoản ngay từ thiết kế — đây là tính năng dựng sẵn, không phải giải pháp tự chế:

CMS → API Gateway → EventBridge (tài khoản CHÍNH)
                          │
                          ├→ rule nội bộ → syndication ở tài khoản chính
                          └→ rule chuyển tiếp ─┬→ event bus tài khoản A
                                               ├→ event bus tài khoản B
                                               └→ event bus tài khoản C

Ở tài khoản chi nhánh — cho phép tài khoản chính gửi sự kiện tới:

aws events put-permission --event-bus-name default \
  --action events:PutEvents \
  --principal <ID-tai-khoan-chinh> \
  --statement-id ChoPhepTaiKhoanChinh

Ở tài khoản chính — tạo rule chuyển tiếp:

aws events put-rule --name chuyen-tiep-cap-nhat \
  --event-pattern '{"source":["cms.noi-bo"],"detail-type":["Cap nhat noi dung"]}'

aws events put-targets --rule chuyen-tiep-cap-nhat \
  --targets '[{"Id":"chi-nhanh-a",
               "Arn":"arn:aws:events:ap-southeast-1:<ID-A>:event-bus/default",
               "RoleArn":"arn:aws:iam::<ID-chinh>:role/EventBridgeCrossAccount"}]'

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | CMS không đổi gì | nó vẫn gửi tới đúng một endpoint như cũ | | Thêm chi nhánh dễ | chỉ thêm một target — không sửa mã | | Mỗi chi nhánh tự lọc | rule riêng ở tài khoản họ, chọn loại sự kiện họ quan tâm |

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

• B. Dựng nhiều API Gateway endpoint ở các tài khoản chi nhánh để nhận trực tiếp từ CMS — vi phạm thẳng ràng buộc: CMS phải được cấu hình lại để gọi nhiều endpoint. Và mỗi lần thêm chi nhánh lại phải sửa CMS.
• C. Dựng nhiều bản CMS, mỗi bản nối với một tài khoản — cực kỳ tốn kém và khó bảo trì: nhiều hệ thống phải đồng bộ nội dung với nhau, và vẫn phải cấu hình lại.
• A. Dùng Lambda ở tài khoản chính để nhân bản rồi gọi thủ công ở tài khoản chi nhánh — tự dựng lại chức năng EventBridge đã có: bạn phải viết mã, quản lý danh sách tài khoản đích, tự lo thử lại và xử lý lỗi. Và cụm "manually invoke" đã trái tinh thần tự động hoá.

Ghi nhớ

Các mẫu định tuyến sự kiện chéo tài khoản của EventBridge: | Mẫu | Cách | |---|---| | Chuyển tiếp bus-to-bus | rule ở tài khoản nguồn, target là event bus tài khoản đích ← câu này | | Bus tập trung | mọi tài khoản gửi vào một bus chung | | Organization-wide | dùng aws:PrincipalOrgID cho toàn bộ tổ chức |

Mẫu thứ ba tiện nhất khi có nhiều tài khoản: thay vì liệt kê từng ID, cho phép cả tổ chức bằng một điều kiện:

{"Effect": "Allow", "Principal": "*", "Action": "events:PutEvents",
 "Resource": "arn:aws:events:...:event-bus/default",
 "Condition": {"StringEquals": {"aws:PrincipalOrgID": "o-abc123"}}}

Ba loại event bus: | Loại | Nguồn sự kiện | |---|---| | Default | dịch vụ AWS (EC2, S3, CodePipeline…) | | Custom | ứng dụng của bạn | | Partner | SaaS bên thứ ba (Datadog, Zendesk, Auth0…) |

Vài tính năng khác của EventBridge đáng biết: | Tính năng | Việc | |---|---| | Event pattern | lọc theo cấu trúc JSON, rất linh hoạt | | Input transformer | biến đổi sự kiện trước khi gửi tới target | | Archive và Replay | lưu sự kiện và PHÁT LẠI — rất hữu ích khi chi nhánh mới tham gia | | Schema registry | tự phát hiện và sinh mã từ cấu trúc sự kiện | | DLQ cho target | không mất sự kiện khi target hỏng |

Tính năng Archive và Replay đặc biệt hợp với tình huống này: khi một chi nhánh mới được thêm vào, bạn phát lại các sự kiện trong quá khứ cho họ mà không cần CMS gửi lại gì.

Đáp án

D và E.

• D — Dùng Parallel Scan API
• E — Dùng tham số Limit

Vì sao đúng

Đề đưa ra hai ràng buộc kéo ngược nhau: giảm thời gian quét nhưng không ảnh hưởng tải production (đang dùng khoảng 50% throughput). Hai đáp án tương ứng với hai vế đó.

D — Parallel scan để nhanh. Scan tuần tự chỉ dùng một luồng đọc lần lượt từng partition, nên không tận dụng được 50% năng lực còn rảnh. Parallel scan chia bảng thành các segment và quét đồng thời:

import threading

TONG_SEGMENT = 8

def quet(segment):
    kwargs = {'TableName': 'bang-lon', 'Segment': segment,
              'TotalSegments': TONG_SEGMENT,
              'Limit': 100,                       # ← vế thứ hai
              'ReturnConsumedCapacity': 'TOTAL'}
    while True:
        r = dynamodb.scan(**kwargs)
        xu_ly(r['Items'])
        if 'LastEvaluatedKey' not in r: break
        kwargs['ExclusiveStartKey'] = r['LastEvaluatedKey']
        time.sleep(0.05)

for i in range(TONG_SEGMENT):
    threading.Thread(target=quet, args=(i,)).start()

E — Limit để điều tiết. Tham số này giới hạn số item trả về mỗi lời gọi, nên nó chia nhỏ mức tiêu thụ RCU thành nhiều cú nhỏ thay vì một cú lớn:

Không có Limit: mỗi trang tới 1 MB → 256 RCU trong một khoảnh khắc → dễ vượt trần
Có Limit=100:   mỗi trang nhỏ hơn  → tiêu thụ rải đều → không đụng production

Hai đáp án bổ sung cho nhau: Parallel scan tăng tốc, Limit giữ cho tốc độ đó không tràn sang phần của production.

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

• C. Tăng RCU trong lúc scan — chạy được nhưng tốn tiền, và không cần thiết: đề nói rõ 50% throughput đang rảnh. Vấn đề là dùng phần rảnh đó cho hiệu quả, không phải mua thêm.
• A. Dùng "Sequential Scan API" — không có API nào tên như vậy, và scan tuần tự chính là hành vi mặc định — tức là thứ đang chậm. Nó không giảm được thời gian.
• B. Dùng phân trang để chia kết quả thành các trang 1 MB — 1 MB đã là giới hạn mặc định của mỗi trang scan. Nói cách khác, phương án này mô tả hành vi sẵn có, không phải một tối ưu. Và trang 1 MB là trang LỚN NHẤT có thể — nó gây ra đúng cú tiêu thụ lớn mà Limit sinh ra để tránh.

Ghi nhớ

Các tham số của scan: | Tham số | Việc | |---|---| | TotalSegments | chia bảng thành N phần để quét song song | | Segment | phần nào (0 … N−1) | | Limit | số item tối đa mỗi lời gọi — công cụ điều tiết chính | | ProjectionExpression | chỉ lấy cột cần — giảm dữ liệu đọc thật sự | | ReturnConsumedCapacity | để tự giám sát và điều tiết |

Chọn TotalSegments bao nhiêu: quy tắc thô là mỗi segment khoảng 1–2 GB, và không nên vượt quá số luồng máy khách chạy được.

Điểm cần khắc sâu về FilterExpression — nó KHÔNG giảm RCU:

Scan đọc 50 GB → tính tiền cho 50 GB → FilterExpression bỏ bớt → trả về 100 MB
                        ↑ bạn trả tiền ở đây, không phải ở kết quả

Muốn thật sự giảm dữ liệu đọc thì phải dùng Query với khoá phù hợp, hoặc GSI — chứ không phải bộ lọc.

Hai mục tiêu, hai công cụ trái ngược nhau — bảng này giúp chọn nhanh khi làm bài: | Đề hỏi | Chọn | |---|---| | "shortest time", "scan as fast as possible" | parallel scan | | "minimize impact", "without affecting production" | Limit, rate limiting | | cả hai | parallel scan + Limit ← câu này |

Và giải pháp tốt nhất cho việc quét toàn bảng định kỳ: DynamoDB Export to S3 rồi phân tích bằng Athena. Nó không tiêu thụ RCU nào cả, nên hoàn toàn không thể ảnh hưởng tới production — với báo cáo chạy mỗi ngày như đề mô tả, đây thường là kiến trúc đúng hơn cả.

Đáp án

A — Xoá access key đã bị lộ.

Vì sao đúng

Nguyên tắc ứng phó sự cố: chặn đứng thiệt hại trước, điều tra sau.

Khi access key có thể đã bị lộ, mỗi giây trôi qua là kẻ tấn công còn dùng được nó. Xoá (hoặc vô hiệu hoá) key là hành động ngăn chặn tức thì:

# Vô hiệu hoá ngay (giữ lại để điều tra)
aws iam update-access-key --user-name nguyen-thi-b \
  --access-key-id AKIAIOSFODNN7EXAMPLE --status Inactive

# Hoặc xoá hẳn
aws iam delete-access-key --user-name nguyen-thi-b \
  --access-key-id AKIAIOSFODNN7EXAMPLE

(Trong thực tế, Inactive thường tốt hơn xoá hẳn ở bước đầu: nó chặn ngay mọi lời gọi nhưng vẫn giữ key trong hồ sơ để đối chiếu với log CloudTrail khi điều tra.)

Vì sao ba phương án còn lại không phải hành động đầu tiên: | Hành động | Vì sao không ưu tiên | |---|---| | Đổi mật khẩu | mật khẩu và access key là hai thứ khác nhau — kẻ tấn công vẫn dùng key được | | Báo AWS Support | quan trọng, nhưng mất thời gian chờ trong khi key vẫn hoạt động | | Xoá IAM user | quá tay — mất luôn cấu hình, và có thể làm hỏng ứng dụng đang dùng danh tính đó |

Sau khi đã chặn, quy trình đầy đủ gồm sáu bước:

1. Vô hiệu hoá / xoá access key             ← ĐẦU TIÊN
2. Tạo key mới cho các ứng dụng hợp lệ
3. Rà soát CloudTrail xem key đã làm gì
4. Kiểm tra tài nguyên lạ: EC2 mới, IAM user mới, key mới
5. Đổi mật khẩu và bật MFA
6. Báo AWS Support nếu có dấu hiệu lạm dụng

Bước 4 rất quan trọng: một trong những việc kẻ tấn công làm đầu tiên là tạo thêm IAM user và access key khác để giữ quyền truy cập ngay cả sau khi bạn xoá key gốc.

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

• B. Đổi mật khẩu tài khoản IAM — nên làm, nhưng không giải quyết vấn đề được nêu: access key hoàn toàn độc lập với mật khẩu. Mật khẩu dùng để đăng nhập Console; access key dùng cho CLI và SDK. Đổi cái này không ảnh hưởng cái kia.
• C. Báo sự cố cho AWS Support — cần thiết ở bước sau, nhưng không phải hành động đầu tiên: trong lúc chờ phản hồi, key vẫn hoạt động và thiệt hại vẫn tiếp diễn.
• D. Xoá tài khoản IAM user — quá tay và có tác dụng phụ: nó xoá luôn mọi policy, group membership, và có thể làm hỏng ứng dụng đang dùng danh tính đó một cách hợp lệ. Vô hiệu hoá key là biện pháp đúng mức.

Ghi nhớ

Ba nguyên tắc ứng phó sự cố bảo mật, theo thứ tự: | Bước | Việc | |---|---| | 1. Ngăn chặn (contain) | cắt đứt đường truy cập ngay | | 2. Điều tra (investigate) | CloudTrail, GuardDuty, Config | | 3. Khắc phục (remediate) | xoá tài nguyên lạ, khôi phục, vá lỗ hổng |

Các công cụ điều tra sau khi đã chặn: | Công cụ | Cho biết | |---|---| | CloudTrail | key đã gọi API nào, khi nào, từ IP nào | | GuardDuty | phát hiện hành vi bất thường (UnauthorizedAccess:IAMUser/*) | | AWS Config | thay đổi cấu hình tài nguyên | | IAM Credential Report | danh sách mọi credential và lần dùng cuối |

Và cách tốt nhất là ngăn sự cố này xảy ra ngay từ đầu: | Biện pháp | Chi tiết | |---|---| | Không dùng access key dài hạn | dùng IAM role cho EC2, Lambda, ECS | | IAM Identity Center (SSO) cho nhân sự | credential tạm thời, không có key | | Bật MFA | | | Xoay vòng key định kỳ | nếu buộc phải dùng | | Quét mã nguồn | git-secrets, GitHub secret scanning |

AWS còn có một cơ chế bảo vệ tự động đáng biết: khi phát hiện access key bị đăng công khai trên GitHub, AWS tự áp policy AWSCompromisedKeyQuarantine vào IAM user đó và gửi email cảnh báo. Nhưng đừng trông vào nó — nó chỉ bắt được trường hợp lộ công khai.

Nguyên tắc rút ra: access key dài hạn là loại credential rủi ro nhất trong AWS. Mọi kiến trúc hiện đại đều nên loại bỏ chúng.

Đáp án

A — Dùng AWS Secrets Manager lưu credential CSDL và bật xoay vòng tự động hằng tuần.

Vì sao đúng

Đề nêu hai yêu cầu: quản lý credential cho Lambda, và xoay vòng mỗi tuần theo chính sách bảo mật.

Secrets Manager có sẵn cả hai, và với RDS thì không phải viết mã xoay vòng nào:

aws secretsmanager rotate-secret \
  --secret-id prod/postgres/ung-dung \
  --rotation-lambda-arn arn:aws:lambda:...:function:SecretsManagerRDSPostgreSQLRotation \
  --rotation-rules '{"ScheduleExpression": "rate(7 days)"}'

AWS cung cấp sẵn Lambda xoay vòng cho từng engine RDS (PostgreSQL, MySQL, Oracle, SQL Server, MariaDB). Hàm đó thực hiện bốn bước: | Bước | Việc | |---|---| | createSecret | sinh mật khẩu mới, lưu ở nhãn AWSPENDING | | setSecret | đổi mật khẩu trong chính CSDL | | testSecret | thử kết nối bằng mật khẩu mới | | finishSecret | chuyển nhãn AWSCURRENT sang giá trị mới |

Chiến lược "alternating users" (hai tài khoản luân phiên) khiến việc xoay vòng không gây gián đoạn: ứng dụng dùng tài khoản A trong khi B đang được đổi mật khẩu.

Lambda chỉ cần đọc bí mật:

bi_mat = json.loads(sm.get_secret_value(SecretId='prod/postgres/ung-dung')['SecretString'])
conn = psycopg2.connect(host=bi_mat['host'], user=bi_mat['username'],
                        password=bi_mat['password'], dbname=bi_mat['dbname'])

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

• B. Lưu trong biến môi trường của Lambda và cập nhật thủ công hằng tuần — thủ công, dễ quên, và không an toàn: biến môi trường hiện nguyên văn trong Console cho ai có lambda:GetFunctionConfiguration. Mỗi lần đổi lại phải triển khai lại hàm.
• C. Bật IAM database authentication rồi xoay vòng thủ công — đây là phương án đáng bàn: IAM database authentication là cơ chế RẤT TỐT cho PostgreSQL — nó cấp token sống 15 phút, nên không có mật khẩu nào để xoay vòng. Nhưng phương án lại nói "manage weekly rotation manually", tự mâu thuẫn với chính lợi ích của nó. (Nếu phương án viết là "bật IAM database authentication, không cần xoay vòng" thì đó sẽ là câu trả lời rất mạnh.)
• D. Lưu credential trong S3 có versioning, tự tải lên hằng tuần — tự dựng lại một dịch vụ đã có, kém hơn ở mọi mặt: không có quy trình bốn bước an toàn, không có nhãn AWSPENDING/AWSCURRENT, và vẫn là thao tác thủ công.

Ghi nhớ

Cách chọn: cần xoay vòng ⇒ Secrets Manager. Cấu hình không nhạy cảm ⇒ Parameter Store.

Hỗ trợ IAM database authentication của RDS — đáng nhớ vì nó là cách loại bỏ hẳn mật khẩu: | Engine | Hỗ trợ | |---|---| | MySQL, PostgreSQL, MariaDB | ✅ | | Aurora MySQL, Aurora PostgreSQL | ✅ | | SQL Server, Oracle | ❌ |

Ba lưu ý khi dùng Secrets Manager với Lambda:

1. Cache bí mật trong biến toàn cục — đừng gọi get_secret_value ở mỗi lần chạy. AWS có sẵn Parameters and Secrets Lambda Extension làm việc này bằng cấu hình.
2. Nếu Lambda nằm trong VPC, cần VPC endpoint cho Secrets Manager (hoặc NAT).
3. Cân nhắc ManageMasterUserPassword: true khi tạo RDS — RDS tự tạo secret và tự lo xoay vòng, gọn hơn cả việc tự khai.

Đáp án

C — Tạo high-resolution custom metric cho dữ liệu hoạt động người dùng, và đăng dữ liệu mỗi 5 giây.

Vì sao đúng

Đề yêu cầu co giãn dựa trên tải trong 15 giây gần nhất — và điều đó loại ngay standard resolution.

Standard resolution có chu kỳ 60 giây, nên nó không thể biểu diễn được cửa sổ 15 giây: dữ liệu chỉ có một điểm mỗi phút, và mọi biến động trong phút đó bị san phẳng.

High resolution cho phép chu kỳ tới 1 giây: | | Standard resolution | High resolution | |---|---|---| | Chu kỳ metric | 60 giây | 1 giây | | Chu kỳ alarm cho phép | 60, 300, 900… giây | 10, 30, và bội số của 60 | | Chi phí | thường | cao hơn |

Đăng metric với StorageResolution=1:

aws cloudwatch put-metric-data \
  --namespace "UngDung/ECS" \
  --metric-data MetricName=NguoiDungHoatDong,Value=1250,StorageResolution=1

Và đăng mỗi 5 giây cho đủ độ chi tiết trong cửa sổ 15 giây — ba điểm dữ liệu, đủ để alarm đánh giá:

aws cloudwatch put-metric-alarm \
  --alarm-name tai-nguoi-dung-cao \
  --namespace UngDung/ECS --metric-name NguoiDungHoatDong \
  --period 10 --evaluation-periods 1 \
  --threshold 1000 --comparison-operator GreaterThanThreshold

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

• D. High-resolution metric nhưng đăng mỗi 30 giây — đúng loại metric nhưng tần suất quá thưa: trong cửa sổ 15 giây có thể không có điểm dữ liệu nào. Dùng high-resolution mà đăng thưa là trả tiền cao hơn mà không được lợi ích gì.
• B. Standard-resolution nhưng đăng mỗi 5 giây — đăng dày không nâng được độ phân giải: CloudWatch gộp các điểm trong cùng một phút thành một điểm duy nhất với standard resolution. Bạn mất hết chi tiết trong phút đó.
• A. Standard-resolution, đăng mỗi 30 giây — sai cả hai vế.

Ghi nhớ

Điểm quan trọng nhất: StorageResolution quyết định độ chi tiết được LƯU, tần suất đăng chỉ quyết định có bao nhiêu dữ liệu để lưu. Cần cả hai đúng.

Thời gian lưu dữ liệu của CloudWatch — dữ liệu cũ tự động được gộp lại: | Tuổi dữ liệu | Độ chi tiết còn giữ | |---|---| | 3 giờ đầu | 1 giây (nếu là high-res) | | 15 ngày | 60 giây | | 63 ngày | 5 phút | | 15 tháng | 1 giờ |

Dòng đầu tiên đáng nhớ: dữ liệu một giây chỉ tồn tại 3 giờ. High-resolution dùng để phát hiện và phản ứng nhanh, không dùng để phân tích lịch sử.

Ba mức chu kỳ trong hệ sinh thái CloudWatch — đừng lẫn: | Khái niệm | Chu kỳ | Áp cho | |---|---|---| | Basic monitoring | 5 phút | EC2, mặc định | | Detailed monitoring | 1 phút | EC2, có phí | | Standard custom metric | 60 giây | metric của bạn | | High-resolution custom metric | 1 giây | metric của bạn, phí cao hơn |

Mẹo giảm chi phí và số lời gọi khi đăng metric tần suất cao: dùng statistic set thay vì gửi từng điểm:

--metric-data MetricName=NguoiDung,StatisticValues={Sum=5000,Minimum=100,Maximum=300,SampleCount=20},StorageResolution=1

Và với ECS, nhớ rằng Application Auto Scaling dùng chính metric này để co giãn service — nên đặt target tracking policy trên custom metric đó là cách đơn giản nhất:

aws application-autoscaling put-scaling-policy \
  --policy-type TargetTrackingScaling --service-namespace ecs ...

Đáp án

A — Linear.

Vì sao đúng

Đề mô tả chính xác hành vi của linear: chuyển 10% traffic mỗi lần, các bước cách nhau 10 phút, và các mức tăng bằng nhau (equal increments).

CodeDeployDefault.LambdaLinear10PercentEvery10Minutes
   0 phút → 10%
  10 phút → 20%
  20 phút → 30%
  ...
  90 phút → 100%

Cụm từ "in equal increments" trong đề là chữ ký nhận dạng của linear — nó tăng đều đặn từng nấc bằng nhau.

Khai trong SAM:

Resources:
  HamXuLy:
    Type: AWS::Serverless::Function
    Properties:
      AutoPublishAlias: live
      DeploymentPreference:
        Type: Linear10PercentEvery10Minutes
        Alarms:
          - !Ref CanhBaoLoi        # tự rollback nếu alarm kêu
        Hooks:
          PreTraffic: !Ref HamKiemThuTruoc

Phần Alarms rất đáng dùng với triển khai kéo dài 90 phút: nếu ở bất kỳ nấc nào CloudWatch alarm chuyển sang ALARM, CodeDeploy tự rollback — bạn không phải ngồi canh suốt.

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

• C. Canary — chỉ có HAI bước: một tỷ lệ nhỏ, chờ, rồi 100%. Nó không tăng đều từng nấc như đề mô tả.

  Canary10Percent10Minutes: 10% → chờ 10 phút → 100%
  

• B. All-at-once — chuyển 100% ngay lập tức, không có bước trung gian nào.
• D. Blue/green — không phải một cách chuyển traffic, mà là DEPLOYMENT TYPE. Với Lambda thì blue/green là loại duy nhất được hỗ trợ, nên nó không phải thứ cần chọn ở đây. Câu hỏi hỏi về deployment configuration.

Phương án D là bẫy tốt vì nó trộn hai tầng khái niệm.

Ghi nhớ

Hai tầng khái niệm của CodeDeploy — đừng lẫn:

Deployment TYPE:   In-place | Blue/green      ← Lambda và ECS chỉ có blue/green
Deployment CONFIG: AllAtOnce | Canary | Linear ← đây mới là thứ cần chọn

Phân biệt ba cấu hình: | Kiểu | Số bước | Hành vi | |---|---|---| | AllAtOnce | 1 | 100% ngay | | Canary | 2 | X% → chờ → 100% | | Linear | nhiều | +X% mỗi N phút, đều nhau |

Các cấu hình dựng sẵn cho Lambda:

CodeDeployDefault.LambdaAllAtOnce
CodeDeployDefault.LambdaCanary10Percent5Minutes
CodeDeployDefault.LambdaCanary10Percent10Minutes
CodeDeployDefault.LambdaCanary10Percent15Minutes
CodeDeployDefault.LambdaCanary10Percent30Minutes
CodeDeployDefault.LambdaLinear10PercentEvery1Minute
CodeDeployDefault.LambdaLinear10PercentEvery2Minutes
CodeDeployDefault.LambdaLinear10PercentEvery3Minutes
CodeDeployDefault.LambdaLinear10PercentEvery10Minutes    ← câu này

Quy tắc đặt tên đọc thẳng ra hành vi:

CodeDeployDefault.<NềnTảng><Kiểu><TỷLệ><ThờiGian>

Cách chọn theo từ khoá trong đề: | Đề nói | Chọn | |---|---| | "equal increments", "gradually over time" | Linear | | "X% then the rest after N minutes" | Canary | | "immediately", "fastest" | AllAtOnce |

Và nhớ: với Lambda, AutoPublishAlias là bắt buộc trong SAM — thiếu nó thì không có alias để chuyển traffic, và DeploymentPreference không hoạt động.

Đáp án

A — Bật thuộc tính TTL và thêm mốc thời gian hết hạn vào các item.

Vì sao đúng

Đề mô tả đúng kịch bản mà TTL sinh ra để giải: dữ liệu chỉ cần trong thời gian ngắn sau khi ghi, sau đó không dùng nữa.

DynamoDB TTL tự động xoá item khi tới mốc hết hạn, và điều quan trọng nhất — hoàn toàn miễn phí:

aws dynamodb update-time-to-live \
  --table-name du-lieu-cam-bien \
  --time-to-live-specification "Enabled=true, AttributeName=het_han"

Khi ghi dữ liệu, kèm mốc hết hạn:

table.put_item(Item={
    'cam_bien_id': 'CB-001',
    'thoi_diem': thoi_diem,
    'gia_tri': 23.5,
    'het_han': int(time.time()) + 3600      # tự xoá sau 1 giờ
})

Ba lý do nó là cách DỄ NHẤT: | Lý do | Chi tiết | |---|---| | Việc xoá KHÔNG tốn WCU nào | hoàn toàn miễn phí | | Không cần hạ tầng | không script, không máy chủ, không lịch chạy | | Không ảnh hưởng hiệu năng | chạy nền, không tranh throughput với ứng dụng |

Định dạng bắt buộc: giá trị phải là Unix epoch tính bằng GIÂY, kiểu Number. Dùng mili giây hoặc chuỗi ISO 8601 thì TTL im lặng bỏ qua item đó — lỗi rất khó phát hiện vì không có thông báo nào.

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

• C. Quét bảng tìm dữ liệu cũ và xoá mỗi giờ — chạy được nhưng đắt nhất: Scan đọc toàn bộ bảng ở mỗi lần chạy (tốn RCU tỷ lệ với kích thước bảng), rồi mỗi lần xoá tốn WCU. Với bảng nhận dữ liệu cảm biến liên tục, chi phí này rất đáng kể — trong khi TTL làm cùng việc đó miễn phí.
• D. Xoá bảng và tạo lại mỗi giờ — gây gián đoạn: trong lúc tạo lại, ứng dụng không ghi được. Tạo bảng cũng mất thời gian, và bạn phải dựng lại mọi cấu hình (index, capacity, stream).
• B. Dùng atomic counter để giảm dữ liệu khi nó cũ — hiểu sai chức năng: atomic counter dùng để tăng/giảm một GIÁ TRỊ SỐ trong item một cách nguyên tử (đếm lượt xem chẳng hạn). Nó không xoá item nào.

Ghi nhớ

Yêu cầu để TTL hoạt động: | Yêu cầu | Chi tiết | |---|---| | Kiểu dữ liệu | Number | | Định dạng | Unix epoch tính bằng GIÂY | | Bật ở mức bảng | chỉ định tên thuộc tính | | Item thiếu thuộc tính đó | không bao giờ bị xoá | | Giá trị quá 5 năm trong quá khứ | bị bỏ qua |

Ba điều đáng biết thêm:

1. TTL không đảm bảo thời điểm chính xác — thường trong vài giờ, AWS chỉ cam kết "trong vài ngày". Nếu ứng dụng không được phép thấy dữ liệu đã hết hạn, hãy lọc thêm ở tầng đọc.
2. Item bị TTL xoá vẫn xuất hiện trong DynamoDB Streams, với userIdentity.principalId = "dynamodb.amazonaws.com" — nên bạn lưu trữ dữ liệu hết hạn sang S3 trước khi mất hẳn. Với dữ liệu cảm biến, đây là mẫu rất hữu ích: TTL dọn bảng nóng, Streams đẩy bản sao sang S3 cho phân tích dài hạn.
3. Item đã hết hạn nhưng chưa bị xoá vẫn xuất hiện trong Query và Scan.

Các dịch vụ khác cũng có cơ chế hết hạn tương tự: | Dịch vụ | Cơ chế | |---|---| | DynamoDB | thuộc tính TTL | | ElastiCache Redis | EXPIRE / SETEX | | S3 | lifecycle rule | | CloudWatch Logs | retention policy | | SQS | MessageRetentionPeriod |

Đáp án

D — Publish thông báo lên một Amazon SNS Topic.

Vì sao đúng

Đề nêu yêu cầu rõ: push notification cho những người đăng ký (subscribers). Đó chính xác là mô hình pub/sub, và SNS là dịch vụ pub/sub của AWS.

SNS hỗ trợ push tới thiết bị di động qua giao thức application:

                        ┌→ APNs  (iOS)
Ứng dụng → SNS topic ───┼→ FCM   (Android)
                        └→ SMS, email, Lambda…

Quy trình gồm ba bước:

# 1. Tạo platform application cho nền tảng di động
aws sns create-platform-application \
  --name ung-dung-ios --platform APNS \
  --attributes PlatformCredential=<chung-chi>

# 2. Đăng ký thiết bị (làm khi người dùng cài ứng dụng)
aws sns create-platform-endpoint \
  --platform-application-arn <arn> --token <device-token>

# 3. Gửi thông báo
aws sns publish --topic-arn arn:aws:sns:...:thong-bao \
  --message '{"default":"Có tin mới","APNS":"{\"aps\":{\"alert\":\"Có tin mới\"}}"}' \
  --message-structure json

Điểm hay của mô hình pub/sub: ứng dụng publish một lần, SNS fan-out tới mọi người đăng ký — không cần vòng lặp gửi từng người, và thêm người đăng ký mới không phải sửa mã.

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

• A. Publish message lên SQS queue — SQS là hàng đợi giữa các thành phần phần mềm, không gửi gì tới người dùng cuối. Consumer phải chủ động lấy message ra — không phải mô hình push.
• B. Publish lên một SWF workflow — Simple Workflow Service dùng để điều phối các bước trong quy trình nghiệp vụ. Không phải dịch vụ thông báo. (Và AWS khuyến nghị dùng Step Functions cho workflow mới.)
• C. Publish notification lên CloudWatch Events — EventBridge định tuyến sự kiện GIỮA CÁC DỊCH VỤ AWS. Nó không gửi push notification tới thiết bị di động.

Ghi nhớ

Các giao thức đăng ký của SNS: | Protocol | Đích | |---|---| | application | push tới thiết bị di động (APNs, FCM, ADM, Baidu) | | lambda | hàm Lambda | | sqs | hàng đợi | | sms | tin nhắn văn bản | | email / email-json | email | | http / https | webhook | | firehose | Kinesis Data Firehose |

So sánh ba dịch vụ nhắn tin: | | SNS (push) | SQS (pull) | EventBridge | |---|---|---|---| | Mô hình | pub/sub, một tới nhiều | hàng đợi, một tới một | định tuyến sự kiện | | Người nhận | có thể là người dùng cuối | chỉ thành phần phần mềm | dịch vụ AWS và SaaS | | Lưu trữ | ❌ | tới 14 ngày | ❌ |

Nhận dạng nhanh: đề nói "push notification", "subscribers", "gửi tới người dùng" ⇒ SNS.

Ba lưu ý khi làm push notification với SNS:

1. Message structure JSON cho phép gửi nội dung khác nhau cho từng nền tảng trong một lời gọi — iOS và Android có định dạng payload riêng.
2. Xử lý endpoint bị vô hiệu hoá: khi người dùng gỡ ứng dụng, device token hết hiệu lực và SNS đánh dấu endpoint Enabled=false. Nên dọn định kỳ để không gửi vô ích.
3. Amazon Pinpoint là lựa chọn mạnh hơn nếu cần chiến dịch marketing, phân khúc người dùng, và phân tích tỷ lệ mở — SNS chỉ lo phần gửi.

Đáp án

B — Cài Kinesis Producer Library (KPL) để nạp dữ liệu vào stream.

Vì sao đúng

Đọc kỹ đề: vấn đề không phải thiếu shard, mà là "producer không tận dụng tốt các shard đang có". Đó là vấn đề ở phía producer, không phải ở năng lực stream.

Nguyên nhân thường gặp: mỗi shard có hai giới hạn độc lập: | Giới hạn mỗi shard | Giá trị | |---|---| | Băng thông | 1 MB/giây | | Số bản ghi | 1.000 bản ghi/giây |

Với dữ liệu giám sát gồm nhiều bản ghi rất nhỏ, bạn chạm trần 1.000 bản ghi/giây khi mới dùng hết một phần nhỏ băng thông:

1.000 bản ghi × 200 byte = 200 KB/giây
→ đã chạm giới hạn số bản ghi, trong khi chỉ dùng 20% băng thông

KPL giải quyết bằng aggregation — gom nhiều bản ghi ứng dụng vào một bản ghi Kinesis:

Không có KPL: 1.000 bản ghi nhỏ → 1.000 bản ghi Kinesis → chạm trần
Có KPL:       1.000 bản ghi nhỏ → gom lại → ~10 bản ghi Kinesis → thoải mái

KPL còn làm thêm hai việc: | Tính năng | Việc | |---|---| | Aggregation | gom nhiều bản ghi con vào một bản ghi Kinesis | | Collection | gộp nhiều bản ghi vào một lời gọi PutRecords | | Thử lại tự động | có backoff sẵn | | Ghi metric | CloudWatch metric về hiệu suất producer |

Bên consumer dùng KCL để tự động tách (deaggregate) — hoàn toàn trong suốt với mã xử lý.

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

• A. Tăng số shard bằng UpdateShardCount — giải quyết vấn đề khác: thêm shard tăng năng lực tổng, nhưng đề nói rõ shard hiện có chưa được tận dụng hết. Thêm shard là trả tiền cho năng lực vẫn tiếp tục không dùng tới.
• **C. Nạp nhiều bản ghi trong một lời gọi bằng BatchWriteItem — sai API hoàn toàn: BatchWriteItem là API của DynamoDB. API tương ứng của Kinesis là PutRecords (số nhiều). (Và PutRecords chỉ giảm số lời gọi API, không gộp bản ghi — nên nó không nới được giới hạn 1.000 bản ghi/giây như KPL làm.)
• D. Tạo SQS queue để tách producer khỏi Kinesis — thêm một dịch vụ mà không giải quyết gì: producer vẫn ghi vào Kinesis với cùng cách kém hiệu quả, chỉ là qua một tầng trung gian.

Ghi nhớ

Phân biệt hai vấn đề và hai giải pháp: | Triệu chứng | Nguyên nhân | Giải pháp | |---|---|---| | WriteProvisionedThroughputExceeded cao, băng thông đã đầy | thiếu shard | thêm shard | | Chạm trần số bản ghi nhưng băng thông còn dư | bản ghi quá nhỏ | KPL aggregation | | Một shard nóng hơn hẳn | partition key kém | sửa cách chọn partition key |

Ba cách gửi dữ liệu vào Kinesis: | Cách | Đặc điểm | |---|---| | PutRecord | một bản ghi mỗi lời gọi — đơn giản nhất, kém hiệu quả nhất | | PutRecords | tới 500 bản ghi, 5 MB mỗi lời gọi — giảm số lời gọi API | | KPL | aggregation + collection + retry — hiệu quả nhất |

Đánh đổi của KPL cần biết: | Nhược điểm | Chi tiết | |---|---| | Thêm độ trễ | gom lô nên phải chờ (cấu hình bằng RecordMaxBufferedTime) | | Chỉ có Java (và C++ daemon) | ngôn ngữ khác phải dùng thư viện cộng đồng | | Consumer phải deaggregate | KCL làm sẵn; tự viết consumer thì phải xử lý |

Với ứng dụng nhạy cảm về độ trễ, đặt RecordMaxBufferedTime thấp (ví dụ 100 mili giây) để cân bằng giữa hiệu quả gom lô và độ trễ.

Và metric cần theo dõi: WriteProvisionedThroughputExceeded kèm IncomingRecords và IncomingBytes — so hai con số cuối là biết bạn đang chạm giới hạn nào.

Đáp án

D — Amazon Cognito user pool.

Vì sao đúng

Đề nêu ba yêu cầu, và user pool đáp ứng cả ba:

1. Hàng nghìn người dùng đăng ký
2. Đăng ký bằng địa chỉ email
3. Lưu thuộc tính cho mỗi người dùng

User pool là thư mục người dùng được quản lý — nó lo trọn vòng đời tài khoản:

aws cognito-idp create-user-pool --pool-name nguoi-dung-ung-dung \
  --username-attributes email \
  --auto-verified-attributes email \
  --schema '[
    {"Name":"email","AttributeDataType":"String","Required":true},
    {"Name":"ho_ten","AttributeDataType":"String","Mutable":true},
    {"Name":"goi_dich_vu","AttributeDataType":"String","Mutable":true}
  ]'

Ba thiết lập trên khớp đúng với đề: | Thiết lập | Việc | |---|---| | username-attributes email | đăng ký bằng email | | auto-verified-attributes email | tự gửi mã xác nhận qua email | | schema | khai các thuộc tính lưu cho mỗi người dùng |

Và mọi luồng đều có sẵn, không phải viết mã: | Luồng | API | |---|---| | Đăng ký | SignUp + ConfirmSignUp | | Đăng nhập | InitiateAuth | | Quên mật khẩu | ForgotPassword + ConfirmForgotPassword | | Đổi thuộc tính | UpdateUserAttributes | | MFA | RespondToAuthChallenge |

Với hosted UI, toàn bộ các luồng trên còn có sẵn giao diện — bạn chỉ cần tuỳ chỉnh logo và màu sắc.

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

• B. Amazon Cognito Sync — sai thành phần của Cognito: Sync dùng để đồng bộ dữ liệu người dùng giữa nhiều thiết bị, không phải để đăng ký và xác thực. (Và nó đã bị AWS ngừng phát triển — bản thay thế là AppSync với Amplify DataStore.)
• C. AWS AppSync — dịch vụ GraphQL API được quản lý. Nó dùng Cognito làm cơ chế xác thực, chứ bản thân nó không quản lý người dùng.
• A. AWS Inspector — công cụ quét lỗ hổng bảo mật trên EC2, container image và Lambda. Hoàn toàn không liên quan tới xác thực.

Ghi nhớ

Cách chọn:

• "đăng ký, đăng nhập, quản lý người dùng" ⇒ user pool ← câu này
• "truy cập trực tiếp dịch vụ AWS" ⇒ identity pool
• cả hai nhu cầu ⇒ dùng cả hai

Hai loại thuộc tính trong user pool: | Loại | Ví dụ | Đặc điểm | |---|---|---| | Standard | email, name, phone_number, address | theo chuẩn OpenID Connect | | Custom | custom:goi_dich_vu, custom:ma_khach_hang | tối đa 50, có tiền tố custom: |

Ba lưu ý khi thiết kế:

1. Thuộc tính bắt buộc (Required) không đổi được sau khi tạo user pool — hãy cân nhắc kỹ từ đầu.
2. Thuộc tính custom không đổi kiểu và không xoá được — chỉ thêm mới.
3. Không lưu dữ liệu nghiệp vụ lớn trong thuộc tính Cognito — dùng nó cho hồ sơ cơ bản, còn dữ liệu ứng dụng nên nằm trong DynamoDB, liên kết bằng sub (định danh duy nhất của người dùng).

Và các Lambda trigger cho phép thêm logic riêng vào luồng có sẵn: PreSignUp (tự động duyệt hoặc từ chối), PostConfirmation (tạo bản ghi trong CSDL của bạn), PreTokenGeneration (thêm claim tuỳ chỉnh).