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

Đáp án

C — Chuyển session data sang một cụm Amazon ElastiCache for Redis.

Vì sao đúng

Đề nêu đúng vấn đề: ứng dụng cũ lưu session trong bộ nhớ của một máy chủ duy nhất, và giờ cần chạy trên nhiều EC2 sau ELB với yêu cầu dữ liệu bền vững khi một instance hỏng và giảm thiểu gián đoạn cho 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 dùng chung:

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

ElastiCache for Redis đáp ứng cả hai yêu cầu của đề: | Yêu cầu | Cách đáp ứng | |---|---| | Dữ liệu bền vững khi instance hỏng | session nằm ngoài instance — máy chết không mất gì | | Giảm thiểu downtime | Multi-AZ với tự động failover; người dùng không bị đăng xuất | | Hiệu năng | dưới mili giây — session được đọc ở mọi request | | TTL sẵn có | session tự hết hạn, không cần job dọn |

aws elasticache create-replication-group \
  --replication-group-id session-store \
  --engine redis --cache-node-type cache.r6g.large \
  --num-node-groups 2 --replicas-per-node-group 2 \
  --automatic-failover-enabled --multi-az-enabled

Và nhiều framework có sẵn adapter — thường chỉ cần đổi cấu hình: spring-session-data-redis, connect-redis cho Node.js, django-redis, hoặc PHP Redis session handler.

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

• A. Một EC2 instance riêng dành cho session data — tạo ra điểm hỏng đơn lẻ mới: instance đó chết là mọi người dùng bị đăng xuất. Và bạn phải tự vá, tự giám sát, tự lo sao lưu — trong khi ElastiCache là dịch vụ được quản lý.
• B. Một EBS volume thứ hai — EBS gắn vào MỘT instance trong MỘT AZ: các instance khác không đọc được. Nên nó giữ nguyên vấn đề gốc — session vẫn cục bộ.
• D. Ổ đĩa chính của web server — chính là vấn đề hiện tại, chỉ đổi từ RAM sang đĩa. Vẫn cục bộ, vẫn mất khi instance được thay.

Ghi nhớ

Các lựa chọn lưu session ngoài: | Kho | Độ trễ | Bền | Chọn khi | |---|---|---|---| | ElastiCache Redis | thấp nhất — dưới mili giây | vừa (có nhân bản, snapshot) | cần nhanh nhất + chịu lỗi | | DynamoDB | mili giây một chữ số | 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 về kiến trúc; cách chọn theo từ khoá trong đề:

• "lowest latency", "fastest" ⇒ ElastiCache Redis
• "durable", "no management", "TTL" ⇒ DynamoDB

Ba thứ không bao giờ dùng làm kho session: | Không dùng | Vì sao | |---|---| | Bộ nhớ hoặc ổ đĩa cục bộ | 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 | instance hỏng là mất session |

So sánh hai engine của ElastiCache — điều quyết định cho yêu cầu "fault tolerant": | | Redis | Memcached | |---|---|---| | Nhân bản, Multi-AZ failover | ✅ | ❌ | | Lưu bền (snapshot, AOF) | ✅ | ❌ | | Mã hoá | ✅ | ❌ | | Cấu trúc dữ liệu | hash, list, set, sorted set | chỉ chuỗi |

Với session, gần như luôn chọn Redis — vì chỉ nó có nhân bản và failover, còn Memcached mất toàn bộ dữ liệu khi một node hỏng.

Và sau khi tách session ra, bước tiếp theo tự nhiên là bật HealthCheckType: ELB cho Auto Scaling group — để instance có ứng dụng chết (chứ không chỉ máy chết) cũng được thay thế.

Đáp án

C — Amazon Inspector.

Vì sao đúng

Đề mô tả chính xác chức năng của Inspector: tự động đánh giá ứng dụng về mức độ phơi nhiễm, lỗ hổng, và độ lệch so với thực hành tốt.

Đó gần như là câu mô tả chính thức của dịch vụ:

"Amazon Inspector là dịch vụ đánh giá bảo mật tự động, giúp cải thiện
tính bảo mật và tuân thủ của ứng dụng triển khai trên AWS. Nó tự động
đánh giá ứng dụng về mức độ phơi nhiễm, lỗ hổng, và độ lệch so với
thực hành tốt."

Inspector quét ba loại tài nguyên: | Đối tượng | Phát hiện | |---|---| | Amazon EC2 | CVE trong hệ điều hành và gói phần mềm, cấu hình mạng phơi ra ngoài | | Container image trong ECR | CVE trong các lớp image | | AWS Lambda | CVE trong thư viện phụ thuộc, và phân tích mã |

Điểm mạnh của phiên bản hiện tại (Inspector v2): nó quét liên tục và tự động, không cần bạn lên lịch — mỗi khi có instance mới, image mới, hoặc CVE mới được công bố, nó tự đánh giá lại:

aws inspector2 enable --resource-types EC2 ECR LAMBDA

Kết quả gồm mức độ nghiêm trọng, mô tả CVE, và hướng dẫn khắc phục cụ thể.

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

• A. AWS Shield — dịch vụ chống tấn công DDoS. Shield Standard tự động bảo vệ ở tầng 3/4; Shield Advanced thêm giám sát và hỗ trợ. Nó bảo vệ khỏi tấn công, không quét tìm lỗ hổng.
• D. AWS WAF — tường lửa ứng dụng web: lọc request độc hại (SQL injection, XSS, giới hạn tần suất) ở tầng 7. Cũng là bảo vệ, không phải đánh giá.
• B. AWS Secrets Manager — lưu trữ và xoay vòng bí mật. Hoàn toàn không liên quan tới quét lỗ hổng.

Ghi nhớ

Các dịch vụ bảo mật của AWS và phạm vi của chúng — bảng này rất đáng thuộc: | Dịch vụ | Việc | |---|---| | Inspector | quét LỖ HỔNG phần mềm trên EC2, ECR, Lambda | | GuardDuty | phát hiện HÀNH VI đáng ngờ (truy cập bất thường, mã độc, đào tiền ảo) | | Macie | tìm DỮ LIỆU NHẠY CẢM trong S3 | | Security Hub | tổng hợp phát hiện từ các dịch vụ trên | | IAM Access Analyzer | tài nguyên bị chia sẻ ra ngoài tài khoản | | AWS Config | thay đổi cấu hình, đánh giá tuân thủ | | Trusted Advisor | khuyến nghị chung về chi phí, hiệu năng, bảo mật |

Ba dịch vụ đầu dễ nhầm — cách phân biệt: | Câu hỏi | Dịch vụ | |---|---| | "Phần mềm của tôi có lỗ hổng nào?" | Inspector | | "Có ai đang làm gì đáng ngờ không?" | GuardDuty | | "Dữ liệu nhạy cảm của tôi nằm ở đâu?" | Macie |

Và hai nhóm dịch vụ theo mục đích: | Nhóm | Dịch vụ | |---|---| | Phát hiện (detective) | Inspector, GuardDuty, Macie, Config, CloudTrail | | Bảo vệ (preventive) | WAF, Shield, Security Group, NACL, IAM |

Nhận dạng nhanh trong đề: "assess", "vulnerabilities", "deviations from best practices" ⇒ Inspector. "detect threats", "unusual activity" ⇒ GuardDuty. "block malicious requests" ⇒ WAF.

Lưu ý về chi phí: Inspector v2 tính tiền theo số instance và số image được quét mỗi tháng — với môi trường lớn, nên bật chọn lọc theo tag thay vì quét toàn bộ.

Đáp án

D — Tạo một customer managed policy với quyền đọc/ghi SQS và gắn vào execution role của hàm.

Vì sao đúng

Đọc kỹ thông báo lỗi:

The function's execution role does not have permissions to call SendMessage
on arn:aws:sqs:us-east-1:515148212435:FailureDestination

Nó chỉ ra hai điều: quyền thiếu là sqs:SendMessage, và nó phải nằm ở execution role của hàm.

Điều này đúng với cơ chế của Lambda destination: chính hàm Lambda gửi kết quả tới đích, bằng credential của execution role. Nên quyền phải là identity-based policy gắn vào role đó:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "sqs:SendMessage",
    "Resource": "arn:aws:sqs:us-east-1:515148212435:FailureDestination"
  }]
}

aws iam create-policy --policy-name GuiVaoDLQ --policy-document file://policy.json
aws iam attach-role-policy --role-name RoleHamCuaToi \
  --policy-arn arn:aws:iam::515148212435:policy/GuiVaoDLQ

Customer managed policy là lựa chọn đúng vì nó thu hẹp được đúng nhu cầu — khác với AWS managed policy vốn thường quá rộng.

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

• B. Thêm AWS managed policy AWSLambdaSQSQueueExecutionRole — đây là bẫy hay nhất, và nó không sửa được lỗi: policy này dành cho tình huống Lambda ĐỌC từ SQS làm event source, nên nó chứa ReceiveMessage, DeleteMessage, GetQueueAttributes — KHÔNG có SendMessage. Ở đây chiều ngược lại: Lambda GHI vào SQS.
• A. Thêm hàm vào một group có quyền quản trị — sai hai chỗ: IAM group chỉ chứa IAM user, không chứa role hay hàm Lambda; và quyền quản trị vi phạm nặng nguyên tắc đặc quyền tối thiểu.
• C. Thêm permissions policy vào SQS queue cho phép SendMessage và chỉ định số tài khoản — đây là phương án đáng bàn. Resource-based policy trên queue có thể hoạt động trong cùng tài khoản, nhưng nó cấp quyền cho CẢ TÀI KHOẢN — nghĩa là mọi danh tính trong tài khoản đó đều gửi được vào queue. Rộng hơn hẳn so với việc cấp đúng cho một role.

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

Đáp án D nói "all read/write permissions to SQS" — rộng hơn mức cần thiết. Cách thực sự an toàn nhất là customer managed policy chỉ chứa sqs:SendMessage trên đúng ARN của queue đó.

Dù vậy D vẫn là lựa chọn đúng trong bộ đã cho, vì nó là phương án duy nhất đặt quyền đúng chỗ (execution role) và dùng customer managed policy (thu hẹp được). Khi làm thật, hãy thu hẹp thêm như ví dụ ở trên.

Ghi nhớ

Hai chiều quyền của Lambda với SQS — nhầm chỗ này là lỗi rất phổ biến: | Chiều | Quyền cần | Managed policy | |---|---|---| | Lambda ĐỌC từ SQS (event source) | ReceiveMessage, DeleteMessage, GetQueueAttributes | AWSLambdaSQSQueueExecutionRole | | Lambda GHI vào SQS (destination, DLQ) | SendMessage | không có sẵn — phải tự tạo |

Các managed policy hay dùng cho Lambda: | Policy | Thêm quyền | |---|---| | AWSLambdaBasicExecutionRole | log CloudWatch | | AWSLambdaVPCAccessExecutionRole | log + tạo/xoá ENI trong VPC | | AWSLambdaDynamoDBExecutionRole | log + đọc DynamoDB Streams | | AWSLambdaSQSQueueExecutionRole | log + đọc SQS | | AWSLambdaKinesisExecutionRole | log + đọc Kinesis |

Điểm chung: chúng đều dành cho ĐỌC từ nguồn sự kiện. Với GHI vào đích (destination, DLQ, SNS topic), bạn phải tự viết policy.

Ba loại policy trong IAM: | Loại | Ai quản | Đặc điểm | |---|---|---| | AWS managed | AWS | tiện, nhưng thường rộng hơn mức cần | | Customer managed | bạn | thu hẹp được đúng nhu cầu, tái sử dụng được | | Inline | bạn | gắn chặt vào một danh tính |

Khi đề nhắc tới "MOST securely", đáp án hầu như luôn là customer managed policy với ARN cụ thể — không phải AWS managed policy.

Đáp án

A và D.

• A — Đưa hàm Lambda vào VPC
• D — Tạo VPC endpoint cho Amazon SQS

Vì sao đúng

Yêu cầu: mọi giao tiếp phải nằm trong VPC, dùng địa chỉ IP riêng tư.

Cần hai thay đổi vì có hai vấn đề khác nhau.

A — Lambda mặc định chạy NGOÀI VPC của bạn. AWS chạy nó trong một VPC do AWS quản lý, nên traffic tới EC2 sẽ phải đi qua Internet. Gắn hàm vào VPC đặt nó vào subnet của bạn với IP riêng tư:

{
  "VpcConfig": {
    "SubnetIds": ["subnet-private-a", "subnet-private-b"],
    "SecurityGroupIds": ["sg-lambda"]
  }
}

D — SQS là dịch vụ công khai, không nằm trong VPC nào. Bình thường, lời gọi tới nó đi qua Internet. Interface VPC endpoint (PrivateLink) tạo một ENI có IP riêng tư trong subnet của bạn, đại diện cho SQS:

aws ec2 create-vpc-endpoint \
  --vpc-id vpc-abc123 \
  --service-name com.amazonaws.us-east-1.sqs \
  --vpc-endpoint-type Interface \
  --subnet-ids subnet-private-a subnet-private-b \
  --security-group-ids sg-endpoint \
  --private-dns-enabled

Cờ --private-dns-enabled rất quan trọng: nó khiến tên miền công khai sqs.us-east-1.amazonaws.com phân giải thành IP riêng tư của endpoint — nên mã ứng dụng không cần đổi một dòng nào.

Kết quả: EC2 và Lambda gọi SQS qua IP riêng tư, traffic không bao giờ rời khỏi mạng AWS.

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

• B. Tạo SQS queue bên trong một VPC — không làm được: SQS là dịch vụ được quản lý, không nằm trong VPC nào. Bạn không "đặt" nó vào VPC — bạn tạo đường riêng tới nó bằng VPC endpoint.
• C. Tạo VPC endpoint cho AWS Lambda — giải quyết chiều ngược lại: endpoint này cho phép tài nguyên trong VPC GỌI TỚI Lambda API (để invoke hàm). Nhưng ở đây Lambda là bên gọi đi, nên thứ cần là đưa nó vào VPC. (Endpoint cho Lambda hữu ích nếu EC2 cần gọi hàm — nhưng đề không nêu nhu cầu đó.)
• E. Tạo VPN và kết nối các dịch vụ vào VPG — VPN nối mạng tại chỗ với VPC, không nối các dịch vụ AWS với nhau. Không áp dụng được ở đây.

Ghi nhớ

Hai loại VPC endpoint — khác biệt rất quan trọng: | | Gateway endpoint | Interface endpoint (PrivateLink) | |---|---|---| | Dịch vụ hỗ trợ | CHỈ S3 và DynamoDB | hầu hết dịch vụ AWS, kể cả SQS | | Cơ chế | route trong route table | ENI có IP riêng trong subnet | | Chi phí | MIỄN PHÍ | có phí giờ + phí dữ liệu | | Từ on-premises | ❌ | ✅ qua Direct Connect/VPN |

Dòng đầu đáng thuộc: chỉ S3 và DynamoDB có Gateway endpoint miễn phí — mọi dịch vụ khác (SQS, SNS, KMS, Secrets Manager…) phải dùng Interface endpoint có phí.

Ba lưu ý khi gắn Lambda vào VPC:

1. Hàm MẤT truy cập Internet — mọi dịch vụ AWS nó cần gọi đều phải có VPC endpoint hoặc đi qua NAT Gateway.
2. Chọn ≥ 2 subnet khác AZ để chịu được sự cố một AZ.
3. Security group của endpoint phải cho phép cổng 443 từ security group của Lambda và EC2.

Điểm thứ ba hay bị bỏ sót: Interface endpoint có security group riêng, và nếu nó không mở HTTPS cho bên gọi thì mọi request đều timeout mà không có thông báo rõ ràng.

Và một lợi ích bảo mật của endpoint: bạn thắt chặt được policy theo aws:SourceVpce:

"Condition": {"StringNotEquals": {"aws:SourceVpce": "vpce-0abc123"}}

Kết hợp với Deny, cách này đảm bảo queue chỉ truy cập được từ đúng VPC của bạn — kể cả credential bị lộ cũng không dùng được từ ngoài.

Đáp án

A và B.

• A — Chuyển website sang Auto Scaling group của EC2 trải NHIỀU AZ kèm Elastic Load Balancer
• B — Chuyển CSDL MySQL sang Amazon RDS Multi-AZ

Vì sao đúng

Đề yêu cầu sẵn sàng cao và chịu lỗi cho cả hai tầng — nên cần hai thay đổi, mỗi thay đổi cho một tầng.

A — tầng web:

Internet → ALB (trải nhiều AZ)
              ↓
        ASG: EC2 ở AZ-a, AZ-b, AZ-c

B — tầng dữ liệu:

aws rds modify-db-instance --db-instance-identifier csdl-chinh \
  --multi-az --apply-immediately

RDS Multi-AZ duy trì một bản standby ở AZ khác, nhân bản đồng bộ, và tự động failover trong 1–2 phút khi primary hỏng. Endpoint DNS không đổi, nên ứng dụng tự kết nối lại.

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

• C. ASG trải trong MỘT AZ kèm ELB — không chịu lỗi ở cấp AZ: mọi instance nằm cùng một AZ, nên AZ sập là mất hết. ASG chỉ bảo vệ khỏi sự cố của từng máy, không bảo vệ khỏi sự cố hạ tầng.
• E. RDS với read replica ở AZ khác — đây là bẫy hay nhất, và khác biệt rất đáng nhớ: read replica dùng để MỞ RỘNG ĐỌC, không phải để chịu lỗi. Nhân bản là bất đồng bộ (có thể mất dữ liệu khi failover), và failover phải làm THỦ CÔNG bằng cách promote. Multi-AZ thì đồng bộ và tự động.
• D. Chuyển MySQL sang DynamoDB với Global Tables — thay đổi kiến trúc quá lớn: DynamoDB là NoSQL, không có SQL, không có JOIN, không có giao dịch phức tạp. Di trú từ MySQL sang đó đòi viết lại toàn bộ tầng truy cập dữ liệu. Đề nói "refactor", không nói "viết lại".

Ghi nhớ

Phân biệt hai tính năng của RDS — một trong những câu hỏi kinh điển nhất: | | Multi-AZ | Read Replica | |---|---|---| | Mục đích | sẵn sàng cao / chịu lỗi | mở rộng đọc | | Nhân bản | đồng bộ | bất đồng bộ | | Standby/replica đọc được? | ❌ KHÔNG | ✅ CÓ | | Failover | ✅ TỰ ĐỘNG (1–2 phút) | ❌ thủ công (promote) | | Số lượng | 1 standby | tối đa 15 | | Xuyên Region | ❌ | ✅ |

Câu thần chú: Multi-AZ = tính sẵn sàng. Read replica = hiệu năng đọc. Đề hỏi "high availability" hay "fault tolerant" thì chọn Multi-AZ.

Ba trụ cột của kiến trúc web chịu lỗi: | Trụ cột | Thành phần | |---|---| | Tầng web phi trạng thái | session ra ElastiCache hoặc DynamoDB | | Phân phối tải đa AZ | ALB + ASG trải ≥ 2 AZ | | Tầng dữ liệu dư thừa | RDS Multi-AZ |

Trụ cột đầu tiên đáng nhấn mạnh với ứng dụng di trú từ máy chủ đơn: nếu session còn nằm trong bộ nhớ instance thì ASG sẽ làm người dùng bị đăng xuất mỗi khi thay máy.

Bốn việc nên làm để thực sự chịu lỗi:

1. Tối thiểu 2 instance, trải trên ≥ 2 AZ
2. HealthCheckType: ELB kèm HealthCheckGracePeriod đủ dài
3. RDS Multi-AZ cho tầng dữ liệu
4. Session ra kho ngoài — điều kiện để ba việc trên có ý nghĩa

Và nếu sau này cần mở rộng đọc, Multi-AZ và read replica dùng được CÙNG NHAU — chúng giải quyết hai vấn đề khác nhau.

Đáp án

C — Tạo sáu IAM role riêng biệt, mỗi role chứa quyền của một service, rồi cấu hình mỗi task definition tham chiếu tới role tương ứng.

Vì sao đúng

Điểm mấu chốt: task role gắn quyền vào từng task definition, tức là vào từng container — không phải vào máy chủ bên dưới.

Vì nhiều service có thể chạy chung một EC2 instance, nếu quyền được gắn ở mức instance thì mọi container trên máy đó đều thừa hưởng toàn bộ quyền của cả sáu service:

Instance EC2 (instance profile có quyền của cả 6 service)
├── Container service A  → dùng được quyền của cả B, C, D, E, F  ✗
├── Container service B  → dùng được quyền của cả A, C, D, E, F  ✗
└── ...

Task role giải quyết bằng cách gắn quyền vào task definition:

{
  "family": "service-thanh-toan",
  "taskRoleArn": "arn:aws:iam::123456789012:role/TaskRole-ThanhToan",
  "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
  "containerDefinitions": [...]
}

ECS agent lấy credential tạm thời cho từng task và cung cấp qua endpoint riêng của task, nên container chỉ thấy đúng quyền của mình — kể cả khi sáu service đang chạy chung một máy. Đó chính là nghĩa của "MOST secure" trong đề.

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

• A. Một instance profile chứa quyền của tất cả service, gắn vào EC2 — đây là bẫy chính, và nó vi phạm đặc quyền tối thiểu nghiêm trọng như sơ đồ trên. Nếu một container bị chiếm quyền, kẻ tấn công có ngay quyền của cả sáu service.
• D. Sáu role, tạo IAM group và cho ECS cluster tham chiếu group — IAM group chỉ chứa IAM user, không chứa role và không gắn được vào dịch vụ. Cluster cũng không có khái niệm tham chiếu group.
• B. Một IAM policy dùng Principal tham chiếu các ECS task, rồi áp policy vào ECS service — sai hai chỗ: identity-based policy không khai Principal (chỉ resource-based policy mới có), và ECS service không nhận policy trực tiếp — quyền khai trong task definition.

Ghi nhớ

Ba loại role của ECS — nhầm lẫn giữa chúng là lỗi cấu hình phổ biến nhất: | Role | Ai dùng | Cho việc gì | |---|---|---| | Task role | mã trong container | gọi S3, DynamoDB, SQS… | | Task execution role | ECS agent | kéo image từ ECR, ghi log, đọc secret | | Instance profile (EC2 launch type) | ECS agent trên host | đăng ký instance vào cluster |

Cách nhớ nhanh:

• "Ứng dụng của tôi cần gọi dịch vụ AWS" ⇒ task role
• "Không kéo được image / không thấy log" ⇒ execution role
• "Instance không tham gia được cluster" ⇒ instance profile

Với Fargate, câu hỏi này biến mất phần lớn: không có EC2 instance nào để gắn quyền, nên bắt buộc phải dùng task role. Đó là một lý do nữa để chọn Fargate khi ưu tiên bảo mật.

Và một biện pháp tăng cường quan trọng cho EC2 launch type: chặn container truy cập instance metadata service, nếu không container vẫn lấy được credential của instance profile bất chấp task role:

# Trong /etc/ecs/ecs.config trên container instance
ECS_AWSVPC_BLOCK_IMDS=true

Hoặc dùng network mode awsvpc — mỗi task có ENI riêng, và metadata service của host không tới được.

Nguyên tắc bao trùm, áp cho mọi nơi mã chạy trên AWS: không bao giờ dùng access key dài hạn, và gắn quyền ở mức nhỏ nhất có thể — task chứ không phải instance, hàm chứ không phải tài khoản.

Đáp án

C — Vô hiệu hoá (invalidate) các tệp khỏi edge cache.

Vì sao đúng

Nguyên nhân rất rõ: CloudFront đang phục vụ bản cũ từ cache ở edge location, và cache đó chưa hết hạn.

Invalidation buộc CloudFront xoá đối tượng khỏi mọi edge cache, nên request tiếp theo phải lấy bản mới từ origin:

aws cloudfront create-invalidation \
  --distribution-id E1ABCDEFGHIJKL \
  --paths "/css/style.css" "/js/app.js"

# Hoặc toàn bộ một thư mục
aws cloudfront create-invalidation --distribution-id E1ABCDEFGHIJKL --paths "/anh/*"

Vì sao đây là cách ít gián đoạn nhất: | Đặc điểm | Chi tiết | |---|---| | Không đụng tới distribution | website vẫn phục vụ bình thường | | Chỉ ảnh hưởng tệp được nêu | các tệp khác vẫn trong cache | | Có hiệu lực trong vài phút | thường 3–5 phút |

Về chi phí: 1.000 đường dẫn đầu tiên mỗi tháng là miễn phí, sau đó khoảng 0,005 USD mỗi đường dẫn. Dùng /* chỉ tính là một đường dẫn.

Theo dõi tiến trình:

aws cloudfront get-invalidation --distribution-id E1ABCDEFGHIJKL --id I2J3K4L5M6N7O8

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

• D. Tắt distribution rồi bật lại để cập nhật mọi edge location — gây gián đoạn nghiêm trọng: tắt distribution nghĩa là website ngừng phục vụ, và việc tắt/bật mất hàng chục phút để lan truyền. Trái hẳn yêu cầu "LEAST disruption".
• B. Tạo origin mới với tệp mới rồi xoá origin cũ — phức tạp và vẫn không giải quyết vấn đề: đổi origin không tự xoá cache; CloudFront vẫn phục vụ bản đã cache cho tới khi TTL hết. Ngoài ra nó đòi sửa cấu hình distribution — nhiều rủi ro hơn hẳn.
• A. Thêm mã vào Lambda@Edge để cập nhật tệp trong cache — Lambda@Edge không sửa được cache: nó can thiệp vào request và response, không có API nào để ghi đè hay xoá mục trong edge cache.

Ghi nhớ

Ba cách làm mới nội dung trên CloudFront: | Cách | Đặc điểm | |---|---| | Invalidation | tức thì (vài phút), có phí sau 1.000 đường dẫn/tháng | | Versioned URL | style-v2.css — MIỄN PHÍ, khuyến nghị | | Chờ TTL hết hạn | miễn phí, nhưng chậm |

Versioned URL là cách được khuyến nghị nhất cho quy trình triển khai thường xuyên:

<!-- Thay vì invalidate mỗi lần đổi -->
<link href="/css/style.css">

<!-- Dùng tên có mã băm nội dung -->
<link href="/css/style-a1b2c3.css">

Cách này miễn phí, có hiệu lực ngay lập tức, và còn cho phép quay lại bản cũ vì cả hai phiên bản đều tồn tại. Hầu hết công cụ build hiện đại (Webpack, Vite) tự sinh tên có mã băm.

Các tham số TTL của CloudFront: | Tham số | Việc | |---|---| | MinTTL | thời gian tối thiểu giữ trong cache | | DefaultTTL | dùng khi origin không gửi Cache-Control (mặc định 86.400 giây) | | MaxTTL | trần, kể cả khi origin yêu cầu lâu hơn |

Origin điều khiển được thời gian cache bằng header:

Cache-Control: max-age=31536000, immutable    # tài nguyên có phiên bản
Cache-Control: no-cache                        # luôn kiểm tra lại với origin

Lời khuyên thực dụng: dùng versioned URL cho tài nguyên tĩnh (CSS, JS, ảnh) với TTL rất dài, và để dành invalidation cho tình huống khẩn cấp — như phải gỡ ngay một nội dung đăng nhầm.

Đáp án

C — Tham số --dimensions.

Vì sao đúng

Dimension là cặp khoá–giá trị dùng để phân loại và phân mảnh một metric — chính xác là điều đề cần: tổ chức metric theo EC2 instance và theo Auto Scaling group.

aws cloudwatch put-metric-data \
  --namespace "UngDung/HieuNang" \
  --metric-name "SoKetNoiDangHoatDong" \
  --value 42 \
  --dimensions InstanceId=i-1234567890abcdef0,AutoScalingGroupName=nhom-web

Nhờ dimension, cùng một metric SoKetNoiDangHoatDong được tách thành nhiều chuỗi dữ liệu độc lập:

SoKetNoiDangHoatDong{InstanceId=i-111, AutoScalingGroupName=nhom-web} → 42
SoKetNoiDangHoatDong{InstanceId=i-222, AutoScalingGroupName=nhom-web} → 38
SoKetNoiDangHoatDong{InstanceId=i-333, AutoScalingGroupName=nhom-api} → 15

Từ đó bạn: | Việc | Cách làm | |---|---| | So sánh giữa các instance | vẽ nhiều chuỗi trên cùng biểu đồ | | Tổng hợp theo ASG | lọc theo AutoScalingGroupName | | Đặt alarm riêng cho từng instance | khai dimension trong alarm |

Cảnh báo về chi phí: mỗi tổ hợp dimension là một custom metric riêng và một khoản phí riêng. Với 100 instance và 2 dimension, bạn có 100 metric — nhân với số metric name thì hoá đơn tăng nhanh. Chỉ dùng dimension cho trường có số giá trị hữu hạn và biết trước.

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

• D. --namespace — phân nhóm ở cấp cao nhất, tạo ra không gian tên riêng biệt (AWS/EC2, UngDung/HieuNang). Nó tách các hệ thống độc lập với nhau, không tách các thể hiện của cùng một thứ. Đề cần phân biệt từng instance trong cùng một ứng dụng — đó là việc của dimension.
• B. --metric-name — đặt tên cho metric (CPUUtilization, SoKetNoi). Nó nói đo cái gì, không nói đo ở đâu.
• A. --statistic-values — dùng để gửi tập số liệu đã tổng hợp sẵn thay vì từng điểm:

  --statistic-values Sum=500,Minimum=1,Maximum=50,SampleCount=100
  

  Nó là cách tối ưu số lời gọi API, không phải cách phân loại.

Ghi nhớ

Cấu trúc phân cấp của metric trong CloudWatch:

Namespace          (AWS/EC2, UngDung/HieuNang)
└── Metric name    (CPUUtilization, SoKetNoi)
    └── Dimensions (InstanceId=i-123, AutoScalingGroupName=nhom-web)
        └── Datapoints (giá trị theo thời gian)

Khi nào dùng cái nào: | Nhu cầu | Cơ chế | |---|---| | Tách các ứng dụng/hệ thống độc lập | namespace | | Tách các thể hiện của cùng một thứ | dimension ← câu này | | Cảnh báo khi vượt ngưỡng | alarm |

Quy ước đặt tên namespace: namespace của AWS luôn bắt đầu bằng AWS/ — AWS/EC2, AWS/Lambda. Đừng dùng tiền tố này cho metric của bạn.

Ba giới hạn và chi phí cần nhớ: | Điểm | Chi tiết | |---|---| | Mỗi tổ hợp dimension = một custom metric | tính phí riêng | | Tối đa 30 dimension mỗi metric | — | | Dimension là một phần của định danh metric | đổi dimension = tạo metric mới, mất lịch sử |

Dòng cuối rất quan trọng: nếu bạn đổi cách đặt dimension giữa chừng, biểu đồ cũ sẽ đứt và bạn bắt đầu lại từ đầu.

Và một mẹo tối ưu chi phí: với metric tần suất cao, dùng statistic set (tham số --statistic-values) để gửi 100 mẫu trong một lời gọi thay vì 100 lời gọi — vẫn vẽ được biểu đồ đúng mà rẻ hơn nhiều.

Đáp án

D — Dùng IAM role với policy AmazonDynamoDBReadOnlyAccess gắn vào các EC2 instance.

Vì sao đúng

Nguyên tắc nền tảng: ứng dụng chạy trên AWS thì dùng IAM role, không bao giờ dùng access key dài hạn.

Với EC2, cơ chế đó là instance profile chứa một IAM role:

aws ec2 associate-iam-instance-profile \
  --instance-id i-1234567890abcdef0 \
  --iam-instance-profile Name=UngDungDynamoDBProfile

Ứng dụng tự động nhận credential tạm thời qua Instance Metadata Service — mã không cần biết gì:

import boto3
table = boto3.resource('dynamodb').Table('BangCuaToi')
table.get_item(Key={'id': 'SP-001'})    # SDK tự lấy credential từ role

Vì sao đây là cách an toàn nhất: | Lợi ích | Chi tiết | |---|---| | Không có credential dài hạn | không có gì để lộ, để commit nhầm, hay để xoay vòng | | Tự động xoay vòng | AWS làm mới credential | | Đổi quyền tức thì | sửa policy của role, không cần triển khai lại | | Vết kiểm toán rõ | CloudTrail ghi cả role lẫn instance |

Và AmazonDynamoDBReadOnlyAccess khớp đúng yêu cầu "read-only access" của đề — đó là đặc quyền tối thiểu ở mức action.

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

• B. IAM role với quyền Administrator — đúng cơ chế (role) nhưng vi phạm nặng đặc quyền tối thiểu: đề chỉ cần đọc một bảng DynamoDB, mà Administrator cho phép làm mọi thứ trong tài khoản — xoá CSDL, tạo IAM user, tắt CloudTrail.
• C. Tạo access key cho mỗi EC2 instance, đặt key vào mã, triển khai lại khi xoay vòng — sai lầm nghiêm trọng ở nhiều tầng: credential dài hạn nằm trong mã (và trong lịch sử Git), phải triển khai lại ở mỗi lần xoay vòng, và không mở rộng được khi số instance tăng.
• A. Chạy mã bằng access key của tài khoản root — tệ nhất có thể: root có toàn quyền không giới hạn và không thể bị hạn chế bởi IAM policy hay SCP. Lộ key root nghĩa là mất toàn bộ tài khoản. AWS khuyến nghị root không nên có access key nào cả.

Ghi nhớ

Cơ chế cấp quyền theo nơi mã chạy — bảng này áp cho mọi tình huống: | Nơi chạy | Cơ chế | |---|---| | EC2 | instance profile | | Lambda | execution role | | ECS / Fargate | task role | | EKS | IAM Roles for Service Accounts (IRSA) | | Máy chủ on-premises | IAM Roles Anywhere, SSM hybrid activation | | Máy của lập trình viên | IAM Identity Center (SSO) |

Và với đặc quyền tối thiểu, nên thu hẹp thêm bằng customer managed policy thay vì dùng managed policy:

{
  "Effect": "Allow",
  "Action": ["dynamodb:GetItem", "dynamodb:Query", "dynamodb:BatchGetItem"],
  "Resource": [
    "arn:aws:dynamodb:ap-southeast-1:123456789012:table/BangCuaToi",
    "arn:aws:dynamodb:ap-southeast-1:123456789012:table/BangCuaToi/index/*"
  ]
}

Lý do: AmazonDynamoDBReadOnlyAccess áp cho Resource: "*" — tức là MỌI bảng trong tài khoản. Với yêu cầu chặt, hãy giới hạn đúng bảng cần.

Một biện pháp tăng cường quan trọng cho EC2: bắt buộc dùng IMDSv2, vốn yêu cầu token và chống được tấn công SSRF lấy credential từ metadata service:

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

Đây là biện pháp một dòng, và nó chặn được một trong những đường tấn công phổ biến nhất vào ứng dụng web trên EC2.

Và nhớ: gắn role vào instance KHÔNG tự động vô hiệu hoá credential cũ — chuỗi tìm credential của SDK đặt biến môi trường và tệp ~/.aws/credentials TRƯỚC instance profile. Phải chủ động gỡ chúng đi.

Đáp án

A — Tạo bảng rồi xoá bảng sau khi tác vụ hoàn tất.

Vì sao đúng

Đề nêu hai tiêu chí: hiệu quả nhất và tiết kiệm chi phí nhất để có một bảng rỗng.

Điểm mấu chốt: xoá cả bảng KHÔNG tốn WCU nào, trong khi xoá từng item thì tốn WCU cho mỗi item.

1 triệu item, mỗi item 1 KB:
  Xoá từng item → 1.000.000 WCU tiêu thụ → tốn tiền và mất rất nhiều thời gian
  Xoá cả bảng   → 0 WCU                  → miễn phí, xong trong vài phút

Quy trình hằng đêm:

# Sáng: xoá bảng cũ
aws dynamodb delete-table --table-name du-lieu-lo
aws dynamodb wait table-not-exists --table-name du-lieu-lo

# Tối: tạo bảng mới rồi nạp dữ liệu
aws dynamodb create-table --table-name du-lieu-lo \
  --attribute-definitions AttributeName=id,AttributeType=S \
  --key-schema AttributeName=id,KeyType=HASH \
  --billing-mode PAY_PER_REQUEST
aws dynamodb wait table-exists --table-name du-lieu-lo

Lợi ích kèm theo: bạn cũng không trả tiền lưu trữ trong khoảng thời gian bảng không tồn tại.

(Một lựa chọn thay thế đáng cân nhắc nếu không muốn xoá bảng: dùng TTL với mốc hết hạn một giờ sau khi nạp. TTL cũng miễn phí, nhưng nó không đảm bảo thời điểm — AWS chỉ cam kết "trong vài ngày" — nên với yêu cầu "bảng phải rỗng trước lô kế tiếp", xoá bảng chắc chắn hơn.)

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

• B. Dùng BatchWriteItem để xoá hết các dòng — tốn WCU cho mỗi item xoá: 1 triệu item nghĩa là 1 triệu WCU, cộng với chi phí đọc để biết cần xoá gì (phải Scan trước). Và BatchWriteItem chỉ xử lý 25 item mỗi lời gọi, nên cần 40.000 lời gọi.
• D. Viết hàm đệ quy Scan rồi gọi DeleteItem — tệ nhất về mọi mặt: tốn RCU cho việc Scan toàn bảng, cộng WCU cho từng lần xoá, cộng thời gian chạy. DeleteItem từng cái một còn chậm hơn BatchWriteItem.
• C. Dùng DeleteItem với ConditionExpression — cùng vấn đề với D, và điều kiện còn không giúp gì ở đây (bạn muốn xoá tất cả, không cần lọc).

Ghi nhớ

Ba cách làm rỗng một bảng DynamoDB: | Cách | Chi phí | Thời gian | Ghi chú | |---|---|---|---| | Xoá và tạo lại bảng | MIỄN PHÍ | vài phút | mất cấu hình — phải khai lại | | TTL | MIỄN PHÍ | vài giờ, không đảm bảo | giữ nguyên bảng | | Xoá từng item | rất tốn WCU | rất lâu | chỉ hợp khi xoá một phần |

Những gì phải khai lại khi tạo bảng mới: | Cấu hình | Ghi chú | |---|---| | Khoá chính | | | GSI, LSI | LSI chỉ tạo được lúc tạo bảng | | Provisioned capacity hoặc billing mode | | | TTL, Streams, mã hoá | | | Tag, auto scaling policy | |

Nên nếu dùng cách này định kỳ, hãy viết script hoặc CloudFormation để tạo bảng nhất quán — đừng làm bằng tay.

Và một lưu ý về billing mode cho tình huống này: PAY_PER_REQUEST (on-demand) thường hợp hơn với job nạp theo lô mỗi đêm, vì bạn không phải cấp provisioned capacity cho một đỉnh tải chỉ xảy ra vài phút mỗi ngày — phần còn lại của ngày bảng gần như không được dùng.

Cuối cùng, nếu dữ liệu cần giữ lâu hơn để phân tích: cân nhắc nạp thẳng vào S3 rồi truy vấn bằng Athena thay vì DynamoDB — rẻ hơn nhiều cho dữ liệu chỉ đọc một lần rồi bỏ.