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

Đáp án

B — Cài và cấu hình Kinesis Agent trên mỗi instance.

Vì sao đúng

Yêu cầu: gửi tệp log từ nhiều EC2 Linux tới Kinesis Data Streams, một cách tối ưu nhất.

Kinesis Agent là ứng dụng Java độc lập do AWS cung cấp, sinh ra đúng cho việc này: nó theo dõi tệp log và tự gửi bản ghi mới, chỉ cần cấu hình:

{
  "cloudwatch.emitMetrics": true,
  "flows": [{
    "filePattern": "/var/log/ung-dung/*.log",
    "kinesisStream": "log-bao-mat",
    "partitionKeyOption": "RANDOM",
    "dataProcessingOptions": [{"optionName": "LOGTOJSON", "logFormat": "COMMONAPACHELOG"}]
  }]
}

Những thứ agent lo sẵn mà bạn không phải viết: | Việc | Agent làm | |---|---| | Theo dõi tệp, xoay vòng tệp (log rotation) | ✅ | | Checkpoint — nhớ đã gửi tới đâu, không gửi trùng sau khi khởi động lại | ✅ | | Thử lại với exponential backoff khi bị throttle | ✅ | | Gộp bản ghi để tối ưu thông lượng | ✅ | | Tiền xử lý (parse log Apache, chuyển sang JSON) | ✅ | | Phát metric vận hành lên CloudWatch | ✅ |

Cài đặt cũng đơn giản: sudo yum install -y aws-kinesis-agent rồi sửa /etc/aws-kinesis/agent.json.

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

• D. Kinesis Producer Library (KPL) — thư viện Java để nhúng vào ứng dụng của bạn. Nó rất mạnh (aggregation, batching), nhưng đòi viết mã, và nó dành cho ứng dụng tự sinh dữ liệu, không phải để đọc tệp log có sẵn. Với việc thu tệp log thì Kinesis Agent chính là KPL đã được đóng gói sẵn.
• C. Cài AWS SDK và tự cấu hình gửi tệp — phải tự viết toàn bộ: theo dõi tệp, xử lý xoay vòng, checkpoint, retry, batching. Đây là viết lại Kinesis Agent bằng tay.
• A. Cron job thu log rồi gửi — tệ nhất: có độ trễ (chờ tới lần chạy tiếp theo), dễ gửi trùng hoặc sót nếu không tự làm checkpoint, và không có retry.

Ghi nhớ

Các cách đưa dữ liệu vào Kinesis, theo bối cảnh: | Cách | Dùng khi | |---|---| | Kinesis Agent | thu tệp log từ máy chủ — không viết mã | | KPL | ứng dụng Java tự sinh dữ liệu, cần thông lượng cao | | SDK (PutRecord/PutRecords) | tích hợp đơn giản, ngôn ngữ bất kỳ | | CloudWatch Logs subscription | log đã ở trong CloudWatch Logs | | Firehose | chỉ cần nạp vào S3/Redshift/OpenSearch |

(Kinesis Agent cũng gửi được vào Firehose, không chỉ Data Streams.)

Đáp án

A — Dùng Git credentials sinh từ IAM.

Vì sao đúng

Đề hỏi cách xác thực với CodeCommit qua HTTPS, và CodeCommit hỗ trợ đúng ba cơ chế:

Git credentials là lựa chọn đơn giản nhất cho HTTPS: sinh trong tab Security credentials của IAM user, rồi dùng như username/password thông thường:

git clone https://git-codecommit.ap-southeast-1.amazonaws.com/v1/repos/du-an
Username: nguyen-van-a-at-123456789012
Password: <mat-khau-do-IAM-sinh>

Ưu điểm: tương thích với mọi công cụ Git hiểu username/password — Git CLI, IDE, GUI client — không cần cài thêm gì. Rất hợp cho việc di trú một repository đã clone từ GitHub.

Điểm cần phân biệt: Git credentials KHÁC mật khẩu đăng nhập Console. Đó là một cặp thông tin xác thực riêng, chỉ dùng được với CodeCommit.

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

• D. Dùng access key ID và secret access key của IAM user trực tiếp — Git không hiểu access key. Muốn dùng chúng thì phải qua credential-helper:

  git config --global credential.helper '!aws codecommit credential-helper $@'
  git config --global credential.UseHttpPath true
  

  Phương án không nêu bước đó, nên như viết thì không hoạt động.
• C. Token bảo mật của GitHub — chỉ dùng được với GitHub. CodeCommit là dịch vụ hoàn toàn khác, xác thực bằng IAM.
• B. IAM Multi-Factor Authentication — MFA là lớp bảo vệ bổ sung khi đăng nhập, không phải cơ chế xác thực cho thao tác Git. Git không có bước nhập mã MFA.

Ghi nhớ

Chọn cách xác thực CodeCommit theo bối cảnh: | Bối cảnh | Nên dùng | |---|---| | Lập trình viên trên máy cá nhân, HTTPS | Git credentials | | Lập trình viên quen SSH | SSH key | | CI/CD (CodeBuild, EC2) | IAM role + credential-helper — thông tin xác thực tạm thời |

Và nhớ: dù dùng cách nào, quyền vẫn do IAM policy quyết định (codecommit:GitPull, codecommit:GitPush…). Cơ chế xác thực chỉ thay đổi cách bạn chứng minh danh tính.

Đáp án

A — Dùng Long Polling.

Vì sao đúng

Triệu chứng trong đề đã chỉ thẳng nguyên nhân: chi phí SQS tăng vọt trong khi client nhận về phản hồi rỗng.

Đó là đặc trưng của short polling (hành vi mặc định): lời gọi ReceiveMessage trả về ngay lập tức, kể cả khi hàng đợi rỗng. Consumer trong vòng lặp sẽ bắn ra hàng nghìn lời gọi rỗng — và SQS tính tiền theo số request API, không theo số message.

Long polling giữ kết nối chờ tới khi có message hoặc hết thời gian:

aws sqs set-queue-attributes --queue-url <url> \
  --attributes ReceiveMessageWaitTimeSeconds=20      # tối đa 20 giây

Con số cụ thể:

Short polling: ~3.600 request/giờ mỗi consumer
Long polling (20 giây): 180 request/giờ mỗi consumer
→ giảm khoảng 95% chi phí API

Hai lợi ích đi kèm: giảm tải cho consumer (không quay vòng vô ích) và giảm độ trễ — message vừa tới là được trả về ngay, không phải chờ vòng lặp sau.

Một điểm kỹ thuật nữa: short polling chỉ lấy mẫu một tập con các server của SQS, nên có thể trả về rỗng dù hàng đợi có message. Long polling quét toàn bộ.

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

• D. Tăng VisibilityTimeout — khoảng thời gian message bị ẩn SAU KHI đã được nhận, để consumer xử lý xong rồi xoá. Nó chống xử lý trùng, không giảm số lời gọi API và không liên quan tới phản hồi rỗng.
• C. Giảm DelaySeconds — DelaySeconds hoãn message mới trước khi chúng hiển thị. Giảm nó không ảnh hưởng tới số lời gọi rỗng của consumer.
• B. Dùng FIFO queue — đảm bảo thứ tự và xử lý đúng một lần, đổi lại thông lượng thấp hơn nhiều (300 msg/giây). Nó không giảm chi phí polling, và còn có thể đắt hơn (FIFO có giá cao hơn standard).

Ghi nhớ

AWS khuyến nghị bật long polling cho gần như mọi hàng đợi. Đặt ReceiveMessageWaitTimeSeconds=20 ở mức queue là xong — hoặc truyền WaitTimeSeconds ở từng lời gọi ReceiveMessage.

Đáp án

D — Network Load Balancer (NLB).

Vì sao đúng

Đề nêu ba yêu cầu, và cả ba đều chỉ về NLB:

Điểm mấu chốt là cách NLB hoạt động ở tầng 4. Với target type instance, NLB giữ nguyên IP nguồn của client — máy chủ Apache nhìn thấy IP thật trong REMOTE_ADDR, không cần đọc header nào cả:

Client (203.0.113.45:54321) ──→ NLB ──→ EC2 thấy nguồn = 203.0.113.45:54321

Đây là khác biệt căn bản với ALB: ALB là proxy ở tầng 7 — nó kết thúc kết nối của client và mở kết nối mới tới target. Instance chỉ thấy IP của ALB, nên buộc phải đọc X-Forwarded-For để biết client thật.

Vế cổng nguồn càng loại ALB dứt khoát: X-Forwarded-For chỉ mang IP, không mang cổng (trừ khi bật thêm X-Forwarded-Port, nhưng đó là cổng của listener, không phải cổng nguồn của client).

Và NLB được thiết kế cho quy mô cực lớn: độ trễ dưới 100 micro giây, IP tĩnh mỗi AZ, không cần làm nóng trước (pre-warm).

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

• C. Application Load Balancer — hoạt động ở tầng 7, là proxy nên luôn thay IP nguồn. Bắt buộc phải dùng X-Forwarded-For — đúng thứ đề cấm.
• B. Classic Load Balancer — công nghệ thế hệ cũ. Ở chế độ HTTP nó cũng là proxy (cần X-Forwarded-For); ở chế độ TCP nó giữ IP nhưng vẫn kém NLB về hiệu năng, và AWS không còn khuyến nghị dùng.
• A. "Elastic Load Balancer" — đây là tên gọi chung của cả họ (ALB, NLB, CLB, GWLB), không phải một loại cụ thể. Không phải câu trả lời.

Ghi nhớ

Ba trường hợp bắt buộc dùng NLB: cần IP nguồn thật, cần IP tĩnh, hoặc giao thức không phải HTTP.

(Lưu ý: với target type ip, NLB không giữ IP nguồn — chỉ target type instance mới giữ.)

Đáp án

C — ApplicationStop → BeforeInstall → ApplicationStart → ValidateService.

Vì sao đúng

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

ApplicationStop      ← dừng ứng dụng cũ
  ↓
*DownloadBundle*     ← CodeDeploy tải bundle (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 hook trong đáp án đúng theo đúng thứ tự đó.

Điểm hay bị nhầm nhất: ApplicationStop chạy ĐẦU TIÊN, trước cả BeforeInstall. Lý do rất hợp lý: phải dừng ứng dụng cũ trước khi ghi đè tệp của nó.

Và một hệ quả quan trọng của thứ tự này: ApplicationStop chạy script từ bản revision TRƯỚC ĐÓ, không phải từ bản đang deploy — vì bản mới còn chưa được tải về. Đây là nguyên nhân của một lỗi rất phổ biến: script ApplicationStop hỏng ở bản cũ 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.

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

• A và B. Đặt BeforeInstall trước ApplicationStop — sai thứ tự ở bước đầu tiên. Không thể chuẩn bị cài đặt khi ứng dụng cũ còn đang chạy và giữ tệp.
• D. Đặt ValidateService trước ApplicationStart — vô lý: không thể xác minh một dịch vụ chưa được khởi động.

Ghi nhớ

Bộ hook khác nhau 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 |

Ba bước không viết hook được vì CodeDeploy tự làm: DownloadBundle, Install, và AllowTraffic.

Đáp án

B — aws sts decode-authorization-message.

Vì sao đúng

Thông báo lỗi trong đề chứa một chuỗi dài mã hoá:

You are not authorized to perform this operation.
Encoded authorization failure message: 6h34GtpmGjJJUm946eDVBfzWQJk6z5GePbbGDs9Z2T8...

Chuỗi đó được mã hoá có chủ đích. Lý do: nó chứa chi tiết về policy đã từ chối request — thông tin nhạy cảm mà AWS không muốn tiết lộ cho người gọi nếu họ không có quyền xem.

Chỉ principal có quyền sts:DecodeAuthorizationMessage mới giải mã được:

aws sts decode-authorization-message --encoded-message 6h34GtpmGjJJUm946eDVBfzWQJk6z5GePbbGDs9Z2T8...

Kết quả là một khối JSON cho biết chính xác vì sao bị từ chối:

{
  "allowed": false,
  "explicitDeny": true,
  "matchedStatements": {
    "items": [{
      "statementId": "DenyProductionAccess",
      "effect": "DENY",
      "principals": {...}, "resources": {...}, "conditions": {...}
    }]
  },
  "failures": {...}
}

Ba thông tin quý nhất trong đó: explicitDeny (bị chặn bởi Deny tường minh hay chỉ thiếu Allow), matchedStatements (statement nào đã chặn), và conditions (điều kiện nào không thoả).

Không có công cụ này, gỡ lỗi phân quyền là đoán mò.

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

• C. aws iam decode-authorization-message — bẫy sát nhất. Lệnh có thật nhưng thuộc namespace sts, không phải iam. Gõ aws iam decode-authorization-message sẽ báo lỗi Invalid choice.
• D. aws kms decode-authorization-message — KMS quản lý khoá mã hoá; nó không có lệnh này. Chuỗi trong lỗi không phải ciphertext của KMS.
• A. "AWS Cognito Decoder" — không tồn tại. Cognito lo danh tính người dùng ứng dụng, hoàn toàn không liên quan.

Ghi nhớ

Điều kiện để dùng được: principal chạy lệnh phải có quyền sts:DecodeAuthorizationMessage:

{"Effect": "Allow", "Action": "sts:DecodeAuthorizationMessage", "Resource": "*"}

Bộ công cụ gỡ lỗi phân quyền IAM: | Công cụ | Dùng khi | |---|---| | sts decode-authorization-message | có encoded message trong lỗi | | IAM Policy Simulator | thử trước khi chạy thật | | --dry-run (EC2) | kiểm tra quyền không gây hậu quả | | CloudTrail | xem lời gọi bị từ chối và ngữ cảnh đầy đủ | | IAM Access Analyzer | tìm quyền thừa, sinh policy tối thiểu |

Đáp án

B — Dùng SNS để đẩy thông báo khi có đơn hàng mới, và cấu hình nhiều SQS queue nhận các thông báo đó.

Vì sao đúng

Đề nêu ba vấn đề của hệ thống hiện tại, và mô hình SNS + SQS fan-out giải quyết cả ba:

Đơn hàng mới → SNS topic ─┬→ SQS: kho hàng    → consumer riêng
                          ├→ SQS: thanh toán  → consumer riêng
                          └→ SQS: giao hàng   → consumer riêng

Vì sao phải có SQS ở giữa, không đăng ký consumer thẳng vào SNS. Đây là điểm then chốt cho vế "reliable":

• 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 consumer có thể chết, được sửa, rồi quay lại xử lý tiếp — không mất gì.
• Mỗi queue có DLQ riêng và tốc độ xử lý riêng.

Thêm nữa, mô hình này mở rộng dễ: thêm một hệ downstream chỉ là thêm một queue đăng ký vào topic — không sửa mã bên phát.

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

• A. Chỉ dùng nhiều SQS queue, vẫn polling — bên phát phải biết và gửi tới từng queue một, nên thêm hệ downstream là phải sửa mã. Và nó không bỏ được cơ chế polling mà đề muốn thay.
• D. SNS + Lambda — bỏ mất lớp đệm: Lambda bị throttle hoặc lỗi liên tục thì message có thể mất (SNS chỉ retry một số lần). Không đạt "reliable" bằng SQS.
• C. SNS → Kinesis Data Firehose — Firehose nạp vào đích lưu trữ (S3, Redshift, OpenSearch), gom theo lô ~60 giây, và không phải hàng đợi xử lý. Sai công cụ cho việc xử lý đơn hàng.

Ghi nhớ

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

Nguồn → SNS topic → nhiều SQS queue → nhiều consumer độc lập

Ghép hai cái lại được cả fan-out lẫn độ bền — đó là lý do mẫu này phổ biến đến vậy.

Đáp án

B — Tạo IAM Role cho EC2 (instance profile).

Vì sao đúng

Ứng dụng trên EC2 cần đọc tệp PDF từ S3. Cách chuẩn và an toàn nhất để cấp quyền đó là instance profile.

Khi gắn role vào instance, AWS SDK tự động lấy thông tin xác thực từ metadata service — không cần một dòng cấu hình nào trong mã:

import boto3
s3 = boto3.client('s3')                      # tự tìm thấy thông tin xác thực
pdf = s3.get_object(Bucket='hoa-don', Key='HD-2026-08.pdf')['Body'].read()

Policy hẹp tới đúng mức cần:

{"Effect": "Allow", "Action": "s3:GetObject",
 "Resource": "arn:aws:s3:::hoa-don/*"}

So sánh với các cách khác:

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

• D. Chạy aws configure trên instance — ghi access key tĩnh vào ~/.aws/credentials. Chạy được, nhưng đây chính là thứ instance profile sinh ra để thay thế: khoá nằm trên đĩa, không tự hết hạn, phải xoay vòng thủ công.
• C. EC2 User Data — script chạy lúc boot lần đầu, không phải cơ chế xác thực. Nếu ý là nhét khoá vào user data thì đó là cách cất bí mật tồi nhất: mọi tiến trình trên máy đọc được qua http://169.254.169.254/latest/user-data.
• A. CloudFormation — công cụ cung cấp hạ tầng. Nó tạo được IAM role và gắn vào instance, nhưng bản thân nó không phải cơ chế cấp quyền — thứ cấp quyền vẫn là role.

Ghi nhớ

Mỗi loại compute có cơ chế role riêng, và không loại nào cần access key: | Compute | Cơ chế | |---|---| | EC2 | instance profile | | Lambda | execution role | | ECS | task role | | EKS | IRSA / Pod Identity | | CodeBuild | service role | | On-premises | SSM hybrid activation |

Nên bật thêm IMDSv2 (yêu cầu token) để chống tấn công SSRF lấy thông tin xác thực từ metadata:

aws ec2 modify-instance-metadata-options --instance-id i-xxx --http-tokens required

Đáp án

A — cloudformation package rồi cloudformation deploy.

Vì sao đúng

Template có một hàm Lambda với mã nguồn nằm trên máy cục bộ. Nhưng CloudFormation không đọc được đường dẫn cục bộ — nó chỉ nhận URI của S3.

Nên quy trình luôn có hai bước:

Bước 1 — package: nén mã, tải lên S3, và sinh ra một template mới trong đó đường dẫn cục bộ đã được thay bằng URI S3:

aws cloudformation package \
  --template-file template.yaml \
  --s3-bucket kho-artifact-cua-toi \
  --output-template-file packaged.yaml

# Trước:  CodeUri: ./src
# Sau :   CodeUri: s3://kho-artifact-cua-toi/a1b2c3d4e5f6...

Bước 2 — deploy: tạo hoặc cập nhật stack từ template đã đóng gói:

aws cloudformation deploy \
  --template-file packaged.yaml \
  --stack-name ung-dung \
  --capabilities CAPABILITY_IAM

package xử lý được nhiều thuộc tính, không chỉ Lambda: CodeUri (Serverless Function), Code (Lambda Function), TemplateURL (nested stack), DefinitionUri (Serverless API), ContentUri (layer)…

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

• B và C. cloudformation zip — lệnh này không tồn tại. Việc nén là do package tự làm.
• C và D. cloudformation upload — cũng không tồn tại. Lệnh đúng để triển khai là deploy.

Namespace aws cloudformation có: package, deploy, create-stack, update-stack, delete-stack, describe-stacks, validate-template, create-change-set… — không có zip hay upload.

Ghi nhớ

Hai bộ lệnh tương đương: | AWS CLI | SAM CLI | |---|---| | aws cloudformation package | sam package | | aws cloudformation deploy | sam deploy |

Trong thực tế, sam deploy --guided gộp cả hai và hỏi các tham số cần thiết, rồi lưu vào samconfig.toml cho lần sau — cách gọn nhất.

Nguyên tắc cần nhớ: thuộc tính nào trỏ vào đường dẫn trên máy cục bộ thì luôn phải qua package trước khi deploy.

Đáp án

A — Tạo IAM role với policy AmazonDynamoDBReadOnlyAccess và gắn vào instance profile của EC2.

Vì sao đúng

Đây là kết hợp của hai thực hành tốt nhất:

1. Dùng role, không dùng khoá tĩnh. Instance profile cấp thông tin xác thực tạm thời, tự xoay vòng, và SDK tự tìm thấy chúng — không cần cấu hình gì trong mã.

2. Đặc quyền tối thiểu. Ứng dụng chỉ cần đọc, nên AmazonDynamoDBReadOnlyAccess là đúng phạm vi:

{"Effect": "Allow",
 "Action": ["dynamodb:GetItem", "dynamodb:BatchGetItem",
            "dynamodb:Query", "dynamodb:Scan", "dynamodb:DescribeTable"],
 "Resource": "*"}

(Chặt hơn nữa thì viết inline policy giới hạn Resource tới đúng bảng cần dùng — nhưng managed policy này đã đủ tốt và là câu trả lời đúng trong bốn phương án.)

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

• C. IAM user với access key, đặt khoá trong mã, "redeploy khi cần đổi khoá" — sai ở mọi mặt: khoá vào Git và ở lại trong lịch sử mãi mãi, không tự hết hạn, và việc xoay vòng đòi deploy lại ứng dụng. Đây là mẫu chống chỉ định rõ ràng nhất trong bảo mật AWS.
• B. IAM user với quyền Administrator — vi phạm nặng đặc quyền tối thiểu. Ứng dụng chỉ cần đọc một bảng mà lại được toàn quyền trên mọi dịch vụ AWS. Ứng dụng bị chiếm quyền là kẻ tấn công có toàn bộ tài khoản.
• D. Chạy bằng thông tin xác thực của root user — nguy hiểm nhất có thể. Root user không bị giới hạn bởi bất kỳ IAM policy nào, làm được cả những việc không ai khác làm được (đóng tài khoản, đổi gói hỗ trợ). AWS khuyến nghị tuyệt đối không tạo access key cho root, và bật MFA rồi cất kỹ thông tin đăng nhập.

Ghi nhớ

Thang bậc từ tệ nhất tới tốt nhất:

Root credentials  ←  tuyệt đối không
IAM user + Administrator  ←  quá rộng
IAM user + access key trong mã  ←  khoá tĩnh, vào Git
IAM user + access key trong biến môi trường  ←  vẫn là khoá tĩnh
IAM role gắn vào instance profile  ←  ĐÚNG
IAM role + policy giới hạn tới đúng tài nguyên  ←  TỐT NHẤT

Và nhớ mẹo làm bài: thấy "access key", "root credentials", hay "Administrator access" trong phương án ⇒ gần như chắc chắn loại được.