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

Đáp án

D — Thử lại lời gọi với exponential backoff.

Vì sao đúng

ThrottlingException xảy ra khi bạn vượt hạn mức số lời gọi API mỗi giây của CloudWatch. Đề nói rõ lỗi xảy ra không thường xuyên (intermittently) — đó là dấu hiệu của đỉnh ngắn, không phải nhu cầu vượt quá năng lực một cách bền vững.

Với lỗi tạm thời, exponential backoff là thực hành chuẩn của AWS: thử lại sau các khoảng chờ tăng dần, cho hệ thống thời gian giải toả:

import time, random
from botocore.exceptions import ClientError

def lay_metric_co_backoff(**kwargs):
    for lan in range(5):
        try:
            return cloudwatch.get_metric_statistics(**kwargs)
        except ClientError as e:
            if e.response['Error']['Code'] not in ('Throttling', 'ThrottlingException',
                                                   'RequestLimitExceeded'):
                raise
            cho = (2 ** lan) * 0.1 + random.uniform(0, 0.1)
            time.sleep(cho)      # 0,1s → 0,2s → 0,4s → 0,8s → 1,6s
    raise Exception('Vẫn bị throttle sau 5 lần thử')

Jitter (thành phần ngẫu nhiên) không phải chi tiết trang trí: nếu nhiều tiến trình cùng bị throttle và cùng thử lại đúng một thời điểm, chúng tạo ra đỉnh mới — hiện tượng thundering herd. Cộng thêm một khoảng ngẫu nhiên nhỏ sẽ rải các lần thử ra.

Và đề hỏi "first attempt to resolve" — backoff là bước đầu tiên đúng đắn vì nó không tốn gì, làm được ngay, và giải quyết phần lớn trường hợp.

(Một ghi chú thực dụng: AWS SDK đã có sẵn cơ chế retry cho các lỗi này. "Implement exponential backoff" trong thực tế thường nghĩa là tăng số lần thử và đổi chế độ:

from botocore.config import Config
cfg = Config(retries={'max_attempts': 10, 'mode': 'adaptive'})
cloudwatch = boto3.client('cloudwatch', config=cfg)

Chế độ adaptive còn tự điều tiết tốc độ gửi theo tín hiệu throttle nhận được — rất hợp với đúng tình huống này.)

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

• C. Liên hệ AWS Support để xin tăng hạn mức — có thể cần thiết về sau, nhưng không phải bước đầu tiên: nó mất thời gian chờ xử lý, và nếu nguyên nhân chỉ là đỉnh ngắn thì tăng hạn mức là chữa triệu chứng cho một vấn đề mà backoff xử lý miễn phí. Chỉ nên xin tăng khi đã đo được rằng nhu cầu thực sự vượt hạn mức một cách bền vững.
• B. Phân tích ứng dụng và bỏ lời gọi API đó đi — quá cực đoan: lời gọi đó đang phục vụ một mục đích. Nếu vấn đề là gọi quá nhiều thì cách đúng là gom lô hoặc cache, không phải bỏ hẳn chức năng.
• A. Dùng AWS CLI để lấy metric — không giải quyết gì: CLI dùng cùng những API và cùng hạn mức như SDK. Đổi công cụ gọi không đổi được giới hạn phía máy chủ.

Ghi nhớ

Các lỗi nên thử lại và không nên thử lại: | Lỗi | Thử lại? | |---|---| | ThrottlingException, RequestLimitExceeded | ✅ với backoff | | ProvisionedThroughputExceededException | ✅ | | 5xx (lỗi máy chủ) | ✅ | | AccessDenied, ValidationException | ❌ thử lại vô ích | | ResourceNotFound | ❌ |

Ngoài backoff, ba cách giảm số lời gọi CloudWatch: | Cách | Chi tiết | |---|---| | GetMetricData thay cho nhiều GetMetricStatistics | lấy tới 500 metric trong MỘT lời gọi | | Cache kết quả | metric chu kỳ 5 phút không cần hỏi mỗi giây | | Tăng Period | ít điểm dữ liệu hơn cho cùng khoảng thời gian |

Cách đầu tiên thường là cải thiện lớn nhất mà ít người biết: nếu ứng dụng đang gọi GetMetricStatistics trong một vòng lặp qua hàng chục metric, gộp lại thành một GetMetricData sẽ giảm số lời gọi hàng chục lần và làm vấn đề throttle biến mất hẳn.

Nguyên tắc chung khi làm bài: gặp lỗi throttle, đáp án gần như luôn là exponential backoff với jitter — đó là câu trả lời chuẩn của AWS cho mọi dịch vụ, không riêng CloudWatch.

Đáp án

C — Dùng AWS Secrets Manager sinh chuỗi bí mật, và dùng dynamic reference để tạo DB instance với giá trị đó.

Vì sao đúng

Yêu cầu: mật khẩu master của RDS phải được sinh tự động trong quá trình triển khai CloudFormation, với ít công sức phát triển nhất.

CloudFormation có sẵn cơ chế cho đúng việc này — kết hợp AWS::SecretsManager::Secret với dynamic reference, và không cần viết một dòng mã nào:

Resources:
  MatKhauCSDL:
    Type: AWS::SecretsManager::Secret
    Properties:
      Name: prod/csdl/master
      GenerateSecretString:
        SecretStringTemplate: '{"username": "admin"}'
        GenerateStringKey: "password"
        PasswordLength: 32
        ExcludeCharacters: '"@/\'

  CoSoDuLieu:
    Type: AWS::RDS::DBInstance
    Properties:
      Engine: postgres
      MasterUsername: !Sub '{{resolve:secretsmanager:${MatKhauCSDL}::username}}'
      MasterUserPassword: !Sub '{{resolve:secretsmanager:${MatKhauCSDL}::password}}'

  GanBiMatVaoCSDL:
    Type: AWS::SecretsManager::SecretTargetAttachment
    Properties:
      SecretId: !Ref MatKhauCSDL
      TargetId: !Ref CoSoDuLieu
      TargetType: AWS::RDS::DBInstance

Ba điểm đáng chú ý trong template này:

GenerateSecretString khiến Secrets Manager tự sinh mật khẩu ngẫu nhiên mạnh — không ai, kể cả người chạy pipeline, từng nhìn thấy nó.

{{resolve:secretsmanager:...}} là dynamic reference: CloudFormation lấy giá trị lúc triển khai và không bao giờ lưu nó vào template hay vào lịch sử stack. Đây là khác biệt then chốt so với việc dùng parameter — mật khẩu không xuất hiện trong describe-stacks, không nằm trong event log, không lọt vào Git.

SecretTargetAttachment bổ sung thông tin kết nối (host, port, dbname) vào chính secret đó, để ứng dụng chỉ cần đọc một chỗ là có đủ.

Và vì bí mật đã nằm trong Secrets Manager, việc xoay vòng tự động về sau chỉ là bật thêm một thuộc tính.

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

• B. Viết Lambda tuỳ chỉnh để sinh chuỗi mã hoá làm mật khẩu — chạy được nhưng nhiều việc nhất: phải viết hàm, đóng gói, dựng custom resource, xử lý tín hiệu thành công/thất bại về CloudFormation, xử lý cả trường hợp rollback và xoá stack. Trái hẳn yêu cầu "minimum possible development effort".
• D. Dùng KMS sinh khoá mã hoá ngẫu nhiên rồi dùng khoá đó làm mật khẩu — sai công cụ: KMS sinh ra khoá mã hoá dạng nhị phân, không phải chuỗi mật khẩu. Dữ liệu nhị phân thường chứa ký tự mà RDS không chấp nhận trong mật khẩu, và bạn vẫn phải tự lo việc lưu trữ và xoay vòng.
• A. Dùng AWS::EC2::KeyPair sinh chuỗi bí mật làm mật khẩu — sai hoàn toàn về mục đích: key pair là cặp khoá SSH để đăng nhập vào EC2 instance. Nó không liên quan gì tới xác thực CSDL, và định dạng cũng không dùng được.

Ghi nhớ

Các dynamic reference của CloudFormation: | Cú pháp | Nguồn | |---|---| | {{resolve:secretsmanager:ten-bi-mat:SecretString:khoa}} | Secrets Manager | | {{resolve:ssm:ten-tham-so:phien-ban}} | SSM Parameter Store (thường) | | {{resolve:ssm-secure:ten:phien-ban}} | SSM SecureString |

Khác biệt cốt lõi so với parameter thường: | | Parameter (NoEcho) | Dynamic reference | |---|---|---| | Ai nhập giá trị | người triển khai | không ai — tự sinh | | Lưu trong stack | có (che khi hiển thị) | không lưu | | Xoay vòng sau này | ❌ | ✅ |

Ba việc nên làm cho mật khẩu CSDL trong hạ tầng dưới dạng mã:

1. Đừng bao giờ đặt mật khẩu vào template hay vào biến CI/CD.
2. Dùng GenerateSecretString để không ai từng biết giá trị.
3. Bật xoay vòng tự động với Lambda dựng sẵn của AWS cho RDS.

Và một cách còn gọn hơn nữa với RDS hiện nay: thuộc tính ManageMasterUserPassword: true — RDS tự tạo secret trong Secrets Manager và tự quản lý xoay vòng, không cần khai AWS::SecretsManager::Secret riêng.

Đáp án

B — Dữ liệu tự động được mã hoá bằng AWS owned key, không thể tắt; lập trình viên có thể thêm một lớp mã hoá nữa bằng customer managed key.

Vì sao đúng

AWS AppConfig (nằm trong AWS Systems Manager) áp dụng mô hình bảo mật khá phổ biến ở các dịch vụ AWS hiện đại: mã hoá at-rest luôn bật, không có công tắc tắt.

Lớp thứ hai đáng dùng khi có yêu cầu tuân thủ, vì nó cho bạn những thứ mà AWS owned key không có:

aws appconfig create-configuration-profile \
  --application-id abc123 \
  --name cau-hinh-ung-dung \
  --location-uri hosted \
  --kms-key-identifier arn:aws:kms:ap-southeast-1:123456789012:key/xyz

Cụm "cannot be disabled" trong phương án B là điểm phân biệt: nó phản ánh đúng thiết kế mã hoá mặc định không thể tắt, và CMK là lớp thêm vào, không phải lớp thay thế.

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

• C. "…lập trình viên có thể TẮT lớp này và thay bằng customer managed key" — sai đúng một điểm nhưng là điểm quan trọng nhất: mã hoá mặc định KHÔNG TẮT ĐƯỢC. CMK bổ sung, không thay thế. Đây là bẫy tinh vi nhất trong bốn phương án.
• A. "Dữ liệu lưu trong S3 và KHÔNG được mã hoá theo mặc định" — sai hai chỗ: AppConfig không lưu cấu hình trong bucket S3 của bạn (nó có kho lưu trữ riêng, gọi là hosted configuration, dù cũng hỗ trợ lấy cấu hình từ S3, Parameter Store hay CodePipeline làm nguồn), và mã hoá luôn bật. (Thêm nữa, từ đầu 2023, ngay cả S3 cũng mã hoá mặc định cho mọi object mới — nên vế "unencrypted by default" đã lỗi thời với cả S3.)
• D. "Dữ liệu không được mã hoá theo mặc định; lập trình viên chọn AWS managed key hoặc customer managed key" — sai ở tiền đề: mã hoá luôn bật, không có trạng thái "chưa mã hoá" nào để bắt đầu.

Ghi nhớ

Ba loại khoá KMS — bảng này áp dụng cho rất nhiều dịch vụ AWS, không riêng AppConfig: | Loại | Ai sở hữu | Thấy trong tài khoản | Key policy | Chi phí | |---|---|---|---|---| | AWS owned | AWS | ❌ không thấy | ❌ | miễn phí | | AWS managed (aws/dich-vu) | AWS, trong tài khoản bạn | ✅ | ❌ không sửa được | miễn phí (trả phí request) | | Customer managed | bạn | ✅ | ✅ toàn quyền | ~1 USD/tháng + phí request |

Nguyên tắc chung ở các dịch vụ AWS hiện đại: mã hoá at-rest bật mặc định bằng AWS owned key, và CMK là tuỳ chọn nâng cấp. Điều này đúng với DynamoDB, S3, AppConfig, Secrets Manager (bắt buộc KMS), CodeCommit, và nhiều dịch vụ khác.

Vài điểm về chính AppConfig — dịch vụ này giải quyết bài toán đáng chú ý: | Tính năng | Chi tiết | |---|---| | Triển khai cấu hình theo giai đoạn | linear, exponential — không đẩy cấu hình lỗi ra toàn bộ cùng lúc | | Validator | kiểm tra cấu hình bằng JSON Schema hoặc Lambda trước khi triển khai | | Tự động rollback | nối với CloudWatch alarm — alarm kêu thì tự quay lại cấu hình cũ | | Feature flag | bật/tắt tính năng không cần triển khai lại mã |

Ba tính năng đầu cùng nhau tạo ra điều mà đọc cấu hình từ S3 hay Parameter Store không có: một cấu hình sai không thể hạ toàn bộ hệ thống cùng lúc. Đó là lý do chính để chọn AppConfig thay vì tự đọc tệp cấu hình.

Đáp án

B — Phải gọi createUsagePlanKey để gắn API key mới vào usage plan phù hợp.

Vì sao đúng

Đây là bước bị bỏ sót phổ biến nhất khi tự động hoá việc cấp API key: tạo key thôi là chưa đủ.

API key trong API Gateway không mang quyền truy cập tự thân. Nó chỉ có tác dụng khi được liên kết với một usage plan, và usage plan mới là thứ khai stage nào được gọi, hạn ngạch bao nhiêu, tần suất thế nào:

API key (tạo bằng CreateApiKey)
    ↓ PHẢI liên kết bằng createUsagePlanKey
Usage plan  ──→ stage "prod" của API
             └─ quota: 10.000 request/tháng
             └─ throttle: 100 req/giây

Thiếu bước liên kết, API Gateway coi key đó là không hợp lệ và trả về 403 Forbidden — đúng triệu chứng trong đề. Người dùng cũ không bị ảnh hưởng vì key của họ đã được gắn từ trước.

Quy trình đúng khi đăng ký người dùng mới:

key = apigw.create_api_key(name=f'khach-{user_id}', enabled=True)

apigw.create_usage_plan_key(
    usagePlanId='abc123',
    keyId=key['id'],
    keyType='API_KEY'          # ← bước quyết định
)

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

• C. Gọi createDeployment để triển khai lại API — API key không phải một phần của cấu hình API. Chúng là tài nguyên độc lập, quản lý qua usage plan. Triển khai lại không thay đổi gì về key.
• A. Gọi updateAuthorizer để authorizer bao gồm key mới — nhầm hai cơ chế: authorizer (Lambda hoặc Cognito) và API key là hai lớp hoàn toàn riêng biệt. Authorizer không biết gì về API key.
• D. Gọi importApiKeys để nhập key mới vào stage hiện tại — importApiKeys có thật, nhưng nó dùng để nhập hàng loạt key từ tệp CSV; key vừa được tạo bằng CreateApiKey đã tồn tại rồi, không cần nhập lại. Và key không thuộc về stage — chúng thuộc về usage plan.

Ghi nhớ

Ba việc phải làm để API key hoạt động: | Bước | API | |---|---| | 1. Tạo key | CreateApiKey | | 2. Gắn vào usage plan | CreateUsagePlanKey ← hay quên | | 3. Bật yêu cầu key trên method | apiKeyRequired: true |

Bước 3 cũng đáng nhớ: nếu method không bật apiKeyRequired, API Gateway bỏ qua header x-api-key hoàn toàn — ai không có key vẫn gọi được, và bạn tưởng mình đang bảo vệ API.

Client gửi key trong header:

x-api-key: abcd1234efgh5678

Và một lưu ý về mục đích: API key KHÔNG PHẢI cơ chế xác thực. Nó dùng để nhận diện và đo lường khách hàng (ai gọi bao nhiêu, có vượt hạn ngạch không). Muốn xác thực thật thì dùng IAM, Cognito, hoặc Lambda authorizer — AWS nói rõ điều này trong tài liệu.

Đáp án

B — Gắn EBS volume vào instance và bật mã hoá lúc tạo volume.

Vì sao đúng

Đề nêu ba yêu cầu, và mỗi yêu cầu loại bớt một phương án:

1. Kho lưu trữ mount được, dùng lâu dài ⇒ phải là ổ đĩa khối
2. Instance loại C6i — thế hệ Nitro
3. Mã hoá cả at-rest lẫn in-transit theo chuẩn tuân thủ nghiêm ngặt

EBS là lựa chọn duy nhất "mountable" trong bốn phương án — nó xuất hiện với hệ điều hành như một ổ đĩa thật, định dạng và mount được như ổ cứng thường.

Và mã hoá EBS lo trọn cả hai chiều: | Chiều | Cơ chế | |---|---| | At rest | dữ liệu trên volume và mọi snapshot đều được mã hoá bằng KMS | | In transit | traffic giữa instance và volume được mã hoá — tự động, không cấu hình |

aws ec2 create-volume --size 100 --volume-type gp3 \
  --availability-zone ap-southeast-1a \
  --encrypted --kms-key-id alias/khoa-cua-toi

Việc mã hoá diễn ra trên máy chủ vật lý host của instance, nên hiệu năng gần như không suy giảm — và với họ instance dựa trên Nitro như C6i, mã hoá được xử lý bằng phần cứng chuyên dụng.

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

• C. Gắn EBS volume, "mã hoá được bật tự động" — đúng dịch vụ nhưng sai về hành vi mặc định: EBS không tự mã hoá trừ khi bạn bật --encrypted, hoặc đã bật thiết lập "encryption by default" ở mức tài khoản và Region. Với yêu cầu tuân thủ nghiêm ngặt, không nên trông vào một mặc định có thể chưa được bật.
• A và D. Gắn S3 bucket vào instance — S3 không mount được như hệ thống tệp: nó là kho object truy cập qua API. (Có công cụ như mountpoint-s3 mô phỏng việc mount, nhưng nó không phải ổ đĩa khối và không phù hợp cho kho lưu trữ chính của instance.) Phương án D còn sai thêm ở chỗ nói mã hoá bật tự động — với S3 thì điều đó đã đúng từ đầu 2023, nhưng vế "mount" vẫn khiến phương án sai.

Ghi nhớ

Ba loại lưu trữ cho EC2: | Loại | Mount được | Chia sẻ nhiều instance | Bền | |---|---|---|---| | EBS | ✅ ổ đĩa khối | ❌ (trừ Multi-Attach, cùng AZ) | ✅ | | EFS | ✅ NFS | ✅ | ✅ | | Instance store | ✅ | ❌ | ❌ mất khi dừng máy | | S3 | ❌ (qua API) | ✅ | ✅ |

Vài điểm cần nhớ về mã hoá EBS:

• Không bật/tắt được cho volume đã có — muốn mã hoá volume cũ thì phải chụp snapshot, sao chép snapshot có mã hoá, rồi tạo volume mới.
• Snapshot của volume mã hoá luôn được mã hoá, và volume tạo từ snapshot đó cũng vậy.
• Bật "encryption by default" ở mức tài khoản là cách chắc chắn nhất để không ai vô tình tạo volume không mã hoá:

aws ec2 enable-ebs-encryption-by-default

• Mã hoá miễn phí — bạn chỉ trả phí lời gọi KMS, và chúng rất ít vì khoá được cache ở mức host.

Đáp án

D — Adaptive authentication (xác thực thích ứng).

Vì sao đúng

Yêu cầu rất cụ thể: cho phép đăng nhập từ mọi nguồn, nhưng tự động chặn khi mức rủi ro cao.

Adaptive authentication là tính năng thuộc nhóm advanced security của Cognito user pool, làm đúng việc đó: nó chấm điểm rủi ro cho từng lần đăng nhập rồi hành động theo mức điểm.

Cognito đánh giá rủi ro dựa trên nhiều tín hiệu: | Tín hiệu | Ví dụ dấu hiệu bất thường | |---|---| | Thiết bị | thiết bị chưa từng thấy | | Vị trí | IP ở quốc gia khác thường | | Hành vi | nhiều lần đăng nhập hỏng liên tiếp | | Danh tiếng IP | IP nằm trong danh sách độc hại | | Mật khẩu bị lộ | thông tin đăng nhập xuất hiện trong các vụ rò rỉ đã biết |

Với mỗi mức rủi ro, bạn khai một hành động:

Rủi ro THẤP        → Allow (cho qua)
Rủi ro TRUNG BÌNH  → Optional MFA / Require MFA
Rủi ro CAO         → Block  ← đúng yêu cầu của đề

aws cognito-idp set-risk-configuration \
  --user-pool-id ap-southeast-1_xxx \
  --account-takeover-risk-configuration '{
    "Actions": {
      "HighAction":   {"EventAction": "BLOCK",  "Notify": true},
      "MediumAction": {"EventAction": "MFA_REQUIRED", "Notify": true},
      "LowAction":    {"EventAction": "NO_ACTION", "Notify": false}
    }
  }'

Điểm hay: nó không cản trở người dùng bình thường (họ vẫn đăng nhập từ bất kỳ đâu như đề yêu cầu), mà chỉ can thiệp khi có dấu hiệu bất thường thật.

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

• A. Advanced security metrics — chỉ hiển thị số liệu về các sự kiện bảo mật (bao nhiêu lần đăng nhập rủi ro cao, bao nhiêu lần bị chặn). Nó là công cụ quan sát, không tự chặn gì cả.
• C. Multi-factor authentication (MFA) — MFA áp cho mọi lần đăng nhập (hoặc bật/tắt theo người dùng), chứ không phản ứng theo mức rủi ro. Bật MFA bắt buộc sẽ làm phiền cả những lần đăng nhập hoàn toàn bình thường. (MFA vẫn là một trong các hành động mà adaptive authentication có thể kích hoạt — nhưng bản thân nó không có logic đánh giá rủi ro.)
• B. Case sensitive user pools — thiết lập quyết định tên đăng nhập có phân biệt hoa thường hay không. Hoàn toàn không liên quan tới bảo mật theo rủi ro.

Ghi nhớ

Nhóm tính năng advanced security của Cognito user pool: | Tính năng | Việc | |---|---| | Adaptive authentication | chấm điểm rủi ro và hành động theo mức | | Compromised credentials | chặn mật khẩu đã xuất hiện trong các vụ rò rỉ | | Advanced security metrics | số liệu và log sự kiện bảo mật |

Ba chế độ của advanced security: | Chế độ | Hành vi | |---|---| | OFF | tắt | | AUDIT | chỉ ghi nhận, KHÔNG chặn — dùng để quan sát trước | | ENFORCED | áp dụng hành động thật |

Thực hành nên theo: bật AUDIT trước vài tuần, xem thực tế có bao nhiêu người dùng thật bị chấm điểm rủi ro cao, rồi mới chuyển sang ENFORCED. Chặn nhầm người dùng hợp lệ là loại sự cố rất khó phát hiện — họ chỉ đơn giản là không đăng nhập được và bỏ đi.

Lưu ý về chi phí: advanced security tính phí thêm theo số người dùng hoạt động hàng tháng, không nằm trong gói miễn phí của Cognito.

Đáp án

C — Tạo event notification cho s3:ObjectCreated:*.

Vì sao đúng

Đề yêu cầu được báo về MỌI sự kiện tạo object mới. Ký tự đại diện * trong s3:ObjectCreated:* bao trùm tất cả các cách một object có thể được tạo:

Cấu hình gửi tới SNS:

{
  "TopicConfigurations": [{
    "TopicArn": "arn:aws:sns:ap-southeast-1:123456789012:thong-bao-s3",
    "Events": ["s3:ObjectCreated:*"]
  }]
}

Rồi đăng ký email vào topic:

aws sns subscribe --topic-arn <arn> --protocol email \
  --notification-endpoint lap-trinh-vien@congty.com

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

• B. Chỉ s3:ObjectCreated:Put — đây là bẫy chính, và nó bỏ sót ba trường hợp quan trọng. Đáng chú ý nhất là CompleteMultipartUpload: AWS CLI và SDK tự động chuyển sang multipart upload cho tệp lớn hơn khoảng 8–16 MB, nên mọi tệp lớn sẽ không sinh thông báo nào. Đây là lỗi rất khó phát hiện vì hệ thống chạy đúng với tệp nhỏ lúc kiểm thử rồi im lặng bỏ sót tệp lớn ở production.
• A. s3:ObjectRestore:Post — sự kiện này xảy ra khi khôi phục object từ Glacier, không phải khi tạo object mới.
• D. s3:ObjectRemoved:Delete — sự kiện XOÁ object. Ngược hẳn với điều đề cần.

Ghi nhớ

Các nhóm sự kiện của S3: | Nhóm | Sự kiện con | |---|---| | s3:ObjectCreated:* | Put, Post, Copy, CompleteMultipartUpload | | s3:ObjectRemoved:* | Delete, DeleteMarkerCreated | | s3:ObjectRestore:* | Post, Completed, Delete | | s3:ReducedRedundancyLostObject | mất object ở lớp RRS | | s3:Replication:* | các sự kiện nhân bản | | s3:LifecycleTransition | object chuyển lớp lưu trữ |

Ba đích mà S3 gửi thông báo tới: | Đích | Ghi chú | |---|---| | SNS | fan-out — email, SMS, nhiều subscriber | | SQS | đưa vào hàng đợi để xử lý | | Lambda | gọi hàm trực tiếp | | EventBridge | linh hoạt nhất — lọc theo mẫu, nhiều đích |

Hai điểm thực dụng:

1. Topic SNS cần resource policy cho phép S3 publish — thiếu nó thì S3 báo lỗi ngay lúc lưu cấu hình notification.
2. Bật EventBridge cho bucket là lựa chọn đáng cân nhắc nếu cần lọc phức tạp (theo prefix, suffix, kích thước) — S3 event notification chỉ lọc được prefix và suffix.

Và nhớ: S3 event notification đảm bảo at-least-once, nên bên xử lý phải idempotent — cùng một sự kiện có thể tới hai lần.

Đáp án

C — Gọi kms:GenerateDataKey để lấy một khoá mã hoá.

Vì sao đúng

Con số quyết định nằm ngay trong đề: dữ liệu khoảng 1 MB.

kms:Encrypt có giới hạn cứng 4 KB — 1 MB vượt xa ngưỡng đó, nên mã hoá trực tiếp bị từ chối. Cách duy nhất là envelope encryption:

# 1. Xin một data key — KMS trả về CẢ HAI dạng
r = kms.generate_data_key(KeyId='alias/khoa-cua-toi', KeySpec='AES_256')
khoa_ban_ro = r['Plaintext']        # dùng để mã hoá TẠI CHỖ
khoa_ban_ma = r['CiphertextBlob']   # lưu kèm dữ liệu

# 2. Mã hoá 1 MB dữ liệu bằng AES cục bộ
f = Fernet(base64.urlsafe_b64encode(khoa_ban_ro))
du_lieu_ma = f.encrypt(du_lieu)

# 3. Xoá khoá bản rõ khỏi bộ nhớ
del khoa_ban_ro

# 4. Gửi đi cả hai: khoá đã mã hoá + dữ liệu đã mã hoá
gui_di(khoa_ban_ma, du_lieu_ma)

Ý tưởng cốt lõi: chỉ có khoá 256-bit đi qua mạng tới KMS, còn 1 MB dữ liệu được mã hoá ngay trong hàm Lambda. Vừa không vướng giới hạn kích thước, vừa nhanh hơn nhiều so với truyền dữ liệu qua mạng.

Bên nhận giải mã ngược lại: gọi kms:Decrypt trên khoá đã mã hoá (nó nhỏ, dưới 4 KB) rồi dùng khoá đó giải mã dữ liệu.

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

• A. Truyền thẳng dữ liệu cho KMS và gọi Encrypt — vượt giới hạn 4 KB, lời gọi sẽ thất bại với 1 MB dữ liệu. Đây là bẫy chính.
• B. Gọi GenerateDataKeyWithoutPlaintext — API này có thật nhưng chỉ trả về khoá ở dạng đã mã hoá, không có bản rõ. Nên bạn không mã hoá được gì ngay lập tức; phải gọi thêm Decrypt để lấy bản rõ. Nó dùng cho tình huống tạo sẵn khoá để dùng sau (ví dụ hệ thống sinh khoá cho hàng nghìn đối tượng rồi mới mã hoá dần ở nơi khác).
• D. Gọi ReEncrypt — API này mã hoá lại một ciphertext ĐÃ CÓ bằng khoá khác, dùng khi xoay vòng CMK hoặc chuyển dữ liệu sang khoá mới. Nó không mã hoá dữ liệu bản rõ, và cũng chịu giới hạn 4 KB.

Ghi nhớ

Cách chọn nhanh:

• ≤ 4 KB ⇒ Encrypt trực tiếp
• > 4 KB ⇒ GenerateDataKey + envelope encryption

Ba việc nên làm khi cài đặt:

1. Xoá khoá bản rõ ngay sau khi dùng — đừng ghi ra log hay đĩa.
2. Lưu khoá đã mã hoá cùng dữ liệu — mất nó là mất dữ liệu vĩnh viễn.
3. Dùng encryption context để ràng buộc khoá với ngữ cảnh, và nó xuất hiện trong CloudTrail giúp kiểm toán có nghĩa.

Trong thực tế, nên dùng AWS Encryption SDK thay vì tự viết — nó đã cài đặt sẵn toàn bộ mẫu này, kèm định dạng thông điệp chuẩn và caching data key.

Đáp án

A — Một bộ credential sinh ra từ IAM (Git credentials).

Vì sao đúng

CodeCommit không có hệ thống tài khoản riêng — mọi xác thực đều đi qua IAM. Với giao thức HTTPS, cách chuẩn là sinh Git credentials cho một IAM user:

IAM Console → Users → chọn user → Security credentials
   → HTTPS Git credentials for AWS CodeCommit → Generate
   → nhận username + password (CHỈ HIỆN MỘT LẦN, lưu lại ngay)

Cặp này dùng như tài khoản Git thông thường:

git clone https://git-codecommit.ap-southeast-1.amazonaws.com/v1/repos/kho-moi
# Username: ten-user-at-123456789012
# Password: <mật khẩu sinh ra>

Quy trình di trú đầy đủ từ GitHub:

git clone --mirror https://github.com/cong-ty/kho-cu.git kho-tam
cd kho-tam
git remote add codecommit https://git-codecommit.ap-southeast-1.amazonaws.com/v1/repos/kho-moi
git push codecommit --all
git push codecommit --tags

Cờ --mirror giữ toàn bộ nhánh, tag và lịch sử commit — quan trọng khi di trú, vì git clone thường chỉ lấy nhánh mặc định.

IAM user cũng cần policy AWSCodeCommitPowerUser hoặc quyền tương đương.

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

• B. Cặp khoá SSH công khai/riêng tư — cách hợp lệ nhưng cho giao thức khác. Đề nói rõ "over HTTPS". SSH dùng khi bạn tải public key lên IAM user rồi clone qua ssh://git-codecommit....
• C. GitHub authentication token — dùng để xác thực với GitHub. Sau khi đã clone kho về máy, token đó không còn vai trò gì trong việc đẩy lên CodeCommit.
• D. IAM role gắn vào EC2 với quyền CodeCommit — hợp lệ nhưng cho tình huống khác: nó dùng khi thao tác chạy trên một EC2 instance với credential helper của AWS CLI. Đề mô tả đội phát triển đẩy kho từ máy của họ.

Ghi nhớ

Bốn cách xác thực với CodeCommit: | Cách | Giao thức | Dùng khi | |---|---|---| | Git credentials (IAM) | HTTPS | đơn giản nhất cho người dùng | | SSH key | SSH | quen dùng SSH | | git-remote-codecommit | HTTPS (grc://) | dùng được với IAM role, SSO, MFA | | Credential helper của AWS CLI | HTTPS | trên EC2, CodeBuild — dùng role |

git-remote-codecommit là cách được AWS khuyến nghị hiện nay, vì nó hoạt động với role và liên kết danh tính — không cần IAM user cố định nào:

pip install git-remote-codecommit
git clone codecommit://ho-so-aws@kho-cua-toi

(Ghi chú thời sự: từ 25/7/2024, AWS ngừng cho khách hàng mới tạo repository trên CodeCommit; các tài khoản đã dùng vẫn hoạt động bình thường. Với dự án mới, AWS hướng người dùng sang GitHub, GitLab hoặc CodeCatalyst — chúng nối vào CodePipeline qua CodeStar Connections. Câu hỏi vẫn nằm trong phạm vi kỳ thi, nhưng đừng chọn CodeCommit làm nơi lưu mã cho hệ thống mới.)

Đáp án

D — Cấu hình ALB dùng chứng chỉ X.509 thông qua AWS Management Console.

Vì sao đúng

Đề nói rõ: kết nối cần bảo vệ là giữa client và ALB. Nên chứng chỉ phải được gắn vào listener HTTPS của ALB — đó là nơi TLS được kết thúc.

Client ──HTTPS (chứng chỉ ACM ở đây)──→ ALB ──HTTP──→ EC2

Cách gắn rất đơn giản, chỉ là chọn chứng chỉ từ danh sách ACM:

aws elbv2 create-listener \
  --load-balancer-arn arn:aws:elasticloadbalancing:...:loadbalancer/app/web/abc \
  --protocol HTTPS --port 443 \
  --certificates CertificateArn=arn:aws:acm:...:certificate/xyz \
  --ssl-policy ELBSecurityPolicy-TLS13-1-2-2021-06 \
  --default-actions Type=forward,TargetGroupArn=...

Điểm mấu chốt về ACM khiến các phương án khác không khả thi: bạn KHÔNG XUẤT được private key của chứng chỉ công cộng do ACM cấp. Đây là thiết kế cố ý — khoá riêng không bao giờ rời khỏi AWS, và đó chính là lý do ACM an toàn và miễn phí.

Vì vậy ACM chỉ dùng được với các dịch vụ tích hợp sẵn: ELB, CloudFront, API Gateway, AppSync, Cognito. Bạn không thể lấy chứng chỉ đó đem đi cài ở nơi khác.

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

• B. Cấu hình từng EC2 instance dùng chứng chỉ X.509 đó — không làm được: để cài chứng chỉ lên máy chủ web trên EC2, bạn cần private key — mà ACM không cho xuất. Ngoài ra làm vậy còn mất hẳn lợi ích của TLS termination tại ALB.
• A và C. Xuất "root key" của chứng chỉ ra S3 bucket rồi dùng từ đó — sai vì hai lẽ. Thứ nhất, không xuất được như đã nói. Thứ hai, "root key" không phải khái niệm đúng — chứng chỉ có private key và chuỗi CA, không có thứ gọi là root key của chứng chỉ. Và kể cả nếu có, lưu private key trong S3 rồi đọc ra dùng là một thực hành bảo mật rất tệ.

Ghi nhớ

Nơi dùng được chứng chỉ ACM công cộng: | Dịch vụ | Dùng được | |---|---| | ELB (ALB, NLB) | ✅ | | CloudFront | ✅ (chứng chỉ phải ở us-east-1) | | API Gateway | ✅ | | AppSync, Cognito | ✅ | | EC2 trực tiếp | ❌ không xuất được private key |

Muốn dùng TLS trên chính EC2 thì có hai lựa chọn:

1. Chứng chỉ từ CA bên ngoài (Let's Encrypt, DigiCert…) — bạn có private key và tự cài.
2. Chứng chỉ từ AWS Private CA — ACM cho phép xuất private key với chứng chỉ riêng tư, khác với chứng chỉ công cộng.

Ba mô hình mã hoá với ALB: | Mô hình | Client → ALB | ALB → EC2 | |---|---|---| | TLS termination (phổ biến nhất) | HTTPS | HTTP | | End-to-end encryption | HTTPS | HTTPS | | Pass-through | — | chỉ NLB làm được (tầng 4) |

Với yêu cầu tuân thủ nghiêm ngặt, mô hình thứ hai được dùng — và điểm hay là ALB không kiểm tra chứng chỉ của backend, nên EC2 dùng được chứng chỉ tự ký, không tốn thêm chi phí nào.

Và nhớ chọn SSL policy đủ mới (ELBSecurityPolicy-TLS13-1-2-...) — chính sách cũ vẫn cho phép TLS 1.0/1.1 vốn đã bị coi là không an toàn.