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

Câu 41 Development with AWS Services

You are storing bids information on your betting application and you would like to automatically expire DynamoDB table data after one week.

What should you use?

A
Use a Lambda function
B
Use DynamoDB Streams
C
Use DAX
D
Use TTL

Xem giải thích

Đáp án

D — Dùng TTL (Time To Live) của DynamoDB.

Vì sao đúng

DynamoDB TTL là cơ chế tự động xoá item hết hạn, và nó hoàn toàn miễn phí.

Cách dùng: chọn một thuộc tính chứa timestamp Unix (tính bằng giây), DynamoDB sẽ tự xoá item khi thời điểm đó đã qua:

import time
het_han = int(time.time()) + 7 * 24 * 3600      # một tuần kể từ bây giờ
table.put_item(Item={
    'bid_id': 'b-12345',
    'amount': 250,
    'ttl': het_han                               # thuộc tính TTL
})

Bốn điểm cần nhớ về TTL:

Miễn phí — không tốn write capacity cho việc xoá
Xoá diễn ra trong nền, thường trong 48 giờ kể từ lúc hết hạn (không tức thì)
Item hết hạn vẫn có thể xuất hiện trong Query/Scan cho tới khi bị xoá thật — nên nếu cần chính xác thì phải lọc thêm ở phía ứng dụng
Việc xoá xuất hiện trong DynamoDB Streams với userIdentity.principalId = "dynamodb.amazonaws.com", nên có thể lưu trữ item trước khi mất

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

A. Lambda function — tự viết lại TTL: phải lên lịch, tự quét bảng tìm item hết hạn, tự gọi DeleteItem. Quét bảng tốn read capacity, xoá tốn write capacity, và phải bảo trì mã. TTL làm cùng việc, miễn phí, không mã.
B. DynamoDB Streams — chỉ ghi lại thay đổi trên bảng để hệ khác tiêu thụ. Nó không xoá gì cả. (Nó bổ sung cho TTL, không thay thế.)
C. DAX — cache trong bộ nhớ đặt trước DynamoDB để tăng tốc đọc. Không liên quan gì tới vòng đời dữ liệu trong bảng.

Ghi nhớ

Yêu cầu định dạng của thuộc tính TTL — nơi hay sai nhất: | Yêu cầu | Chi tiết | |---|---| | Kiểu dữ liệu | Number (không phải String) | | Đơn vị | giây Unix epoch (không phải mili giây) | | Item không có thuộc tính đó | không bao giờ bị xoá | | Giá trị quá khứ hơn 5 năm | bị bỏ qua |

Sai lầm phổ biến nhất: lưu mili giây thay vì giây — khi ấy thời điểm hết hạn rơi vào năm 56.000 và item không bao giờ bị xoá.

Câu 42 Development with AWS Services

An organization has hosted its EC2 instances in two AZs. AZ1 has two instances and AZ2 has 8 instances. The Elastic Load Balancer managing the instances in the two AZs has cross-zone load balancing enabled in its configuration.

What percentage traffic will each of the instances in AZ1 receive?

A
15
B
20
C
25
D
10

Xem giải thích

Đáp án

D — 10%.

Vì sao đúng

Đây là phép tính trực tiếp từ định nghĩa của cross-zone load balancing.

Khi cross-zone load balancing được BẬT, load balancer coi toàn bộ instance ở mọi AZ như một tập duy nhất và chia đều cho từng instance:

AZ1: 2 instance
AZ2: 8 instance
────────────────
Tổng: 10 instance

Mỗi instance nhận: 100% / 10 = 10%

Nên mỗi instance ở AZ1 nhận 10%, và mỗi instance ở AZ2 cũng nhận 10%.

Để so sánh — khi cross-zone bị TẮT, traffic được chia đều giữa các AZ trước, rồi mới chia trong mỗi AZ:

AZ1 nhận 50%  →  chia cho 2 instance  →  mỗi instance 25%
AZ2 nhận 50%  →  chia cho 8 instance  →  mỗi instance 6,25%

Đây chính là vấn đề mà cross-zone sinh ra để chữa: khi số instance lệch nhau giữa các AZ, tắt cross-zone khiến AZ ít instance bị quá tải trong khi AZ nhiều instance lại nhàn rỗi.

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

C. 25% — đây là kết quả khi TẮT cross-zone. Đề nói rõ nó đang bật. Đây là bẫy chính của câu hỏi.
A. 15% và B. 20% — không khớp với phép tính nào trong hai trường hợp.

Ghi nhớ

Mặc định của cross-zone load balancing khác nhau theo loại load balancer — chi tiết bị hỏi rất nhiều: | Loại | Mặc định | Tắt/bật được | Phí truyền dữ liệu giữa AZ | |---|---|---|---| | ALB | luôn BẬT | ❌ ở mức LB (chỉnh được ở mức target group) | miễn phí | | NLB | TẮT | ✅ | có tính phí khi bật | | CLB | tắt (qua API/CLI) | ✅ | miễn phí |

Nhớ nhanh: ALB luôn cross-zone và miễn phí; NLB mặc định tắt và bật thì tốn tiền.

Câu 43 Chọn nhiều đáp án Troubleshooting and Optimization

A data analytics company processes Internet-of-Things (IoT) data using Amazon Kinesis. The development team has noticed that the IoT data feed into Kinesis experiences periodic spikes. The PutRecords API call occasionally fails and the logs show that the failed call returns the response shown below:

HTTP/1.1 200 OK
x-amzn-RequestId: <RequestId>
Content-Type: application/x-amz-json-1.1
Content-Length: <PayloadSizeBytes>
Date: <Date>
{
    "FailedRecordCount": 2,
    "Records": [
        {
            "SequenceNumber": "49543463076548007577105092703039560359975228518395012686",
            "ShardId": "shardId-000000000000"
        },
        {
            "ErrorCode": "ProvisionedThroughputExceededException",
            "ErrorMessage": "Rate exceeded for shard shardId-000000000001 in stream exampleStreamName under account 111111111111."
        },
        {
            "ErrorCode": "InternalFailure",
            "ErrorMessage": "Internal service failure."
        }
    ]
}

As an AWS Certified Developer Associate, which of the following options would you recommend to address this use case? (Select two)

A
Increase the frequency or size of your requests
B
Decrease the number of KCL consumers
C
Merge the shards to decrease the number of shards in the stream
D
Use an error retry and exponential backoff mechanism
E
Decrease the frequency or size of your requests

Xem giải thích

Đáp án

D và E.

D — Dùng cơ chế thử lại kèm exponential backoff.
E — Giảm tần suất hoặc kích thước request.

Vì sao đúng

Điểm mấu chốt nằm ở phản hồi trong đề: HTTP/1.1 200 OK nhưng FailedRecordCount: 2.

Đây là đặc điểm rất quan trọng của PutRecords: nó là API theo lô, và lô có thể thành công một phần. Mã HTTP 200 chỉ nói "lời gọi API hợp lệ và đã được xử lý" — không nói mọi bản ghi đều được ghi. Bản ghi hỏng mang mã lỗi ProvisionedThroughputExceededException, nghĩa là shard bị vượt hạn mức.

Hạn mức của mỗi shard: | Giới hạn | Giá trị | |---|---| | Ghi | 1 MB/giây hoặc 1.000 bản ghi/giây | | Đọc | 2 MB/giây, 5 lời gọi GetRecords/giây |

Đề nói dữ liệu IoT có spike theo chu kỳ — tức là những lúc cao điểm vượt hạn mức shard.

D — retry với exponential backoff. Đây là cách xử lý bắt buộc, và phải chỉ gửi lại những bản ghi thất bại, không gửi lại cả lô:

kq = kinesis.put_records(Records=ban_ghi, StreamName='iot-stream')
if kq['FailedRecordCount'] > 0:
    con_lai = [ban_ghi[i] for i, r in enumerate(kq['Records']) if 'ErrorCode' in r]
    time.sleep(delay); delay *= 2      # backoff tăng dần

Gửi lại cả lô sẽ ghi trùng những bản ghi đã thành công.

E — giảm tần suất hoặc kích thước request. Đây là cách giảm áp lực tức thời lên shard trong lúc spike.

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

A. Tăng tần suất hoặc kích thước request — đúng ngược lại. Shard đang quá tải; đẩy mạnh hơn chỉ làm tỷ lệ thất bại tăng.
B. Giảm số consumer KCL — consumer nằm ở phía đọc; lỗi trong đề nằm ở phía ghi. Không liên quan.
C. Merge shard để giảm số shard — sai hướng dứt khoát. Ít shard hơn = ít năng lực ghi hơn = hỏng nhiều hơn. Cách đúng khi bị vượt hạn mức là SplitShard để tăng số shard, hoặc chuyển sang on-demand mode để Kinesis tự co giãn.

Ghi nhớ

Ba API ghi của Kinesis và cách xử lý lỗi: | API | Lô | Thất bại một phần | |---|---|---| | PutRecord | 1 bản ghi | không — thành công hoặc lỗi | | PutRecords | tối đa 500 bản ghi / 5 MB | có — phải kiểm FailedRecordCount |

Bài học lớn nhất: HTTP 200 từ PutRecords KHÔNG có nghĩa là mọi bản ghi đã được ghi. Luôn kiểm FailedRecordCount và chỉ thử lại phần thất bại.

Câu 44 Chọn nhiều đáp án Deployment

You have created a Java application that uses RDS for its main data storage and ElastiCache for user session storage. The application needs to be deployed using Elastic Beanstalk and every new deployment should allow the application servers to reuse the RDS database. On the other hand, user session data stored in ElastiCache can be re-created for every deployment.

Which of the following configurations will allow you to achieve this? (Select two)

A
ElastiCache database defined externally and referenced through environment variables
B
ElastiCache bundled with the application source code
C
RDS database defined in .ebextensions/
D
ElastiCache defined in .ebextensions/
E
RDS database defined externally and referenced through environment variables

Xem giải thích

Đáp án

D và E.

E — RDS định nghĩa BÊN NGOÀI môi trường và tham chiếu qua biến môi trường.
D — ElastiCache định nghĩa trong .ebextensions/.

Vì sao đúng

Nguyên tắc quyết định: vòng đời tài nguyên phải khớp với vòng đời dữ liệu trong đó.

Tài nguyên	Dữ liệu	Nên đặt ở đâu
RDS	phải giữ qua mọi lần deploy	bên ngoài môi trường
ElastiCache	dựng lại được mỗi lần deploy	trong `.ebextensions/`

Vì sao RDS phải ở ngoài (E). Tài nguyên tạo bên trong môi trường Beanstalk bị xoá khi môi trường bị xoá hoặc dựng lại. Với blue/green (swap CNAME), môi trường mới còn có một CSDL trống hoàn toàn khác — swap xong người dùng rơi vào CSDL rỗng. Đặt RDS bên ngoài rồi truyền endpoint qua biến môi trường thì mọi môi trường dùng chung một CSDL:

option_settings:
  aws:elasticbeanstalk:application:environment:
    DB_HOST: prod-db.abc123.ap-southeast-1.rds.amazonaws.com

Vì sao ElastiCache nên ở trong (D). Đề nói rõ dữ liệu phiên tạo lại được. Đặt trong .ebextensions/ thì mỗi môi trường có cache riêng, tự sinh tự huỷ theo môi trường — sạch sẽ, không có trạng thái sót lại giữa các lần deploy:

# .ebextensions/elasticache.config
Resources:
  CumCache:
    Type: AWS::ElastiCache::CacheCluster
    Properties:
      Engine: redis
      CacheNodeType: cache.t3.micro
      NumCacheNodes: 1

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

A. ElastiCache ở bên ngoài — làm được, nhưng đề nói rõ dữ liệu phiên có thể tạo lại mỗi lần deploy, nên đưa ra ngoài là tự thêm việc quản lý mà không được gì.
C. RDS trong .ebextensions/ — vi phạm thẳng yêu cầu "mọi lần deploy phải dùng lại chính CSDL đó". Đây là lỗi nghiêm trọng nhất trong bốn phương án.
B. "ElastiCache bundled với mã nguồn ứng dụng" — vô nghĩa: ElastiCache là dịch vụ AWS, không phải thư viện đóng gói được vào mã.

Ghi nhớ

Quy tắc vàng của Elastic Beanstalk: CSDL production luôn nằm NGOÀI môi trường.

Nếu lỡ tạo bên trong rồi thì vẫn cứu được: chụp snapshot → tạo RDS độc lập từ snapshot → đổi DeletionPolicy của tài nguyên cũ sang Retain → cấu hình môi trường trỏ sang CSDL mới bằng biến môi trường.

Câu 45 Development with AWS Services

A SaaS company runs a HealthCare web application that is used worldwide by users. There have been requests by mobile developers to expose public APIs for the application-specific functionality. You decide to make the APIs available to mobile developers as product offerings.

Which of the following options will allow you to do that?

A
Use AWS Billing Usage Plans
B
Use API Gateway Usage Plans
C
Use AWS Lambda Custom Authorizers
D
Use CloudFront Usage Plans

Xem giải thích

Đáp án

B — Dùng API Gateway Usage Plans.

Vì sao đúng

Yêu cầu: phơi bày API công khai cho lập trình viên bên ngoài như những gói sản phẩm khác nhau.

Usage plan của API Gateway sinh ra đúng cho mô hình đó. Nó kết hợp ba thứ:

Thành phần	Vai trò
API key	định danh từng lập trình viên hoặc từng ứng dụng
Throttling	giới hạn tốc độ: `rateLimit` (req/giây) và `burstLimit`
Quota	hạn mức tổng theo ngày, tuần hoặc tháng

Nhờ vậy dựng được các gói sản phẩm rõ ràng:

Gói Free   : 10 req/giây,  10.000 request/tháng
Gói Basic  : 50 req/giây, 100.000 request/tháng
Gói Premium: 500 req/giây, không giới hạn

Client gửi API key trong header x-api-key, API Gateway đối chiếu với usage plan tương ứng và tự áp giới hạn.

Một lưu ý quan trọng về bảo mật: API key KHÔNG phải cơ chế xác thực. Nó dùng để định danh và đo lường, không để bảo vệ. Muốn xác thực thì dùng Cognito, Lambda authorizer hoặc IAM.

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

A. "AWS Billing Usage Plans" — không tồn tại. AWS Billing quản lý hoá đơn và chi phí của chính tài khoản bạn; nó không phơi bày API cho bên ngoài.
D. "CloudFront Usage Plans" — cũng không tồn tại. CloudFront là CDN; nó có cache policy và behavior, nhưng không có khái niệm usage plan hay API key theo kiểu này.
C. Lambda Custom Authorizer — đây là cơ chế xác thực và phân quyền (kiểm token, trả về IAM policy). Nó trả lời câu hỏi "người này có được gọi không", chứ không đo lường và giới hạn theo gói sản phẩm. Nó bổ sung cho usage plan, không thay thế.

Ghi nhớ

Ba tầng kiểm soát của API Gateway, thường dùng chồng lên nhau: | Tầng | Trả lời | |---|---| | Authorizer (Cognito / Lambda / IAM) | Bạn là ai? Có được vào không? | | Usage plan + API key | Bạn thuộc gói nào? Đã dùng bao nhiêu? | | Throttling (theo stage hoặc theo method) | Có đang gửi quá nhanh không? |

Và nhớ dứt khoát: API key là để đo lường, không phải để bảo mật.

Câu 46 Development with AWS Services

A retail company is migrating its on-premises database to Amazon RDS for PostgreSQL. The company has read-heavy workloads. The development team at the company is looking at refactoring the code to achieve optimum read performance for SQL queries.

Which solution will address this requirement with the least current as well as future development effort?

A
Set up Amazon RDS in the multi-AZ configuration with a single standby instance. Refactor the application code so that the queries use the standby instance endpoint
B
Configure Elasticache for Memcached to act as a caching layer for Amazon RDS. Refactor the application code so that the queries use the Elasticache for Memcached endpoint
C
Configure Elasticache for Redis to act as a caching layer for Amazon RDS. Refactor the application code so that the queries use the Elasticache for Redis endpoint
D
Set up Amazon RDS with one or more read replicas. Refactor the application code so that the queries use the endpoint for the read replicas

Xem giải thích

Đáp án

D — Thiết lập RDS với một hoặc nhiều read replica và sửa mã để truy vấn dùng endpoint của read replica.

Vì sao đúng

Đề mô tả tải nặng về đọc và đòi ít công sức phát triển nhất, cả hiện tại lẫn về sau.

Read replica là câu trả lời gọn nhất vì:

Chúng là PostgreSQL thật, nói cùng giao thức, cùng SQL, cùng driver
Sửa mã chỉ là đổi chuỗi kết nối cho các truy vấn đọc — không đổi một dòng SQL nào
Mở rộng về sau không cần sửa mã: thêm replica thì chỉ thêm địa chỉ vào cấu hình, và RDS còn có endpoint đọc chung tự cân bằng
Không có logic cache nào phải viết và duy trì

Vế "future development effort" là điểm phân biệt then chốt: thêm một replica là thao tác hạ tầng; thêm một tầng cache là thêm mã mãi mãi.

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

B và C. ElastiCache (Memcached hoặc Redis) — cache có tăng tốc đọc rất tốt, nhưng nó đòi công sức phát triển liên tục:
- Viết logic cache-aside: đọc cache trước, trượt thì đọc CSDL rồi ghi lại cache
- Xử lý vô hiệu hoá cache khi dữ liệu đổi — đây là phần khó nhất và là nguồn của rất nhiều lỗi dữ liệu cũ
- Xử lý cache trượt hàng loạt, cache đầy, node hỏng
Mỗi truy vấn mới thêm vào ứng dụng là thêm một lần phải quyết định chiến lược cache. Trái thẳng "least future development effort".
A. Multi-AZ và truy vấn vào standby instance — không làm được. Standby của Multi-AZ không nhận truy vấn nào cả; nó chỉ tồn tại để failover. Nó thậm chí không có endpoint riêng để mà trỏ vào. Đây là nhầm lẫn kinh điển giữa Multi-AZ và read replica.

Ghi nhớ

	Multi-AZ standby	Read replica
Sao chép	đồng bộ	bất đồng bộ
Phục vụ đọc	❌ không bao giờ	✅
Failover	tự động	promote thủ công
Mục đích	tính sẵn sàng cao	mở rộng đọc
Số lượng	1 standby	tới 15 (Aurora), 5 (RDS)

Câu thần chú: Multi-AZ để không chết; read replica để không chậm.

Câu 47 Troubleshooting and Optimization

A multi-national company has multiple business units with each unit having its own AWS account. The development team at the company would like to debug and trace data across accounts and visualize it in a centralized account.

As a Developer Associate, which of the following solutions would you suggest for the given use-case?

A
VPC Flow Logs
B
CloudWatch Events
C
CloudTrail
D
X-Ray

Xem giải thích

Đáp án

D — AWS X-Ray.

Vì sao đúng

Đề đòi ba thứ: gỡ lỗi, theo dấu (trace) dữ liệu xuyên nhiều tài khoản, và trực quan hoá tập trung.

X-Ray là dịch vụ theo dấu phân tán của AWS. Nó gắn một trace ID vào mỗi request và theo nó qua mọi thành phần, dựng ra service map cho thấy toàn bộ đường đi, độ trễ ở từng chặng và lỗi ở đâu.

X-Ray hỗ trợ theo dấu chéo tài khoản đúng như đề mô tả: các tài khoản nguồn gửi trace segment tới một tài khoản giám sát tập trung thông qua IAM role, và toàn bộ service map hiện ra ở một chỗ.

Tài khoản A (frontend)  ─┐
Tài khoản B (đơn hàng)  ─┼→ Tài khoản giám sát: service map + trace hoàn chỉnh
Tài khoản C (thanh toán)─┘

X-Ray tích hợp sẵn với API Gateway, Lambda, ECS, EC2, Elastic Beanstalk, SNS, SQS và DynamoDB.

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

A. VPC Flow Logs — ghi metadata luồng mạng (IP nguồn/đích, cổng, số byte, accept/reject). Nó cho biết gói tin có đi qua hay không, không cho biết request của ứng dụng đi qua những dịch vụ nào và chậm ở đâu. Sai tầng hoàn toàn.
B. CloudWatch Events (EventBridge) — định tuyến sự kiện, không theo dấu request. Nó phản ứng với sự kiện, không dựng được bản đồ đường đi của một request.
C. CloudTrail — ghi lời gọi API quản trị AWS (ai tạo gì, ai xoá gì). Nó là công cụ kiểm toán, không phải công cụ gỡ lỗi hiệu năng ứng dụng. CloudTrail không biết gì về luồng đi của một request bên trong ứng dụng của bạn.

Ghi nhớ

Bốn công cụ quan sát của AWS, mỗi cái trả lời một câu hỏi: | Công cụ | Trả lời | |---|---| | X-Ray | Request này đi qua đâu và chậm ở chặng nào? | | CloudWatch Logs | Ứng dụng đã ghi gì? | | CloudWatch Metrics | Số liệu đang ở mức nào? | | CloudTrail | Ai đã gọi API nào? |

Từ khoá nhận dạng X-Ray: trace, debug, service map, distributed, latency breakdown.

Câu 48 Development with AWS Services

An application is hosted by a 3rd party and exposed at yourapp.3rdparty.com. You would like to have your users access your application using www.mydomain.com, which you own and manage under Route 53.

What Route 53 record should you create?

A
Create a PTR record
B
Create a CNAME record
C
Create an Alias Record
D
Create an A record

Xem giải thích

Đáp án

B — Tạo bản ghi CNAME.

Vì sao đúng

Tình huống: ứng dụng nằm ở yourapp.3rdparty.com — một tên miền bạn không sở hữu và không kiểm soát. Bạn chỉ có www.mydomain.com trong Route 53.

CNAME là bản ghi trỏ một tên miền sang một tên miền khác:

www.mydomain.com.   CNAME   yourapp.3rdparty.com.

Trình duyệt phân giải www.mydomain.com → nhận về yourapp.3rdparty.com → phân giải tiếp → nhận IP. Bên thứ ba đổi IP lúc nào cũng được, bạn không phải làm gì.

Đây là lựa chọn duy nhất hợp lệ vì bạn không biết và không kiểm soát địa chỉ IP của họ.

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

C. Alias record — đây là bẫy chính, và cần hiểu chính xác giới hạn của nó. Alias là bản ghi riêng của Route 53 và chỉ trỏ được vào tài nguyên AWS: CloudFront, ELB, S3 website endpoint, API Gateway, Global Accelerator, hoặc một bản ghi khác trong cùng hosted zone. Nó không trỏ được vào một tên miền bên ngoài tuỳ ý.
D. A record — trỏ tên miền vào địa chỉ IPv4 cụ thể. Bạn không biết IP của bên thứ ba, và kể cả biết thì họ đổi IP là ứng dụng của bạn chết mà không ai báo trước.
A. PTR record — dùng cho phân giải ngược (từ IP tra ra tên miền), phục vụ chủ yếu cho việc kiểm tra danh tiếng máy chủ email. Hoàn toàn không liên quan.

Ghi nhớ

So sánh CNAME và Alias — bị hỏi rất nhiều: | | CNAME | Alias | |---|---|---| | Trỏ tới | bất kỳ tên miền nào | chỉ tài nguyên AWS | | Dùng ở đỉnh tên miền (mydomain.com) | ❌ không được | ✅ được | | Chi phí truy vấn | tính tiền | miễn phí | | Chuẩn | DNS chuẩn | riêng của Route 53 |

Quy tắc chọn nhanh: trỏ vào tài nguyên AWS ⇒ Alias (miễn phí, dùng được ở đỉnh tên miền). Trỏ ra ngoài AWS ⇒ CNAME. Và nhớ ràng buộc cứng của DNS: không đặt CNAME ở đỉnh tên miền — đó chính là lý do Alias ra đời.

Câu 49 Troubleshooting and Optimization

Your company has stored all application secrets in SSM Parameter Store. The audit team has requested to get a report to better understand when and who has issued API calls against SSM Parameter Store.

Which of the following options can be used to produce your report?

A
Use SSM Parameter Store Access Logs in S3 to get a record of actions taken by a user
B
Use SSM Parameter Store Access Logs in CloudWatch Logs to get a record of actions taken by a user
C
Use AWS CloudTrail to get a record of actions taken by a user
D
Use SSM Parameter Store List feature to get a record of actions taken by a user

Xem giải thích

Đáp án

C — Dùng AWS CloudTrail để lấy nhật ký các hành động của người dùng.

Vì sao đúng

Yêu cầu: biết ai đã gọi API nào lên SSM Parameter Store và khi nào. Đó chính xác là định nghĩa của CloudTrail.

CloudTrail ghi lại mọi lời gọi API tới Parameter Store — GetParameter, PutParameter, DeleteParameter, GetParametersByPath… — kèm đầy đủ ngữ cảnh:

{
  "eventTime": "2026-08-27T09:15:32Z",
  "eventSource": "ssm.amazonaws.com",
  "eventName": "GetParameter",
  "userIdentity": {"type": "IAMUser", "userName": "nguyen.van.a"},
  "sourceIPAddress": "203.0.113.45",
  "requestParameters": {"name": "/prod/db/password", "withDecryption": true}
}

Một chi tiết quan trọng cho kiểm toán bí mật: trường withDecryption: true cho biết ai đã thực sự giải mã một SecureString — không chỉ đọc tên tham số. Và nếu tham số dùng CMK riêng, KMS cũng ghi thêm sự kiện Decrypt riêng.

CloudTrail mặc định lưu 90 ngày trong Event History; muốn giữ lâu hơn thì tạo trail ghi vào S3.

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

A. "SSM Parameter Store Access Logs trong S3" và B. "…trong CloudWatch Logs" — cả hai đều không tồn tại. Parameter Store không có cơ chế access log riêng; mọi việc ghi nhận truy cập đều đi qua CloudTrail. Đây là kiểu bẫy đặt tên nghe rất hợp lý cho một tính năng không có thật.
D. "Tính năng List của Parameter Store" — DescribeParameters chỉ liệt kê các tham số đang tồn tại kèm siêu dữ liệu (tên, kiểu, ngày sửa cuối, người sửa cuối). Nó không có lịch sử ai đã đọc gì — mà đó mới là điều đội kiểm toán cần.

Ghi nhớ

Phân biệt ba loại log của AWS: | Loại | Ghi gì | |---|---| | CloudTrail | lời gọi API — ai làm gì, khi nào, từ đâu | | CloudWatch Logs | log do ứng dụng ghi ra | | Access log của dịch vụ (S3, ELB, CloudFront) | request ở tầng dữ liệu |

Nguyên tắc: câu hỏi có cụm "who called", "audit", "record of actions taken by a user" thì gần như luôn là CloudTrail.

Câu 50 Security

You are a developer for a web application written in .NET which uses the AWS SDK. You need to implement an authentication mechanism that returns a JWT (JSON Web Token).

Which AWS service will help you with token handling and management?

A
API Gateway
B
Cognito Sync
C
Cognito User Pools
D
Cognito Identity Pools

Xem giải thích

Đáp án

C — Cognito User Pools.

Vì sao đúng

Yêu cầu là một cơ chế xác thực trả về JWT và lo phần quản lý token.

Cognito User Pool là thư mục người dùng, và sau khi xác thực thành công nó phát ra ba JWT:

Token	Nội dung	Dùng để
ID token	thông tin người dùng (email, tên, thuộc tính tuỳ chỉnh)	biết người dùng là ai
Access token	phạm vi quyền (scope)	gọi API được bảo vệ
Refresh token	(không phải JWT)	lấy token mới khi hết hạn

User pool lo trọn phần "quản lý token" mà đề nhắc tới: ký token bằng khoá riêng, công bố JWKS để bên nhận xác minh chữ ký, đặt hạn sử dụng, và làm mới token qua refresh token (mặc định 30 ngày, chỉnh được).

Nó cũng có sẵn: đăng ký, xác minh email/SMS, quên mật khẩu, MFA, và liên kết với IdP bên ngoài (SAML, OIDC, Google, Facebook).

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

D. Cognito Identity Pools — đây là bẫy chính. Identity pool không phát JWT; nó làm việc ngược lại: nhận một danh tính đã được xác thực (JWT từ user pool, hoặc token từ Google/Facebook) rồi đổi lấy thông tin xác thực AWS tạm thời (access key, secret key, session token) qua STS. Nó cho phép truy cập S3, DynamoDB… chứ không phát token.
A. API Gateway — tiêu thụ JWT (qua Cognito authorizer hoặc Lambda authorizer) chứ không phát JWT. Nó là bên xác minh, không phải bên cấp.
B. Cognito Sync — dịch vụ đồng bộ dữ liệu người dùng giữa các thiết bị, và đã lỗi thời (AWS khuyến nghị dùng AWS AppSync thay thế). Không liên quan tới xác thực.

Ghi nhớ

	User Pool	Identity Pool
Là gì	thư mục người dùng	bộ đổi danh tính
Phát ra	JWT (ID + access token)	thông tin xác thực AWS tạm thời
Cho phép	đăng ký, đăng nhập, MFA, quên mật khẩu	gọi trực tiếp S3, DynamoDB…

Nhiều ứng dụng dùng cả hai nối tiếp nhau: user pool xác thực và phát JWT → identity pool đổi JWT lấy quyền AWS.

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

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ