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

Đáp án

C và D.

• C — Người dùng gửi được ReceiveMessage tới example_queue — IAM policy cho phép.
• D — Nếu thêm một policy từ chối mọi hành động trên queue, nó ghi đè cả hai policy kia và người dùng mất quyền truy cập.

Vì sao đúng

Tình huống: IAM policy cho ReceiveMessage, SQS policy cho SendMessage. Kết quả là người dùng làm được cả hai.

C đúng vì đây là nguyên tắc hợp nhất của IAM: identity-based policy và resource-based policy CỘNG DỒN với nhau:

IAM policy  : Allow ReceiveMessage
SQS policy  : Allow SendMessage
────────────────────────────────
Quyền thực tế: ReceiveMessage ✅  +  SendMessage ✅

Chỉ cần một trong hai cho phép là hành động được thực hiện — không cần cả hai cùng cho phép (khác với trường hợp chéo tài khoản, ở đó bắt buộc cả hai vế).

D đúng vì quy tắc tuyệt đối của IAM: Deny tường minh luôn thắng mọi Allow, bất kể nó nằm ở loại policy nào:

1. Có Deny tường minh?  → CÓ → TỪ CHỐI (dừng, không xét gì thêm)
2. Có Allow tường minh? → CÓ → CHO PHÉP
3. Mặc định             → TỪ CHỐI ngầm định

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

• A. "IAM policy sẽ TỪ CHỐI SendMessage" — hiểu sai cơ chế. IAM policy không nhắc tới SendMessage, và không nhắc tới nghĩa là không cho phép, chứ không phải từ chối tường minh. Quyền đó đến từ SQS policy, và không có gì chặn nó.
• B. "Chỉ được dùng một trong hai loại policy, không dùng đồng thời" — sai hoàn toàn. Dùng cả hai là chuyện bình thường và rất phổ biến.
• E. "Chỉ thêm IAM policy deny là chưa đủ, SQS policy cũng phải deny" — sai. Một Deny tường minh ở bất kỳ đâu là đủ để chặn. Không cần deny ở cả hai nơi.

Ghi nhớ

Hai quy tắc quan trọng nhất:

1. Trong CÙNG một tài khoản: chỉ cần một bên cho phép
2. CHÉO tài khoản: bắt buộc cả hai bên cho phép

Và luôn nhớ: Deny tường minh thắng tất cả — đó là công cụ mạnh nhất để dựng guardrail không thể lách.

Đáp án

D — ElastiCache for Redis với cluster mode BẬT.

Vì sao đúng

Đề nêu ba yêu cầu, và yêu cầu thứ ba là điểm phân biệt:

Geospatial là tính năng riêng của Redis:

GEOADD nha_hang 106.700 10.776 "Quan-A"  106.660 10.762 "Quan-B"
GEOSEARCH nha_hang FROMLONLAT 106.695 10.770 BYRADIUS 2 km ASC

Cluster mode là điểm loại giữa D và B. Đây là khác biệt cốt lõi:

Với cluster mode tắt, bạn chỉ có một node primary — mở rộng nghĩa là đổi sang node lớn hơn (vertical scaling), có trần và phải dừng dịch vụ. Đề nói rõ cần horizontal scaling.

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

• B. Redis với cluster mode TẮT — có geospatial và query, nhưng không mở rộng ngang được. Trượt yêu cầu thứ ba.
• C. Migrate sang DynamoDB + DAX — cuộc di trú CSDL toàn diện thay vì thêm một tầng cache. DAX cũng chỉ cache cho DynamoDB, không dùng được với RDS. Và DynamoDB không có geospatial gốc (phải tự cài đặt geohash).
• A. CloudFront caching — CDN cache nội dung web ở edge. Nó không phải cache dữ liệu cho ứng dụng, không có truy vấn, không có geospatial. Sai tầng hoàn toàn.

Ghi nhớ

Các cấu trúc dữ liệu của Redis — lý do nó mạnh hơn Memcached rất nhiều: | Cấu trúc | Dùng cho | |---|---| | String | cache đơn giản | | Sorted set | bảng xếp hạng, xếp hạng theo điểm | | Geospatial | tìm theo vị trí, tính khoảng cách | | Hash | lưu object | | List | hàng đợi, dòng thời gian | | Stream | log sự kiện | | HyperLogLog | đếm số phần tử khác nhau (xấp xỉ) |

Cách chọn nhanh: cần shard/mở rộng ngang ⇒ cluster mode BẬT. Đổi lại, cluster mode bật có vài hạn chế: không promote replica thủ công được, và các lệnh multi-key phải nằm cùng một shard.

Đáp án

C — DownloadBundle → BeforeInstall → ApplicationStart → ValidateService.

Vì sao đúng

Vòng đời deployment của CodeDeploy trên EC2 có thứ tự cố định. Đây là chuỗi đầy đủ, với các bước CodeDeploy tự thực hiện in nghiêng:

ApplicationStop      ← dừng ứng dụng cũ (chạy script của bản revision TRƯỚC)
  ↓
*DownloadBundle*     ← CodeDeploy tải bundle về (KHÔNG viết hook được)
  ↓
BeforeInstall        ← chuẩn bị: sao lưu, dọn dẹp
  ↓
*Install*            ← CodeDeploy chép tệp (KHÔNG viết hook được)
  ↓
AfterInstall         ← đổi quyền tệp, sửa cấu hình
  ↓
ApplicationStart     ← khởi động ứng dụng mới
  ↓
ValidateService      ← xác minh deploy thành công

Bốn sự kiện trong đáp án đúng theo đúng thứ tự đó.

Một chi tiết đáng nhớ: DownloadBundle và Install là sự kiện của CodeDeploy, không phải hook viết được. Chúng xuất hiện trong lịch sử deployment và trong câu hỏi này, nhưng bạn không đặt script vào chúng.

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

• A. BeforeInstall trước DownloadBundle — vô lý: không thể chuẩn bị cài đặt khi bundle còn chưa được tải về.
• B và D. Đặt ValidateService trước ApplicationStart — cũng vô lý: không thể xác minh một dịch vụ chưa được khởi động.

Ghi nhớ

Hai câu hỏi trong lô này (#5230 và câu này) đều về thứ tự hook, chỉ khác tập sự kiện được liệt kê — nên nhớ toàn bộ chuỗi là trả lời được cả hai.

Bộ hook theo nền tảng: | Nền tảng | Hook viết được | |---|---| | EC2/On-prem (in-place) | ApplicationStop, BeforeInstall, AfterInstall, ApplicationStart, ValidateService | | EC2 blue/green | thêm BeforeBlockTraffic, AfterBlockTraffic, BeforeAllowTraffic, AfterAllowTraffic | | ECS | BeforeInstall, AfterInstall, AfterAllowTestTraffic, BeforeAllowTraffic, AfterAllowTraffic | | Lambda | chỉ BeforeAllowTraffic, AfterAllowTraffic |

Và cái bẫy kinh điển: ApplicationStop chạy script từ bản revision TRƯỚC ĐÓ. Script đó hỏng sẽ chặn mọi lần deploy sau, và cách thoát là tạo deployment mới với tuỳ chọn bỏ qua ApplicationStop.

Đáp án

D — Amazon DynamoDB.

Vì sao đúng

Yêu cầu: xử lý theo sự kiện mỗi khi dữ liệu bị sửa hoặc xoá, bằng Lambda, theo hướng serverless.

DynamoDB Streams là câu trả lời trực tiếp: nó ghi lại mọi thay đổi ở mức item theo đúng thứ tự và giữ trong 24 giờ.

{"StreamSpecification": {
  "StreamEnabled": true,
  "StreamViewType": "NEW_AND_OLD_IMAGES"
}}

Bốn loại view — chọn theo nhu cầu: | StreamViewType | Nội dung bản ghi | |---|---| | KEYS_ONLY | chỉ khoá chính | | NEW_IMAGE | item sau khi thay đổi | | OLD_IMAGE | item trước khi thay đổi | | NEW_AND_OLD_IMAGES | cả hai — cần cho việc so sánh |

Lambda tiêu thụ stream qua event source mapping, và ba loại sự kiện được phân biệt sẵn:

def handler(event, context):
    for r in event['Records']:
        if r['eventName'] == 'MODIFY':
            cu  = r['dynamodb']['OldImage']
            moi = r['dynamodb']['NewImage']
        elif r['eventName'] == 'REMOVE':
            xu_ly_xoa(r['dynamodb']['OldImage'])

Đây là serverless trọn vẹn: không hạ tầng nào để quản, Lambda tự co giãn theo số shard của stream.

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

• A. RDS — CSDL quan hệ không có cơ chế stream gốc kiểu này. Muốn bắt thay đổi thì phải dùng DMS với CDC hoặc trigger tự viết — cả hai đều nặng hơn và không serverless.
• B. ElastiCache — cache trong bộ nhớ, không phải CSDL chính. Nó không phát stream thay đổi để Lambda tiêu thụ. (Redis có keyspace notification, nhưng đó là cơ chế khác và không tích hợp với Lambda.)
• C. Kinesis — không phải CSDL. Đề hỏi "which of the following databases should you choose". Kinesis là dịch vụ luồng dữ liệu; nó có thể nhận dữ liệu nhưng không lưu trữ theo kiểu CSDL.

Ghi nhớ

Ba mẫu dùng phổ biến của DynamoDB Streams: nhân bản dữ liệu sang hệ khác (OpenSearch để tìm kiếm), kiểm toán thay đổi, và kích hoạt nghiệp vụ (gửi email khi trạng thái đơn hàng đổi).

Đáp án

A — SNS + SQS.

Vì sao đúng

Đề nêu ba yêu cầu, và mô hình fan-out đáp ứng cả ba:

Đơn hàng mới → SNS topic ─┬→ Email/SMS phòng ban        (thông báo)
                          └→ SQS queue → EC2 instances   (xử lý, có thể thử lại)

Vì sao phải có SQS, không cho EC2 đăng ký thẳng vào SNS. Đây là điểm then chốt cho vế "re-processed at a later stage":

• SNS không lưu message. Subscriber đang chết thì message mất luôn (SNS có retry nhưng hết lượt là bỏ).
• SQS giữ message tới 14 ngày, nên EC2 có thể chết, được sửa, rồi quay lại xử lý tiếp — không mất gì.
• SQS còn cho visibility timeout (xử lý hỏng thì message tự quay lại) và DLQ (cô lập message hỏng hẳn).

Mô hình này cũng mở rộng dễ: thêm một hệ downstream chỉ là thêm một subscriber — không sửa mã bên phát.

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

• B. SNS + Lambda — bỏ mất lớp đệm bền vững. Lambda bị throttle hoặc lỗi liên tục thì message có thể mất. Và đề nói rõ việc xử lý do EC2 instances đảm nhiệm.
• C. SNS + Kinesis — Kinesis là luồng dữ liệu, hợp cho phân tích thời gian thực và nhiều consumer đọc lại. Nó không phải hàng đợi công việc, không có visibility timeout hay DLQ theo message — mô hình xử lý đơn hàng không khớp.
• D. SQS + SES — SES gửi email được, nhưng SQS không phát tin cho nhiều người nhận: mỗi message chỉ một consumer lấy được. Không có fan-out, nên không thể vừa thông báo vừa xử lý từ cùng một message.

Ghi nhớ

Fan-out pattern — một trong những mẫu kiến trúc quan trọng nhất trên AWS:

Nguồn → SNS topic ─┬→ SQS → consumer A
                   ├→ SQS → consumer B
                   └→ Email / Lambda / HTTP endpoint

Nguyên tắc: cần fan-out ⇒ SNS. Cần độ bền và thử lại ⇒ SQS. Cần cả hai ⇒ ghép chúng lại.

Đáp án

D, E và F.

• E — Quản trị viên tài khoản A tạo IAM role và gắn permission policy.
• F — Quản trị viên tài khoản A gắn trust policy vào role, xác định tài khoản B là principal được assume role.
• D — Quản trị viên tài khoản B uỷ quyền cho người dùng trong tài khoản B được assume role đó.

Vì sao đúng

Đây là mẫu cross-account role chuẩn, và nó có đúng ba bước — mỗi bước ở một chỗ:

Tài khoản A (sở hữu SQS queue)          Tài khoản B (cần truy cập)
┌──────────────────────────────┐        ┌──────────────────────────┐
│ E. Tạo role + permission     │        │                          │
│    policy (quyền trên queue) │        │                          │
│                              │        │                          │
│ F. Trust policy:             │◀───────│ D. Cấp cho user quyền    │
│    Principal = tài khoản B   │assume  │    sts:AssumeRole        │
└──────────────────────────────┘        └──────────────────────────┘

E — permission policy nói role làm được gì:

{"Effect": "Allow",
 "Action": ["sqs:SendMessage", "sqs:ReceiveMessage", "sqs:DeleteMessage"],
 "Resource": "arn:aws:sqs:ap-southeast-1:<A>:example_queue"}

F — trust policy nói ai được vào:

{"Effect": "Allow",
 "Principal": {"AWS": "arn:aws:iam::<B>:root"},
 "Action": "sts:AssumeRole"}

D — identity policy ở B nói ai được phép xin vào:

{"Effect": "Allow", "Action": "sts:AssumeRole",
 "Resource": "arn:aws:iam::<A>:role/TruyCapQueue"}

Thiếu bất kỳ bước nào cũng ra AccessDenied, và thông báo lỗi không cho biết thiếu bước nào.

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

• B. "Quản trị viên B tạo IAM role với trust policy có B là principal" — sai vị trí: role phải nằm ở tài khoản A (nơi có tài nguyên), không phải ở B.
• C. "Quản trị viên A uỷ quyền assume role cho người dùng trong A" — sai tài khoản: người cần assume nằm ở B, không phải A.
• A. "Trust policy xác định tài khoản B là AWS service principal" — sai loại principal. Service principal là các dịch vụ AWS (ec2.amazonaws.com, lambda.amazonaws.com). Một tài khoản AWS là AWS principal, khai bằng {"AWS": "arn:aws:iam::<B>:root"}.

Ghi nhớ

Câu thần chú cho truy cập chéo tài khoản:

Trust policy nằm ở nơi bạn muốn ĐẾN. Permission policy nằm ở nơi bạn ĐI TỪ.

Với SQS còn có cách thứ hai, đơn giản hơn: dùng queue policy (resource-based policy) cấp thẳng cho tài khoản B, không cần assume role nào:

{"Effect": "Allow",
 "Principal": {"AWS": "arn:aws:iam::<B>:root"},
 "Action": "sqs:SendMessage",
 "Resource": "arn:aws:sqs:...:example_queue"}

Cách role linh hoạt hơn (kiểm soát chi tiết, có vết CloudTrail hai phía); cách queue policy gọn hơn cho quyền đơn giản.

Đáp án

C — Dùng trường Export trong section Outputs của template.

Vì sao đúng

Chia sẻ giá trị giữa hai stack CloudFormation đi theo cặp Export → ImportValue, và mỗi bên nằm ở một stack:

Stack A — công bố giá trị bằng Export:

Outputs:
  IdSubnet:
    Description: Subnet cho tầng ứng dụng
    Value: !Ref SubnetChinh
    Export:
      Name: !Sub "${AWS::StackName}-IdSubnet"    # → mang-luoi-IdSubnet

Stack B — tiêu thụ bằng Fn::ImportValue:

Resources:
  MayChu:
    Type: AWS::EC2::Instance
    Properties:
      SubnetId: !ImportValue mang-luoi-IdSubnet

Đề hỏi "cung cấp thông tin này cho stack khác" — tức là phía công bố, nên đáp án là Export.

Kèm theo là một cơ chế bảo vệ rất đáng giá: CloudFormation không cho xoá hoặc sửa một export đang được stack khác import. Xoá nhầm subnet thì lệnh cập nhật thất bại ngay, thay vì âm thầm phá hỏng stack kia.

Mẹo đặt tên: đưa ${AWS::StackName} vào tên export để tránh trùng — vì tên export phải duy nhất trong một tài khoản + Region.

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

• A. Fn::ImportValue — đúng cơ chế nhưng sai phía. Đây là hàm dùng ở stack tiêu thụ, không phải ở stack cung cấp. Và không có Export thì không có gì để import.
• B. "Trường Expose trong section Outputs" — không tồn tại. Từ khoá đúng là Export.
• **D. Fn::Transform — không phải cơ chế chia sẻ giá trị. Transform dùng để gọi macro (SAM, AWS::Include) biến đổi template trước khi triển khai.

Ghi nhớ

Ba ràng buộc của cross-stack reference: | Ràng buộc | Chi tiết | |---|---| | Tên export duy nhất | trong một tài khoản + Region | | Không xuyên Region hay tài khoản | ImportValue chỉ dùng trong cùng tài khoản + Region | | Không xoá/sửa export đang bị import | phải gỡ mọi stack tiêu thụ trước |

So sánh với nested stack: ở đó quan hệ là cha–con (xoá cha là xoá cả cây), còn cross-stack là ngang hàng, độc lập — mỗi đội giữ vòng đời riêng.

Cần chia sẻ xuyên Region hoặc xuyên tài khoản thì dùng SSM Parameter Store thay cho export.

Đáp án

D — Dùng Amazon S3 và sửa mã ứng dụng để mọi tệp tải lên được ghi vào S3.

Vì sao đúng

Yêu cầu: tệp người dùng tải lên phải lưu bền vững và truy cập được từ mọi instance trong Auto Scaling group.

Vấn đề với lưu trữ cục bộ trong môi trường co giãn:

Instance A: /uploads/anh1.jpg     ← chỉ A thấy
Instance B: /uploads/anh2.jpg     ← chỉ B thấy
Instance A bị scale-in            ← anh1.jpg MẤT

S3 giải quyết trọn vẹn, và là lựa chọn đúng về mặt kiến trúc cho tệp người dùng tải lên:

Và có một mẫu tối ưu đáng nhắc: dùng pre-signed URL để client tải thẳng lên S3, không đi qua EC2 — tránh được giới hạn payload và giảm tải cho tầng ứng dụng.

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

• A. Instance Store + phần mềm đồng bộ tệp — tệ nhất: instance store là lưu trữ tạm thời, dữ liệu mất sạch khi instance dừng hoặc bị thay. Đồng bộ giữa các máy cũng phức tạp và luôn có độ trễ.
• B. EBS + phần mềm đồng bộ tệp — EBS bền hơn instance store, nhưng EBS volume chỉ gắn được vào một instance trong một AZ. Tự dựng cơ chế đồng bộ giữa nhiều volume là phức tạp, dễ xung đột, và không đảm bảo nhất quán.
• C. EBS + AMI dùng snapshot khi tạo instance mới — hiểu sai vấn đề: snapshot là ảnh chụp tại một thời điểm. Instance mới sẽ có dữ liệu tại lúc chụp snapshot, không có tệp người dùng vừa tải lên. Và mỗi instance vẫn có volume riêng, không chia sẻ được.

Ghi nhớ

Chọn lưu trữ theo nhu cầu: | Nhu cầu | Dịch vụ | |---|---| | Tệp người dùng tải lên, truy cập qua API | S3 | | Hệ thống tệp POSIX chia sẻ giữa nhiều instance | EFS | | Ổ đĩa khối cho một instance | EBS | | Lưu trữ tạm, hiệu năng cực cao | Instance store | | Chia sẻ cho Windows/SMB | FSx for Windows |

S3 và EFS đều giải quyết được bài toán chia sẻ, nhưng khác nhau: EFS khi ứng dụng cũ cần đường dẫn tệp POSIX và không sửa mã được; S3 khi sửa mã được — rẻ hơn, mở rộng tốt hơn, và là lựa chọn đúng cho tệp người dùng.

Đáp án

D — Tạo S3 event gọi một Lambda function để chèn bản ghi vào DynamoDB.

Vì sao đúng

Yêu cầu: chèn bản ghi vào DynamoDB ngay khi nhà cung cấp tải tệp mới lên S3.

S3 Event Notification là tích hợp trực tiếp giữa S3 và Lambda — không có gì ở giữa:

Tệp mới lên S3 → S3 event (s3:ObjectCreated:*) → Lambda → DynamoDB

{"LambdaFunctionConfigurations": [{
  "LambdaFunctionArn": "arn:aws:lambda:...:function:xu-ly-tep",
  "Events": ["s3:ObjectCreated:*"],
  "Filter": {"Key": {"FilterRules": [{"Name": "suffix", "Value": ".csv"}]}}
}]}

Ba ưu điểm khớp đúng với đề:

• Gần như tức thì — thường dưới một giây
• Không tốn gì khi không có tệp mới — không polling, không lịch
• Lọc được theo prefix và suffix, nên chỉ gọi Lambda cho tệp đúng loại

Nhớ hai điều kiện: Lambda cần resource-based policy cho phép s3.amazonaws.com gọi (Console tự thêm), và execution role cần quyền dynamodb:PutItem.

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

• C. Lambda poll bucket S3 — đi ngược hướng: phải chạy Lambda liên tục hoặc theo lịch để hỏi xem có tệp mới không. Tốn kém, có độ trễ, và phải tự nhớ đã xử lý tệp nào rồi.
• A. Cron job chạy Lambda theo lịch — cùng vấn đề với C: có độ trễ (chờ tới lần chạy tiếp theo), chạy vô ích khi không có tệp mới.
• B. CloudWatch Events "giám sát bucket S3" — EventBridge KHÔNG tự giám sát bucket. Muốn có sự kiện S3 trên EventBridge thì phải bật EventBridge notification cho bucket (hoặc bật CloudTrail data event). Cách này chạy được nhưng vòng vèo hơn so với S3 event notification gọi thẳng Lambda.

Ghi nhớ

Ba đích của S3 Event Notification: Lambda, SNS, SQS (và EventBridge nếu bật riêng).

Các loại sự kiện quan trọng: | Sự kiện | Khi nào | |---|---| | s3:ObjectCreated:* | tạo mới (Put, Post, Copy, CompleteMultipartUpload) | | s3:ObjectRemoved:* | xoá | | s3:ObjectRestore:* | khôi phục từ Glacier | | s3:ReplicationEvent:* | sự kiện sao chép |

Và nhớ giới hạn quan trọng: S3 event notification KHÔNG phát cho GetObject — không có cách nào bắt lượt đọc bằng cơ chế này. Muốn theo dõi lượt đọc thì dùng server access logging hoặc CloudTrail data event.

Đáp án

A và C.

• A — In-place deployment — triển khai tăng dần, thay thế phiên bản trên chính các instance đang có.
• C — Blue/green deployment — dùng Auto Scaling group để dựng fleet mới.

Vì sao đúng

CodeDeploy có đúng hai kiểu deployment, và đề mô tả cả hai:

A khớp với vế thứ nhất của đề — "incremental deployment... replaces existing versions in the EC2 instances": in-place cập nhật theo lô (OneAtATime, HalfAtATime, AllAtOnce) trên chính các instance đang chạy.

C khớp với vế thứ hai — "an Auto Scaling group is used to perform a deployment": blue/green trên EC2 hoạt động bằng cách sao chép Auto Scaling group hiện có, deploy lên bản sao, rồi chuyển traffic ở load balancer.

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

• B. "Pilot Light" và D. "Warm Standby" — đây là chiến lược khôi phục thảm hoạ (DR), không phải kiểu deployment. Chúng mô tả mức độ sẵn sàng của môi trường dự phòng ở Region khác: | Chiến lược DR | Đặc điểm | |---|---| | Backup & restore | chỉ có backup | | Pilot light | dữ liệu sao chép liên tục, compute ngủ | | Warm standby | môi trường thu nhỏ chạy 24/7 | | Multi-site active/active | đầy đủ ở mọi Region |
• E. "Cattle Deployment" — không phải thuật ngữ của AWS. Nó bắt nguồn từ ẩn dụ "pets vs cattle" trong DevOps (máy chủ là gia súc, thay được, không phải thú cưng) — một triết lý, không phải một kiểu deployment.

Ghi nhớ

Ba deployment configuration dựng sẵn, dùng cho cả in-place lẫn blue/green: | Cấu hình | Hành vi | |---|---| | CodeDeployDefault.OneAtATime | một instance mỗi lượt — an toàn nhất | | CodeDeployDefault.HalfAtATime | 50% mỗi lượt | | CodeDeployDefault.AllAtOnce | tất cả cùng lúc — nhanh nhất |

Và nhớ tách bạch hai nhóm thuật ngữ hay bị trộn trong đề: kiểu deployment (in-place, blue/green — CodeDeploy) và chiến lược DR (pilot light, warm standby — kiến trúc).