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

Đáp án

C — Dùng CloudFront signed URL để kiểm soát truy cập vào tệp.

Vì sao đúng

Đề mô tả rất cụ thể: một tệp duy nhất (bài nghiên cứu) cần chia sẻ với một nhóm xác định, và phải an toàn.

Signed URL là cơ chế đúng cho phạm vi đó. Nó tạo một URL có chữ ký, kèm các ràng buộc:

https://d123.cloudfront.net/nghien-cuu.pdf
  ?Expires=1735689600
  &Signature=<chu-ky>
  &Key-Pair-Id=<id-khoa>

Nguyên tắc chọn giữa signed URL và signed cookie rất rõ ràng:

Đề nói "a new research paper" — một tệp — nên signed URL là lựa chọn tương xứng.

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

• A. Signed cookies — làm được, nhưng quá nặng cho một tệp duy nhất: phải đặt ba cookie (CloudFront-Policy, CloudFront-Signature, CloudFront-Key-Pair-Id), phải xử lý domain và path của cookie, và người nhận phải truy cập qua trình duyệt hỗ trợ cookie. Signed URL gửi qua email là xong.
• B. Field-Level Encryption — mã hoá một số trường dữ liệu nhạy cảm trong request POST (số thẻ tín dụng, thông tin y tế) để chỉ ứng dụng đích giải mã được. Nó bảo vệ dữ liệu người dùng gửi lên, không kiểm soát quyền tải xuống.
• D. AWS WAF — lọc request theo quy tắc chung (IP, quốc gia, mẫu chuỗi, tần suất). Nó không phân biệt được cá nhân: không có cách nào dùng WAF để nói "chỉ 12 nhà nghiên cứu này được tải tệp này".

Ghi nhớ

Bộ công cụ bảo vệ nội dung của CloudFront: | Công cụ | Bảo vệ | |---|---| | Signed URL | một tệp, có hạn | | Signed cookie | nhiều tệp, có hạn | | Origin Access Control (OAC) | chặn truy cập thẳng vào S3, bắt đi qua CloudFront | | Geo restriction | chặn theo quốc gia | | WAF | lọc theo luật ở tầng ứng dụng |

Trong thực tế nên dùng kết hợp: OAC khoá bucket lại, signed URL kiểm soát ai tải được gì.

Đáp án

C — Conditional writes.

Vì sao đúng

Vấn đề: PutItem ghi đè item đang tồn tại có cùng khoá chính, gây mất dữ liệu âm thầm.

Conditional write thêm một điều kiện mà DynamoDB kiểm tra một cách nguyên tử trước khi ghi. Điều kiện không thoả thì lời gọi bị từ chối với ConditionalCheckFailedException, và không có gì bị ghi đè:

table.put_item(
    Item={'user_id': 'u-123', 'ten': 'Nguyễn Văn A'},
    ConditionExpression='attribute_not_exists(user_id)')   # chỉ ghi nếu CHƯA CÓ

Vài mẫu điều kiện hay dùng: | Điều kiện | Ý nghĩa | |---|---| | attribute_not_exists(pk) | chỉ tạo mới, không ghi đè | | attribute_exists(pk) | chỉ cập nhật, không tạo mới | | version = :v | optimistic locking — chỉ ghi nếu chưa ai sửa | | so_luong >= :n | ràng buộc nghiệp vụ |

Điểm quan trọng nhất: kiểm tra và ghi diễn ra nguyên tử trong một lời gọi. Nếu tự đọc rồi mới ghi (GetItem → kiểm tra → PutItem), hai tiến trình chạy song song vẫn có thể ghi đè nhau — đó chính là chỗ để lọt đua tranh.

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

• A. Batch writes — BatchWriteItem gửi tối đa 25 thao tác trong một lời gọi để giảm số round trip. Nó không hỗ trợ ConditionExpression chút nào, nên còn tệ hơn cho vấn đề này.
• B. Atomic counters — dùng UpdateItem với biểu thức SET dem = dem + :val để tăng giảm một số mà không cần đọc trước. Rất hữu ích cho bộ đếm, nhưng nó không ngăn ghi đè và không có tính điều kiện.
• D. Scan operation — thao tác đọc: quét toàn bộ bảng. Không liên quan gì tới việc ghi.

Ghi nhớ

Hai bài học: mặc định dùng UpdateItem thay PutItem, và BatchWriteItem không có điều kiện — đừng dùng nó cho dữ liệu quan trọng.

Đáp án

D — Access logging đang trỏ vào chính bucket đó, tạo ra vòng lặp làm bucket phình ra.

Vì sao đúng

Đây là lỗi cấu hình kinh điển của S3 server access logging, và nó tạo ra một vòng lặp tự nuôi:

1. Có request tới bucket        →  S3 ghi một tệp log VÀO CHÍNH BUCKET ĐÓ
2. Việc ghi tệp log đó          →  cũng là một request tới bucket
3. Request đó lại sinh ra log   →  ghi thêm một tệp log nữa
4. → quay lại bước 2, không dừng

Kết quả đúng như đề mô tả: không ai thêm tệp nào, mà dung lượng bucket vẫn tăng đều.

AWS cảnh báo rõ về điều này trong tài liệu và khuyến nghị luôn dùng một bucket riêng cho log:

aws s3api put-bucket-logging --bucket du-lieu-khach-hang \
  --bucket-logging-status '{
    "LoggingEnabled": {
      "TargetBucket": "kho-log-rieng",        ← BUCKET KHÁC
      "TargetPrefix": "du-lieu-khach-hang/"
    }}'

Kèm theo, bucket log nên có lifecycle policy chuyển log cũ sang Glacier và xoá sau một thời hạn — nếu không thì nó cũng phình ra vô hạn, chỉ chậm hơn.

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

• B. "Mã hoá object nên mỗi object được lưu hai lần" — sai về cơ chế. Mã hoá không nhân đôi dữ liệu; nó chỉ biến đổi nội dung tại chỗ. Kích thước object sau khi mã hoá gần như không đổi.
• C. "Bucket policy sai cho batch upload gây tăng trưởng theo cấp số nhân" — vô nghĩa: bucket policy chỉ cấp hoặc từ chối quyền, nó không tạo ra dữ liệu. Và đề nói rõ không có tệp mới nào được thêm vào.
• A. "Tấn công DDoS làm phình dung lượng bucket" — DDoS tạo ra lưu lượng request, không tạo ra dữ liệu lưu trữ (trừ khi kẻ tấn công có quyền ghi, mà khi đó vấn đề đã nghiêm trọng hơn nhiều). Điều thú vị: DDoS sẽ làm bucket phình — nhưng chính vì mỗi request sinh thêm một dòng log, tức là lại quay về nguyên nhân D.

Ghi nhớ

Quy tắc chung cho mọi loại log trên AWS: không bao giờ ghi log vào chính tài nguyên đang được ghi log. Áp dụng cho S3 access log, CloudTrail, ELB access log, VPC Flow Logs.

Và với bucket log, luôn đặt sẵn: | Việc | Vì sao | |---|---| | Bucket riêng | tránh vòng lặp | | Lifecycle policy | log cũ chuyển Glacier rồi xoá | | Prefix theo nguồn | dễ phân biệt log của bucket nào | | Quyền chặt | log là dữ liệu nhạy cảm |

Đáp án

A — VPC Flow Logs.

Vì sao đúng

Câu hỏi rất cụ thể: xác minh xem traffic có tới được subnet B hay không.

VPC Flow Logs ghi lại metadata của mọi luồng IP đi vào và đi ra khỏi các ENI trong VPC. Đây là công cụ duy nhất trả lời được câu hỏi đó:

2 123456789012 eni-abc123 10.1.0.5 10.2.0.10 443 51234 6 10 840 1690000000 1690000060 REJECT OK
                          ↑ nguồn  ↑ đích                                          ↑ QUYẾT ĐỊNH

Trường action ở cuối là thứ quan trọng nhất, và nó phân biệt được hai tình huống hoàn toàn khác nhau:

Bật flow log ở mức subnet cho đúng câu hỏi đang hỏi:

aws ec2 create-flow-logs --resource-type Subnet --resource-ids subnet-B \
  --traffic-type ALL --log-destination-type cloud-watch-logs \
  --log-group-name flow-logs --deliver-logs-permission-arn <arn-role>

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

• B. "Subnet logs" — không tồn tại. Không có dịch vụ hay tính năng nào tên như vậy. Việc ghi log traffic ở mức subnet chính là VPC Flow Logs với --resource-type Subnet.
• C. "BGP logs" — không tồn tại như một dịch vụ AWS. Thông tin BGP xem được qua describe-vpn-connections (trạng thái đường hầm, số route nhận được) và metric CloudWatch của VPN, nhưng đó là trạng thái phiên BGP, không phải log traffic tới một subnet.
• D. "VPN logs" — cũng không tồn tại như một loại log riêng. Site-to-Site VPN có CloudWatch metrics (TunnelState, TunnelDataIn/Out) và từ 2023 có VPN tunnel logs cho sự kiện IKE — nhưng cả hai đều nói về đường hầm, không nói traffic có tới được một subnet cụ thể hay không.

Ghi nhớ

Phạm vi bật được của VPC Flow Logs: | Mức | Phủ | |---|---| | VPC | mọi ENI trong VPC | | Subnet | mọi ENI trong subnet đó | | ENI | một network interface |

Hai giới hạn cần biết: flow log không ghi nội dung gói tin (chỉ metadata), và nó không bắt được một số loại traffic như DHCP, DNS tới Amazon DNS resolver, và metadata service 169.254.169.254.

Đáp án

B — EBS volume bị khoá theo Availability Zone.

Vì sao đúng

Đây là một ràng buộc cứng và rất cơ bản của EBS:

Một EBS volume chỉ gắn được vào EC2 instance nằm trong CÙNG một Availability Zone.

Trong đề, volume nằm ở us-east-1a còn instance mới ở us-east-1e — hai AZ khác nhau, nên không gắn được.

Lý do kỹ thuật: EBS volume được lưu trữ vật lý trong một AZ cụ thể, và độ trễ của EBS phụ thuộc vào việc nó ở gần instance. AWS không cho gắn xuyên AZ để đảm bảo đặc tính hiệu năng đó.

Cách chuyển volume sang AZ khác — phải đi qua snapshot:

# 1. Chụp snapshot (snapshot lưu trong S3, phạm vi Region)
aws ec2 create-snapshot --volume-id vol-0abc123 --description "chuyen AZ"

# 2. Tạo volume mới từ snapshot ở AZ đích
aws ec2 create-volume --snapshot-id snap-0def456 --availability-zone us-east-1e

# 3. Gắn vào instance
aws ec2 attach-volume --volume-id vol-moi --instance-id i-xxx --device /dev/sdf

Snapshot là chìa khoá vì nó được lưu trong S3 — phạm vi Region, không phải AZ. Từ snapshot có thể tạo volume ở bất kỳ AZ nào trong Region, và copy sang Region khác cũng được.

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

• C. "EBS volume bị khoá theo Region" — quá rộng. Nếu chỉ khoá theo Region thì us-east-1a và us-east-1e cùng Region us-east-1, và việc gắn đã thành công. Ràng buộc thật chặt hơn một bậc: theo AZ.
• A. "Volume được mã hoá" — mã hoá không ngăn việc gắn volume. Instance chỉ cần quyền dùng KMS key, và với khoá mặc định thì hoàn toàn trong suốt. Ngoài ra, mã hoá cũng không phải thứ phụ thuộc AZ.
• D. "Thiếu quyền IAM" — nếu vậy thì lỗi sẽ là UnauthorizedOperation, một thông báo rõ ràng khác hẳn. Và điều đó không giải thích được vì sao volume lại hiện ở trạng thái available sẵn sàng để gắn.

Ghi nhớ

Phạm vi các tài nguyên lưu trữ của AWS — bảng đáng thuộc: | Tài nguyên | Phạm vi | |---|---| | EBS volume | một AZ | | EBS snapshot | Region (lưu trong S3) | | Instance store | gắn cứng với host | | EFS | Region — mount được từ mọi AZ | | S3 bucket | Region | | AMI | Region (copy sang Region khác được) |

Cần lưu trữ chia sẻ xuyên AZ thì câu trả lời là EFS, không phải EBS. (Ngoại lệ: EBS Multi-Attach cho phép một volume io1/io2 gắn vào nhiều instance — nhưng vẫn trong cùng một AZ.)

Đáp án

B — Auto Scaling chỉ thêm 1 instance.

Vì sao đúng

Phép tính rất trực tiếp:

Maximum capacity : 3
Current capacity : 2
Scaling policy   : thêm 3 instance
─────────────────────────────────
Mong muốn : 2 + 3 = 5
Trần      : 3
Thực tế   : min(5, 3) = 3  →  chỉ thêm được 1

Maximum capacity là ranh giới cứng. Auto Scaling không bao giờ vượt qua nó vì một scaling policy — nó chỉ thêm được tới đúng mức trần rồi dừng.

Đây là cơ chế bảo vệ có chủ đích: max tồn tại để bạn không bị bất ngờ về chi phí khi một scaling policy phản ứng quá đà, hoặc khi có sự cố khiến metric tăng vọt bất thường.

Sự kiện trong lịch sử Auto Scaling sẽ ghi lại rõ ràng, đại ý: "Could not scale to desired capacity 5 because the maximum capacity is 3".

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

• A. "Thêm đủ 3 instance" — sẽ nâng tổng lên 5, vượt max. Không xảy ra.
• D. "Thêm 3 rồi sau đó scale down 2" — mô tả một hành vi không tồn tại. Auto Scaling không bao giờ vượt trần rồi sửa lại; nó chặn ngay từ đầu. (Có một ngoại lệ hẹp: trong lúc rebalancing giữa các AZ, ASG được phép tạm vượt max thêm 10% hoặc 1 instance — nhưng đó là hành vi khác, không phải do scaling policy.)
• C. "Không thêm instance nào, nhưng gợi ý đổi scaling policy" — Auto Scaling không đưa ra gợi ý cho ai cả. Nó thực thi trong giới hạn được phép và ghi sự kiện vào lịch sử.

Ghi nhớ

Ba tham số dung lượng của Auto Scaling group: | Tham số | Vai trò | |---|---| | Minimum | sàn cứng — không bao giờ xuống dưới | | Desired | mức mong muốn hiện tại — scaling policy thay đổi con số này | | Maximum | trần cứng — không bao giờ vượt qua |

Quy tắc: mọi thay đổi đều được kẹp vào khoảng [min, max]. Nếu ứng dụng thực sự cần nhiều hơn, phải nâng max — scaling policy không tự làm điều đó.

Bài học vận hành: đặt max quá thấp thì hệ thống không mở rộng nổi khi cần thật, và triệu chứng rất khó nhận ra nếu không xem lịch sử scaling — nên hãy đặt alarm khi desired chạm max.

Đáp án

B — Tạo tệp appspec.yml ở thư mục gốc của gói mã nguồn.

Vì sao đúng

Hai yêu cầu trong đề — đổi quyền cho tệp đã triển khai và xác minh deploy thành công — đều là những việc mà appspec.yml của CodeDeploy khai báo:

version: 0.0
os: linux
files:
  - source: /
    destination: /var/www/html

permissions:                          # ← đổi quyền cho tệp đã triển khai
  - object: /var/www/html
    owner: apache
    group: apache
    mode: 755
    type: [file, directory]

hooks:
  ValidateService:                    # ← xác minh deploy thành công
    - location: scripts/kiem-tra.sh
      timeout: 300
      runas: root

Ba điểm về vị trí và tên tệp — đề hỏi thẳng cả hai: | Yêu cầu | Chi tiết | |---|---| | Tên tệp | appspec.yml (EC2/on-premises) hoặc appspec.yaml/.json (ECS, Lambda) | | Vị trí | thư mục gốc của gói mã nguồn | | Dịch vụ đọc nó | CodeDeploy |

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

• C. buildspec.yml ở thư mục gốc — sai dịch vụ. buildspec.yml là tệp cấu hình của CodeBuild: nó khai các phase build, lệnh chạy, và artifact xuất ra. Nó không có khái niệm permissions hay lifecycle hook triển khai.
• A. buildspec.yml trong thư mục codebuild/ — sai cả tệp lẫn vị trí. buildspec.yml cũng phải nằm ở gốc (trừ khi khai đường dẫn khác trong cấu hình project).
• D. appspec.yml trong thư mục codebuild/ — đúng tệp nhưng sai vị trí. CodeDeploy chỉ tìm ở thư mục gốc; đặt chỗ khác thì deploy thất bại với lỗi AppSpec file cannot be found.

Ghi nhớ

Hai tệp cấu hình hay bị lẫn nhất trong bộ Code của AWS: | | buildspec.yml | appspec.yml | |---|---|---| | Dịch vụ | CodeBuild | CodeDeploy | | Nội dung | phase, lệnh build, artifact | files, permissions, hooks | | Vị trí | gốc (đổi được) | gốc (bắt buộc) |

Vòng đời hook của CodeDeploy trên EC2 — thứ tự đáng thuộc:

ApplicationStop → DownloadBundle → BeforeInstall → Install
→ AfterInstall → ApplicationStart → ValidateService

ValidateService là hook cuối, đúng chỗ để chạy kiểm thử xác nhận deploy thành công.

Đáp án

C — Tăng bộ nhớ của hàm.

Vì sao đúng

Đặc điểm nền tảng của Lambda: bạn không cấu hình CPU trực tiếp — CPU được cấp tỷ lệ thuận với bộ nhớ.

Với hàm CPU-bound, tăng bộ nhớ là cách duy nhất để có thêm sức tính toán — và thường không làm tăng chi phí, đôi khi còn giảm:

128 MB  × 10 giây = 1.280 MB-giây
1.024 MB × 1 giây = 1.024 MB-giây   ← nhanh gấp 10 lần VÀ rẻ hơn

Vì Lambda tính tiền theo GB-giây, hàm chạy nhanh gấp N lần với bộ nhớ gấp N lần có chi phí tương đương — nhưng độ trễ giảm mạnh. Trên mốc 1.769 MB, hàm còn dùng được đa luồng.

Công cụ nên biết: AWS Lambda Power Tuning chạy thử hàm ở nhiều mức bộ nhớ và vẽ biểu đồ chi phí – thời gian để tìm điểm tối ưu.

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

• D. "Tăng CPU của hàm" — Lambda không có thiết lập CPU. Đây là bẫy trung tâm: cấu hình duy nhất bạn chỉnh được là bộ nhớ.
• A. Tăng provisioned concurrency — giải quyết cold start bằng cách giữ sẵn môi trường ấm. Nó không làm hàm chạy nhanh hơn sau khi đã khởi động. Đề hỏi về hiệu năng của một hàm CPU-bound, tức là thời gian tính toán, không phải độ trễ khởi động.
• B. Tăng timeout — chỉ cho phép hàm chạy lâu hơn trước khi bị cắt. Nó không tăng tốc gì cả; thực tế nó đi ngược mục tiêu "ensure fast response time".

Ghi nhớ

Nguyên tắc thực dụng: đừng mặc định để 128 MB. Với hàm nặng tính toán, tăng bộ nhớ thường vừa nhanh hơn vừa không đắt hơn — hãy đo bằng Power Tuning thay vì đoán.

Đáp án

A — Bật tích hợp S3 và CloudWatch Logs cho CodeBuild.

Vì sao đúng

Đề cần hai thứ khác nhau, và mỗi thứ dùng một đích ghi log:

CodeBuild cho phép bật cả hai cùng lúc trong cấu hình project:

"logsConfig": {
  "cloudWatchLogs": {"status": "ENABLED", "groupName": "/aws/codebuild/du-an"},
  "s3Logs": {"status": "ENABLED", "location": "kho-log/codebuild", "encryptionDisabled": false}
}

Vì sao cần S3 cho vế Athena. Đây là điểm mấu chốt: Athena chỉ truy vấn được dữ liệu nằm trên S3, nó không đọc CloudWatch Logs. Nên muốn phân tích log build hỏng bằng SQL thì bắt buộc phải có bản trên S3.

Vì sao cần CloudWatch cho vế báo cáo. CodeBuild tự phát metric — Builds, SucceededBuilds, FailedBuilds, Duration — vào namespace AWS/CodeBuild. Dựng dashboard hoặc truy vấn GetMetricStatistics là ra ngay con số cho báo cáo hằng tuần.

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

• C. CloudTrail giao log về S3 — CloudTrail ghi lời gọi API (StartBuild, StopBuild, ai gọi, lúc nào). Nó không chứa log đầu ra của build — không có thông báo lỗi biên dịch, không có kết quả test. Vế Athena sẽ không có gì để phân tích.
• D. CloudWatch Events (EventBridge) — dùng để phản ứng với sự kiện build (gửi thông báo khi hỏng, kích hoạt bước tiếp theo). Nó không lưu trữ log và không sinh báo cáo.
• B. Tích hợp AWS Lambda — quá chung chung, và là tự viết lại thứ đã có sẵn: phải tự thu log, tự đẩy sang S3, tự tổng hợp số liệu. CodeBuild bật một cấu hình là xong.

Ghi nhớ

Metric dựng sẵn của CodeBuild trong namespace AWS/CodeBuild: | Metric | Đo | |---|---| | Builds | tổng số build | | SucceededBuilds / FailedBuilds | thành công / thất bại | | Duration | thời gian mỗi build | | DownloadSourceDuration, BuildDuration | thời gian từng phase |

Và nguyên tắc chung khi chọn nơi để log: cần truy vấn tức thì và đặt alarm ⇒ CloudWatch Logs; cần phân tích lịch sử dài bằng SQL ⇒ S3 + Athena. Bật cả hai khi cần cả hai.

Đáp án

A — Sự hiện diện của section Transform cho biết đây là template AWS Serverless Application Model (SAM).

Vì sao đúng

Transform: 'AWS::Serverless-2016-10-31' là dòng bắt buộc của mọi template SAM. Nó khai báo với CloudFormation: hãy chạy macro SAM để mở rộng template này trước khi triển khai.

Cơ chế:

Template SAM (ngắn gọn) → macro Transform → Template CloudFormation đầy đủ → triển khai

Ví dụ cho thấy SAM tiết kiệm bao nhiêu:

Transform: 'AWS::Serverless-2016-10-31'
Resources:
  HamXuLy:
    Type: AWS::Serverless::Function        # ← 8 dòng
    Properties:
      Handler: index.handler
      Runtime: nodejs20.x
      Events:
        Api: {Type: Api, Properties: {Path: /don-hang, Method: post}}

Macro SAM biến đoạn này thành hàng chục dòng CloudFormation: AWS::Lambda::Function, AWS::IAM::Role, AWS::ApiGateway::RestApi, AWS::ApiGateway::Deployment, AWS::Lambda::Permission…

SAM là phần mở rộng của CloudFormation, không phải công nghệ riêng. Bạn hoàn toàn trộn được tài nguyên SAM và tài nguyên CloudFormation thường trong cùng một template — điều rất hay dùng khi cần Cognito, SNS hay S3 bên cạnh Lambda.

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

• D. "Đại diện cho định nghĩa một hàm Lambda" — hàm được khai trong section Resources với type AWS::Serverless::Function. Transform chỉ khai báo macro cần chạy.
• B. "Là một CloudFormation Parameter" — Parameters là section hoàn toàn khác, dùng để nhận giá trị đầu vào lúc deploy.
• C. "Là một intrinsic function" — intrinsic function là các hàm dùng bên trong template: !Ref, !GetAtt, !Sub, !Join, !FindInMap… Transform là một section cấp cao nhất, không phải hàm.

Ghi nhớ

Các giá trị Transform thường gặp: | Giá trị | Tác dụng | |---|---| | AWS::Serverless-2016-10-31 | macro SAM | | AWS::Include | chèn nội dung từ tệp trên S3 | | AWS::LanguageExtensions | thêm hàm và cú pháp mở rộng |

Nhận dạng nhanh: thấy Transform: AWS::Serverless-* ⇒ đây là SAM. Và nhớ: SAM cuối cùng vẫn thành CloudFormation, nên mọi khái niệm của CloudFormation (stack, change set, drift, rollback) đều áp dụng.