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

Đáp án

C — Zonal Reserved Instances.

Vì sao đúng

Đề nêu rõ nhu cầu: đặt trước năng lực (capacity reservation), ngoài phần tiết kiệm chi phí.

Reserved Instance có hai phạm vi, và chúng khác nhau ở đúng điểm này:

Regional RI chỉ là khoản giảm giá trên hoá đơn. Nó không giữ chỗ — nếu AZ hết năng lực loại instance đó, bạn vẫn không khởi động được instance, dù đã trả tiền RI.

Zonal RI thì có bảo đảm năng lực: AWS giữ sẵn chỗ cho bạn trong AZ đã chọn. Đổi lại là mất tính linh hoạt.

Với ứng dụng business-critical như trong đề, đảm bảo năng lực đáng giá hơn tính linh hoạt — đặc biệt trong các sự kiện quy mô lớn khi nhiều khách hàng cùng tranh năng lực.

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

• A. Regional RI — chỉ giảm giá, không đặt trước năng lực. Đây là hiểu nhầm phổ biến nhất về RI.
• D. "Cả hai đều đặt trước năng lực" — sai vì Regional RI không có tính năng này.
• B. "Không loại nào đặt trước năng lực" — sai vì Zonal RI có.

Ghi nhớ

Ba cơ chế liên quan tới năng lực và chi phí — đừng lẫn: | Cơ chế | Giảm giá | Đặt trước năng lực | |---|---|---| | Regional RI | ✅ | ❌ | | Zonal RI | ✅ | ✅ | | On-Demand Capacity Reservation | ❌ (trả giá On-Demand) | ✅ | | Savings Plans | ✅ (linh hoạt nhất) | ❌ |

Kết hợp thực dụng nhất hiện nay: Savings Plans cho phần giảm giá (linh hoạt hơn RI, áp cả EC2, Fargate và Lambda) cộng với On-Demand Capacity Reservation cho phần đảm bảo năng lực — hai thứ này chồng lên nhau được, và tách bạch hai mối quan tâm.

Đáp án

A — Tham số tên cluster chưa được cập nhật vào tệp /etc/ecs/ecs.config trong lúc bootstrap.

Vì sao đúng

Đây là cách ECS agent hoạt động: khi khởi động, nó đọc tên cluster từ tệp cấu hình /etc/ecs/ecs.config:

ECS_CLUSTER=MainCluster

Nếu tệp này không có hoặc không khai ECS_CLUSTER, agent mặc định đăng ký vào cluster tên default. Còn nếu user data ghi cứng MainCluster — hoặc CloudFormation template không truyền tham số xuống user data — thì mọi instance đều vào MainCluster, bất kể bạn nhập gì làm tham số. Đúng triệu chứng trong đề.

Cách sửa là truyền tham số xuống user data:

Parameters:
  TenCluster: {Type: String}
Resources:
  LaunchTemplate:
    Properties:
      LaunchTemplateData:
        UserData:
          Fn::Base64: !Sub |
            #!/bin/bash
            echo "ECS_CLUSTER=${TenCluster}" >> /etc/ecs/ecs.config

Điểm cần nhớ: ECS_CLUSTER phải được ghi trước khi ECS agent khởi động, và agent chỉ đọc tệp này lúc khởi động — sửa tệp trên instance đang chạy thì phải khởi động lại agent.

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

• B. "Phải build lại Docker image của ECS agent" — không cần. Cùng một agent làm việc với mọi cluster; tên cluster là cấu hình lúc chạy, không phải thứ nướng vào image.
• C. "EC2 thiếu quyền IAM để tham gia cluster khác" — nếu thiếu quyền thì instance không đăng ký được vào cluster NÀO CẢ, và log của agent sẽ báo AccessDenied. Đề nói rõ instance đăng ký thành công — chỉ là vào nhầm cluster.
• D. "Security group trỏ sai ECS cluster" — security group không có khái niệm cluster. Nó lọc traffic mạng theo IP, cổng và giao thức; hoàn toàn không tham gia vào việc agent chọn cluster.

Ghi nhớ

Danh sách kiểm khi ECS instance không xuất hiện trong cluster mong muốn:

1. /etc/ecs/ecs.config có dòng ECS_CLUSTER=<đúng tên> chưa?
2. User data có ghi tệp đó trước khi agent khởi động không?
3. Instance profile có policy AmazonEC2ContainerServiceforEC2Role chưa?
4. Instance có ra được endpoint ECS không? (NAT gateway hoặc VPC endpoint)
5. Xem log agent: /var/log/ecs/ecs-agent.log

Các biến cấu hình hay dùng khác trong ecs.config: ECS_ENABLE_TASK_IAM_ROLE, ECS_AVAILABLE_LOGGING_DRIVERS, ECS_ENABLE_CONTAINER_METADATA.

Đáp án

D — ElastiCache for Redis ở chế độ Cluster Mode.

Vì sao đúng

Chi tiết quyết định nằm ở cuối đề: "cache content regeneration is a costly activity" — dựng lại cache rất tốn kém. Nghĩa là mất cache là chuyện không chấp nhận được, nên cần một cache đáng tin cậy.

Redis có những đặc tính mà Memcached hoàn toàn không có:

Cluster mode bổ sung thêm: dữ liệu được chia (shard) trên nhiều node, mỗi shard có replica riêng. Một node chính hỏng thì replica của shard đó tự lên thay trong vài giây, và dữ liệu không mất — đúng điều đề cần.

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

• C. ElastiCache Memcached — bẫy chính. Memcached nhanh và đơn giản, nhưng không có sao chép, không có failover, không có snapshot. Mất một node là mất sạch dữ liệu trên node đó, và với việc dựng lại cache tốn kém thì đây là rủi ro không chấp nhận được.
• A. Tự cài Redis trên EC2 — làm được, nhưng không phải "fully-managed" như đề yêu cầu: bạn phải tự vá, tự cấu hình sao chép, tự dựng failover, tự sao lưu, tự giám sát. Đây chính là gánh nặng mà ElastiCache sinh ra để bỏ đi.
• B. Chuyển CSDL sang Redshift — hiểu sai hoàn toàn yêu cầu. Redshift là kho dữ liệu phân tích (OLAP) cho báo cáo và quét lớn. Nó không phải tầng cache và có độ trễ cao hơn RDS cho tra cứu từng bản ghi.

Ghi nhớ

Và nhớ thêm một bậc nữa: nếu cần cache vừa là kho dữ liệu chính (dữ liệu chỉ nằm ở đó, không dựng lại được từ đâu cả) thì câu trả lời là Amazon MemoryDB for Redis — nó có transaction log đa AZ và nhất quán mạnh, khác hẳn ElastiCache vốn vẫn là cache.

Đáp án

D — CodeBuild tự động co giãn; tổ chức không phải làm gì cho việc mở rộng hay chạy build song song.

Vì sao đúng

Đây là đặc điểm nền tảng của CodeBuild: nó là dịch vụ được quản lý hoàn toàn và không có máy chủ.

Mỗi lần build chạy trong một môi trường tạm thời, cô lập, hoàn toàn mới:

Build #1 → container riêng → chạy → huỷ
Build #2 → container riêng → chạy → huỷ    ← song song, không ảnh hưởng nhau
Build #3 → container riêng → chạy → huỷ

Bạn không quản gì cả: không cụm build, không Auto Scaling group, không hàng đợi. Cần bao nhiêu build song song thì CodeBuild cấp bấy nhiêu, trong giới hạn concurrent build của tài khoản (mặc định thường là 60, nâng được).

Và về chi phí: tính tiền theo phút build thực tế, không trả gì khi không có build nào chạy — khác hẳn một cụm Jenkins phải nuôi 24/7.

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

• A. "Bật CodeBuild Auto Scaling" — không tồn tại. Không có thiết lập nào như vậy vì không cần: co giãn là hành vi mặc định.
• C. "Chạy CodeBuild trong Auto Scaling group" — hiểu sai bản chất dịch vụ. CodeBuild không chạy trên instance của bạn; nó không phải phần mềm bạn cài. Không có gì để đưa vào ASG.
• B. Chọn instance type hiệu năng cao — đây là phương án gần đúng nhất và cần phân biệt kỹ. CodeBuild có cho chọn compute type (BUILD_GENERAL1_SMALL, MEDIUM, LARGE, 2XLARGE), và chọn loại mạnh hơn sẽ làm mỗi build nhanh hơn. Nhưng nó không liên quan tới việc mở rộng hay chạy song song — mà đó mới là điều đề hỏi. Số build song song không phụ thuộc vào compute type.

Ghi nhớ

Vài thiết lập của CodeBuild đáng biết: | Thiết lập | Tác dụng | |---|---| | Compute type | sức mạnh của mỗi build (vCPU, RAM) | | Concurrent build limit | trần số build song song — nâng được qua service quota | | Batch build | chạy nhiều build liên quan như một nhóm, có build graph khai phụ thuộc | | Cache (S3 hoặc local) | tái sử dụng phụ thuộc Maven/npm giữa các lần build — cách tăng tốc thật sự | | Timeout | mặc định 60 phút, tối đa 8 giờ |

Với Maven như trong đề, bật cache cho thư mục ~/.m2 thường rút ngắn thời gian build nhiều hơn hẳn so với việc nâng compute type.

Đáp án

A — Lưu S3 key của ảnh mỗi người vào bảng DynamoDB, dùng Lambda sinh pre-signed URL động, và ứng dụng web tham chiếu URL đó để hiển thị.

Vì sao đúng

Yêu cầu: bucket riêng tư, nhưng ứng dụng web vẫn hiển thị được ảnh một cách an toàn.

Pre-signed URL giải quyết trọn vẹn: nó là một URL có chữ ký và có hạn, cho phép tải đúng một object mà không cần mở bucket ra công khai.

def lay_url_anh(user_id):
    item = table.get_item(Key={'user_id': user_id})['Item']
    return s3.generate_presigned_url(
        'get_object',
        Params={'Bucket': 'anh-nhan-vien', 'Key': item['s3_key']},
        ExpiresIn=300)          # URL sống 5 phút

Mẫu kiến trúc ở đây là mẫu chuẩn cho mọi ứng dụng lưu tệp: S3 giữ nội dung, DynamoDB giữ con trỏ và metadata.

Ba lý do nó là lựa chọn đúng:

• Bucket vẫn riêng tư hoàn toàn — không có Block Public Access nào bị tắt
• URL hết hạn — link bị chia sẻ ra ngoài cũng chỉ dùng được trong vài phút
• Quyền kế thừa từ role sinh URL, nên kiểm soát tập trung

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

• B. Mở bucket công khai — vi phạm thẳng yêu cầu "private S3 bucket" và "secure way". Ảnh chân dung nhân viên là dữ liệu cá nhân; công khai chúng là sự cố bảo mật, không phải giải pháp.
• C. Lưu ảnh base64 trong DynamoDB — vướng giới hạn 400 KB mỗi item của DynamoDB, mà ảnh chân dung thường vượt qua. Base64 còn làm phình dữ liệu thêm ~33%. Và lưu tệp trong DynamoDB đắt hơn S3 rất nhiều lần.
• D. Lưu ảnh base64 trong RDS — làm được về mặt kỹ thuật nhưng là thiết kế tồi: CSDL quan hệ không phải nơi lưu tệp nhị phân. Nó làm phình kích thước CSDL, làm chậm backup và restore, tốn bộ nhớ đệm của CSDL, và đắt hơn S3 nhiều bậc.

Ghi nhớ

Mẫu chuẩn cho ứng dụng lưu tệp:

Client → API (xác thực) → Lambda
                            ├→ S3        (tệp thật)
                            └→ DynamoDB  (S3 key + metadata)

Đặc điểm của pre-signed URL: | Đặc điểm | Chi tiết | |---|---| | Thời hạn tối đa | 7 ngày (SigV4) | | Dùng cho | GetObject và PutObject (cho phép tải lên) | | Quyền | không vượt quá quyền của người tạo URL | | Tạo bằng | SDK, không cần gọi API tới AWS |

Mẹo cho tệp lớn: dùng pre-signed URL cho PutObject để client tải thẳng lên S3, không đi qua Lambda — tránh được giới hạn payload 6 MB và rẻ hơn nhiều.

Đáp án

D — Dùng header X-Forwarded-For.

Vì sao đúng

Vấn đề: khi có load balancer ở giữa, ứng dụng thấy IP nguồn là IP của load balancer, không phải IP của người dùng cuối. Kết nối TCP thực tế là từ ALB tới instance.

X-Forwarded-For là header chuẩn (RFC 7239) mà ALB tự động thêm vào mỗi request, chứa IP gốc của client:

X-Forwarded-For: 203.0.113.45

Nếu request đi qua nhiều proxy, header tích luỹ theo thứ tự:

X-Forwarded-For: 203.0.113.45, 198.51.100.10, 10.0.0.5
                 ↑ client thật   ↑ proxy 1      ↑ proxy 2

IP đầu tiên là client gốc — đây là quy tắc đọc quan trọng nhất.

ALB thêm ba header cùng lúc, và cả ba đều hữu ích: | Header | Nội dung | |---|---| | X-Forwarded-For | IP gốc của client | | X-Forwarded-Proto | giao thức gốc (http / https) | | X-Forwarded-Port | cổng gốc |

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

• C. X-Forwarded-From — header này không tồn tại. Tên đúng là X-Forwarded-**For**. Đây là bẫy đánh vần điển hình.
• A. Lấy IP client từ ELB access log — access log có chứa IP client, nhưng nó không giải quyết được yêu cầu: đề nói ứng dụng phải ghi thông tin request vào RDS lúc chạy. Access log được ghi ra S3 theo lô mỗi 5 phút, nên ứng dụng không lấy được IP tại thời điểm xử lý request.
• B. "Server access log" — mơ hồ và sai ngữ cảnh: thuật ngữ này thường chỉ S3 server access logging, chẳng liên quan gì tới ALB. Nếu hiểu là log của máy chủ web (nginx/Apache) thì nó cũng chỉ ghi IP của ALB — trừ khi được cấu hình đọc chính X-Forwarded-For, tức là quay về đáp án D.

Ghi nhớ

Hai cảnh báo khi dùng X-Forwarded-For trong thực tế:

• Client giả mạo được header này. Đừng dùng nó cho quyết định bảo mật trừ khi bạn kiểm soát toàn bộ chuỗi proxy — với ALB thì an toàn vì ALB ghi đè giá trị client gửi lên.
• Với framework web, thường phải bật chế độ tin proxy (server.forward-headers-strategy trong Spring Boot, ProxyFix trong Flask) thì request.remote_addr mới trả về IP thật.

Đáp án

A — aws ec2 monitor-instances --instance-ids i-1234567890abcdef0

Vì sao đúng

Câu này kiểm tra hai thứ: đúng lệnh và đúng tên tham số.

monitor-instances là lệnh bật detailed monitoring cho instance đã tồn tại, và tham số của nó là --instance-ids (số nhiều), nhận một hoặc nhiều instance ID:

aws ec2 monitor-instances --instance-ids i-1234567890abcdef0 i-0987654321fedcba
aws ec2 unmonitor-instances --instance-ids i-1234567890abcdef0   # tắt lại

Detailed monitoring đổi độ chi tiết của metric EC2:

Chu kỳ 1 phút quan trọng khi cần Auto Scaling phản ứng nhanh — với metric 5 phút, ASG có thể mất tới 5 phút mới nhận ra tải đã tăng.

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

• B. --instance-id (số ít) — tên tham số sai. AWS CLI dùng dạng số nhiều --instance-ids cho lệnh này và sẽ báo Unknown options.
• C và D. aws ec2 run-instances --monitoring ... — sai ngữ cảnh. run-instances tạo instance MỚI; đề nói bật monitoring cho các instance đội đang dùng, tức là đã tồn tại. (Về cú pháp, dạng đúng khi tạo mới là --monitoring Enabled=true — nên C còn sai thêm ở chỗ viết State=enabled.)

Ghi nhớ

Ba nơi bật detailed monitoring: | Cách | Khi nào | |---|---| | aws ec2 monitor-instances | instance đã tồn tại | | run-instances --monitoring Enabled=true | lúc tạo mới | | Launch template — Monitoring: {Enabled: true} | mọi instance do Auto Scaling tạo |

Cách thứ ba là cách nên dùng trong production: đặt trong launch template thì mọi instance mới tự có, không phải nhớ bật thủ công.

Và nhớ: detailed monitoring chỉ áp dụng cho metric của EC2 (CPU, mạng, đĩa). Metric bộ nhớ và dung lượng đĩa còn trống thì bật detailed monitoring cũng không có — chúng bắt buộc phải cài CloudWatch Agent.

Đáp án theo nguồn

B — Cập nhật giá trị stage variable từ tên stage test sang prod.

Vì sao nguồn chọn phương án này

Logic của khoá đáp án dựa trên một mẫu thiết kế cụ thể: dùng stage variable để trỏ tới backend khác nhau.

Trong mẫu này, integration của API không ghi cứng địa chỉ backend mà tham chiếu qua biến:

Integration URI: arn:aws:lambda:...:function:xu-ly:${stageVariables.alias}
hoặc:            http://${stageVariables.backendHost}/don-hang

Stage test có alias = test, stage prod có alias = prod. Khi bản test đã qua kiểm thử, "promote" nghĩa là trỏ biến sang phiên bản backend đã được duyệt — không cần đụng gì tới cấu hình API.

Đây là mẫu có thật và được AWS ghi trong tài liệu, đặc biệt hữu ích khi backend là Lambda alias: cùng một cấu hình API phục vụ nhiều phiên bản mã.

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

• A. Xoá stage prod rồi tạo lại cùng tên — rất nguy hiểm trong production: có khoảng thời gian API hoàn toàn không phục vụ, và mọi cấu hình gắn với stage (throttling, cache, usage plan, custom domain mapping) đều mất theo.
• D. "Deploy mà không chọn stage để cập nhật mọi stage" — không làm được. Mỗi deployment bắt buộc gắn với đúng một stage; không có cách nào cập nhật tất cả stage cùng lúc.
• C. — bị đánh dấu sai, nhưng xem ghi chú bên dưới.

Ghi nhớ về chất lượng câu hỏi

Phương án C — "promotion nên được thực hiện bằng cách deploy lại API sang stage prod" — thực ra mô tả đúng cách làm chuẩn trong đa số trường hợp, và nó bị đánh dấu là sai.

Sự thật là cả hai đều đúng, tuỳ kiến trúc:

Nếu đội đã thêm endpoint mới hoặc sửa integration, đổi stage variable là không đủ — thay đổi cấu hình chỉ có hiệu lực khi tạo deployment:

aws apigateway create-deployment --rest-api-id abc123 --stage-name prod

Đề không nói rõ thay đổi thuộc loại nào, nên câu hỏi mơ hồ. Hãy nắm cả hai cơ chế và nhận ra chúng phục vụ hai tình huống khác nhau.

Đáp án

D — Bật API Gateway caching.

Vì sao đúng

Đề nêu hai mục tiêu: giảm số lời gọi tới endpoint và cải thiện độ trễ. Và dữ liệu là danh sách phim nổi tiếng trong quá khứ — nội dung gần như không đổi, cùng một câu trả lời cho rất nhiều người.

Đó là mô tả hoàn hảo của một tải cache được.

Khi bật cache ở mức stage, API Gateway lưu phản hồi và trả thẳng từ cache mà không gọi backend:

Không cache: 100.000 request/ngày → 100.000 truy vấn RDS
Có cache   : 100.000 request/ngày →    vài trăm truy vấn RDS

Ba lợi ích cùng lúc, và chúng khớp đúng với hai mục tiêu của đề:

• Độ trễ giảm mạnh — trả từ bộ nhớ, không đi tới CSDL
• Số lời gọi backend giảm mạnh — đúng vế "reducing the number of calls made to endpoint"
• Giảm tải cho RDS, nên CSDL phục vụ tốt hơn cho phần còn lại

aws apigateway update-stage --rest-api-id abc123 --stage-name prod \
  --patch-operations \
    op=replace,path=/cacheClusterEnabled,value=true \
    op=replace,path=/cacheClusterSize,value=0.5 \
    op=replace,path=/*/*/caching/ttlInSeconds,value=3600

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

• A. Stage variable — cặp khoá–giá trị cấu hình theo từng stage, dùng để trỏ tới backend khác nhau giữa dev và prod. Không ảnh hưởng gì tới hiệu năng.
• B. Mapping template — biến đổi định dạng request và response bằng VTL. Nó thay đổi hình dạng dữ liệu, không giảm số lời gọi và không giảm độ trễ (thực tế còn thêm một chút xử lý).
• C. Kinesis Data Streams — dịch vụ cho luồng dữ liệu thời gian thực, dùng khi cần nạp khối lượng lớn sự kiện. Đây là API đọc dữ liệu tra cứu — hoàn toàn sai mô hình, và chèn Kinesis vào giữa còn làm kiến trúc phức tạp hơn mà chẳng giải quyết gì.

Ghi nhớ

Đặc điểm của API Gateway cache: | | Chi tiết | |---|---| | Kích thước | 0,5 GB → 237 GB | | TTL | mặc định 300 giây, tối đa 3.600 giây | | Phạm vi | theo stage, ghi đè được theo từng method | | Khoá cache | tuỳ chỉnh qua cache key parameters | | Vô hiệu hoá | header Cache-Control: max-age=0 | | Chi phí | theo giờ, không theo request |

Điểm cuối cùng đáng lưu ý về kinh tế: vì tính theo giờ, cache chỉ đáng khi lưu lượng đủ lớn. Với API vài trăm request mỗi ngày thì tiền cache còn đắt hơn tiền gọi Lambda.

Đáp án

D — Tạo custom metric trong CloudWatch, để instance gửi dữ liệu bằng PutMetricData, rồi tạo alarm dựa trên metric đó.

Vì sao đúng

Điểm kiến thức cốt lõi: EC2 KHÔNG phát metric bộ nhớ.

Lý do là kiến trúc: hypervisor nhìn instance từ bên ngoài, nên nó thấy được CPU, lưu lượng mạng và I/O đĩa. Nhưng mức dùng RAM là thứ chỉ hệ điều hành bên trong biết — hypervisor chỉ thấy bộ nhớ đã được cấp phát, không thấy bao nhiêu đang thực sự được dùng.

Nên muốn có metric bộ nhớ thì instance phải tự đo và tự báo cáo:

aws cloudwatch put-metric-data \
  --namespace "UngDung/EC2" \
  --metric-name "MemoryUtilization" \
  --dimensions AutoScalingGroupName=nhom-web \
  --value 78.5 --unit Percent

Trong thực tế thì không tự viết script — dùng CloudWatch Agent, vốn làm sẵn việc này:

{"metrics": {
  "append_dimensions": {"AutoScalingGroupName": "${aws:AutoScalingGroupName}"},
  "metrics_collected": {
    "mem": {"measurement": ["mem_used_percent"], "metrics_collection_interval": 60},
    "disk": {"measurement": ["used_percent"], "resources": ["/"]}
}}}

Có metric rồi thì tạo alarm và gắn vào scaling policy như bình thường.

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

• C. "Bật detailed monitoring để lấy dữ liệu RAM" — đây là bẫy chính. Detailed monitoring chỉ đổi CHU KỲ của metric từ 5 phút xuống 1 phút; nó không thêm metric mới nào. Bộ nhớ không có trong danh sách metric của EC2 ở cả hai chế độ.
• A. "PutAlarmData API" — API này không tồn tại. API đúng để gửi dữ liệu metric là PutMetricData. (Có PutMetricAlarm để tạo alarm, nhưng đó là việc khác.)
• B. Chuyển ứng dụng sang Lambda — cuộc tái kiến trúc lớn để né một vấn đề nhỏ. Và nó không giải quyết gì: Lambda cũng không cho bạn metric bộ nhớ theo thời gian thực để scale theo.

Ghi nhớ

Ba metric không có sẵn trên EC2 và bắt buộc cần CloudWatch Agent: | Metric | Tên trong agent | |---|---| | Bộ nhớ | mem_used_percent | | Dung lượng đĩa còn trống | disk_used_percent | | Swap | swap_used_percent |

Đây là câu hỏi kinh điển, và biến thể phổ biến nhất là: đặt alarm cho một metric chưa từng tồn tại — alarm sẽ nằm ở trạng thái INSUFFICIENT_DATA vĩnh viễn và không bao giờ kêu, mà cũng không báo lỗi gì.

Mẹo nhỏ nhưng quan trọng: nhớ khai append_dimensions với AutoScalingGroupName, nếu không Auto Scaling không dùng được metric đó cho scaling policy.