GĐ33 — AWS SAA: Labs, Case Studies và Ôn tập có giải thích

Áp dụng GĐ28–32. Lab là hướng dẫn để bạn tự thực hành; việc build guide không tạo tài nguyên AWS và không xác nhận lab đã chạy trên account của bạn. Câu hỏi dưới đây do guide tự xây, không phải đề thi AWS hay exam dumps.

1. Chuẩn bị lab và cách lưu bằng chứng#

Hai mức thực hành:

• Trên giấy: sơ đồ, policy review, cost estimate, câu hỏi lỗi; dùng được trước khi có account.
• Trên AWS: tài nguyên sandbox và dữ liệu giả, chạy từng lab rồi dọn ngay.

Chuẩn bị AWS CLI v2, danh tính tạm thời theo phương thức đăng nhập account hỗ trợ, một Region và quyền tạo đúng tài nguyên lab. Không dùng root cho lab. Bật MFA cho account, tạo budget alert, kiểm tra pricing; budget không phải hard cap. Gắn tag Project=aws-saa-lab, Owner và ngày dự kiến dọn cho tài nguyên hỗ trợ.

Kiểm tra CLI bằng lệnh đọc, thay profile/Region bằng giá trị của bạn:

aws sts get-caller-identity --profile YOUR-LAB-PROFILEaws configure get region --profile YOUR-LAB-PROFILE

Không đưa output có thông tin account cá nhân lên repo public. Không lưu secrets vào source. Mỗi lab ghi riêng: sơ đồ, resource IDs, điều kiện thử, kết quả mong đợi/thực tế, timestamp, cost estimate và cleanup checklist. Dữ liệu upload chỉ là file giả; không dùng PDF cá nhân.

Nguồn: CLI authentication, AWS Budgets.

# Lab X - <tên>             Ngày: YYYY-MM-DD   Region: ...Sơ đồ:            (ASCII hoặc ảnh, có AZ/subnet/SG)Tài nguyên tạo:   <loại> | <id/tên> | <thời điểm tạo>Điều kiện thử:    <ai gọi gì, từ đâu>Mong đợi:         ...Thực tế:          ... (dán output đã che Account ID)Giải thích:       vì sao ra kết quả đó (policy nào, rule nào)Thời gian đo:     bắt đầu - kết thúc - tổngƯớc tính chi phí: giả định, nguồn giá, ngàyDọn dẹp:          lệnh dọn + lệnh kiểm "không còn gì" + ngày xem billingCòn lại/không làm: ...

Quyết định: <một câu>Bối cảnh/requirement: <RTO/RPO, AZ, ngân sách, compliance>Phương án đã xét: A ... | B ... | C ...Chọn: B vì ...Loại: A vì (vi phạm requirement nào) ; C vì ...Hệ quả: chi phí cố định, vận hành, rủi ro còn lạiKhi nào xem lại: <điều kiện + ngày>

2. Lab A — S3 private, IAM và versioning#

Mục tiêu: cùng một object, quyền đọc đúng prefix thành công, prefix ngoài phạm vi bị từ chối; ghi đè rồi lấy lại được version cũ.

1. Tạo general purpose bucket có tên duy nhất trong Region đã chọn; giữ Block Public Access, dùng SSE-S3 cho lần đầu.

   Đáp án

   Tạo bucket và kiểm tra mặc định. Bucket mới đã bật Block Public Access, tắt ACL (bucket owner enforced) và mã hóa SSE-S3 mặc định (SSE-S3 mặc định từ tháng 1/2023 theo AWS What's New; Block Public Access bật và ACL tắt cho bucket mới từ tháng 4/2023 theo AWS What's New), nên các lệnh get-* chỉ để xác nhận:

   bashReady

   BUCKET=saa-lab-$(date +%s)-CHANGE-ME     # tên phải duy nhất toàn cầu# Region khác us-east-1 cần LocationConstraint; nếu chọn us-east-1# thì BỎ dòng --create-bucket-configuration (nếu không sẽ lỗi# InvalidLocationConstraint; suy luận theo tài liệu, chưa chạy)aws s3api create-bucket --bucket "$BUCKET" --region "$AWS_REGION" \  --create-bucket-configuration LocationConstraint="$AWS_REGION"aws s3api get-public-access-block --bucket "$BUCKET"aws s3api get-bucket-encryption --bucket "$BUCKET"

2. Bật versioning. Tạo hai file giả qua editor, upload raw/note.txt và other/note.txt bằng danh tính setup có quyền tương ứng.

   Đáp án

   Bật versioning rồi kiểm tra, sau đó tạo hai file giả và upload:

   bashReady

   aws s3api put-bucket-versioning --bucket "$BUCKET" \  --versioning-configuration Status=Enabledaws s3api get-bucket-versioning --bucket "$BUCKET"   # Status: Enabledecho "version one" > note.txtaws s3api put-object --bucket "$BUCKET" --key raw/note.txt --body note.txtaws s3api put-object --bucket "$BUCKET" --key other/note.txt --body note.txt

3. Tạo role kiểm thử mà danh tính lab được assume; trust chỉ dành cho danh tính đó. Gắn identity policy chỉ s3:GetObject trên raw/* như GĐ29. Giữ role này không có policy rộng khác làm sai phép thử.

   Đáp án

   Tạo role chỉ cho phép đọc raw/*. trust.json cho danh tính lab được assume (thay ARN bằng của bạn), policy.json chỉ có s3:GetObject:

   jsonReady

   { "Version": "2012-10-17",  "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::ACCOUNT_ID:user/YOUR-LAB-USER" }, "Action": "sts:AssumeRole" } ] }

   jsonReady

   { "Version": "2012-10-17",  "Statement": [ { "Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::BUCKET-NAME/raw/*" } ] }

   bashReady

   aws iam create-role --role-name saa-lab-reader \  --assume-role-policy-document file://trust.jsonaws iam put-role-policy --role-name saa-lab-reader \  --policy-name raw-read-only --policy-document file://policy.json

   Nếu danh tính lab dùng IAM Identity Center thay vì IAM user, đổi Principal cho khớp phương thức đăng nhập (xem trang CLI role profiles).

4. Assume role qua phương thức profile được hỗ trợ; dùng profile kiểm thử đọc raw/note.txt → thành công, đọc other/note.txt → AccessDenied. Không yêu cầu ListBucket để đọc một key đã biết.

   Đáp án

   Tạo profile đọc trong ~/.aws/config (đợi vài giây để role lan truyền):

   textReady

   [profile saa-reader]role_arn = arn:aws:iam::ACCOUNT_ID:role/saa-lab-readersource_profile = YOUR-LAB-PROFILE

   bashReady

   aws s3api get-object --bucket "$BUCKET" --key raw/note.txt out-raw.txt \  --profile saa-readeraws s3api get-object --bucket "$BUCKET" --key other/note.txt out-other.txt \  --profile saa-reader

5. Quay về danh tính setup, ghi đè raw/note.txt với nội dung khác. Xem Versions và tải version đầu; delete current object rồi quan sát delete marker.

   Đáp án

   Quay lại profile setup: ghi đè, xem versions, lấy bản cũ, rồi xóa:

   bashReady

   echo "version two" > note.txtaws s3api put-object --bucket "$BUCKET" --key raw/note.txt --body note.txtaws s3api list-object-versions --bucket "$BUCKET" --prefix raw/note.txtaws s3api get-object --bucket "$BUCKET" --key raw/note.txt \  --version-id VERSION-ID-OF-V1 old.txtaws s3api delete-object --bucket "$BUCKET" --key raw/note.txtaws s3api list-object-versions --bucket "$BUCKET" --prefix raw/note.txt

6. Mở rộng tùy chọn: dùng SSE-KMS, cấp GetObject nhưng chưa cấp quyền KMS phù hợp; quan sát lỗi rồi bổ sung quyền key tối thiểu.

   Đáp án

   Tùy chọn, chưa chạy: tạo KMS key riêng, đặt mặc định mã hóa SSE-KMS cho bucket, upload lại một object. Cấp cho role s3:GetObject nhưng chưa cấp quyền KMS: đọc sẽ lỗi. Sau đó thêm kms:Decrypt trên đúng key vào policy của role rồi đọc lại. Đây là lỗi hay gặp với SSE-KMS (xem Lỗi hay gặp trong Khung và mã dùng chung).

   Mẫu CLI (tham số đã đối chiếu help). Key tạo không kèm --policy sẽ dùng default key policy; policy này cho phép account dùng IAM policy để cấp quyền key, nên inline policy của role là đủ:

   bashReady

   KEY_ARN=$(aws kms create-key --description saa-lab-s3 \  --tags TagKey=Project,TagValue=aws-saa-lab --query KeyMetadata.Arn --output text)aws s3api put-bucket-encryption --bucket "$BUCKET" \  --server-side-encryption-configuration \  '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"aws:kms","KMSMasterKeyID":"'"$KEY_ARN"'"}}]}'echo kms-test > kms.txtaws s3api put-object --bucket "$BUCKET" --key raw/kms.txt --body kms.txtaws s3api get-object --bucket "$BUCKET" --key raw/kms.txt out-kms.txt \  --profile saa-reader            # mong đợi: lỗi, role chưa có kms:Decryptaws iam put-role-policy --role-name saa-lab-reader --policy-name kms-decrypt \  --policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"kms:Decrypt","Resource":"'"$KEY_ARN"'"}]}'

   Chờ vài giây rồi chạy lại get-object. Khi dọn: aws iam delete-role-policy --role-name saa-lab-reader --policy-name kms-decrypt trước khi xóa role, và lên lịch xóa key như phần dọn bên dưới. Nguồn: SSE-KMS trong S3, default key policy.

 profile saa-setup (quyền tạo)          profile saa-reader (assume role)        |  put-object x2                        |  get-object        v                                       v   +--------------------- bucket (private, versioning ON) ---------+   |  raw/note.txt   (v1, v2)         other/note.txt               |   +---------------------------------------------------------------+   role saa-lab-reader: Allow s3:GetObject on arn:...:bucket/raw/*   raw/*  -> Allow            other/*  -> implicit deny (không có Allow)

aws s3api list-object-versions --bucket "$BUCKET" --output json \ | jq '{Objects: ([.Versions[]?, .DeleteMarkers[]?]                  | map({Key, VersionId})), Quiet: true}' > del.jsonaws s3api delete-objects --bucket "$BUCKET" --delete file://del.jsonaws s3api list-multipart-uploads --bucket "$BUCKET"     # nếu có: abort-multipart-uploadaws s3api delete-bucket --bucket "$BUCKET"aws iam delete-role-policy --role-name saa-lab-reader --policy-name raw-read-onlyaws iam delete-role --role-name saa-lab-reader

Lệnh đọc object bằng profile giới hạn, output là file mới trong thư mục lab của bạn:

aws s3api get-object --bucket YOUR-LAB-BUCKET --key raw/note.txt ./saa-raw-result.txt --profile YOUR-READER-PROFILE --region YOUR-LAB-REGIONaws s3api get-object --bucket YOUR-LAB-BUCKET --key other/note.txt ./saa-other-result.txt --profile YOUR-READER-PROFILE --region YOUR-LAB-REGION

Evidence: hai kết quả khác nhau dưới cùng principal, version IDs/nội dung trước-sau và giải thích implicit deny. Nếu cả hai đọc được, tìm policy rộng/resource grant khác trước khi kết luận prefix policy sai.

Dọn: xóa tất cả object versions và delete markers, incomplete multipart uploads nếu có, bucket, role/policies riêng cho lab; chỉ xóa KMS key riêng khi chắc không còn dữ liệu cần decrypt. Key deletion có waiting period và không được nhầm với xóa object.

Nguồn: S3 versioning, CLI role profiles.

3. Lab B — VPC, ALB và Auto Scaling hai AZ#

Mục tiêu: thấy load balancer đưa request tới nhiều máy; khi một máy bị thay, service phục hồi mà không lưu state trên máy đó. Lab này có ALB/EC2 và tài nguyên network tính phí.

1. Vẽ VPC với hai public subnets và hai private app subnets ở hai AZ. Public route tới IGW; app egress qua thiết kế NAT/endpoints đã chọn. Ghi fixed cost trước khi tạo.

   Đáp án

   Vẽ và tạo VPC: hai public subnet, hai private subnet ở hai AZ khác nhau, route public tới IGW. Chọn một cách egress cho private subnet và ghi chi phí cố định trước khi tạo: NAT gateway từng AZ, hoặc Regional NAT gateway (một gateway tự mở rộng qua nhiều AZ; ra mắt 2025-11-19, không có ở GovCloud và China), hoặc interface/gateway endpoints cho đúng dịch vụ cần dùng.

   Mẫu CLI tạo network (chưa chạy trên AWS; tham số đã đối chiếu aws ec2 <lệnh> help). Mỗi lệnh in ra ID để dùng tiếp; tag Project=aws-saa-lab để quét sót khi dọn:

   bashReady

   TAG='Tags=[{Key=Project,Value=aws-saa-lab}]'read AZ1 AZ2 _ < <(aws ec2 describe-availability-zones \  --filters Name=zone-type,Values=availability-zone \  --query 'AvailabilityZones[].ZoneName' --output text)VPC=$(aws ec2 create-vpc --cidr-block 10.20.0.0/16 \  --tag-specifications "ResourceType=vpc,$TAG" --query Vpc.VpcId --output text)mk() { aws ec2 create-subnet --vpc-id "$VPC" --cidr-block "$1" \  --availability-zone "$2" --tag-specifications "ResourceType=subnet,$TAG" \  --query Subnet.SubnetId --output text; }PUB_A=$(mk 10.20.0.0/24 "$AZ1");  PUB_B=$(mk 10.20.1.0/24 "$AZ2")APP_A=$(mk 10.20.10.0/24 "$AZ1"); APP_B=$(mk 10.20.11.0/24 "$AZ2")IGW=$(aws ec2 create-internet-gateway \  --tag-specifications "ResourceType=internet-gateway,$TAG" \  --query InternetGateway.InternetGatewayId --output text)aws ec2 attach-internet-gateway --internet-gateway-id "$IGW" --vpc-id "$VPC"RT_PUB=$(aws ec2 create-route-table --vpc-id "$VPC" \  --tag-specifications "ResourceType=route-table,$TAG" \  --query RouteTable.RouteTableId --output text)aws ec2 create-route --route-table-id "$RT_PUB" \  --destination-cidr-block 0.0.0.0/0 --gateway-id "$IGW"aws ec2 associate-route-table --route-table-id "$RT_PUB" --subnet-id "$PUB_A"aws ec2 associate-route-table --route-table-id "$RT_PUB" --subnet-id "$PUB_B"RT_APP=$(aws ec2 create-route-table --vpc-id "$VPC" \  --tag-specifications "ResourceType=route-table,$TAG" \  --query RouteTable.RouteTableId --output text)aws ec2 associate-route-table --route-table-id "$RT_APP" --subnet-id "$APP_A"aws ec2 associate-route-table --route-table-id "$RT_APP" --subnet-id "$APP_B"

   Route table RT_APP chưa có đường ra Internet. Thêm NAT/Regional NAT nếu app cần tải package, hoặc làm theo biến thể không NAT ở cuối mục này.

2. Tạo ALB SG chỉ nhận HTTP từ IP máy bạn cho lần thử; app SG chỉ nhận port app từ ALB SG. Với demo public dùng HTTPS/ACM; HTTP lab không truyền credentials/dữ liệu nhạy cảm.

   Đáp án

   Tạo SG: SG-alb cho HTTP 80 từ IP máy bạn; SG-app cho port app chỉ từ SG-alb.

   bashReady

   SG_ALB=$(aws ec2 create-security-group --group-name saa-alb \  --description "ALB lab" --vpc-id "$VPC" --query GroupId --output text)aws ec2 authorize-security-group-ingress --group-id "$SG_ALB" \  --protocol tcp --port 80 --cidr YOUR-IP/32SG_APP=$(aws ec2 create-security-group --group-name saa-app \  --description "App lab" --vpc-id "$VPC" --query GroupId --output text)aws ec2 authorize-security-group-ingress --group-id "$SG_APP" \  --protocol tcp --port 8080 --source-group "$SG_ALB"

   Rule thứ hai tham chiếu SG thay vì IP, nên instance mới do ASG tạo ra vẫn nhận traffic từ ALB.

3. Tạo launch template bằng AMI hỗ trợ, role tối thiểu và bootstrap server trả JSON chứa marker instance cùng /health/ready. Đảm bảo đường bootstrap/package downloads và management có egress/endpoints cần thiết. Dùng app từ GĐ15 nếu đã có image; không đưa secret vào user data.

   Đáp án

   Launch template: AMI, instance profile tối thiểu, user data khởi động HTTP server trả JSON có instanceId và có /health/ready. Không đặt secret vào user data. Mẫu khung:

   bashReady

   aws ec2 create-launch-template --launch-template-name saa-lt \  --launch-template-data file://lt.json     # ImageId, InstanceType, UserData(base64), SG

4. Tạo target group, health check, ALB listener; ASG ở hai app subnets với min/desired 2, max 3. Bật ELB health checks cho ASG và đặt grace period phù hợp bootstrap.

   Đáp án

   Tạo target group, ALB và listener trước, rồi ASG ở hai private subnet, dùng ELB health check và grace period lớn hơn thời gian khởi động app. Grace period mặc định là 300 giây khi tạo ASG bằng console và 0 giây khi tạo bằng CLI hoặc SDK (tài liệu Auto Scaling), nên hãy đặt rõ, ví dụ lab 120 giây:

   bashReady

   aws elbv2 create-target-group --name saa-tg --protocol HTTP --port 8080 \  --vpc-id VPC-ID --target-type instance --health-check-path /health/readyaws elbv2 create-load-balancer --name saa-alb --type application \  --subnets PUBLIC-A PUBLIC-B --security-groups SG-ALB-IDaws elbv2 create-listener --load-balancer-arn ALB-ARN --protocol HTTP --port 80 \  --default-actions Type=forward,TargetGroupArn=TG-ARNaws autoscaling create-auto-scaling-group --auto-scaling-group-name saa-asg \  --launch-template LaunchTemplateName=saa-lt,Version='$Latest' \  --min-size 2 --max-size 3 --desired-capacity 2 \  --vpc-zone-identifier "PRIVATE-A,PRIVATE-B" --target-group-arns TG-ARN \  --health-check-type ELB --health-check-grace-period 120

5. Gọi endpoint nhiều lần; ghi marker trả về và healthy targets.

   Đáp án

   Gọi endpoint nhiều lần và ghi instanceId trả về; kiểm tra target:

   bashReady

   for i in $(seq 1 10); do curl -s http://ALB-DNS-NAME/; echo; doneaws elbv2 describe-target-health --target-group-arn TG-ARN

6. Chỉ terminate một instance thuộc ASG lab, giữ desired capacity. Quan sát ASG launch replacement, target health và thời gian endpoint phục hồi. Không terminate tài nguyên ngoài lab.

   Đáp án

   Chỉ terminate một instance của ASG lab, giữ desired capacity, và ghi mốc thời gian:

   bashReady

   aws autoscaling terminate-instance-in-auto-scaling-group \  --instance-id i-XXXX --no-should-decrement-desired-capacityaws autoscaling describe-scaling-activities --auto-scaling-group-name saa-asg

7. Bật target tracking phù hợp, tạo tải nhẹ có giới hạn từ máy của bạn; ghi metric/capacity và dừng tải. Nếu không scale, kiểm tra warmup, threshold và metric thay vì tăng tải vô hạn.

   Đáp án

   Target tracking nhẹ, rồi tạo tải có giới hạn từ máy bạn và dừng khi xong:

   jsonReady

   { "PredefinedMetricSpecification": { "PredefinedMetricType": "ASGAverageCPUUtilization" },  "TargetValue": 50.0 }

   bashReady

   aws autoscaling put-scaling-policy --auto-scaling-group-name saa-asg \  --policy-name cpu50 --policy-type TargetTrackingScaling \  --target-tracking-configuration file://tt.json

Internet --> IGW --> ALB (public-a, public-b)  SG-alb: 80 từ IP của bạn                      |  forward -> target group, health /health/ready          +-----------+-----------+          v                       v   app-a (private, AZ-a)   app-b (private, AZ-b)   SG-app: chỉ từ SG-alb          |  ASG min=2 desired=2 max=3  (ELB health check)          v   egress: NAT hoặc VPC endpoints (để tải package/ECR)   Mất 1 instance -> ASG thay -> target mới healthy   Mất cả AZ-a    -> còn app-b; DB/NAT nếu chỉ ở AZ-a thì vẫn là điểm đơn

aws autoscaling delete-auto-scaling-group --auto-scaling-group-name saa-asg --force-deleteaws elbv2 delete-listener --listener-arn LISTENER-ARNaws elbv2 delete-load-balancer --load-balancer-arn ALB-ARNaws elbv2 wait load-balancers-deleted --load-balancer-arns ALB-ARNaws elbv2 delete-target-group --target-group-arn TG-ARNaws ec2 delete-launch-template --launch-template-name saa-lt

aws ec2 delete-security-group --group-id "$SG_APP"aws ec2 delete-security-group --group-id "$SG_ALB"for a in $(aws ec2 describe-route-tables --route-table-ids "$RT_PUB" "$RT_APP" \    --query 'RouteTables[].Associations[].RouteTableAssociationId' --output text); do  aws ec2 disassociate-route-table --association-id "$a"; doneaws ec2 delete-route-table --route-table-id "$RT_PUB"aws ec2 delete-route-table --route-table-id "$RT_APP"for s in "$PUB_A" "$PUB_B" "$APP_A" "$APP_B"; do  aws ec2 delete-subnet --subnet-id "$s"; doneaws ec2 detach-internet-gateway --internet-gateway-id "$IGW" --vpc-id "$VPC"aws ec2 delete-internet-gateway --internet-gateway-id "$IGW"aws ec2 delete-vpc --vpc-id "$VPC"

Evidence: sơ đồ route/SG, hai targets thuộc hai AZ, timeline replacement, request errors và thời gian phục hồi. Terminate một instance kiểm tra instance failure, chưa chứng minh toàn bộ AZ failure; phần AZ outage làm tabletop: chỉ ra DB/egress còn phụ thuộc AZ nào.

Dọn: ASG về 0 rồi xóa, EC2/volumes còn lại, ALB/listeners/target group, launch template, NAT/EIP/endpoints riêng, SG/routes/subnets/IGW/VPC khi hết dependencies. Kiểm tra tài nguyên theo Region.

Nguồn: ASG + ELB, ASG health checks.

Lab B biến thể — app subnet không NAT, dựng bằng CloudFormation#

Kiểm chứng ngày 2026-10-05. Biến thể này cho app subnet không có đường ra Internet: không NAT, instance không có public IP. Nó chạy được vì ứng dụng mẫu chỉ dùng Python 3 có sẵn trong AL2023 (AL2023 Python), AMI lấy qua SSM public parameter (AL2023 trên EC2), và ALB gọi instance ngay trong VPC. Template có sẵn S3 gateway endpoint, loại endpoint không tính thêm phí (gateway endpoints), để dùng khi app cần đọc S3.

Chi phí cố định: bỏ được NAT gateway, vốn tính theo mỗi giờ tồn tại cộng mỗi GB xử lý, giờ lẻ tính tròn một giờ (VPC pricing; đơn giá theo Region, xem trang pricing). Public IPv4 tính 0,005 USD mỗi giờ mỗi địa chỉ, gồm cả địa chỉ của load balancer (cùng trang, đọc ngày 2026-10-05), nên ALB internet-facing vẫn có dòng này. ALB, EC2 và EBS: xem pricing của từng dịch vụ.

Bằng chứng: đã chạy cfn-lint 1.57.1 trên đúng template dưới đây (0 lỗi, 0 cảnh báo) và chạy thử phần ứng dụng Python trên máy local (trả JSON, HTTP 200; instanceId là unknown vì máy local không có IMDS). Template chưa deploy trên AWS thật.

AWSTemplateFormatVersion: "2010-09-09"Description: SAA Lab B - ALB + ASG hai AZ, app subnet private khong NATParameters:  MyIpCidr:    Type: String    Description: IP may ban dang x.x.x.x/32, duoc goi ALB qua HTTP 80  LatestAmiId:    Type: AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>    Default: /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64  InstanceType:    Type: String    Default: t3.microResources:  Vpc:    Type: AWS::EC2::VPC    Properties:      CidrBlock: 10.20.0.0/16      EnableDnsSupport: true      EnableDnsHostnames: true      Tags: [{ Key: Project, Value: aws-saa-lab }]  Igw:    Type: AWS::EC2::InternetGateway    Properties:      Tags: [{ Key: Project, Value: aws-saa-lab }]  IgwAttach:    Type: AWS::EC2::VPCGatewayAttachment    Properties: { VpcId: !Ref Vpc, InternetGatewayId: !Ref Igw }  PublicA:    Type: AWS::EC2::Subnet    Properties:      VpcId: !Ref Vpc      CidrBlock: 10.20.0.0/24      AvailabilityZone: !Select [0, !GetAZs ""]      Tags: [{ Key: Project, Value: aws-saa-lab }]  PublicB:    Type: AWS::EC2::Subnet    Properties:      VpcId: !Ref Vpc      CidrBlock: 10.20.1.0/24      AvailabilityZone: !Select [1, !GetAZs ""]      Tags: [{ Key: Project, Value: aws-saa-lab }]  AppA:    Type: AWS::EC2::Subnet    Properties:      VpcId: !Ref Vpc      CidrBlock: 10.20.10.0/24      AvailabilityZone: !Select [0, !GetAZs ""]      Tags: [{ Key: Project, Value: aws-saa-lab }]  AppB:    Type: AWS::EC2::Subnet    Properties:      VpcId: !Ref Vpc      CidrBlock: 10.20.11.0/24      AvailabilityZone: !Select [1, !GetAZs ""]      Tags: [{ Key: Project, Value: aws-saa-lab }]  PublicRt:    Type: AWS::EC2::RouteTable    Properties:      VpcId: !Ref Vpc      Tags: [{ Key: Project, Value: aws-saa-lab }]  PublicDefault:    Type: AWS::EC2::Route    DependsOn: IgwAttach    Properties:      RouteTableId: !Ref PublicRt      DestinationCidrBlock: 0.0.0.0/0      GatewayId: !Ref Igw  PublicAAssoc:    Type: AWS::EC2::SubnetRouteTableAssociation    Properties: { SubnetId: !Ref PublicA, RouteTableId: !Ref PublicRt }  PublicBAssoc:    Type: AWS::EC2::SubnetRouteTableAssociation    Properties: { SubnetId: !Ref PublicB, RouteTableId: !Ref PublicRt }  AppRt: # khong co route 0.0.0.0/0: app subnet khong ra Internet    Type: AWS::EC2::RouteTable    Properties:      VpcId: !Ref Vpc      Tags: [{ Key: Project, Value: aws-saa-lab }]  AppAAssoc:    Type: AWS::EC2::SubnetRouteTableAssociation    Properties: { SubnetId: !Ref AppA, RouteTableId: !Ref AppRt }  AppBAssoc:    Type: AWS::EC2::SubnetRouteTableAssociation    Properties: { SubnetId: !Ref AppB, RouteTableId: !Ref AppRt }  S3Endpoint: # gateway endpoint: duong rieng toi S3 neu app can doc S3    Type: AWS::EC2::VPCEndpoint    Properties:      VpcId: !Ref Vpc      VpcEndpointType: Gateway      ServiceName: !Sub com.amazonaws.${AWS::Region}.s3      RouteTableIds: [!Ref AppRt]  AlbSg:    Type: AWS::EC2::SecurityGroup    Properties:      GroupDescription: ALB lab, HTTP 80 tu IP cua ban      VpcId: !Ref Vpc      SecurityGroupIngress:        - { IpProtocol: tcp, FromPort: 80, ToPort: 80, CidrIp: !Ref MyIpCidr }      Tags: [{ Key: Project, Value: aws-saa-lab }]  AppSg:    Type: AWS::EC2::SecurityGroup    Properties:      GroupDescription: App lab, port 8080 chi tu ALB SG      VpcId: !Ref Vpc      SecurityGroupIngress:        - IpProtocol: tcp          FromPort: 8080          ToPort: 8080          SourceSecurityGroupId: !Ref AlbSg      Tags: [{ Key: Project, Value: aws-saa-lab }]  Alb:    Type: AWS::ElasticLoadBalancingV2::LoadBalancer    DependsOn: IgwAttach    Properties:      Type: application      Scheme: internet-facing      Subnets: [!Ref PublicA, !Ref PublicB]      SecurityGroups: [!Ref AlbSg]      Tags: [{ Key: Project, Value: aws-saa-lab }]  Tg:    Type: AWS::ElasticLoadBalancingV2::TargetGroup    Properties:      VpcId: !Ref Vpc      Protocol: HTTP      Port: 8080      TargetType: instance      HealthCheckPath: /health/ready      Tags: [{ Key: Project, Value: aws-saa-lab }]  Listener:    Type: AWS::ElasticLoadBalancingV2::Listener    Properties:      LoadBalancerArn: !Ref Alb      Protocol: HTTP      Port: 80      DefaultActions: [{ Type: forward, TargetGroupArn: !Ref Tg }]  Lt:    Type: AWS::EC2::LaunchTemplate    Properties:      LaunchTemplateData:        ImageId: !Ref LatestAmiId        InstanceType: !Ref InstanceType        SecurityGroupIds: [!Ref AppSg]        MetadataOptions: { HttpTokens: required }        UserData:          Fn::Base64: |            #!/bin/bash            cat > /opt/saa-app.py <<'PY'            import http.server, json, urllib.request            def imds(path):                base = "http://169.254.169.254/latest/"                try:                    t = urllib.request.Request(base + "api/token", method="PUT",                        headers={"X-aws-ec2-metadata-token-ttl-seconds": "300"})                    tok = urllib.request.urlopen(t, timeout=2).read().decode()                    r = urllib.request.Request(base + "meta-data/" + path,                        headers={"X-aws-ec2-metadata-token": tok})                    return urllib.request.urlopen(r, timeout=2).read().decode()                except OSError:                    return "unknown"            IID, AZ = imds("instance-id"), imds("placement/availability-zone")            class H(http.server.BaseHTTPRequestHandler):                def do_GET(self):                    body = json.dumps({"instanceId": IID, "az": AZ,                                       "path": self.path}).encode()                    self.send_response(200)                    self.send_header("Content-Type", "application/json")                    self.end_headers()                    self.wfile.write(body)            http.server.ThreadingHTTPServer(("", 8080), H).serve_forever()            PY            nohup python3 /opt/saa-app.py > /var/log/saa-app.log 2>&1 &  Asg:    Type: AWS::AutoScaling::AutoScalingGroup    Properties:      MinSize: "2"      MaxSize: "3"      DesiredCapacity: "2"      VPCZoneIdentifier: [!Ref AppA, !Ref AppB]      LaunchTemplate:        LaunchTemplateId: !Ref Lt        Version: !GetAtt Lt.LatestVersionNumber      TargetGroupARNs: [!Ref Tg]      HealthCheckType: ELB      HealthCheckGracePeriod: 120      Tags:        - { Key: Project, Value: aws-saa-lab, PropagateAtLaunch: true }Outputs:  AlbDns:    Value: !GetAtt Alb.DNSName

1. Deploy stack với IP của bạn, chờ xong, lấy DNS của ALB và gọi nhiều lần.

   Đáp án

   bashReady

   aws cloudformation deploy --template-file lab-b-no-nat.yaml \  --stack-name saa-lab-b --parameter-overrides MyIpCidr=YOUR-IP/32 \  --tags Project=aws-saa-labALB=$(aws cloudformation describe-stacks --stack-name saa-lab-b \  --query "Stacks[0].Outputs[?OutputKey=='AlbDns'].OutputValue" --output text)for i in $(seq 1 10); do curl -s "http://$ALB/"; echo; done

   Mong đợi: JSON có instanceId và az đổi giữa hai instance ở hai AZ. Nếu target không healthy, kiểm tra SG-app có nhận 8080 từ SG-alb và aws elbv2 describe-target-health; muốn vào máy thì thêm endpoint Session Manager (bước 2), đừng mở SSH ra Internet.

2. Chứng minh app subnet không ra Internet, rồi liệt kê những gì sẽ hỏng nếu app cần thêm phụ thuộc.

   Đáp án

   bashReady

   VPC=$(aws cloudformation describe-stack-resource --stack-name saa-lab-b \  --logical-resource-id Vpc --query StackResourceDetail.PhysicalResourceId \  --output text)APP_A=$(aws cloudformation describe-stack-resource --stack-name saa-lab-b \  --logical-resource-id AppA --query StackResourceDetail.PhysicalResourceId \  --output text)aws ec2 describe-route-tables \  --filters Name=association.subnet-id,Values="$APP_A" \  --query 'RouteTables[].Routes[].[DestinationCidrBlock,DestinationPrefixListId,GatewayId]'

   Route table gắn với app subnet chỉ có route local và route tới prefix list của S3 qua vpce-...; không có 0.0.0.0/0. Sẽ hỏng nếu app cần: cài package bằng dnf từ repo ngoài, kéo image từ registry Internet, gọi API bên thứ ba, hoặc dùng Session Manager. Session Manager cần interface endpoint cho ssm, ssmmessages và ec2messages (Systems Manager và VPC endpoints); mỗi interface endpoint có phí riêng, xem PrivateLink pricing. Lúc đó so tổng phí endpoints với một NAT trước khi chọn.

3. Xóa stack và kiểm tra không còn tài nguyên của lab.

   Đáp án

   bashReady

   aws cloudformation delete-stack --stack-name saa-lab-baws cloudformation wait stack-delete-complete --stack-name saa-lab-baws ec2 describe-vpcs --filters Name=tag:Project,Values=aws-saa-lab \  --query 'Vpcs[].VpcId'

   Mong đợi: wait kết thúc không lỗi và lệnh cuối trả []. Nếu xóa kẹt ở DELETE_FAILED, xem describe-stack-events để biết tài nguyên nào còn phụ thuộc. Quét toàn bộ theo tag ở mục 7, phần quét tài nguyên sót.

4. Lab C — SQS retry, visibility và DLQ#

Mục tiêu: chứng minh receive không xóa message và phân biệt retry với mất dữ liệu. Làm Standard queue trước.

1. Tạo Standard queue saa-jobs và Standard DLQ cùng account/Region; đặt redrive policy maxReceiveCount=3, visibility timeout 30 giây, retention DLQ dài hơn queue nguồn. Cho source queue được dùng DLQ qua redrive allow policy phù hợp.

   Đáp án

   Tạo DLQ trước, lấy ARN, rồi tạo queue nguồn. DLQ phải cùng account, cùng Region và cùng loại (Standard) với queue nguồn. Retention của DLQ phải dài hơn queue nguồn, vì với Standard queue message giữ nguyên thời điểm enqueue gốc khi chuyển sang DLQ (đồng hồ retention không được reset). Redrive allow policy mặc định cho phép mọi queue nguồn dùng DLQ; chỉ cần đặt nếu muốn siết:

   bashReady

   aws sqs create-queue --queue-name saa-jobs-dlq \  --attributes MessageRetentionPeriod=1209600       # 14 ngày; kiểm giới hạn tối đa trong trang quotasDLQ_URL=$(aws sqs get-queue-url --queue-name saa-jobs-dlq --query QueueUrl --output text)DLQ_ARN=$(aws sqs get-queue-attributes --queue-url "$DLQ_URL" \  --attribute-names QueueArn --query Attributes.QueueArn --output text)

   RedrivePolicy là chuỗi JSON nằm trong JSON, dễ sai khi quote trong zsh. Viết ra file thay vì gõ trên dòng lệnh:

   jsonReady

   {  "VisibilityTimeout": "30",  "RedrivePolicy": "{\"deadLetterTargetArn\":\"DLQ_ARN\",\"maxReceiveCount\":\"3\"}"}

   bashReady

   # thay DLQ_ARN trong attrs.json bằng giá trị thật, kiểm bằng: jq . attrs.jsonaws sqs create-queue --queue-name saa-jobs --attributes file://attrs.jsonJOBS_URL=$(aws sqs get-queue-url --queue-name saa-jobs --query QueueUrl --output text)

2. Send một message JSON giả { "jobId": "job-001", "kind": "demo" }.

   Đáp án

   Gửi job-001:

   bashReady

   aws sqs send-message --queue-url "$JOBS_URL" \  --message-body '{"jobId":"job-001","kind":"demo"}'

3. Receive với long polling, ghi MessageId/receipt handle và timestamp. Không delete; receive ngay có thể chưa thấy message vì đang invisible.

   Đáp án

   Receive bằng long polling (tối đa 20 giây; ở đây 10) và không delete; ghi MessageId, ReceiptHandle và giờ:

   bashReady

   aws sqs receive-message --queue-url "$JOBS_URL" --wait-time-seconds 10 \  --max-number-of-messages 1 --message-system-attribute-names All

   Gọi lại ngay: không thấy message vì đang invisible.

4. Sau visibility timeout, receive lại; kiểm tra ApproximateReceiveCount. Tiếp tục không delete tới khi message được chuyển DLQ; quá trình/metrics có thể có độ trễ.

   Đáp án

   Đợi hết visibility timeout (mặc định 30 giây, ở lab này đặt 30), receive lại; mỗi lần ghi ApproximateReceiveCount. Lặp đến khi message không còn xuất hiện ở queue nguồn; rồi kiểm tra DLQ:

   bashReady

   aws sqs get-queue-attributes --queue-url "$DLQ_URL" \  --attribute-names ApproximateNumberOfMessagesaws sqs receive-message --queue-url "$DLQ_URL" --wait-time-seconds 10

5. Send job-002, receive và delete bằng receipt handle của lần receive đó. MessageId không phải receipt handle.

   Đáp án

   Gửi job-002, receive, rồi delete bằng ReceiptHandle của chính lần receive đó:

   bashReady

   aws sqs delete-message --queue-url "$JOBS_URL" --receipt-handle "RECEIPT-HANDLE"

   ReceiptHandle gắn với từng lần receive; MessageId không dùng để delete.

6. Bài nâng cao với worker từ GĐ10: lưu kết quả theo jobId unique; chủ động crash sau commit trước delete. Cho retry và chứng minh chỉ có một business result.

   Đáp án

   Nâng cao (idempotency nghiệp vụ). Worker ghi kết quả vào bảng có ràng buộc duy nhất theo jobId, rồi mới delete. Cố tình crash sau khi commit và trước khi delete, để message được giao lại:

   textReady

   -- PostgreSQL (chưa chạy)CREATE TABLE job_results (job_id text PRIMARY KEY, result jsonb NOT NULL);INSERT INTO job_results (job_id, result) VALUES ($1, $2)ON CONFLICT (job_id) DO NOTHING;   -- lần giao lại: 0 hàng được chèn

send job-001 --> [saa-jobs] --receive #1--> (invisible 30s) --hết hạn-->                     ^                                           |                     +--------- hiện lại (chưa delete) <---------+   receive #1,#2,#3 không delete -> vượt maxReceiveCount=3 -> [saa-jobs-dlq]   job-002: receive -> xử lý -> delete-message(ReceiptHandle của lần đó) -> xong

aws sqs delete-queue --queue-url "$JOBS_URL"aws sqs delete-queue --queue-url "$DLQ_URL"aws cloudwatch delete-alarms --alarm-names saa-dlq-not-empty   # nếu đã tạo

Lệnh quan sát queue của bạn; mỗi receive có thể làm message invisible:

aws sqs receive-message --queue-url YOUR-LAB-QUEUE-URL --wait-time-seconds 10 --max-number-of-messages 1 --message-system-attribute-names All --profile YOUR-LAB-PROFILE --region YOUR-LAB-REGION

Evidence: cùng job nhận lại, receive count tăng, message lỗi tới DLQ, job thành công được delete. Phần receive/DLQ chưa chứng minh idempotency business; cần phần worker nâng cao để chứng minh.

Dọn: dừng worker trước, xóa hai queue và policies/alarms riêng. Không redrive message lỗi hàng loạt khi chưa sửa nguyên nhân.

Nguồn: SQS visibility, DLQ.

5. Lab D — RDS restore và failover#

Mục tiêu: chứng minh backup đọc lại được dữ liệu và phân biệt restore/failover. Lab có DB/storage tính phí; bắt đầu với dữ liệu nhỏ và diễn tập trên giấy nếu chưa cần tạo DB.

1. Tạo RDS PostgreSQL private với DB subnet group ít nhất hai AZ theo yêu cầu dịch vụ; chọn Single-AZ cho restore lab, bật backup retention phù hợp, SG chỉ nhận từ app/test client trong VPC.

   Đáp án

   Tạo DB PostgreSQL private. DB subnet group cần subnet ở ít nhất hai AZ; chọn Single-AZ cho phần restore, bật automated backup, SG chỉ nhận từ client trong VPC, không public.

   Trước hết tạo SG và DB subnet group (dùng lại VPC và hai private subnet của Lab B, hoặc VPC sandbox của bạn; SG-CLIENT là SG của máy client trong VPC):

   bashReady

   SG_DB=$(aws ec2 create-security-group --group-name saa-db \  --description "RDS lab" --vpc-id "$VPC" --query GroupId --output text)aws ec2 authorize-security-group-ingress --group-id "$SG_DB" \  --protocol tcp --port 5432 --source-group SG-CLIENTaws rds create-db-subnet-group --db-subnet-group-name saa-db-subnets \  --db-subnet-group-description "SAA lab DB subnets" \  --subnet-ids "$APP_A" "$APP_B" --tags Key=Project,Value=aws-saa-lab

   Trong các lệnh dưới, SUBNET-GROUP là saa-db-subnets và SG-DB là giá trị $SG_DB.

   bashReady

   aws rds create-db-instance --db-instance-identifier saa-pg \  --engine postgres --db-instance-class CLASS-NHO-NHAT \  --allocated-storage 20 --master-username saaadmin \  --manage-master-user-password \  --db-subnet-group-name SUBNET-GROUP --vpc-security-group-ids SG-DB \  --no-publicly-accessible --no-multi-az --backup-retention-period 1aws rds wait db-instance-available --db-instance-identifier saa-pg

   --manage-master-user-password để RDS lưu mật khẩu trong Secrets Manager; không đặt mật khẩu trong lệnh hay file.

2. Kết nối bằng client trong VPC, dùng TLS verify theo docs engine. Tạo bảng lab, insert dữ liệu giả, ghi count và vài khóa đã biết; không mở DB public chỉ để kết nối thuận tiện.

   Đáp án

   Từ client trong VPC (EC2 nhỏ hoặc Session Manager), kết nối và tạo dữ liệu giả; ghi count(*) và vài khóa:

   textReady

   CREATE TABLE notes (id int PRIMARY KEY, body text);INSERT INTO notes SELECT g, 'before-snapshot-' || g FROM generate_series(1,5) g;SELECT count(*) FROM notes;   -- 5

3. Tạo manual snapshot sau khi dữ liệu đã commit. Ghi thời gian snapshot sẵn sàng; insert thêm bản ghi sau snapshot.

   Đáp án

   Snapshot sau khi commit, chờ sẵn sàng, rồi chèn thêm dữ liệu sau snapshot:

   bashReady

   aws rds create-db-snapshot --db-instance-identifier saa-pg \  --db-snapshot-identifier saa-pg-snap1aws rds wait db-snapshot-available --db-snapshot-identifier saa-pg-snap1# sau đó: INSERT INTO notes VALUES (6, 'after-snapshot');

4. Restore snapshot sang DB instance mới, chọn subnet/SG/secret phù hợp. Kiểm tra endpoint mới và dữ liệu tại thời điểm snapshot; bản ghi thêm sau snapshot không có.

   Đáp án

   Restore sang instance mới, chỉ định rõ subnet group và SG (không để mặc định):

   bashReady

   aws rds restore-db-instance-from-db-snapshot \  --db-instance-identifier saa-pg-restored --db-snapshot-identifier saa-pg-snap1 \  --db-subnet-group-name SUBNET-GROUP --vpc-security-group-ids SG-DB \  --no-publicly-accessibleaws rds wait db-instance-available --db-instance-identifier saa-pg-restored

5. Nếu học PITR, chọn thời điểm nằm trong restorable window và restore thành instance mới. Ghi target time, thời gian bắt đầu/kết thúc và kết quả dữ liệu.

   Đáp án

   PITR: lấy mốc restore trong cửa sổ, rồi restore thành instance mới khác:

   bashReady

   aws rds describe-db-instances --db-instance-identifier saa-pg \  --query 'DBInstances[0].LatestRestorableTime'aws rds restore-db-instance-to-point-in-time \  --source-db-instance-identifier saa-pg \  --target-db-instance-identifier saa-pg-pitr \  --restore-time 2026-10-05T10:00:00Z \  --db-subnet-group-name SUBNET-GROUP --vpc-security-group-ids SG-DB

   (restore-time là ví dụ; dùng mốc nằm giữa cửa sổ của bạn. Hoặc --use-latest-restorable-time.)

6. Tùy chọn riêng: dùng Multi-AZ DB instance trong sandbox, reboot với failover khi dịch vụ hỗ trợ; quan sát client reconnect và downtime. Đọc rõ cách failover theo deployment type trước khi thao tác.

   Đáp án

   Tùy chọn failover (chỉ sandbox): đổi sang Multi-AZ instance rồi reboot với failover:

   bashReady

   aws rds modify-db-instance --db-instance-identifier saa-pg --multi-az --apply-immediatelyaws rds wait db-instance-available --db-instance-identifier saa-pgaws rds reboot-db-instance --db-instance-identifier saa-pg --force-failover

   Với Multi-AZ DB cluster thì dùng lệnh failover riêng của cluster; đọc trang failover theo deployment type trước khi thử.

 saa-pg (Single-AZ) --snapshot (sau commit)--> saa-pg-snap1      | insert thêm (sau snapshot)                 |      |                                            v restore => DB MỚI      +--transaction log lên S3 (mỗi 5 phút)   saa-pg-restored (endpoint mới)              \__ PITR: restore-time trong cửa sổ => DB MỚI khác nữa Tùy chọn: Multi-AZ instance --reboot --force-failover--> standby lên primary           (endpoint DNS giữ tên; kết nối TCP cũ đứt, app phải reconnect)

aws rds delete-db-instance --db-instance-identifier saa-pg-restored \  --skip-final-snapshot --delete-automated-backupsaws rds delete-db-instance --db-instance-identifier saa-pg-pitr \  --skip-final-snapshot --delete-automated-backupsaws rds delete-db-instance --db-instance-identifier saa-pg \  --skip-final-snapshot --delete-automated-backupsaws rds delete-db-snapshot --db-snapshot-identifier saa-pg-snap1

for i in saa-pg saa-pg-restored saa-pg-pitr; do  aws rds wait db-instance-deleted --db-instance-identifier "$i"doneaws rds delete-db-subnet-group --db-subnet-group-name saa-db-subnetsaws ec2 delete-security-group --group-id "$SG_DB"

Evidence: snapshot/PITR restore thành công, dữ liệu đúng thời điểm, thời gian thực tế, app reconnect. Thời gian trong lab nhỏ không phải RTO production; còn thời gian dựng network/app, đổi endpoint, validation và DNS.

Dọn: app/test client, DB gốc và DB restored, snapshot lab/retained backups không cần giữ, secret và log riêng theo retention. RDS stop không phải cleanup vĩnh viễn; storage vẫn có thể tính phí và DB có cơ chế tự start lại.

Nguồn: RDS restore snapshot, PITR, stopping RDS.

6. Lab E — CloudFront và S3 origin private#

Mục tiêu: S3 URL trực tiếp không public, CloudFront vẫn trả static object; phân biệt quyền origin với quyền viewer.

1. Tạo private S3 bucket với Block Public Access; upload một static file giả bằng danh tính setup.

   Đáp án

   Bucket private, Block Public Access bật, Object Ownership là bucket owner enforced (mặc định bucket mới; OAC yêu cầu). Upload file giả:

   bashReady

   echo "<h1>saa lab</h1>" > index.htmlaws s3api put-object --bucket "$BUCKET" --key index.html --body index.html \  --content-type text/html

2. Tạo distribution với S3 REST origin, OAC ký request và bucket policy chỉ cho distribution đó đọc objects. Không chọn S3 website endpoint cho bài OAC này.

   Đáp án

   Tạo OAC kiểu S3, ký luôn luôn:

   bashReady

   aws cloudfront create-origin-access-control --origin-access-control-config \  Name=saa-oac,SigningProtocol=sigv4,SigningBehavior=always,OriginAccessControlOriginType=s3

   Ghi Id trả về. Tạo distribution (console: origin là S3 REST endpoint của bucket, không phải website endpoint; Origin access: Origin access control settings; chọn OAC trên; default root object index.html). Ghi ID distribution.

   Hoặc tạo bằng CLI. File dist.json tối thiểu (tên field đối chiếu aws cloudfront create-distribution --generate-cli-skeleton; cache policy ID là của managed policy CachingOptimized theo tài liệu managed cache policies):

   jsonReady

   {  "CallerReference": "saa-lab-e-2026-10-05",  "Comment": "saa lab E",  "Enabled": true,  "DefaultRootObject": "index.html",  "Origins": { "Quantity": 1, "Items": [{    "Id": "s3-origin",    "DomainName": "BUCKET.s3.REGION.amazonaws.com",    "S3OriginConfig": { "OriginAccessIdentity": "" },    "OriginAccessControlId": "OAC_ID" }] },  "DefaultCacheBehavior": {    "TargetOriginId": "s3-origin",    "ViewerProtocolPolicy": "redirect-to-https",    "CachePolicyId": "658327ea-f89d-4fab-a63d-7e88639e58f6" }}

   bashReady

   aws cloudfront create-distribution --distribution-config file://dist.json \  --query 'Distribution.[Id,DomainName]' --output text

   OriginAccessIdentity để chuỗi rỗng vì dùng OAC thay cho OAI. CallerReference phải khác nhau giữa các lần tạo.

   Bucket policy cho đúng distribution đó (thay ACCOUNT_ID, BUCKET, DIST_ID):

   jsonReady

   {  "Version": "2012-10-17",  "Statement": [{    "Sid": "AllowCloudFrontRead",    "Effect": "Allow",    "Principal": { "Service": "cloudfront.amazonaws.com" },    "Action": "s3:GetObject",    "Resource": "arn:aws:s3:::BUCKET/*",    "Condition": { "StringEquals": {      "AWS:SourceArn":        "arn:aws:cloudfront::ACCOUNT_ID:distribution/DIST_ID" } }  }]}

   bashReady

   aws s3api put-bucket-policy --bucket "$BUCKET" --policy file://oac-policy.json

3. Chờ distribution deploy; gọi CloudFront URL → đọc được, gọi unsigned S3 object URL → bị từ chối. Danh tính IAM có quyền vẫn có thể đọc S3: phép thử public dùng request không ký.

   Đáp án

   Chờ distribution deploy rồi gọi hai đường truy cập (đường S3 gọi không ký, không dùng credentials):

   bashReady

   aws cloudfront wait distribution-deployed --id DIST_IDcurl -sI https://DOMAIN.cloudfront.net/index.html          # 200curl -sI https://"$BUCKET".s3."$AWS_REGION".amazonaws.com/index.html   # 403

4. Đọc response headers/cache status và xem hit/miss sau nhiều request. Đặt cache policy cho nội dung static; không upload dữ liệu private của user vào bài này.

   Đáp án

   Gọi lặp và đọc header cache:

   bashReady

   for i in 1 2 3; do  curl -sI https://DOMAIN.cloudfront.net/index.html | grep -i x-cachedone

5. Tùy chọn: yêu cầu signed viewer URL/cookie, cấu hình trusted key group và thử request không ký/bị hết hạn. Không commit signing private key.

   Đáp án

   Tùy chọn viewer: tạo trusted key group (public key bạn tải lên, private key giữ ngoài repo), đặt behavior yêu cầu signed URL/cookie, rồi thử request không ký, hết hạn, hợp lệ. Dùng key group, không dùng root key pair.

   Mẫu CLI, chưa chạy (tham số đã đối chiếu help). Với trusted key group, Key-Pair-Id trong signed URL là ID của CloudFront public key:

   bashReady

   openssl genrsa -out private_key.pem 2048     # giữ ngoài repoopenssl rsa -pubout -in private_key.pem -out public_key.pemjq -n --arg k "$(cat public_key.pem)" --arg r "saa-$(date +%s)" \  '{CallerReference: $r, Name: "saa-lab-pub", EncodedKey: $k}' > pubkey.jsonPUB_ID=$(aws cloudfront create-public-key --public-key-config file://pubkey.json \  --query PublicKey.Id --output text)aws cloudfront create-key-group \  --key-group-config "Name=saa-lab-kg,Items=$PUB_ID" --query KeyGroup.Id --output text

   Gắn key group ID vào TrustedKeyGroups của cache behavior (get-distribution-config rồi update-distribution --if-match ETAG), chờ deploy, rồi ký URL:

   bashReady

   aws cloudfront sign --url "https://DIST-DOMAIN/index.html" \  --key-pair-id "$PUB_ID" --private-key file://private_key.pem \  --date-less-than "$(date -u -v+10M +%Y-%m-%dT%H:%M:%SZ)"   # macOS date

   Nguồn: signed URL canned policy.

 Viewer --HTTPS--> CloudFront (cache) --SigV4 do OAC ký--> S3 bucket (private) Viewer --trực tiếp--> https://BUCKET.s3...amazonaws.com/index.html -> 403 bucket policy: Allow cloudfront.amazonaws.com GetObject                nếu AWS:SourceArn = distribution của bạn OAC  = bảo vệ ORIGIN (chỉ CloudFront đọc được S3) Signed URL/cookie = bảo vệ VIEWER (ai được xem qua CloudFront)

aws cloudfront get-distribution-config --id DIST_ID > dist.json   # lấy ETag + config# sửa DistributionConfig.Enabled=false rồi:aws cloudfront update-distribution --id DIST_ID \  --distribution-config file://dist-config-disabled.json --if-match ETAG-CUaws cloudfront wait distribution-deployed --id DIST_IDaws cloudfront get-distribution --id DIST_ID --query ETag --output textaws cloudfront delete-distribution --id DIST_ID --if-match ETAG-MOIaws cloudfront delete-origin-access-control --id OAC_ID --if-match OAC-ETAG

Evidence: hai đường truy cập có kết quả khác nhau; giải thích OAC không tự chặn viewer public. Với signed viewer config, ghi kết quả valid/invalid/expired.

Dọn: disable distribution, chờ triển khai rồi xóa; bỏ OAC/bucket policy riêng và dọn bucket. Kiểm tra objects/versions và tài nguyên phụ trợ.

Nguồn: OAC setup, signed URLs.

7. Lab F — Cost estimate và alarm có kiểm chứng#

Mục tiêu: biết cost drivers và kiểm tra alarm từ lỗi có kiểm soát.

1. Dùng Pricing Calculator lập hai phương án cho cùng workload: Lambda/API Gateway so với ECS/Fargate/ALB. Nhập request, runtime, RAM, hours, logs, database và network; ghi phần chưa tính.

   Đáp án

   Calculator, hai phương án cùng workload (ví dụ 20 triệu request/tháng, 200 ms mỗi request, 512 MB, log 30 ngày): A = API Gateway + Lambda (+ DynamoDB nếu cần dữ liệu), B = ALB + ECS/Fargate hai task + RDS nếu cần. Với mỗi dòng ghi đơn vị và con số nhập. Dùng bảng kết quả để tìm điểm hòa vốn như bài ở GĐ32 mục 1.

2. So bình thường/peak; thử đổi retention logs, traffic S3 qua NAT/endpoints và số AZ. Không xóa HA requirement chỉ để một phương án rẻ hơn.

   Đáp án

   Biến thể: đổi retention log (ngắn hơn / dài hơn), chuyển traffic S3 từ NAT sang gateway endpoint, đổi số AZ (1 so với 2). Không bỏ yêu cầu HA chỉ để phương án rẻ hơn.

3. Với lab compute đã tạo, đặt alarm cho metric có thể thử an toàn: error count hoặc unhealthy target. Cấu hình threshold, periods và missing data behavior.

   Đáp án

   Tạo SNS topic và alarm trên tài nguyên Lab B (thay ARN):

   bashReady

   aws sns create-topic --name saa-lab-alertsaws sns subscribe --topic-arn TOPIC-ARN --protocol email --notification-endpoint you@example.com# mở email, bấm xác nhậnaws cloudwatch put-metric-alarm --alarm-name saa-unhealthy \  --namespace AWS/ApplicationELB --metric-name UnHealthyHostCount \  --dimensions Name=TargetGroup,Value=targetgroup/saa-tg/TG-ID \            Name=LoadBalancer,Value=app/saa-alb/LB-ID \  --statistic Maximum --period 60 --evaluation-periods 2 --threshold 1 \  --comparison-operator GreaterThanOrEqualToThreshold \  --treat-missing-data notBreaching --alarm-actions TOPIC-ARN --ok-actions TOPIC-ARN

4. Kích hoạt lỗi trong resource lab, kiểm tra trạng thái alarm và kênh thông báo của chính bạn; khôi phục rồi xác nhận alarm về trạng thái mong đợi. Kênh email cần xác nhận subscription nếu dùng SNS.

   Đáp án

   Kiểm thử hai tầng. Tầng thông báo (không phá tài nguyên): ép trạng thái để thử đường SNS; trạng thái này sẽ tự quay về theo dữ liệu thật ở lần đánh giá tiếp theo:

   bashReady

   aws cloudwatch set-alarm-state --alarm-name saa-unhealthy \  --state-value ALARM --state-reason "test notification path"aws cloudwatch describe-alarm-history --alarm-name saa-unhealthy --max-items 5

   Tầng thật: làm một instance của Lab B trả health check lỗi (ví dụ đổi health path hoặc dừng tiến trình app trên đúng một instance lab), ghi giờ, chờ alarm sang ALARM, rồi khôi phục và chờ về OK.

5. Sau cleanup, xem Billing/Cost Explorer và danh sách tài nguyên. Dữ liệu billing có độ trễ; ghi thời điểm cần kiểm tra lại, không kết luận zero cost ngay sau xóa.

   Đáp án

   Sau cleanup, xem Billing và Cost Explorer, kiểm tra lại sau độ trễ billing (không nêu số vì chưa xác minh), và đối chiếu danh sách tài nguyên.

target unhealthy --> metric UnHealthyHostCount --> alarm (2 chu kỳ liên tiếp)        --> ALARM --> SNS topic --> email của bạn (phải xác nhận subscription) khôi phục instance --> metric về 0 --> alarm OK --> (tùy chọn) thông báo OK

aws cloudwatch delete-alarms --alarm-names saa-unhealthyaws sns delete-topic --topic-arn TOPIC-ARN

Evidence: hai estimate cùng assumptions, nguồn giá/ngày/Region, alarm đã trigger/recover, inventory tài nguyên đã dọn. Ngoài vài đơn giá có ghi nguồn và ngày kiểm (ví dụ IPv4 công khai ở Lab B biến thể), tài liệu này không dùng giá cố định để tránh estimate lỗi thời; mọi estimate lấy từ Calculator.

Nguồn: Calculator, CloudWatch alarms.

Quét tài nguyên sót sau các lab#

Kiểm chứng ngày 2026-10-05 với tài liệu AWS ở cuối mục và phần help của AWS CLI 2.35.14 (aws s3 rb help, aws ec2 describe-regions help). Lệnh dưới đây chưa chạy trên AWS thật; chỉ kiểm tên lệnh và tham số bằng help.

Mỗi lab đã có phần dọn riêng; bước này là lưới an toàn cuối, làm sau khi dọn xong mọi lab. Ba điểm cần nhớ:

• GetResources của Resource Groups Tagging API chỉ trả tài nguyên đang có tag hoặc từng có tag, trong một Region được chỉ định, nên phải lặp qua từng Region. Tài nguyên từng có tag nhưng nay không còn tag hiện với "Tags": [].
• GetResources không trả tài nguyên chưa từng gắn tag. Tài liệu AWS hướng dẫn tìm loại này bằng Resource Explorer với truy vấn tag:none. Vì vậy lab nào không gắn tag Project=aws-saa-lab thì vẫn phải kiểm bằng phần dọn của lab đó.
• aws s3 rb --force không xóa object versions, nên bucket từng bật versioning sẽ không xóa được nếu còn version. Khi versioning chuyển sang Suspended, các object hiện có không thay đổi, tức version cũ vẫn còn. Cách xóa hết versions và delete markers nằm ở phần dọn của GĐ33 mục 2.

1. Sau khi dọn xong các lab, quét mọi Region đang bật để tìm tài nguyên còn tag Project=aws-saa-lab, rồi kiểm bucket nào còn version. Ghi kết quả vào bằng chứng của Lab F.

   Đáp án

   Quét tag theo từng Region (describe-regions không có --all-regions chỉ trả các Region đang bật cho account):

   bashReady

   for R in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do  echo "== $R"  aws resourcegroupstaggingapi get-resources --region "$R" \    --tag-filters Key=Project,Values=aws-saa-lab \    --query 'ResourceTagMappingList[].ResourceARN' --output textdone

   Kiểm trạng thái versioning của từng bucket, rồi xem bucket lab còn version hay delete marker không:

   bashReady

   for B in $(aws s3api list-buckets --query 'Buckets[].Name' --output text); do  echo "$B $(aws s3api get-bucket-versioning --bucket "$B" --query Status --output text)"doneaws s3api list-object-versions --bucket BUCKET --max-items 5 \  --query '{versions: Versions[].Key, markers: DeleteMarkers[].Key}'

   Kết quả mong đợi: vòng lặp tag không in ARN nào, hoặc chỉ in ARN của tài nguyên bạn chủ động giữ lại và ghi lý do. Bucket có Enabled hoặc Suspended mà còn version là chưa dọn xong: quay lại phần dọn của Lab A. KMS key ở trạng thái Pending deletion vẫn mang tag nên có thể còn hiện ra: đó là bình thường cho tới khi hết thời gian chờ xóa. Role IAM, SNS subscription và log group tạo tay cho lab cũng kiểm riêng (ví dụ aws iam list-roles --query 'Roles[].RoleName'), vì chúng có thể không mang tag lab. Sau đó vẫn xem Billing theo bước 5 ở trên.

Nguồn: GetResources, Resource Explorer search query syntax, Versioning-suspended buckets.

8. Case study — SaaS xử lý tài liệu và RAG#

Yêu cầu giả định để luyện kiến trúc: user upload PDF, xử lý bất đồng bộ, hỏi đáp qua LLM; metadata/billing cần transaction; API chịu mất một AZ; downtime khi mất Region chấp nhận vài giờ. Không có yêu cầu train ML model.

Browser → CloudFront → frontend static private S3 originBrowser → ALB HTTPS → ECS/Fargate API (hai AZ)                       ├→ RDS PostgreSQL Multi-AZ: metadata/billing                       ├→ Secrets Manager: credentials                       └→ presigned URL → browser upload S3 privateS3 upload event → SQS → worker → extraction/embedding → DB/indexBrowser → API → retrieval (tenant filter) → external LLM/Bedrock nếu chọnCloudWatch: queue age, errors, latency; CloudTrail: AWS API audit

Phân biệt frontend static dùng CloudFront với PDF user private: không cho viewer public đọc mọi PDF. API phải xác thực user, chọn key/prefix và quyền tenant; IAM của worker không thay tenant authorization trong app.

Giải thích quyết định: PostgreSQL cho quan hệ/transaction; S3 cho file; queue để xử lý burst; worker compute chọn theo duration/RAM; app hai AZ và DB Multi-AZ cho AZ failure. Nếu cần OCR managed có thể đánh giá Textract; gọi LLM không tự tạo nhu cầu SageMaker.

S3 → SQS trực tiếp dùng Standard queue cùng Region và queue policy cho S3 với source conditions phù hợp; nếu cần FIFO phải thiết kế đường trung gian hỗ trợ như EventBridge. Event có thể trùng; worker dùng idempotency. Không để output ghi lại prefix trigger tạo loop.

Recovery: backup/PITR và bản dữ liệu ở recovery Region theo RPO; template/config/secret/permissions phải có kế hoạch dựng lại. DNS failover riêng không đủ. Theo dõi egress worker → LLM, queue age, DB connections và chi phí embedding.

Bài tập: vẽ phiên bản tối giản cho MVP; thêm AZ resilience; thêm Region recovery. Với mỗi phiên bản, ghi tài nguyên tăng thêm, yêu cầu được đáp ứng và chi phí tăng. Xem capstone GĐ25 cho hành vi sản phẩm.

(1) MVP tối giản: chưa chịu mất AZ, Region recovery = dựng lại từ backup Browser -> CloudFront -> S3 (static, private, OAC) Browser -> ALB (subnet ở 2 AZ, theo yêu cầu của ALB) -> 1 task API (AZ-a) API -> RDS PostgreSQL Single-AZ ; presigned URL -> S3 private (PDF) S3 event -> SQS (+DLQ) -> 1 worker (AZ-a) -> DB/index Backup: automated backup RDS + versioning S3 ; IaC trong repo(2) + chịu mất một AZ ALB -> API task x2 (AZ-a, AZ-b)      RDS Multi-AZ (instance hoặc cluster) SQS -> worker x2 (hai AZ)            egress: NAT mỗi AZ hoặc Regional NAT,                                      hoặc endpoints; rà điểm đơn còn lại(3) + khôi phục khi mất Region (downtime vài giờ chấp nhận) Region chính                          Region phụ (chưa chạy full app) RDS ---- snapshot copy / backup ---->  bản sao backup (hoặc replica tùy RPO) S3  ---- replication (versioning) --->  bucket đích IaC + image + secrets + quyền: có kế hoạch dựng lại ở Region phụ DNS chuyển sang Region phụ SAU khi dựng xong và validate

Nguồn kỹ thuật event: S3 notification destinations, S3 notification permissions.

9. Case study — ba yêu cầu, ba thiết kế khác nhau#

Với mỗi dòng, thay một requirement: static site có user-private content; báo cáo phải đọc ngay write mới; batch có deadline cứng và không chịu interruption. Kiến trúc phải được đánh giá lại theo yêu cầu mới.

10. Câu hỏi tự luyện — security và networking#

Chọn trước khi mở đáp án. Mỗi câu chọn một phương án phù hợp nhất với các điều kiện đã nêu.

1. EC2 phải đọc raw/* trong S3, không lưu static credentials. Chọn gì?

A. Access key trong image. B. EC2 instance role với quyền tối thiểu. C. Public bucket. D. Root credentials trong environment.

2. Role có Allow đọc S3 nhưng SCP áp dụng có explicit Deny action đó. Kết quả?

A. Allow vì role gần resource. B. Allow khi retry. C. Deny. D. SCP tự cấp quyền administrator.

3. App private chỉ cần đọc S3 trong Region, muốn tránh đường NAT cho traffic này. Chọn gì?

A. IGW và không cần public IP. B. S3 gateway endpoint với route/policy phù hợp. C. NLB. D. Route 53 weighted record.

4. EC2 không có public IP ở subnet có route IGW. Vì sao inbound IPv4 Internet trực tiếp không vào được?

A. Mọi subnet public đều tự cấp public IP. B. Cần địa chỉ public và các lớp route/firewall phù hợp. C. IAM role mở network. D. S3 endpoint cấp public IP.

11. Câu hỏi tự luyện — resilience và messaging#

5. Worker Standard SQS commit kết quả rồi chết trước delete. Yêu cầu không tạo kết quả business trùng. Chọn gì?

A. Bỏ retry. B. Idempotency theo job ID với transaction/constraint phù hợp. C. Chỉ tăng CPU. D. Xóa message trước xử lý.

6. Cần ba consumer độc lập đều nhận cùng event, mỗi consumer có buffer riêng. Chọn gì?

A. Ba worker cùng một queue. B. SNS fan-out tới ba SQS queues. C. Một SG cho ba worker. D. ASG desired 3.

7. API cần chịu mất một AZ. Thiết kế nào xử lý trực tiếp failure domain đó tốt hơn?

A. Hai EC2 cùng subnet một AZ. B. App nhiều AZ + LB và data tier có HA phù hợp. C. Một máy lớn hơn. D. Backup app disk hàng tháng.

8. Core data đang replicate tới recovery site; full app đã chạy capacity nhỏ, cần scale khi failover. Chiến lược?

A. Backup/restore thuần. B. Warm standby. C. Pilot light chỉ giữ core và chưa chạy full app. D. Active/active đủ tải cả hai site.

12. Câu hỏi tự luyện — performance và dữ liệu#

9. RDS Multi-AZ DB instance truyền thống đã có standby; muốn scale báo cáo đọc. Chọn gì?

A. Route SELECT tới standby đó. B. Đánh giá read replica và sửa query/index, chấp nhận lag phù hợp. C. Public DB. D. Tăng số ALB.

10. DynamoDB GSI trả dữ liệu cũ ngay sau write; cần strong read bằng key chính. Chọn gì?

A. ConsistentRead=true trên GSI. B. Strongly consistent read trên base table với key phù hợp. C. TTL. D. CloudFront invalidation.

11. Nhiều Linux instances cần mount shared filesystem. Chọn dịch vụ mặc định để đánh giá?

A. EFS. B. Instance store một máy. C. S3 thay POSIX mount không cần thay app. D. Snapshot EBS.

12. Cần archive ít đọc nhưng retrieval milliseconds. Chọn class để đánh giá?

A. Glacier Deep Archive. B. Glacier Flexible Retrieval không restore. C. Glacier Instant Retrieval. D. Chỉ download trước mỗi request.

13. Câu hỏi tự luyện — cost và migration#

13. Batch jobs có checkpoint, chấp nhận interruption và chạy lại. Hướng giảm compute cost?

A. Spot với queue/checkpoint/retry và capacity fallback theo deadline. B. Dedicated Host bất kể license. C. Luôn máy lớn nhất. D. Bỏ checkpoint.

14. Compute ổn định, cam kết chi tiêu theo giờ nhưng muốn linh hoạt theo phạm vi plan. Chọn gì?

A. Savings Plans phù hợp. B. Capacity Reservation mặc định discount. C. Budget alert. D. EIP.

15. Cần database migration full load rồi tiếp tục replicate changes, source/target hỗ trợ. Chọn gì?

A. DataSync thay CDC database. B. DMS, kèm schema assessment/validation/cutover. C. CloudFront. D. WAF.

16. Budget vượt ngưỡng nhưng tài nguyên vẫn chạy. Hiểu đúng thế nào?

A. AWS chắc chắn lỗi. B. Budget alert không phải hard cap; kiểm tra action đã cấu hình và dữ liệu có độ trễ. C. Mọi tài nguyên tự xóa. D. Chi phí không bao giờ vượt ngưỡng.

Ngân hàng câu hỏi theo domain SAA-C03#

Kiểm chứng ngày 2026-10-05 với exam guide SAA-C03 và tài liệu AWS ghi ở cuối đáp án của từng câu. 65 câu dưới đây (số 17–81, nối tiếp 16 câu ở mục 10–13) do guide tự viết theo task statement của exam guide; không chép và không dựng lại từ đề thi thật hay exam dumps. Chưa chạy trên AWS thật: đáp án lập luận từ tài liệu AWS, và link "Nguồn" là trang quyết định đáp án.

Cách dùng: làm hết một khối task rồi mới mở đáp án, ghi câu sai vào error notebook ở mục 14. Câu một đáp án có bốn phương án, giống dạng multiple choice trong exam guide (một đúng, ba sai). Câu ghi "Chọn HAI" có năm phương án và hai đáp án đúng; exam guide gọi dạng này là multiple response (hai đáp án đúng trở lên trong năm phương án trở lên).

Số câu mỗi domain lấy 65 nhân trọng số rồi làm tròn theo phần dư lớn nhất. Vị trí đáp án đúng được trộn đều: 53 câu một đáp án có đáp án ở A/B/C/D lần lượt 14/13/13/13 lần; 12 câu "Chọn HAI" có 24 đáp án đúng, A/B/C/D/E lần lượt 4/5/5/5/5 lần. Đừng đoán theo chữ cái. Task 3.5 có sáu câu (63–68) phủ Kinesis, EMR, Lake Formation, Amazon Quick, Athena, DataSync, Storage Gateway, Glue và đổi CSV sang Parquet.

Bộ câu này kiểm tra lập luận theo requirement, không mô phỏng độ khó, coverage hay xác suất đỗ của đề thật.

Domain 1 — Design Secure Architectures (30%, câu 17–35)#

Domain 2 — Design Resilient Architectures (26%, câu 36–52)#

Domain 3 — Design High-Performing Architectures (24%, câu 53–68)#

Domain 4 — Design Cost-Optimized Architectures (20%, câu 69–81)#

14. Error notebook và chuẩn bị trước khi thi#

Sau mỗi câu sai, ghi: requirement đã bỏ sót, lý do đáp án đúng đáp ứng yêu cầu, vì sao từng distractor sai, link docs và một tình huống mà phương án sai lại có thể đúng. Ví dụ read replica không phải lựa chọn cho “standby tự failover” nhưng có thể đúng cho “offload reports chấp nhận lag”.

Đọc lại bốn domain và danh sách services/concepts chính thức; bổ sung mục chưa biết. Dùng official practice questions/exam trên Skill Builder theo khả năng truy cập. Bộ 16 câu ở mục 10–13 và ngân hàng 65 câu theo domain ngay trước mục này chỉ là tự kiểm tra kiến thức, không đủ mô phỏng độ khó, coverage hoặc xác suất đỗ.

Một chuẩn tự đánh giá do guide đề xuất: giải thích được từng quyết định không nhìn tài liệu, làm được các lab phù hợp ngân sách, và đạt kết quả ổn định trên bộ practice mới có review lỗi. Không đổi scaled passing score thành tỷ lệ cần đạt ở practice set.

Nguồn: Exam guide, AWS Skill Builder.

15. Done khi#

• Có sơ đồ và decision record cho ít nhất hai kiến trúc cùng requirement.

  Đáp án

  Tự kiểm: có hai sơ đồ ASCII (ví dụ MVP và +AZ ở mục 8), mỗi sơ đồ một decision record theo mẫu ở mục 1 với dòng "Loại: vì sao" cho phương án bị bỏ. Sai thường gặp: hai sơ đồ nhưng khác requirement nên không so sánh được.

• Có evidence IAM allow/deny và versioning, hoặc tabletop ghi rõ chưa thực hành.

  Đáp án

  Làm Lab A: cùng principal đọc raw/ thành công và other/ bị AccessDenied (implicit deny), hai version, delete marker. Nếu chưa làm, ghi "tabletop, chưa chạy" cùng dự đoán kết quả và lý do. Lưu ý 403 cũng xuất hiện cho key không tồn tại khi principal không có s3:ListBucket.

• Giải thích replacement instance khác mô phỏng AZ outage.

  Đáp án

  Terminate một instance (Lab B) chứng minh ASG thay thế một máy hỏng và ALB loại target unhealthy. Nó không chứng minh chịu mất cả AZ: AZ outage làm hỏng nhiều thành phần cùng lúc (instance, NAT, DB nếu một AZ). Cách kiểm: liệt kê từng thành phần nằm ở AZ nào; điểm đơn nào còn thì chưa chịu được mất AZ.

  textReady

  mất instance: ASG thay 1 máy            mất AZ-a: app-a + NAT-a + DB(a?)[app-a x] [app-b ok]  -> replacement    [AZ-a toàn bộ x] [AZ-b ok] -> còn đủ?

• Chứng minh queue retry và phân biệt với business idempotency.

  Đáp án

  Lab C: receive không delete làm message hiện lại, receive count tăng, vượt maxReceiveCount thì vào DLQ. Đó mới là retry. Business idempotency chứng minh ở bước nâng cao: hai lần giao, một hàng kết quả nhờ ràng buộc duy nhất theo jobId. SQS giao ít nhất một lần nên handler luôn phải idempotent.

• Restore được dữ liệu lab và ghi thời gian; không suy ra RTO production.

  Đáp án

  Lab D: restore tạo DB mới, dữ liệu đúng thời điểm snapshot/PITR, ghi thời gian bắt đầu-kết thúc. Thời gian này không phải RTO production, vì RTO gồm cả dựng network/app, đổi endpoint, validate và DNS. Sai thường gặp: báo "RTO 12 phút" từ lab nhỏ.

• Phân biệt OAC bảo vệ origin và signed URL bảo vệ viewer.

  Đáp án

  OAC làm CloudFront ký request tới S3 để chỉ CloudFront đọc được bucket (S3 URL trực tiếp trả 403); ai có URL CloudFront vẫn xem được. Signed URL/cookie (trusted key group) quyết định viewer nào được xem qua CloudFront. Cần nội dung private theo user thì cần cả hai lớp. Xem Lab E.

• Có estimate đầy đủ hơn compute-only và alarm đã trigger/recover nếu làm lab.

  Đáp án

  Estimate có các dòng ALB/NAT/endpoints/log/transfer/backup và ghi "chưa tính"; hai phương án cùng giả định (Lab F). Alarm: có lịch sử chuyển OK -> ALARM -> OK; set-alarm-state chỉ chứng minh đường thông báo, cần cả lần gây lỗi thật. Nếu chưa làm lab, ghi rõ "tabletop".

• Giải thích cả đáp án đúng lẫn phương án loại trong 16 câu tự luyện.

  Đáp án

  Tự kiểm: với mỗi câu, bạn nói được yêu cầu quyết định, vì sao đáp án đúng đáp ứng nó, và vì sao từng phương án còn lại sai (các dòng Loại ở mục 10-13 là đáp án mẫu). Câu sai thì ghi vào error notebook (mục 14) cùng một tình huống mà phương án sai lại đúng. Bộ 16 câu chỉ là tự kiểm tra, không mô phỏng độ khó đề thi. Làm tiếp ngân hàng 65 câu theo domain (câu 17–81) với cùng cách tự kiểm.

• Dọn tài nguyên đã tạo, kiểm tra retained storage/snapshots/EIP/endpoints/logs.

  Đáp án

  Với mỗi lab dùng lệnh dọn trong block lời giải và lệnh kiểm "không còn gì": S3 versions và multipart uploads, RDS manual snapshots và automated backups, Elastic IP và NAT, endpoints, log groups, CloudFront distribution/OAC, SNS/CloudWatch alarms, KMS key (đang chờ xóa 7-30 ngày). Quét theo từng Region, rồi xem Billing sau độ trễ billing; không kết luận "zero cost" ngay.

• Đối chiếu exam guide hiện tại trước khi chọn tài liệu luyện thi.

  Đáp án

  Mở trang chứng chỉ và exam guide online của AWS trước khi đặt lịch. Đối chiếu ngày 2026-10-05 với exam guide SAA-C03 và trang chứng chỉ: SAA-C03 là bản hiện hành, 65 câu (50 tính điểm và 15 không tính), 130 phút, thang 100-1000 và đạt 720 (chấm bù trừ), trọng số bốn domain 30/26/24/20 (Secure, Resilient, High-Performing, Cost-Optimized), không trừ điểm khi sai. Không có tiếng Việt: thi tiếng Anh và đăng ký ESL +30 (thêm 30 phút) một lần trước khi đăng ký thi. Trượt thì chờ 14 ngày để thi lại (chính sách sau khi thi); ESL +30 xem chính sách trước khi thi. Đừng dùng thông tin "SAA-C04" hay ngày retire từ site bên thứ ba: chưa có nguồn AWS.

• Làm hết ngân hàng 65 câu theo domain, ghi câu sai và domain còn yếu vào error notebook.

  Đáp án

  Tự kiểm: làm từng khối task trước khi mở đáp án, chấm riêng theo bốn domain. Với mỗi câu sai, ghi requirement đã bỏ sót, đọc lại trang "Nguồn" của câu đó và viết một câu vì sao từng phương án bị loại. Domain có tỷ lệ sai cao hơn các domain khác là chỗ cần ôn lại từ GĐ29 đến GĐ32. Sai thường gặp: nhớ chữ cái đáp án thay vì nhớ điều kiện chọn; coi tỷ lệ đúng trên bộ này là xác suất đỗ.

Ghi chú chung: Kiểm chứng ngày 2026-10-05 theo tài liệu AWS (các URL nằm trong đáp án trên). Chưa chạy trên AWS thật. Số liệu về kỳ thi lấy từ exam guide và trang chính sách chứng chỉ của AWS; mở lại exam guide trước ngày thi.

Quay lại GĐ28 — bản đồ học SAA hoặc tiếp tục project GĐ25 — AI SaaS để dùng kiến thức AWS vào sản phẩm.