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

Đáp án

A — Amazon DynamoDB.

Vì sao đúng

Đề nêu bốn yêu cầu, và DynamoDB khớp cả bốn:

1. Hàng nghìn terabyte dữ liệu
2. NoSQL được quản lý hoàn toàn
3. Độ trễ thấp
4. Lưu cặp khoá–giá trị

Điểm mạnh đặc trưng của DynamoDB: độ trễ không tăng theo kích thước dữ liệu. Bảng 1 TB và bảng 1 PB cho cùng độ trễ truy vấn — vì nó phân vùng dữ liệu và định tuyến trực tiếp tới đúng phân vùng qua partition key.

table.put_item(Item={'san_pham_id': 'SP-001', 'ten': 'Điện thoại', 'gia': 5000000})
table.get_item(Key={'san_pham_id': 'SP-001'})    # mili giây, bất kể bảng lớn thế nào

Và với quy mô petabyte, hai tính năng đáng dùng: on-demand mode (không phải tính capacity) và auto scaling cho provisioned mode.

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

• D. Amazon RDS — CSDL QUAN HỆ, không phải NoSQL. Nó có lược đồ cố định, và không mở rộng ngang được tới quy mô petabyte cho tải giao dịch. Với dữ liệu lớn, RDS chạm giới hạn dung lượng của một instance.
• C. Amazon ElastiCache — kho khoá–giá trị trong bộ nhớ, đúng một phần yêu cầu. Nhưng nó là cache, không phải CSDL bền vững: dữ liệu có thể mất, và lưu hàng nghìn terabyte trong RAM là hoàn toàn không khả thi về chi phí.
• B. Amazon S3 — kho object, không phải CSDL khoá–giá trị. Nó không hỗ trợ truy vấn theo thuộc tính, không có index, không cập nhật một phần được, và độ trễ hàng chục tới hàng trăm mili giây — cao hơn DynamoDB rất nhiều.

Ghi nhớ

Chọn CSDL theo nhu cầu — bảng này đáng thuộc: | Nhu cầu | Dịch vụ | |---|---| | NoSQL khoá–giá trị, độ trễ mili giây, quy mô lớn | DynamoDB | | Quan hệ, có lược đồ, JOIN, giao dịch phức tạp | RDS / Aurora | | Cache trong bộ nhớ | ElastiCache | | Kho object, tệp lớn | S3 | | Kho dữ liệu phân tích (OLAP) | Redshift | | Đồ thị, quan hệ nhiều bậc | Neptune | | Chuỗi thời gian | Timestream | | Sổ cái bất biến có xác minh mật mã | QLDB | | Tương thích MongoDB | DocumentDB | | Tương thích Cassandra | Keyspaces |

Nhận dạng nhanh trong đề: "NoSQL", "key-value", "fully managed", "low-latency", "thousands of terabytes" ⇒ DynamoDB.

Một lưu ý thiết kế quan trọng ở quy mô lớn: "schema-less" không có nghĩa là không cần thiết kế. Ngược lại, với DynamoDB bạn phải thiết kế khoá theo mẫu truy vấn ngay từ đầu, vì: | Hạn chế | Hệ quả | |---|---| | Không JOIN được | phải phi chuẩn hoá dữ liệu | | Khoá chính bất biến | đổi sau là phải tạo bảng mới và di trú | | Scan rất đắt ở quy mô lớn | mọi truy vấn nên dùng Query |

Và ở quy mô petabyte, hot partition là rủi ro lớn nhất: chọn partition key có nhiều giá trị phân bố đều, tránh giá trị theo thời gian (như ngay) vốn dồn toàn bộ ghi vào một phân vùng.

Đáp án

C và D.

• C — Access key ID
• D — Secret access key

Vì sao đúng

Đề nói rõ: các lập trình viên cần làm việc theo cách lập trình (programmatically) — tức là qua AWS CLI hoặc SDK, không phải qua Console.

Và với truy cập lập trình, AWS xác thực bằng một cặp gồm hai thành phần: | Thành phần | Vai trò | |---|---| | Access Key ID (AKIA...) | định danh — "bạn là ai" | | Secret Access Key | bí mật — "chứng minh đi" |

Cả hai đều bắt buộc — thiếu một là không ký được request:

# ~/.aws/credentials
[default]
aws_access_key_id = AKIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

Cách chúng hoạt động: SDK dùng secret access key để tạo chữ ký SigV4 cho mỗi request, và gửi kèm access key ID để AWS biết dùng khoá nào mà xác minh. Secret key không bao giờ được truyền đi — chỉ chữ ký được gửi.

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

• B. Console password — dùng để đăng nhập vào AWS Management Console qua trình duyệt. Nó hoàn toàn tách biệt với access key, và không dùng được cho CLI hay SDK.
• A. MFA device — lớp bảo mật bổ sung, rất nên có nhưng không bắt buộc cho truy cập lập trình. (Khi chính sách yêu cầu MFA cho API call, quy trình là gọi sts:GetSessionToken với mã MFA để lấy credential tạm thời — nhưng bản thân thiết bị MFA không thay thế được access key.)
• E. IAM user ID — định danh nội bộ của IAM user (AIDAJQABLZS4A3QDU576Q). Nó xuất hiện trong log và trong biến ${aws:userid}, nhưng không dùng để xác thực.

Ghi nhớ

Hai loại truy cập AWS — và mỗi loại có credential riêng: | Loại truy cập | Credential | Dùng ở đâu | |---|---|---| | Console | username + password (+ MFA) | trình duyệt | | Lập trình | access key ID + secret access key | CLI, SDK, API |

Một IAM user có thể có cả hai, một, hoặc không có cái nào — chúng độc lập hoàn toàn.

Điểm quan trọng nhất về secret access key: | Thành phần | Có xem lại được? | |---|---| | Access Key ID | ✅ luôn xem được trong Console | | Secret Access Key | ❌ CHỈ HIỆN MỘT LẦN lúc tạo |

Mất secret key thì không khôi phục được — phải tạo cặp mới và xoá cặp cũ.

Nhưng với đội lập trình viên từ xa như đề mô tả, access key dài hạn KHÔNG phải lựa chọn tốt nhất trong thực tế. Cách được khuyến nghị hiện nay là IAM Identity Center (SSO):

aws configure sso
aws sso login --profile congty
aws s3 ls --profile congty      # credential tạm thời, tự hết hạn

Với kỳ thi thì đáp án vẫn là C và D — đó là hai thành phần của truy cập lập trình cổ điển. Nhưng với hệ thống thật, hãy hướng tới loại bỏ hẳn access key dài hạn.

Đáp án

C — Lambda sẽ mở rộng ra (scale out) và thực thi các request ĐỒNG THỜI.

Vì sao đúng

Lambda tự động co giãn theo số sự kiện đến — đó là đặc tính cốt lõi của nó.

Với S3 event notification, mỗi ảnh được tải lên sinh một sự kiện riêng, và Lambda gọi một lần chạy riêng cho mỗi sự kiện:

100 ảnh tải lên cùng lúc → 100 sự kiện S3 → Lambda chạy 100 lần ĐỒNG THỜI

Không có hàng đợi tuần tự, không có gom lô — mỗi lần gọi là một môi trường thực thi độc lập.

Vì mỗi ảnh xử lý dưới một giây, concurrency cần thiết cũng thấp:

Concurrency = số sự kiện mỗi giây × thời lượng
            = 1.000 ảnh/giây × 1 giây = 1.000

Con số này vừa chạm hạn mức mặc định 1.000 mỗi Region — nên với đợt tải lớn hơn, cần cân nhắc xin tăng.

Một chi tiết quan trọng về burst concurrency: khi tải tăng đột ngột, Lambda không nhảy thẳng lên hạn mức tối đa. Nó khởi động một lượng burst ban đầu (500–3.000 tuỳ Region) rồi tăng dần 500 mỗi phút. Nên với đỉnh rất dốc như "một đợt bùng nổ ngắn", bạn vẫn có thể bị throttle dù chưa chạm hạn mức tổng.

Và vì S3 gọi Lambda bất đồng bộ, các sự kiện bị throttle sẽ được thử lại tự động — nên chúng không mất, chỉ chậm hơn.

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

• A. Lambda xử lý ảnh tuần tự theo thứ tự nhận được — sai hoàn toàn về mô hình: Lambda không có hàng đợi tuần tự cho nguồn bất đồng bộ như S3. Nó chạy song song, và không đảm bảo thứ tự nào.
• B. Lambda gom ảnh lại và xử lý theo lô trong một lần chạy — S3 event notification KHÔNG gom lô: mỗi object tạo ra một sự kiện riêng, và mỗi sự kiện là một lần gọi riêng. (Gom lô là đặc tính của nguồn poll-based như SQS và Kinesis, nơi có tham số BatchSize.)
• D. Lambda tự tăng bộ nhớ để có thêm CPU — Lambda KHÔNG tự đổi cấu hình bộ nhớ: đó là thiết lập cố định do bạn khai. Nó co giãn bằng cách chạy nhiều bản sao, không phải bằng cách làm mỗi bản sao mạnh hơn.

Ghi nhớ

Cách Lambda co giãn theo từng loại nguồn: | Nguồn | Cách co giãn | |---|---| | S3, SNS, EventBridge (bất đồng bộ) | một lần gọi mỗi sự kiện, chạy song song | | API Gateway (đồng bộ) | một lần gọi mỗi request | | SQS | thêm consumer dần, tối đa 1.000 (mỗi lô nhiều message) | | Kinesis, DynamoDB Streams | một consumer mỗi shard (× ParallelizationFactor) |

Các hạn mức liên quan: | Hạn mức | Giá trị | |---|---| | Concurrency mặc định | 1.000 mỗi Region (tăng được) | | Burst concurrency | 500–3.000 tuỳ Region, sau đó +500/phút | | Timeout | 15 phút |

Ba cách xử lý đợt bùng nổ như trong đề: | Cách | Chi tiết | |---|---| | Xin tăng hạn mức concurrency | nếu đỉnh thường xuyên vượt 1.000 | | Đặt SQS giữa S3 và Lambda | hàng đợi hấp thụ đỉnh, Lambda xử lý theo nhịp | | Reserved concurrency | bảo vệ các hàm khác khỏi bị hàm này chiếm hết |

Cách thứ hai đáng cân nhắc nhất cho xử lý ảnh: S3 → SQS → Lambda cho bạn kiểm soát tốc độ, thử lại có cấu hình, DLQ cho ảnh lỗi, và xử lý theo lô để giảm số lần gọi.

Và nhớ đặt on-failure destination cho gọi bất đồng bộ, nếu không ảnh xử lý lỗi sẽ biến mất sau ba lần thử:

aws lambda put-function-event-invoke-config --function-name resize-anh \
  --maximum-retry-attempts 2 \
  --destination-config '{"OnFailure":{"Destination":"arn:aws:sqs:...:anh-loi"}}'

Đáp án

A — Gọi GenerateDataKey để nhận khoá bản rõ và bản sao đã mã hoá của data key, rồi dùng khoá bản rõ để mã hoá dữ liệu.

Vì sao đúng

Con số quyết định nằm ngay trong đề: object 1 GB, tổng 150 GB.

kms:Encrypt có giới hạn cứng 4 KB — nên mã hoá trực tiếp bị từ chối ngay. Cách duy nhất là envelope encryption:

# 1. Xin data key — KMS trả về CẢ HAI dạng
r = kms.generate_data_key(KeyId='alias/khoa-cua-toi', KeySpec='AES_256')
khoa_ban_ro = r['Plaintext']        # mã hoá TẠI CHỖ
khoa_ban_ma = r['CiphertextBlob']   # lưu kèm dữ liệu

# 2. Mã hoá object 1 GB bằng AES cục bộ
du_lieu_ma = ma_hoa_aes(du_lieu, khoa_ban_ro)

# 3. Xoá khoá bản rõ khỏi bộ nhớ
del khoa_ban_ro

# 4. Lưu cả hai
luu(du_lieu_ma, khoa_ban_ma)

Ý tưởng cốt lõi: chỉ khoá 256-bit đi qua mạng tới KMS, còn 1 GB dữ liệu được mã hoá ngay trong ứng dụng. Vừa không vướng giới hạn kích thước, vừa nhanh hơn nhiều so với truyền dữ liệu qua mạng.

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

• B. Gọi Encrypt để mã hoá dữ liệu bằng CMK — vượt giới hạn 4 KB, lời gọi thất bại ngay với object 1 GB.
• D. Gọi Encrypt với CMK có imported key material — cùng vấn đề: nguồn gốc vật liệu khoá không thay đổi giới hạn 4 KB.
• C. Gọi GenerateDataKeyWithoutPlaintext rồi dùng khoá đã mã hoá để mã hoá dữ liệu — vô lý về mặt logic: một khoá đã bị mã hoá thì không dùng để mã hoá gì được — nó chỉ là dữ liệu vô nghĩa cho tới khi được giải mã. (API này có thật, dùng để tạo sẵn khoá cho hệ thống khác dùng sau — người tạo không cần thấy bản rõ.)

Ghi nhớ

Cách chọn nhanh: ≤ 4 KB ⇒ Encrypt. > 4 KB ⇒ GenerateDataKey + envelope encryption.

Ba nguyên tắc khi cài đặt:

1. Xoá khoá bản rõ khỏi bộ nhớ ngay sau khi dùng.
2. Lưu khoá đã mã hoá cùng dữ liệu — mất nó là mất dữ liệu vĩnh viễn.
3. Dùng encryption context để ràng buộc khoá với ngữ cảnh và có vết kiểm toán trong CloudTrail.

Với 150 GB chia thành 150 object, có một tối ưu quan trọng về hạn mức: đừng gọi GenerateDataKey cho từng object nhỏ nếu số lượng rất lớn — KMS có hạn mức request mỗi giây. AWS Encryption SDK với LocalCryptoMaterialsCache cho phép dùng lại một data key cho nhiều object trong giới hạn bạn đặt.

Và nếu đích đến là S3: SSE-KMS đã tự làm envelope encryption bên dưới — bạn chỉ chỉ định CMK, không phải viết đoạn mã này. Nhớ bật thêm BucketKeyEnabled để giảm số lời gọi KMS tới 99%.

Đáp án

A — appspec.yml.

Vì sao đúng

AppSpec file là tệp cấu hình của CodeDeploy — nó cho biết triển khai cái gì và chạy hook nào. Với Amazon ECS, nội dung của nó trỏ tới task definition và khai container nhận traffic:

version: 0.0
Resources:
  - TargetService:
      Type: AWS::ECS::Service
      Properties:
        TaskDefinition: "arn:aws:ecs:...:task-definition/ung-dung:5"    # ← cập nhật ở đây
        LoadBalancerInfo:
          ContainerName: "web"
          ContainerPort: 80
Hooks:
  - BeforeInstall: "arn:aws:lambda:...:function:chuan-bi"
  - AfterInstall: "arn:aws:lambda:...:function:kiem-tra"
  - AfterAllowTestTraffic: "arn:aws:lambda:...:function:kiem-thu-sau"
  - BeforeAllowTraffic: "arn:aws:lambda:...:function:chot-cuoi"
  - AfterAllowTraffic: "arn:aws:lambda:...:function:sau-trien-khai"

Để đẩy thay đổi qua CodeDeploy, lập trình viên cập nhật TaskDefinition trỏ tới revision mới (chứa image mới), rồi tạo deployment.

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

• C. buildspec.yml — tệp của AWS CodeBuild, khai các lệnh biên dịch và test. Nó chạy ở giai đoạn build, không phải triển khai.
• B. ebextensions.config — tệp cấu hình của Elastic Beanstalk, đặt trong thư mục .ebextensions/. Không liên quan tới ECS hay CodeDeploy.
• D. dockerrun.aws.json — tệp của Elastic Beanstalk chạy Docker, mô tả cách chạy container trong môi trường Beanstalk. ECS dùng task definition, không dùng tệp này.

Ghi nhớ

Bốn tệp cấu hình hay bị lẫn: | Tệp | Dịch vụ | Việc | |---|---|---| | appspec.yml | CodeDeploy | triển khai cái gì, hook nào | | buildspec.yml | CodeBuild | lệnh build và test | | .ebextensions/*.config | Elastic Beanstalk | tuỳ chỉnh môi trường | | dockerrun.aws.json | Elastic Beanstalk (Docker) | cách chạy container |

Định dạng AppSpec theo nền tảng: | Nền tảng | Định dạng | Nội dung | |---|---|---| | EC2 / On-premises | CHỈ YAML, tên appspec.yml, đặt ở gốc gói | files + hooks | | ECS | YAML hoặc JSON | task definition + container | | Lambda | YAML hoặc JSON | tên hàm, alias, version |

Dòng đầu đáng nhớ: với EC2, tệp bắt buộc tên appspec.yml và nằm ở thư mục gốc của gói triển khai — sai chỗ là CodeDeploy báo lỗi không tìm thấy.

Hook theo từng nền tảng: | Nền tảng | Hook | |---|---| | Lambda | BeforeAllowTraffic, AfterAllowTraffic (chỉ hai) | | ECS | thêm BeforeInstall, AfterInstall, AfterAllowTestTraffic | | EC2 in-place | ApplicationStop, BeforeInstall, AfterInstall, ApplicationStart, ValidateService |

Mẹo nhận dạng: AfterAllowTestTraffic chỉ có ở ECS; ApplicationStop/ApplicationStart chỉ có ở EC2.

Và với ECS, nhớ rằng CodeDeploy chỉ hỗ trợ blue/green — không có in-place. Nên phần thực sự phải chọn là deployment configuration (AllAtOnce, Canary, hay Linear).

Đáp án

B — Amazon ECS với Fargate launch type.

Vì sao đúng

Đề nêu hai dữ kiện, và cả hai đều chỉ về Fargate:

1. Workload rất biến động
2. Muốn được tính tiền theo TASK ĐANG CHẠY

Fargate tính tiền theo vCPU và bộ nhớ mà TASK sử dụng, theo giây — không phải theo instance:

EC2 launch type:  trả tiền cho INSTANCE, kể cả khi chúng chạy ở 20% công suất
Fargate:          trả tiền cho TASK, chỉ trong thời gian task thật sự chạy

Với workload biến động, khác biệt này rất lớn: bạn không phải giữ sẵn một cụm EC2 đủ lớn cho đỉnh tải, và không trả tiền cho phần năng lực nằm không giữa các đỉnh.

Và Fargate còn loại bỏ toàn bộ gánh nặng vận hành: | Việc | EC2 launch type | Fargate | |---|---|---| | Vá hệ điều hành | bạn làm | AWS làm | | Co giãn cụm | bạn cấu hình | không có cụm | | Chọn instance type | bạn tính | không cần | | Tính tiền | theo instance | theo task |

{
  "family": "ung-dung",
  "requiresCompatibilities": ["FARGATE"],
  "networkMode": "awsvpc",
  "cpu": "512",
  "memory": "1024",
  "containerDefinitions": [...]
}

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

• D. ECS với EC2 launch type — tính tiền theo instance, không theo task. Với workload biến động, bạn hoặc cấp thừa (lãng phí) hoặc cấp thiếu (task không chạy được).
• A. ECS Service với Auto Scaling và C. ECS Cluster với Auto Scaling — cả hai đều là cơ chế co giãn, không phải mô hình tính tiền. Chúng vẫn chạy trên EC2 launch type, nên vẫn trả tiền theo instance. (Và chúng dùng được kèm Fargate — Service Auto Scaling điều chỉnh số task, hoàn toàn tương thích.)

Hai phương án A và C là bẫy tốt vì chúng nghe như giải quyết được vấn đề "biến động", nhưng không chạm tới yêu cầu về cách tính tiền.

Ghi nhớ

So sánh hai launch type của ECS: | | Fargate | EC2 | |---|---|---| | Tính tiền | theo vCPU và RAM của TASK, theo giây | theo instance-giờ | | Quản lý hạ tầng | không có gì | vá, giám sát, co giãn cụm | | Network mode | bắt buộc awsvpc | bridge, host, awsvpc, none | | Placement strategy | không dùng được | ✅ | | GPU, instance type đặc thù | ❌ | ✅ | | Mật độ container cao | thấp hơn | cao hơn | | Chi phí khi tải đều và cao | cao hơn | thường rẻ hơn |

Cách chọn: | Đề nói | Chọn | |---|---| | "charged per running task", "highly variable", "no infrastructure management" | Fargate | | "cần GPU", "instance type đặc thù", "tải đều và cao" | EC2 | | "chạy được cả hai" | capacity provider trộn Fargate và EC2 |

Dòng cuối đáng biết: ECS capacity provider cho phép một service chạy trên cả Fargate lẫn EC2, với tỷ lệ bạn đặt — ví dụ nền tảng chạy trên EC2 (rẻ) và phần đỉnh tràn sang Fargate (linh hoạt).

Và Fargate Spot giảm thêm tới 70% chi phí cho workload chịu được gián đoạn — rất hợp với xử lý theo lô.

Đáp án

D — Amazon S3.

Vì sao đúng

Đề mô tả bằng đúng thuật ngữ kỹ thuật của S3: | Mô tả trong đề | Đặc điểm của S3 | |---|---| | "standards-based REST web service interface" | API REST qua HTTPS: GET, PUT, DELETE, HEAD | | "store objects based on keys" | kho OBJECT, mỗi object định danh bằng KEY |

S3 là object storage: mỗi object gồm key (đường dẫn định danh), dữ liệu, và metadata:

# REST API thuần
curl -X PUT https://kho-du-lieu.s3.ap-southeast-1.amazonaws.com/bao-cao/2026/q3.pdf   --data-binary @q3.pdf -H "Authorization: AWS4-HMAC-SHA256 ..."

# Hoặc qua SDK
s3.put_object(Bucket='kho-du-lieu', Key='bao-cao/2026/q3.pdf', Body=du_lieu)
s3.get_object(Bucket='kho-du-lieu', Key='bao-cao/2026/q3.pdf')

Chú ý: "thư mục" trong S3 chỉ là quy ước đặt tên — bao-cao/2026/q3.pdf là một key duy nhất, không phải cấu trúc thư mục thật.

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

• B. Amazon EFS — hệ thống tệp POSIX, truy cập qua giao thức NFS (mount như thư mục), không phải REST API. Nó dùng đường dẫn hệ thống tệp, không phải key.
• A. Amazon EBS — ổ đĩa khối gắn vào một EC2 instance. Nó cung cấp block device, không có API REST và không có khái niệm key.
• C. Amazon DynamoDB — có REST API và có khái niệm khoá, nên đây là bẫy đáng chú ý. Nhưng nó là CSDL NoSQL lưu ITEM (bản ghi có thuộc tính), giới hạn 400 KB mỗi item — không phải object storage cho tệp.

Ghi nhớ

Ba mô hình lưu trữ trên AWS: | Mô hình | Dịch vụ | Truy cập | Đơn vị | |---|---|---|---| | Object storage | S3 | REST API (HTTPS) | object + key | | File storage | EFS, FSx | NFS, SMB (mount) | tệp + đường dẫn | | Block storage | EBS, instance store | gắn như ổ đĩa | khối (block) |

Nhận dạng nhanh trong đề: | Đề nói | Chọn | |---|---| | "object", "key", "REST API", "bucket" | S3 | | "file system", "mount", "POSIX", "NFS" | EFS | | "block device", "volume", "attach to instance" | EBS | | "NoSQL", "key-value", "item", "attributes" | DynamoDB |

Vài đặc điểm của S3 đáng nhớ: | Đặc điểm | Giá trị | |---|---| | Kích thước object | 0 byte đến 5 TB | | Tải lên một lần | tối đa 5 GB (lớn hơn thì dùng multipart) | | Độ bền | 99,999999999% (11 số 9) | | Hiệu năng | 5.500 GET / 3.500 PUT mỗi giây MỖI PREFIX | | Số bucket | 100 mặc định (tăng được tới 1.000) |

Dòng hiệu năng đáng chú ý: giới hạn tính theo prefix, và số prefix không giới hạn — nên S3 mở rộng gần như vô hạn bằng cách rải key ra nhiều prefix.

Và với ứng dụng đang di trú như đề mô tả, S3 còn cho thêm: versioning, lifecycle rule (tự chuyển sang lớp rẻ hơn), event notification (kích hoạt Lambda khi có object mới), và mã hoá mặc định — những thứ mà kho lưu trữ tự dựng phải tự làm.

Đáp án

D — Amazon S3 và Amazon CloudFront.

Vì sao đúng

Đề liệt kê các loại nội dung, và tất cả đều là TĨNH: | Loại | Tĩnh? | |---|---| | HTML | ✅ | | Ảnh, video | ✅ | | JavaScript (client-side) | ✅ — chạy trên TRÌNH DUYỆT, không phải máy chủ |

Cụm "client-side scripts" là chìa khoá: JavaScript được tải xuống rồi chạy trên máy người dùng, nên máy chủ chỉ cần phục vụ tệp — không cần chạy mã gì.

Đó chính xác là những gì S3 + CloudFront làm, và đây là kiến trúc website tĩnh chuẩn của AWS:

Route 53 → CloudFront (CDN, TLS, cache) → S3 bucket (lưu tệp)

Và nó hoàn toàn serverless — không có máy chủ nào để vá hay co giãn, đúng yêu cầu của đề.

Một chi tiết quan trọng: S3 static website endpoint chỉ hỗ trợ HTTP, nên muốn HTTPS thì bắt buộc phải có CloudFront — đó là lý do đáp án gồm cả hai.

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

• B. AWS Lambda và API Gateway — kiến trúc cho API động, không phải cho website tĩnh. Dùng chúng để phục vụ tệp HTML và video là đắt hơn nhiều và chậm hơn — mỗi request tốn một lần gọi Lambda. (Chúng vẫn cần thiết nếu website có backend API, nhưng đề chỉ nêu nội dung tĩnh.)
• A. EC2 và ElastiCache — không serverless: phải nuôi máy chủ, vá lỗi, co giãn. Và ElastiCache là cache trong bộ nhớ cho ứng dụng, không phục vụ tệp cho trình duyệt.
• C. Amazon ECS và Redis — cũng không serverless, và cũng sai công cụ: container để chạy ứng dụng, Redis để cache dữ liệu — không cái nào là kho lưu trữ tệp web.

Ghi nhớ

Kiến trúc website tĩnh chuẩn trên AWS:

Route 53 (tên miền)
    ↓
CloudFront (chứng chỉ ACM ở us-east-1, OAC)
    ↓
S3 bucket RIÊNG TƯ

Ba điểm cần nhớ trong kiến trúc này: | Điểm | Chi tiết | |---|---| | Chứng chỉ ACM cho CloudFront | bắt buộc cấp ở Region us-east-1 | | Origin Access Control (OAC) | giữ bucket riêng tư, chỉ CloudFront đọc được | | Versioned URL | style-a1b2c3.css — làm mới cache miễn phí, không cần invalidation |

Hai loại endpoint của S3 — khác nhau ở chỗ rất quan trọng: | Endpoint | HTTPS | Chức năng website (index, error, redirect) | |---|---|---| | bucket.s3-website-<region>.amazonaws.com | ❌ | ✅ | | bucket.s3.<region>.amazonaws.com | ✅ | ❌ |

Nghĩa là không thể vừa có HTTPS vừa có chức năng website chỉ với S3 — CloudFront giải quyết cả hai.

Nhận dạng nhanh trong đề: | Nội dung | Kiến trúc | |---|---| | HTML, CSS, JS client-side, ảnh, video | S3 + CloudFront | | API động, xử lý dữ liệu | API Gateway + Lambda | | Cả hai | S3 + CloudFront cho tĩnh, API Gateway + Lambda cho /api/* |

Dòng cuối là kiến trúc phổ biến nhất cho ứng dụng web hiện đại — CloudFront định tuyến /api/* sang API Gateway và phần còn lại sang S3, tất cả dưới một tên miền duy nhất.

Và với dự án mới, AWS Amplify Hosting đóng gói sẵn toàn bộ kiến trúc này kèm CI/CD từ Git — gọn hơn nhiều so với tự dựng.

Đáp án

B — AWS Cloud9.

Vì sao đúng

Đề mô tả chính xác Cloud9: viết, chạy và gỡ lỗi ứng dụng CHỈ BẰNG TRÌNH DUYỆT, không cần cài hay bảo trì IDE trên máy.

Cloud9 là IDE chạy trên đám mây, và nó giải quyết đúng vấn đề của đề: | Vấn đề trong đề | Cloud9 | |---|---| | Lập trình viên mang thiết bị riêng | chỉ cần trình duyệt — Windows, Mac, Linux, Chromebook đều được | | Cần nhất quán về công cụ | môi trường giống hệt nhau cho mọi người | | Không muốn cài IDE cục bộ | không cài gì cả |

Môi trường Cloud9 có sẵn nhiều công cụ: | Công cụ | Chi tiết | |---|---| | AWS CLI, SAM CLI, Docker, Git | cài sẵn | | Nhiều runtime | Python, Node.js, Java, Go, C++, PHP… | | Gỡ lỗi tích hợp | breakpoint cho Lambda, Node.js, Python | | Cộng tác thời gian thực | nhiều người cùng sửa một tệp, có chat | | Credential tạm thời | không có access key nào nằm trên đĩa |

Dòng cuối đáng chú ý về bảo mật: Cloud9 tự cung cấp AWS managed temporary credentials của chính người đang đăng nhập — rất phù hợp khi tuyển nhiều người mới.

Và tự dừng sau 30 phút không hoạt động giúp chi phí thấp: bạn chỉ trả tiền EC2 cho thời gian thực sự làm việc.

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

• D. AWS CodeCommit — kho lưu trữ mã nguồn (Git). Nó là nơi lưu mã, không phải môi trường để viết, chạy và gỡ lỗi.
• A. AWS CodeDeploy — triển khai mã đã đóng gói lên EC2, ECS, Lambda. Không phải công cụ phát triển.
• C. AWS X-Ray — theo dấu và phân tích request qua các dịch vụ. Công cụ quan sát, không phải IDE.

Ghi nhớ

Vai trò từng dịch vụ trong bộ công cụ phát triển: | Dịch vụ | Việc | |---|---| | Cloud9 | IDE trên trình duyệt | | CodeCommit | lưu trữ mã nguồn (Git) | | CodeBuild | biên dịch, test, đóng gói | | CodeDeploy | triển khai | | CodePipeline | điều phối | | X-Ray | theo dấu và phân tích |

Nhận dạng nhanh: đề nói "write, run, debug", "just a browser", "without installing an IDE" ⇒ Cloud9.

Hai kiểu môi trường Cloud9: | | EC2 environment | SSH environment | |---|---|---| | Máy chủ | Cloud9 tự tạo EC2 | bạn tự chuẩn bị | | Tự tắt khi rảnh | ✅ (mặc định 30 phút) | ❌ | | Vòng đời | Cloud9 quản lý | bạn quản lý | | Dùng khi | mặc định, ít công sức nhất | phải làm việc trên máy có sẵn |

Vài lưu ý thực dụng:

• Cloud9 không tính phí riêng — chỉ trả tiền EC2 và EBS bên dưới.
• Muốn làm việc với tài nguyên trong private subnet, đặt môi trường vào đúng VPC đó.
• Ổ đĩa mặc định khá nhỏ — dự án lớn nên tăng dung lượng EBS ngay từ đầu.

(Ghi chú thời sự: từ giữa 2024, AWS ngừng nhận khách hàng mới cho Cloud9; các tài khoản đã dùng vẫn hoạt động. Với đội mới, AWS hướng người dùng sang CodeCatalyst Dev Environments hoặc AWS Toolkit với IDE cục bộ. Câu hỏi vẫn nằm trong phạm vi kỳ thi, nhưng với dự án thật thì nên biết lựa chọn hiện hành.)

Đáp án

C — Cài CloudWatch agent trên CẢ máy chủ on-premises LẪN EC2 instance.

Vì sao đúng

Đề yêu cầu thu thập metric mức hệ thống từ cả hai môi trường, một cách hiệu quả nhất.

Unified CloudWatch agent hoạt động trên cả EC2 lẫn máy chủ on-premises — nên bạn dùng một công cụ, một tệp cấu hình, một cách vận hành cho toàn bộ hạ tầng lai:

{
  "metrics": {
    "namespace": "HeThongLai",
    "append_dimensions": {"InstanceId": "${aws:InstanceId}"},
    "metrics_collected": {
      "mem": {"measurement": ["mem_used_percent"]},
      "disk": {"measurement": ["used_percent"], "resources": ["/"]},
      "cpu": {"measurement": ["cpu_usage_idle", "cpu_usage_iowait"]},
      "swap": {"measurement": ["swap_used_percent"]}
    }
  }
}

Khác biệt duy nhất giữa hai môi trường là cách cấp credential: | Môi trường | Credential | Chế độ agent | |---|---|---| | EC2 | instance profile | -m ec2 | | On-premises | IAM user + access key (hoặc IAM Roles Anywhere) | -m onPremise |

# Trên máy on-premises
amazon-cloudwatch-agent-ctl -a fetch-config -m onPremise \
  -c file:/opt/aws/amazon-cloudwatch-agent/etc/config.json -s

Và điểm quan trọng nhất về "metric mức hệ thống": CloudWatch KHÔNG tự có metric bộ nhớ và ổ đĩa cho EC2 — vì hypervisor không nhìn được vào bên trong hệ điều hành. Chỉ agent mới thu thập được chúng.

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

• B. Cài agent trên EC2 và dùng cron job trên máy on-premises — hai công cụ khác nhau cho cùng một việc: bạn phải tự viết và bảo trì script cron, tự xử lý lỗi và thử lại, tự đảm bảo định dạng metric khớp nhau. Trái yêu cầu "MOST efficiently".
• A. CloudWatch cho EC2 và script AWS CLI với put-metric-data cho phần còn lại — cùng vấn đề: tự dựng lại thứ agent làm sẵn. Và "CloudWatch cho EC2" một mình không có metric bộ nhớ và ổ đĩa.
• D. Dùng CloudWatch detailed monitoring cho cả hai — detailed monitoring chỉ áp cho EC2 (đổi chu kỳ metric từ 5 phút xuống 1 phút), và không tồn tại cho máy on-premises. Ngoài ra nó không thêm metric bộ nhớ hay ổ đĩa — chỉ tăng tần suất của các metric sẵn có.

Ghi nhớ

Metric nào cần agent — điều nhiều người ngạc nhiên: | Metric | Có sẵn trong CloudWatch | |---|---| | CPU utilization, network in/out, disk read/write ops | ✅ (từ hypervisor) | | Bộ nhớ đã dùng | ❌ CẦN AGENT | | Dung lượng đĩa còn trống | ❌ CẦN AGENT | | Số tiến trình, swap | ❌ cần agent |

Hai phiên bản agent: | | Unified CloudWatch agent | CloudWatch Logs agent (cũ) | |---|---|---| | Thu thập | log VÀ metric | chỉ log | | Nền tảng | Linux, Windows, on-premises | Linux | | Trạng thái | được khuyến nghị | đã ngừng phát triển |

Ba cách cấp credential cho máy on-premises — theo thứ tự nên ưu tiên: | Cách | Đặc điểm | |---|---| | SSM hybrid activation | máy nhận định danh mi-xxxxx, dùng role như EC2 | | IAM Roles Anywhere | dùng chứng chỉ X.509, không có access key | | IAM user + access key | cách cổ điển, có credential dài hạn phải bảo vệ |

Với hạ tầng lai, hai cách đầu đáng đầu tư — chúng loại bỏ hẳn access key dài hạn, và SSM còn cho thêm khả năng quản lý máy bằng Run Command và Patch Manager.

Và mẹo tiết kiệm chi phí: mỗi tổ hợp dimension là một custom metric riêng và một khoản phí riêng — nên chỉ khai những dimension thật sự cần, đừng thêm dimension có nhiều giá trị như ProcessId.