Ngân hàng đề AWS Certified Solutions Architect Associate

Câu 391

An Amazon EC2 administrator created the following policy associated with an IAM group containing several users:

What is the effect of this policy?

A Users can terminate an EC2 instance in any AWS Region except us-east-1.
B Users can terminate an EC2 instance with the IP address 10.100.100.1 in the us-east-1 Region.
C Users can terminate an EC2 instance in the us-east-1 Region when the user's source IP is 10.100.100.254.
D Users cannot terminate an EC2 instance in the us-east-1 Region when the user's source IP is 10.100.100.254.

Xem giải thích

Đáp án chuẩn

C — Người dùng huỷ được EC2 ở vùng us-east-1 khi thoả điều kiện trong chính sách

Quy tắc cần nắm

Chính sách kiểu này thường gồm một câu Allow cho ec2:TerminateInstances kèm khối Condition với hai loại ràng buộc hay gặp:

aws:RequestedRegion — giới hạn hành động chỉ có hiệu lực ở một vùng.
aws:SourceIp — giới hạn theo địa chỉ IP nguồn của lời gọi.

Điểm dễ nhầm: aws:SourceIp so với IP công khai mà lời gọi đi ra, không phải IP riêng của instance. Lời gọi từ trong VPC qua VPC endpoint sẽ không mang IP công khai, nên điều kiện này không khớp theo cách nhiều người tưởng.

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

Bản đề thiếu khối JSON của chính sách vì nó vốn là ảnh, nên không đối chiếu được từng dòng. Hãy đọc phần trên như bài học về cách các khoá điều kiện thu hẹp một câu Allow.

Câu 392

A solutions architect has created two IAM policies: Policy1 and Policy2. Both policies are attached to an IAM group.

A cloud engineer is added as an IAM user to the IAM group. Which action will the cloud engineer be able to perform?

A Deleting IAM users
B Deleting directories
C Deleting Amazon EC2 instances
D Deleting logs from Amazon CloudWatch Logs

Xem giải thích

Đáp án

C — Xoá instance Amazon EC2

Vì sao đúng

Khi nhiều chính sách cùng gắn vào một nhóm, quyền thực tế là hợp của mọi câu Allow, trừ đi mọi câu Deny tường minh. Deny luôn thắng Allow, bất kể thứ tự hay chính sách nào.

Vì vậy một hành động chỉ thực hiện được khi: có ít nhất một chính sách cho phép nó, và không chính sách nào từ chối nó. Trong bốn phương án, xoá instance EC2 là hành động duy nhất thoả cả hai vế.

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

A. Xoá IAM user, B. Xoá thư mục, D. Xoá log trong CloudWatch Logs — mỗi hành động này hoặc không được chính sách nào cho phép, hoặc bị một câu Deny chặn lại.

Nhớ nhanh

Đọc nhiều chính sách thì luôn quét Deny trước. Tìm thấy Deny khớp là dừng, không cần đọc tiếp.

Câu 393 Chọn nhiều đáp án

A solutions architect wants to use the following JSON text as an identity-based policy to grant specific permissions:

Which IAM principals can the solutions architect attach this policy to? (Choose two.)

A Role
B Group
C Organization
D Amazon Elastic Container Service (Amazon ECS) resource
E Amazon EC2 resource

Xem giải thích

Đáp án

A và B — Role và Group

Vì sao đúng

Chính sách theo danh tính gắn được vào đúng ba loại đối tượng trong IAM: user, group và role. Đề cho chọn hai, và hai phương án hợp lệ trong danh sách là role và group.

Điểm phân biệt cốt lõi: chính sách theo danh tính đi theo người gọi nên không có trường Principal — principal chính là thứ nó được gắn vào. Còn chính sách theo tài nguyên (bucket policy, key policy, trust policy) thì bắt buộc có Principal.

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

C. Organization — không phải một IAM principal; ở cấp tổ chức thì dùng SCP, một loại chính sách khác hẳn.
D. Tài nguyên ECS và E. Tài nguyên EC2 — là tài nguyên, không phải danh tính. Muốn cấp quyền cho chúng thì tạo vai rồi gắn vai đó cho tài nguyên.

Câu 394

The following IAM policy is attached to an IAM group. This is the only policy applied to the group.

What are the effective IAM permissions of this policy for group members?

A Group members are permitted any Amazon EC2 action within the us-east-1 Region. Statements after the Allow permission are not applied.
B Group members are denied any Amazon EC2 permissions in the us-east-1 Region unless they are logged in with multi-factor authentication (MFA).
C Group members are allowed the ec2:StopInstances and ec2:TerminateInstances permissions for all Regions when logged in with multi-factor authentication (MFA). Group members are permitted any other Amazon EC2 action.
D Group members are allowed the ec2:StopInstances and ec2:TerminateInstances permissions for the us-east-1 Region only when logged in with multi-factor authentication (MFA). Group members are permitted any other Amazon EC2 action within the us-east-1 Region.

Xem giải thích

Đáp án chuẩn

D

Quy tắc cần nắm

Với một chính sách vừa có Allow vừa có Deny gắn cho nhóm, thứ tự đánh giá luôn là:

Quét toàn bộ tìm Deny tường minh — khớp là từ chối ngay.
Không có Deny thì tìm Allow khớp cả hành động lẫn tài nguyên lẫn điều kiện.
Không có gì khớp thì từ chối ngầm.

Điểm hay bị bỏ sót: khối Condition thu hẹp phạm vi của câu chứa nó. Một câu Allow cho ec2:StopInstances kèm điều kiện về vùng chỉ có hiệu lực ở vùng đó; ngoài vùng đó, quyền rơi về từ chối ngầm chứ không phải "vẫn được phép".

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

Bản đề trong ngân hàng này thiếu khối JSON của chính sách vì nó vốn là ảnh, nên không truy ra được từng dòng dẫn tới đáp án. Hãy đọc phần trên như bài học về thứ tự đánh giá và vai trò của Condition.

Câu 395

A group requires permissions to list an Amazon S3 bucket and delete objects from that bucket. An administrator has created the following IAM policy to provide access to the bucket and applied that policy to the group. The group is not able to delete objects in the bucket. The company follows least-privilege access rules.

Which statement should a solutions architect add to the policy to correct bucket access?

A
B
C
D

Xem giải thích

Đáp án

D — Thêm câu cho phép s3:DeleteObject trên arn:aws:s3:::bucket-name/*

"Action":   ["s3:DeleteObject"],
"Resource": ["arn:aws:s3:::bucket-name/*"],
"Effect":   "Allow"

Vì sao đúng

Lỗi trong chính sách gốc nằm ở ARN của tài nguyên. S3 có hai loại ARN khác nhau, và mỗi hành động chỉ chấp nhận đúng một loại:

ARN	Trỏ tới	Dùng cho hành động
`arn:aws:s3:::bucket-name`	bản thân bucket	`s3:ListBucket`, `s3:GetBucketLocation`
`arn:aws:s3:::bucket-name/*`	các object bên trong	`s3:GetObject`, `s3:PutObject`, `s3:DeleteObject`

Chính sách gốc khai cả ListBucket lẫn DeleteObject trên cùng một ARN không có /*. Nên ListBucket chạy được, còn DeleteObject thì không khớp tài nguyên nào — đúng triệu chứng mà đề mô tả: liệt kê được nhưng xoá không được.

Phương án D bổ sung đúng phần thiếu, và chỉ cấp riêng DeleteObject, giữ được nguyên tắc quyền tối thiểu.

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

A. s3:*Object — ARN đúng nhưng hành động quá rộng: kéo theo cả GetObject, PutObject, RestoreObject… những quyền nhóm này không cần.
B. s3:* — rộng hơn nữa, cấp toàn quyền S3 trên object.
C. arn:aws:s3:::bucket-name* — thiếu dấu gạch chéo. Ký tự * dán thẳng vào tên bucket nên nó khớp những bucket có tên bắt đầu bằng chuỗi đó, chứ không khớp object nào. Câu lệnh xoá vẫn thất bại y như cũ, và tệ hơn là chính sách này còn vô tình chạm tới bucket khác.

Câu 396

A company uses Amazon EC2 instances to host its internal systems. As part of a deployment operation, an administrator tries to use the AWS CLI to terminate an EC2 instance. However, the administrator receives a 403 (Access Denied) error message.

The administrator is using an IAM role that has the following IAM policy attached:

What is the cause of the unsuccessful request?

A The EC2 instance has a resource-based policy with a Deny statement.
B The principal has not been specified in the policy statement.
C The "Action" field does not grant the actions that are required to terminate the EC2 instance.
D The request to terminate the EC2 instance does not originate from the CIDR blocks 192.0.2.0/24 or 203.0.113.0/24.

Xem giải thích

Đáp án

D — Yêu cầu huỷ instance không xuất phát từ dải CIDR mà chính sách cho phép

Vì sao đúng

Khi một lời gọi bị từ chối dù hành động và tài nguyên đều đúng, nghi phạm tiếp theo luôn là khối Condition. Điều kiện aws:SourceIp giới hạn lời gọi phải đến từ một dải địa chỉ nhất định — thường là mạng văn phòng hoặc VPN. Quản trị viên gọi từ ngoài dải đó sẽ bị từ chối, và thông báo lỗi không nói rõ nguyên nhân là điều kiện nào.

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

A. EC2 instance có resource policy với câu Deny — EC2 instance không có chính sách theo tài nguyên; khái niệm đó chỉ tồn tại với S3, KMS, SQS và một số dịch vụ khác.
B. Chưa khai Principal — chính sách theo danh tính không có trường này, và thiếu nó không phải lỗi.
C. Action không cấp đủ quyền — đề cho biết hành động đã đúng; nếu sai action thì lỗi sẽ chỉ thẳng ra điều đó.

Câu 397 Design Cost-Optimized Architectures

A leading social media analytics company is contemplating moving its dockerized application stack into AWS Cloud. The company is not sure about the pricing for using Amazon Elastic Container Service (Amazon ECS) with the EC2 launch type compared to the Amazon Elastic Container Service (Amazon ECS) with the Fargate launch type.

Which of the following is correct regarding the pricing for these two services?

A
Both Amazon ECS with EC2 launch type and Amazon ECS with Fargate launch type are charged based on vCPU and memory resources that the containerized application requests
B
Amazon ECS with EC2 launch type is charged based on EC2 instances and EBS volumes used. Amazon ECS with Fargate launch type is charged based on vCPU and memory resources that the containerized application requests
C
Both Amazon ECS with EC2 launch type and Amazon ECS with Fargate launch type are just charged based on Elastic Container Service used per hour
D
Both Amazon ECS with EC2 launch type and Amazon ECS with Fargate launch type are charged based on Amazon EC2 instances and Amazon EBS Elastic Volumes used

Xem giải thích

Đáp án

B — ECS với EC2 launch type tính phí theo EC2 instance và EBS volume đã dùng; ECS với Fargate launch type tính phí theo vCPU và bộ nhớ mà ứng dụng container YÊU CẦU.

Vì sao đúng

Hai launch type có mô hình chi phí hoàn toàn khác nhau, và đó là điểm phân biệt cốt lõi.

EC2 launch type — bạn trả tiền cho HẠ TẦNG:

Bạn quản lý một cụm EC2 instance
    → trả tiền cho INSTANCE (theo giờ) + EBS volume
    → dù container có dùng hết tài nguyên hay không
        ↓
    Instance chạy 24/7 với 30% mức dùng
    → vẫn trả tiền cho 100% instance

Fargate launch type — bạn trả tiền cho TÀI NGUYÊN TASK YÊU CẦU:

Task khai: 1 vCPU, 2 GB bộ nhớ
    → trả tiền đúng 1 vCPU và 2 GB
    → tính theo GIÂY (tối thiểu 1 phút)
    → task dừng là ngừng tính tiền
        ↓
    KHÔNG có instance nào để trả tiền

Và bản thân dịch vụ ECS MIỄN PHÍ — cả hai launch type đều không tính phí cho ECS.

Bảng so sánh chi phí thực tế:

Tải ỔN ĐỊNH, dùng hết công suất instance:
    → EC2 launch type RẺ HƠN (đặc biệt với Savings Plan)

Tải BIẾN ĐỘNG, nhiều lúc rảnh:
    → Fargate RẺ HƠN (không trả tiền lúc không chạy)

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

**A. Cả hai đều tính phí theo vCPU và bộ nhớ mà container yêu cầu — đây là phương án gần nhất và mô tả đúng Fargate, nhưng nó sai với EC2 launch type: với EC2, bạn trả tiền cho instance, không phải cho tài nguyên task yêu cầu. Một instance chạy một task nhỏ vẫn tính phí đầy đủ.
**D. Cả hai đều tính phí theo EC2 instance và EBS volume — sai với Fargate: Fargate không có instance nào để tính phí.
**C. Cả hai chỉ tính phí theo giờ dùng dịch vụ ECS — sai hoàn toàn: bản thân ECS MIỄN PHÍ. Chi phí đến từ tài nguyên compute bên dưới.

Ghi nhớ

Mô hình chi phí của các dịch vụ container: | Dịch vụ | Tính phí theo | |---|---| | ECS (bản thân dịch vụ) | MIỄN PHÍ | | ECS trên EC2 | EC2 instance + EBS volume | | ECS trên Fargate | vCPU-giây + GB-giây mà task YÊU CẦU | | EKS (control plane) | ~0,10 USD/giờ mỗi cụm | | EKS trên EC2 | control plane + EC2 instance | | EKS trên Fargate | control plane + vCPU-giây và GB-giây |

Chú ý dòng EKS: control plane tính phí, còn ECS thì không — đó là khác biệt chi phí đáng kể khi có nhiều cụm nhỏ.

Fargate và EC2 launch type — bảng phân biệt đầy đủ: | | Fargate | EC2 | |---|---|---| | Quản lý máy chủ | ❌ không có | ✅ bạn lo vá lỗi, co giãn | | Tính phí | theo task | theo instance | | Chi phí khi rảnh | 0 | vẫn trả tiền instance | | Đơn giá vCPU-giờ | cao hơn | thấp hơn | | GPU | ❌ | ✅ | | Daemon task | ❌ | ✅ | | Tuỳ chỉnh hệ điều hành | ❌ | ✅ | | Reserved / Savings Plan | ✅ Compute Savings Plan | ✅ đầy đủ |

Quy tắc chọn:

Tải biến động, đội ngũ nhỏ, muốn ít việc vận hành → Fargate Tải ổn định cao, cần GPU hoặc tuỳ chỉnh, tối ưu chi phí tối đa → EC2

Ràng buộc kết hợp CPU và bộ nhớ của Fargate:

0,25 vCPU → 0,5, 1, 2 GB
0,5 vCPU  → 1–4 GB
1 vCPU    → 2–8 GB
2 vCPU    → 4–16 GB
4 vCPU    → 8–30 GB
8 vCPU    → 16–60 GB
16 vCPU   → 32–120 GB

Không chọn tuỳ ý được — đây là chi tiết hay gây bất ngờ khi thiết kế task definition.

Ba cách giảm chi phí Fargate: | Cách | Mức tiết kiệm | |---|---| | Fargate Spot | tới 70% | | Compute Savings Plan | tới 50% với cam kết 1–3 năm | | Chọn đúng kích thước task | đo bằng Container Insights |

Và mixed capacity provider strategy là mẫu phổ biến:

{"capacityProviderStrategy": [
   {"capacityProvider": "FARGATE", "base": 2, "weight": 1},
   {"capacityProvider": "FARGATE_SPOT", "weight": 4}]}

Hai task luôn trên Fargate thường (đảm bảo dịch vụ), phần vượt dùng Spot.

Ba cách giảm chi phí ECS trên EC2: | Cách | Chi tiết | |---|---| | Savings Plan hoặc Reserved Instance | tới 72% cho mức nền | | Spot Instance cho phần vượt | tới 90% | | Tăng mật độ đóng gói task | targetCapacity cao hơn trong capacity provider |

Dòng cuối đáng chú ý:

targetCapacity = 100
    → cụm được lấp đầy tối đa trước khi thêm instance
    → ít lãng phí hơn, nhưng ít biên độ cho task mới
targetCapacity = 80
    → chừa 20% để đặt task mới ngay

Ba lưu ý về chi phí ẩn: | Khoản | Chi tiết | |---|---| | EBS volume của instance ECS | tính phí kể cả khi instance rảnh | | NAT Gateway để kéo image từ ECR | dùng VPC endpoint thay thế | | Load balancer | tính phí giờ dù không có lưu lượng |

Dòng giữa đáng kể với cụm container: kéo image Docker tốn rất nhiều băng thông, và qua NAT Gateway thì tính phí mỗi GB. Interface endpoint cho ECR rẻ hơn nhiều ở khối lượng lớn.

Ba công cụ đo và tối ưu: | Công cụ | Việc | |---|---| | Container Insights | mức dùng CPU và bộ nhớ thật của từng task | | Compute Optimizer | gợi ý kích thước phù hợp hơn | | Cost Explorer với thẻ | chi phí theo service, môi trường |

Container Insights là công cụ quan trọng nhất để chọn kích thước task:

Task khai 2 vCPU nhưng chỉ dùng 0,3 vCPU
    → giảm xuống 0,5 vCPU → tiết kiệm 75% chi phí task đó

Và một lời khuyên: hãy bắt đầu với Fargate cho ứng dụng mới. Nó loại bỏ toàn bộ công vận hành cụm, và với tải chưa rõ ràng thì mô hình trả theo mức dùng an toàn hơn. Khi tải đã ổn định và đủ lớn, hãy đo lại và cân nhắc chuyển sang EC2 với Savings Plan.

Câu 398 Design High-Performing Architectures

The engineering team at an e-commerce company wants to establish a dedicated, encrypted, low latency, and high throughput connection between its data center and AWS Cloud. The engineering team has set aside sufficient time to account for the operational overhead of establishing this connection.

As a solutions architect, which of the following solutions would you recommend to the company?

A
Use AWS Direct Connect to establish a connection between the data center and AWS Cloud
B
Use AWS Direct Connect plus virtual private network (VPN) to establish a connection between the data center and AWS Cloud
C
Use AWS Transit Gateway to establish a connection between the data center and AWS Cloud
D
Use AWS site-to-site VPN to establish a connection between the data center and AWS Cloud

Xem giải thích

Đáp án

B — Dùng AWS Direct Connect KẾT HỢP với VPN để thiết lập kết nối giữa trung tâm dữ liệu và AWS.

Vì sao đúng

Đề nêu bốn yêu cầu, và cụm từ "MÃ HOÁ (encrypted)" là điểm phân biệt quyết định: | Yêu cầu | Đáp ứng bởi | |---|---| | Kết nối CHUYÊN DỤNG | Direct Connect | | Độ trễ THẤP | Direct Connect | | Thông lượng CAO | Direct Connect | | MÃ HOÁ | VPN chạy QUA Direct Connect |

Và đây là chi tiết nhiều người không biết:

AWS Direct Connect KHÔNG mã hoá mặc định
    → nó là kết nối vật lý riêng, không đi qua Internet
    → riêng tư về mặt đường đi, NHƯNG dữ liệu KHÔNG được mã hoá
        ↓
    Muốn mã hoá → chạy IPsec VPN QUA kết nối DX

Kiến trúc kết hợp:

Trung tâm dữ liệu
    ↓ cáp vật lý riêng (Direct Connect)
    ↓ IPsec VPN tunnel chạy BÊN TRONG kết nối đó
Virtual Private Gateway hoặc Transit Gateway
    ↓
VPC

Kết quả: được cả bốn thứ. | Từ Direct Connect | Từ VPN | |---|---| | Băng thông cam kết | mã hoá IPsec | | Độ trễ ổn định | | | Không qua Internet | |

Và đề còn nói rõ đội ngũ chấp nhận công vận hành:

"has set aside sufficient time to account for the operational overhead"
    → Direct Connect mất HÀNG TUẦN tới hàng tháng để lắp đặt
    → đề đã tính tới điều đó

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

**A. Chỉ dùng AWS Direct Connect — đây là phương án gần nhất và đáp ứng ba trong bốn yêu cầu, nhưng nó thiếu vế MÃ HOÁ: DX không mã hoá dữ liệu. Đề nêu rõ "encrypted".
**D. Chỉ dùng Site-to-Site VPN — có mã hoá nhưng thiếu ba yêu cầu còn lại: VPN đi qua Internet công cộng, nên độ trễ biến động và băng thông giới hạn khoảng 1,25 Gbps mỗi tunnel. Không phải "dedicated, low latency, high throughput".
**C. Dùng AWS Transit Gateway để kết nối — không phải cơ chế kết nối: Transit Gateway là trung tâm ĐỊNH TUYẾN giữa các VPC và các kết nối. Nó không tạo ra đường kết nối vật lý nào tới trung tâm dữ liệu.

Ghi nhớ

Direct Connect và Site-to-Site VPN — bảng phân biệt cốt lõi: | | Direct Connect | Site-to-Site VPN | |---|---|---| | Đường đi | cáp VẬT LÝ riêng | Internet công cộng | | Băng thông | 50 Mbps – 100 Gbps | ~1,25 Gbps mỗi tunnel | | Độ trễ | ổn định, thấp | biến động | | MÃ HOÁ | ❌ KHÔNG mặc định | ✅ IPsec | | Thời gian thiết lập | hàng TUẦN tới tháng | vài PHÚT | | Chi phí | cao (phí cổng + truyền) | thấp | | Phí truyền dữ liệu ra | rẻ hơn đáng kể | giá Internet |

"Direct Connect không mã hoá" là chi tiết hay được hỏi.

Ba cách mã hoá lưu lượng qua Direct Connect: | Cách | Đặc điểm | |---|---| | VPN qua DX (IPsec) | phổ biến nhất, dùng public VIF hoặc transit VIF ← câu này | | MACsec | mã hoá ở TẦNG 2, chỉ với kết nối chuyên dụng tốc độ cao | | Mã hoá ở tầng ứng dụng | TLS cho từng kết nối |

MACsec đáng biết: nó mã hoá ở tầng liên kết dữ liệu với độ trễ gần như bằng không, nhưng chỉ có với dedicated connection 10 Gbps và 100 Gbps ở một số vị trí.

Ba loại virtual interface của Direct Connect: | Loại VIF | Dùng để | |---|---| | Private VIF | vào VPC riêng tư qua virtual private gateway | | Public VIF | truy cập dịch vụ CÔNG KHAI của AWS — dùng cho VPN over DX | | Transit VIF | vào Transit Gateway (kiến trúc nhiều VPC) |

Với VPN qua DX, mẫu chuẩn là dùng public VIF — VPN endpoint của AWS có địa chỉ công khai, và public VIF cho phép tới được nó qua kết nối DX.

Ba lưu ý về sẵn sàng cao của Direct Connect: | Lưu ý | Chi tiết | |---|---| | MỘT kết nối DX = KHÔNG có dự phòng | cáp đứt là mất kết nối | | Sẵn sàng cao thật cần HAI kết nối ở HAI vị trí | tốn gấp đôi | | Nên có VPN làm đường dự phòng | rẻ, nhanh, tự chuyển bằng BGP |

Kiến trúc được AWS khuyến nghị:

Direct Connect (đường chính, có VPN mã hoá bên trong)
    +
Site-to-Site VPN qua Internet (đường dự phòng)
    → BGP tự chuyển khi DX mất kết nối

Hai loại kết nối Direct Connect: | Loại | Băng thông | Đặt qua | |---|---|---| | Dedicated connection | 1, 10, 100 Gbps | AWS trực tiếp | | Hosted connection | 50 Mbps – 25 Gbps | đối tác Direct Connect |

Hosted connection linh hoạt hơn cho nhu cầu nhỏ và thường nhanh có hơn.

Ba thành phần bổ trợ: | Thành phần | Việc | |---|---| | Direct Connect Gateway | một DX phục vụ NHIỀU VPC ở nhiều Region — MIỄN PHÍ | | Link Aggregation Group (LAG) | gộp nhiều kết nối để tăng băng thông | | Transit VIF + Transit Gateway | kiến trúc hàng trăm VPC |

Direct Connect Gateway gần như luôn cần khi có nhiều hơn một VPC.

Và Accelerated Site-to-Site VPN là lựa chọn trung gian đáng biết:

VPN đi qua điểm biên AWS gần nhất (Global Accelerator)
    → rồi đi trên mạng xương sống AWS
    → độ trễ ổn định hơn VPN thường nhiều
    → thiết lập vẫn nhanh như VPN
        ↓
    Không bằng DX, nhưng tốt hơn VPN qua Internet thuần

Ba yếu tố chi phí của Direct Connect: | Khoản | Chi tiết | |---|---| | Phí cổng theo giờ | tuỳ băng thông | | Phí truyền dữ liệu RA | rẻ hơn Internet đáng kể | | Phí của đối tác hoặc trung tâm dữ liệu | với hosted connection |

Dòng giữa là lý do kinh tế thật của DX: với tổ chức truyền hàng trăm terabyte ra khỏi AWS mỗi tháng, phần tiết kiệm ở phí truyền có thể bù toàn bộ chi phí cổng.

Và một lời khuyên về kế hoạch: hãy dựng Site-to-Site VPN trước để đội ngũ bắt đầu làm việc ngay, rồi chuyển sang DX khi nó sẵn sàng — và giữ VPN lại làm đường dự phòng. Thời gian lắp đặt DX tính bằng tuần, và không nên là thứ chặn tiến độ dự án.

Câu 399 Design Secure Architectures

A development team requires permissions to list an Amazon S3 bucket and delete objects from that bucket. A systems administrator has created the following IAM policy to provide access to the bucket and applied that policy to the group. The group is not able to delete objects in the bucket. The company follows the principle of least privilege.

    "Version": "2021-10-17",
    "Statement": [
        {
            "Action": [
                "s3:ListBucket",
                "s3:DeleteObject"
            ],
            "Resource": [
                "arn:aws:s3:::example-bucket"
            ],
            "Effect": "Allow"
        }
    ]

Which statement should a solutions architect add to the policy to address this issue?

A

{
    "Action": [
        "s3:*"
    ],
    "Resource": [
        "arn:aws:s3:::example-bucket/*"
    ],
    "Effect": "Allow"
}

B

{
    "Action": [
        "s3:DeleteObject"
    ],
    "Resource": [
        "arn:aws:s3:::example-bucket/*"
    ],
    "Effect": "Allow"
}

C

{
    "Action": [
        "s3:*Object"
    ],
    "Resource": [
        "arn:aws:s3:::example-bucket/*"
    ],
    "Effect": "Allow"
}

D

{
    "Action": [
        "s3:DeleteObject"
    ],
    "Resource": [
        "arn:aws:s3:::example-bucket*"
    ],
    "Effect": "Allow"
}

Xem giải thích

Đáp án

B — Thêm statement cho phép s3:DeleteObject trên resource arn:aws:s3:::example-bucket/*.

Vì sao đúng

Policy hiện tại có một lỗi kinh điển: dùng ARN của BUCKET cho hành động trên OBJECT.

Hai loại ARN của S3 — và chúng KHÔNG thay thế nhau:

arn:aws:s3:::example-bucket       → chính BUCKET
arn:aws:s3:::example-bucket/*     → các OBJECT bên trong bucket

Và mỗi hành động cần đúng loại ARN: | Hành động | ARN cần | |---|---| | s3:ListBucket | ARN của BUCKET (không có /*) | | s3:DeleteObject | ARN của OBJECT (có /*) | | s3:GetObject, s3:PutObject | ARN của object | | s3:GetBucketPolicy | ARN của bucket |

Policy trong đề gán cả hai hành động cho ARN của bucket:

"Action": ["s3:ListBucket", "s3:DeleteObject"],
"Resource": ["arn:aws:s3:::example-bucket"]
    ↓
    s3:ListBucket  → ĐÚNG ARN → hoạt động ✅
    s3:DeleteObject → SAI ARN → KHÔNG hoạt động ✗

Đó chính xác là triệu chứng mà đề mô tả: liệt kê được nhưng không xoá được.

Và đáp án B bổ sung đúng thứ thiếu:

{"Action": ["s3:DeleteObject"],
 "Resource": ["arn:aws:s3:::example-bucket/*"],
 "Effect": "Allow"}

Và nó tuân thủ quyền tối thiểu — chỉ thêm đúng hành động cần, không mở rộng gì thêm.

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

**C. Thêm s3:*Object trên example-bucket/* — đây là phương án gần nhất và hoạt động được, nhưng nó cấp thừa quyền: s3:*Object bao gồm GetObject, PutObject, DeleteObject, RestoreObject, GetObjectAcl, PutObjectAcl... Đề nói rõ công ty tuân thủ nguyên tắc quyền tối thiểu.
**A. Thêm s3:* trên example-bucket/* — cấp thừa nhiều nhất: bao gồm mọi hành động S3 có thể áp cho object.
**D. Thêm s3:DeleteObject trên arn:aws:s3:::example-bucket* (dấu * liền sau tên, không có /) — sai và nguy hiểm: ARN này khớp với mọi bucket có tên BẮT ĐẦU bằng example-bucket — ví dụ example-bucket-backup, example-bucket-production. Đó là phạm vi rộng ngoài ý muốn.

Ghi nhớ

Hai loại ARN của S3 — thuộc lòng:

arn:aws:s3:::ten-bucket       → thao tác trên BUCKET
arn:aws:s3:::ten-bucket/*     → thao tác trên OBJECT

Và policy đầy đủ thường cần CẢ HAI:

{"Effect": "Allow",
 "Action": ["s3:ListBucket", "s3:GetBucketLocation"],
 "Resource": "arn:aws:s3:::example-bucket"},
{"Effect": "Allow",
 "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
 "Resource": "arn:aws:s3:::example-bucket/*"}

Bảng phân loại hành động S3: | Nhóm | Hành động | ARN | |---|---|---| | Trên BUCKET | ListBucket, GetBucketLocation, GetBucketPolicy, PutBucketPolicy | không có /* | | Trên OBJECT | GetObject, PutObject, DeleteObject, GetObjectVersion | có /* |

Và s3:ListBucket là hành động hay gây nhầm nhất — tên có chữ "Bucket" và nó thực sự áp cho bucket, dù kết quả trả về là danh sách object.

Ba cạm bẫy về dấu * trong ARN: | Viết | Khớp với | |---|---| | arn:aws:s3:::bucket | chỉ bucket đó | | arn:aws:s3:::bucket/* | mọi object trong bucket đó | | arn:aws:s3:::bucket* | MỌI BUCKET có tên bắt đầu bằng "bucket" ← nguy hiểm | | arn:aws:s3:::bucket/thu-muc/* | object trong một prefix |

Dòng thứ ba là lỗi bảo mật thật — nó vô tình cấp quyền cho các bucket khác có tên tương tự.

Ba mức phân quyền theo prefix:

{"Effect": "Allow", "Action": "s3:GetObject",
 "Resource": "arn:aws:s3:::example-bucket/nhom-a/*"}

Cho phép truy cập chỉ một thư mục — hữu ích khi nhiều đội dùng chung bucket.

Và điều kiện s3:prefix giới hạn cả việc LIỆT KÊ:

{"Effect": "Allow", "Action": "s3:ListBucket",
 "Resource": "arn:aws:s3:::example-bucket",
 "Condition": {"StringLike": {"s3:prefix": ["nhom-a/*"]}}}

Không có điều kiện này, người dùng liệt kê được TOÀN BỘ tên tệp trong bucket — dù không đọc được nội dung.

Ba lưu ý về phiên bản trong policy: | Trường | Chi tiết | |---|---| | "Version" | phải là "2012-10-17" | | "Version": "2021-10-17" | KHÔNG hợp lệ | | "Version": "2008-10-17" | bản cũ, không hỗ trợ biến policy |

Policy trong đề ghi "2021-10-17" — đó là một lỗi thứ hai mà câu hỏi không hỏi tới, nhưng đáng lưu ý: giá trị này không hợp lệ và policy sẽ bị từ chối khi lưu.

Ba công cụ kiểm chứng policy: | Công cụ | Việc | |---|---| | IAM Policy Simulator | thử một hành động trên một tài nguyên, xem kết quả kèm lý do | | IAM Access Analyzer policy validation | cảnh báo về cú pháp và quyền quá rộng | | Access Analyzer policy generation | sinh policy từ hoạt động THẬT trong CloudTrail |

Policy Simulator là cách nhanh nhất chẩn đoán lỗi trong đề:

Thử s3:DeleteObject trên arn:aws:s3:::example-bucket/tep.txt
    → kết quả: implicitly denied
    → lý do: không có statement nào khớp resource này

Và với xoá object trong bucket có versioning, cần thêm quyền:

{"Action": ["s3:DeleteObject", "s3:DeleteObjectVersion"],
 "Resource": "arn:aws:s3:::example-bucket/*"}

DeleteObject chỉ tạo delete marker; xoá vĩnh viễn một phiên bản cần DeleteObjectVersion.

Và một lời khuyên: hãy chạy IAM Access Analyzer policy generation cho các nhóm người dùng. Nó đọc CloudTrail và sinh ra policy khớp chính xác những gì họ thực sự dùng — cách đó tránh được cả việc thiếu quyền (như lỗi trong đề) lẫn việc cấp thừa.

Câu 400 Chọn nhiều đáp án Design Resilient Architectures

The DevOps team at an e-commerce company wants to perform some maintenance work on a specific Amazon EC2 instance that is part of an Auto Scaling group using a step scaling policy. The team is facing a maintenance challenge - every time the team deploys a maintenance patch, the instance health check status shows as out of service for a few minutes. This causes the Auto Scaling group to provision another replacement instance immediately.

As a solutions architect, which are the MOST time/resource efficient steps that you would recommend so that the maintenance work can be completed at the earliest? (Select two)

A
Put the instance into the Standby state and then update the instance by applying the maintenance patch. Once the instance is ready, you can exit the Standby state and then return the instance to service
B
Suspend the ScheduledActions process type for the Auto Scaling group and apply the maintenance patch to the instance. Once the instance is ready, you can you can manually set the instance's health status back to healthy and activate the ScheduledActions process type again
C
Take a snapshot of the instance, create a new Amazon Machine Image (AMI) and then launch a new instance using this AMI. Apply the maintenance patch to this new instance and then add it back to the Auto Scaling Group by using the manual scaling policy. Terminate the earlier instance that had the maintenance issue
D
Suspend the ReplaceUnhealthy process type for the Auto Scaling group and apply the maintenance patch to the instance. Once the instance is ready, you can manually set the instance's health status back to healthy and activate the ReplaceUnhealthy process type again
E
Delete the Auto Scaling group and apply the maintenance fix to the given instance. Create a new Auto Scaling group and add all the instances again using the manual scaling policy

Xem giải thích

Đáp án

A và D.

A — Đưa instance vào trạng thái Standby, áp bản vá, rồi thoát khỏi Standby và trả instance về phục vụ
D — Tạm dừng tiến trình ReplaceUnhealthy của Auto Scaling group, áp bản vá, rồi đặt lại trạng thái sức khoẻ và kích hoạt lại tiến trình

Vì sao đúng

Đề nêu vấn đề rõ: áp bản vá làm health check thất bại vài phút, và ASG lập tức thay instance bằng máy mới.

Và hai đáp án là hai cách chuẩn để tạm ngăn ASG can thiệp:

A — Standby state là cách sạch nhất:

Đưa instance vào Standby:
    → ASG NGỪNG tính nó vào số lượng mong muốn
    → ASG KHÔNG chạy health check trên nó
    → ASG KHÔNG thay thế nó
    → và tự động gỡ khỏi target group của load balancer
        ↓
Bảo trì xong → thoát Standby → instance quay lại phục vụ

aws autoscaling enter-standby --instance-ids i-0abc123   --auto-scaling-group-name asg-ung-dung   --should-decrement-desired-capacity

# ... áp bản vá ...

aws autoscaling exit-standby --instance-ids i-0abc123   --auto-scaling-group-name asg-ung-dung

D — hoặc tạm dừng đúng tiến trình gây vấn đề:

ReplaceUnhealthy là tiến trình chịu trách nhiệm
    thay instance bị đánh giá là không khoẻ
        ↓
    Tạm dừng nó → ASG không thay instance nào
    → bảo trì xong thì đặt lại trạng thái khoẻ và bật lại

aws autoscaling suspend-processes --auto-scaling-group-name asg-ung-dung   --scaling-processes ReplaceUnhealthy

# ... áp bản vá ...

aws autoscaling set-instance-health --instance-id i-0abc123   --health-status Healthy
aws autoscaling resume-processes --auto-scaling-group-name asg-ung-dung   --scaling-processes ReplaceUnhealthy

Cả hai đều nhanh và không phá vỡ cấu hình gì.

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

**B. Tạm dừng tiến trình ScheduledActions — đây là phương án gần nhất và có cấu trúc đúng, nhưng nó tạm dừng sai tiến trình: ScheduledActions chỉ liên quan tới các hành động co giãn theo lịch. Nó không ảnh hưởng gì tới việc ASG thay instance không khoẻ.
**C. Chụp snapshot, tạo AMI mới, khởi chạy instance mới, vá rồi thêm vào ASG — rất tốn thời gian và tài nguyên: quá trình này mất hàng chục phút, trong khi đề hỏi cách "MOST time/resource efficient".
**E. Xoá cả Auto Scaling group, vá, rồi tạo lại và thêm mọi instance — cực đoan và rủi ro: mất toàn bộ cấu hình co giãn, và trong lúc không có ASG thì không có gì thay instance hỏng.

Ghi nhớ

Bảy tiến trình của Auto Scaling group — bảng cần thuộc: | Tiến trình | Việc | |---|---| | Launch | khởi chạy instance mới | | Terminate | chấm dứt instance | | HealthCheck | kiểm tra sức khoẻ instance | | ReplaceUnhealthy | THAY instance được đánh giá không khoẻ ← câu này | | AZRebalance | cân bằng lại instance giữa các AZ | | AlarmNotification | phản ứng với CloudWatch alarm | | ScheduledActions | thực thi hành động theo lịch | | AddToLoadBalancer | đăng ký instance vào load balancer | | InstanceRefresh | thay toàn bộ đội máy |

Phân biệt HealthCheck và ReplaceUnhealthy:

HealthCheck:      ĐÁNH GIÁ instance khoẻ hay không
ReplaceUnhealthy: THAY instance đã bị đánh giá là không khoẻ
    → tạm dừng ReplaceUnhealthy vẫn cho ASG đánh giá
      nhưng không hành động

Standby state — vòng đời của instance trong ASG:

Pending → InService → Standby → InService
                    ↘ Terminating → Terminated

Ba đặc điểm của Standby: | Đặc điểm | Chi tiết | |---|---| | Không tính vào DesiredCapacity | tuỳ tham số should-decrement-desired-capacity | | Tự gỡ khỏi target group | không nhận lưu lượng | | ASG không thay thế | và không chạy health check |

Và tham số --should-decrement-desired-capacity quyết định hành vi:

CÓ khai:    DesiredCapacity giảm 1 → ASG không khởi chạy máy bù
KHÔNG khai: DesiredCapacity giữ nguyên → ASG khởi chạy MỘT MÁY MỚI để bù

Với bảo trì ngắn, nên khai — tránh việc ASG dựng thêm máy rồi lại phải gỡ.

Ba cách bảo trì instance trong ASG: | Cách | Phù hợp | |---|---| | Standby state | bảo trì một hoặc vài instance cụ thể ← câu này | | Suspend ReplaceUnhealthy | tương tự, ở mức cả nhóm | | Instance refresh | thay TOÀN BỘ đội máy bằng AMI mới |

Instance refresh là cách đúng cho việc vá lỗi định kỳ:

aws autoscaling start-instance-refresh   --auto-scaling-group-name asg-ung-dung   --preferences '{"MinHealthyPercentage": 90, "InstanceWarmup": 300,
                  "CheckpointPercentages": [20, 50, 100],
                  "CheckpointDelay": 600}'

CheckpointPercentages cho phép thay theo đợt và dừng lại quan sát — an toàn hơn nhiều so với vá tay từng máy.

Và AWS Systems Manager Patch Manager là công cụ chuẩn cho việc vá lỗi:

Patch Manager:
    ✓ vá theo lịch, theo baseline
    ✓ vá theo nhóm (patch group) để không vá hết cùng lúc
    ✓ báo cáo tuân thủ
    ✓ tích hợp maintenance window

Nó giải quyết bài toán của đề một cách hệ thống hơn — thay vì xử lý từng lần vá thủ công.

Ba lưu ý khi dùng Standby: | Lưu ý | Chi tiết | |---|---| | Instance vẫn TÍNH PHÍ | Standby không phải dừng máy | | Nhớ thoát Standby sau khi xong | quên thì máy nằm đó không phục vụ mà vẫn tốn tiền | | Kiểm tra dung lượng còn lại đủ không | gỡ một máy khi đang cao điểm có thể gây quá tải |

Ba lưu ý khi tạm dừng tiến trình: | Lưu ý | Chi tiết | |---|---| | NHỚ bật lại | quên là ASG mất khả năng tự phục hồi | | Tạm dừng áp cho CẢ NHÓM | không chỉ một instance | | Đặt nhắc nhở hoặc tự động hoá | tránh quên |

Dòng đầu là rủi ro thật: một ASG bị tạm dừng ReplaceUnhealthy trong nhiều tháng sẽ không thay instance chết nào — và không ai biết cho tới khi có sự cố.

Và một lời khuyên: hãy thiết kế để không cần vá tay. Với AMI được nướng sẵn qua EC2 Image Builder và instance refresh theo lịch, việc vá lỗi trở thành thay máy chứ không phải sửa máy — sạch hơn, kiểm chứng được, và quay lui dễ dàng.

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

Đáp án chuẩn

Quy tắc cần nắm

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

Đáp án

Vì sao đúng

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

Nhớ nhanh

Đáp án

Vì sao đúng

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

Đáp án chuẩn

Quy tắc cần nắm

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

Đáp án

Vì sao đúng

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

Đáp án

Vì sao đúng

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

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ