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

Đáp án

B — Lưu log trong S3 bucket và dùng Athena để chạy truy vấn SQL.

Vì sao đúng

Điểm mấu chốt rất dứt khoát: Athena CHỈ truy vấn được dữ liệu nằm trên Amazon S3.

Đó không phải một tuỳ chọn kiến trúc mà là giới hạn của dịch vụ. Athena đọc dữ liệu trực tiếp từ S3 bằng Presto, dùng lược đồ trong Glue Data Catalog, và không có driver nào để đọc EBS, EFS hay instance store.

CREATE EXTERNAL TABLE nhat_ky_web (
  ip STRING, thoi_gian STRING, phuong_thuc STRING,
  duong_dan STRING, ma_trang_thai INT, dich_den STRING
)
ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.RegexSerDe'
LOCATION 's3://nhat-ky-web/alb/';

-- Kiểm tra chuyển hướng có đúng không
SELECT duong_dan, dich_den, COUNT(*) AS so_luot
FROM nhat_ky_web
WHERE ma_trang_thai IN (301, 302, 307, 308)
GROUP BY duong_dan, dich_den
ORDER BY so_luot DESC;

Vì sao S3 cũng là nơi đúng để lưu log, ngoài chuyện Athena đòi hỏi: | Lợi ích | Chi tiết | |---|---| | Đích mặc định của log AWS | ALB, CloudFront, S3, VPC Flow Logs đều ghi thẳng vào S3 | | Rẻ | rẻ hơn nhiều so với ổ đĩa khối | | Bền | 99,999999999% | | Không giới hạn dung lượng | không phải mở rộng gì | | Lifecycle policy | tự chuyển sang Glacier hoặc xoá sau N ngày |

Với "web logs" cụ thể, thường không phải làm gì cả: bật access log của ALB hoặc CloudFront là chúng tự ghi vào S3 theo cấu trúc phân vùng sẵn.

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

Cả ba phương án còn lại đều sai vì cùng một lý do: Athena không đọc được các nơi lưu trữ đó.

• A. EBS — ổ đĩa khối gắn vào một instance. Athena không truy cập được, và bản thân EBS còn giới hạn dung lượng cũng như bị bó trong một AZ.
• D. EFS — hệ thống tệp chia sẻ qua NFS. Nhiều instance mount được, nhưng Athena vẫn không đọc được, và chi phí lưu trữ cao hơn S3 nhiều lần — rất lãng phí cho log.
• C. Instance store — tệ nhất: dữ liệu mất khi instance dừng hoặc bị huỷ. Lưu log ở đây là mất log ngay khi máy được thay thế, chưa nói tới chuyện Athena không đọc được.

Ghi nhớ

Nguyên tắc một dòng: Athena + S3 là một cặp không tách rời. Thấy Athena trong đề, đáp án đúng gần như luôn liên quan tới S3.

Bộ ba công cụ phân tích không máy chủ trên S3: | Dịch vụ | Việc | |---|---| | Athena | chạy SQL trên dữ liệu S3 | | Glue Crawler | tự phát hiện lược đồ, tạo bảng trong Data Catalog | | QuickSight | trực quan hoá kết quả |

Ba việc nên làm để truy vấn log rẻ và nhanh (Athena tính ~5 USD mỗi TB quét):

1. Phân vùng theo ngày — truy vấn một ngày chỉ quét một thư mục
2. Dùng định dạng cột (Parquet, ORC) thay vì CSV/JSON — giảm 80–90% dữ liệu quét
3. Nén (Snappy, Zstd)

Riêng với log của ALB và CloudFront, AWS có sẵn câu lệnh CREATE TABLE mẫu trong tài liệu — không cần tự viết regex SerDe, chỉ cần sửa đường dẫn S3.

Đáp án

B và D.

• D — AWS Elastic Beanstalk cho tầng ứng dụng.
• B — Amazon RDS với PostgreSQL cho tầng dữ liệu.

Vì sao đúng

Đề liệt kê ba việc mà dịch vụ được quản lý phải lo: cấp phát năng lực (capacity provisioning), cân bằng tải (load balancing), và tự động co giãn (auto-scaling).

Ba cụm từ đó là mô tả nguyên văn của Elastic Beanstalk trong tài liệu AWS. Bạn tải mã lên, Beanstalk tự dựng toàn bộ:

Beanstalk tự tạo và quản lý:
├── EC2 instance (Linux, đúng runtime)
├── Auto Scaling group        ← auto-scaling
├── Elastic Load Balancer     ← load balancing
├── Security group
└── CloudWatch alarm + health check

Bạn vẫn giữ toàn quyền kiểm soát các tài nguyên bên dưới nếu cần — khác với PaaS đóng kín.

RDS for PostgreSQL lo tầng CSDL, cũng theo hướng được quản lý: | Việc | RDS tự làm | |---|---| | Cài đặt, vá lỗi | ✅ | | Sao lưu tự động | ✅ (giữ tới 35 ngày) | | Multi-AZ failover | ✅ | | Read replica | ✅ | | Giám sát | ✅ |

Ứng dụng đang chạy PostgreSQL nên di trú gần như không phải sửa mã — chỉ đổi chuỗi kết nối.

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

• C. EC2 với PostgreSQL — tự cài CSDL trên máy ảo, tức là bạn phải tự vá, tự sao lưu, tự dựng replication, tự xử lý failover. Không phải dịch vụ được quản lý — trái yêu cầu.
• E. EC2 với Auto Scaling — có auto-scaling, nhưng bạn vẫn phải tự cài và cấu hình mọi thứ: hệ điều hành, runtime, ứng dụng, load balancer. Beanstalk làm chính việc đó thay bạn.
• A. Lambda với CloudWatch Events — không phù hợp với ứng dụng đang có: đề nói ứng dụng chạy trên máy chủ Linux, tức là một ứng dụng web hoặc dịch vụ chạy liên tục. Chuyển sang Lambda đòi viết lại toàn bộ theo kiến trúc sự kiện, và Lambda còn có giới hạn 15 phút mỗi lần chạy. CloudWatch Events chỉ để lên lịch, không phải cách phục vụ traffic web.

Ghi nhớ

Mức độ được quản lý của các lựa chọn tính toán: | Lựa chọn | Bạn quản gì | |---|---| | EC2 | hệ điều hành, runtime, ứng dụng, co giãn | | Elastic Beanstalk | chỉ mã ứng dụng | | ECS/Fargate | container image | | Lambda | chỉ hàm |

Nhận dạng nhanh trong đề:

• "capacity provisioning, load balancing, auto-scaling, health monitoring" ⇒ Elastic Beanstalk (đây là câu mô tả chuẩn của AWS)
• "di trú ứng dụng có sẵn, ít thay đổi nhất" ⇒ Beanstalk hoặc EC2
• "kiến trúc mới, chạy theo sự kiện" ⇒ Lambda

Beanstalk hỗ trợ sẵn: Java, .NET, PHP, Node.js, Python, Ruby, Go, và Docker — nên gần như ứng dụng Linux nào cũng đưa lên được.

Một lưu ý về CSDL trong Beanstalk: bạn có thể để Beanstalk tạo RDS instance như một phần của môi trường, nhưng đừng làm vậy cho production — khi xoá môi trường, CSDL cũng bị xoá theo. Hãy tạo RDS độc lập rồi truyền endpoint vào Beanstalk qua biến môi trường.

Đáp án

B — Lưu session state trong Amazon ElastiCache.

Vì sao đúng

Đề nêu ba yêu cầu: chịu lỗi, co giãn tự nhiên, và gián đoạn dịch vụ không được ảnh hưởng trải nghiệm người dùng.

Nguyên tắc nền tảng: tầng web phải phi trạng thái. Session phải nằm ở kho ngoài, để mọi instance đều phục vụ được mọi người dùng:

Client → ELB → EC2 #1, #2, #3… (thay thế được bất cứ lúc nào)
                  ↓
            ElastiCache (kho session dùng chung)

ElastiCache đáp ứng cả ba yêu cầu: | Yêu cầu | Cách đáp ứng | |---|---| | Chịu lỗi | Redis replication group + Multi-AZ tự động failover | | Co giãn tự nhiên | cluster mode thêm shard; đọc mở rộng bằng replica | | Không ảnh hưởng người dùng | instance web hỏng ⇒ session vẫn còn, người dùng không bị đăng xuất | | Hiệu năng | dưới mili giây — không làm chậm request |

Nên chọn Redis thay vì Memcached ở đây, vì chỉ Redis có nhân bản và tự động failover — đúng vế "fault tolerant".

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

• A. Bật sticky session trên load balancer — đây là bẫy chính, và nó đi ngược yêu cầu: sticky session ghim mỗi người dùng vào đúng instance đang giữ session của họ. Khi instance đó hỏng — hoặc khi Auto Scaling thu hồi nó lúc scale-in — session mất hoàn toàn và người dùng bị đăng xuất giữa chừng. Nó cũng cản trở cân bằng tải, vì traffic không phân bố đều được nữa.
• C. Lưu session trên S3 — quá chậm cho session: mỗi request phải gọi API S3, độ trễ hàng chục tới hàng trăm mili giây, trong khi session được đọc ở mọi request. S3 rất bền nhưng sai công cụ.
• D. Lưu session trong CloudFront — sai bản chất: CloudFront là CDN cache nội dung tĩnh ở edge, nó không phải kho lưu trữ và không có API để ứng dụng ghi/đọc dữ liệu session.

Ghi nhớ

Các lựa chọn lưu session ngoài, và khi nào chọn cái nào: | Kho | Độ trễ | Bền | Chọn khi | |---|---|---|---| | ElastiCache Redis | thấp nhất | vừa (bật persistence được) | cần nhanh nhất | | DynamoDB | mili giây | rất bền, đa AZ | cần bền, có TTL, không quản lý | | RDS | cao hơn | bền | quá nặng cho session |

Cả hai lựa chọn đầu đều đúng cho đề này; Redis thắng khi đề nhấn mạnh hiệu năng, DynamoDB thắng khi đề nhấn mạnh độ bền hoặc không muốn vận hành gì.

Ba thứ không bao giờ dùng làm kho session:

• Bộ nhớ/ổ đĩa cục bộ của instance — mất khi instance được thay
• Instance store — mất khi instance dừng
• Sticky session làm giải pháp duy nhất — không sống sót qua sự cố instance

(Sticky session vẫn hữu ích như tối ưu bổ sung khi đã có kho session ngoài: nó giúp tận dụng cache cục bộ và giảm số lần đọc từ kho. Nhưng nó không thay thế được kho chia sẻ — và câu hỏi kiểu này luôn hỏi về cái thay thế, không phải cái bổ sung.)

Đáp án nguồn

A — Dùng AWS Certificate Manager (ACM) để cung cấp giao tiếp TLS cho thiết bị IoT, và triển khai chứng chỉ X.509 trong môi trường IoT.

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

Đáp án nguồn ở câu này rất khó bảo vệ, và phương án B mới mô tả đúng cách AWS làm việc này.

Lý do: ACM không cấp và không triển khai chứng chỉ cho thiết bị IoT. ACM cấp chứng chỉ máy chủ TLS công cộng cho tên miền bạn sở hữu, và chỉ gắn được vào ELB, CloudFront, API Gateway và vài dịch vụ AWS khác. Nó không có cơ chế nào để phát chứng chỉ danh tính cho hàng nghìn thiết bị, và bạn không tải được private key của chứng chỉ ACM công cộng ra để nạp vào thiết bị.

Trong khi đó, AWS IoT Core có CA riêng và cấp chứng chỉ X.509 cho từng thiết bị — đó là cơ chế xác thực gốc của dịch vụ:

# IoT Core tự tạo chứng chỉ và cặp khoá cho một thiết bị
aws iot create-keys-and-certificate \
  --set-as-active \
  --certificate-pem-outfile thiet-bi.cert.pem \
  --public-key-outfile thiet-bi.public.key \
  --private-key-outfile thiet-bi.private.key

# Gắn policy và gắn vào "thing"
aws iot attach-policy --policy-name ChinhSachThietBi --target <arn-chung-chi>
aws iot attach-thing-principal --thing-name cam-bien-01 --principal <arn-chung-chi>

Thiết bị dùng chứng chỉ đó để xác thực hai chiều (mutual TLS) khi kết nối tới endpoint MQTT của IoT Core — đúng nghĩa "secure communication protocols over the internet".

Phương án D cũng đáng cân nhắc hơn A: AWS Private CA thật sự cấp được chứng chỉ X.509 riêng tư và tích hợp chính thức với IoT Core (tính năng just-in-time provisioning, đăng ký CA riêng của bạn với IoT Core). Đó là con đường chuẩn khi doanh nghiệp muốn tự kiểm soát chuỗi tin cậy thay vì dùng CA của AWS.

Nói gọn thứ tự hợp lý: B là đáp án đúng nhất cho một triển khai mới, D đúng khi cần PKI riêng, còn A mô tả một việc mà ACM không làm.

Phân biệt các dịch vụ liên quan

Ghi nhớ về bảo mật IoT trên AWS

Ba cách xác thực thiết bị với IoT Core: | Cách | Dùng khi | |---|---| | Chứng chỉ X.509 (mutual TLS) | mặc định và phổ biến nhất | | Cognito identity | ứng dụng di động điều khiển thiết bị | | Custom authorizer | token của hệ thống có sẵn |

Ba lớp bảo vệ nên có:

1. Mỗi thiết bị một chứng chỉ riêng — không dùng chung, để thu hồi được từng cái
2. IoT policy theo đặc quyền tối thiểu — dùng biến thay thế để mỗi thiết bị chỉ publish vào topic của chính nó:

   {"Effect":"Allow","Action":"iot:Publish",
    "Resource":"arn:aws:iot:*:*:topic/thiet-bi/${iot:Connection.Thing.ThingName}/du-lieu"}
   

3. AWS IoT Device Defender — phát hiện hành vi bất thường và cấu hình sai

Và với đội ngũ triển khai hàng loạt: fleet provisioning cho phép thiết bị tự đăng ký và nhận chứng chỉ riêng ở lần khởi động đầu tiên, thay vì phải nạp sẵn từng cái trong nhà máy.

Đáp án

A — Đặt page size nhỏ hơn cho lệnh scan.

Vì sao đúng

Scan tiêu thụ throughput theo từng trang kết quả. Mặc định DynamoDB trả về tối đa 1 MB mỗi trang, và toàn bộ lượng RCU cho trang đó được tính cùng một lúc:

Trang 1 MB, strongly consistent → 256 RCU tiêu thụ TRONG MỘT KHOẢNH KHẮC

Nếu bảng chỉ được cấp 100 RCU/giây, một cú như vậy sẽ vượt trần ngay lập tức, ăn hết burst capacity và gây throttle cho các truy vấn thật đang chạy.

Giảm page size bằng Limit sẽ rải mức tiêu thụ ra đều hơn theo thời gian:

paginator = dynamodb.get_paginator('scan')
for trang in paginator.paginate(
        TableName='bang-lon',
        PaginationConfig={'PageSize': 100}):   # ← 100 item mỗi lần thay vì 1 MB
    xu_ly(trang['Items'])
    time.sleep(0.05)                            # thêm khoảng nghỉ giữa các trang

Trước: [████████████] một cú lớn → throttle
Sau:   [█] [█] [█] [█] [█] nhiều cú nhỏ → không bao giờ vượt trần

Scan sẽ mất nhiều thời gian hơn, nhưng đó chính là điều đề muốn: giảm ảnh hưởng lên provisioned throughput, không phải chạy nhanh hơn.

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

• B. Dùng parallel scan — làm điều ngược lại: nó chạy nhiều luồng đồng thời để quét nhanh hơn, nên tiêu thụ throughput mạnh hơn hẳn và gây ảnh hưởng lớn hơn. Parallel scan là công cụ cho mục tiêu "quét nhanh nhất", còn đề này hỏi "ảnh hưởng ít nhất" — hai mục tiêu trái nhau. (Kết hợp parallel scan có kèm rate limiting thì lại hợp lý, nhưng phương án không nói tới việc điều tiết.)
• C. "Làm nóng bảng bằng cách cập nhật mọi item" — không có khái niệm prewarming trong DynamoDB, và việc cập nhật mọi item còn tiêu tốn WCU khổng lồ — tệ hơn nhiều so với chính vấn đề cần giải.
• D. Định nghĩa range key cho bảng — không sửa được khoá chính của bảng đã tạo; muốn đổi phải tạo bảng mới và di trú toàn bộ dữ liệu. Và kể cả làm được, thêm sort key không làm scan bớt tốn: scan vẫn đọc toàn bộ bảng bất kể cấu trúc khoá.

Ghi nhớ

Bốn cách giảm ảnh hưởng của scan, tuỳ mục tiêu: | Cách | Tác dụng | |---|---| | Giảm page size (Limit) | rải tiêu thụ theo thời gian | | Eventually consistent | giảm một nửa RCU | | ProjectionExpression | chỉ lấy cột cần — giảm dữ liệu đọc thật sự | | Chèn sleep giữa các trang | điều tiết chủ động |

Điều cần nhớ về FilterExpression: nó không giảm RCU. Bộ lọc được áp sau khi dữ liệu đã được đọc và tính tiền — bạn chỉ nhận về ít kết quả hơn, không trả ít tiền hơn.

Hai mục tiêu, hai công cụ trái ngược nhau — bảng này giúp chọn nhanh khi làm bài: | Đề hỏi | Chọn | |---|---| | "minimize impact", "without affecting production" | page size nhỏ, rate limiting | | "shortest time", "scan as fast as possible" | parallel scan (kèm rate limiting nếu có ràng buộc production) |

Và giải pháp tốt nhất cho việc quét toàn bảng lặp lại định kỳ: DynamoDB Export to S3 rồi phân tích bằng Athena. Nó không tiêu thụ RCU nào cả, nên hoàn toàn không thể ảnh hưởng tới workload thật — đây là điều nhiều đội chỉ phát hiện ra sau khi đã vật lộn với việc điều tiết scan.

Đáp án

A — Cấu hình Lambda dùng KMS customer managed CMK, dùng CMK đó sinh data key và mã hoá dữ liệu trước khi ghi vào /tmp.

Vì sao đúng

Có một sự thật về Lambda mà câu hỏi này xoay quanh:

Thư mục /tmp của Lambda KHÔNG được mã hoá at-rest bởi dịch vụ. Nó là vùng lưu trữ tạm gắn với môi trường thực thi, và AWS không cung cấp thiết lập nào để bật mã hoá cho nó. Nếu dữ liệu nhạy cảm phải được mã hoá ở đó, ứng dụng phải tự làm.

Cách đúng là envelope encryption:

import boto3, os, base64
from cryptography.fernet import Fernet

kms = boto3.client('kms')
CMK = os.environ['KMS_KEY_ID']

def ghi_tam_ma_hoa(ten_tep, noi_dung):
    r = kms.generate_data_key(KeyId=CMK, KeySpec='AES_256')
    f = Fernet(base64.urlsafe_b64encode(r['Plaintext']))
    with open(f'/tmp/{ten_tep}', 'wb') as fp:
        fp.write(r['CiphertextBlob'])      # lưu khoá đã mã hoá ở đầu tệp
        fp.write(f.encrypt(noi_dung))
    del r['Plaintext']                      # xoá khoá bản rõ khỏi bộ nhớ

Vì sao dùng GenerateDataKey chứ không phải kms:Encrypt trực tiếp: Encrypt giới hạn 4 KB, còn /tmp chứa được 512 MB tới 10 GB.

Và có một rủi ro cụ thể khiến việc này quan trọng: môi trường thực thi Lambda được tái sử dụng giữa các lần gọi, nên tệp trong /tmp vẫn còn đó ở lần gọi sau — có thể là một lần gọi phục vụ người dùng khác. Mã hoá (và xoá tệp sau khi dùng) là biện pháp bắt buộc với dữ liệu nhạy cảm.

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

• B. Bật mã hoá mặc định trên S3 bucket rồi mount bucket vào /tmp — không mount được S3 như hệ thống tệp trong Lambda. S3 là kho object truy cập qua API. (Có công cụ như mountpoint-s3 hay s3fs nhưng chúng cần quyền và môi trường mà Lambda không cung cấp.)
• C. Gắn Lambda vào VPC và mount EBS volume vào /tmp — Lambda không gắn được EBS volume. Bạn không có quyền truy cập vào máy chủ bên dưới, và gắn hàm vào VPC chỉ cho phép nó gọi tới tài nguyên trong VPC, không cho nó mount ổ đĩa.
• D. Bật HTTPS/TLS cho các endpoint API của Lambda — nhầm hai loại mã hoá: TLS bảo vệ dữ liệu khi truyền, còn đề hỏi về dữ liệu khi lưu (at rest) trong /tmp. (Và các endpoint AWS vốn đã là HTTPS.)

Ghi nhớ

Mã hoá trong Lambda — cái gì được lo sẵn, cái gì phải tự làm: | Đối tượng | Mã hoá at-rest | |---|---| | Mã nguồn hàm (gói triển khai) | ✅ tự động | | Biến môi trường | ✅ mặc định, dùng CMK riêng được | | Thư mục /tmp | ❌ PHẢI TỰ LÀM | | Bộ nhớ (RAM) | không có cơ chế mã hoá | | EFS gắn vào Lambda | ✅ bật được ở phía EFS |

Đặc điểm của /tmp cần thuộc: | Đặc điểm | Chi tiết | |---|---| | Kích thước | 512 MB (mặc định) đến 10 GB | | Tái sử dụng | giữa các lần gọi trên cùng môi trường | | Chia sẻ | không chia sẻ giữa các môi trường thực thi | | Mã hoá | không có sẵn |

Ba thực hành nên theo khi xử lý dữ liệu nhạy cảm trong Lambda:

1. Mã hoá trước khi ghi vào /tmp
2. Xoá tệp ngay sau khi dùng xong — đừng dựa vào việc môi trường sẽ bị huỷ
3. Nếu cần lưu trữ bền và mã hoá, dùng EFS gắn vào Lambda (có mã hoá at-rest và in-transit) thay vì /tmp

Và nhớ cấp quyền cho execution role: kms:GenerateDataKey và kms:Decrypt trên CMK đó.

Đáp án

B — Write-through cache.

Vì sao đúng

Yêu cầu của đề: dashboard phải phản ánh dữ liệu thời gian thực, và dữ liệu đến từ CSDL cần có mặt trong cache.

Write-through ghi vào cache và CSDL cùng lúc, ở mỗi lần ghi:

def cap_nhat(khoa, gia_tri):
    csdl.update(khoa, gia_tri)        # ghi CSDL
    cache.set(khoa, gia_tri)          # ghi cache NGAY

Ứng dụng ghi ──┬──→ CSDL
               └──→ Cache      ← cả hai cùng lúc, luôn khớp nhau

Vì sao nó hợp với dashboard thời gian thực: | Đặc điểm | Ý nghĩa | |---|---| | Dữ liệu trong cache không bao giờ cũ | dashboard hiển thị đúng trạng thái hiện tại | | Không có cache miss cho dữ liệu đã ghi | mọi lần đọc đều nhanh, độ trễ đều đặn | | Không có "cold start" của cache | không có cú đọc đầu tiên chậm bất thường |

Điểm cuối quan trọng với dashboard: người xem không gặp cảnh một vài ô tải chậm hẳn vì rơi vào cache miss.

Đánh đổi cần biết: | Nhược điểm | Chi tiết | |---|---| | Độ trễ ghi cao hơn | mỗi lần ghi phải làm hai việc | | Cache chứa cả dữ liệu không ai đọc | tốn bộ nhớ | | Cache mới tạo thì trống | phải chờ có lượt ghi mới có dữ liệu |

Với dashboard, các nhược điểm này ít quan trọng — dashboard đọc nhiều hơn ghi rất nhiều, nên trả giá ở đường ghi để đường đọc luôn nhanh và luôn đúng là đánh đổi hợp lý.

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

• C. Lazy loading (cache-aside) — chỉ nạp vào cache khi có người đọc mà không thấy:

  def doc(khoa):
      gt = cache.get(khoa)
      if gt is None:                 # cache miss
          gt = csdl.get(khoa)
          cache.set(khoa, gt)
      return gt
  

  Hai vấn đề với dashboard: lần đọc đầu luôn chậm, và quan trọng hơn — dữ liệu trong cache có thể cũ sau khi CSDL đã đổi, cho tới khi TTL hết hạn. Trái yêu cầu "real-time".
• D. Read-through cache — về bản chất giống lazy loading, chỉ khác là cache tự đi lấy dữ liệu thay vì ứng dụng làm. Cùng vấn đề: dữ liệu có thể cũ.
• A. Write-behind (write-back) — ghi vào cache ngay rồi mới ghi xuống CSDL sau, bất đồng bộ. Ghi rất nhanh, nhưng rủi ro mất dữ liệu nếu cache hỏng trước khi kịp ghi xuống — không chấp nhận được với dữ liệu nghiệp vụ. (ElastiCache cũng không cung cấp cơ chế này sẵn; phải tự dựng.)

Ghi nhớ

Mẫu thực dụng nhất trong sản xuất là kết hợp write-through với TTL:

cache.setex(khoa, 3600, gia_tri)     # write-through + hết hạn sau 1 giờ

TTL đóng vai trò lưới an toàn: nếu có đường ghi nào đó bỏ qua cache (job batch, thao tác thủ công trên CSDL), dữ liệu lệch sẽ tự được dọn sau khi hết hạn thay vì tồn tại mãi.

Và nhớ: lazy loading không bao giờ là câu trả lời khi đề nói "real-time" — theo định nghĩa, nó phục vụ dữ liệu cũ cho tới lần miss tiếp theo.

Đáp án nguồn

B — "Chỉ thực hiện thay đổi ở giai đoạn deployment, không bao giờ trong lúc synthesis."

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

Đáp án nguồn không trả lời câu hỏi được đặt ra, và cả bốn phương án đều có vấn đề. Đề hỏi: "làm sao quay lại phiên bản trước nếu có lỗi?" — nhưng phương án B mô tả một thói quen làm việc, không phải một cơ chế quay lui. Dù có tuân thủ nó tuyệt đối, bạn vẫn không có cách nào trở về phiên bản cũ.

Ba phương án còn lại cũng lủng củng: cả A, C, D đều bắt đầu bằng "once CloudFormation has been installed/added", trong khi CloudFormation không phải thứ để cài hay để thêm vào ứng dụng — nó là dịch vụ có sẵn, và CDK luôn dùng nó bên dưới dù bạn có làm gì hay không. Nghe như một câu hỏi bị viết lại từ nguồn khác và mất nghĩa trong quá trình đó.

Trong bốn phương án, A ("dùng CloudFormation để quay về phiên bản trước") mới là thứ gần với câu trả lời đúng nhất, chỉ sai ở chữ "installed".

Câu trả lời thật sự

CDK không tự có cơ chế rollback riêng — nó tổng hợp (synth) ra template CloudFormation rồi giao cho CloudFormation triển khai. Nên khả năng quay lui đến từ CloudFormation:

Mã CDK (TypeScript/Python)
    ↓ cdk synth
Template CloudFormation
    ↓ cdk deploy
CloudFormation stack  ← nơi có rollback

Ba lớp bảo vệ, theo thứ tự tự động giảm dần:

1. Rollback tự động khi triển khai thất bại. Đây là hành vi mặc định và là câu trả lời trực tiếp nhất cho đề: nếu một tài nguyên tạo/cập nhật hỏng, CloudFormation tự động đưa toàn bộ stack về trạng thái trước đó (UPDATE_ROLLBACK_COMPLETE). Bạn không phải làm gì cả.

2. Quay lại bằng mã nguồn. Vì hạ tầng là mã, phiên bản trước nằm trong Git:

git revert <commit>
cdk deploy

3. Xem trước thay đổi để không phải rollback. cdk diff cho biết chính xác cái gì sẽ đổi, kể cả tài nguyên nào sẽ bị thay thế (mất dữ liệu):

cdk diff          # so trạng thái hiện tại với mã mới

Ghi nhớ về CDK

Hai giai đoạn của CDK, và đây là chỗ mà phương án B có ý đúng dù trả lời sai câu hỏi: | Giai đoạn | Việc | |---|---| | Synthesis (cdk synth) | chạy mã của bạn, sinh ra template CloudFormation | | Deployment (cdk deploy) | CloudFormation áp dụng template đó |

Ý đúng ẩn trong phương án B: đừng viết logic phụ thuộc vào trạng thái runtime trong lúc synth. Mã CDK chạy trên máy của bạn lúc synth — nó không biết gì về tài nguyên đang tồn tại trên AWS. Muốn quyết định dựa trên giá trị chỉ biết lúc triển khai thì phải dùng CloudFormation parameter, Fn::If, hoặc custom resource — chứ không phải một câu if trong TypeScript.

Các lệnh CDK cần biết: | Lệnh | Việc | |---|---| | cdk synth | sinh template, không triển khai | | cdk diff | so sánh với stack đang chạy — luôn chạy trước khi deploy | | cdk deploy | triển khai | | cdk destroy | xoá stack | | cdk bootstrap | chuẩn bị tài khoản/Region lần đầu |

Và một thiết lập đáng biết cho việc gỡ lỗi: --no-rollback giữ nguyên trạng thái thất bại thay vì quay lui, để bạn kịp xem chuyện gì đã xảy ra. Dùng ở môi trường dev thôi — production nên để rollback tự động chạy.

Đáp án

A — Dùng AWS Secrets Manager để lưu các biến này và lấy chúng trực tiếp trong ứng dụng bằng AWS SDK.

Vì sao đúng

Đề nêu ba yêu cầu, và Secrets Manager đáp ứng cả ba:

1. Xử lý và truy cập an toàn thông tin nhạy cảm (credential, thông tin xác thực API)
2. Dùng chung được cho mọi môi trường — dev, test, production
3. Ít thay đổi cho ứng dụng

import boto3, json

def lay_bi_mat(ten):
    client = boto3.client('secretsmanager')
    return json.loads(client.get_secret_value(SecretId=ten)['SecretString'])

bi_mat = lay_bi_mat('ung-dung/api-ben-ngoai')
url = bi_mat['apiUrl']
khoa = bi_mat['apiKey']

Vì sao Secrets Manager hơn hẳn các lựa chọn khác cho dữ liệu nhạy cảm: | Tính năng | Chi tiết | |---|---| | Mã hoá bằng KMS | mặc định, không phải cấu hình | | Xoay vòng tự động | có lịch, tích hợp sẵn với RDS, Redshift, DocumentDB | | Kiểm soát bằng IAM | phân quyền tới từng secret | | Vết CloudTrail | biết ai đã đọc bí mật nào, khi nào | | Có phiên bản | quay lại giá trị cũ được, và hỗ trợ xoay vòng không gián đoạn | | Chia sẻ đa môi trường | một secret dùng chung, hoặc một secret cho mỗi môi trường với cùng tên logic |

Vế "minimal modifications" cũng thoả: ứng dụng thay chỗ đọc cấu hình bằng một lời gọi SDK, không đổi kiến trúc.

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

• D. Dùng biến môi trường — đây là phương án phổ biến trong thực tế và cần nói rõ vì sao nó thua ở đây. Với ECS, biến môi trường khai trong task definition hiện nguyên văn trong Console và trong CloudTrail; ai có ecs:DescribeTaskDefinition đều đọc được mật khẩu. Nó cũng không xoay vòng được và không có vết kiểm toán cho việc đọc. (Cách làm đúng khi vẫn muốn dùng biến môi trường là dùng trường secrets của ECS — nó chỉ lưu ARN trỏ tới Secrets Manager hoặc SSM, còn giá trị thật được nạp lúc container khởi động.)
• B. Lưu trên S3 rồi đọc bằng SDK — làm được nhưng thiếu mọi thứ khiến Secrets Manager đáng dùng: không xoay vòng, không có phiên bản cho mục đích xoay vòng, và bạn phải tự lo mã hoá cùng phân quyền. Đây là dựng lại một dịch vụ đã có, kém hơn.
• C. Nhúng thẳng vào mã và quản lý bằng version control — sai lầm bảo mật nghiêm trọng nhất: bí mật nằm trong lịch sử Git vĩnh viễn, mọi người có quyền đọc kho mã đều thấy, và đổi bí mật thì phải build lại và triển khai lại.

Ghi nhớ

Cách chọn thực dụng:

• Mật khẩu CSDL, khoá API cần xoay vòng ⇒ Secrets Manager
• Cấu hình không nhạy cảm (API URL, feature flag, tên bucket) ⇒ Parameter Store (miễn phí)

Áp vào đúng đề bài này: credential và thông tin xác thực API ⇒ Secrets Manager, còn API URL vốn không phải bí mật nên hoàn toàn có thể để ở Parameter Store cho rẻ. Gom tất cả vào Secrets Manager thì đơn giản hơn về mặt vận hành, và với vài biến thì chênh lệch chi phí không đáng kể.

Và một tối ưu quan trọng: cache giá trị đã lấy trong bộ nhớ, đừng gọi get_secret_value ở mỗi request — vừa tốn tiền theo lời gọi API, vừa thêm độ trễ.

Đáp án

C — Tạo mapping template.

Vì sao đúng

Vấn đề: query string parameter đến từ client nằm ở cấu trúc request của API Gateway, còn Lambda cần chúng ở dạng đối tượng JSON làm đầu vào của hàm. Việc chuyển đổi giữa hai dạng đó là công việc của mapping template.

Điều này chỉ cần thiết với Lambda integration kiểu non-proxy (custom). Template viết bằng VTL:

## Integration request — biến query string thành đối tượng cho hàm
{
  "tenNguoiDung": "$input.params('username')",
  "diem": $input.params('score'),
  "ghiChu": "$util.escapeJavaScript($input.params('note'))"
}

Hàm nhận được đúng thứ nó cần:

def lambda_handler(event, context):
    ten = event['tenNguoiDung']    # sạch sẽ, không phải bóc tách gì
    diem = event['diem']

Lưu ý về $util.escapeJavaScript ở dòng cuối: nó thoát ký tự đặc biệt trong giá trị do người dùng nhập. Thiếu nó, một giá trị chứa dấu nháy kép sẽ phá vỡ cấu trúc JSON của template — đây là lỗi tinh vi hay gặp và chỉ lộ ra với dữ liệu bất thường.

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

• A. Đổi integration type — đây là phương án đáng bàn nhất, vì nó gần đúng theo một hướng khác. Chuyển sang Lambda proxy integration thì API Gateway tự truyền toàn bộ request vào hàm dưới dạng chuẩn:

  def lambda_handler(event, context):
      ten = event['queryStringParameters']['username']   # tự bóc tách trong mã
  

  Nhưng đề hỏi cách "convert the query string parameters to arguments" — tức là biến đổi ở tầng API Gateway. Với proxy integration thì không có phép chuyển đổi nào cả; hàm nhận nguyên request và tự xử lý. Hai cách đều dùng được trong thực tế, nhưng chỉ mapping template mới là "chuyển đổi".
• B. Đưa ARN của hàm Lambda vào — ARN chỉ cho biết gọi hàm nào. Nó không ảnh hưởng gì tới hình dạng dữ liệu truyền vào.
• D. Bật request validation — kiểm tra tính hợp lệ của request (có đủ tham số bắt buộc không, body có khớp JSON Schema không) rồi từ chối request sai. Nó không biến đổi gì cả.

Ghi nhớ

Hai kiểu tích hợp Lambda — khác biệt cốt lõi: | | Lambda Proxy | Lambda (custom/non-proxy) | |---|---|---| | Đầu vào hàm | toàn bộ request theo định dạng chuẩn | do mapping template quyết định | | Đầu ra hàm | phải đúng định dạng (statusCode, headers, body) | mapping template lo | | Mapping template | không dùng | bắt buộc nếu cần biến đổi | | Linh hoạt | ít — logic nằm trong mã | nhiều — logic nằm ở API Gateway | | Phổ biến | cách mặc định hiện nay | khi cần biến đổi định dạng |

Các biến VTL hay dùng trong mapping template:

$input.params('ten')          ## lấy từ path, query, hoặc header
$input.params().querystring   ## toàn bộ query string
$input.path('$.field')        ## đọc từ body JSON
$input.json('$')              ## toàn bộ body
$context.requestId            ## thông tin request
$context.identity.sourceIp    ## IP người gọi
$stageVariables.tenBien       ## biến của stage
$util.escapeJavaScript(...)   ## THOÁT KÝ TỰ — nhớ dùng cho dữ liệu người dùng

Nhận dạng nhanh: đề nói "transform", "convert", "map" giữa hai định dạng ⇒ mapping template. Đề nói "pass through", "forward the entire request" ⇒ proxy integration.